El Proyecto | Sobre nosotros | Contribuir | Donaciones | Licencia

HOME

Tenemos la red y el servidor, pero falta protegerlo con un firewall (Security Group) y, opcionalmente, darle una dirección IP fija (Elastic IP). Recuerda los conceptos del Capítulo 4 (subcapítulos 4.2 y 4.4); ahora los escribimos en Terraform y completamos nuestra primera infraestructura funcional.

Paso 1: Crear el Security Group (el firewall)

El Security Group (subcapítulo 4.2) controla qué tráfico entra y sale de la instancia. Para un servidor web, queremos permitir HTTP, HTTPS y, de forma limitada, SSH para administración.

resource "aws_security_group" "web" {
  name        = "sg-servidor-web"
  description = "Permite HTTP, HTTPS y SSH limitado"
  vpc_id      = aws_vpc.principal.id

  # Regla de ENTRADA: permitir HTTP desde cualquier sitio
  ingress {
    description = "HTTP desde internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Regla de ENTRADA: permitir HTTPS desde cualquier sitio
  ingress {
    description = "HTTPS desde internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Regla de ENTRADA: permitir SSH SOLO desde mi IP
  ingress {
    description = "SSH solo desde mi IP"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.25/32"]   # ← TU IP, no 0.0.0.0/0
  }

  # Regla de SALIDA: permitir todo el tráfico saliente
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"     # todos los protocolos
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "sg-servidor-web"
  }
}

Repasemos las decisiones, que aplican lo aprendido en seguridad:

HTTP (80) y HTTPS (443) desde 0.0.0.0/0: correcto, porque queremos que cualquiera pueda ver la web pública.
SSH (22) solo desde tu IP (/32): ¡crítico! Recuerda el error de principiante del subcapítulo 4.2. NUNCA pongas SSH abierto a 0.0.0.0/0. Aquí lo limitamos a una IP concreta (la /32 significa «exactamente esta IP»). Sustituye 203.0.113.25 por tu IP real.
Salida (egress) abierta: permite que el servidor salga a internet (para descargar el software del user_data). Recuerda que los Security Groups son stateful (subcapítulo 6.4), así que las respuestas a las conexiones entrantes se permiten automáticamente.

Ahora la instancia del subcapítulo 12.2 ya encuentra su Security Group, porque lo referenciaba con vpc_security_group_ids = [aws_security_group.web.id]. Las piezas encajan.

Paso 2 (opcional): Crear una Elastic IP

Recuerda el problema de las IPs cambiantes (subcapítulo 4.4): la IP pública de una instancia cambia si la paras y arrancas. Si quieres una IP fija, usas una Elastic IP:

resource "aws_eip" "web" {
  instance = aws_instance.web.id
  domain   = "vpc"

  tags = {
    Name = "eip-servidor-web"
  }
}

Esto reserva una Elastic IP y la asocia a nuestra instancia. A partir de ahora, el servidor tiene una dirección pública estable.

Recuerda el aviso de costes (subcapítulo 4.4): AWS cobra por las Elastic IPs no usadas y por las IPv4 públicas en general. Para una sola instancia de prueba está bien, pero en arquitecturas reales se suele poner un balanceador de carga delante (Capítulo 13) en vez de una Elastic IP por servidor. Para este primer proyecto, la Elastic IP es perfecta para tener una dirección estable.

El conjunto completo

¡Ya tenemos una infraestructura funcional! Resumamos todo lo construido en el capítulo hasta ahora:

┌──────────── VPC (10.0.0.0/16) ─────────────────┐
│  Internet Gateway ──── Route Table (0.0.0.0/0) │
│                                                 │
│  ┌─ Subred pública (10.0.1.0/24) ──────────┐    │
│  │                                          │   │
│  │   ┌─ Instancia EC2 ──────────────┐       │   │
│  │   │  Servidor web (Apache)        │       │  │
│  │   │  Protegido por Security Group │       │  │
│  │   │  Elastic IP fija asociada     │       │  │
│  │   └───────────────────────────────┘      │   │
│  └──────────────────────────────────────────┘   │
│                                                  │
│  Security Group: HTTP/HTTPS abiertos, SSH solo a tu IP │
└──────────────────────────────────────────────────┘

Si ejecutas terraform apply (escribiendo yes), Terraform crea todo en el orden correcto y, en un par de minutos, tu servidor estará sirviendo la página web «¡Hola desde mi primer servidor en AWS con Terraform!» en su IP pública.

Lo que debes recordar

El Security Group se define con reglas ingress (entrada) y egress (salida), cada una con puertos, protocolo y orígenes (cidr_blocks).
Aplica seguridad real: HTTP/HTTPS abiertos al público, pero SSH solo a tu IP (/32), nunca a 0.0.0.0/0.
Al ser stateful, no hace falta abrir manualmente el tráfico de respuesta.
Una Elastic IP (aws_eip) da una dirección pública fija a la instancia; recuerda su coste y que en producción se suele preferir un balanceador.
Con esto tienes tu primera infraestructura funcional: red + servidor web + firewall + IP fija, todo en código.

En el siguiente subcapítulo aprenderás a sacar información útil de tu infraestructura (como la IP del servidor) con outputs y a entender mejor las referencias entre recursos.

Cloud, AWS & Terraform — De cero a experto

Capítulo 1 · Qué es el cloud computing

Capítulo 2 · El mercado cloud y los grandes proveedores

Capítulo 3 · Regiones, zonas de disponibilidad y edge

Capítulo 4 · Cómputo: EC2

Capítulo 5 · Almacenamiento: S3

Capítulo 6 · Redes: VPC

Capítulo 7 · Identidad y acceso: IAM

Capítulo 8 · Bases de datos gestionadas

Capítulo 9 · Por qué Infraestructura como Código

Capítulo 10 · HCL: el lenguaje de Terraform

Capítulo 11 · Providers y estado

Capítulo 12 · Tu primera infraestructura real en Terraform

Capítulo 13 · Balanceo de carga y autoescalado

Capítulo 14 · Serverless con Lambda

Capítulo 15 · Mensajería y eventos

Capítulo 16 · Entrega de contenido y DNS

Capítulo 17 · Contenedores en AWS

Capítulo 18 · Módulos: reutilización y composición

Capítulo 19 · Workspaces y gestión de entornos

Capítulo 20 · Backends remotos y locking

Capítulo 21 · Testing de infraestructura

Capítulo 22 · Terraform en CI/CD

Capítulo 23 · Seguridad en profundidad

Capítulo 24 · Observabilidad: logs, métricas y trazas

Capítulo 25 · Optimización de costes

Capítulo 26 · Alta disponibilidad y disaster recovery

Capítulo 27 · Well-Architected Framework de AWS

Capítulo 28 · Arquitecturas serverless a escala

Capítulo 29 · Plataformas de datos en AWS

Capítulo 30 · Multi-cuenta y landing zones

Capítulo 31 · Platform Engineering e Internal Developer Platform

Capítulo 32 · Certificaciones AWS relevantes

Capítulo 33 · Proyectos para consolidar lo aprendido

Capítulo 34 · Recursos y comunidad