Was ist der Unterschied zwischen Security Groups und Network ACLs?

Dies ist eine klassische Cloud-Networking-Frage, und die Antwort hängt an einem Wort: zustandsbehaftet versus zustandslos. Kandidaten, die diese verwechseln, schreiben kaputte Regeln.

Security Groups — zustandsbehaftet, auf Instanzebene

Eine Security Group wird an eine Instanz oder Netzwerkschnittstelle angehängt und wirkt als zustandsbehaftete Firewall:

• Sie enthält nur Allow-Regeln (es gibt kein explizites Deny — alles, was nicht erlaubt ist, wird implizit verweigert).
• Weil sie zustandsbehaftet ist, wird, wenn du eine eingehende Anfrage erlaubst, der entsprechende Rückverkehr automatisch zugelassen. Du schreibst keine Regel für die Antwort.
• Dies ist die primäre, feingranulare Kontrolle — du grenzt sie auf konkrete Ports und Quell-Security-Groups oder CIDRs ein.

Network ACLs — zustandslos, auf Subnetzebene

Eine Network ACL sitzt an der Subnetzgrenze und ist zustandslos:

• Sie hat nummerierte, geordnete Regeln, die von niedrig nach hoch ausgewertet werden, und unterstützt sowohl Allow als auch Deny — nützlich, um einen bestimmten bösartigen IP-Bereich über ein ganzes Subnetz zu blockieren.
• Weil sie zustandslos ist, merkt sie sich keine Verbindungen. Wenn du eingehenden Verkehr erlaubst, musst du auch den ausgehenden Rückverkehr auf ephemeren Ports explizit erlauben (und umgekehrt). Dies zu vergessen ist der NACL-Bug Nummer eins.

Wie sie zusammenwirken

Verkehr zu einer Instanz muss beide passieren: die NACL des Subnetzes und die Security Group der Instanz. Sie werden zusammen ausgewertet, und ein Deny auf einer der Ebenen verwirft das Paket. In der Praxis nutzt du Security Groups für fast alles und reservierst NACLs für grobe Leitplanken auf Subnetzebene.

Worauf Interviewer achten

Die Unterscheidung zustandsbehaftet versus zustandslos klar formuliert, die Folge (Rückverkehrsregeln für NACLs), den Unterschied nur Allow versus Allow/Deny und dass beide Ebenen auf ein Paket wirken.