Casi todos los errores en AWS son reversibles. Redimensionas una instancia, cambias una política, borras un bucket. La red no es así: un CIDR que elegiste en 2021 está hoy emparejado con dos socios y horneado en cuarenta grupos de seguridad, y cambiarlo es una migración.
Estos son los seis que más encontramos, más o menos en orden de lo dolorosos que son de arreglar después.
1. Un CIDR que colisiona con algo
El error de red más caro es elegir 10.0.0.0/16 porque es el valor por defecto. Todas las demás empresas lo eligieron también, y el día que emparejas con un socio, compras una empresa o conectas una VPN de cliente, no puedes enrutar.
Asigna desde un plan: un /16 por región y entorno, sacado de un rango documentado que tu equipo de red local haya bendecido, con IPAM llevando la cuenta. Si ya has colisionado, los NAT gateways privados y Transit Gateway con NAT pueden tapar el agujero, pero el parche es caro y confuso.
Reserva más de lo que crees. Un /24 por subred parece generoso hasta que un clúster de EKS con el CNI de VPC asigna una IP por pod y lo agotas en un trimestre.
2. Ninguna separación entre subredes públicas, privadas y de datos
Tres capas por zona de disponibilidad, siempre: pública (solo balanceadores y NAT), privada (cómputo) y aislada (bases de datos, sin ninguna ruta a internet). La capa aislada es la que se salta la gente, y es la que convierte "la base de datos no es alcanzable desde internet" en una afirmación sobre enrutamiento en lugar de sobre grupos de seguridad.
3. Topología de NAT gateway elegida por accidente
Un NAT gateway por zona de disponibilidad es la respuesta correcta de alta disponibilidad y son tres cargos fijos mensuales más procesamiento de datos. Un único NAT gateway ahorra dinero y añade un cargo de tráfico entre zonas más un punto único de fallo.
Ninguna de las dos está mal. Lo que está mal es no decidir. Y antes de decidir, quita el tráfico que nunca debería llegar a un NAT gateway: los endpoints de tipo gateway para S3 y DynamoDB son gratuitos y se llevan una porción sorprendente. Los endpoints de interfaz para el resto de servicios cuestan por hora, así que actívalos donde el cargo de procesamiento supere el precio del endpoint — normalmente ECR, Secrets Manager, SSM y CloudWatch Logs en una cuenta movida.
4. Grupos de seguridad usados como cortafuegos y no como identidad
El patrón que escala: los grupos de seguridad referencian otros grupos de seguridad, no rangos CIDR. app-sg permite el 5432 desde web-sg. Cuando añades una subred, no cambia nada. Cuando usas CIDR, cada cambio de topología es una revisión de grupos de seguridad.
Deja 0.0.0.0/0 completamente fuera de las reglas de entrada salvo en el puerto HTTPS del balanceador, y usa SSM Session Manager en lugar de SSH para que el puerto 22 no se abra nunca. Esa única sustitución elimina el hallazgo más común de todos los escaneos de postura que hacemos — mira el artículo de herramientas para cazar el resto.
5. Peering donde necesitabas un Transit Gateway
El peering de VPC es gratis de crear y no es transitivo: A emparejada con B y B con C no permite que A alcance C. Con tres VPC va bien. Con ocho son 28 conexiones de peering y una tabla de rutas que nadie entiende.
Transit Gateway cuesta por adjunto y hora más procesamiento de datos, y te da un concentrador con tablas de rutas sobre las que se puede razonar, segmentación entre entornos y un único sitio donde enganchar la VPN. El punto de cruce está en torno a cinco VPC, o de inmediato si necesitas segmentar entornos.
6. Sin flow logs, o con flow logs que nadie puede consultar
Activa los flow logs de VPC hacia S3 en formato Parquet, particionados por hora, en la cuenta de archivo de logs. No hacia CloudWatch Logs, donde el coste a volumen duele. Y crea la tabla de Athena el primer día, porque un flow log que no puedes consultar durante un incidente es almacenamiento, no telemetría.
Las tres preguntas que responden los flow logs y nada más responde: qué habla de verdad con esta instancia, de dónde sale el tráfico entre zonas y si algo alcanzó al host comprometido en la hora anterior.
La versión barata de los seis
Para un entorno nuevo, todo esto es una tarde de decisiones y una semana de Terraform. Para uno existente, empieza por los reversibles: endpoints, referencias entre grupos de seguridad, flow logs. El CIDR y la topología de peering son migraciones, y van en un plan con fecha, no en un backlog. Ese plan suele ser de las primeras cosas que escribimos en un proyecto cloud.
Qué hacer esta semana
Lista los CIDR de tus VPC en todas las cuentas y regiones y busca solapamientos. Después comprueba si existen los endpoints de gateway de S3 y DynamoDB en las VPC que hablan con ellos. Lo primero te dice si tienes una migración por delante; lo segundo es dinero gratis.