Anatomia y funcionamientio de la VPC

Clase 22 de 76 • Curso de AWS Certified Solutions Architect Associate

Clase anteriorSiguiente clase

Anatomía y Funcionamiento de la VPC: El Fundamento de la Red en AWS

En 2018, Nexiabank sufrió una brecha de seguridad que expuso datos de millones de clientes. La investigación posterior reveló que el incidente ocurrió porque sus bases de datos estaban desplegadas en subredes públicas directamente accesibles desde Internet. Tras rediseñar su arquitectura de VPC con subredes privadas, NAT Gateways y controles de acceso estrictos, no solo mejoraron su postura de seguridad, sino que también optimizaron sus costos de transferencia de datos en un 40% y redujeron la latencia de sus aplicaciones. Este caso ilustra por qué entender la anatomía y el funcionamiento de la VPC es fundamental para cualquier arquitecto de soluciones en AWS.

image.png

Subnets Públicas vs. Privadas, Route Tables y CIDR Blocks

La Virtual Private Cloud (VPC) es el bloque fundamental de redes en AWS, proporcionando un segmento de red aislado y personalizable.

CIDR Blocks

Cada VPC se define mediante un bloque CIDR (Classless Inter-Domain Routing):

  • Define el rango de direcciones IP disponibles
  • Utiliza notación x.x.x.x/y donde /y es la máscara de red
  • Tamaño mínimo: /28 (16 direcciones IP)
  • Tamaño máximo: /16 (65,536 direcciones IP)
# Ejemplos de bloques CIDR
10.0.0.0/16    # 65,536 direcciones (10.0.0.0 - 10.0.255.255)
172.16.0.0/20  # 4,096 direcciones (172.16.0.0 - 172.16.15.255)
192.168.0.0/24 # 256 direcciones (192.168.0.0 - 192.168.0.255)

Nota importante: De cada bloque CIDR, AWS reserva 5 direcciones IP para uso interno (primera, última y tres adicionales), por lo que el número real de direcciones utilizables es ligeramente menor.

Subnets

Las subnets son subdivisiones de una VPC:

  • Cada subnet existe dentro de una única Availability Zone
  • Tiene su propio bloque CIDR que es un subconjunto del CIDR de la VPC
  • No pueden solaparse entre sí

Subnets Públicas

Las subnets públicas:

  • Tienen una ruta directa a Internet a través de un Internet Gateway
  • Recursos con IPs públicas son accesibles directamente desde Internet
  • Típicamente alojan balanceadores de carga, bastiones y aplicaciones web

Subnets Privadas

Las subnets privadas:

  • No tienen ruta directa a Internet
  • Los recursos solo son accesibles desde dentro de la VPC o a través de conexiones privadas
  • Típicamente alojan bases de datos, servidores de aplicaciones y sistemas de backend

Route Tables

Las tablas de rutas controlan el tráfico de red:

  • Cada subnet debe estar asociada a una tabla de rutas
  • Contienen reglas (rutas) que determinan dónde se dirige el tráfico
  • La ruta local (dentro de la VPC) siempre está presente y no se puede eliminar

Ejemplo de tabla de rutas para subnet pública

Ejemplo de tabla de rutas para subnet privada

Internet Gateway, NAT Gateway/Instance, y VPC Peering

Internet Gateway (IGW)

El Internet Gateway es un componente horizontal, redundante y escalable:

  • Permite la comunicación bidireccional entre recursos en la VPC e Internet
  • Se adjunta a nivel de VPC, no de subnet
  • Es necesario para que las subnets sean públicas
  • No tiene costo adicional

image.png

# Crear un Internet Gateway y adjuntarlo a una VPC
aws ec2 create-internet-gateway --output text
# Salida: igw-1234567890abcdef0

aws ec2 attach-internet-gateway --internet-gateway-id igw-1234567890abcdef0 --vpc-id vpc-0987654321fedcba0

NAT Gateway / NAT Instance

Los dispositivos NAT (Network Address Translation) permiten que instancias en subnets privadas accedan a Internet:

NAT Gateway

  • Servicio gestionado por AWS
  • Alta disponibilidad dentro de una AZ
  • Escalado automático hasta 45 Gbps
  • Requiere una dirección IP elástica
  • Tiene costo por hora y por GB de datos procesados

image.png

# Crear un NAT Gateway en una subnet pública
aws ec2 create-nat-gateway --subnet-id subnet-public-12345 --allocation-id eipalloc-12345

NAT Instance

  • Instancia EC2 configurada como NAT
  • Requiere gestión manual (parches, escalado, etc.)
  • Menor costo pero menor disponibilidad
  • Puede servir también como bastion host

Concepto de AZ (Availability Zone) y Región en la VPC

Relación con VPC

  • Una VPC abarca todas las AZs de una región
  • Las subnets existen en una única AZ
  • Para alta disponibilidad, se deben distribuir recursos en múltiples AZs
# Estructura típica de una VPC con alta disponibilidad
VPC: 10.0.0.0/16 (Región us-east-1)
  |
  |-- Subnet pública: 10.0.1.0/24 (AZ us-east-1a)
  |-- Subnet privada: 10.0.2.0/24 (AZ us-east-1a)
  |
  |-- Subnet pública: 10.0.3.0/24 (AZ us-east-1b)
  |-- Subnet privada: 10.0.4.0/24 (AZ us-east-1b)
  |
  |-- Subnet pública: 10.0.5.0/24 (AZ us-east-1c)
  |-- Subnet privada: 10.0.6.0/24 (AZ us-east-1c)

Consideraciones de Diseño Multi-AZ

  • Balanceadores de carga: Distribuyen tráfico entre múltiples AZs
  • Auto Scaling Groups: Pueden distribuir instancias entre AZs
  • Bases de datos RDS: Pueden tener réplicas en diferentes AZs
  • Costos: No hay cargo por transferencia de datos entre AZs dentro de la misma VPC, pero sí hay costos por transferencia entre AZs para ciertos servicios como RDS

Default VPC vs. VPC Custom y Buenas Prácticas

Default VPC

Cada cuenta de AWS viene con una VPC predeterminada en cada región:

  • CIDR: 172.31.0.0/16
  • Subnets públicas en cada AZ
  • Internet Gateway adjunto
  • Tabla de rutas con ruta a Internet
  • Grupo de seguridad default
  • DHCP options configuradas

Limitaciones de la Default VPC:

  • No se puede cambiar el CIDR
  • Todas las subnets son públicas
  • Estructura predefinida que puede no ser óptima
  • Menos control sobre la segmentación

Custom VPC

Las VPCs personalizadas ofrecen control total:

  • Elección del rango CIDR
  • Diseño personalizado de subnets
  • Control granular sobre tablas de rutas
  • Implementación de múltiples capas de seguridad
  • Integración con servicios on-premise

Buenas Prácticas de Configuración

  1. Planificación del CIDR:
    • Usar rangos privados (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
    • Evitar solapamientos con otras redes corporativas
    • Reservar espacio para crecimiento futuro
  2. Diseño de Subnets:
    • Crear subnets en múltiples AZs para alta disponibilidad
    • Separar subnets por función (web, aplicación, datos)
    • Asignar CIDRs de tamaño adecuado para cada subnet
  3. Seguridad por Capas:
    • Usar Network ACLs para control de acceso a nivel de subnet
    • Implementar grupos de seguridad para control a nivel de instancia
    • Colocar recursos sensibles en subnets privadas
  4. Conectividad:
    • Usar NAT Gateways redundantes (uno por AZ)
    • Implementar VPC Endpoints para servicios AWS
    • Considerar Transit Gateway para topologías complejas
  5. Monitoreo y Logging:
    • Habilitar VPC Flow Logs
    • Configurar alertas para tráfico inusual
    • Revisar periódicamente reglas de seguridad
# Estructura recomendada para una VPC personalizada
VPC: 10.0.0.0/16
  |
  |-- Tier público (DMZ)
  |   |-- 10.0.1.0/24 (AZ-a) - ALB, bastiones
  |   |-- 10.0.2.0/24 (AZ-b) - ALB, bastiones
  |   |-- 10.0.3.0/24 (AZ-c) - ALB, bastiones
  |
  |-- Tier de aplicación
  |   |-- 10.0.11.0/24 (AZ-a) - Servidores web, aplicaciones
  |   |-- 10.0.12.0/24 (AZ-b) - Servidores web, aplicaciones
  |   |-- 10.0.13.0/24 (AZ-c) - Servidores web, aplicaciones
  |
  |-- Tier de datos
      |-- 10.0.21.0/24 (AZ-a) - Bases de datos, caches
      |-- 10.0.22.0/24 (AZ-b) - Bases de datos, caches
      |-- 10.0.23.0/24 (AZ-c) - Bases de datos, caches

Métodos de Expansión (CIDR IPv4, IPv6)

A medida que las aplicaciones crecen, puede ser necesario expandir la capacidad de direccionamiento de la VPC.

Expansión de CIDR IPv4

Desde 2017, AWS permite añadir bloques CIDR secundarios a una VPC existente:

  • Se pueden añadir hasta 5 bloques CIDR adicionales (total 6)
  • Los bloques adicionales no pueden solaparse con los existentes
  • No es posible reducir o eliminar un CIDR una vez añadido
  • Los bloques deben estar dentro de los rangos privados
# Añadir un bloque CIDR secundario a una VPC
aws ec2 associate-vpc-cidr-block --vpc-id vpc-12345 --cidr-block 172.16.0.0/16

Limitaciones:

  • Los bloques adicionales no se reflejan automáticamente en las subnets existentes
  • Se deben crear nuevas subnets para utilizar los rangos adicionales
  • Algunos servicios AWS pueden tener limitaciones con CIDRs secundarios

Soporte IPv6

AWS ofrece soporte nativo para IPv6:

  • Se puede asignar un bloque IPv6 /56 a una VPC
  • AWS asigna el rango (no se puede elegir)
  • Se pueden crear subnets con direccionamiento IPv6 (/64 por subnet)
  • Funcionamiento en modo "dual-stack" (IPv4 e IPv6 simultáneamente)
# Asignar un bloque IPv6 a una VPC
aws ec2 associate-vpc-cidr-block --vpc-id vpc-12345 --amazon-provided-ipv6-cidr-block

Consideraciones para IPv6:

  • Requiere un Internet Gateway para conectividad IPv6 a Internet
  • Para subnets privadas, se necesita un Egress-Only Internet Gateway (equivalente a NAT para IPv6)
  • No todas las instancias o servicios AWS soportan IPv6
  • Las direcciones IPv6 son siempre públicas (no hay concepto de rango privado)

Estrategias de Migración y Expansión

  1. Expansión dentro de la misma VPC:
    • Añadir CIDRs secundarios
    • Crear nuevas subnets con los rangos adicionales
    • Migrar gradualmente recursos a las nuevas subnets
  2. Creación de VPCs adicionales:
    • Crear nuevas VPCs para nuevas cargas de trabajo
    • Conectar mediante VPC Peering o Transit Gateway
    • Segregar entornos o aplicaciones en VPCs separadas
  3. Migración a IPv6:
    • Implementar configuración dual-stack
    • Actualizar grupos de seguridad y NACLs para IPv6
    • Probar compatibilidad de aplicaciones con IPv6

Casos de Uso Avanzados

Arquitectura Multi-Tier

Internet
   |
   v
Internet Gateway
   |
   v
Public Subnet (10.0.1.0/24) --- ALB
   |
   v
Private Subnet (10.0.11.0/24) --- EC2 Instances (App Tier)
   |
   v
Private Subnet (10.0.21.0/24) --- RDS Instances (Data Tier)

Conectividad Híbrida

On-Premises Data Center
   |
   v
VPN Connection / Direct Connect
   |
   v
VPC (10.0.0.0/16)
   |
   |-- Private Subnet (10.0.1.0/24) --- EC2 Instances
   |-- Private Subnet (10.0.2.0/24) --- RDS Instances

Arquitectura Multi-VPC

Management VPC (10.0.0.0/16)
   |
   |-- Transit Gateway
       |
       |-- Production VPC (172.16.0.0/16)
       |-- Development VPC (172.17.0.0/16)
       |-- Shared Services VPC (172.18.0.0/16)

Resumen

La Virtual Private Cloud (VPC) es el componente fundamental de la infraestructura de red en AWS. Entender su anatomía y funcionamiento es esencial para diseñar arquitecturas seguras, escalables y eficientes.

Las subnets públicas y privadas, junto con las tablas de rutas, permiten segmentar la red y controlar el flujo de tráfico. Los componentes como Internet Gateways, NAT Gateways y VPC Peering facilitan la conectividad tanto interna como externa.

El concepto de regiones y zonas de disponibilidad es crucial para diseñar aplicaciones con alta disponibilidad, distribuyendo recursos en múltiples ubicaciones físicas para resistir fallos.

Aunque la VPC predeterminada puede ser útil para comenzar rápidamente, las VPCs personalizadas ofrecen el control y la flexibilidad necesarios para entornos de producción. Siguiendo las buenas prácticas de diseño, podemos crear infraestructuras que satisfagan requisitos de seguridad, rendimiento y escalabilidad.

Finalmente, los métodos de expansión como CIDRs secundarios e IPv6 nos permiten adaptar nuestras redes a medida que crecen las necesidades, asegurando que nuestra infraestructura pueda evolucionar junto con nuestras aplicaciones.

La VPC no es solo un componente técnico, sino un elemento estratégico que influye directamente en la seguridad, el rendimiento y la escalabilidad de nuestras aplicaciones en AWS.