Créditos da Imagem

Isenção de responsabilidade: esta é uma lista longa, você não precisa marcar todos os itens antes de ir para produção. Pense neles como uma escada, quanto mais crítico for o sistema, mais alto você deve tentar subir.

Observabilidade

1. Ative o monitoramento detalhado para obter métricas por método (por exemplo, latência para GET /index). Sem isso, o CloudWatch relata apenas métricas agregadas para todos os seus pontos da API. O que é quase inútil... Não há como descobrir qual endpoint está passando por um tempo de resposta lento ou com alta taxa de erros.
2. Configure alarmes por método na latência da cauda. Use a métrica Latency ao invés da Integration Latency. Defina o alarme em p90, p95 ou p99, dependendo do seu requisito/SLA (service-level agreement).
3. Configure alarmes por método em altas taxas de erro. A contagem de erros é facilmente distorcida pela contagem de solicitações - um erro a 10.000 RPS não vale a pena ser acordado às 3h, mas pode ser um erro em cada 10 RPS. Use métricas computadas para calcular taxas de erro como 4xx count / request count e 5xx count / request count.
4. Configure alarmes por método em baixa taxa de sucesso. Semelhante ao acima, mas para a taxa de sucesso (ou seja, 200 count / request count).
5. Ative o rastreamento ativo do X-Ray. Isso permite ver rastreamentos no X-Ray quando as solicitações fluem pela API Gateway e Lambda. Se você investir tempo na instrumentação das funções do Lambda, isso ajudará você a identificar problemas de desempenho.
6. Adicione métricas personalizadas para métricas específicas do aplicativo. Para APIs, você deve registrar métricas personalizadas de forma assíncrona, publicando-as nos CloudWatch Logs primeiro (escrevendo em stdout). Isso evita adicionar latência extra à chamada do Lambda, e você não precisa se preocupar com o tratamento de erros e as tentativas novas (retries) quando o CloudWatch tiver um problema. Você pode usar este aplicativo SAR para analisar e encaminhar essas métricas personalizadas para o CloudWatch.
7. Verifique se você possui tags. Considere adicionar tags para EQUIPE, RECURSO, CENTRO DE CUSTOS etc. Isso ajuda no rastreamento de custos no faturamento da AWS.

Como você pode ver, você precisa configurar muitos alarmes! Para facilitar sua vida, criei uma macro no CloudFormation que pode gerar automaticamente os alarmes de latência e erros mencionados acima.Ele também suporta outros recursos, como Lambda, SQS e Step Functions.

Segurança

1. Revise a configuração de limitação de taxa padrão. A configuração padrão deixa você vulnerável a ataques de negação de serviço contra toda a região. Escolha um limite de taxa sensível para cada método.
2. Configure o WAF e ative a regra de limitação de taxa baseada em IP. Isso oferece proteção contra ataques de negação de serviço e pode ser ativado na camada do API Gateway ou CloudFront.
3. Configure o WAF e ative a regra SQLi. Esta regra WAF protege você contra ataques básicos de injeção SQL.
4. Você protegeu os endpoints com autenticação? A maioria dos endpoints em uma API deve ser autenticado. Para endpoints de API voltados para o usuário, considere o uso de Cognito User Pools ou Custom Lambda Authorizer. Para APIs internas (a serem usadas por outros sistemas internos), considere usar o AWS_IAM. Para uma plataforma SASS que precise impor cota de uso por cliente, use API Key.
5. Ative a validação de requisições do API Gateway. Aproveite o recurso de validação de requisições do API Gateway para não pagar por solicitações inválidas.
6. Implementar validação de respostas. Semelhante ao acima, mas valide sua resposta. Isso evita a exfiltração de dados no caso de um invasor ser capaz de iniciar um ataque de injeção e manipular sua função na busca de dados que não devem ser retornados. Infelizmente, o API Gateway não possui validação de resposta integrada. Você precisaria implementar isso em sua função Lambda. Para Node.js, o middleware middy possui um validador embutido, que suporta validação de resposta.

Performance

1. Como regra geral, armazene em cache o máximo que puder. Você pode implementar o cache em diferentes camadas, consulte este post para obter mais detalhes. Por padrão, tente armazenar em cache na borda com o CloudFront sempre que possível.
2. Verifique se o Lambda tem um tempo limite curto. O API Gateway tem um tempo limite máximo de integração de 29s, portanto, o tempo limite do Lambda deve ser menor que isso. Para APIs voltadas para o usuário, o tempo limite do Lambda deve ser inferior a 3 segundos. Se sua API precisar executar tarefas de longa execução, considere adotar o padrão de chamada desacoplado.

Resiliência

1. Configure múltiplas regiões, ativo-ativo. Para se proteger contra falhas em toda a região na AWS, considere optar por uma configuração ativo-ativo de várias regiões. Dê uma olhada neste post para obter mais detalhes.
2. Implemente disjuntores com fallbacks. O padrão de disjuntor, protege você contra problemas como novas tempestades. E quando combinado com fallbacks, protege você contra falhas em cascata, nas quais um serviço com falha pode derrubar todos os seus sistemas upstream.

Testando

1. Teste a API de ponta a ponta. Não pare de testar as funções localmente com mocks e stubs. Você deve testar a API de ponta a ponta falando com ela por meio de sua interface HTTP e garantir que tudo funcione realmente, incluindo configurações de permissões e validação de solicitação.
2. Considere adotar testes orientados a contratos de usuários. Isso é realmente útil em uma organização grande, onde as equipes geralmente dependem das APIs de outras equipes. Os testes orientados ao usuário ajuda a impedir que uma equipe libere acidentalmente alterações no contrato (que podem ser comportamentais) que quebram um sistema upstream. Pact é um framework robusto para implementação de testes orientados a contratos de usuários.
3. Execute testes de carga em jornadas reais de usuários. Embora o API Gateway e o Lambda sejam escaláveis, você ainda precisa garantir que entende o comportamento de dimensionamento de todo o sistema. Esses testes também testam seus sistemas downstream (bancos de dados, filas, outras APIs etc.) para destacar onde estão os gargalos de escala.

Documentação

1. Publique a especificação Swagger/API. Isso ajuda a compartilhar informações sobre seu serviço e pode ser feito como parte do seu processo de integração contínua. Para fazer isso, você pode chamar getExport com o ID da API.

Gostou deste artigo? Apoie-me no Patreon e obtenha ajuda direta por meio de um canal privado no Slack ou por 1-2-1.

Créditos

• Check-list for going live with API Gateway and Lambda, escrito originalmente por Yan Cui.