Design der Patching-Lösung für mehrere AWS Konten und Regionen

Sie können die automatisierte Patching-Lösung so erweitern, dass sie Server unterstützt, die sich über mehrere AWS Konten und mehrere Regionen erstrecken. AWS Die erweiterte Lösung umfasst die Einrichtung der Patch-Automatisierungslösung in jedem AWS Konto über AWS CloudFormation StackSets ein Shared Services-Konto und die Konfiguration einer Ressourcendatensynchronisierung zwischen den Konten mit dem Shared Services-Konto.

Automatisierter Prozess

Das folgende Diagramm veranschaulicht die Architektur für dieses Szenario. Diese Architektur umfasst AWS CloudFormation StackSets ein AWS gemeinsames Dienstkonto.

Der Arbeitsablauf ähnelt dem im vorherigen Abschnitt beschriebenen Prozess, umfasst jedoch die folgenden zusätzlichen Schritte, wobei die Schrittnummern den Beschriftungen im Diagramm entsprechen:

1. Im Shared Services-Konto wird ein AWS CloudFormation Stack-Set verwendet, um den S3-Bucket für die Ressourcendatensynchronisierung über Systems Manager Inventory zu konfigurieren.

2. Das CloudFormation Stack-Set erstellt den Stack mit der automate-patch Lambda-Funktion, richtet die Patch-Baselines ein und richtet die Systems Manager Manager-Inventarressourcendatensynchronisierung auf den Anwendungskonten ein, um Ressourcen im Shared Services-Konto zu synchronisieren.

3. Die Ressourceninformationen in den Anwendungskonten werden mit den Ressourceninformationen im Shared Services-Konto synchronisiert.

4. QuickSight generiert Patch-Compliance-Berichte unter Verwendung des Amazon Athena Athena-Datensatzes für die synchronisierten Ressourceninformationen.

Architektonische Überlegungen und Einschränkungen

Kontingente pro Konto im Wartungsfenster

Die im vorherigen Abschnitt dargestellte und beschriebene Architektur erstellt für jede Patchgruppe ein Wartungsfenster. Das Kontingent für die Anzahl der Wartungsfenster pro AWS Konto beträgt jedoch 50 (vorausgesetzt, Sie haben keine Erhöhung der Servicequote beantragt). Wenn Sie davon ausgehen, dass die Anzahl der Patchgruppen 50 Gruppen in einem einzigen AWS Konto überschreiten wird, lässt sich diese Architektur nicht Ihren Anforderungen entsprechend skalieren.

Wenn eine Erhöhung der Servicequote für Ihre Anforderungen nicht ausreicht, gibt es zwei Möglichkeiten, diese Herausforderung zu bewältigen: die Verwendung vordefinierter Wartungsfenster und die Verwendung von CloudWatch Ereignissen. Hier sind die Vor- und Nachteile der einzelnen Ansätze.

Option 1. Verwenden Sie vordefinierte Wartungsfenster

• Definieren Sie eine Liste von Wartungsfenstern mit unterschiedlichen Zeitfenstern (z. B. 15 bis 20 Wartungsfenster pro Konto).

• Die Anwendungsteams wählen aus der vordefinierten Liste die für sie passenden Wartungsfenster aus und kennzeichnen die Instanzen entsprechend.

• Aktualisieren Sie die automatisierte Patching-Lösung so, dass sie die Patchgruppen den ausgewählten Wartungsfenstern zuordnet, anstatt neue Wartungsfenster zu erstellen.

Vorteile:

• Vereinfachtes Management.

Nachteile:

• Weniger Flexibilität bei der Definition benutzerdefinierter Wartungsfenster.

• Wenn sich mehrere Patchgruppen Wartungsfenster und Patchtasks teilen, erfordert das Abbrechen einer bestimmten Patch-Aufgabe für eine bestimmte Patchgruppe zusätzlichen manuellen Aufwand.

Option 2. Verwenden Sie CloudWatch Ereignisse, um Patch-Aufgaben auszulösen, anstatt Wartungsfenster zu verwenden

• Anstatt Wartungsfenster zu erstellen, verwenden Sie CloudWatch Ereignisse, um Patch-Aufgaben auf der Grundlage des Zeitplans und der Patchgruppen auszulösen.

• In diesem Szenario ist jede Patchgruppe einem Ereignis mit CloudWatch Ereignissen und nicht mit einem Wartungsfenster verknüpft.

• Aktualisieren Sie die automatisierte Patching-Lösung, sodass Ereignisse statt Wartungsfenster erstellt werden.

Vorteile:

• Skalierbares Design.

• Bietet Flexibilität bei der Definition benutzerdefinierter Wartungsfenster.

Nachteile:

• Wartungsfenster bieten zusätzliche Funktionen (wie Dauer und Annahmeschluss), die bei CloudWatch Events nicht verfügbar sind.

Weitere Überlegungen

• Die in diesem Abschnitt beschriebene automatisierte Patching-Lösung unterstützt keine EC2 heruntergefahrenen Instanzen.

• Dieser Prozess unterstützt EC2 Instanzen in öffentlichen Subnetzen. Um Instanzen in privaten Subnetzen zu patchen, müssen Sie ein lokales Patch-Repository wie Windows Server Update Services (WSUS) bereitstellen.

• Sie müssen die Häufigkeit für die Ausführung der Lambda-Funktion anpassen, damit die Patchgruppen und Wartungsfenster gemäß Ihrem erforderlichen Zeitplan aktualisiert werden.