Erklär mir, wie du eine VPC für einen Production-Workload designen würdest.

Nimm einen CIDR-Block, der groß genug zum Wachsen ist und sich nicht mit irgendetwas überschneidet, mit dem du später peeren könntest, und verteil ihn dann über mindestens drei Availability Zones. Public Subnets nur für Load Balancer und NAT, Private Subnets für Compute, und isolierte Subnets ganz ohne ausgehende Route für Datenbanken. Steuer den Traffic über Security Groups, die sich gegenseitig referenzieren statt über IP-Ranges, und schalt Flow Logs ab Tag eins ein.

Ich fange bei der Adressierung an, weil das die Entscheidung ist, die du nicht billig rückgängig machst. Ich wähle einen Block mit reichlich Luft nach oben und gleiche ihn gegen jedes andere Netz ab, mit dem wir eines Tages peeren oder zurück ins Büro verbinden könnten, denn überlappende Ranges sind genau das, was aus einer simplen Verbindung ein monatelanges Renumbering-Projekt macht. Dann drei Availability Zones, und ein Subnet pro Tier pro Zone. In den Public Subnets liegen nur der Load Balancer und die NAT Gateways. In den Private Subnets liegt die Anwendung, die ausgehend über NAT ins Internet kommt. Datenbanken sitzen in isolierten Subnets ganz ohne Route nach draußen. Für die Kontrolle setze ich auf Security Groups, die andere Security Groups referenzieren statt CIDR-Ranges, sodass sich die Regel liest als: das App-Tier darf die Datenbank auf dem Datenbank-Port erreichen. Und sie bleibt korrekt, wenn Instanzen sich ändern. Network ACLs halte ich grob, hauptsächlich als groben Riegel. Flow Logs gehen sofort an, denn an dem Tag, an dem du nachweisen musst, was mit was geredet hat, kannst du sie nicht rückwirkend aktivieren. Dazu kommen Gateway Endpoints für Object Storage, was diesen Traffic vom NAT fernhält.