Un'azienda esegue un'applicazione critica in cui API Gateway espone un'API HTTP integrata con una funzione Lambda. L'applicazione memorizza i dati in un'istanza RDS for MySQL (2 vCPU, 64 GB RAM). Durante periodi di picco imprevedibili, alcune chiamate API restituiscono errori HTTP 500. I log di CloudWatch mostrano "troppe connessioni". Il database deve rimanere disponibile tranne che durante la manutenzione programmata. Come può l'azienda rendere l'applicazione resiliente ai picchi di connessione?

L'opzione corretta è utilizzare Amazon RDS Proxy. RDS Proxy gestisce in modo efficiente i pool di connessioni al database, riutilizzando le connessioni esistenti e riducendo il sovraccarico di stabilirne di nuove, il che è ideale per carichi di lavoro serverless come Lambda che possono aprire e chiudere molte connessioni rapidamente. Questo risolve direttamente l'errore "troppe connessioni" senza richiedere modifiche significative al codice dell'applicazione. Ridurre le vCPU e aumentare maxconnections non risolverebbe il problema di fondo del sovraccarico di connessioni e potrebbe peggiorare le prestazioni del database. La creazione di un allarme CloudWatch per modificare la classe dell'istanza DB è una soluzione reattiva e lenta che causerebbe tempi di inattività e non affronterebbe la gestione delle connessioni. L'utilizzo di una regola EventBridge per aumentare maxconnections in base all'utilizzo della CPU è una soluzione reattiva e non risolve il problema della gestione efficiente delle connessioni, inoltre, maxconnections ha un limite massimo e aumentarlo eccessivamente può sovraccaricare il database.