Eine über CloudFormation bereitgestellte Anwendung verwendet API Gateway REST APIs, die in Lambda und DynamoDB integriert sind. Es gibt Entwicklungs-, Test- und Produktions-Stages, jede mit ihrer eigenen DynamoDB-Tabelle. Änderungen, die in die Produktion übernommen wurden, haben unerwartete Probleme verursacht, obwohl sie in der Entwicklung und im Test funktioniert haben. Für die nächste Version muss der Entwickler 20 % des Produktionsdatenverkehrs an die neue API-Bereitstellung und 80 % an die bestehende Produktionsbereitstellung leiten, um die Wahrscheinlichkeit zu minimieren, dass ein einzelner Kunde Fehler sieht. Was ist der beste Ansatz?

Die Konfiguration von Canary-Bereitstellungseinstellungen für die Produktions-API-Stage ist der beste Ansatz. API Gateway unterstützt Canary-Releases nativ, indem es einen Teil des Datenverkehrs an eine neue Bereitstellung leitet, während der Rest des Datenverkehrs an die bestehende Bereitstellung gesendet wird. Dies ermöglicht eine schrittweise Einführung neuer Funktionen in einer Produktionsumgebung und minimiert das Risiko für Endbenutzer. Die Option, Änderungen schrittweise bereitzustellen, ist ineffizient und manuell. Die Verwendung von Route 53 mit der Test-Stage ist problematisch, da die Test-Stage nicht für Produktionslasten ausgelegt ist und möglicherweise andere Konfigurationen als die Produktions-Stage aufweist. Ein Application Load Balancer vor API Gateway ist unnötig, da API Gateway bereits die erforderliche Traffic-Management-Funktionalität bietet.