Guía AWS Cloud Practitioner CLF-C02

Amazon VPC es uno de los temas más importantes para entender cómo se conectan los recursos dentro de AWS. En Cloud Practitioner no te van a pedir diseñar una red compleja como en un examen de arquitectura, pero sí debes reconocer los conceptos principales: qué es una VPC, qué es una subred, qué hace una tabla de rutas, cuándo una subred es pública o privada, para qué sirve un Internet Gateway, cuándo usar un NAT Gateway y cómo se diferencian Security Groups y Network ACLs.

La forma sencilla de verlo es esta: una VPC es tu red privada dentro de AWS. Dentro de esa red creas subredes, colocas recursos como EC2, balanceadores o bases de datos, decides qué caminos puede seguir el tráfico y aplicas controles de seguridad. Si vienes del mundo on-premise, puedes imaginarla como una red corporativa virtual, pero gestionada sobre infraestructura AWS.

Objetivos de aprendizaje

1. Qué es Amazon VPC

Amazon Virtual Private Cloud, o Amazon VPC, te permite crear una red virtual aislada dentro de AWS. Aislada no significa desconectada del mundo, sino controlada por ti. Tú decides el rango de IP, las subredes, las rutas, los controles de entrada y salida, y la conectividad con Internet, otras VPC o tu datacenter.

Cuando lanzas recursos como instancias EC2, bases de datos RDS, balanceadores o servicios dentro de una red, normalmente los colocas dentro de una VPC y una subred concreta. Esa elección no es decorativa: afecta a seguridad, conectividad, disponibilidad y arquitectura.

Para CLF-C02 debes quedarte con esta frase: una VPC es la red privada donde colocas recursos de AWS y controlas cómo se comunican.

2. CIDR: el rango de IP de tu red

Cuando creas una VPC, eliges un rango de direcciones IP usando notación CIDR, por ejemplo 10.0.0.0/16. Ese rango define cuántas direcciones IP tendrá la red y de qué bloque saldrán las IP privadas de tus recursos.

No necesitas hacer cálculos avanzados de subnetting para Cloud Practitioner, pero sí reconocer que CIDR está relacionado con rangos de IP. Si una pregunta habla de definir el espacio de direcciones de una VPC o subred, está hablando de CIDR.

3. Subnets: dividir la VPC en partes más pequeñas

Una subnet es una parte de la VPC. Cada subnet vive dentro de una zona de disponibilidad concreta. Esto es muy importante: una VPC puede abarcar varias zonas de disponibilidad, pero cada subnet pertenece a una sola AZ.

Por eso, cuando quieres alta disponibilidad, normalmente creas varias subredes en distintas AZ. Por ejemplo, una subred pública en la AZ A, otra subred pública en la AZ B, una subred privada en la AZ A y otra subred privada en la AZ B.

Este patrón se repite muchísimo en arquitectura AWS: recursos distribuidos en varias zonas para evitar que un fallo de una zona deje toda la aplicación caída.

4. Subred pública y subred privada

Una de las confusiones más comunes es pensar que una subred es pública simplemente porque se llama “public-subnet”. No. El nombre no decide nada. Lo que hace que una subred sea pública es su tabla de rutas.

Una subred pública tiene una ruta hacia un Internet Gateway. Si un recurso dentro de esa subred tiene IP pública o Elastic IP y sus reglas de seguridad lo permiten, puede comunicarse directamente con Internet.

Una subred privada no tiene ruta directa hacia un Internet Gateway para tráfico iniciado desde Internet. Los recursos privados pueden estar protegidos de entrada directa, aunque pueden salir a Internet usando un NAT Gateway si lo necesitan.

5. Route tables: las tablas de rutas

Una route table decide hacia dónde se envía el tráfico que sale de una subred. Es como el mapa de carreteras de la red. Si el destino es una IP dentro de la VPC, el tráfico se queda dentro. Si el destino es Internet, la tabla de rutas necesita una ruta que apunte a un componente adecuado, como un Internet Gateway o un NAT Gateway.

La ruta más famosa que verás en ejemplos es 0.0.0.0/0. Significa “cualquier destino IPv4”. Si una route table tiene una ruta 0.0.0.0/0 hacia un Internet Gateway, esa subred puede comportarse como pública para recursos con IP pública.

Si una subred privada necesita salir a Internet para actualizaciones, descargas o llamadas externas, su route table puede tener una ruta 0.0.0.0/0 hacia un NAT Gateway ubicado en una subred pública.

6. Internet Gateway

Un Internet Gateway permite que una VPC se comunique con Internet. Se adjunta a la VPC y se utiliza en las tablas de rutas de subredes públicas.

Pero ojo: tener un Internet Gateway no significa que todos tus recursos sean públicos automáticamente. Para que una instancia sea accesible desde Internet normalmente necesita estar en una subred con ruta al IGW, tener IP pública o Elastic IP, y permitir tráfico en sus Security Groups y NACLs.

7. NAT Gateway

NAT Gateway sirve para que recursos en subredes privadas puedan iniciar conexiones hacia Internet sin ser accesibles directamente desde Internet.

Este caso aparece muchísimo en preguntas: “una instancia en una subred privada necesita descargar actualizaciones, pero no debe recibir conexiones entrantes desde Internet”. La respuesta suele ser NAT Gateway.

Normalmente el NAT Gateway se coloca en una subred pública, con acceso al Internet Gateway. Después, la route table de la subred privada apunta el tráfico de salida hacia ese NAT Gateway.

8. Security Groups

Un Security Group actúa como firewall virtual a nivel de recurso, por ejemplo una instancia EC2, un balanceador o una interfaz de red. Es uno de los controles de seguridad de red más importantes en AWS.

Los Security Groups son stateful. Esto significa que si permites una conexión de entrada, la respuesta de salida se permite automáticamente. Y si permites una conexión de salida, la respuesta de entrada correspondiente también se permite automáticamente.

Otro detalle clave: los Security Groups usan reglas de permitir. No se usan para crear reglas explícitas de denegación. Si algo no está permitido, queda bloqueado por defecto.

Para CLF-C02, asocia Security Group con: firewall a nivel de recurso, stateful, reglas allow, asociado a EC2/ENI/ALB/RDS.

9. Network ACLs

Una Network ACL, o NACL, controla tráfico a nivel de subred. A diferencia de los Security Groups, las NACLs son stateless. Esto significa que debes permitir tanto la ida como la vuelta del tráfico si quieres que funcione correctamente.

Las NACLs pueden tener reglas de allow y deny, y se evalúan por orden numérico. La primera regla que coincide gana. Esto las hace útiles para controles más generales a nivel de subred.

Para Cloud Practitioner no necesitas configurar NACLs en detalle, pero sí diferenciar NACL y Security Group.

10. Security Groups vs NACLs

11. Diferencia entre rutas y reglas de seguridad

Otro error típico es mezclar rutas con seguridad. Una tabla de rutas dice por dónde puede ir el tráfico. Un Security Group o una NACL dice si ese tráfico está permitido o bloqueado.

Puede existir una ruta correcta hacia Internet, pero si el Security Group no permite el puerto 443, el tráfico HTTPS no funcionará. También puede existir una regla de Security Group permitiendo tráfico, pero si no hay ruta hacia el destino, tampoco funcionará.

12. Alta disponibilidad en redes AWS

Las redes en AWS se diseñan pensando en zonas de disponibilidad. Una arquitectura típica usa varias subredes en distintas AZ para evitar depender de una única zona.

Por ejemplo, una aplicación web puede tener un Application Load Balancer en subredes públicas de dos AZ y servidores EC2 en subredes privadas de esas mismas AZ. Si una zona falla, la otra puede seguir atendiendo tráfico si la aplicación está preparada.

Con NAT Gateway también conviene pensar en resiliencia. En arquitecturas bien diseñadas, se suele desplegar un NAT Gateway por AZ y las subredes privadas de cada AZ salen por el NAT de su misma zona. Así se evita depender de un único NAT para toda la aplicación.

13. VPC Peering

VPC Peering permite conectar dos VPC para que puedan comunicarse usando direcciones IP privadas. Es útil cuando tienes redes separadas y quieres que ciertos recursos se comuniquen sin pasar por Internet público.

Para CLF-C02, si una pregunta dice “conectar dos VPC mediante conectividad privada”, VPC Peering puede aparecer como respuesta. Pero recuerda que no es una solución para conectar cientos de VPC de forma centralizada; para escenarios más grandes se usa AWS Transit Gateway.

14. AWS Transit Gateway

AWS Transit Gateway actúa como un hub central para conectar múltiples VPC y redes on-premises. Imagina una rotonda o núcleo central de conectividad: en vez de crear muchas conexiones punto a punto, conectas redes al Transit Gateway.

En Cloud Practitioner no deberías tener que diseñar Transit Gateway, pero sí reconocerlo cuando el escenario habla de simplificar conectividad entre muchas VPC y entornos locales.

15. VPC Endpoints

VPC Endpoints permiten acceder a servicios de AWS desde una VPC sin salir a Internet público. Esto es importante para seguridad y privacidad.

Por ejemplo, una instancia privada puede necesitar acceder a Amazon S3. En vez de salir por NAT Gateway hacia Internet, puede usar un VPC Endpoint para S3 y mantener el tráfico dentro de la red de AWS.

Para el examen, asocia VPC Endpoint con acceso privado a servicios AWS sin usar Internet público.

16. VPN Site-to-Site

AWS Site-to-Site VPN permite conectar una red on-premises con AWS usando túneles cifrados sobre Internet. Es una opción habitual cuando una empresa quiere conectividad híbrida de forma relativamente rápida y segura.

La pista del examen suele ser: “conexión cifrada entre el datacenter de la empresa y AWS a través de Internet”. Ahí piensa en VPN.

17. AWS Direct Connect

AWS Direct Connect proporciona una conexión de red dedicada entre el entorno del cliente y AWS. No va por Internet público como una VPN normal. Suele usarse cuando se necesita conectividad más estable, predecible, privada o con mayor ancho de banda.

La pista típica es: “conexión dedicada”, “conectividad privada”, “ancho de banda consistente” o “reducir variabilidad de Internet”. Ahí piensa en Direct Connect.

18. VPN vs Direct Connect

19. Load Balancer dentro de una VPC

Los balanceadores de carga, como Application Load Balancer o Network Load Balancer, se despliegan dentro de una VPC y normalmente usan subredes de varias zonas de disponibilidad.

Un patrón típico es tener un ALB público en subredes públicas y servidores EC2 en subredes privadas. El usuario entra por el balanceador, pero las instancias no están expuestas directamente a Internet. Esto mejora seguridad y permite escalar mejor.

20. Subred pública no significa insegura

Una subred pública no es “mala” por definición. Se usa para recursos que necesitan entrada o salida directa a Internet, como balanceadores públicos, NAT Gateways o bastiones si se usan. Lo importante es controlar qué recursos colocas ahí y qué reglas de seguridad aplicas.

Una mala práctica sería colocar bases de datos directamente en subredes públicas sin necesidad. En una arquitectura típica, una base de datos RDS va en subredes privadas y solo permite acceso desde la capa de aplicación.

21. Subred privada no significa sin Internet

Una subred privada no recibe tráfico directo desde Internet, pero eso no significa que sus recursos no puedan salir a Internet. Pueden hacerlo usando NAT Gateway, endpoints privados o conectividad controlada.

Esto se usa mucho para servidores de aplicación que necesitan descargar paquetes, llamar a APIs externas o actualizar software, pero que no deben ser accesibles desde Internet.

22. Patrones típicos de examen

23. Tabla de decisión rápida

24. Errores típicos

• Creer que una subred es pública solo porque se llama “public”. Lo importante es la ruta hacia Internet Gateway.
• Confundir Internet Gateway con NAT Gateway. IGW permite conectividad pública; NAT permite salida desde privado.
• Pensar que NAT Gateway permite conexiones entrantes desde Internet hacia instancias privadas. No es su función.
• Confundir Security Groups con NACLs. Security Group es stateful y va a nivel de recurso; NACL es stateless y va a nivel de subnet.
• Olvidar que las rutas y los controles de seguridad son cosas distintas.
• Elegir Direct Connect cuando el escenario solo pide una VPN cifrada sobre Internet.
• Elegir VPN cuando el escenario pide una conexión dedicada y rendimiento predecible.
• Colocar bases de datos en subred pública sin necesidad.
• Olvidar que para alta disponibilidad conviene distribuir recursos en varias AZ.
• Pensar que una instancia en subred pública será accesible automáticamente aunque no tenga IP pública o reglas adecuadas.

Resumen final

Amazon VPC es la base de red de muchas arquitecturas en AWS. Para CLF-C02, lo más importante es reconocer la función de cada pieza. La VPC es la red virtual. Las subnets dividen esa red por zonas de disponibilidad. Las route tables deciden hacia dónde va el tráfico. Internet Gateway permite conectividad pública. NAT Gateway permite salida desde subredes privadas. Security Groups protegen recursos de forma stateful. NACLs filtran a nivel de subnet de forma stateless.

Cuando leas una pregunta de examen, no intentes resolver toda la arquitectura de golpe. Busca la pista: si habla de salida desde privado, NAT Gateway. Si habla de entrada/salida a Internet para recursos públicos, Internet Gateway. Si habla de firewall de instancia, Security Group. Si habla de reglas allow/deny a nivel de subnet, NACL. Si habla de conexión cifrada con on-premises, VPN. Si habla de conexión dedicada, Direct Connect.