Semana 5 · Módulo 5 de 11

Redes en AWS (I): VPC, conectividad híbrida y costes de red

Aprenderás a diseñar una VPC desde cero (subredes, rutas, NAT, security groups y network ACLs), a conectarla de forma privada con servicios de AWS, con otras VPC y con tu centro de datos, y a elegir la opción de red más barata. Es el bloque con más preguntas «trampa» del examen: casi todos los escenarios tienen una VPC debajo.

Reparto de la semana

Esta semana tiene mucha teoría nueva y dos laboratorios con recursos que cobran por hora (NAT Gateway, IPv4 públicas, interface endpoints). Haz cada lab de una sentada y limpia al terminar.

Por qué importa

Casi cualquier arquitectura de AWS vive dentro de una Amazon VPC (Virtual Private Cloud, nube privada virtual): las instancias EC2, las bases de datos RDS, los balanceadores, las funciones Lambda conectadas a una red privada, los contenedores… Si no entiendes cómo se enruta el tráfico, no sabrás por qué una instancia «no llega a S3» ni cuál es la opción más barata para que lo haga.

El examen pregunta redes en tres task statements:

• 1.2 (seguridad): segmentar con subredes públicas y privadas, security groups, network ACLs, NAT, endpoints y conexiones cifradas (VPN, Direct Connect).
• 3.4 (rendimiento y escalabilidad): topologías multinivel, híbridas y globales, direccionamiento IP que aguante el crecimiento, opciones de conexión (VPN, Direct Connect, PrivateLink).
• 4.4 (coste): NAT Gateway compartido o uno por AZ, Direct Connect frente a VPN frente a internet, rutas que evitan cargos de transferencia (entre AZ, entre regiones, endpoints).

Qué es una VPC

Una VPC es una red virtual aislada lógicamente, dentro de una región, en la que lanzas tus recursos. Tú eliges su rango de direcciones, sus subredes, sus tablas de rutas y sus puertas de salida.

Ideas clave:

• Una VPC pertenece a una región y abarca todas las AZ (Availability Zones, zonas de disponibilidad) de esa región.
• Una subred (subnet) pertenece a una sola AZ. Para tener alta disponibilidad necesitas subredes en al menos dos AZ.
• Cada cuenta tiene una VPC por defecto (default VPC) en cada región, con una subred pública por AZ. Sirve para pruebas; en producción se diseña una VPC propia.
• Cuotas por defecto (ajustables): 5 VPC por región y 200 subredes por VPC.

CIDR: el rango de direcciones

El rango de la VPC se expresa en notación CIDR (Classless Inter-Domain Routing), por ejemplo 10.0.0.0/16: los primeros 16 bits son la red y quedan 16 bits para hosts (65.536 direcciones).

• El bloque IPv4 de una VPC y de una subred puede ir de /16 (65.536 direcciones) a /28 (16 direcciones).
• Usa rangos privados de la RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
• Puedes añadir bloques CIDR secundarios a una VPC (5 bloques IPv4 por defecto, ampliable hasta 50) si te quedas sin direcciones.
• No solapes rangos con otras VPC ni con tu red local si algún día vas a conectarlas: el VPC peering no admite CIDR solapados y el enrutamiento híbrido se complica.

Las 5 direcciones reservadas de cada subred

AWS reserva las 4 primeras y la última dirección de cada subred. En 10.0.0.0/24:

Así, una /24 ofrece 256 − 5 = 251 direcciones utilizables, y una /28, solo 11.

Enrutamiento: tablas de rutas y puertas de enlace

Tablas de rutas (route tables)

Cada subred está asociada a una sola tabla de rutas (una tabla puede servir a varias subredes). Si no la asocias explícitamente, usa la tabla principal (main route table) de la VPC.

• Toda tabla tiene la ruta local para el CIDR de la VPC: todas las subredes de una VPC se ven entre sí por defecto. No se puede borrar.
• Si varias rutas coinciden, gana la más específica (longest prefix match): una ruta a 10.1.0.0/16 gana a 0.0.0.0/0.
• Destinos (targets) habituales: internet gateway (igw-), NAT gateway (nat-), VPC peering (pcx-), transit gateway (tgw-), virtual private gateway (vgw-), gateway endpoint (mediante una prefix list pl-), interfaz de red (eni-), egress-only internet gateway (eigw-).

Internet gateway (IGW)

Componente gestionado, redundante y escalado horizontalmente que conecta la VPC con internet. Una VPC tiene como mucho un IGW. No tiene coste por hora (pagas la transferencia de datos).

¿Qué hace «pública» a una subred?

Esta es la definición que el examen da por sabida:

• Subred pública: su tabla de rutas tiene una ruta 0.0.0.0/0 hacia un internet gateway. Las instancias necesitan además una IPv4 pública (o Elastic IP) para ser alcanzables.
• Subred privada: no tiene ruta al IGW. Si necesita salir a internet (parches, APIs externas), lo hace a través de un NAT gateway situado en una subred pública (o de un NAT gateway regional).

La VPC de referencia: dos AZ, tres niveles

Este es el diseño que verás en el 80 % de los escenarios: una arquitectura multinivel (multi-tier) repartida en dos AZ.

flowchart TB
  internet(("Internet"))
  subgraph vpc["VPC 10.0.0.0/16 (región eu-south-2)"]
    igw["Internet gateway"]
    subgraph az1["AZ a"]
      pub1["Subred pública 10.0.0.0/24<br/>ALB + NAT gateway"]
      app1["Subred privada app 10.0.10.0/24<br/>EC2 (Auto Scaling)"]
      db1["Subred privada datos 10.0.20.0/24<br/>RDS primaria"]
    end
    subgraph az2["AZ b"]
      pub2["Subred pública 10.0.1.0/24<br/>ALB + NAT gateway"]
      app2["Subred privada app 10.0.11.0/24<br/>EC2 (Auto Scaling)"]
      db2["Subred privada datos 10.0.21.0/24<br/>RDS standby"]
    end
  end
  internet --> igw
  igw --> pub1
  igw --> pub2
  pub1 --> app1
  pub2 --> app2
  app1 --> db1
  app2 --> db2

Y sus tablas de rutas:

Fíjate en que hay una tabla privada por AZ, cada una apuntando al NAT gateway de su propia AZ: si cae la AZ a, la AZ b sigue saliendo a internet. Lo verás en detalle en la sección de NAT.

Direccionamiento IP

IPv4 privada, IPv4 pública y Elastic IP

• IPv4 privada: toda interfaz de red (ENI, elastic network interface) tiene una, del CIDR de su subred. Se mantiene aunque pares la instancia.
• IPv4 pública automática: se asigna al lanzar (si la subred o la instancia lo piden) y cambia al parar y arrancar la instancia.
• Elastic IP (EIP): IPv4 pública estática que reservas en tu cuenta y asocias a una instancia o NAT gateway. Cuota por defecto: 5 por región.

IPv6 en la VPC

• Puedes asociar a la VPC un bloque IPv6 (Amazon te asigna uno, o traes el tuyo con BYOIP). Las subredes IPv6 van de /44 a /64 en saltos de /4.
• Las VPC pueden ser dual-stack (IPv4 + IPv6) y hay subredes IPv6-only.
• Las IPv6 son globalmente únicas y, por tanto, públicas: no existe «IPv6 privada con NAT». Para que una instancia IPv6 salga a internet sin ser accesible desde fuera se usa un egress-only internet gateway (ruta ::/0 → eigw). Es stateful, gratuito (pagas la transferencia) y solo sirve para IPv6.
• Si una carga IPv6-only necesita hablar con destinos IPv4, el NAT gateway hace NAT64 junto con DNS64 del Route 53 Resolver.

Planificar el direccionamiento para crecer (task 3.4)

• Reserva un bloque grande por VPC (por ejemplo /16) aunque hoy uses poco: ampliar después es posible (CIDR secundarios) pero añade complejidad.
• No solapes rangos entre VPC, cuentas y oficinas. En organizaciones grandes se centraliza con Amazon VPC IP Address Manager (IPAM).
• Deja subredes de reserva por AZ para futuros niveles (por ejemplo, contenedores que consumen muchas IP).
• Para compartir una misma red entre cuentas sin duplicar VPC, existe el VPC sharing con AWS RAM (Resource Access Manager): la cuenta propietaria comparte subredes y las cuentas participantes lanzan recursos en ellas.

Seguridad de red

La VPC ofrece dos cortafuegos integrados, gratuitos, que se complementan: el security group (a nivel de interfaz de red) y la network ACL (a nivel de subred).

Security groups (SG)

Un security group es un cortafuegos virtual con estado (stateful) asociado a una interfaz de red (y, por tanto, a instancias, balanceadores, bases de datos RDS, funciones Lambda en VPC, endpoints…).

• Solo reglas de permitir (allow). No hay reglas de denegar: lo que no está permitido se deniega.
• Stateful: si permites la entrada de una petición, la respuesta sale automáticamente, sin mirar las reglas de salida (y viceversa).
• Se evalúan todas las reglas a la vez (no hay orden).
• Un SG nuevo no permite ninguna entrada y permite toda la salida.
• Puedes usar como origen otro security group (por ejemplo, «la base de datos acepta 3306 solo desde el SG de la aplicación»), un CIDR o una prefix list.
• Cuotas por defecto: 60 reglas de entrada y 60 de salida por SG, 5 SG por interfaz de red (ampliable hasta 16).

Network ACLs (NACL)

Una network ACL es un cortafuegos sin estado (stateless) a nivel de subred.

• Reglas de permitir y de denegar.
• Stateless: la respuesta se evalúa como tráfico nuevo; tienes que permitir explícitamente el tráfico de vuelta, que usa puertos efímeros (por ejemplo 1024-65535).
• Reglas numeradas del 1 al 32766; se evalúan en orden, de menor a mayor, y se aplica la primera que coincide. Al final hay una regla * que deniega todo.
• La NACL por defecto de la VPC permite todo en ambos sentidos. Una NACL personalizada nueva deniega todo hasta que añades reglas.
• Cada subred tiene una sola NACL; una NACL puede asociarse a varias subredes.
• Cuota: 20 reglas de entrada y 20 de salida por defecto (ampliable hasta 40 y 40).
• No filtran el tráfico al DNS de Amazon (VPC+2), a DHCP ni al servicio de metadatos (IMDS). Para filtrar DNS se usa Route 53 Resolver DNS Firewall.

Security group vs network ACL

Ejemplo: tres niveles con SG que se referencian

Referenciar SG en lugar de CIDR hace que la regla siga funcionando aunque el Auto Scaling group cambie las IP de las instancias.

Controlar puertos, protocolos y tráfico (task 1.2)

Resumen de las capas de control de red de AWS, de fuera hacia dentro:

1. Borde (edge): AWS Shield y AWS WAF en CloudFront (módulo 6).
2. Perímetro de la VPC: AWS Network Firewall (inspección con estado, IPS, filtrado por dominio).
3. Subred: network ACL.
4. Interfaz de red: security group.
5. Instancia: cortafuegos del sistema operativo.

AWS Network Firewall

Servicio gestionado de cortafuegos con estado e IPS/IDS (intrusion prevention/detection system) para tus VPC.

• Filtra el tráfico en el perímetro de la VPC: hacia y desde el internet gateway, el NAT gateway, VPN o Direct Connect, y entre VPC (con Transit Gateway).
• Usa el motor de código abierto Suricata: reglas compatibles con Suricata, reglas de 5 tuplas, filtrado por nombres de dominio (por ejemplo, permitir salida solo a *.amazonaws.com) e inspección profunda de paquetes. Admite inspección TLS con certificados de ACM.
• Tiene grupos de reglas stateless y stateful.
• Se despliega creando firewall endpoints en subredes dedicadas (una por AZ) y cambiando las tablas de rutas para que el tráfico pase por ellos.
• Se gestiona de forma centralizada en una organización con AWS Firewall Manager.

«Inspeccionar todo el tráfico que entra y sale de las VPC, con reglas IPS y filtrado de dominios, sin gestionar appliances» → AWS Network Firewall. Si el enunciado habla de appliances de terceros (cortafuegos virtuales de un fabricante) que deben escalar de forma transparente → Gateway Load Balancer (módulo 2).

VPC Flow Logs

Los VPC Flow Logs capturan metadatos del tráfico IP (origen, destino, puertos, protocolo, bytes, ACCEPT/REJECT) de las interfaces de red.

• Se crean a nivel de VPC, subred o interfaz de red (y también para Transit Gateway).
• Destinos: CloudWatch Logs, Amazon S3 o Amazon Data Firehose. En S3 se consultan con Amazon Athena.
• Tráfico a capturar: aceptado, rechazado o todo.
• No capturan el contenido de los paquetes (para eso existe Traffic Mirroring) y no son en tiempo real (tardan unos minutos).
• Se recogen fuera del camino del tráfico: no afectan al rendimiento de la red.
• No registran, entre otros, el tráfico al DNS de Amazon, al servicio de metadatos (169.254.169.254), DHCP ni al Amazon Time Sync Service.
• Una vez creado, un flow log no se puede modificar: se borra y se crea otro.

Salida a internet desde subredes privadas

NAT gateway

Un NAT gateway permite que los recursos de subredes privadas inicien conexiones hacia fuera de la VPC (internet u otras redes) mientras nadie de fuera puede iniciar conexiones hacia ellos. Es un servicio gestionado.

• Tipo público (por defecto): se crea en una subred pública con una Elastic IP, y la ruta de la subred privada 0.0.0.0/0 apunta al NAT. Hacia internet, el tráfico sale con la EIP.
• Tipo privado: sin EIP; sirve para salir hacia otras VPC o la red local (vía Transit Gateway o virtual private gateway) cuando hay solapamiento de rangos o hay que presentar IP concretas. No puede salir a internet.
• Protocolos: TCP, UDP e ICMP. Admite NAT64 para cargas IPv6.
• Rendimiento: 5 Gbps que escalan automáticamente hasta 100 Gbps, y de 1 a 10 millones de paquetes por segundo. Cada IPv4 admite 55.000 conexiones simultáneas por destino único; puedes asociar hasta 8 IP a un NAT zonal (2 EIP por defecto, ampliable).
• No se le pueden asociar security groups: controlas el tráfico con los SG de las instancias y la NACL de la subred del NAT (que usa los puertos 1024-65535).
• No se puede usar a través de un VPC peering («cliente → peering → NAT → internet» no funciona), ni desde VPN/Direct Connect con virtual private gateway (sí con Transit Gateway).

NAT gateway zonal: la alta disponibilidad es cosa tuya

El NAT gateway clásico (ahora llamado zonal) se crea en una AZ concreta y es redundante dentro de esa AZ. Si varias AZ comparten un único NAT y cae la AZ del NAT, las demás AZ pierden la salida a internet.

La recomendación de AWS: un NAT gateway por AZ y una tabla de rutas por AZ que apunte a su NAT local. Además evitas el cargo por tráfico entre AZ hacia el NAT.

flowchart LR
  subgraph compartido["Opción A: un NAT compartido (barato, punto único de fallo)"]
    pa["Privada AZ a"] --> nata["NAT (AZ a)"]
    pb["Privada AZ b"] -- "tráfico entre AZ (se cobra)" --> nata
  end
  subgraph poraz["Opción B: un NAT por AZ (alta disponibilidad)"]
    qa["Privada AZ a"] --> nat1["NAT (AZ a)"]
    qb["Privada AZ b"] --> nat2["NAT (AZ b)"]
  end

NAT gateway regional (novedad de noviembre de 2025)

Desde noviembre de 2025 existe el NAT gateway regional, que el material antiguo no menciona:

• Se expande y contrae automáticamente por las AZ donde tienes cargas de trabajo (detecta interfaces de red en una AZ nueva; la expansión puede tardar hasta 60 minutos, y mientras tanto el tráfico se procesa desde otra AZ).
• No necesita subred pública: es un recurso independiente con su propia tabla de rutas (con ruta preconfigurada al internet gateway, así que la VPC sigue necesitando IGW).
• Un único ID de NAT para todas las AZ: todas las subredes privadas pueden usar la misma ruta 0.0.0.0/0 → nat-regional.
• Hasta 32 IP por AZ (frente a 8 del zonal).
• Modos automático (AWS gestiona IP y expansión) o manual.
• No admite NAT privado: para conectividad privada, NAT zonal.
• Se factura por hora y por cada AZ en la que está activo (tres AZ durante una hora = tres «NAT Gateway-hours»), más el procesamiento de datos.

aws ec2 create-nat-gateway --vpc-id vpc-12345678 --availability-mode regional

NAT instance (la opción antigua)

Una NAT instance es una instancia EC2 configurada para hacer NAT (con la comprobación de origen/destino, source/destination check, desactivada). AWS la considera una solución heredada.

Acceso privado a servicios de AWS: VPC endpoints y AWS PrivateLink

Los servicios de AWS (S3, DynamoDB, SQS, KMS, Secrets Manager…) tienen endpoints públicos (por ejemplo s3.eu-south-2.amazonaws.com). Una instancia en una subred privada no llega a ellos salvo que:

1. salga por un NAT gateway (funciona, pero pagas el NAT y el tráfico pasa por la ruta de internet de la VPC), o
2. use un VPC endpoint, que conecta la VPC con el servicio de forma privada, sin IGW, sin NAT y sin IP públicas.

Esto es lo que el task statement 1.2 llama «AWS service endpoints».

Gateway endpoints

• Solo para Amazon S3 y Amazon DynamoDB.
• Gratis: sin cargo por hora ni por GB.
• No crean interfaces de red: añaden a las tablas de rutas que elijas una ruta cuyo destino es la prefix list del servicio (pl-…) y cuyo target es el endpoint (vpce-…). Esa ruta, al ser más específica, gana a 0.0.0.0/0.
• Funcionan solo dentro de la región de la VPC y solo para tráfico que se origina en esa VPC: no sirven desde la red local (VPN/Direct Connect), ni desde una VPC emparejada, ni desde otra región.
• Admiten endpoint policies (políticas de recurso del endpoint) para limitar qué buckets o acciones se permiten.

Interface endpoints (AWS PrivateLink)

• Para la mayoría de servicios de AWS (SQS, SNS, KMS, Secrets Manager, STS, ECR, CloudWatch, Systems Manager…), para servicios de terceros de AWS Marketplace y para tus propios servicios. También existen para S3 (DynamoDB también admite interface endpoints).
• Crean una interfaz de red (ENI) con IP privada en cada subred que elijas (una por AZ para alta disponibilidad).
• Con private DNS activado, el nombre público del servicio (sqs.eu-south-2.amazonaws.com) resuelve a las IP privadas del endpoint dentro de la VPC: no hay que cambiar el código.
• Se protegen con security groups (deben permitir TCP 443 desde tus instancias) y admiten endpoint policies.
• Accesibles desde la red local (por VPN o Direct Connect) y desde VPC emparejadas o conectadas por Transit Gateway, porque son simples IP privadas.
• Cobran: en eu-south-2, 0,011 USD por hora y por AZ más 0,01 USD por GB procesado (primer PB al mes), según la API de precios de AWS (septiembre de 2026).

Gateway endpoint vs interface endpoint

Ejemplo de bucket policy que deniega todo acceso que no llegue por un endpoint concreto (ajusta los nombres):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SoloDesdeMiEndpoint",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::mi-bucket-privado",
        "arn:aws:s3:::mi-bucket-privado/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

Exponer tus propios servicios con PrivateLink

AWS PrivateLink también sirve para publicar un servicio tuyo a otras VPC o cuentas sin peering ni exponer rangos de red:

• El proveedor pone su aplicación detrás de un Network Load Balancer (o Gateway Load Balancer) y crea un endpoint service.
• Cada consumidor crea un interface endpoint en su VPC hacia ese servicio.
• El tráfico es unidireccional (consumidor → servicio), no hay que enrutar redes enteras y funciona aunque los CIDR se solapen.

Conectar VPC entre sí

VPC peering

Una conexión uno a uno entre dos VPC, de la misma o de distinta cuenta, y de la misma o de distinta región (inter-Region peering). El tráfico va por la red privada de AWS.

• Se solicita desde una VPC y se acepta desde la otra; después, cada lado añade rutas hacia el CIDR del otro y ajusta los security groups.
• Sin CIDR solapados: si cualquiera de los bloques (incluso secundarios) se solapa, no se puede crear.
• No es transitivo: si A está emparejada con B y con C, B no llega a C a través de A. Hace falta un peering B–C.
• Sin enrutamiento «de borde a borde» (edge-to-edge): B no puede usar el internet gateway, el NAT, la VPN, el Direct Connect ni el gateway endpoint de S3 de A.
• En la misma región puedes referenciar security groups de la VPC emparejada.
• Cuota: 50 peerings activos por VPC (ampliable hasta 125). No hay cargo por la conexión en sí; pagas la transferencia de datos (gratis dentro de la misma AZ; con cargo entre AZ y entre regiones).

Con muchas VPC, el peering se convierte en una malla completa: con n VPC necesitas n·(n−1)/2 conexiones (10 VPC → 45 peerings, con sus rutas).

AWS Transit Gateway (TGW)

Un router regional gestionado que actúa como hub (modelo hub-and-spoke): conectas cada VPC, VPN, Direct Connect gateway u otro Transit Gateway una sola vez al hub y el TGW enruta entre todos.

• Adjuntos (attachments): VPC, Site-to-Site VPN, Direct Connect gateway, peering con otro TGW (misma o distinta región), Connect (SD-WAN).
• Enrutamiento transitivo controlado con tablas de rutas del TGW: puedes aislar entornos (producción no ve desarrollo) o forzar el paso por una VPC de inspección.
• Escala: 5.000 adjuntos por TGW por defecto y hasta 100 Gbps por adjunto de VPC y por AZ.
• Admite ECMP (equal-cost multipath) con VPN de enrutamiento dinámico (BGP) para sumar el ancho de banda de varios túneles VPN.
• Se comparte entre cuentas con AWS RAM.
• También admite multicast (poco preguntado).

flowchart TB
  tgw["AWS Transit Gateway (hub regional)"]
  a["VPC prod"] --- tgw
  b["VPC dev"] --- tgw
  c["VPC servicios compartidos"] --- tgw
  d["VPC inspección (Network Firewall)"] --- tgw
  vpn["Site-to-Site VPN (oficina)"] --- tgw
  dx["Direct Connect gateway"] --- tgw
  tgw2["Transit Gateway en otra región"] -- "peering de TGW" --- tgw

VPC peering vs Transit Gateway

Precios de eu-south-2 obtenidos de la API de precios de AWS (septiembre de 2026); consulta Amazon VPC pricing.

Conectividad híbrida: VPN y Direct Connect

El task statement 1.2 pide «securing external network connections to and from the AWS Cloud (for example, VPN, AWS Direct Connect)», y el 4.4, elegir entre Direct Connect, VPN e internet y dimensionar el ancho de banda.

AWS Site-to-Site VPN

Un túnel IPsec cifrado sobre internet entre tu red (un router o cortafuegos, el customer gateway) y AWS.

• En el lado de AWS termina en un virtual private gateway (VGW), asociado a una sola VPC, o en un Transit Gateway (para compartir la VPN con muchas VPC).
• En AWS creas un customer gateway (CGW): el recurso que representa tu dispositivo (su IP pública y su ASN).
• Cada conexión VPN tiene dos túneles (en dos puntos de AWS) para redundancia.
• Enrutamiento estático o dinámico con BGP (recomendado; necesario para ECMP con Transit Gateway).
• Ancho de banda: hasta 1,25 Gbps por túnel estándar y hasta 5 Gbps por túnel de gran ancho de banda (large bandwidth tunnel). Para más, varias VPN con ECMP en un Transit Gateway.
• Accelerated Site-to-Site VPN: entra por la red de AWS Global Accelerator (la ubicación edge más cercana) para mejorar la calidad del túnel en conexiones de larga distancia (requiere Transit Gateway).
• Se configura en minutos y es barata: 0,05 USD por hora por conexión en eu-south-2 (≈36,5 USD al mes) más la transferencia de datos.

AWS Client VPN

VPN de acceso remoto para personas (portátiles de empleados), gestionada por AWS y basada en OpenVPN (TLS).

• Autenticación con Active Directory (AWS Directory Service), federación SAML o certificados mutuos.
• Reglas de autorización por grupo de usuarios y security groups.
• Split tunnel opcional (solo el tráfico hacia AWS va por la VPN).
• Se asocia a subredes de una VPC o a un Transit Gateway; desde ahí llegas a otras VPC o a la red local.
• Coste en eu-south-2: 0,15 USD por hora por asociación del endpoint y 0,05 USD por hora por conexión activa. Es cara para un laboratorio.

«Los empleados que teletrabajan deben acceder de forma segura a recursos privados de la VPC» → Client VPN. «Conectar la oficina o el centro de datos» → Site-to-Site VPN (o Direct Connect).

AWS Direct Connect (DX)

Una conexión física dedicada (fibra) entre tu red y AWS a través de una ubicación de Direct Connect (un centro de datos de colocation), sin pasar por internet.

• Latencia consistente y ancho de banda predecible; útil para grandes volúmenes (y la transferencia de salida por DX es más barata que por internet).
• Tarda semanas en aprovisionarse (circuito físico, cross-connect): nunca es la respuesta a «lo necesitamos para mañana».
• No va cifrado por defecto. Opciones: MACsec (cifrado de capa 2 en conexiones dedicadas de 10, 100 y 400 Gbps) o VPN IPsec sobre Direct Connect.

Tipos de conexión:

Virtual interfaces (VIF) sobre la conexión:

• Private VIF: acceso a una VPC (a su virtual private gateway) o a un Direct Connect gateway, con IP privadas.
• Public VIF: acceso a los servicios públicos de AWS (S3, DynamoDB…) con IP públicas, sin pasar por internet.
• Transit VIF: acceso a Transit Gateways a través de un Direct Connect gateway.

Direct Connect gateway (DXGW): recurso global que permite usar una misma conexión DX para llegar a VPC de cualquier región (salvo China) y de varias cuentas, asociándolo a virtual private gateways o a Transit Gateways. No enruta tráfico entre las VPC asociadas (no es un router entre VPC).

LAG (link aggregation group): agrupa varias conexiones dedicadas de la misma velocidad, que terminan en el mismo endpoint de Direct Connect, como una sola conexión lógica (LACP, activo/activo). Máximo 4 conexiones de menos de 100 Gbps, o 2 de 100 o 400 Gbps. Sirve para sumar ancho de banda, no para resiliencia ante la caída de una ubicación.

Resiliencia de Direct Connect (modelos recomendados)

El AWS Direct Connect Resiliency Toolkit propone tres modelos:

flowchart LR
  dc["Centro de datos"]
  subgraph loc1["Ubicación DX 1"]
    r1["Dispositivo AWS 1"]
    r2["Dispositivo AWS 2"]
  end
  subgraph loc2["Ubicación DX 2"]
    r3["Dispositivo AWS 3"]
    r4["Dispositivo AWS 4"]
  end
  aws["Región AWS (Direct Connect gateway)"]
  dc --> r1 --> aws
  dc --> r2 --> aws
  dc --> r3 --> aws
  dc --> r4 --> aws
  dc -. "VPN de respaldo por internet (opción económica)" .-> aws

La opción económica de redundancia: una conexión Direct Connect + una Site-to-Site VPN de respaldo por internet. La VPN tiene menos ancho de banda y latencia variable, pero mantiene el servicio si cae el DX.

VPN sobre Direct Connect

Si necesitas cifrado de extremo a extremo además de la conexión privada:

• Private IP VPN: túneles IPsec con IP privadas sobre una transit VIF, terminando en un Transit Gateway (con Direct Connect gateway). No expone IP públicas.
• La forma clásica: una Site-to-Site VPN sobre una public VIF.
• Alternativa en capa 2: MACsec (solo dedicadas de 10/100/400 Gbps).

Internet vs VPN vs Direct Connect

Dimensionar el ancho de banda (task 4.4)

La guía pide «selecting the appropriate bandwidth allocation for a network device (for example, a single VPN compared with multiple VPNs, Direct Connect speed)»:

• Una VPN no pasa de 1,25 Gbps por túnel estándar. Si necesitas más: túneles large bandwidth (hasta 5 Gbps) o varias VPN con ECMP en un Transit Gateway (enrutamiento dinámico BGP obligatorio).
• Direct Connect: elige la velocidad por el tráfico sostenido previsto. Si necesitas menos de 1 Gbps, una hosted connection (desde 50 Mbps) es más barata que un puerto dedicado. Para más de un puerto, LAG.
• Sobredimensionar cuesta dinero; infradimensionar provoca colas y pérdidas. Mide con CloudWatch (métricas de la conexión DX y de los túneles VPN) antes de ampliar.

Costes de transferencia de datos

El task statement 4.4 exige saber qué tráfico se cobra y cómo reducirlo. Los precios siguientes son de eu-south-2 (España), obtenidos de la API pública de precios de AWS (publicación de septiembre de 2026). Úsalos como estimación: comprueba siempre la página de precios de EC2 (Data Transfer), la de Amazon VPC y la AWS Pricing Calculator.

flowchart LR
  inet(("Internet"))
  subgraph region1["Región A"]
    az1["AZ 1"]
    az2["AZ 2"]
  end
  region2["Región B"]
  inet -- "entrada: gratis" --> az1
  az1 -- "salida: 0,09 USD/GB (tras 100 GB gratis)" --> inet
  az1 -- "0,01 USD/GB cada sentido" --> az2
  az1 -- "0,02 USD/GB" --> region2

Cómo optimizar el coste de red

1. Gateway endpoints para S3 y DynamoDB en todas las VPC con subredes privadas: eliminan el procesamiento del NAT (0,048 USD/GB) para ese tráfico.
2. Interface endpoints para otros servicios con mucho tráfico (por ejemplo ECR al descargar imágenes de contenedores): 0,01 USD/GB frente a 0,048 USD/GB del NAT.
3. NAT gateway por AZ cuando el tráfico es alto: además de la disponibilidad, evitas pagar la transferencia entre AZ hasta un NAT de otra AZ. Con tráfico bajo y entornos no productivos, un NAT compartido puede ser más barato (una hora de NAT cuesta lo mismo que 4,8 GB entre AZ).
4. Mantén en la misma AZ los componentes muy «habladores» cuando la disponibilidad lo permita (por ejemplo, un clúster de cálculo en un placement group).
5. Evita el tráfico entre regiones innecesario: replica solo lo imprescindible (CRR de S3, réplicas entre regiones).
6. Usa CloudFront delante de S3, ALB o EC2 para la salida a internet: la transferencia del origen a CloudFront es gratis y la caché reduce la carga del origen.
7. Direct Connect para grandes volúmenes híbridos: la tarifa de salida por DX es inferior a la de internet.
8. Peering en lugar de Transit Gateway para pocas VPC con mucho tráfico: el peering no cobra por GB procesado.
9. IP privadas siempre entre recursos de AWS: si dos instancias de la misma región hablan por sus IP públicas o Elastic IP, se factura como transferencia regional aunque estén en la misma AZ.
10. AWS Global Accelerator frente a CloudFront cuando el tráfico no es cacheable (TCP/UDP): lo verás en el módulo 6.

Revisar cargas existentes (task 4.4)

• AWS Cost Explorer filtrado por usage type (DataTransfer-Regional-Bytes, NatGateway-Bytes, DataTransfer-Out-Bytes…) muestra qué tráfico te cuesta.
• Etiquetas de asignación de costes (cost allocation tags) y la facturación consolidada multicuenta de AWS Organizations permiten repartir el coste de la red compartida (TGW, NAT centralizado).
• AWS Cost and Usage Report para análisis detallado; AWS Budgets para alertas.
• VPC Flow Logs (con Athena) revela quién habla con quién y cuánto: tráfico entre AZ, hacia el NAT, hacia internet.
• Revisa: NAT sin gateway endpoints, IPv4 públicas sin uso, peerings o adjuntos de TGW sin tráfico, réplicas entre regiones innecesarias.

Estrategias de throttling (task 4.4)

La guía también cita «selecting an appropriate throttling strategy». En redes significa limitar la tasa de peticiones para proteger los servicios y el coste:

• Amazon API Gateway: límites de peticiones por segundo y ráfaga, usage plans con cuotas por cliente (módulo 8).
• AWS WAF: reglas rate-based que bloquean IP que superan un umbral (módulo 6).
• Colas (Amazon SQS) para amortiguar picos en lugar de escalar sin límite (módulo 8).
• Cuotas de servicio: dimensionarlas y vigilarlas para no ser limitado por AWS en el peor momento.

Topologías de red: multinivel, híbrida y global

La guía (3.4) pide «creating a network topology for various architectures (for example, global, hybrid, multi-tier)». Estos son los patrones:

Principios de colocación de recursos (3.4, «appropriate placement of resources»):

• Lo que recibe tráfico de internet (ALB, NLB, NAT zonal), en subredes públicas; todo lo demás, en privadas.
• Repartir por al menos dos AZ; para cargas críticas, tres.
• Acercar los recursos al usuario (región adecuada; edge con CloudFront) y a sus dependencias (misma región que la base de datos).
• Para latencia mínima entre instancias: cluster placement group en una AZ (módulo 2).
• Para escalar a futuro: CIDR amplios, subredes de reserva, Transit Gateway en lugar de mallas de peering, endpoints compartidos en una VPC central.

Balanceo de carga en la red (recordatorio)

El módulo 2 trata a fondo Elastic Load Balancing. Lo que tienes que relacionar aquí:

• ALB (capa 7, HTTP/HTTPS) y NLB (capa 4, TCP/UDP/TLS, IP estáticas por AZ) van en subredes públicas si son internet-facing y en privadas si son internos, siempre en varias AZ.
• El NLB es el que se usa para publicar servicios con PrivateLink.
• El Gateway Load Balancer inserta appliances de seguridad de terceros de forma transparente.
• El balanceador reparte entre AZ; si el backend está en otra AZ, ese salto puede tener coste de transferencia entre AZ (revísalo en la página de precios de Elastic Load Balancing).

Trampas típicas del examen

Palabras clave en inglés que aparecen mucho: private subnet, public subnet, outbound-only, stateful/stateless, ephemeral ports, transitive routing, overlapping CIDR, hub-and-spoke, consistent network performance, dedicated connection, encrypted in transit, MOST cost-effective, LEAST operational overhead.

Resumen

• Una VPC es regional; una subred, de una sola AZ. CIDR de /16 a /28; AWS reserva 5 IP por subred.
• Subred pública = ruta 0.0.0.0/0 al internet gateway. Privada = sin esa ruta; sale por NAT gateway.
• Security group: stateful, solo allow, por interfaz de red. NACL: stateless, allow y deny, en orden, por subred.
• NAT gateway zonal: uno por AZ para alta disponibilidad. NAT regional (nov. 2025): se expande solo por las AZ, sin subred pública. NAT instance: heredada, solo por coste mínimo. Para IPv6, egress-only IGW.
• Gateway endpoint (S3, DynamoDB): gratis, por rutas, solo desde la propia VPC. Interface endpoint / PrivateLink: ENI con IP privada, cobra, accesible desde on-premises y VPC emparejadas.
• VPC peering: uno a uno, sin transitividad, sin CIDR solapados, sin edge-to-edge. Transit Gateway: hub transitivo para muchas VPC, VPN y DX.
• Site-to-Site VPN: IPsec sobre internet, minutos, 1,25 Gbps por túnel. Client VPN: personas. Direct Connect: físico, semanas, latencia consistente, sin cifrado por defecto (MACsec o VPN encima); DXGW para varias regiones; resiliencia máxima con dos ubicaciones.
• Costes: entrada gratis; misma AZ gratis; entre AZ 0,01 USD/GB por sentido; entre regiones 0,02 USD/GB; internet 0,09 USD/GB tras 100 GB gratis; NAT 0,048 USD/GB procesado. Gateway endpoints y CloudFront son los grandes ahorradores.
• Network Firewall para inspección gestionada en el perímetro; Flow Logs para auditar el tráfico.

Cobertura del temario

Task statements principales de este módulo: 3.4, 4.4 y la parte de red de 1.2. Los puntos que pertenecen a otros módulos se indican con su módulo dueño.

Task 3.4: Determine high-performing and/or scalable network architectures

Task 4.4: Design cost-optimized network architectures

Task 1.2: Design secure workloads and applications (parte de red)

Practica lo aprendido

Documentación oficial para ampliar

• What is Amazon VPC?
• NAT gateways
• Regional NAT gateways
• Gateway endpoints (Amazon S3 y DynamoDB)
• How VPC peering connections work
• AWS Transit Gateway quotas
• AWS Site-to-Site VPN quotas
• AWS Direct Connect Resiliency Toolkit
• What is AWS Network Firewall?
• Logging IP traffic using VPC Flow Logs
• Whitepaper: Building a Scalable and Secure Multi-VPC Network Infrastructure
• Whitepaper: Hybrid Connectivity
• Amazon VPC pricing