Sophos Firewall auf AWS bereitstellen und betreiben

Sophos Firewall 22 läuft in AWS als virtuelle EC2-Appliance inline in einer VPC. Für ein belastbares Design muss zuerst feststehen, welcher Verkehr durch die Firewall laufen soll. Eine Standalone-Firewall kann eingehenden und ausgehenden Verkehr prüfen. Das Sophos-Auto-Scaling-Template ist dagegen ein spezialisiertes PAYG-Design für eingehenden DNAT- oder WAF-Traffic.

Der sichere Kurzablauf lautet: Architektur und Lizenz wählen, IP- und Routingplan festhalten, das passende Marketplace-Template starten, Managementzugriff auf eine feste Quell-IP begrenzen, einen einzelnen Testfluss Ende zu Ende prüfen und erst danach weitere Dienste freigeben.

⚠️ AWS Security Groups bleiben eine zweite Firewall-Ebene. Eine erlaubende SFOS-Regel reicht nicht, wenn Security Group, NACL oder Route Table den Pfad blockiert. Umgekehrt darf ein offener AWS-Port nicht durch eine breite Sophos-Regel ergänzt werden. Security Groups sind zustandsbehaftet, Network ACLs nicht; bei einer benutzerdefinierten NACL müssen deshalb Hin- und Rückrichtung passen.

Standalone oder Auto Scaling wählen

AWS unterstützt für Sophos Firewall kein natives Appliance-HA. Auto Scaling und Network Load Balancing sind ein eigenes Cloud-Design und kein Ersatz für die SFOS-HA-Synchronisation. Wer eine einzelne Firewall einsetzt, plant daher auch den Wiederaufbau und die mögliche Unterbrechung bei Wartung oder Ausfall ein.

Für die Instanzwahl gelten drei Prüfungen: Der EC2-Typ muss im geöffneten Marketplace-CloudFormation-Template für die gewählte Region und AMI angeboten werden. CPU, RAM und Netzwerkleistung müssen zum Durchsatz und Verbindungsprofil passen. Bei BYOL müssen CPU-Berechtigung und die für genau diese Lizenz geltenden Bedingungen bestätigt sein.

Die SFOS-22/23-Zuordnung nennt beispielsweise m5.large mit 2 vCPU und 8 GB RAM für SFv2C4 sowie m5.xlarge mit 4 vCPU und 16 GB RAM für SFv4C6. Das sind versions- und angebotsgebundene Zuordnungsbeispiele, keine Zusage für jedes aktuelle Template. Der historische RAM-Suffix der Lizenz ist deshalb keine belastbare Obergrenze für den physischen EC2-RAM; daraus folgt aber ebenso wenig eine pauschale Zusage unbegrenzter RAM-Berechtigung. Vor dem Kauf die konkrete Lizenz-/Angebotsberechtigung mit Sophos beziehungsweise dem Lizenzpartner klären und dokumentieren; bei Unklarheit nicht produktiv bereitstellen.

Eine angebotene Grösse mit Lastreserve wählen und EC2-Typ, AMI/SFOS-Version sowie die bestätigten Lizenzbedingungen im Bauplan festhalten.

Bei PAYG endet die Softwareabrechnung erst, wenn alle betreffenden Firewall-Instanzen entfernt sind; separat verbleibende AWS-Ressourcen können weiter Kosten verursachen.

Fehlt der geplante Typ im Template oder weist CloudFormation die Kombination aus Region, AMI und Grösse zurück, darf sie nicht mit einem manuellen Template-Override erzwungen werden. Einen angebotenen Typ wählen, der Lastprofil und Lizenz erfüllt, oder das Deployment stoppen, bis Region, Angebot oder Lizenz geklärt sind.

Lizenz und Pilot vor dem Kauf klären

Ist PAYG im eigenen Land oder Angebot nicht verfügbar, kommt Standalone-BYOL mit bestätigter Lizenz infrage; das PAYG-only-Auto-Scaling-Template ist dadurch nicht mit BYOL nutzbar. Über Sophos oder einen Partner kann auch ein Private Offer mit individuell vereinbarten Preisen und Bedingungen geprüft werden. BYOL vermeidet die Marketplace-Softwaregebühr, nicht die EC2- und Infrastrukturkosten.

Für einen Pilot die tatsächliche Trial-Berechtigung, Dauer und Bedingungen des ausgewählten Angebots prüfen. Die historische AWS-FAQ beschreibt 30 Tage PAYG-Softwaretrial; dies ist keine Garantie für das heute gewählte Angebot. Nach dessen Trial-Ende wird weitere PAYG-Softwarenutzung automatisch kostenpflichtig. EC2, Speicher, Netzwerk und andere Infrastruktur können bereits während des Trials kostenpflichtig sein. Enddatum, Kostenverantwortlichen, Budgetalarm und eine Entscheidung zum Weiterbetrieb oder rechtzeitigen Rückbau festhalten. Bei BYOL eine angebotene Trial-Aktivierung bei der Ersteinrichtung oder eine vorab genehmigte Trial-Lizenz verwenden; Registrierung allein ist keine Lizenzzusage.

Eine produktive UTM-Lizenz kann nur über den vorgesehenen, berechtigungsabhängigen Konversionsprozess auf Sophos Firewall umgestellt werden. Die Übertragung einer vorhandenen Firewall-Lizenz ist ebenfalls nur in zugelassenen Szenarien möglich, nicht durch beliebige Wiederverwendung desselben Keys. Beides vor dem BYOL-Start mit dem Lizenzpartner bestätigen. Lizenz-Key aktivieren beschreibt anschliessend die Aktivierung.

Im Shared-Responsibility-Modell bleiben Anwendungen, Daten, Konfiguration und Wartung in der eigenen Verantwortung. IPS, Webfilter und WAF ergänzen SG/NACL nur auf dem tatsächlich kontrollierten Verkehrspfad. Synchronized Security setzt passende Endpoint-Lizenzen, Registrierung und Heartbeat-/Firewall-Policy voraus; es isoliert nicht automatisch jeden EC2-Querpfad, der die Kontrollen umgeht. Central-Anbindung erklärt die Verbindung zur zentralen Verwaltung.

Standalone-Deployment vorbereiten

Vor dem Start gehören diese Werte in einen kurzen Bauplan:

• AWS-Konto, Region, Availability Zone und BYOL- oder PAYG-Angebot;
• neue oder bestehende VPC sowie kollisionsfreie CIDRs für Public und Private Subnet;
• feste Admin-Quelladresse, beispielsweise 198.51.100.27/32, statt einer weltweiten Managementfreigabe;
• Elastic IP, DNS-Namen und benötigte eingehende Dienste;
• private Zielnetze, Default Route und erwarteter Rückweg für jeden Testfluss;
• unterstützter EC2-Typ, Lizenzgrenze, Kostenverantwortlicher und Tags;
• Backup-, Firmware- und Wiederaufbauverfahren.

198.51.100.27/32 ist eine Dokumentationsadresse und muss durch die tatsächliche öffentliche Adresse des Admin-Zugangs ersetzt werden. Ändert sich diese Adresse regelmässig, ist ein Managementzugang über VPN oder einen kontrollierten Jump Host sicherer als eine breite Freigabe von TCP 4444.

Bei einer bestehenden VPC dürfen Public und Private Subnet nicht nur anhand ihres Namens gewählt werden. Ihre Route Tables müssen zur geplanten Richtung passen. AWS beschreibt die Einbindung einer Netzwerk-Appliance und die dafür nötigen Routen in den Middlebox-Routing-Beispielen. Ausserdem muss der Source/Destination Check der Firewall-ENIs deaktiviert sein, weil die Appliance fremden Traffic weiterleitet. Das CloudFormation-Deployment soll diese Plattformdetails setzen; nach dem Aufbau werden sie kontrolliert und nicht blind geändert.

Standalone mit CloudFormation bereitstellen

1. Im AWS Marketplace das Sophos-Firewall-Angebot für BYOL oder PAYG öffnen, View purchase options wählen und die Bedingungen akzeptieren.
2. Unter Continue to Configuration die Fulfillment-Option, die aktuelle SFOS-Softwareversion und die gewünschte Region festlegen.
3. Unter Continue to Launch als Aktion Launch CloudFormation wählen und das Template in der AWS CloudFormation Console öffnen.
4. Einen eindeutigen Stack name vergeben. Bei einer neuen VPC die vorgeschlagenen Adressbereiche auf Überschneidungen mit bestehenden VPCs, VPNs und lokalen Netzen prüfen.
5. Bei einer bestehenden VPC die VPC-ID, genau ein vorhandenes Public Subnet, ein vorhandenes Private Subnet und eine neue oder freie vorhandene Elastic IP zuordnen. Den Parameter Network Address Prefix for new VPC dabei unverändert lassen.
6. Nur eine EC2-Grösse verwenden, die das geöffnete Template für Region und AMI anbietet, und sie bei BYOL nochmals gegen die im Bauplan festgehaltene Lizenzgrenze prüfen. Passwörter und andere Geheimnisse nicht in Tickets, Screenshots oder frei lesbaren Parameterdateien ablegen.
7. Die vom Template angeforderten IAM-Ressourcen prüfen. Erst danach I acknowledge that AWS CloudFormation might create IAM resources bestätigen und den Stack mit Submit starten.
8. Auf CREATE_COMPLETE warten. Unter Outputs die Elastic IP ablesen und in der EC2 Console zusätzlich beide Instanz-Statusprüfungen sowie die erwarteten ENIs kontrollieren.
9. WebAdmin aus der zuvor festgelegten Adminquelle über https://<EIP>:4444 öffnen. Die Warnung für das anfänglich lokal signierte Zertifikat nur nach Kontrolle der Ziel-IP übergehen, die Nutzungsbedingungen akzeptieren und Registrierung sowie Basiskonfiguration abschliessen. Danach unter Administration > Licensing prüfen, ob die erwartete Lizenz aktiv ist; bei einer Abweichung Instanzgrösse und Lizenzzuordnung korrigieren, bevor produktiver Traffic freigegeben wird.

Marketplace-Parameter können sich ändern; die sichtbaren Feldnamen deshalb vor jedem produktiven Rollout mit dem tatsächlich geöffneten Template abgleichen.

AWS- und SFOS-Regeln gemeinsam öffnen

Das Standalone-Sophos-Template aktiviert standardmässig nur Managementzugriff für WebAdmin und SSH. Diese Aussage gilt nicht pauschal für Auto Scaling: Dort steuert Public Network CIDR den Nicht-Management-Verkehr. IPsec, SSL VPN, RED, WAF, User Portal oder veröffentlichte Anwendungen benötigen zusätzlich passende AWS-Security-Group-Regeln. Für SD-RED 20/60 sind zur Firewall TCP 3400 für den Kontrollkanal und UDP 3410 für den Datentunnel zu berücksichtigen; die weiteren Anforderungen an Provisioning, DNS und NTP sowie andere RED-Varianten separat prüfen.

Für jede Freigabe werden Protokoll, Zielport und Quelle identisch dokumentiert, aber auf beiden Ebenen separat umgesetzt:

1. Die Security Group erlaubt nur die benötigte Quelle zum benötigten Port der richtigen ENI.
2. Eine benutzerdefinierte NACL erlaubt den Request und den dazugehörigen Rückverkehr. AWS erläutert den Unterschied in der Dokumentation zu Security Groups und Network ACLs.
3. Die Route Table führt den Datenpfad tatsächlich über die Firewall und besitzt einen gültigen Rückweg.
4. Die SFOS-Firewall- und gegebenenfalls NAT-Regel verwendet konkrete Zonen, Hosts und Services, ist geloggt und enthält die passenden Security-Profile.

SSH und WebAdmin werden niemals vorsorglich für 0.0.0.0/0 geöffnet. Auch ein enger AWS-Zugriff ersetzt keine saubere SFOS-Regel: So bleibt die beabsichtigte Policy verständlich, wenn später Security Groups oder Routen geändert werden.

Auto Scaling für Inbound-Traffic aufbauen

Für Auto Scaling sind ein AWS-Konto, das Marketplace-Angebot Sophos Cloud Firewall (PAYG) und ein Sophos-Fusion-Konto mit den erforderlichen Firewall-Verwaltungsrechten nötig. In Sophos Fusion (ehemals Sophos Central) unter My products > General settings > API credentials management die Bedingungen prüfen und eine Credential mit Name, Beschreibung und Rolle Service principal firewall erstellen. Client ID und Client secret in einem zugriffsbeschränkten Secret Store sichern, nicht in einem ungeschützten Textfile. Das Kontopasswort der Sophos ID ist ein anderes Geheimnis als der API-Client-Secret.

1. In der gewünschten AWS-Region unter EC2 > Network & security > Key pairs ein geeignetes Key Pair erstellen oder ein vorhandenes wiederverwenden. Den privaten Schlüssel sicher verwahren und den Namen für SSH KeyPair Name notieren.
2. Im Marketplace View purchase options und Continue to configuration öffnen. Sophos Auto Scaling Firewall for AWS als Fulfillment option, die freigegebene Software version und Region wählen. Unter Continue to launch die Aktion Launch CloudFormation wählen, Launch und in CloudFormation Next anklicken.
3. Einen eindeutigen Stack name vergeben. AMI ID mit dem gewählten Angebot und der Version abgleichen und unter Instance size eine angebotene, ausreichend leistungsfähige Grösse wählen. Unter AvailabilityZone 1 for deployment und AvailabilityZone 2 for deployment zwei verschiedene AZs auswählen.
4. Neue VPC: Unter Network Address Prefix for new VPC die ersten zwei Oktette eines kollisionsfreien geplanten Bereichs eintragen; die Felder für eine bestehende VPC leer lassen. Bestehende VPC: Den Prefix-Parameter unverändert lassen und Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 sowie Existing private subnet ID aus dem Bauplan eintragen. Die Public Subnets müssen zu den gewählten AZs gehören und Auto-assign public IPv4 address aktiviert haben. Routen und NACLs ebenfalls prüfen.
5. Den Firewall-Namen, Admin Password für WebAdmin/CLI, Secure Storage Master Key Password und SSH KeyPair Name setzen. Die beiden Firewall-Passwörter getrennt vom API-Secret schützen.
6. Die Sophos ID email address und Sophos ID password des vorgesehenen Kontos, Sophos Central client ID, Sophos Central client secret und Sophos Central AS Group name eintragen. Die Central-Feldnamen können trotz Fusion-Branding im Template stehen; die Gruppe wird im zugehörigen Konto automatisch erstellt. Keine Secrets in Tickets, Screenshots oder öffentliche Parameterdateien übernehmen.
7. Die folgenden Netzwerk-, Kapazitäts- und Logparameter setzen. Unter I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy nach Prüfung exakt yes eingeben; Gross-/Kleinschreibung beachten. Für Opt in to the customer experience improvement program bewusst eine Option wählen.
8. Mit Next die Stack-Optionen öffnen, Owner-/Kosten-Tags setzen und die angeforderten IAM-Rechte prüfen. Erst danach I acknowledge that AWS CloudFormation might create IAM resources bestätigen, die Gesamtübersicht prüfen und mit Submit starten.

Nach CREATE_COMPLETE die EC2-Instanzen und unter My products > Firewall management > Firewalls die automatisch erstellte Gruppe mit allen erwarteten freigegebenen PAYG-Workern prüfen. Policy-Synchronisation bestätigen, bevor ein Dienst exponiert wird. Fehlt ein Worker oder scheitert die Registrierung, keine weiteren Ports öffnen; Stack Events, Netzwerkzugang und Konto/API-Zuordnung prüfen, ohne Secrets zu protokollieren. Kapazität später unter EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit ändern und mit Update bestätigen. Instanz-ID, AZ und Firewall-Namen eindeutig dokumentieren; jede Kapazitätsänderung erneut gegen Gruppenmitgliedschaft und Target Health prüfen.

DNAT hinter dem Network Load Balancer

Voraussetzung ist ein funktionsfähiges, geprüftes Auto-Scaling-Deployment. Für einen genehmigten TCP-Dienst führt der NLB-Listener zu einer Target Group der Firewall-Worker, nicht direkt zum Backend. Das folgende ursprüngliche Schema zeigt einen HTTPS-Beispielpfad, keine gemessene Verbindung:

Erlaubter Client : kurzlebiger Quellport
                 | TCP Zielport 443
          NLB TCP-Listener :443
                 |
       Firewall-Worker-Target-Group
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT zum Backend :443
          SNAT = MASQ des Workers
                 |
          Interner App-Server :443
                 | Antwort
          Derselbe Worker -> NLB -> Client

Schema: zwei AZs, ein aktiver PortB pro Worker und ein MASQ-Rückweg. Die Pfeile beschreiben den logischen Datenpfad; Lastverteilung ist keine Garantie gleichmässiger Nutzung. Sämtliche Beispielwerte an den genehmigten Dienst anpassen.

1. In Fusion unter My products > Firewall management > Firewalls beim richtigen Auto-Scaling-Firewallverbund Manage policy öffnen. Unter Hosts and services > IP host zwei IPv4-IP-Ranges für die tatsächlichen WAN-Subnetze beider AZs und einen IPv4-Host für den internen Server erstellen. Die erste Adresse jedes Subnetzes nicht einschliessen; nur tatsächlich nutzbare Worker-Adressen erfassen, keine AWS-reservierten Adressen.
2. Unter Hosts and services > Services einen TCP/UDP-Service mit Protocol TCP erstellen. Für diesen eingehenden Verbindungsaufbau ist der kurzlebige Client-Port die Quelle und der veröffentlichte Dienstport das Ziel. Die folgende Richtung gilt für den Request, nicht für die Antwort; 3389 oder 8080 werden nicht zusätzlich geöffnet.

3. Die Firewallregel unter Rules and policies > Firewall rules und die NAT-Regel unter Rules and policies > NAT rules in der Gruppenpolicy speichern. Synchronisation auf jedem laufenden Worker prüfen.
4. Unter EC2 > Load balancing > Target groups > Create target group Instances, einen eindeutigen Namen, Protocol TCP, Port 443 und die Deployment-VPC wählen. Health-Check-Protokoll, -Port und gegebenenfalls -Pfad bewusst an den geprüften Dienst anpassen. Beim Erstellen unter Available instances keine Instanz manuell auswählen, insbesondere nicht den Backend-Server.
5. Unter EC2 > Auto scaling > Auto scaling groups die Firewall-ASG wählen und unter Integrations > Load balancing > Edit die Target Group anhängen; mit Update bestätigen. Die ASG registriert damit ihre Worker automatisch, auch später neu gestartete.
6. Vor dem Listener-Start unter Load balancers beim tatsächlichen Template-NLB die Security-Group-Zuordnung prüfen. Wurde der NLB ohne eine Security Group erstellt, lässt sich später keine hinzufügen. Dann keinen öffentlichen Listener freigeben, bis ein unterstützter, quellenbeschränkter Pfad freigegeben ist; alternativ VPN/ZTNA nutzen. Nicht blind das verwaltete Template umbauen oder einen späteren SG-Anhang versprechen.
7. Ist der restriktive Pfad vorhanden, im NLB unter Listeners > Add listener TCP und Port 443 mit der Worker-Target-Group als Default action konfigurieren. NLB-SG auf erlaubte Client-CIDRs und Listener-Port begrenzen; am Worker die vom NLB benötigten Ziel- und Health-Check-Ports getrennt erlauben. NLB-Egress muss die Health Checks erreichen können. Ein Health-Check-Zugriff ist keine öffentliche Anwendungsfreigabe. Direkten Zugriff auf Worker und Backend ebenfalls einschränken.
8. Vor Produktivnutzung kontrollieren, dass die erwarteten Worker beider AZs und ein im freigegebenen Änderungsfenster neu gestarteter Worker automatisch in der Target Group erscheinen und die vorgesehenen Health Checks bestehen. Über den NLB-DNS-Namen den positiven Anwendungsfluss und einen negativen Versuch aus einer unerlaubten Quelle prüfen; Log Viewer muss die erwartete Regel und DNAT/MASQ zeigen. Nicht nur auf healthy vertrauen.

Direktes öffentliches RDP bleibt keine Empfehlung; VPN oder ZTNA bevorzugen. Bleibt ein Target unhealthy, zuerst ASG-Zuordnung, synchronisierte Policy, Health-Check-Port/-Pfad, NLB-Egress, Worker-SG und NACL prüfen. Bei falschem Backend oder Rückweg den Listener geschlossen lassen und NAT/Service/Route korrigieren. Die Ports werden anhand der Request-Richtung im Client-Listener-Backend-Pfad zugeordnet.

Abnahme: einen Flow Schicht für Schicht prüfen

Für die erste Abnahme wird genau ein Flow notiert, etwa 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. Der Quellport ist nur ein Beispiel für einen kurzlebigen Client-Port. Geprüft wird in dieser Reihenfolge:

1. DNS und NLB-Listener zeigen auf das erwartete Ziel; die Target Group meldet die erwarteten Worker als healthy.
2. Security Groups und NACLs erlauben genau diesen Hin- und Rückweg.
3. Subnet Route Tables und ENIs führen den Traffic durch die Appliance; Source/Destination Check ist für die weiterleitenden Firewall-Interfaces deaktiviert.
4. Im SFOS Log Viewer erscheint die erwartete Firewall Rule ID. Bei DNAT stimmen Original- und übersetztes Ziel sowie der Rückweg.
5. Der erlaubte Test liefert die erwartete Anwendung, ein Test von einer nicht erlaubten Quelle bleibt blockiert.

Ist kein SFOS-Logeintrag vorhanden, liegt der Fehler meist vor der Firewall: DNS, Listener, Target Health, Security Group, NACL oder Route prüfen. Erscheint ein Drop mit unerwarteter Rule ID, zuerst Zonen, Netzobjekte, Service und Regelreihenfolge korrigieren. Funktioniert der Hinweg, aber keine Antwort kommt zurück, sind Route Table, NACL, Server-Default-Gateway und bei Auto Scaling die MASQ-Einstellung die nächsten Prüfpunkte.

Betrieb und Wiederherstellung

Standalone und Auto Scaling brauchen unterschiedliche Runbooks. Bei Standalone werden ein SFOS-Backup und eine geprüfte Wiederherstellung, der Firmwareprozess, CloudFormation-Parameter und ein Wiederaufbau-Test dokumentiert. Ein EC2-Snapshot ersetzt kein exportiertes SFOS-Backup.

Auto-Scaling-Worker sind kurzlebig. Wenn CloudWatch aktiviert wurde, liegen ihre Logs in Log Groups unter /sophos/xg/; Aufbewahrung, Verschlüsselung, Zugriff und Kosten müssen bewusst konfiguriert werden. Beendete EC2-Instanzen bleiben in der Fusion-Firewallgruppe sichtbar und müssen dort manuell entfernt werden. Ein Warm Pool synchronisiert gestoppte Instanzen in seinem Intervall, ersetzt aber nicht die Kontrolle, ob eine neue Gruppenpolicy auf allen laufenden Workern angekommen ist.

Zum Betriebsprotokoll gehören Owner- und Kosten-Tags, Budgetalarm, Lizenzstatus, Secret-Rotation, CloudWatch-Retention, Fusion-Bereinigung, Firmwarefreigabe, Änderungstest und Wiederherstellung. Nach jeder Template-, Routing- oder Policy-Änderung wird der definierte positive und negative Flow erneut geprüft. So belegt die Abnahme nicht nur, dass die Instanz läuft, sondern dass AWS und SFOS gemeinsam genau den vorgesehenen Verkehr zulassen.

Änderung stoppen und gezielt zurücknehmen

Vor der Änderung Stack-Parameter und Ressourcen-IDs, Listener/Target-Group-Zuordnung, SG/NACL/Route Tables sowie SFOS-Gruppenpolicy und Backup sichern. Bei falschem Ziel, unerwarteter Quelle, fehlender Policy-Synchronisation oder gestörter Bestandsverbindung zuerst den neu hinzugefügten Listener beziehungsweise die neue Exposition schliessen; danach nur die neu eingeführten Regeln und Routen auf den dokumentierten sicheren Stand zurücksetzen. Bestandsverkehr und blockierte unerlaubte Quellen erneut prüfen. Keine gemeinsam genutzte VPC, Subnetze, Gateway oder vorhandene Listener zur Fehlerbehebung löschen.

Zum geplanten PAYG-Rückbau reicht es nicht, einzelne Worker zu beenden: Die ASG kann sie neu erzeugen. Zuerst neue Exposition entfernen, die genehmigte Stilllegung über den Stack-/ASG-Lebenszyklus durchführen und prüfen, dass weder Scaling-Aktionen noch Warm-Pool-Instanzen Worker erneut starten. Alle zugehörigen PAYG-Firewall-Instanzen entfernen und den tatsächlichen Ressourcenbestand kontrollieren. Retained Volumes, EIPs, NLB, Log Groups und weitere kostenpflichtige Ressourcen anhand der Ressourcenliste einzeln bewerten, nicht pauschal löschen; beendete Worker aus der Fusion-Gruppe entfernen. Abrechnungs-/Kostenkontrolle anschliessend prüfen. Rückbau und Restore als getrennte Vorgänge planen und ihren Erfolg jeweils kontrollieren.