Arquitectura VPC: Planificación de redes seguras y escalables en AWS

Una Red Privada Virtual (VPC) es el límite de red fundamental para tus recursos dentro de Amazon Web Services. Una arquitectura VPC mal concebida es una fuente principal de deuda técnica, creando vulnerabilidades de seguridad críticas y cuellos de botella severos para la escalabilidad. Por otro lado, una VPC bien diseñada, construida sobre principios básicos, permite una postura "segura por defecto", simplifica las operaciones y escala sin problemas con tus cargas de trabajo.

Este artículo es una guía técnica y orientada a la implementación para directores técnicos y ingenieros senior. Nos adentraremos más allá de la "VPC predeterminada" y construiremos una infraestructura de red de nivel de producción, detallando las decisiones arquitectónicas y configuraciones precisas necesarias para un despliegue seguro, escalable y en múltiples zonas de disponibilidad (AZ).

Decisión Arquitectónica Principal: Planificación de VPC y CIDR de Subredes

La decisión más crítica e irreversible es el bloque principal de enrutamiento interdominio sin clases (CIDR) de su VPC. Una vez que se crea una VPC, su bloque CIDR principal no puede ser modificado.

Problema: Elegir una CIDR común (por ejemplo, 172.16.0.0/16 o 192.168.0.0/16) crea una alta probabilidad de conflictos de direcciones IP cuando inevitablemente necesite conectarse a una red local (a través de VPN o Direct Connect) o comunicarse con otra VPC (por ejemplo, un socio o un proveedor de SaaS).

Solución:

1. Utilice un bloque grande: Siempre comience con un /16 bloque. Esto proporciona 65,536 direcciones IP privadas, lo cual es más que suficiente para el crecimiento y la segmentación. Las direcciones IP son gratuitas; el agotamiento de las direcciones IP es un fallo catastrófico.
2. Evite los bloques comunes: Seleccione un bloque del rango 10.0.0.0/8 que sea poco común. Por ejemplo, elija algo específico como 10.100.0.0/16. Esta simple decisión evitará innumerables conflictos futuros de red.

Servicios de Ingeniería de Productos

Trabaje con nuestros gestores de proyectos, ingenieros de software y probadores de calidad internos para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

Estrategia de Segmentación: El modelo Multi-AZ, Multi-Nivel

Tu estrategia de subred debe basarse en dos principios:Alta Disponibilidad (HA) yAislamiento de Seguridad.

• HA: Su aplicación debe sobrevivir al fallo de una Zona de Disponibilidad completa. Esto significa que debe tener presencia en al menos dos, preferiblemente tres, Zonas de Disponibilidad.
• Aislamiento: Los recursos deben estar segmentados según su función y su postura de seguridad. La división principal es Público vs. Privado.
  • Subredes Públicas: Contienen recursos que deben tener una ruta directa al Gateway de Internet (IGW). Esta capa es para Elastic Load Balancers (ELB) y NAT Gateways orientados a internet.
  • Subredes Privadas: Contienen sus recursos protegidos (servidores de aplicaciones, tareas de contenedor, bases de datos) que deben nunca ser accesibles directamente desde internet.

Combinando estas opciones, un modelo sólido implica crear subredes asociadas para cada nivel funcional en cada zona de disponibilidad (AZ).

Plan de VPC de ejemplo:

• CIDR de VPC: 10.100.0.0/16
• Región: us-east-1(con zonas us-east-1a, us-east-1b, us-east-1c)

Utilizaremos bloques de /24 para nuestros subredes (con 256 direcciones IP cada una), que es un tamaño común y flexible.

Esta estructura nos proporciona una clara separación de responsabilidades, soporte para todas las capas y un amplio espacio para futuras expansiones (por ejemplo, añadir las capas de datos privadosprivate-data o private-mgmt

Implementación: Enrutamiento, Puertos y Salida

Con el plan definido, la implementación implica crear los componentes de red y "conectarlos" entre sí utilizando las tablas de enrutamiento.

Paso 1: Crear VPC, subredes e Internet Gateway (IGW)

Primero, cree los componentes principales. Utilizaremos la AWS CLI para obtener resultados precisos.

# 1. Create the VPC
VPC_ID=$(aws ec2 create-vpc --cidr-block 10.100.0.0/16 \
  --query 'Vpc.VpcId' --output text)
aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=prod-vpc

# 2. Create the Internet Gateway and attach it
IGW_ID=$(aws ec2 create-internet-gateway --query 'InternetGateway.InternetGatewayId' --output text)
aws ec2 create-tags --resources $IGW_ID --tags Key=Name,Value=prod-igw
aws ec2 attach-internet-gateway --vpc-id $VPC_ID --internet-gateway-id $IGW_ID

# 3. Create public subnets (example for AZ-a)
# (Enable auto-assign public IP for convenience in this subnet)
SUBNET_PUB_A=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.100.10.0/24 \
  --availability-zone us-east-1a --query 'Subnet.SubnetId' --output text)
aws ec2 modify-subnet-attribute --subnet-id $SUBNET_PUB_A --map-public-ip-on-launch
aws ec2 create-tags --resources $SUBNET_PUB_A --tags Key=Name,Value=public-a

# 4. Create private subnets (example for AZ-a)
SUBNET_APP_A=$(aws ec2 create-subnet --vpc-id $VPC_ID --cidr-block 10.100.20.0/24 \
  --availability-zone us-east-1a --query 'Subnet.SubnetId' --output text)
aws ec2 create-tags --resources $SUBNET_APP_A --tags Key=Name,Value=private-app-a

# ... repeat for all other subnets in our plan ...

Paso 2: Configurar el enrutamiento público frente al privado

El enrutamiento es lo que define una subred como "pública" o "privada".

Tablas de enrutamiento privadas (HA Salida): Las subredes privadas no deben tener una ruta al IGW. Para el acceso a internet fuera (por ejemplo, para aplicar parches o llamar a APIs externas), deben usar un Puerta de enlace NAT (NGW).Para la alta disponibilidad (HA), debemos configurar una NGW en cada Zona de Disponibilidad (por ejemplo, en public-a, public-b, public-c). Luego creamos una tabla de enrutamiento privada separada para cada Zona de Disponibilidad que apunte a su NGW local. Esto evita que un fallo en la NGW tome el acceso a internet fuera de todos los AZ.Bash

# --- Configuration for AZ-A ---

# 1. Create Elastic IP for NGW-A
EIP_A=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)

# 2. Create NGW-A in the public-a subnet
NGW_A=$(aws ec2 create-nat-gateway --subnet-id $SUBNET_PUB_A --allocation-id $EIP_A \
  --query 'NatGateway.NatGatewayId' --output text)
aws ec2 create-tags --resources $NGW_A --tags Key=Name,Value=nat-gateway-a

# Wait for NGW to be available (omitted for brevity)

# 3. Create a private route table for AZ-A
RTB_PRIVATE_A=$(aws ec2 create-route-table --vpc-id $VPC_ID \
  --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-tags --resources $RTB_PRIVATE_A --tags Key=Name,Value=rtb-private-a

# 4. Add default route via NGW-A
aws ec2 create-route --route-table-id $RTB_PRIVATE_A \
  --destination-cidr-block 0.0.0.0/0 --nat-gateway-id $NGW_A

# 5. Associate with ALL private subnets in AZ-A
aws ec2 associate-route-table --subnet-id $SUBNET_APP_A --route-table-id $RTB_PRIVATE_A
# ... associate with private-db-a ...

# --- Repeat steps 1-5 for AZ-B and AZ-C ---
# (Create EIP-B, NGW-B in public-b, RTB_PRIVATE_B, route 0.0.0.0/0 to NGW-B,
#  and associate with private-app-b, private-db-b)

Tabla de enrutamiento pública: Crear una tabla de enrutamiento única para todas las subredes públicas. Su característica principal es una ruta predeterminada (0.0.0.0/0) que apunta al puerto de acceso a Internet.Bash

# Create public route table
RTB_PUBLIC=$(aws ec2 create-route-table --vpc-id $VPC_ID \
  --query 'RouteTable.RouteTableId' --output text)
aws ec2 create-tags --resources $RTB_PUBLIC --tags Key=Name,Value=rtb-public

# Add the "public" route to the IGW
aws ec2 create-route --route-table-id $RTB_PUBLIC \
  --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW_ID

# Associate with our public subnets
aws ec2 associate-route-table --subnet-id $SUBNET_PUB_A --route-table-id $RTB_PUBLIC
# ... associate with public-b, public-c ...

En este punto, cualquier instancia de EC2 que se lance en private-app-a no tiene una dirección IP pública y no es accesible desde internet, pero puede iniciar conexiones salientes a través de nat-gateway-a.

Servicios de Ingeniería de Productos

Trabaje con nuestros gestores de proyectos, ingenieros de software y testers de calidad internos para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

Seguridad en capas: Grupos de seguridad frente a ACL de red

Un punto de fallo común es malinterpretar las dos capas de los firewalls de la VPC.

Grupos de Seguridad (GS)

• ¿Qué son: Un firewall a nivel de instancia y con estado.
• Con estado: Si permite el tráfico entrante (por ejemplo, puerto 443), el retorno del tráfico saliente se permite automáticamente, independientemente de las reglas de salida.
• Alcance: Aplicado a una Interfaz de Red Elástica (ENI), que es esencialmente una instancia.
• Reglas: Solo permite. No se pueden crear "reglas de denegación".
• Mejor práctica: Utilice los grupos de seguridad como su firewall principal y granular. Una técnica clave es referenciar otros grupos de seguridad en sus reglas. Esto es mucho mejor que codificar bloques CIDR directamente.

Ejemplo de Terraform (HCL): Este patrón es ideal.

resource "aws_security_group" "lb_sg" {
  name   = "prod-lb-sg"
  vpc_id = aws_vpc.prod.id
  
  # Allow public web traffic
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "app_sg" {
  name   = "prod-app-sg"
  vpc_id = aws_vpc.prod.id

  # ONLY allow traffic from our load balancer
  ingress {
    from_port       = 8080 # App port
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.lb_sg.id] # Source is the LB SG
  }
}

resource "aws_security_group" "db_sg" {
  name   = "prod-db-sg"
  vpc_id = aws_vpc.prod.id

  # ONLY allow traffic from our application tier
  ingress {
    from_port       = 5432 # PostgreSQL port
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app_sg.id] # Source is the App SG
  }
}

Listas de control de acceso a la red (NAC)

• ¿Qué son?: Un firewall de nivel de subred, sin estado.
• Sin estado: Si permite el tráfico entrante, debe también permitir explícitamente el retorno del tráfico saliente.
• Alcance: Aplicado a una o más subredes.
• Reglas: Permitir y Rechazar reglas. Las reglas se procesan por número, en orden.
• Recomendación: Dejar la NACL predeterminada como "PERMITIR TODO" (que es por defecto). Utilice las SGs para el 99% de sus necesidades de seguridad. Las NACLs son una herramienta tosca, que mejor se reservan para reglas explícitas de "rechazo" amplias (por ejemplo, "rechazar todo el tráfico desde el rango conocido de direcciones maliciosas 1.2.3.0/24"). Las NACLs demasiado complejas son una causa común de pesadillas al depurar la conectividad de red.

Seguridad del tráfico interno: puntos finales de VPC

Una importante vulnerabilidad de seguridad en muchas VPCs es que la comunicación desde una subred privada hacia un servicio de AWS (como S3 o DynamoDB) atraviesa por defecto internet público (a través del Gateway NAT). Esto es ineficiente, incrementa el coste de transferencia de datos y aumenta tu superficie de ataque.

Solución: Puntos de acceso VPC Mantenga este tráfico dentro de la red privada de AWS.

Puntos de acceso

• Servicios: S3 y DynamoDB.
• Cómo funcionan: Usted crea el punto final y lo asocia con sus tablas de ruta privadas. AWS añade automáticamente una ruta para el rango de IP público del servicio al punto final.
• Coste: Gratuito.

Implementación (API S3):

# Create the gateway endpoint for S3
aws ec2 create-vpc-endpoint --vpc-id $VPC_ID \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids $RTB_PRIVATE_A $RTB_PRIVATE_B $RTB_PRIVATE_C

# Best Practice: Attach a policy to restrict access
# This example policy only allows Get/PutObject to a specific bucket
# from a specific IAM role within your instances.
# (Policy JSON ommitted for brevity)

Ahora, cualquier llamada al SDK de S3 desde una instancia en una subred privada se dirige automáticamente y sin problemas a través del punto final privado, no a través del Gateway NAT.

Puntos de conexión de la interfaz (AWS PrivateLink)

• Servicios: La mayoría de los otros servicios de AWS (SQS, SNS, Kinesis, CodeCommit, etc.) y sus propios servicios.
• Cómo funcionan: Crea una Interfaz de Red Elástica (ENI) con una dirección IP privada dentro de tus subredes privadas. Accedes al servicio a través de un nombre DNS privado.
• Coste: Se cobra por hora y por GB de datos procesados.
• Implementación: Debes especificar qué subredes privadas (una por zona, para alta disponibilidad) deben albergar las ENI del punto final.

# Example for SQS
aws ec2 create-vpc-endpoint --vpc-id $VPC_ID \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.sqs \
  --subnet-ids $SUBNET_APP_A $SUBNET_APP_B $SUBNET_APP_C \
  --security-group-id $YOUR_ENDPOINT_SG_ID

Utilizar endpoints es un componente esencial e indispensable para el diseño de una VPC segura.

Escalar más allá de una sola VPC: AWS Transit Gateway

A medida que su organización crece, tendrá múltiples redes privadas virtuales (por ejemplo, producto, <s4>, ,<s6>, ,<s8>). La solución tradicional, VPC Peering, crea una red compleja y no transitiva de "n-a-n" que es difícil de gestionar.). La solución existente, VPC Peering, crea una red compleja y no transitiva de "n-a-n", que es difícil de gestionar.

Solución: AWS Transit Gateway (TGW).

Servicios de Ingeniería de Productos

Trabaje con nuestros gestores de proyectos, ingenieros de software y probadores de calidad internos para crear su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo las metodologías Agile, DevOps y Lean.

Build with 4Geeks

El TGW actúa como un enrutador en la nube central en un modelo de "nodo y centro".

1. Crearás una única red TGW.
2. Todas tus redes VPC (que son los "nodos") se conectan a esta red TGW (que es el "centro").
3. Tu red local (a través de VPN/Direct Connect) también se conecta a la red TGW.

Este modelo simplifica drásticamente la gestión de rutas:

• Cada VPC solo necesita una ruta (p. ej., 10.0.0.0/810.0.0.0/8
• Las tablas de enrutamiento del TGW controlan todo el tráfico entre las VPC y entre la VPC y la red local.
• Permite un modelo de "inspección centralizada", donde todo el tráfico puede ser dirigido a través de una VPC dedicada ("de seguridad") (con firewalls de terceros) antes de llegar a su destino.

Para cualquier arquitectura que se espere que supere los dos o tres VPCs, comience con un Transit Gateway. No construya una red de pares que tendrá que refactorizar más adelante.

Conclusión

Una red privada virtual (VPC) de nivel de producción no es un componente "de instalar y olvidarse". Es un diseño dinámico que debe basarse en decisiones arquitectónicas intencionales. Al centrarse en un plan CIDR lógico, una estrategia de subredización multi-AZ, enrutamiento consciente de la alta disponibilidad (HA) y seguridad en capas a través de grupos de seguridad (SGs) y puntos finales de VPC, se crea una base que permite, en lugar de obstaculizar, la seguridad y el crecimiento de su aplicación.

Construir esta base correctamente es una competencia fundamental de los servicios de ingeniería en la nube para expertos cloud engineering services. Ya sea que sus remote teams estén desarrollando nuevas plataformas o migrando las existentes, dominar esta capa de red es un requisito previo para el éxito en AWS.

Preguntas frecuentes