Terraform AWS VPC: Redes Seguras y Escalables 2026

Terraform AWS VPC te permite definir redes en Amazon Web Services como código: VPC, subnets públicas y privadas, NAT Gateway e Internet Gateway en un solo módulo reutilizable. En esta guía verás cómo usar el módulo oficial terraform-aws-modules/vpc/aws del Terraform Registry para crear una VPC lista para producción. Si ya usas Terraform, revisa Terraform AWS EC2 y nuestra categoría Terraform.

¿Qué es Terraform AWS VPC?

Una VPC (Virtual Private Cloud) en AWS es una red aislada lógicamente donde creas subnets, tablas de ruteo, gateways y controles de tráfico. Con Terraform AWS VPC describes esa topología en HCL (HashiCorp Configuration Language) y la versionas en Git: mismo resultado en todos los entornos, sin crear recursos a mano desde la consola. La documentación de Terraform en HashiCorp Developer y el repositorio terraform-aws-vpc son la referencia. El módulo oficial del Registry crea la VPC, subnets públicas y privadas, Internet Gateway, NAT Gateway (opcional), tablas de rutas y asociaciones; opcionalmente subnets para bases de datos (RDS), flow logs y más. Comparado con CloudFormation o con crear recursos manualmente, Terraform AWS VPC te da un único bloque reutilizable con buenas prácticas por defecto y outputs listos para enlazar con otros módulos (EC2, RDS, EKS).

Casos de uso: entornos de desarrollo, staging y producción con redes aisladas; preparar la red base para clústeres EKS o ECS; tener subnets privadas para bases de datos y subnets públicas para balanceadores; cumplir requisitos de compliance con redes definidas como código y auditables. El producto Terraform de HashiCorp y el ecosistema de módulos permiten componer infraestructura completa a partir de bloques como este. A diferencia de definir cada recurso (aws_vpc, aws_subnet, aws_internet_gateway, etc.) a mano, el módulo Terraform AWS VPC abstrae la complejidad y aplica convenciones probadas (por ejemplo nombres de recursos, tags y asociaciones entre tablas de ruta y subnets), lo que acelera el desarrollo y reduce errores de configuración.

Arquitectura y conceptos de Terraform AWS VPC

En una configuración típica de Terraform AWS VPC: la VPC tiene un bloque CIDR (por ejemplo 10.0.0.0/16). Dentro defines subnets en distintas Availability Zones (AZs) para alta disponibilidad. Las subnets públicas tienen ruta hacia un Internet Gateway y suelen albergar balanceadores o instancias con IP pública; las subnets privadas tienen ruta hacia un NAT Gateway (o NAT Instance) para tráfico saliente a internet sin exponer las instancias. El módulo terraform-aws-modules/vpc/aws crea estos recursos y sus asociaciones; el flujo de Terraform (init, plan, apply) aplica los cambios en el orden correcto gracias a las dependencias implícitas. Los outputs del módulo (vpc_id, private_subnet_ids, public_subnet_ids, etc.) se usan como input en otros recursos: por ejemplo pasas subnet_ids a un módulo de EKS o a un recurso aws_instance. La documentación del módulo VPC en el Registry lista todos los inputs y outputs.

Requisitos previos para Terraform AWS VPC

Necesitas Terraform instalado (1.x recomendado), credenciales AWS configuradas (variables de entorno AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY, o AWS CLI con aws configure, o IAM roles si ejecutas en EC2/CodeBuild). El provider AWS debe estar declarado en tu configuración; el módulo VPC usa el provider por defecto. Conocimientos básicos de HCL y de conceptos de red (CIDR, subnets, gateways) ayudan. Para producción conviene usar un backend remoto (por ejemplo S3 con DynamoDB para state locking) tal como recomienda HashiCorp en backends S3.

Crear Terraform AWS VPC paso a paso

Paso 1: Crear un directorio para el proyecto y un fichero main.tf (o vpc.tf). Declara el provider AWS y la región que quieras usar (por ejemplo eu-west-1). Incluye la configuración del backend si usas S3 (en un bloque terraform { backend "s3" { ... } }). Paso 2: Añadir el módulo terraform-aws-modules/vpc/aws con source y version (por ejemplo ~> 5.0). Define name, cidr, azs (lista de Availability Zones) y los bloques CIDR de private_subnets y public_subnets. Asegúrate de no solapar rangos con otras VPCs si usas VPN o peering. Paso 3: Decidir si quieres NAT Gateway: enable_nat_gateway = true y single_nat_gateway = true para un solo NAT (más barato, menos resiliente) o false para un NAT por AZ. En desarrollo muchas veces basta con un único NAT. Paso 4: Activar enable_dns_hostnames y enable_dns_support para resolver nombres dentro de la VPC; necesario para que recursos como RDS o interfaces VPC resuelvan nombres internos. Paso 5: Ejecutar terraform init para descargar el módulo y el provider, luego terraform plan para revisar los recursos que se crearán (VPC, subnets, gateways, tablas de ruta), y terraform apply para aplicar. Los costes de NAT Gateway y de la VPC (por datos procesados) aparecen en la facturación AWS; para desarrollo puedes usar single_nat_gateway = true para reducir coste. Con estos pasos tienes una VPC funcional definida con Terraform AWS VPC lista para conectar instancias EC2, RDS o clústeres EKS.

Ejemplo Terraform AWS VPC completo

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "mi-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway   = true
  single_nat_gateway   = false
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Terraform   = "true"
    Environment = "prod"
  }
}

Con enable_nat_gateway = true las subnets privadas pueden salir a internet; con single_nat_gateway = false tendrás un NAT por AZ (más coste, más resiliencia). Los outputs del módulo exponen vpc_id, private_subnets, public_subnets, nat_public_ips y otros para usarlos en otros recursos (EC2, RDS, EKS). Así defines Terraform AWS VPC una vez y reutilizas en todos los entornos. Para RDS puedes usar database_subnets, create_database_subnet_group = true y opcionalmente create_database_subnet_route_table = true. Consulta los documentación del provider AWS para recursos concretos que consuman estos outputs.

Variables y configuración avanzada de Terraform AWS VPC

Externaliza nombre, CIDR, AZs y flags en variables.tf y pásalos al módulo; en outputs.tf expón module.vpc.vpc_id, module.vpc.private_subnets, module.vpc.public_subnet_ids, etc., para que otros módulos los usen. El módulo admite database_subnets y create_database_subnet_group = true para RDS; así puedes colocar bases de datos en subnets sin acceso directo desde internet. Activa enable_flow_logs si quieres auditoría de tráfico (los logs se envían a CloudWatch Logs o S3); útil para seguridad y troubleshooting. Para producción, usa al menos dos AZs y revisa los inputs del módulo en el Registry; tags consistentes (Environment, Terraform, Project) ayudan en costes y organización. Puedes usar public_subnet_tags y private_subnet_tags para que herramientas como el AWS Load Balancer Controller o EKS reconozcan las subnets. Enlaces útiles: módulos terraform-aws-modules y tutoriales Terraform AWS de HashiCorp.

Optimización y buenas prácticas con Terraform AWS VPC

Seguridad: Usa un backend remoto para el state (S3 + DynamoDB) y habilita cifrado del bucket; no subas state con secretos a repositorios públicos. IAM: limita los permisos del usuario o rol que ejecuta Terraform al mínimo necesario (VPC, EC2 para NAT si usas NAT Instance, etc.). Flow logs permiten detectar tráfico anómalo y cumplir requisitos de auditoría. Considera VPC Endpoints para servicios AWS (S3, DynamoDB) si quieres que el tráfico no salga a internet. Organización: Estructura el código en módulos reutilizables; usa workspaces o directorios por entorno (dev/staging/prod) con variables distintas. Naming conventions en recursos y tags facilitan la búsqueda y la facturación. Un terraform.tfvars.example documenta las variables esperadas sin exponer valores reales. State: Bloqueo del state con DynamoDB evita aplicaciones concurrentes; versionado del bucket S3 permite recuperar versiones anteriores. Con Terraform AWS VPC y estas prácticas la infraestructura de red queda escalable y mantenible en el tiempo.

Troubleshooting Terraform AWS VPC

Error de credenciales: Verifica AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y la región; prueba con aws sts get-caller-identity. Módulo no encontrado: Ejecuta terraform init de nuevo; si cambiaste la versión del módulo, terraform init -upgrade. Recursos ya existen: Si creaste recursos a mano, importa con terraform import o ajusta el código para que coincida con el estado real. Plan muestra muchos cambios inesperados: Revisa si alguien modificó recursos en la consola; evita cambios manuales en recursos gestionados por Terraform. NAT Gateway caro: En desarrollo usa single_nat_gateway = true o considera NAT Instance; para producción valora el coste frente a la alta disponibilidad. Documentación de Terraform: HashiCorp Terraform docs.

Conclusión

Con Terraform AWS VPC tienes redes definidas como código, reproducibles y documentadas: un solo módulo para VPC, subnets, NAT e Internet Gateway, con outputs listos para integrar con EC2, RDS o EKS. Versionando la configuración en Git y aplicando el mismo patrón en todos los entornos reduces errores y tiempo de operación. Como próximos pasos puedes añadir subnets de base de datos, flow logs, y enlazar esta VPC con más artículos del blog: Terraform AWS RDS y la categoría Terraform.

FAQ sobre Terraform AWS VPC

¿Cuánto cuesta un NAT Gateway?
En AWS se cobra por hora y por datos procesados. Para desarrollo usa single_nat_gateway = true para reducir coste; para producción valora un NAT por AZ.

¿Puedo usar Terraform AWS VPC con EKS?
Sí. El módulo tiene ejemplos y tags recomendados para subnets de Kubernetes; enlaza la VPC creada con tu módulo EKS usando los subnet_ids que expone el módulo.

¿Cómo actualizo el módulo?
Cambia la versión en version = "~> 5.0", ejecuta terraform init -upgrade y terraform plan para ver el impacto antes de aplicar.

¿Cómo gestiono el state file?
Usa un backend remoto (S3 + DynamoDB) y habilita cifrado y bloqueo; así el state no está en local y varios miembros del equipo pueden ejecutar Terraform de forma segura.

¿Puedo tener varias VPCs en el mismo proyecto Terraform?
Sí. Instancia el módulo varias veces con distintos name y CIDRs, o usa un módulo que reciba variables para entorno (dev/prod) y cree una VPC por entorno. Usa count o for_each si quieres generar varias VPCs desde una misma configuración.

¿Terraform AWS VPC es compatible con otros proveedores?
El módulo que hemos visto es específico de AWS. Para Azure o GCP existen módulos equivalentes en el Registry (por ejemplo terraform-azure-modules/vnet/azurerm); la idea de definir redes como código es la misma, cambian los recursos del provider.