Änderungsmanagement

In diesem Dokument werden bewährte Methoden für die Einführung von Änderungen an den Konfigurationen von AWS-Edge-Services wie CloudFront, Lambda@Edge und AWS WAF beschrieben. Diese Änderungen können das Aktualisieren des CloudFront-Funktionscodes, das Ändern der Laufzeit einer Lambda@Edge-Funktion, das Hinzufügen eines neuen Cache-Verhaltens in CloudFront, das Aktualisieren von WAF-Regeln oder das Aktivieren neuer CloudFront-Feature wie HTTP/3 beinhalten. Wenn Sie über relativ statische und einfache Konfigurationen verfügen und eine Benutzeroberfläche zur manuellen Verwaltung bevorzugen, können Sie sich auf die AWS-Konsole verlassen. Für komplexere Einrichtungen empfiehlt es sich jedoch, CI/CD-Pipelines zu nutzen, um Konfigurationsänderungen und Codeaktualisierungen kontrolliert bereitzustellen.

CI/CD-Pipelines verbessern die Veröffentlichungszyklen von Software, indem sie die Entwicklungsgeschwindigkeit erhöhen, eine höhere Codequalität liefern und menschliche Fehler durch Automatisierung reduzieren. AWS Edge-Services wie CloudFront und Edge-Funktionen können innerhalb einer CI/CD-Pipeline mithilfe von Infrastructure as Code (IaC) verwaltet werden. Edge-Ressourcen können über APIs (z. B. die API von CloudFront), die AWS CLI oder Abstraktionstools auf höherer Ebene wie CloudFormation, Terraform und das AWS Cloud Development Kit (CDK) bereitgestellt werden.

Das auf CloudFormation basierende CDK bietet die höchste Abstraktionsebene, indem es Ihnen die Bereitstellung von AWS-Ressourcen mithilfe einer Programmiersprache ermöglicht. Beispielsweise können die folgenden drei Zeilen JavaScript-Code einen S3-Bucket mit CloudFront als Ursprung bereitstellen:

Werfen Sie einen Blick in die CDK-Konstrukte-Bibliothek, um wiederverwendbare Konstrukte in Ihren CDK-Code einzubinden.

Für Ihre CI/CD-Pipeline benötigen Sie ein Repository wie AWS CodeCommit, um Ihren Code (CDK-Code, Edge-Funktionen) zu speichern, ein Tool wie AWS CodeDeploy, um Ihre Infrastruktur bereitzustellen, sowie ein Orchestrierungs-Tool wie AWS CodePipeline, um die Schritte der Pipeline zu verwalten. In diesem Blogbeitrag wird die Verwendung von AWS-Entwicklertools zur Implementierung einer CI/CD-Pipeline für CloudFront demonstriert. Sie können jedoch auch Ihre bevorzugten CI/CD-Tools verwenden. Berücksichtigen Sie beim Erstellen Ihrer CI/CD-Pipeline für AWS-Edge-Services die folgenden Einschränkungen:

• CloudFront, CloudFront-Funktionen und regionale AWS-WAF-WebACLs können von jeder AWS-Region aus bereitgestellt werden
• Lambda@Edge und WAF WAF WebACLs für CloudFront können nur in der Region us-east-1 in Northern Virginia bereitgestellt werden.
• Die Firewall Manager-Richtlinien müssen im AWS-Konto des Firewall Manager-Administrators bereitgestellt werden.

Ihre Edge-Konfiguration kann auf verschiedenen Ebenen getestet werden. Zunächst können Sie Ihre Infrastruktur, z. B. eine CloudFront-Verteilung mit einer AWS WAF WebACL, in Testkonten replizieren. Dies kann während der Entwicklungsphase oder zur Durchführung automatisierter Funktionstests vor dem Übergang zur Produktion erfolgen. Beachten Sie, dass Sie nicht zwei CloudFront-Verteilungen mit demselben CNAME verwenden können. Folglich müssen Sie die CNAME-Konfiguration für Ihre CloudFront-Ressource basierend auf der CI/CD-Phase unterscheiden. Sie können beispielsweise den Domain-Namen von CloudFront (z. B. xyz.cloudfront.net) für die Entwicklungsphase verwenden, einen dedizierten CNAME für Staging (z. B. staging.www.example.com) und den öffentlichen CNAME für die Produktionsbereitstellung (z. B. www.example.com). Sie können Sicherheitskontrollen auch nach Phasen differenzieren, z. B. die Beschränkung des Zugriffs auf bestimmte IPs mithilfe von AWS WAF für die Staging-Phase.

Nachdem Ihre neue Konfiguration die Tests bestanden hat, können Sie mit dem Feature für kontinuierliche Bereitstellung von CloudFront einen Canary-Veröffentlichungsansatz implementieren, um die Änderung in der Produktion mit einem kleinen Teil Ihres Datenverkehrs zu testen. Mit diesem Feature können Sie eine andere Konfiguration für Ihre Produktionsverteilung erstellen und nur einen Teil Ihres globalen Datenverkehrs dorthin senden. Sie haben zwei Möglichkeiten, den Datenverkehr an die neue Konfiguration weiterzuleiten: die Verwendung eines bestimmten Anforderungsheaders (nützlich für synthetische Tests) oder die Verwendung einer gewichteten Richtlinie, um einen konfigurierbaren Prozentsatz des Datenverkehrs an die neue Konfiguration weiterzuleiten. Optional können Sie Stickiness aktivieren. In der aktuellen Version dieses Features können Sie Änderungen nur an einer Teilmenge der CloudFront-Konfigurationsparameter testen. Was genau Sie mit diesem Feature testen können, können Sie der Dokumentation entnehmen.

Stellen Sie sich ein Szenario vor, in dem mehrere Teams Änderungen an der CloudFront-Konfiguration vornehmen, aber ein einzelnes Team die CI/CD-Pipeline für alle Teams verwaltet. Beispielsweise können verschiedene Teams separate Microservices verwalten, die alle ihre APIs auf der Haupt-Domain bereitstellen, die von einer einzigen CloudFront-Verteilung gehostet wird. Wenn Sie jedem Team den Zugriff auf die gesamte Konfiguration der CloudFront-Verteilung gewähren, vergrößern Sie den Wirkungsradius einer einzigen schädlichen Änderung. Wenn Sie hingegen dem CI/CD-Team nur erlauben, Änderungen an der CloudFront-Verteilung vorzunehmen, verringern Sie die Entwicklungsgeschwindigkeit und führen einen Engpass in Ihrem Veröffentlichungslebenszyklus ein. Stattdessen können Sie die Konfiguration dynamisch basierend auf Teilkonfigurationen generieren, die jedem Microservice-Team gehören. In einer einfachen Implementierung kann jedes Team die Konfiguration seiner eigenen Route (Caching, Edge-Funktionen usw.) in einer textbasierten Datei verwalten, die in einem S3-Bucket gehostet wird. In Ihrer CI/CD-Pipeline können Sie einen zusätzlichen Schritt einführen, um die endgültige CloudFront-Konfiguration mithilfe der verschiedenen Teilkonfigurationsdateien dynamisch zu erstellen.

Shield- und WAF-Services können mit denselben Tools bereitgestellt werden, die zuvor in einer CI/CD-Pipeline beschrieben wurden.

Besser ist es jedoch, AWS Firewall Manager für die Bereitstellung von WAF-Regeln und Shield-Schutzmaßnahmen zu verwenden. Das hat folgende Vorteile:

• Es vereinfacht die Durchsetzung einer zentralen Sicherheits-Governance (z. B. die Bereitstellung zentraler Regeln in Kombination mit Regeln, die von Anwendungsteams verwaltet werden)
• Es bietet eine schnellere Bereitstellung, was für das Patchen kritischer Schwachstellen mithilfe von AWS WAF von entscheidender Bedeutung ist.
• Es vereinfacht die Bereitstellung über Konten und heterogene CI/CD-Pipelines hinweg (z. B. aus Übernahmen übernommen). Allerdings müssen Sie bei diesem Ansatz die Abweichung verwalten, wenn Sie eine CI/CD-Pipeline mit Abweichungserkennung verwenden.

Darüber hinaus können Sie eine CI/CD-Pipeline verwenden, um Änderungen an den Richtlinien des Firewall Managers im Administratorkonto vorzunehmen. die dann vom Firewall Manager in Ihrer gesamten AWS-Organisation bereitgestellt werden, wie von OLX demonstriert.

Das sichere Bereitstellen von WAF-Regeln in Ihrer Produktionsumgebung kann mithilfe verschiedener Strategien erfolgen. Sie können im Zählmodus einer vorhandenen WebACL neue Regeln hinzufügen und sie dann in den Blockmodus ändern. Bei diesem Ansatz müssen Sie jedoch auf die maximale WCU Ihrer WebACL achten. Ein anderer Ansatz besteht darin, Änderungen an einer Staging-WebACL bereitzustellen und die Änderungen in einer Staging-Umgebung zu testen.