Eine monolithische REST-API für eine mobile App läuft auf fünf EC2-Instances in öffentlichen Subnetzen und wird von einem Route 53 Multivalue Answer Record vorgelagert, der direkt auf die IPs der Instances zeigt. Plötzliche große Verkehrsspitzen überfordern die App. Welche Lösung ermöglicht es der Anwendung, mit dem GERINGSTEN Betriebsaufwand auf die neue, variable Last zu skalieren?

Die Bereitstellung eines Application Load Balancers (ALB) ist die Lösung mit dem geringsten Betriebsaufwand, da er automatisch skaliert und die Last auf die EC2-Instances verteilt. Die Verschiebung der Instances in private Subnetze erhöht die Sicherheit, da sie nicht mehr direkt aus dem Internet erreichbar sind. Der Route 53-Eintrag wird aktualisiert, um auf den ALB zu zeigen, der als einziger Einstiegspunkt dient. Die Aufteilung der API in Lambda-Funktionen (Serverless) würde einen hohen Refactoring-Aufwand bedeuten. Die Containerisierung mit EKS erfordert die Verwaltung eines Kubernetes-Clusters, was komplexer ist als die ALB-Lösung. Eine Auto Scaling-Gruppe allein löst das Problem der direkten IP-Adressierung im Route 53 Multivalue Answer Record nicht effizient, da die manuelle Aktualisierung des Route 53-Eintrags bei Skalierungsereignissen umständlich ist und zu Inkonsistenzen führen kann.