Um aplicativo de e-commerce usa Amazon API Gateway e uma função AWS Lambda, armazenando dados em um banco de dados Amazon Aurora PostgreSQL. Durante um evento de vendas, um aumento repentino de pedidos causou timeouts. O arquiteto de soluções encontrou alto uso de CPU e memória no banco de dados devido a muitas conexões abertas. Para evitar erros de timeout com a menor alteração no aplicativo, qual solução o arquiteto deve implementar?

A resposta correta é usar o Amazon RDS Proxy. O RDS Proxy gerencia pools de conexões de banco de dados e reutiliza conexões existentes, reduzindo a sobrecarga de CPU e memória causada pela abertura e fechamento de muitas conexões. Isso é ideal para cargas de trabalho como AWS Lambda, que podem escalar rapidamente e gerar muitas conexões de curta duração. A modificação necessária no aplicativo é mínima: apenas atualizar o endpoint do banco de dados na função Lambda para apontar para o RDS Proxy. Configurar simultaneidade provisionada para o Lambda não resolve o problema de conexões do banco de dados. Um banco de dados global não aborda o problema de alto uso de CPU e memória devido a muitas conexões abertas, apenas melhora a resiliência e a latência em várias regiões. Criar uma réplica de leitura não resolve o problema de conexões de escrita e requer mudanças significativas na lógica de roteamento. Migrar para o DynamoDB é uma mudança arquitetônica drástica que vai além da "menor alteração no aplicativo".