Amazon SAA-C03: Redes y conectividad — Guía de estudio

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Forma parte de la AWS SAA-C03 — Guía de estudio completa. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Diseño de VPC y Planificación de CIDR

Toda VPC comienza con un bloque CIDR, y la elección que se hace en el momento de la creación tiene consecuencias posteriores para el peering, las conexiones de Transit Gateway y la conectividad híbrida. El CIDR primario debe tener entre /16 y /28, ser elegido del espacio RFC 1918 y no debe superponerse con ninguna red con la que se pretenda hacer peering, enrutar a través de un Transit Gateway o alcanzar mediante Direct Connect o VPN. Los CIDR superpuestos son la causa más común de diseños híbridos fallidos porque AWS no puede enrutar entre dos redes que comparten el mismo espacio de direcciones; Transit Gateway aceptará la conexión, pero la propagación fallará o descartará el tráfico silenciosamente.

Cuando una VPC se queda sin espacio de direcciones, no es necesario reconstruirla. Se pueden adjuntar hasta cuatro bloques CIDR IPv4 secundarios (y rangos adicionales de un conjunto más amplio para un total por defecto de cinco, ampliable mediante un aumento de cuota). Los bloques secundarios pueden provenir del mismo rango RFC 1918 o del espacio de direcciones compartido 100.64.0.0/10, lo cual es útil cuando el rango 10.0.0.0/8 se ha agotado o cuando se necesita espacio para NAT de nivel de operador (carrier-grade NAT). Los CIDR secundarios permiten crear nuevas subredes para la expansión —redes de pods de EKS, un nuevo nivel de aplicación— sin tener que volver a numerar las cargas de trabajo existentes.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Un diseño robusto reserva un /17 o /18 para crecimiento futuro, alinea los límites de las subredes con las Zonas de Disponibilidad (un patrón común es un /20 por AZ por nivel de aplicación) y deja un margen para las ENI que consumen los interface endpoints, los NAT gateways y los balanceadores de carga.

Una VPC es un recurso a nivel de región, particionado en subredes, cada una vinculada a una única AZ. La distinción entre «pública» y «privada» es puramente una decisión de enrutamiento: una subred pública tiene una ruta 0.0.0.0/0 → igw-xxxx que apunta a un Internet Gateway, mientras que una subred privada o bien no tiene una ruta por defecto o apunta 0.0.0.0/0 a un dispositivo NAT. Las instancias en una subred pública también necesitan una IP pública o Elástica para ser accesibles desde el exterior; el IGW realiza una NAT 1:1 entre la IP privada y la pública.

NAT Gateways, Instancias NAT y Salida con IPv6

Para el acceso a Internet solo de salida con IPv4 desde subredes privadas, los NAT gateways son el primitivo correcto. Un NAT gateway administrado escala automáticamente hasta 45–100 Gbps, soporta 55.000 conexiones simultáneas por destino único, recibe parches de AWS y es de alta disponibilidad dentro de su AZ. Los NAT gateways se facturan por hora y por GB procesado.

Las instancias NAT —EC2 autoadministradas con la comprobación de origen/destino deshabilitada— son un método obsoleto. Están limitadas por el rendimiento de una única instancia, requieren scripts para la conmutación por error (failover) y se convierten en un cuello de botella bajo carga sostenida. Solo son apropiadas para necesidades atípicas como el filtrado personalizado, e incluso en esos casos, un appliance de Gateway Load Balancer suele ser preferible.

El patrón canónico de alta disponibilidad es un NAT gateway por AZ, cada uno en la subred pública de esa AZ, con una tabla de rutas privada distinta por cada AZ cuya ruta por defecto apunte al NAT gateway local:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Desplegar un único NAT gateway compartido entre Zonas de Disponibilidad es una trampa por dos razones. Primero, es un punto único de fallo: una interrupción en una AZ deja sin salida a Internet a todas las subredes privadas. Segundo, cada paquete de las instancias en otras AZ cruza un límite de AZ, incurriendo en cargos por transferencia de datos entre AZ (actualmente $0.01/GB en cada dirección) además del procesamiento del NAT gateway. En cargas de trabajo que realizan cientos de TB de salida, esto supera con creces el costo de los NAT gateways adicionales. Otro error de configuración frecuente es colocar el propio NAT gateway en una subred privada; en ese caso, no tiene una ruta hacia el IGW y no funciona.

Para IPv6, el NAT no es necesario ni está disponible, ya que toda dirección IPv6 es enrutable globalmente. Para permitir solo la salida con IPv6 y bloquear las conexiones entrantes no solicitadas, adjunte un egress-only internet gateway y enrute ::/0 hacia él desde las subredes privadas. Un IGW normal es bidireccional y expondría las instancias.

Endpoints de VPC: Gateway frente a Interface

Los endpoints de VPC mantienen el tráfico entre tu VPC y los servicios de AWS en la red troncal (backbone) de AWS, evitando por completo internet, los NAT gateways y los internet gateways. Existen dos implementaciones fundamentalmente diferentes, y confundirlas es uno de los errores de arquitectura más comunes.

Los endpoints de tipo gateway existen solo para Amazon S3 y DynamoDB. Son una entrada en la tabla de rutas: una lista de prefijos (por ejemplo, pl-63a5400a para S3 en us-east-1) que apunta al propio endpoint. No hay ENI, ni cambio de DNS, ni costo por hora, ni security group (el acceso se controla mediante la tabla de rutas más la política del endpoint). Debido a que se basan en rutas, solo funcionan para recursos dentro de la VPC; las redes on-premises que acceden a S3 a través de Direct Connect no pueden usarlos.

Los endpoints de tipo interface (AWS PrivateLink) son ENIs con IPs privadas ubicadas en tus subredes, con una facturación por hora por AZ más un costo por GB. Funcionan para casi todos los demás servicios (SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS y cientos más), así como para servicios de terceros publicados como endpoint services. Los endpoints de tipo interface admiten DNS privado, que sobrescribe el nombre de host del servicio público para que se resuelva a la IP privada del endpoint, de modo que los SDK y las CLI no necesiten cambios en el código. Como están respaldados por una ENI, se les aplican los security groups.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

La lógica de costos es importante: cualquier tráfico que sale de una subred privada hacia un servicio público de AWS atraviesa por defecto un NAT gateway a un costo aproximado de 0,045 $/GB. Para una carga de trabajo en contenedores que envía 1 TB por día a S3, la diferencia entre una ruta a través de un NAT gateway y un endpoint de tipo gateway es de miles de dólares al mes. Los endpoints de tipo interface valen la pena cuando reemplazan el egreso a través de NAT a gran escala o cuando el cumplimiento normativo prohíbe el enrutamiento por internet.

Trampas: asociar un security group a un endpoint de tipo gateway (no tienen ENI); suponer que un endpoint de tipo gateway es accesible desde on-premises (no lo es: usa un endpoint de tipo interface o el patrón híbrido EC2 → endpoint de gateway de S3 → ruta de DX separada); deshabilitar el DNS privado en un endpoint de tipo interface y esperar que las llamadas al SDK sin modificar funcionen (accederán al endpoint público a través de internet, anulando por completo el propósito del endpoint); crear un endpoint de tipo gateway pero olvidar asociar la tabla de rutas de la subred privada (el tráfico continúa usando silenciosamente la ruta pública); intentar usar un endpoint de tipo gateway para un servicio que no lo admite (KMS, por ejemplo): solo S3 y DynamoDB son compatibles.

Conectividad entre VPCs: Peering frente a Transit Gateway

El VPC peering es una conexión de Capa 3 uno a uno y no transitiva entre dos VPCs, en la misma o en diferentes cuentas, en la misma o en diferentes Regiones. El tráfico atraviesa la red troncal de AWS, no hay cuellos de botella de ancho de banda y no hay un cargo por hora; solo pagas por la transferencia de datos entre AZs o entre Regiones. Dos propiedades limitan el peering: (1) es no transitivo (si A está conectada con B y B con C, A no puede alcanzar C a través de B); y (2) los rangos CIDR no deben superponerse. Conectar N VPCs en una malla completa (full-mesh) requiere N(N-1)/2 conexiones de peering con ediciones en las tablas de rutas en ambas direcciones de cada una; con 30 VPCs, eso equivale a 435 peerings. Esperar que el peering escale a cientos de VPCs es una trampa.

El Transit Gateway (TGW) es un enrutador de nube regional. Cada VPC, VPN o Direct Connect gateway es un attachment (adjunto), y las tablas de rutas del TGW controlan qué attachment puede alcanzar qué prefijo. Esto convierte una malla de complejidad O(n²) en O(n) attachments y permite topologías de tipo hub-and-spoke, donde una VPC de seguridad aloja firewalls que inspeccionan todo el tráfico entre VPCs. El TGW admite enrutamiento transitivo, termina de forma nativa las asociaciones de VPN y Direct Connect gateway, y se puede compartir entre cuentas de AWS Organizations a través de Resource Access Manager para que los equipos centrales de redes controlen el enrutamiento mientras que las cuentas de las cargas de trabajo son propietarias de las VPCs. El TGW añade una tarifa por hora por cada attachment y un costo aproximado de 0,02 $/GB procesado.

Para la conectividad entre Regiones, el TGW peering conecta TGWs en diferentes Regiones a través de la red troncal global de AWS con tráfico cifrado: un TGW por Región, conectados en un diseño de malla o hub. Esto evita el problema de N al cuadrado entre Regiones que el VPC peering entre Regiones reintroduce.

La higiene de las tablas de rutas es el asesino silencioso aquí. Crear una conexión de peering o un attachment de TGW no hace nada hasta que se añaden rutas CIDR explícitas en las tablas de rutas de las subredes de ambas VPCs que apunten al destino pcx- o tgw-, y los security groups permitan el tráfico. Los fallos de conectividad silenciosos casi siempre se deben a una ruta faltante o a una denegación implícita en un security group que hace referencia al CIDR de origen incorrecto.

Conectividad Híbrida: Site-to-Site VPN vs. Direct Connect

La elección entre Site-to-Site VPN y Direct Connect es una compensación entre la velocidad de despliegue y la encriptación integrada por un lado, y la baja latencia constante, el ancho de banda dedicado y un rendimiento predecible por el otro.

Site-to-Site VPN establece dos túneles IPsec entre un customer gateway (router local) y un Virtual Private Gateway o un Transit Gateway. Cada túnel tiene un límite de aproximadamente 1.25 Gbps. El tráfico se encripta en la capa de red, cumpliendo los requisitos de encriptación en las capas de red y sesión cuando se combina con TLS. Atraviesa la internet pública, por lo que la latencia y el jitter son variables, pero está disponible en minutos y cuesta céntimos por hora. Úselo cuando se necesite conectividad de inmediato, cuando el ancho de banda sea modesto o como una ruta de respaldo.

Direct Connect (DX) proporciona una conexión de fibra dedicada (1, 10 o 100 Gbps) desde un router local hasta una ubicación de AWS Direct Connect. Evita la internet pública, lo que produce una latencia constante y un mayor rendimiento. El precio de egreso de DX es sustancialmente más bajo que el egreso a internet, lo cual es importante cuando se mueven cientos de gigabytes por día. El aprovisionamiento tarda semanas: cross-connects, LOAs, configuración de BGP.

Aquí predominan dos errores comunes. Primero, Direct Connect por sí solo no encripta el tráfico. Un circuito privado no es un canal protegido criptográficamente. Para satisfacer un requisito de encriptación sobre DX, implemente una Site-to-Site VPN por encima, o use MACsec para encriptación de Capa 2 en puertos dedicados compatibles. Segundo, una conexión DX básica no enruta por sí misma a múltiples VPCs. Una VIF privada se conecta a un único Virtual Private Gateway asociado a una única VPC. Para alcanzar muchas VPCs —especialmente entre cuentas y Regiones— use un Direct Connect Gateway asociado con un Transit Gateway a través de una VIF de tránsito, y conecte cada VPC al TGW:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

El patrón canónico de producción utiliza dos conexiones DX en dos ubicaciones de DX que terminan en routers de cliente separados, con Site-to-Site VPN como failover automático de BGP: el AS-path prepending o MED de BGP dirige el tráfico a DX mientras está activo; si falla, BGP retira las rutas de DX y la VPN toma el control.

Balanceadores de Carga: ALB, NLB y GWLB

ALB es de Capa 7 y entiende la semántica de HTTP: enrutamiento por host y ruta, WebSockets, redirecciones, sesiones persistentes basadas en cookies. Es la herramienta incorrecta para cualquier cosa que no sea HTTP: MQTT, TCP puro, syslog sobre UDP, SMTP. ALB utiliza direccionamiento basado en DNS con IPs que cambian con el tiempo; no se le pueden asignar Elastic IPs. Cuando los clientes necesitan incluir en una lista blanca las IPs de destino, un ALB por sí solo no es adecuado; use un NLB con EIPs, o ponga un Global Accelerator con sus dos IPs estáticas anycast delante del ALB. “Simplemente resuelva el DNS del ALB una vez y fije las IPs en las reglas del firewall” es un error común: AWS las cambia sin previo aviso.

NLB es de Capa 4 y escala a millones de flujos por segundo. Conserva la IP de origen real del cliente por defecto (los destinos ven al cliente real), admite la asignación de una Elastic IP estática por AZ y maneja cargas de trabajo TCP/UDP de alto rendimiento. Históricamente, el NLB no admitía grupos de seguridad en el propio balanceador de carga; los CIDRs de los clientes debían permitirse directamente en el SG del destino. AWS añadió grupos de seguridad opcionales para NLB en 2023, pero muchos diseños todavía asumen el comportamiento clásico.

El patrón canónico de cara al público es:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Hacer referencia al grupo de seguridad del ALB como origen en el backend —en lugar de un CIDR— es el patrón de mínimo privilegio y cubre automáticamente el tráfico de los health checks, que se origina en las ENIs del ALB. El ALB en sí mismo reside en subredes públicas en al menos dos AZs (con rutas a un IGW); los destinos residen en subredes privadas. Colocar un ALB con acceso a internet en una subred privada es una configuración errónea clásica: el registro de destinos tiene éxito, pero los clientes no pueden alcanzarlo.

Gateway Load Balancer (GWLB) está diseñado específicamente para la inserción transparente de appliances virtuales de terceros (firewalls, IDS/IPS, DPI). Opera en la Capa 3, reenviando todos los protocolos IP usando encapsulación GENEVE sobre UDP 6081. El tráfico llega al GWLB a través de un endpoint de GWLB (GWLBe), un interface endpoint que se encuentra en una subred y aparece en las tablas de rutas como un destino:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

El endpoint reenvía los paquetes a través de PrivateLink al GWLB, que balancea la carga entre la flota de appliances usando persistencia de flujo para que ambas direcciones de un flujo lleguen al mismo appliance. En un diseño de inspección hub-and-spoke, las VPCs spoke se conectan a un TGW cuyas tablas de rutas fuerzan el tráfico este-oeste a pasar por la VPC de inspección (que contiene el GWLB y los appliances) antes de llegar a las VPCs de destino. La inspección de entrada utiliza tablas de rutas de borde (edge) que redirigen el tráfico de IGW a la capa web a través del GWLBe primero:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Esta es la respuesta correcta para la inspección centralizada y entre cuentas; crear una solución propia con EC2, modificaciones personalizadas en las tablas de rutas y scripts de failover reinventa lo que GWLB proporciona de forma nativa.

PrivateLink para servicios de consumidor a proveedor

Además de potenciar los endpoints de interfaz para los servicios de AWS, PrivateLink habilita la conectividad privada a servicios publicados por terceros u otras cuentas de AWS. El proveedor coloca su servicio detrás de un NLB y crea un servicio de endpoint de VPC (VPC endpoint service). Los consumidores crean endpoints de interfaz (interface endpoints) en sus propias VPC que apuntan a él.

La regla de direccionalidad crítica es: la conexión siempre se inicia desde el consumidor hacia el proveedor. El proveedor no puede iniciar conexiones hacia la VPC del consumidor. El tráfico nunca toca internet, solo el servicio de destino específico es accesible (no toda la VPC del proveedor, como con el peering), y no surgen problemas de superposición de CIDR porque solo se exponen las IP de los endpoints en cada lado. Esta es la respuesta canónica para un patrón de acceso a una base de datos de un proveedor o SaaS donde la VPC del consumidor no tiene IGW, ni VPN, ni Direct Connect. El VPC peering expone rangos CIDR completos y requiere IP que no se superpongan; un adjunto de TGW (TGW attachment) enruta de forma amplia; una API pública a través de internet no es privada.

Global Accelerator y Route 53

AWS Global Accelerator asigna dos direcciones IPv4 estáticas anycast que se anuncian desde las ubicaciones de borde (edge locations) de AWS en todo el mundo. El tráfico del cliente entra por el borde más cercano y viaja por la red troncal (backbone) de AWS hasta el endpoint regional sano más próximo (ALB, NLB, EIP o EC2). Esto resuelve dos problemas a la vez: IP estáticas frente a los ALB (solucionando el problema de las listas blancas o whitelisting), y una reducción de la fluctuación (jitter) y la latencia para usuarios distribuidos globalmente al acortar el camino por la internet pública. Acelera el tráfico TCP/UDP no almacenable en caché hacia los orígenes donde CloudFront (que almacena contenido en caché) no es aplicable.

Route 53 resuelve un problema diferente: la dirección del tráfico a nivel de DNS. Global Accelerator afecta al plano de datos en sí; Route 53 solo afecta a la resolución de DNS, después de lo cual la conexión TCP va a donde sea que resida la IP resuelta. Ambos se combinan con frecuencia: un alias de Route 53 apunta a un Global Accelerator que se encuentra frente a los ALB regionales.

Políticas de enrutamiento de Route 53:

La latencia y la geolocalización se confunden con frecuencia: la latencia minimiza el RTT percibido por el usuario; la geolocalización impone la residencia de los datos independientemente de la latencia. El failover multirregional requiere chequeos de salud en el primario. Los registros de alias (Alias records) son específicos de AWS, se resuelven directamente a endpoints de ALB, NLB, CloudFront, sitios web de S3 y API Gateway sin costo por consulta y, a diferencia de los CNAME, funcionan en el ápice de la zona (zone apex).

Route 53 Resolver responde a las consultas de DNS dentro de una VPC a través de la dirección .2 (base del CIDR de la VPC + 2). Para DNS híbrido, los endpoints de entrada (inbound endpoints) permiten que los resolutores on-premises consulten zonas alojadas privadas en AWS; los endpoints de salida (outbound endpoints) con reglas de reenvío permiten que los recursos de la VPC resuelvan nombres on-premises. Sin estos, las instancias EC2 no pueden resolver corp.internal y los servidores on-prem no pueden resolver db.prod.internal, una ruptura sutil que solo aparece cuando las aplicaciones comienzan a realizar búsquedas entre entornos. Los endpoints de interfaz requieren Habilitar DNS privado (Enable Private DNS) para que las llamadas del SDK lleguen a la ENI del endpoint; sin esto, las llamadas aún llegan al endpoint público a través de internet, anulando su propósito.

Grupos de seguridad, NACL y mínimo privilegio

Los grupos de seguridad son stateful (con estado): el tráfico de retorno se permite automáticamente y actúan a nivel de la ENI. Las NACL son stateless (sin estado) y actúan en el límite de la subred. Cualquier regla TCP en una NACL requiere una regla explícita de entrada y de salida; debido a que los clientes eligen un puerto de origen del rango efímero, la regla de dirección de retorno debe permitir los puertos 1024–65535 (Linux usa 32768–60999 por defecto; el rango más amplio cubre Windows y otras pilas). Olvidar la regla de retorno efímera es una causa clásica de conexiones que completan el SYN pero se quedan colgadas esperando la respuesta.

Para el mínimo privilegio entre capas, las reglas de los grupos de seguridad deben hacer referencia a otros ID de grupos de seguridad, no a CIDR. Esto escala con Auto Scaling y evita las frágiles listas blancas de IP:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

Las NACL son un control de radio de explosión (blast radius) burdo, no un sustituto de los grupos de seguridad. Restringir las NACL “para defensa en profundidad” sin cambios correspondientes en los grupos de seguridad comúnmente rompe los flujos iniciados desde el exterior, como las actualizaciones de yum/apt a través de un NAT gateway, porque el tráfico de retorno sin estado se descarta silenciosamente. Las tablas de rutas determinan en última instancia la alcanzabilidad: incluso un grupo de seguridad permisivo no puede entregar tráfico si la tabla de rutas carece de una entrada para el destino y, a la inversa, un endpoint de gateway solo es efectivo cuando la ruta de la lista de prefijos de S3 está realmente instalada en las tablas de rutas de las subredes que alojan la carga de trabajo.

Referencia para Decisiones

← Transferencia y migración de datos · Todos los dominios · Entrega de contenido →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →