Ein Unternehmen betreibt eine geschäftskritische Anwendung, bei der API Gateway eine HTTP-API bereitstellt, die in eine Lambda-Funktion integriert ist. Die Anwendung speichert Daten in einer RDS for MySQL-Instanz (2 vCPUs, 64 GB RAM). Während unvorhersehbarer Spitzenzeiten geben einige API-Aufrufe HTTP 500-Fehler zurück. CloudWatch Logs zeigen „too many connections“ an. Die Datenbank muss außer während geplanter Wartungsarbeiten verfügbar bleiben. Wie kann das Unternehmen die Anwendung gegen Verbindungsspitzen resistent machen?

Amazon RDS Proxy ist die effektivste Lösung, um die Anwendung gegen Verbindungsspitzen resistent zu machen. Er verwaltet und multiplexiert Datenbankverbindungen, wodurch die Anzahl der direkten Verbindungen zur RDS-Instanz reduziert wird. Dies verhindert "too many connections"-Fehler, insbesondere bei zustandslosen Funktionen wie Lambda, die viele kurzlebige Verbindungen öffnen können. Die Aktualisierung der Lambda-Funktion zur Verbindung mit dem Proxy ist notwendig, um diese Funktion zu nutzen. Das Reduzieren der vCPUs und Erhöhen von maxconnections ist keine nachhaltige Lösung, da eine geringere Rechenleistung die Datenbankleistung beeinträchtigen könnte und das Problem der Verbindungsmultiplexierung nicht löst. Ein CloudWatch-Alarm, der die DB-Instanzklasse ändert, ist zu reaktiv und würde zu Ausfallzeiten führen. Eine EventBridge-Regel, die maxconnections basierend auf der CPU-Auslastung erhöht, ist ebenfalls reaktiv und löst nicht das Problem der effizienten Verbindungshandhabung.