AWS Certified Cloud Practitioner

Post 9 of 25

36%

Complete

Cloud Architecture12 min read

AWS Cloud Practitioner #9: Amazon VPC - Tu Red Privada en la Nube

Domina VPC: subnets públicas y privadas, Internet Gateway, NAT Gateway, Route Tables y diseña arquitecturas de red seguras y escalables.

Recommended Prerequisites

For the best learning experience, we recommend reading these posts first:

🎯 Lo que Aprenderás Hoy

Al finalizar este post, podrás:

  • Explicar qué es Amazon VPC y sus componentes
  • Diferenciar entre subnets públicas y privadas
  • Configurar Internet Gateway y NAT Gateway
  • Diseñar arquitecturas de red con múltiples AZs
  • Comprender Route Tables y routing

El Problema Real

Lanzas una aplicación web en AWS. Necesitas:

plaintext
1. Web servers accesibles desde internet
2. Database servers NO accesibles desde internet (seguridad)
3. Database servers SÍ pueden acceder a internet (para updates)
4. Todo en red privada aislada
5. Alta disponibilidad (múltiples AZs)

Sin VPC: Imposible. Todo está en internet pública.

Con VPC: Diseñas red exactamente como necesitas.

plaintext
Internet
    ↓
Internet Gateway
    ↓
Public Subnet (10.0.1.0/24)
    ├─ Web Server 1 (10.0.1.10)
    └─ NAT Gateway (10.0.1.20)
         ↓
Private Subnet (10.0.3.0/24)
    ├─ App Server 1 (10.0.3.10)
    └─ Database (10.0.3.20)
 
✅ Web servers: Accesibles desde internet
✅ Database: NO accesible desde internet
✅ Database: Puede acceder internet via NAT Gateway
✅ Todo en red privada (10.0.0.0/16)

¿Qué es Amazon VPC?

Amazon VPC (Virtual Private Cloud) es tu red privada virtual dentro de AWS.

Info

Analogía: VPC es como tu propia red corporativa, pero en la nube.

Oficina física:

  • Router, switches
  • IP addresses privadas (192.168.x.x)
  • Firewall para controlar acceso
  • DMZ para servers públicos

VPC en AWS:

  • Internet Gateway (router)
  • Subnets (segments de red)
  • IP ranges privadas (10.0.0.0/16)
  • Security Groups (firewall)
  • Public/Private subnets (DMZ)

Componentes Principales

plaintext
VPC (10.0.0.0/16)
├── Subnets
│   ├── Public (10.0.1.0/24, 10.0.2.0/24)
│   └── Private (10.0.3.0/24, 10.0.4.0/24)
├── Internet Gateway (acceso a internet)
├── NAT Gateway (private → internet)
├── Route Tables (routing rules)
└── Network ACLs y Security Groups (firewall)

Conceptos Fundamentales

1. CIDR Block

CIDR (Classless Inter-Domain Routing) define el rango de IP addresses de tu VPC.

plaintext
Ejemplo: 10.0.0.0/16
 
10.0.0.0 = Network address
/16 = Netmask (primeros 16 bits son network, últimos 16 son hosts)
 
Cálculo:
32 bits total - 16 bits network = 16 bits para hosts
2^16 = 65,536 IP addresses
 
Range: 10.0.0.0 - 10.0.255.255
 
AWS reserved IPs (por subnet):
- 10.0.0.0: Network address
- 10.0.0.1: VPC router
- 10.0.0.2: DNS server
- 10.0.0.3: Future use
- 10.0.0.255: Broadcast (no soportado pero reserved)
 
Usable IPs: 65,536 - 5 = 65,531

CIDR ranges comunes:

plaintext
/16 → 65,536 IPs (10.0.0.0 - 10.0.255.255)
/20 → 4,096 IPs (10.0.0.0 - 10.0.15.255)
/24 → 256 IPs (10.0.1.0 - 10.0.1.255)
/28 → 16 IPs (10.0.1.0 - 10.0.1.15)
 
Recomendación AWS:
VPC: /16 (máximo IPs, flexibilidad)
Subnet: /24 (256 IPs, fácil de gestionar)

2. Subnets

Una subnet es un segmento de IPs dentro del VPC.

plaintext
VPC: 10.0.0.0/16 (65,536 IPs)
 
Subnets:
├─ Public Subnet 1: 10.0.1.0/24 (256 IPs) - AZ-1a
├─ Public Subnet 2: 10.0.2.0/24 (256 IPs) - AZ-1b
├─ Private Subnet 1: 10.0.3.0/24 (256 IPs) - AZ-1a
└─ Private Subnet 2: 10.0.4.0/24 (256 IPs) - AZ-1b
 
Total usado: 1,024 IPs
Disponible: 64,512 IPs (para futuro crecimiento)

Características:

plaintext
✅ Cada subnet está en UNA Availability Zone
✅ Subnets NO pueden spanning AZs
✅ Puedes tener múltiples subnets por AZ
✅ IPs dentro de subnet NO se solapan

3. Public vs. Private Subnets

plaintext
Public Subnet:
✅ Tiene route a Internet Gateway
✅ Instances pueden tener Public IP
✅ Accesible desde internet (con Security Group permitiendo)
Uso: Web servers, load balancers
 
Private Subnet:
❌ NO tiene route directo a Internet Gateway
❌ Instances solo tienen Private IP
❌ NO accesible desde internet
✅ Puede acceder internet via NAT Gateway
Uso: Databases, app servers, backend

¿Qué hace a una subnet "pública"?

plaintext
NO es configuración de la subnet.
Es la Route Table:
 
Public Subnet Route Table:
Destination         Target
10.0.0.0/16         local (dentro de VPC)
0.0.0.0/0           igw-12345 (Internet Gateway)
                    ↑
                    Esto hace que sea "pública"
 
Private Subnet Route Table:
Destination         Target
10.0.0.0/16         local
0.0.0.0/0           nat-12345 (NAT Gateway)
                    ↑
                    Internet via NAT, no directo

Internet Gateway (IGW)

¿Qué es? Gateway que permite comunicación entre VPC e internet.

plaintext
Función:
- VPC → Internet (outbound)
- Internet → VPC (inbound, para instances con Public IP)
 
Características:
✅ Horizontally scaled, redundant, HA
✅ No bandwidth constraints
✅ 1 VPC = 1 Internet Gateway
✅ Free (no charges)

¿Cómo funciona?

plaintext
User (internet) → Public IP (54.123.45.67)
                       ↓
                  Internet Gateway
                  (NAT: Public IP → Private IP)
                       ↓
                  EC2 (Private IP: 10.0.1.10)
 
EC2 no sabe su Public IP.
IGW hace NAT translation.

NAT Gateway

¿Qué es? Permite que instances en private subnets accedan internet, pero internet NO puede iniciar conexiones a ellas.

plaintext
Problema:
Database en private subnet necesita:
- Descargar patches
- Acceder APIs externas
- Install packages (yum, apt)
 
Pero NO debe ser accesible desde internet.
 
Solución: NAT Gateway

Arquitectura:

plaintext
Internet
    ↓
Internet Gateway
    ↓
Public Subnet
    └─ NAT Gateway (10.0.1.20, Public IP: 54.123.45.100)
            ↓
Private Subnet
    └─ Database (10.0.3.20)
 
Flujo:
1. Database inicia request a internet (ej: yum update)
2. Traffic va a NAT Gateway (via route table)
3. NAT Gateway reemplaza source IP (10.0.3.20 → 54.123.45.100)
4. Request va a internet via Internet Gateway
5. Response regresa a NAT Gateway
6. NAT Gateway forward a Database
 
Seguridad:
❌ Internet NO puede iniciar conexión a Database
✅ Database SÍ puede iniciar conexión a internet

NAT Gateway vs. NAT Instance:

AspectoNAT GatewayNAT Instance
ManagedAWS managedTu gestionas
AvailabilityHA dentro de AZManual (script)
BandwidthHasta 45 GbpsDepende de instance type
MaintenanceAWSTú (patches, etc.)
Costo$0.045/hora + dataInstance cost
Security GroupsN/ASí
UsoRecomendadoLegacy

Importante:

plaintext
⚠️ NAT Gateway está en UNA AZ
⚠️ Si AZ falla, private subnets en esa AZ pierden internet access
 
Best practice:
Crea NAT Gateway en CADA AZ
 
AZ-1a:
├─ Public Subnet 1 → NAT Gateway 1
└─ Private Subnet 1 → uses NAT Gateway 1
 
AZ-1b:
├─ Public Subnet 2 → NAT Gateway 2
└─ Private Subnet 2 → uses NAT Gateway 2
 
Costo: 2x ($0.045/h × 2 = $0.09/h = $65/mes)
Beneficio: High availability

Route Tables

¿Qué son? Reglas que determinan hacia dónde va el network traffic.

plaintext
Route Table = conjunto de routes
 
Route components:
- Destination: CIDR block de destino
- Target: Hacia dónde enviar el traffic

Ejemplo:

plaintext
Public Subnet Route Table:
┌─────────────────┬──────────────┐
│ Destination     │ Target       │
├─────────────────┼──────────────┤
│ 10.0.0.0/16     │ local        │  ← Traffic dentro de VPC
│ 0.0.0.0/0       │ igw-12345    │  ← Todo lo demás → Internet
└─────────────────┴──────────────┘
 
Private Subnet Route Table:
┌─────────────────┬──────────────┐
│ Destination     │ Target       │
├─────────────────┼──────────────┤
│ 10.0.0.0/16     │ local        │  ← Traffic dentro de VPC
│ 0.0.0.0/0       │ nat-12345    │  ← Todo lo demás → NAT Gateway
└─────────────────┴──────────────┘

Evaluación de routes:

plaintext
Tráfico destination: 10.0.3.20 (database en mismo VPC)
Check route table:
- 10.0.0.0/16 → local ✓ (match, más específico)
- 0.0.0.0/0 → igw-12345 (match, pero menos específico)
 
Result: Usa local (most specific match wins)
 
Tráfico destination: 8.8.8.8 (Google DNS, internet)
Check route table:
- 10.0.0.0/16 → local (no match)
- 0.0.0.0/0 → igw-12345 ✓ (match, default route)
 
Result: Usa Internet Gateway

Arquitectura de Referencia: 3-Tier Application

plaintext
---
config:
  theme: base
  themeVariables:
    darkMode: false
    archEdgeColor: "#232F3E"
    archEdgeArrowColor: "#232F3E"
    archGroupBorderColor: "#7D8998"
---
flowchart TB
    internet@{img: "https://api.iconify.design/material-symbols/globe-asia.svg", label: "Internet", pos: "b", w: 60, h: 60}

    subgraph vpc["VPC: 10.0.0.0/16"]
        subgraph az1["Availability Zone 1a"]
            subgraph pubsub1["Public Subnet<br/>10.0.1.0/24"]
                web1@{img: "https://api.iconify.design/logos/aws-ec2.svg", label: "Web<br/>Server", pos: "b", w: 50, h: 50}
                nat1@{img: "https://api.iconify.design/logos/aws.svg", label: "NAT<br/>Gateway", pos: "b", w: 50, h: 50}
            end
            subgraph privsub1["Private Subnet<br/>10.0.3.0/24"]
                app1@{img: "https://api.iconify.design/logos/aws-ec2.svg", label: "App<br/>Server", pos: "b", w: 50, h: 50}
            end
            subgraph datasub1["Private Subnet<br/>10.0.5.0/24"]
                db1@{img: "https://api.iconify.design/logos/aws-rds.svg", label: "Database<br/>Primary", pos: "b", w: 50, h: 50}
            end
        end

        subgraph az2["Availability Zone 1b"]
            subgraph pubsub2["Public Subnet<br/>10.0.2.0/24"]
                web2@{img: "https://api.iconify.design/logos/aws-ec2.svg", label: "Web<br/>Server", pos: "b", w: 50, h: 50}
                nat2@{img: "https://api.iconify.design/logos/aws.svg", label: "NAT<br/>Gateway", pos: "b", w: 50, h: 50}
            end
            subgraph privsub2["Private Subnet<br/>10.0.4.0/24"]
                app2@{img: "https://api.iconify.design/logos/aws-ec2.svg", label: "App<br/>Server", pos: "b", w: 50, h: 50}
            end
            subgraph datasub2["Private Subnet<br/>10.0.6.0/24"]
                db2@{img: "https://api.iconify.design/logos/aws-rds.svg", label: "Database<br/>Standby", pos: "b", w: 50, h: 50}
            end
        end

        igw@{img: "https://api.iconify.design/mdi/router-wireless.svg", label: "Internet<br/>Gateway", pos: "b", w: 60, h: 60}
    end

    internet --> igw
    igw --> web1
    igw --> web2
    web1 --> app1
    web2 --> app2
    app1 --> db1
    app2 --> db1
    db1 -.->|"replication"| db2
    app1 --> nat1
    app2 --> nat2
    nat1 --> igw
    nat2 --> igw

    style vpc fill:#fff,stroke:#232F3E,color:#232F3E
    style az1 fill:#fff,stroke:#FF9900,stroke-dasharray: 5 5,color:#232F3E
    style az2 fill:#fff,stroke:#FF9900,stroke-dasharray: 5 5,color:#232F3E
    style pubsub1 fill:#E7F7E7,stroke:#0a0,color:#232F3E
    style pubsub2 fill:#E7F7E7,stroke:#0a0,color:#232F3E
    style privsub1 fill:#FFE7E7,stroke:#c00,color:#232F3E
    style privsub2 fill:#FFE7E7,stroke:#c00,color:#232F3E
    style datasub1 fill:#FFE7E7,stroke:#c00,color:#232F3E
    style datasub2 fill:#FFE7E7,stroke:#c00,color:#232F3E

    classDef default fill:#fff,stroke:#232F3E

Explicación de la arquitectura:

plaintext
Tier 1: Web Layer (Public Subnets)
- EC2 instances con Public IPs
- Accesibles desde internet via Internet Gateway
- Load balancer distribuye tráfico (no mostrado)
 
Tier 2: Application Layer (Private Subnets)
- EC2 instances con solo Private IPs
- NO accesibles desde internet
- Acceden internet via NAT Gateway (para updates)
 
Tier 3: Data Layer (Private Subnets)
- RDS database en private subnet
- NO accesible desde internet
- Multi-AZ para HA
- Standby en otra AZ
 
Alta disponibilidad:
- 2 AZs (si una falla, otra continúa)
- NAT Gateway en cada AZ
- Database con Multi-AZ automatic failover
 
Seguridad:
- Internet solo accede Web tier
- App tier aislado
- Database en subnet más restrictiva

Default VPC vs. Custom VPC

Default VPC:

plaintext
Cada AWS account tiene Default VPC (por región)
 
Características:
✅ CIDR: 172.31.0.0/16
✅ Default subnets en cada AZ (public)
✅ Internet Gateway ya attached
✅ Instances reciben Public IP automáticamente
 
Propósito:
- Para comenzar rápido
- Testing
- Learning
 
Limitaciones:
❌ No puedes modificar CIDR
❌ Todos los subnets son públicos por defecto
❌ No ideal para producción

Custom VPC:

plaintext
VPC que TÚ creas
 
Características:
✅ Tú eliges CIDR (10.0.0.0/16, 192.168.0.0/16, etc.)
✅ Diseñas subnet architecture
✅ Public/private subnets según necesites
✅ Múltiples VPCs posibles
 
Propósito:
- Producción
- Control completo
- Seguridad customizada
 
Recomendación:
Usa Custom VPC para cualquier workload serio

VPC Peering

¿Qué es? Conexión de red entre dos VPCs (mismo account o diferentes accounts).

plaintext
VPC A (10.0.0.0/16)  ←→  VPC B (172.31.0.0/16)
 
Después de peering:
Instance en VPC A (10.0.1.10) puede comunicar con Instance en VPC B (172.31.1.10)
 
Casos de uso:
- Shared services (una VPC con databases compartida)
- Multi-account architecture
- Dev/Prod separation

Restricciones:

plaintext
❌ CIDR blocks NO pueden solaparse
   VPC A: 10.0.0.0/16
   VPC B: 10.0.0.0/16  ← NO permitido
 
✅ Diferentes CIDR OK:
   VPC A: 10.0.0.0/16
   VPC B: 172.31.0.0/16  ← OK
 
❌ NO transitive peering:
   VPC A ←→ VPC B
   VPC B ←→ VPC C
   VPC A ❌ VPC C (need direct peering)

VPC Endpoints

¿Qué son? Permiten acceso privado a AWS services sin usar internet.

plaintext
Sin VPC Endpoint:
EC2 (private subnet) → NAT Gateway → Internet → S3
- Usa internet
- Costo de NAT Gateway
- Latencia mayor
 
Con VPC Endpoint:
EC2 (private subnet) → VPC Endpoint → S3
- Tráfico se queda en AWS network
- No usa NAT Gateway (ahorro $)
- Latencia menor
- Más seguro

Tipos:

plaintext
1. Gateway Endpoints (gratis):
   - S3
   - DynamoDB
 
2. Interface Endpoints (costo):
   - Todo lo demás (EC2, SNS, SQS, etc.)
   - $0.01/hora + data transfer
bash
# Crear VPC Endpoint para S3
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-12345678
 
# Ahora traffic a S3 va via VPC Endpoint (no internet)

📝 Preparación para el Examen

Puntos Clave para Memorizar

VPC Basics:

  • 📌 VPC: Red privada virtual en AWS, región-specific
  • 📌 CIDR: Define IP range (ej: 10.0.0.0/16 = 65,536 IPs)
  • 📌 Subnet: Segment de VPC, vive en UNA AZ
  • 📌 Default VPC: Cada account tiene uno (172.31.0.0/16)

Public vs. Private:

  • 📌 Public Subnet: Route table con route a Internet Gateway
  • 📌 Private Subnet: NO route directo a IGW, usa NAT Gateway

Componentes:

  • 📌 Internet Gateway: VPC ↔ Internet (bidirectional)
  • 📌 NAT Gateway: Private subnet → Internet (unidirectional)
  • 📌 Route Table: Define hacia dónde va el tráfico
  • 📌 VPC Endpoint: Acceso privado a AWS services (no internet)

Best Practices:

  • 📌 Multi-AZ: Subnets en ≥2 AZs para HA
  • 📌 NAT per AZ: NAT Gateway en cada AZ (HA)
  • 📌 Custom VPC: Para producción (no Default VPC)

Preguntas de Práctica

Pregunta 1:

Un database en private subnet necesita descargar patches de internet. ¿Qué componente permite esto?

A) Internet Gateway B) NAT Gateway C) VPC Endpoint D) Direct Connect

Success

Respuesta: B) NAT Gateway

NAT Gateway permite que instances en private subnets accedan internet para outbound traffic (downloads, updates), pero internet NO puede iniciar conexiones inbound.

A es incorrecto: IGW es para public subnets.

Pregunta 2:

¿Qué hace que una subnet sea "pública"?

A) Está en una región pública B) Tiene Public IPs asignadas C) Su route table tiene route a Internet Gateway D) No tiene Security Groups

Success

Respuesta: C) Su route table tiene route a Internet Gateway

Una subnet es pública cuando su route table tiene una route 0.0.0.0/0 → Internet Gateway. La subnet en sí no tiene configuración "pública", es el routing.

Pregunta 3:

Una empresa tiene EC2 instances en private subnet que necesitan acceder S3. Quieren minimizar costos y no usar internet. ¿Qué solución es mejor?

A) NAT Gateway B) Internet Gateway C) VPC Endpoint para S3 D) VPC Peering

Success

Respuesta: C) VPC Endpoint para S3

VPC Endpoint permite acceso directo a S3 sin internet, sin NAT Gateway costs. Gateway Endpoints para S3/DynamoDB son gratis.

A es incorrecto: NAT Gateway funciona pero cuesta $0.045/hora + data transfer.

🎓 Resumen

Lo que aprendimos:

  1. VPC: Red privada en AWS con CIDR customizable
  2. Subnets: Públicas (IGW route) y privadas (NAT route)
  3. Internet Gateway: Comunicación bidirectional VPC ↔ Internet
  4. NAT Gateway: Private subnet → Internet (unidirectional)
  5. Route Tables: Controlan routing de tráfico
  6. HA Design: Múltiples AZs + NAT Gateway por AZ

Arquitectura típica:

plaintext
Internet
    ↓
Internet Gateway
    ↓
Public Subnets (2+ AZs)
├─ Load Balancer
├─ Web Servers
└─ NAT Gateways
    ↓
Private Subnets (2+ AZs)
├─ App Servers
└─ Databases
 
Beneficios:
✅ Web layer accesible desde internet
✅ App/Data layers aislados
✅ High availability (multi-AZ)
✅ Seguridad por capas

⏭️ Próximo Post

En el Post #10 profundizaremos en Security Groups y Network ACLs:

  • Diferencias entre Security Groups y NACLs
  • Stateful vs. stateless
  • Reglas inbound/outbound
  • Best practices de seguridad

📚 Recursos

Tags: #AWS #CloudPractitioner #VPC #Networking #Subnets #InternetGateway #NATGateway #Certification

Written by Jhonny Lorenzo

Researcher at TrautsLab

Related Articles

Cloud Architecture

AWS Cloud Practitioner #5: Shared Responsibility Model - ¿Quién es Responsable de Qué?

Comprende el modelo de responsabilidad compartida de AWS: qué gestiona AWS (security OF the cloud) vs. qué gestionas tú (security IN the cloud).

13 min
Cloud Architecture

AWS Cloud Practitioner #12: AWS IAM - Control de Accesos

Domina IAM: users, groups, roles, policies, MFA, y el principio de least privilege para asegurar tu cuenta AWS.

10 min
Cloud Architecture

AWS Cloud Practitioner #13: Encryption y AWS KMS

Aprende encryption at rest y in transit, AWS KMS para gestión de claves, y cómo proteger datos sensibles en AWS.

9 min
Cloud Architecture

AWS Cloud Practitioner #1: De Servidores Físicos a la Nube

Aprende qué es cloud computing y las diferencias entre IaaS, PaaS y SaaS con una metodología bottom-up que construye tu conocimiento paso a paso.

7 min

Recent Articles

Cloud Architecture

AWS Cloud Practitioner #4: Well-Architected Framework - Los 6 Pilares

13 min
Cloud Architecture

AWS Cloud Practitioner #5: Shared Responsibility Model - ¿Quién es Responsable de Qué?

13 min
Cloud Architecture

AWS Cloud Practitioner #6: Amazon EC2 - Tu Servidor en la Nube

12 min
Cloud Architecture

AWS Cloud Practitioner #7: Amazon S3 - Almacenamiento Ilimitado en la Nube

13 min
Cloud Architecture

AWS Cloud Practitioner #8: Amazon RDS - Databases Gestionadas

12 min

Comments