Назад | Перейти на главную страницу

Как я могу использовать AWS CloudFront и API Gateway одновременно для одного домена?

Я помещаю эти статические ресурсы своего веб-сайта на S3 и настраиваю CloudFront для их распространения. По сути, они содержат контент, который потребуется пользователям для любого запроса GET на моем сайте, по существующим путям, то есть со списком ошибок.

У меня также есть несколько запросов POST, которые мне нужно обработать. Отправка форм, отправка писем, уведомлений, взаимодействие с базой данных.

Как я могу настроить Lambda (или API Gateway) бок о бок с CloudFront для того же домена, чтобы CloudFront обрабатывал запросы GET, а шлюз API обрабатывал запросы с телом или запросами POST. Или можно как-то по индивидуальному URL?

Вы можете создать лямбда-функцию, настроить шлюз API, а затем настроить CloudFront для пересылки определенных путей (например, / rest / *) в шлюз API и обслуживания всего остального из корзины S3.

Вот полное руководство, показывающее, как это сделать: https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/

С точки зрения подключения «что-то» должно отвечать на ваши запросы (GET, POST, PUT, все). Прежде всего, у вас есть TCP-соединение, и «что-то» должно убедиться, что оно понимает уровень 7 и имеет смысл в байтах, которые отправляет клиент. Только на этом этапе можно обрабатывать запросы GET иначе, чем запросы POST или один URL-адрес, чем другой URL-адрес. Итак, в конце концов, вам нужна служба, способная понимать и маршрутизировать HTTP. На это способны следующие сервисы: CloudFront ELB / ALB API Gateway (ограничение появится позже)

API Gateway использует CloudFront внутри (не давая вам возможности фактически настроить что-либо на уровне CloudFront) - это означает, что нет возможности запускать CloudFront и API Gateway одновременно, поскольку в конечном итоге это будет означать, что вы запускаете CloudFront с CloudFront бок о бок.

CloudFront дает вам возможность выбрать другое происхождение на основе шаблонов, но вы можете выбрать только S3 или ELB / ALB в качестве источника, но не функции Lambda (кроме функциональности Lambda @ Edge).

ALB / ELB может использовать только экземпляры EC2 в качестве бэкэнда - здесь нет Lambda или S3.

Единственные способы, которые я могу придумать, могут сделать то, что вы хотите, это следующие:

  • Вы используете API-шлюз и маршрутизируете определенный «актив» -путь к лямбда-функции, которая выполняет своего рода обратный прокси-сервер для S3 (таким образом, передавая статические активы через лямбда) - помните о затратах на Lambda здесь!
  • Вы могли бы сделать то же самое, но вместо того, чтобы передавать ресурс через Lambda, просто сгенерируйте подписанный URL-адрес в Lambda, перенаправление непосредственно на S3 для обслуживания (может быть более экономичным)
  • Использование разных поддоменов для ваших активов, чем остальная часть вашего приложения - это очень распространенный шаблон, поскольку вы можете легко разделиться на уровне DNS и использовать разные службы для разных сценариев использования (CloudFront для активов и API Gateway для нестатических части)

Таким образом, мой вызов был бы последним вариантом, но это означает, что вам нужно указать клиентам / браузерам отдельный субдомен для всех статических ресурсов (или для всех запросов POST).

Похоже, вы хотите взглянуть на такие технологии, как AngularJS или React, чтобы создать в браузере действительно управляемое API приложение. При таком подходе вы используете настоящий API, который обрабатывает все «динамические» запросы с помощью шлюза API и доставляет само приложение из S3 как статический актив. Возможно, их просмотр поможет вам сориентироваться - даже если вы их не используете, архитектурный паттерн того, как создавать такие вещи, - это то, о чем вы просите imho.

Я запускаю несколько веб-приложений в соответствии с предложенным вами дизайном и извлекаю гофаас, образовательное приложение Go и Lambda, чтобы поделиться своими приемами.

Вам нужны два отдельных домена, например www.gofaas.net для S3 + CloudFront и api.gofaas.net для API Gateway + Lambda.

Затем вы можете позволить своему статическому сайту взаимодействовать с API с помощью конфигурации CORS шлюза API и некоторого кода JavaScript:

fetch(`https://api.gofaas.net/work`, {
    method: "POST",
    mode: "cors",
    headers: {
        "Accept": "application/json",
        ...
    },
    body: JSON.stringify(...)
})
    .then(function(response) {
        return response.json();
    })
    .then(function (json) {
        // use response
    })
    .catch(function (err) {
        console.log("fetch error", err);
    });

Вот несколько руководств по настройке всего этого:

Статические сайты с S3, CloudFront и ACM

Безопасность API с помощью Lambda, API Gateway, CORS и JWT

У меня такая же установка. Статические ресурсы на S3, функции Lambda обслуживаются через шлюз API, и они имеют одно и то же доменное имя.

Я использую шлюз API, который уже использует CloudFront и предоставляет некоторые его функции, такие как кеширование. Затем я настраиваю URI, которые сопоставляются со статическими активами. В API Gateway ресурс может быть функцией Lambda, функцией AWS, макетом или другим URL-адресом. Они указывают на мои URL-адреса S3.

URI также могут быть настроены для поиска подпути, например /assets/*.