Configurar VPC escalable y segura en AWS

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

Implementación: Enrutamiento, Puertos y Salida

Con el plan definido, la implementación implica la creación de 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

Larutificación

Tablas de enrutamiento privadas (HA Salida): Las subredes privadas no deben tener una ruta al IGW. Para el acceso a internet (por ejemplo, para aplicar parches de software o llamar a APIs externas), deben utilizar un Gateway NAT (NGW). Para la alta disponibilidad, debemos provisionar un NGW en cada Zona de Disponibilidad (por ejemplo, en public-a, public-b, public-c). A continuación, creamos una tabla de enrutamiento privada separada para cada Zona de Disponibilidad que apunta a su NGW local. Esto evita que un fallo en un NGW específico afecte la conectividad de internet para todas las Zonas de Disponibilidad. 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 única tabla de enrutamiento para todas las subredes públicas. Su característica principal es una ruta predeterminada (0.0.0.0/0) que apunta al puerto de 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 lanzada en private-app-a no tiene una dirección IP pública, no es accesible desde internet, pero puede iniciar conexiones salientes a través de nat-gateway-a.

Servicios de Ingeniería de Productos

Colabore con nuestros gestores de proyectos, ingenieros de software y testers de control de calidad 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 ACLs de red

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

Grupos de seguridad (SGs)

• Qué son: Un firewall de nivel de instancia y con estado.
• Con estado: Si permite el tráfico entrante (por ejemplo, el puerto 443), el tráfico saliente se permite automáticamente, independientemente de las reglas salientes.
• Alcance: Aplicado a una Interfaz de Red Elástica (ENI), que es efectivamente una instancia.
• Reglas: Solo permitir. No se pueden crear reglas de "rechazo".
• Mejor práctica: Utilice las SG como su firewall principal y granular. Una técnica clave es referenciar otras SG en sus reglas. Esto es mucho mejor que codificar bloques CIDR.

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 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 el NACL predeterminado como "PERMITER TODO" (lo cual es por defecto). Utilice los grupos de seguridad para el 99% de sus necesidades de seguridad. Los NACLs son una herramienta tosca, que es mejor reservar para reglas explícitas de "rechazo" (por ejemplo, "rechazar todo el tráfico del rango de direcciones IP maliciosas conocido 1.2.3.0/24"). Los NACLs demasiado complejos son una causa común de pesadillas al depurar la conectividad de la red.1.2.3.0/24"). Las NACLs (Network Access Control Lists) excesivamente complejas son una causa común de problemas y frustraciones al intentar solucionar problemas de 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 la red pública por defecto (a través del Gateway NAT). Esto es ineficiente, genera costes adicionales de transferencia de datos y aumenta tu superficie de ataque.

Solución: VPC Endpoints para mantener este tráfico en 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 enrutamiento privadas. AWS añade automáticamente una ruta para el rango de IP pública del servicio al punto final.
• Coste: Gratuito.

Implementación (Punto final 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 a la API S3 desde una instancia en una subred privada se enruta automáticamente y de forma transparente a través del punto final privado, no a través del Gateway NAT.

Puntos de acceso de la interfaz (AWS PrivateLink)

• Servicios: La mayoría de los demás 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 IP privada dentro de sus subredes privadas.. Accede al servicio a través de un nombre de DNS privado.
• Coste: Se factura por hora y por GB de datos procesados.
• Implementación: Debe especificar qué subredes privadas (una por zona de alta disponibilidad) deben pertenecer a las ENI del punto de conexión.

# 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 en el diseño de una VPC segura.

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

A medida que su organización crece, tendrá múltiples VPCs (por ejemplo, producción, desarrollo, servicios compartidos, ciencia de datos). La solución tradicional, 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 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

El TGW actúa como un enrutador central en la nube en un modelo de "hub and spoke".

1. Usted crea un TGW.
2. Todas sus redes VPC (los "centros") se conectan a este TGW (el "hub").
3. Su red local (a través de VPN/Direct Connect) también se conecta al TGW.

Este modelo simplifica enormemente la gestión de rutas:

• Cada VPC solo necesita una ruta (p. ej., 10.0.0.0/810.0.0.0/8
• ) que apunte al nodo de conexión.
• Permite un modelo de "inspección centralizada", donde todo el tráfico puede ser dirigido a través de una VPC dedicada ("seguridad") con firewalls de terceros antes de llegar a su destino.

Para cualquier arquitectura que se espere que crezca más allá de dos o tres VPCs, comience con un Transit Gateway. No construya una red punto a punto que tendrá que refactorizar.

Conclusión

Una red privada virtual (VPC) de nivel de producción no es un componente que se "configura y olvida". Es un diseño vivo que debe basarse en decisiones arquitectónicas intencionales. Al centrarse en un plan CIDR lógico, una estrategia de subredes 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.Ya sea que sus equipos remotos estén creando nuevas plataformas o migrando las existentes, dominar este nivel de red es un requisito previo para el éxito en AWS.Estamos creando nuevas plataformas o migrando las existentes, y dominar esta capa de red es un requisito fundamental para tener éxito en AWS.

Preguntas frecuentes