Amazon DVA-C02: Amazon API Gateway и интеграция приложений — Руководство по подготовке

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Часть AWS Developer Associate DVA-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Проектирование API с помощью API Gateway (REST, HTTP, WebSocket) и интеграций

Проектирование начинается с выбора подходящего типа API: REST API (API Gateway REST) предоставляют детальные функции на уровне стадии, такие как кэширование для каждой стадии и сложные шаблоны сопоставления (mapping templates); HTTP API (API Gateway v2) обеспечивают меньшую задержку и более низкую стоимость для распространенных прокси-паттернов и имеют встроенные JWT/OIDC-авторизаторы; WebSocket API предоставляют постоянные клиент-серверные каналы с ключами маршрутизации ($connect, $disconnect, $default) и требуют использования API Gateway Management API (PostToConnection) для отправки сообщений. При проектировании интеграций отдавайте предпочтение AWS_PROXY/прокси-интеграции с Lambda для простых сценариев «запрос-ответ» (используйте

undefined

или для v2 вызов

undefined

) и выбирайте HTTP или VPC Link для приватных HTTP-бэкендов. Для бэкендов с высокой пропускной способностью используйте связку NLB + VPC Link. Mock-интеграции (

undefined

) и шаблоны ответов интеграции позволяют фронтенд-командам начинать работу, не дожидаясь готовности бэкенда. При использовании CloudFront перед API, используйте региональные эндпоинты API в качестве origin и устанавливайте Origin Protocol Policy в значение HTTPS-only; оптимизированные для периферии (edge-optimized) REST API уже работают через CloudFront. Распространенные ошибки включают несоответствие версий формата полезной нагрузки (payload) между API и Lambda (v1.0 против 2.0), отсутствие разрешения для apigateway.amazonaws.com на вызов Lambda (добавьте разрешение с помощью

undefined

) и неправильные настройки CORS, блокирующие запросы из браузеров.

Паттерны безопасности и авторизации (Cognito, IAM, пользовательские авторизаторы)

Паттерны безопасности должны соответствовать типам клиентов и моделям доступа: используйте пулы пользователей Amazon Cognito или внешнего OIDC-провайдера и настройте их как JWT-авторизаторы для HTTP API (вызов

undefined

с параметром identitySource, установленным в

undefined

), или используйте Cognito-авторизаторы для REST API для доступа пользователей на основе сессий. Для API, предназначенных для межсервисного взаимодействия или администрирования, предпочтительна IAM-авторизация (SigV4) и строго ограниченные ресурсные политики IAM на уровне стадий и методов. Lambda-авторизаторы (пользовательские) предлагают максимальную гибкость для реализации специализированных правил аутентификации, но помните, что они добавляют задержку и новые режимы отказа — кэшируйте ответы авторизатора с определенным TTL, чтобы уменьшить количество холодных стартов и избежать возврата ошибок 500 клиентам. Защищайтесь от злоупотреблений с помощью планов использования (usage plans) и ключей API (

undefined

) в сочетании с квотами для регулирования (throttling). Убедитесь в правильности IAM-разрешений: предоставьте API Gateway разрешение на вызов Lambda (

undefined

) и ограничьте роли выполнения Lambda принципом наименьших привилегий. Типичные ошибки разработчиков включают: забывают включить извлечение токена для JWT-авторизаторов, тайм-ауты авторизатора влияют на общую задержку API, а перенаправление заголовков/cookie через CloudFront может непреднамеренно приводить к обходу кэша или утечке пользовательских данных.

Управление стадиями, версионирование, кэширование и канареечные развертывания

Рассматривайте стадии как независимые среды выполнения: развертывания (deployments) — это снимки состояния (snapshots) (

undefined

или

undefined

), а стадии сопоставляются с этими снимками. Используйте переменные стадии или, что предпочтительнее, алиасы Lambda для маршрутизации трафика между версиями; переключайте алиасы атомарно (

undefined

) или используйте настройки канареечного развертывания на стадии API Gateway для постепенного выката. Для REST API включайте кэширование на уровне стадии (

undefined

с patch-операциями для установки cacheClusterEnabled и cacheClusterSize) и управляйте TTL и параметрами ключа кэширования в настройках метода; HTTP API в настоящее время не имеют встроенного кэширования, поэтому используйте CloudFront или кэши на уровне приложения. Очищайте кэш при развертывании или при изменении базовых данных; опора исключительно на TTL может привести к возврату устаревших данных. Паттерны версионирования: используйте семантическое версионирование API в пути (/v1/…) или полагайтесь на развертывания по стадиям для реализации схем blue/green. Распространенные ошибки включают предположение о безопасности переменных стадии (они видны разработчикам с доступом к консоли), неправильную настройку ключей кэширования (например, не включив заголовок авторизации или query-параметры) и отсутствие координации при развертывании изменений схемы с обеспечением совместимости клиентов.

Производительность, наблюдаемость и диагностика

Инструментируйте API от начала до конца: включите журналы выполнения (execution logs) и журналы доступа (access logs) в API Gateway и создавайте структурированные JSON-сообщения (с использованием переменных $context) в CloudWatch Logs; включите X-Ray для API Gateway и Lambda (установите tracingEnabled в развертывании/стадии или используйте SDK: PutFunctionConcurrency/UpdateFunctionConfiguration с TracingConfig) для корреляции трассировок. Отслеживайте метрики API Gateway (Latency, IntegrationLatency, 4XX/5XX, CacheHitCount) и метрики Lambda (Duration, Throttles, ConcurrentExecutions) в CloudWatch; используйте математику метрик (metric math), чтобы определить, где накапливается задержка. Для WebSocket отслеживайте количество соединений и всплески ошибок 5XX в API Gateway. Шаги по устранению неполадок включают сравнение IntegrationLatency с Latency, чтобы выяснить, создает ли бэкенд или шлюз дополнительные задержки, детальный анализ сегментов X-Ray для выявления холодных стартов или проблем с VPC ENI, и проверку CloudWatch Logs на наличие ошибок в шаблонах сопоставления (mapping templates). Используйте DLQ и destinations для обработки сбоев асинхронных Lambda-функций и настраивайте зарезервированный параллелизм (reserved concurrency) или подготовленный параллелизм (provisioned concurrency) для критически важных функций. Типичные ошибки разработчиков: логирование конфиденциальной личной информации (PII) в трассировки (редактируйте на источнике или отключайте сэмплирование X-Ray для таких потоков), отсутствие сертификатов от провайдера для пользовательских доменов (региональный ACM в сравнении с us-east-1 для edge-оптимизированных конечных точек) и использование стандартных ограничений (throttling) аккаунта без планов использования (usage plans) для публичных API.

Практическая задача: сценарий использования

Сценарий: BrightCart использует региональный фронтенд для электронной коммерции в виде одностраничного приложения (SPA), размещенного в S3/CloudFront, и предоставляет API для оформления заказов через API Gateway (региональный HTTP API), который вызывает Lambda-функции в VPC и записывает заказы в DynamoDB. В среде используется конвейер CI/CD, который развертывает версии Lambda в производственные псевдонимы (aliases) и предоставляет эндпоинт /checkout на производственной стадии (stage).

Проблема: после недавнего развертывания новой функциональности задержка производственного API увеличилась, и некоторые запросы на оформление заказа периодически возвращают ошибки 502/504; разработчикам необходим безопасный механизм отката и средства немедленной диагностики.

Рекомендуемый подход:

Выполните откат развертывания, перенаправив производственную стадию API на предыдущее развертывание: используйте aws apigatewayv2 create-deployment --api-id <api> --description "rollback", а затем aws apigatewayv2 update-stage --api-id <api> --stage-name prod --deployment-id <old-deploy-id>.
Безопасно переключите трафик с помощью псевдонимов Lambda: обновите производственный псевдоним prod для Lambda-функции до предыдущей версии с помощью aws lambda update-alias --function-name CheckoutFn --name prod --function-version <previous-version> и проверьте поведение.
Включите и соберите диагностические данные: включите трассировку X-Ray для API и Lambda (aws apigatewayv2 update-stage --tracing-enabled true и aws lambda update-function-configuration --function-name CheckoutFn --tracing-config Mode=Active) и включите подробные журналы доступа (с переменными $context.requestTime, $context.integrationErrorMessage) в CloudWatch Logs.
Проанализируйте метрики и трассировки: сравните IntegrationLatency и Latency для API Gateway в CloudWatch, изучите сегменты X-Ray, чтобы выявить холодные старты, связанные с VPC ENI, и проверьте наличие троттлинга Lambda или сбоев условных записей в DynamoDB; если основной причиной является задержка VPC ENI, рассмотрите возможность использования подготовленного параллелизма (aws lambda put-provisioned-concurrency-config) или переход на Lambda с оптимизациями для эндпоинтов VPC.

Обоснование: Атомарное переразвертывание стадии и переключение псевдонимов Lambda обеспечивают быстрый откат с низким риском без изменения кода. Включение X-Ray и структурированных журналов доступа позволяет разработчикам точно определить, вызваны ли ошибки API Gateway, холодными стартами Lambda, сетевыми проблемами в VPC или вызовами нижестоящего сервиса DynamoDB, что помогает выбрать правильный способ устранения проблемы (подготовленный параллелизм, увеличение пропускной способности или исправление конфигурации).

← Бессерверные вычисления и AWS Lambda · Все домены · Amazon DynamoDB и проектирование NoSQL →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →