AWS Serverless: API Gateway, Lambda e uma lista de itens para verificar antes de ir para produção
Tags: ptbr, aws, lambda, serverless
Published: 2019-11-12 04:48:21

[_Créditos da Imagem_](https://unsplash.com/photos/RLw-UC03Gwc)

**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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) 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](https://serverlessrepo.aws.amazon.com/#!/applications/arn:aws:serverlessrepo:us-east-1:374852340823:applications~async-custom-metrics) 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](https://github.com/lumigo/SAR-cloudwatch-alarms-macro).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](https://medium.com/@oieduardorabelo/amazon-api-gateway-uma-falha-de-segurança-que-você-precisa-prestar-atenção-f52f522f0396). 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](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-sql-conditions.html).
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](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-method-request-validation.html) 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](https://github.com/middyjs/middy) possui [um validador embutido](https://github.com/middyjs/middy/blob/master/docs/middlewares.md#validator), 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](https://medium.com/@oieduardorabelo/aws-serverless-tudo-o-que-você-precisa-saber-sobre-cache-para-suas-aplicações-serverless-cd506e2ac17a). 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](https://read.acloud.guru/applying-the-decoupled-invocation-pattern-with-aws-lambda-2f5f7e78d18).

# 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](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0).
2. **Implemente disjuntores com fallbacks.** [O padrão de disjuntor](https://martinfowler.com/bliki/CircuitBreaker.html), 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](https://docs.pact.io) é 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](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/APIGateway.html#getExport-property) com o ID da API.

Gostou deste artigo? [Apoie-me no Patreon](https://www.patreon.com/bePatron?u=905909) 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](https://theburningmonk.com/2019/11/check-list-for-going-live-with-api-gateway-and-lambda/), escrito originalmente por [Yan Cui](https://twitter.com/theburningmonk).