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

By Laurynas Brazys · 15 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

Cada VPC comienza con un bloque CIDR, y la elección realizada en el momento de la creación tiene consecuencias posteriores para el emparejamiento (peering), las conexiones de Transit Gateway y la conectividad híbrida. El CIDR principal debe estar entre /16 y /28, elegido del espacio RFC 1918, y no debe superponerse con ninguna red con la que se pretenda establecer peering, enrutar a través de un Transit Gateway o alcanzar a través de Direct Connect o VPN. Los CIDR superpuestos son la causa más común de diseños híbridos defectuosos porque AWS no puede enrutar entre dos redes que comparten espacio de direcciones; Transit Gateway aceptará la conexión, pero la propagación fallará o el tráfico se perderá 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 grupo más amplio para un total predeterminado de cinco, extensible mediante un aumento de cuota). Los bloques secundarios pueden provenir del mismo rango RFC 1918 o del espacio de direcciones compartidas 100.64.0.0/10, lo cual es útil cuando 10.0.0.0/8 se ha agotado o cuando se necesita espacio NAT de grado de operador. Los CIDR secundarios permiten crear nuevas subredes para la expansión (redes de pods de EKS, una nueva capa) sin renumerar 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 el crecimiento futuro, alinea los límites de las subredes con las Zonas de Disponibilidad (un /20 por AZ por capa es un patrón común) y deja espacio para las ENI consumidas por los puntos finales de interfaz, las puertas de enlace NAT y los balanceadores de carga.

Una VPC es un constructo regional 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 no tiene ruta predeterminada 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 de entrada; el IGW realiza NAT 1:1 entre la IP privada y la pública.

NAT Gateways, NAT Instances e IPv6 Egress

Para el acceso a Internet IPv4 solo de salida desde subredes privadas, las puertas de enlace NAT (NAT gateways) son la primitiva correcta. Una puerta de enlace NAT administrada escala automáticamente a 45-100 Gbps, admite 55,000 conexiones simultáneas por destino único, es parcheada por AWS y es de alta disponibilidad dentro de su AZ. Las puertas de enlace NAT se facturan por hora y por GB procesado.

Las instancias NAT —EC2 autoadministradas con la verificación de origen/destino deshabilitada— son heredadas. Están limitadas por el rendimiento de una sola instancia, deben ser programadas para la conmutación por error y se convierten en un cuello de botella bajo carga sostenida. Son apropiadas solo para necesidades atípicas como el filtrado personalizado, e incluso entonces, un dispositivo Gateway Load Balancer suele ser preferible.

El patrón canónico de alta disponibilidad es una puerta de enlace NAT por AZ, cada una en la subred pública de esa AZ, con una tabla de rutas privada distinta por AZ cuya ruta predeterminada apunta a la puerta de enlace NAT 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 una única puerta de enlace NAT compartida entre AZs es una trampa por dos razones. Primero, es un punto único de fallo: una interrupción de AZ desactiva la salida para cada subred privada. Segundo, cada paquete de instancias en otras AZs cruza un límite de AZ, incurriendo en cargos de transferencia de datos entre AZs (actualmente $0.01/GB en cada sentido) además del procesamiento de la puerta de enlace NAT. En cargas de trabajo que realizan cientos de TB de salida, esto empequeñece el costo de las puertas de enlace NAT adicionales. Una segunda configuración errónea frecuente es colocar la propia puerta de enlace NAT en una subred privada; entonces no tiene ruta al IGW y no funciona.

Para IPv6, NAT no es necesario ni está disponible porque cada dirección IPv6 es enrutable globalmente. Para permitir IPv6 solo de salida mientras se bloquea la entrada no solicitada, adjunte un internet gateway de solo salida y enrute ::/0 a él desde subredes privadas. Un IGW regular es bidireccional y expondría las instancias.

Puntos de conexión de VPC: Gateway vs. Interface

Los puntos de conexión de VPC mantienen el tráfico entre su VPC y los servicios de AWS en la red troncal de AWS, evitando por completo Internet, las puertas de enlace NAT y las puertas de enlace a Internet. Existen dos implementaciones fundamentalmente diferentes, y confundirlas es uno de los errores arquitectónicos más comunes.

Los puntos de conexión de 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 punto de conexión. No hay ENI, no hay cambio de DNS, no hay costo por hora y no hay grupo de seguridad (el acceso se controla mediante la tabla de rutas más la política del punto de conexión). Debido a que se basan en rutas, solo funcionan para recursos dentro de la VPC; las redes locales que acceden a S3 a través de Direct Connect no pueden usarlos.

Los puntos de conexión de interfaz (AWS PrivateLink) son ENI con IP privadas ubicadas en sus subredes, facturadas por hora por AZ más 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 servicios de punto de conexión. Los puntos de conexión de interfaz admiten DNS privado, que anula el nombre de host del servicio público para resolver la IP privada del punto de conexión, de modo que los SDK y las CLI no necesitan cambios de código. Debido a que están respaldados por ENI, se aplican los grupos de seguridad.

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 importa: cualquier tráfico que sale de una subred privada a un servicio público de AWS atraviesa por defecto una puerta de enlace NAT a aproximadamente $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 de puerta de enlace NAT y un punto de conexión de gateway es de miles de dólares al mes. Los puntos de conexión de interfaz valen la pena cuando reemplazan la salida de NAT a escala o cuando el cumplimiento prohíbe el enrutamiento por Internet.

Trampas: adjuntar un grupo de seguridad a un punto de conexión de gateway (no tienen ENI); asumir que un punto de conexión de gateway es accesible desde el entorno local (no lo es, use un punto de conexión de interfaz o el patrón híbrido EC2 → punto de conexión de gateway S3 → ruta DX separada); deshabilitar el DNS privado en un punto de conexión de interfaz y esperar que las llamadas SDK sin modificar funcionen (llegarán al punto de conexión público a través de Internet, anulando completamente el punto de conexión); crear un punto de conexión de gateway pero olvidarse de asociar la tabla de rutas de la subred privada (el tráfico continúa usando silenciosamente la ruta pública); intentar usar un punto de conexión de gateway para un servicio que no tiene un punto de conexión de gateway (KMS, por ejemplo), solo S3 y DynamoDB califican.

Conectividad entre VPC: Peering vs. Transit Gateway

El peering de VPC es una conexión uno a uno, no transitiva de Capa 3 entre dos VPC, de la misma o diferente cuenta, de la misma o diferente Región. El tráfico atraviesa la red troncal de AWS, no hay cuello de botella de ancho de banda y no hay cargo por hora; solo paga por la transferencia de datos entre AZ o entre Regiones. Dos propiedades limitan el peering: (1) es no transitivo: si A se empareja con B y B se empareja con C, A no puede llegar a C a través de B; y (2) los rangos CIDR no deben superponerse. Conectar N VPC en malla completa requiere N(N-1)/2 peerings con ediciones de tabla de rutas en ambas direcciones de cada uno; con 30 VPC, eso son 435 peerings. Esperar que el peering escale a cientos de VPC es una trampa.

Transit Gateway (TGW) es un enrutador en la nube regional. Cada VPC, VPN o puerta de enlace de Direct Connect es un adjunto, y las tablas de rutas de TGW controlan qué adjunto puede alcanzar qué prefijo. Esto convierte una malla O(n²) en O(n) adjuntos y permite topologías de tipo hub-and-spoke donde una VPC de seguridad aloja firewalls que inspeccionan todo el tráfico entre VPC. TGW admite enrutamiento transitivo, termina de forma nativa las asociaciones de VPN y puerta de enlace de Direct Connect, y se puede compartir entre organizaciones de AWS a través de Resource Access Manager para que los equipos de redes centrales controlen el enrutamiento mientras las cuentas de carga de trabajo poseen las VPC. TGW agrega una tarifa por hora por adjunto y aproximadamente $0.02/GB procesado.

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

La higiene de la tabla de rutas es el asesino silencioso aquí. Crear una conexión de peering o un adjunto de TGW no hace nada hasta que se agregan rutas CIDR explícitas en las tablas de rutas de subred de ambas VPC que apuntan al destino pcx- o tgw-, y los grupos de seguridad permiten el tráfico. Las fallas de conectividad silenciosas casi siempre se remontan a una ruta faltante o una denegación implícita en un grupo de seguridad 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 implementación más el cifrado incorporado, por un lado, y la baja latencia consistente, el ancho de banda dedicado y el rendimiento predecible, por el otro.

Site-to-Site VPN establece dos túneles IPsec entre un gateway de cliente (router on-prem) 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 cifra en la capa de red, satisfaciendo los requisitos de cifrado en las capas de red y sesión cuando se combina con TLS. Atraviesa la internet pública, por lo que la latencia y la fluctuación son variables, pero está disponible en minutos y cuesta centavos por hora. Úselo cuando la conectividad se necesite de inmediato, cuando el ancho de banda sea modesto o como ruta de respaldo.

Direct Connect (DX) proporciona una conexión de fibra dedicada (1, 10 o 100 Gbps) desde un router on-premises a una ubicación de AWS Direct Connect. Evita la internet pública, lo que produce una latencia consistente y un mayor rendimiento. El precio de salida de DX es sustancialmente más bajo que el de salida de internet, lo que importa al mover cientos de gigabytes por día. El aprovisionamiento lleva semanas: interconexiones, LOAs, configuración BGP.

Aquí dominan dos trampas. Primero, Direct Connect por sí solo no cifra el tráfico. Un circuito privado no es un canal criptográficamente protegido. Para satisfacer un requisito de cifrado sobre DX, superponga una Site-to-Site VPN, o use MACsec para el cifrado de Capa 2 en puertos dedicados compatibles. Segundo, una conexión DX pura no enruta por sí misma a múltiples VPCs. Una VIF privada se conecta a un solo Virtual Private Gateway adjunto a una sola VPC. Para llegar a 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 adjunte cada VPC al TGW:

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

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

Balanceadores de carga: ALB, NLB y GWLB

ALB es de Capa 7 y comprende la semántica 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 IPs elásticas. Cuando los clientes incluyen IPs de destino en una lista blanca, un ALB por sí solo no es adecuado; use NLB con EIPs, o coloque Global Accelerator con sus dos IPs anycast estáticas delante del ALB. “Simplemente resuelva el DNS del ALB una vez y fije las IPs en las reglas del firewall” es una trampa: AWS las cambia sin previo aviso.

NLB es de Capa 4 y escala a millones de flujos por segundo. Preserva la IP de origen real del cliente por defecto (los destinos ven al cliente real), admite la asignación de una IP elástica estática por AZ, y maneja cargas de trabajo TCP/UDP de alto rendimiento. Históricamente, 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 NLB opcionales en 2023, pero muchos diseños aún 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

Referenciar el grupo de seguridad del ALB como origen en el backend, en lugar de un CIDR, es el patrón de menor privilegio y cubre automáticamente el tráfico de verificación de estado, que se origina en las ENIs del ALB. El propio ALB reside en subredes públicas en al menos dos AZs (rutas a IGW); los destinos residen en subredes privadas. Colocar un ALB con acceso a internet en una subred privada es una mala configuración clásica: el registro del destino tiene éxito, pero los clientes no pueden alcanzarlo.

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

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

El punto final reenvía paquetes a través de PrivateLink al GWLB, que balancea la carga entre la flota de dispositivos utilizando la persistencia de flujo para que ambas direcciones de un flujo lleguen al mismo dispositivo. En un diseño de inspección hub-and-spoke, las VPCs spoke se conectan a un TGW cuyas tablas de enrutamiento fuerzan el tráfico este-oeste a través de la VPC de inspección (que contiene el GWLB y los dispositivos) antes de llegar a las VPCs de destino. La inspección de entrada utiliza tablas de enrutamiento de borde 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; la implementación casera con EC2, hacks de tablas de enrutamiento personalizados y scripts de conmutación por error reinventa lo que GWLB proporciona de forma nativa.

PrivateLink para servicios de consumidor a proveedor

Además de potenciar los puntos de conexión de interfaz para los servicios de AWS, PrivateLink permite 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 punto de conexión de VPC. Los consumidores crean puntos de conexión de interfaz en sus propias VPC que lo tienen como objetivo.

La regla direccional crítica: la conexión siempre se inicia desde el consumidor hacia el proveedor. El proveedor no puede iniciar conexiones en 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 emparejamiento), y no surgen problemas de superposición de CIDR porque solo se exponen las IP de los puntos de conexión en cada lado. Esta es la respuesta canónica para un patrón de acceso a bases de datos de SaaS o de proveedores donde la VPC del consumidor no tiene IGW, VPN ni Direct Connect. El emparejamiento de VPC expone rangos CIDR completos y requiere IP no superpuestas; un adjunto de TGW enruta ampliamente; una API pública a través de Internet no es privada.

Global Accelerator y Route 53

AWS Global Accelerator asigna dos direcciones IPv4 anycast estáticas anunciadas desde las ubicaciones de borde de AWS en todo el mundo. El tráfico del cliente ingresa al borde más cercano y viaja por la red troncal de AWS hasta el punto de conexión regional saludable más cercano (ALB, NLB, EIP o EC2). Esto resuelve dos problemas a la vez: IP estáticas frente a los ALB (solucionando la brecha de la lista blanca) y reducción de la fluctuación/latencia para usuarios distribuidos globalmente al acortar el acceso a Internet público. Acelera el tráfico TCP/UDP no almacenable en caché a orígenes donde CloudFront (que almacena contenido en caché) no es aplicable.

Route 53 resuelve un problema diferente: el enrutamiento de tráfico a nivel de DNS. Global Accelerator afecta el plano de datos en sí; Route 53 afecta solo la resolución de DNS, después de lo cual la conexión TCP va a donde reside 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 datos independientemente de la latencia. La conmutación por error multirregional requiere comprobaciones de estado en el primario. Los registros de alias son específicos de AWS, se resuelven directamente en ALB, NLB, CloudFront, sitios web de S3 y puntos de conexión de API Gateway sin cargo por consulta, y, a diferencia de los CNAME, funcionan en el ápice de la zona.

Route 53 Resolver responde a las consultas de DNS dentro de una VPC a través de la dirección .2 (CIDR base de la VPC + 2). Para DNS híbrido, los puntos de conexión de entrada permiten que los resolvedores locales consulten zonas alojadas privadas en AWS; los puntos de conexión de salida con reglas de reenvío permiten que los recursos de la VPC resuelvan nombres locales. Sin estos, las instancias EC2 no pueden resolver corp.internal y los servidores locales no pueden resolver db.prod.internal, una ruptura sutil que solo aparece cuando las aplicaciones comienzan a realizar búsquedas entre entornos. Los puntos de conexión de interfaz requieren Habilitar DNS privado para que las llamadas del SDK lleguen al ENI del punto de conexión; sin él, las llamadas aún llegan al punto de conexión público a través de Internet, lo que anula el propósito.

Grupos de seguridad, NACL y privilegio mínimo

Los grupos de seguridad son stateful (el tráfico de retorno se permite automáticamente) y actúan a nivel de ENI. Las NACL son stateless y actúan en el límite de la subred. Cualquier regla TCP en una NACL requiere una regla explícita de entrada y 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 SYN pero se cuelgan en la respuesta.

Para el privilegio mínimo entre niveles, las reglas del grupo de seguridad deben hacer referencia a otras ID de grupo de seguridad, no a CIDR. Esto se escala con Auto Scaling y evita listas blancas de IP frágiles:

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 grueso, no un sustituto de los grupos de seguridad. Endurecer las NACL “para defensa en profundidad” sin cambios coincidentes en los grupos de seguridad comúnmente rompe los flujos iniciados por salida, como las actualizaciones de yum/apt a través de una puerta de enlace NAT, porque el tráfico de retorno sin estado se descarta silenciosamente. Las tablas de enrutamiento determinan en última instancia la accesibilidad: incluso un grupo de seguridad permisivo no puede entregar tráfico si la tabla de enrutamiento carece de una entrada para el destino, y, a la inversa, un punto de conexión de puerta de enlace solo es efectivo cuando la ruta de la lista de prefijos de S3 se instala realmente en las tablas de enrutamiento de las subredes que alojan la carga de trabajo.

Referencia de decisión

← Transferencia y Migración de Datos · Todos los dominios · Entrega de Contenido →

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

Explorar Amazon →