☰

AWS — сопоставление URL-адреса с API-бэкендом (например, Apache ProxyPass)

tag-icon • tag-icon amazon-ec2 amazon-web-services reverse-proxy amazon-s3 amazon-cloudfront
AWS — сопоставление URL-адреса с API-бэкендом (например, Apache ProxyPass)

У меня есть веб-архитектура, использующая Apache в качестве фронтенда и Nodejs в качестве бэкенда. Я хочу перенести эту архитектуру в AWS. Node.js будет Elastic Beanstalk, а Apache будет храниться на Amazon S3 (он хранит только статические файлы).

Я использую эти директивы для сопоставления URL-пути /api с бэкэндом в Apache:

<Location /api>
    ProxyPass http://localhost:8081/api
</Location>

Я хотел бы использовать тот же механизм в AWS. Я обнаружил, что Amazon S3 не сможет этого сделать, поскольку это всего лишь сервис хранения.

Я узнал, что Amazon CloudFrontможно использовать несколько Amazon CloudFrontисточников, которые могут быть Amazon S3сегментами или Amazon Elastic Load Balancers. Затем я бы использовал Amazon EC2для размещения моего приложения Node.js backend сAmazon Load Balancer

Окончательная архитектура будет выглядеть так:

                        - Amazon Elastic Load Balancer -> Amazon EC2
                 /api  /
                      /
-->Amazon CloudFront-<
                      \
                 else  \
                        - Amazon S3

Возможен ли такой тип архитектуры? Если да, то является ли это лучшим способом достижения такого типа архитектуры в AWS?

Спасибо всем за ваши ответы!

решение1

Да... используйте CloudFront.

Конечно, его официальное предназначение — кэширующая CDN, но у него есть встроенная возможность выборочно направлять запросы в соответствующую исходную систему в зависимости от пути.

Итак, вы настраиваете свой путь по умолчанию на S3, и запросы будут отправляться в ваш контейнер. Настройте второй источник, указывающий на Elastic Load Balancer перед вашим развертыванием Elastic Beanstalk. Установите шаблон пути для /api/*маршрутизации запросов к этому второму источнику.

Функцию кэширования можно отключить, если она не нужна или нежелательна.

Развертывание CloudFront называется «распределением».

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web.html

Является ли это "лучшим" подходом? Это зависит от вашего опыта и креативности... но если вы хотите использовать доступные компоненты AWS, то да, это, вероятно, путь. Это единственный компонент, который обеспечивает по сути не требующую обслуживания маршрутизацию запросов по пути на http. (Шлюз API Amazon также маршрутизирует по путям, конечно, но он не подходит для этого приложения с S3 в качестве "подстановочного" пункта назначения.)

Связанный контент