Ein SysOps-Administrator startet eine öffentliche Website auf einer EC2-Instance, die in einem bestehenden öffentlichen Subnetz platziert ist, und weist eine Elastic IP zu. Der Administrator hat dann eine Sicherheitsgruppe angehängt, die eingehenden HTTP-Verkehr (Port 80) von 0.0.0.0/0 erlaubt. Eine neue Netzwerk-ACL wurde erstellt und auf das Subnetz angewendet, die eingehenden HTTP-Verkehr von 0.0.0.0/0 erlaubt. Trotz dieser Änderungen ist die Website immer noch nicht über das Internet erreichbar. Was ist der wahrscheinlichste Grund?

Netzwerk-ACLs sind zustandslos, was bedeutet, dass sie sowohl für eingehenden als auch für ausgehenden Datenverkehr explizite Regeln benötigen. Obwohl eine Regel für eingehenden HTTP-Verkehr (Port 80) vorhanden ist, fehlt eine entsprechende ausgehende Regel, um den Rückverkehr über ephemere Ports (z.B. 1024-65535) zu ermöglichen. Ohne diese ausgehende Regel kann die EC2-Instanz die Antworten auf die HTTP-Anfragen nicht an den Client zurücksenden, wodurch die Website nicht erreichbar ist. Sicherheitsgruppen sind zustandsbehaftet und erlauben ausgehenden Rückverkehr automatisch, wenn eingehender Verkehr erlaubt ist, daher ist die fehlende ausgehende Regel in der Sicherheitsgruppe unwahrscheinlich. Eine neu zugewiesene Elastic IP würde einen sofortigen Verbindungsverlust verursachen, nicht nur das Fehlen einer Website. Eine blockierende Regel in einer anderen Netzwerk-ACL ist irrelevant, da nur eine Netzwerk-ACL pro Subnetz aktiv ist.