Firma uruchamia krytyczną aplikację, w której API Gateway udostępnia HTTP API zintegrowane z funkcją Lambda. Aplikacja przechowuje dane w instancji RDS for MySQL (2 vCPU, 64 GB RAM). Podczas nieprzewidywalnych okresów szczytowych niektóre wywołania API zwracają błędy HTTP 500. CloudWatch Logs pokazują komunikat „too many connections”. Baza danych musi pozostać dostępna z wyjątkiem zaplanowanych prac konserwacyjnych. Jak firma może zwiększyć odporność aplikacji na skoki połączeń?

Amazon RDS Proxy jest najlepszym rozwiązaniem, ponieważ efektywnie zarządza pulą połączeń do bazy danych. W przypadku funkcji Lambda, które są bezstanowe i często tworzą nowe połączenia, RDS Proxy utrzymuje stałą pulę połączeń, redukując obciążenie bazy danych związane z nawiązywaniem i zamykaniem połączeń. Dzięki temu baza danych może obsłużyć więcej żądań, nawet podczas szczytowego ruchu, bez przekraczania limitu maxconnections i zwracania błędów HTTP 500. Zmniejszenie vCPU i zwiększenie maxconnections jest błędne, ponieważ zmniejszenie zasobów obliczeniowych (vCPU) pogorszy wydajność, a samo zwiększenie maxconnections nie rozwiąże problemu efektywnego zarządzania połączeniami przez bezstanowe funkcje Lambda. Tworzenie alarmu CloudWatch zmieniającego klasę instancji DB jest rozwiązaniem reaktywnym i nie zapobiega problemom z połączeniami, a także wiąże się z przestojami podczas zmiany rozmiaru instancji. Użycie reguły EventBridge do zwiększenia maxconnections jest również reaktywne i może nie być wystarczająco szybkie, aby zapobiec błędom podczas nagłych skoków ruchu, a także nie rozwiązuje problemu nadmiernego nawiązywania połączeń przez funkcje Lambda.