Amazon API Gateway: обзор, стоимость и подключение к Lambda

Что такое API Gateway?

API Gateway — это управляемый обратный прокси. Он принимает внешние запросы, маршрутизирует их к интеграциям (Lambda, HTTP-эндпоинты, другие AWS-сервисы), применяет авторизацию, трансформирует и кэширует ответы. Вместо того чтобы держать EC2-серверы, вы отдаёте инфраструктуру и масштабирование AWS.

Ключевые преимущества в двух строках:

• Отделение маршрутизации и публичного интерфейса API от реализации бэкенда.
• Платформа для единой политики безопасности, лимитирования, логирования и версионирования API.

API Gateway хорошо подходит для:

• Лёгких HTTP-API и REST API.
• Безсерверных архитектур с AWS Lambda.
• Управления схематикой и жизненным циклом REST API.

Он также поддерживает WebSocket API для двунаправленной связи в реальном времени.

Когда применять API Gateway и когда нет

Важно понимать случаи, когда Gateway помогает, и когда он может быть избыточен.

Когда применять:

• Нужно единообразно управлять публичными маршрутами, аутентификацией и лимитированием.
• Планируется интеграция с Lambda или другими AWS-сервисами.
• Требуется поддержка версий/стадий и кастомных доменов.

Когда не применять / альтернатива:

• Если у вас очень простой сервис и вы уже управляете NGINX/ALB с PaaS, возможно, проще оставить текущую инфраструктуру.
• Для высокопроизводительных потоковых API с большими payload стоит проверить прямые ALB/Network Load Balancer интеграции или специализированные прокси — Gateway может стать дороже при больших объёмах больших ответов.

Стоимость API Gateway — что важно знать

API Gateway имеет разные тарифы в зависимости от типа API:

• HTTP API: примерно $1 за 1 миллион запросов после бесплатного уровня 1M.
• REST API: примерно $3.50 за 1 миллион запросов (дорожe), плюс опциональные расходы на кэширование (оплата по часам в зависимости от размера узла).
• WebSocket API: ценообразование отличается — сообщение тарифицируется по пропуску и по времени соединения: низкая плата за сообщение, но есть плата за минуты соединения ($0.25 за 1 млн минут соединения). Объём полезной нагрузки ограничен (128 KB для WebSocket) и биллинг идёт по блокам.

Блоки передачи данных и учёт запросов:

• HTTP API: метеринг данных в блоках по 512 KB. Это значит, что ответ 1.5 MB будет считаться как 3 единицы по учёту трафика.
• WebSocket API: метеринг в блоках по 32 KB.

Эти округления могут значительно увеличить счёт, если у вас большие payloadы или часто передаёте мультимедиа.

Дополнительные расходы:

• Стоимость вызовов интеграционных сервисов (например, оплатите вызовы Lambda отдельно по тарифу Lambda).
• Стоимость исходящего трафика из AWS (data transfer out).
• ACM и Route 53 — обычно бесплатны для сертификатов в ACM (в пределах регионов/услуг), но есть правила и возможные затраты на DNS/публичные записи при использовании внешнего DNS.

Important: учитывайте метеринг блоков — это частая причина неочевидного роста расходов.

Факт-бокс: ключевые числа

• Бесплатный уровень: 1M запросов (зависит от условий AWS).
• HTTP API: ~ $1 / 1M запросов.
• REST API: ~ $3.50 / 1M запросов.
• WebSocket: плата за сообщения + $0.25 / 1M минут соединения.
• Блоки передачи: HTTP — 512 KB, WebSocket — 32 KB.

Настройка HTTP API и подключение к Lambda — шаг за шагом

HTTP API проще и дешевле, чем REST API. В большинстве простых безсерверных сценариев достаточно HTTP API.

1. В консоли API Gateway выберите «Create API» → «HTTP API».
2. Конфигурируйте интеграции: HTTP APIs поддерживают HTTP-эндпоинты и Lambda-функции. Добавьте интеграцию — для каждого логического маршрута можно указать отдельную Lambda.

3. Настройка маршрутов. Маршруты располагаются на под-URL, например:

/users

Маршрут может отличаться по HTTP-методу:

GET /messages

и

POST /messages

Метод GET возвращает список, POST — создаёт запись.

# Пример простого маршрута в конфигурации (псевдо-конфиг)
GET /messages -> интеграция : lambda:messages-list
POST /messages -> интеграция : lambda:messages-create

4. Создайте Stages (этапы развёртывания). Обычно нужно отделить разработку и продакшн. По умолчанию есть среда

$default

Она автоматом получает изменения. Создайте stage «Production» и развертывайте туда когда готовы.

5. После развёртывания найдите Invocation URL для выбранного Stage. Он статичен для конкретного API и обычно выглядит так:

https://api_id.execute-api.us-east-1.amazonaws.com

6. Кастомный домен: чтобы использовать собственное доменное имя, получите сертификат в ACM и свяжите домен с API Gateway, затем настройте DNS (в Route 53 это проще).

7. Авторизация: HTTP API поддерживает JWT (OpenID Connect / Cognito) как встроенный метод авторизации. Если требуется другая схема, рассмотрите использование Lambda Authorizer или внешнего провайдера.

Авторизация и безопасность

• HTTP API: нативная поддержка JWT — удобно для интеграции с Cognito или внешними OIDC провайдерами.
• Для контроля доступа можно использовать IAM-полисы, Lambda authorizer или API ключи (для простого контроля квот).
• Логирование: включайте request/response трассировку и CloudWatch Logs для отладки.

Рекомендации по безопасности:

• Всегда используйте HTTPS и, при необходимости, строгую проверку JWT (подпись, срок действия, audience).
• Ограничьте объём полезной нагрузки и используйте валидацию схемы, если это возможно.
• Включите rate limiting и throttling для защиты от DDoS-стиля пиков.

Контроль затрат и оптимизация

Практические приёмы:

• Используйте HTTP API вместо REST, если не нужны расширенные возможности REST и трансформации.
• Минимизируйте размер ответов: убирайте лишние поля, используйте сжатие на уровне интеграции.
• Внедрите кэширование на стороне клиента и CDN (CloudFront) перед Gateway для статического контента.
• Группируйте маршруты, чтобы не создавать лишние интеграции.
• Мониторьте CloudWatch метрики: Latency, Count, IntegrationLatency, 4XX/5XX.

Когнитивная эвристика: «Малые ответы + edge-кеширование = минимальные расходы при высоком трафике».

Модель принятия решения (Mermaid)

flowchart TD
  A[Требуется публичный API?] -->|Нет| B[Используйте существующую infra или ALB]
  A -->|Да| C[Нужна ли интеграция с Lambda?]
  C -->|Да| D[HTTP API—быстро и дёшево]
  C -->|Нет| E[REST API — если нужны сложные трансформации и схемы]
  D --> F{Есть требования к WebSocket?}
  F -->|Да| G[Используйте WebSocket API]
  F -->|Нет| H[Разворачивайте HTTP API]

Роли и контрольные списки (кто что делает)

Список задач для команды при внедрении:

• Архитектор:
  • Решает, какой тип API нужен (HTTP/REST/WebSocket).
  • Проектирует интеграции и потоки авторизации.
• DevOps/Инженер:
  • Настраивает API в консоли/CloudFormation.
  • Привязывает ACM-сертификат и настраивает DNS.
  • Настраивает мониторинг и алерты.
• Разработчик бэкенда:
  • Разрабатывает Lambda-функции.
  • Тестирует контракты и обработку ошибок.
• QA:
  • Проверяет авторизацию, лимиты, поведение при больших payload.

Критерии приёмки

• API доступен через Stage Production с корректным статическим Invocation URL.
• Авторы могут аутентифицироваться через настроенную JWT-схему.
• Примеры запросов GET/POST работают, возвращая ожидаемые коды HTTP и схемы ответов.
• Мониторинг и логирование включены, алерты настроены на 5XX spike.

Возможные проблемы и когда это не подойдёт

• Большие ответы: если большинство запросов возвращают >512 KB, учтите блоки биллинга. Для больших потоковых ответов проверьте прямые NLB/ALB или S3+CloudFront.
• Постоянные WebSocket-подключения с тысячами клиентов могут привести к затратам за минуты соединения.
• Если нужна сложная трансформация тела запроса/ответа на лету, REST API имеет больше инструментов, но и больше сложности и стоимости.

Сопутствующие рекомендации по миграции

• Миграция с REST → HTTP: протестируйте поведение авторизации и интеграций; HTTP API не поддерживает все расширенные фичи REST.
• Используйте IaC (CloudFormation, Terraform) для воспроизводимости конфигураций API Gateway и привязки сертификатов.

Краткая методология быстрого развёртывания (SOP)

1. Определите тип API (HTTP/REST/WebSocket).
2. Создайте интеграции (Lambda/HTTP).
3. Опишите маршруты и методы.
4. Разверните в $default и протестируйте.
5. Создайте Production stage и перенесите стабильную версию.
6. Настройте мониторинг и лимиты.
7. Подключите кастомный домен ивыдайте сертификат.

Глоссарий в одну строку

• Invocation URL — статичный базовый URL для вызова API в конкретном Stage.
• Stage — окружение развёртывания (напр., $default, Production).
• Integration — целевой сервис, обработчик запроса (Lambda, HTTP endpoint).
• JWT — JSON Web Token for stateless authentication.

Итог

API Gateway позволяет быстро и аккуратно выставлять API наружу, управлять доступом и интегрировать безсерверные функции. HTTP API — хорошее сочетание простоты и цены для большинства задач. Помните про биллинг по блокам и мониторьте метрики, чтобы не получить сюрпризов.

Краткое резюме и действие:

• Начните с HTTP API для новых безсерверных проектов.
• Контролируйте размер ответов и включайте кеширование/CloudFront.
• Настройте JWT или Lambda authorizer и включите логирование.

Сообщение для команды (коротко): разверните HTTP API, подключите функции Lambda, протестируйте в $default, затем перенесите в Production и подключите кастомный домен через ACM.