Lambda@Edge

Lambda@Edge — это сервис бессерверных вычислений, предоставляемый Amazon Web Services (AWS — организация, осуществляющая деятельность на территории РФ), который позволяет выполнять пользовательский код в ответ на события, происходящие на глобальных точках присутствия сети доставки контента Amazon CloudFront. Lambda@Edge расширяет возможности стандартной AWS Lambda, позволяя запускать функции в инфраструктуре, расположенной географически ближе к конечным пользователям, что снижает задержки и повышает производительность веб-приложений и API.

Архитектура и принцип работы

Lambda@Edge работает в рамках архитектуры бессерверных вычислений, где разработчику не требуется управлять серверами, операционными системами или масштабированием. Код упаковывается в виде функции AWS Lambda, которая затем ассоциируется с определённым поведением дистрибутива Amazon CloudFront.

Триггеры CloudFront

Основное отличие Lambda@Edge от обычной Lambda заключается в том, что функция запускается не по прямому вызову через API, а в ответ на четыре типа событий, происходящих в процессе обработки запроса пользователя к CloudFront:

1. Запрос зрителя (Viewer Request): Функция выполняется, когда CloudFront получает запрос от конечного пользователя (зрителя), но до того, как будет проверен кэш. Это позволяет модифицировать входящий запрос (например, переписывать URL, добавлять заголовки, проверять cookies) до того, как он будет обработан.
2. Запрос источника (Origin Request): Функция выполняется только в том случае, если запрошенный объект отсутствует в кэше CloudFront (кэш-промах) и перед тем, как CloudFront направит запрос к исходному серверу (origin). Здесь можно, например, динамически генерировать запрос к источнику, изменять путь или заголовки.
3. Ответ источника (Origin Response): Функция выполняется после того, как CloudFront получил ответ от исходного сервера, но до того, как этот ответ будет помещён в кэш и отправлен пользователю. Это позволяет модифицировать ответ (например, добавлять заголовки безопасности, сжимать контент, изменять статусные коды) или даже кэшировать ответы с ошибками.
4. Ответ зрителя (Viewer Response): Функция выполняется перед отправкой ответа конечному пользователю, независимо от того, был ли объект взят из кэша или получен от источника. Это последняя возможность изменить ответ перед его доставкой (например, вставить скрипт аналитики во все HTML-страницы).

Выполнение на границе сети

Функции Lambda@Edge развёртываются не в одном регионе AWS, а реплицируются на множество точек присутствия CloudFront по всему миру. Когда пользователь делает запрос, он направляется к ближайшей точке присутствия, где и выполняется соответствующая функция. Это обеспечивает минимальную задержку (latency) при обработке запроса, так как код выполняется на «границе» (edge) сети, а не в центральном дата-центре.

Возможности и ограничения

Lambda@Edge предоставляет широкие возможности для кастомизации доставки контента, но имеет ряд ограничений, связанных с её архитектурой.

Возможности

• Модификация HTTP-запросов и ответов: Изменение URL, заголовков, cookies, query-параметров, статусных кодов и тел ответов.
• A/B-тестирование: Перенаправление части пользователей на разные версии приложения на основе cookies или других параметров.
• Перенаправление и перезапись URL: Реализация «красивых» URL, редиректов (301/302) и обработка ошибок 404.
• Аутентификация и авторизация: Проверка JWT-токенов, cookies или других механизмов аутентификации на границе сети, без обращения к основному серверу.
• Генерация динамического контента: Создание HTML-страниц, изображений или других ресурсов «на лету» в зависимости от запроса пользователя.
• Безопасность: Добавление заголовков безопасности (например, Content-Security-Policy, HSTS), фильтрация вредоносных запросов (например, на уровне URL или headers).
• Интеграция с другими сервисами: Вызов API или баз данных из функции Lambda@Edge (например, для проверки подписки пользователя или получения персонализированных данных).

Ограничения

• Время выполнения: Максимальное время выполнения функции ограничено 5 секундами для триггеров «Запрос зрителя» и «Ответ зрителя», и 30 секундами для «Запрос источника» и «Ответ источника». Это связано с необходимостью быстрой обработки запросов на границе сети.
• Размер функции: Максимальный размер развёрнутого пакета функции (включая зависимости) составляет 50 МБ. Размер кода после распаковки не должен превышать 3 МБ для триггеров, связанных со зрителем, и 50 МБ для триггеров, связанных с источником.
• Размер ответа: Максимальный размер тела ответа, который может быть сгенерирован или модифицирован функцией, составляет 1 МБ для триггеров «Ответ зрителя» и «Ответ источника».
• Отсутствие поддержки VPC: Функции Lambda@Edge не могут быть развёрнуты внутри виртуального частного облака (VPC) AWS. Это означает, что они не имеют прямого доступа к ресурсам, находящимся в VPC (например, к базам данных RDS или ElastiCache), без использования публичных эндпоинтов или NAT-шлюзов.
• Ограничения по языкам: Поддерживаются те же языки, что и для AWS Lambda: Node.js, Python, Java, Go, .NET Core и Ruby. Однако версии рантаймов могут быть более старыми, чем в основных регионах.
• Отсутствие переменных окружения: В Lambda@Edge не поддерживаются переменные окружения. Для передачи конфигурации необходимо использовать код функции или внешние сервисы (например, AWS Systems Manager Parameter Store или AWS Secrets Manager).
• Логирование и мониторинг: Логи функций записываются в Amazon CloudWatch Logs, но в регионе, где находится точка присутствия, а не в центральном регионе. Это может усложнить агрегацию и анализ логов.

Сравнение с AWS Lambda

Примеры использования

Перенаправление на мобильную версию

Функция Lambda@Edge, привязанная к триггеру «Запрос зрителя», может анализировать заголовок User-Agent в запросе пользователя. Если запрос исходит от мобильного устройства, функция переписывает URL, перенаправляя пользователя на поддомен m.example.com, или изменяет путь к ресурсу на /mobile/index.html.

A/B-тестирование

Функция, привязанная к триггеру «Запрос зрителя», может читать специальную cookie (например, experiment_id). В зависимости от значения cookie, функция модифицирует запрос к источнику, добавляя заголовок X-Experiment-Version: B, что позволяет исходному серверу отдавать разные версии страницы для разных групп пользователей.

Защита от DDoS-атак

Lambda@Edge может использоваться для фильтрации входящих запросов на раннем этапе. Функция проверяет IP-адрес, заголовки или URL на наличие известных паттернов атак (например, SQL-инъекций или XSS) и возвращает ответ с кодом 403 (Forbidden) для вредоносных запросов, не допуская их до исходного сервера.

Динамическая генерация изображений

Функция, привязанная к триггеру «Запрос источника», может анализировать параметры запроса (например, ?width=200&height=300). Если запрошенный объект отсутствует в кэше, функция может вызвать сервис обработки изображений (например, AWS Lambda в регионе), получить обработанное изображение и вернуть его в ответе, которое затем будет закэшировано CloudFront.

Стоимость

Ценообразование на Lambda@Edge основывается на количестве запросов, выполненных функциями, и времени их выполнения (с округлением до 100 мс). Стоимость за запрос и за гигасекунду (GiB-second) обычно выше, чем для обычной AWS Lambda, из-за глобального развёртывания и более низких задержек. Первый уровень использования (до определённого количества запросов и времени выполнения) может быть бесплатным в рамках бессрочного бесплатного предложения AWS.

История

Сервис Lambda@Edge был анонсирован на конференции re:Invent в 2016 году и стал доступен в 2017 году. Он стал одним из первых сервисов, реализующих концепцию «edge computing» (периферийных вычислений) в рамках публичного облака, позволяя выполнять код непосредственно на границе сети доставки контента.

Критика

Основные критические замечания в адрес Lambda@Edge связаны с её ограничениями по сравнению с обычной Lambda. Отсутствие поддержки VPC, ограниченное время выполнения и размер пакета, а также сложность отладки и мониторинга из-за распределённой природы сервиса часто упоминаются как недостатки. Кроме того, более высокая стоимость по сравнению с региональными функциями может быть существенной для проектов с большим объёмом трафика. Некоторые разработчики отмечают, что для сложных сценариев обработки запросов на границе сети более гибким решением может быть использование CloudFront Functions, который является более лёгким и быстрым сервисом, но с ещё более жёсткими ограничениями.

Источники

1. Документация Amazon Web Services: «Customizing at the edge with Lambda@Edge».
2. Документация Amazon Web Services: «CloudFront Functions vs. Lambda@Edge».
3. Whitepaper AWS: «Serverless Architectures with AWS Lambda».
4. Блог Amazon Web Services: «Announcing Lambda@Edge: Run Code Globally at the Edge».