Um aplicativo de e-commerce serverless usa o API Gateway para invocar funções Lambda baseadas em Java que se conectam a um banco de dados Amazon RDS for MySQL. Durante um pico de tráfego, o desempenho da API sofreu e as conexões com o banco de dados falharam. A empresa quer reduzir a latência do Lambda e suportar picos de tráfego com o mínimo de alterações. Qual solução atende aos requisitos com a menor modificação no aplicativo?

A opção correta aborda os problemas de conexão do banco de dados e de latência do Lambda. O RDS Proxy gerencia pools de conexão de banco de dados, reutilizando conexões existentes e reduzindo a sobrecarga de estabelecer novas conexões para cada invocação do Lambda, o que é crucial para lidar com picos de tráfego e reduzir a latência. Armazenar credenciais no Secrets Manager e configurar permissões IAM é uma prática de segurança recomendada. Aumentar a simultaneidade provisionada para as funções Lambda garante que um número pré-aquecido de instâncias do Lambda esteja sempre disponível, minimizando os tempos de inicialização a frio e melhorando a capacidade de resposta durante picos. Refatorar o código para abrir a conexão fora do manipulador ajuda, mas não resolve o problema fundamental de esgotamento de conexão do banco de dados em grande escala. Aumentar maxconnections no RDS pode mitigar o problema, mas não otimiza o uso da conexão nem resolve a latência do Lambda de forma tão eficaz quanto o RDS Proxy. A diferença entre "simultaneidade provisionada" e "simultaneidade reservada" é crucial: a provisionada pré-aquece as funções, enquanto a reservada apenas define um limite máximo.