Explícame cómo diseñarías una VPC para una carga de trabajo en producción.

Elige un bloque CIDR lo bastante grande para crecer que no se solape con nada con lo que puedas hacer peering más adelante, y luego repártelo en al menos tres zonas de disponibilidad. Usa subredes públicas solo para balanceadores y NAT, subredes privadas para el cómputo, y subredes aisladas sin ruta de salida para las bases de datos. Controla el tráfico con security groups que se referencien entre sí en lugar de rangos de IP, y activa los flow logs desde el primer día.

Empiezo por el direccionamiento, porque es la decisión que no puedes deshacer barata. Elijo un bloque con mucho margen y lo contrasto con cualquier otra red con la que algún día podamos hacer peering o conectar de vuelta con la oficina, ya que los rangos solapados son lo que convierte una conexión simple en un proyecto de renumeración de meses. Luego tres zonas de disponibilidad, y una subred por nivel y por zona. Las subredes públicas solo alojan el balanceador y las NAT gateways. Las subredes privadas alojan la aplicación, que sale a internet a través de NAT. Las bases de datos están en subredes aisladas sin ninguna ruta de salida. Para el control me apoyo en security groups que referencian otros security groups en vez de rangos CIDR, así la regla se lee como el nivel de aplicación puede llegar a la base de datos por el puerto de base de datos, y sigue siendo correcta cuando cambian las instancias. Las network ACLs las mantengo gruesas, sobre todo como bloqueo bruto. Los flow logs se activan de inmediato, porque el día que necesites demostrar quién habló con quién no puedes activarlos de forma retroactiva. También añado gateway endpoints para el almacenamiento de objetos, lo que saca ese tráfico del NAT.