Uma empresa executa um aplicativo crítico onde o API Gateway expõe uma HTTP API integrada a uma função Lambda. O aplicativo armazena dados em uma instância RDS for MySQL (2 vCPUs, 64 GB RAM). Durante períodos de pico imprevisíveis, algumas chamadas de API retornam erros HTTP 500. Os logs do CloudWatch mostram “too many connections”. O banco de dados deve permanecer disponível, exceto durante a manutenção programada. Como a empresa pode tornar o aplicativo resiliente a picos de conexão?

A opção correta é usar o Amazon RDS Proxy. O RDS Proxy gerencia pools de conexões de banco de dados, reutilizando conexões existentes e reduzindo a sobrecarga de novas conexões. Isso é ideal para lidar com picos de conexão de aplicativos sem servidor, como funções Lambda, que podem abrir e fechar muitas conexões rapidamente. Ao direcionar as conexões da função Lambda para o proxy, o banco de dados RDS é protegido contra a exaustão de conexões, resolvendo os erros HTTP 500. Reduzir vCPUs e aumentar maxconnections pode piorar o desempenho e não resolve a causa raiz da exaustão de conexões. Alterar a classe da instância via CloudWatch é uma ação reativa e pode levar a tempo de inatividade e não resolve diretamente o problema de maxconnections. Usar o EventBridge para aumentar maxconnections baseado na CPU não é uma solução escalável ou recomendada, pois o limite de maxconnections é configurado para a capacidade da instância e não deve ser alterado dinamicamente dessa forma.