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

Главное изображение: концепция Amazon API Gateway

Что такое API Gateway?

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

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

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

API Gateway располагается перед другими сервисами и маршрутизирует запросы

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

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

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

Структура REST 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.

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

Добавьте интеграции для маршрутов, например Lambda-функции

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

/users

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

GET /messages

POST /messages

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

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

Добавьте маршруты и методы

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

$default

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

Настройка стадий/окружений для отделения разработки и продакшна

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

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

Кастомный домен: чтобы использовать собственное доменное имя, получите сертификат в ACM и свяжите домен с API Gateway, затем настройте DNS (в Route 53 это проще).
Авторизация: 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)

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

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

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.