Existe um problema clássico em arquiteturas serverless que nenhum tutorial menciona. Você constrói uma função elegante, ela escala automaticamente de zero para mil execuções simultâneas em segundos, os custos são ridiculamente baixos, e então, numa quinta-feira à tarde durante um pico de tráfego, o banco de dados começa a rejeitar conexões.
O erro no CloudWatch é direto: too many connections. O banco não quebrou, não ficou sem memória, não teve problema de disco. Ele simplesmente atingiu o limite máximo de conexões simultâneas, e cada nova invocação de Lambda tentando abrir a sua própria conexão foi rejeitada.
Esse é o problema que o Amazon RDS Proxy foi criado para resolver.
O RDS Proxy: Pool de Conexões Gerenciado como Serviço
O Amazon RDS Proxy atua como um intermediário entre o Lambda (ou qualquer cliente) e o banco de dados. Ele mantém um pool de conexões persistentes com o banco e multiplexar as conexões dos clientes sobre essas conexões do pool.
O fluxo fica assim:
Lambda (1.000 conexões simultâneas)
↓
RDS Proxy (pool de ~20 conexões com o banco)
↓
RDS / Aurora (vê apenas 20 conexões ativas)O Proxy usa uma técnica chamada connection multiplexing: enquanto uma transação não está ativa, a conexão do cliente pode ser reutilizada por outro cliente. Isso significa que mil Lambdas simultâneos podem operar sobre um pool de apenas algumas dezenas de conexões reais com o banco — desde que cada transação seja curta, o que é o comportamento típico em aplicações Lambda bem projetadas.
Números Reais: Antes e Depois
Para ilustrar o impacto, considere um cenário típico de API serverless com picos de tráfego:
Sem RDS Proxy:
- Concorrência Lambda: 500 execuções simultâneas
- Conexões abertas no PostgreSQL: até 500 (uma por execution environment ativo)
- Limite do
db.r6g.large(PostgreSQL): ~325 conexões antes de degradação - Resultado:
FATAL: remaining connection slots are reserved for non-replication superuser connections
Com RDS Proxy:
- Concorrência Lambda: 500 execuções simultâneas
- Conexões abertas no PostgreSQL: 15–30 (pool gerenciado pelo Proxy)
- Banco opera bem abaixo do limite
- Resultado: zero erros de conexão, latência média de conexão reduzida em 60–70% por eliminar o overhead de handshake TCP + TLS a cada invocação
Implementação: O Que Você Precisa Configurar
O RDS Proxy é configurado no console da AWS ou via Terraform/CloudFormation. Os pontos de atenção na implementação:
1. IAM Authentication obrigatória para Lambda
O RDS Proxy suporta autenticação via IAM Token, o que significa que o Lambda não precisa armazenar usuário e senha do banco em variáveis de ambiente. A autenticação acontece via token temporário gerado pelo IAM. Para isso, a execution role do Lambda precisa de permissão rds-db:connect no recurso do Proxy.
json
{
"Effect": "Allow",
"Action": "rds-db:connect",
"Resource": "arn:aws:rds-db:us-east-1:123456789:dbuser:prx-xxxxx/lambda_user"
}2. Endpoint correto na string de conexão
O Lambda deve se conectar ao endpoint do Proxy, não diretamente ao endpoint do RDS. O Proxy cria um endpoint próprio que substitui o endpoint original na configuração da aplicação.
3. Pinning: o inimigo silencioso do multiplexing
O Proxy pode entrar em modo pinning — onde uma conexão do pool fica dedicada a um único cliente e não pode ser reutilizada enquanto a sessão estiver ativa. Isso acontece quando a aplicação usa recursos de sessão que o Proxy não consegue multiplexar: variáveis de sessão (SET), cursores, prepared statements de longa duração.
Em Lambda, o pinning é raro se as transações forem atômicas e curtas. O CloudWatch do Proxy expõe a métrica DatabaseConnectionsCurrentlySessionPinned para monitorar esse comportamento.
Quando o RDS Proxy Vale a Pena (e Quando Não Vale)
O Proxy tem custo: você paga por vCPU do banco por hora. Para um db.r6g.large (2 vCPUs), o Proxy custa aproximadamente US$ 0,015/vCPU/hora, somando cerca de US$ 22/mês para essa instância.
Vale a pena quando:
- Você tem Lambda conectando diretamente a RDS ou Aurora PostgreSQL/MySQL.
- A concorrência do Lambda pode exceder o limite de conexões do banco.
- Você quer simplificar failover: o Proxy gerencia a reconexão automática ao novo primary durante um Multi-AZ failover, reduzindo o tempo de indisponibilidade percebido pelas aplicações.
- Você quer eliminar credenciais do banco no código usando IAM auth.
Não vale a pena quando:
- O banco já é Aurora Serverless v2 com escalabilidade de conexões integrada.
- A aplicação usa poucas conexões e está bem abaixo dos limites do banco.
- A latência adicional do Proxy (geralmente 1–2ms) é inaceitável para o caso de uso (streaming de dados de alta frequência, por exemplo).
Conclusão
O RDS Proxy não é uma otimização opcional para arquiteturas Lambda + RDS. Em qualquer workload com concorrência relevante, ele é a peça que torna a combinação viável em produção. Sem ele, você está construindo uma bomba-relógio: tudo funciona perfeitamente em desenvolvimento, o staging aguenta porque a concorrência é baixa, e o problema aparece exatamente quando você menos quer — num pico de tráfego real.
O custo de alguns dólares por mês para o Proxy é irrelevante frente ao custo de um banco indisponível por too many connections durante uma promoção ou evento crítico. E o bônus de poder usar IAM authentication no lugar de credenciais hardcoded já justificaria a adoção por si só.
