Amazon DVA-C02: Amazon API Gateway e Integração de Aplicações — Guia de estudos
Faz parte do AWS Developer Associate DVA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.
Projetando APIs com o API Gateway (REST, HTTP, WebSocket) e integrações
O projeto começa com a escolha do tipo de API correto: as REST APIs (API Gateway REST) oferecem recursos refinados no nível do stage, como cache por stage e templates de mapeamento sofisticados; as HTTP APIs (API Gateway v2) proporcionam menor latência e menor custo para padrões de proxy comuns e autorizadores JWT/OIDC nativos; as WebSocket APIs fornecem canais persistentes cliente-servidor com chaves de rota ($connect, $disconnect, $default) e exigem a API Gateway Management API (PostToConnection) para enviar mensagens. Arquitete as integrações preferindo o proxy AWS_PROXY/Lambda para requisição/resposta simples (use aws apigateway put-integration --type AWS_PROXY ou, para a v2, use CreateIntegration no ApiGatewayV2Client), e escolha HTTP ou VPC Link para backends HTTP privados. Para backends de alta vazão (high-throughput), use NLB + VPC Link. Integrações mock (simuladas) (put-integration --type MOCK) e templates de resposta de integração permitem que as equipes de frontend comecem sem que o backend esteja pronto. Ao usar o CloudFront na frente das APIs, use endpoints de API regionais como origens e defina a Origin Protocol Policy como HTTPS-only; as REST APIs otimizadas para a borda (edge-optimized) já estão atrás do CloudFront. Armadilhas comuns incluem versões de formato de payload incompatíveis entre a API e o Lambda (v1.0 vs 2.0), esquecer de conceder permissão para apigateway.amazonaws.com invocar o Lambda (adicione a permissão com aws lambda add-permission --principal apigateway.amazonaws.com) e configurações incorretas de CORS que bloqueiam os navegadores.
Padrões de Segurança e Autorização (Cognito, IAM, autorizadores customizados)
Os padrões de segurança devem corresponder aos tipos de cliente e modelos de acesso: use Amazon Cognito User Pools ou um provedor OIDC externo e conecte-os como autorizadores JWT para HTTP APIs (CreateAuthorizer no apigatewayv2 com identitySource definido como $request.header.Authorization), ou use autorizadores Cognito de REST API para acesso de usuário baseado em sessão. Para APIs de serviço para serviço ou de administração, prefira a autorização do IAM (SigV4) e políticas de recurso do IAM com escopo restrito nos stages e métodos. Autorizadores Lambda (customizados) oferecem flexibilidade máxima para implementar regras de autenticação personalizadas, mas lembre-se que eles adicionam latência e modos de falha — faça cache das respostas do autorizador com um TTL para reduzir cold starts e evite lançar erros que retornam 500 para os clientes. Proteja contra abusos com planos de uso (usage plans) e chaves de API (aws apigateway create-usage-plan e create-api-key) combinados com cotas de throttling (limitação). Garanta as permissões corretas do IAM: conceda permissão ao API Gateway para invocar o Lambda (aws lambda add-permission) e restrinja as execution roles do Lambda ao privilégio mínimo. Pegadinhas para desenvolvedores incluem esquecer de habilitar a extração de token para autorizadores JWT, timeouts do autorizador impactando a latência geral da API e o encaminhamento de cabeçalhos/cookies pelo CloudFront, que pode inadvertidamente ignorar caches ou vazar dados do usuário.
Gerenciamento de Stages, Versionamento, Cache e Deployments Canary
Trate os stages como superfícies de execução independentes: os deployments são snapshots (instantâneos) (aws apigateway create-deployment ou apigatewayv2 create-deployment), e os stages mapeiam para esses snapshots. Use variáveis de stage ou, preferencialmente, aliases do Lambda para rotear o tráfego entre versões; troque os aliases atomicamente (UpdateAlias) ou use as configurações de canary do stage do API Gateway para um lançamento gradual (gradual rollout). Para REST APIs, habilite o cache no nível do stage (aws apigateway update-stage com patch-operations para definir cacheClusterEnabled e cacheClusterSize) e controle o TTL e os parâmetros da chave de cache nas configurações do método; as HTTP APIs atualmente não possuem cache embutido, então use o CloudFront ou caches no nível da aplicação. Invalide (evict) o cache no deploy ou quando os dados subjacentes mudarem; confiar apenas no TTL pode retornar dados obsoletos (stale). Padrões de versionamento: use o versionamento semântico de API no caminho (/v1/…) ou confie em deployments por stage para fluxos blue/green. Armadilhas comuns incluem assumir que as variáveis de stage são seguras (elas são visíveis para desenvolvedores com acesso ao console), configurar incorretamente as chaves de cache (esquecendo de incluir o cabeçalho de autorização ou parâmetros de consulta) e não coordenar o deploy de mudanças de schema com a compatibilidade do cliente.
Desempenho, Observabilidade e Diagnóstico
Instrumente as APIs de ponta a ponta: habilite logs de execução e logs de acesso no API Gateway e produza JSON estruturado (variáveis $context) para o CloudWatch Logs; habilite o X-Ray no API Gateway e no Lambda (defina tracingEnabled na implantação/estágio ou use o SDK:
undefined
/
undefined
com
undefined
) para correlacionar os rastreamentos. Monitore as métricas do API Gateway (Latency, IntegrationLatency, 4XX/5XX, CacheHitCount) e as métricas do Lambda (Duration, Throttles, ConcurrentExecutions) no CloudWatch; use a matemática de métricas para identificar onde a latência se acumula. Para WebSocket, acompanhe a contagem de conexões e os picos de erros 5XX do API Gateway. As etapas de solução de problemas incluem comparar a IntegrationLatency com a Latency para ver se o backend ou o gateway adiciona sobrecarga, detalhar os segmentos do X-Ray em busca de cold starts ou ENIs de VPC e verificar os CloudWatch Logs em busca de erros de template de mapeamento. Use DLQs e destinos para falhas assíncronas do Lambda e defina concorrência reservada ou concorrência provisionada para funções críticas. Armadilhas para desenvolvedores: registrar PII sensíveis em rastreamentos (redija na origem ou desabilite a amostragem do X-Ray para esses fluxos), ausência de certificados de provedor para domínios personalizados (ACM regional vs. us-east-1 para edge) e depender da limitação de taxa (throttling) padrão da conta sem planos de uso para APIs públicas.
Problema Prático: Cenário de Caso de Uso
Cenário: A BrightCart executa um frontend de e-commerce regional em uma aplicação de página única (SPA) hospedada no S3/CloudFront e expõe uma API de checkout via API Gateway (API HTTP regional) que invoca funções Lambda em uma VPC e grava os pedidos no DynamoDB. O ambiente usa um pipeline de CI/CD que implanta versões do Lambda em aliases de produção e expõe /checkout em um estágio de produção.
Desafio: Após o lançamento recente de uma feature, a latência da API de produção aumentou e algumas solicitações de checkout retornam 502/504 intermitentemente; os desenvolvedores precisam de um mecanismo de rollback seguro e de diagnóstico imediato.
Abordagem Recomendada:
- Crie um rollback da implantação apontando o estágio da API de produção para a implantação anterior: use
undefined
e depois
undefined
.
2. Mude o tráfego com segurança usando aliases do Lambda: atualize o alias prod do Lambda para a versão anterior com
undefined
e verifique o comportamento. 3. Habilite e colete diagnósticos: habilite o rastreamento do X-Ray para a API e o Lambda (
undefined
e
undefined
) e ative logs de acesso detalhados (
undefined
,
undefined
) para o CloudWatch Logs.
4. Analise métricas e rastreamentos: compare a IntegrationLatency vs. Latency do API Gateway no CloudWatch, examine os segmentos do X-Ray para identificar cold-starts de ENI da VPC e verifique limitações (throttles) do Lambda ou escritas condicionais do DynamoDB; se a latência da ENI da VPC for a causa raiz, considere usar concorrência provisionada (
undefined
) ou migrar para o Lambda com otimizações de endpoint de VPC.
Justificativa: A reimplantação atômica de estágios e a troca de aliases do Lambda fornecem um rollback rápido e de baixo risco sem alterações no código. Habilitar o X-Ray e logs de acesso estruturados permite que os desenvolvedores identifiquem se o API Gateway, os cold starts do Lambda, a rede da VPC ou as chamadas downstream para o DynamoDB estão causando os erros, orientando a mitigação correta (concorrência provisionada, aumento de throughput ou correções de configuração).
← Serverless e AWS Lambda · Todos os domínios · Amazon DynamoDB e Design NoSQL →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →