Tu primer servidor en AWS con Terraform (2026)

Terraform es una herramienta de Infrastructure as Code (IaC) que te permite describir tu infraestructura en archivos de configuración y desplegarla con un solo comando. Según una guía publicada el 21 de mayo de 2026, es posible levantar un servidor EC2 en AWS con Apache corriendo en menos de 30 minutos, sin tocar la consola web de Amazon.

¿Qué es Infrastructure as Code y por qué Terraform?

Terraform es una herramienta open source de HashiCorp que te permite definir infraestructura en la nube como código declarativo. En vez de entrar a la consola de AWS, hacer clic en “Launch Instance”, elegir AMI, configurar el security group, y rezar para acordarte de todos los pasos la próxima vez, escribís un archivo de texto que describe exactamente qué querés y Terraform lo crea.

El cambio de mentalidad es importante. No le decís “creá una instancia EC2”. Le decís “quiero que exista una instancia EC2 con estas características” y Terraform se encarga de llegar a ese estado desde donde sea que estés. Si la instancia ya existe y coincide con tu definición, no hace nada. Si hay diferencias, las resuelve.

Eso sí: hay varias herramientas de IaC dando vueltas. CloudFormation es la opción nativa de AWS, Pulumi te deja usar Python o TypeScript, Ansible va más por el lado de configuración que de infraestructura. Terraform tiene la ventaja de ser multi-cloud (AWS, Azure, Google Cloud, y decenas más) y tiene una comunidad enorme. Para la mayoría de los equipos DevOps en 2026, es el estándar de facto.

Requisitos previos: AWS CLI, credenciales y Terraform instalado

Antes de escribir una sola línea de Terraform, necesitás tres cosas funcionando:

• Cuenta de AWS con Free Tier activo: la instancia t2.micro que vamos a crear es elegible para el Free Tier, así que si es tu primera cuenta, no te cuesta nada.
• AWS CLI instalada y configurada: descargala desde la documentación oficial de AWS. Después ejecutás aws configure y cargás tu Access Key ID y Secret Access Key. Las encontrás en IAM, en tu usuario, bajo “Security credentials”.
• Terraform instalado: descargalo desde terraform.io. En Windows podés usar winget install HashiCorp.Terraform, en Mac brew install terraform, en Linux hay paquetes para todas las distros.

Para verificar que todo está en orden: aws sts get-caller-identity te devuelve tu Account ID si las credenciales están bien configuradas. terraform version te dice qué versión tenés instalada. Si ambos comandos responden sin errores, estás listo.

Un detalle que mucha gente saltea: si estás en una empresa, es posible que necesites configurar un perfil de AWS específico o variables de entorno (AWS_PROFILE, AWS_DEFAULT_REGION). Terraform hereda esas variables, así que si tu CLI funciona, Terraform también debería funcionar.

Los dos bloques fundamentales de Terraform: provider y resource

Cualquiera que haya trabajado con Terraform sabe que todo parte de estos dos bloques. Vale la pena entenderlos bien antes de escribir código. Más contexto en automatizar tu pipeline de deployment.

El bloque provider

Le dice a Terraform dónde desplegar. Especifica el cloud, la región, y cómo autenticarse. Para AWS, la configuración mínima es esta:

provider "aws" {
  region = "us-east-1"
}

Eso es todo. Terraform va a usar las credenciales del AWS CLI que configuraste antes. Si querés ser explícito sobre el perfil, podés agregar profile = "mi-perfil".

El bloque resource

Le dice a Terraform qué crear. Cada recurso tiene un tipo (como aws_instance o aws_security_group) y un nombre local que usás para referenciarlo en otros bloques. La estructura es siempre:

resource "tipo_de_recurso" "nombre_local" {
  argumento = valor
}

¿Y qué diferencia hay entre los dos? El provider dice “trabajá con AWS en us-east-1”. El resource dice “creá una instancia EC2 con estas propiedades”. Sin provider, Terraform no sabe a dónde conectarse. Sin resource, no tiene nada que hacer.

Tu primer servidor en AWS: el código completo paso a paso

Creá una carpeta nueva, por ejemplo mi-primer-servidor, y dentro un archivo main.tf. Este es el código completo para levantar una EC2 con Apache corriendo: Relacionado: optimizar contenido en múltiples idiomas.

Paso 1: el provider

provider "aws" {
  region = "us-east-1"
}

Paso 2: el security group

resource "aws_security_group" "web_sg" {
  name = "web-server-sg"
  ingress {
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port = 0
    to_port = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Paso 3: la instancia EC2 con user data

resource "aws_instance" "web_server" {
  ami = "ami-0c02fb55956c7d316"
  instance_type = "t2.micro"
  vpc_security_group_ids = [aws_security_group.web_sg.id]
  user_data = <<-EOF
    #!/bin/bash
    yum update -y
    yum install -y httpd
    systemctl start httpd
    systemctl enable httpd
    echo "<h1>Servidor desplegado con Terraform</h1>" > /var/www/html/index.html
    EOF
  tags = {
    Name = "MiPrimerServidor"
  }
}

Paso 4: el output con la IP pública

output "public_ip" {
  value = aws_instance.web_server.public_ip
}

Guardás el archivo y estás listo para el siguiente paso.

Seguridad: qué hace ese security group y qué no hace

El security group es el firewall virtual que controla qué tráfico puede entrar y salir de tu instancia. En el ejemplo de arriba, abrimos el puerto 80 (HTTP) al mundo entero (0.0.0.0/0). Para un servidor web público, tiene sentido.

Lo que no abrimos es el puerto 22 (SSH). Esto es intencional: no necesitás SSH si tu configuración inicial la hacés con user data (más sobre eso abajo). Un puerto 22 abierto al mundo es un problema de seguridad real. Si alguna vez necesitás acceso SSH, la práctica correcta es restringir el cidr_blocks a tu IP: ["TU.IP.AQUI/32"].

La regla de egress con protocol = "-1" permite todo el tráfico saliente. Para un servidor de producción querrías ser más restrictivo, pero para aprender está bien. Te puede servir nuestra cobertura de ejecutar agentes en tu infraestructura.

User data: automatizá la configuración al arranque

El bloque user_data es un script bash que AWS ejecuta cuando la instancia arranca por primera vez. Instalás Apache, lo iniciás, escribís el HTML, y cuando Terraform termina de crear el servidor, ya tiene todo corriendo (con un pequeño delay de 1-2 minutos mientras el script se ejecuta).

Ponele que normalmente harías esto: SSH a la instancia, actualizás paquetes, instalás el servidor web, configurás el servicio, subís tus archivos. Ahora ese proceso está en código, se ejecuta solo, y si el servidor muere y levantás uno nuevo, queda configurado igual.

La limitación de user data es que solo corre una vez, al primer arranque. Para configuración más compleja o que necesite actualizarse frecuentemente, herramientas como Ansible o Chef tienen más sentido. Para esto, zafa perfectamente.

El flujo de trabajo: init, plan, apply y destroy

Tenés el archivo main.tf listo. Ahora:

• terraform init: descarga el provider de AWS (el plugin que sabe cómo hablarle a la API de Amazon). Solo lo necesitás la primera vez o cuando cambiás providers.
• terraform plan: muestra exactamente qué va a crear, modificar o eliminar. No hace ningún cambio. Leé esto siempre antes de ejecutar apply.
• terraform apply: aplica los cambios. Te pide confirmación (escribís “yes”). Crea los recursos y al final imprime los outputs, incluyendo la IP pública.
• terraform destroy: elimina todo lo que Terraform creó. Fundamental para evitar costos cuando terminás de probar.

¿Cuánto tarda? El plan es casi instantáneo. El apply tarda entre 30 segundos y 2 minutos dependiendo de AWS. La IP pública aparece en el output apenas Terraform termina.

Verificación: tu servidor corriendo en el navegador

Copiás la IP que aparece en el output de Terraform, abrís el navegador y navegás a http://TU_IP_PUBLICA. Si todo salió bien, ves el HTML que inyectaste en el user data.

Si no carga, revisá en este orden:

• ¿El security group tiene el puerto 80 abierto? (terraform show te muestra el estado actual)
• ¿La instancia terminó de ejecutar el user data? Esperate 2 minutos y probá de nuevo.
• ¿Estás usando http:// y no https://? No configuramos HTTPS todavía.
• ¿El AMI de Amazon Linux 2 es correcto para la región que elegiste? Los AMI IDs varían por región.

Comparativa: Terraform vs consola web de AWS vs CLI de AWS

Método	Repetibilidad	Versionado	Curva de entrada	Ideal para
Consola web AWS	Manual, propenso a errores	No	Muy baja	Explorar, aprender la UI
AWS CLI	Scripts bash posibles	Con scripts en git	Media	Automatizaciones simples
CloudFormation	Alta	Sí	Alta (YAML verbose)	Proyectos 100% AWS
Terraform	Alta	Sí (archivos .tf)	Media	Multi-cloud, equipos DevOps

Para hosting de servidores web en Argentina, muchos equipos combinan Terraform para la infra en cloud con proveedores locales como donweb.com para los dominios y CDN de la región. No es excluyente.

Errores comunes al arrancar con Terraform en AWS

Error 1: usar el AMI ID de otra región

El AMI ami-0c02fb55956c7d316 es Amazon Linux 2 en us-east-1. Si cambiás la región a us-west-2, ese AMI no existe y Terraform falla. Buscá el AMI correcto para tu región en la documentación de EC2 o usá un data source de Terraform para buscarlo dinámicamente.

Error 2: correr terraform apply sin leer el plan

El plan te dice exactamente qué va a pasar. Si ves Plan: 5 to add, 0 to change, 3 to destroy y esperabas solo agregar, algo está mal. Leé el plan siempre. El costo de ignorarlo puede ser una instancia de producción destruida. Sobre eso hablamos en fortalecer la seguridad de tu servidor.

Error 3: no hacer destroy después de practicar

Una instancia t2.micro corriendo las 24 horas fuera del Free Tier cuesta alrededor de USD 8-9 por mes. Parece poco, pero si tenés 5 servidores de prueba olvidados, se acumula. terraform destroy tarda menos de un minuto y deja todo limpio.

Error 4: subir las credenciales de AWS al repositorio

Nunca pongas el Access Key y el Secret Key directamente en el archivo .tf. Si ese archivo va a git, tus credenciales quedan expuestas. Usá aws configure o variables de entorno. Terraform las toma automáticamente del CLI sin que las especifiques en el código.

Preguntas Frecuentes

¿Necesito saber programar para usar Terraform?

No en el nivel básico. El lenguaje de Terraform (HCL) es declarativo: describís qué querés, no cómo hacerlo. Con entender la diferencia entre bloques provider y resource, y saber leer mensajes de error, podés arrancar. Cuando llegues a módulos reutilizables, variables dinámicas o condicionales, ahí sí conviene tener algo de experiencia con lógica de programación.

¿Cuál es la diferencia entre provider y resource en Terraform?

El provider define la plataforma y las credenciales de conexión (AWS en us-east-1, por ejemplo). El resource define un elemento concreto de infraestructura dentro de esa plataforma (una instancia EC2, un bucket S3, un security group). Un archivo Terraform tiene un solo provider por plataforma pero puede tener decenas de resources.

¿Por qué usar Terraform en lugar de la consola web de AWS?

Con la consola hacés un servidor en 10 minutos, pero no podés repetir el proceso exacto ni guardarlo en control de versiones. Con Terraform, el mismo archivo crea la misma infraestructura en cualquier cuenta, cualquier región, cualquier cantidad de veces. Para equipos o para proyectos que van a crecer, el tiempo que “perdés” aprendiendo Terraform lo recuperás la primera vez que tenés que replicar o reconstruir algo.

¿Cómo configuro las credenciales de AWS para que Terraform las use?

Instalás AWS CLI y ejecutás aws configure. Te pide el Access Key ID, el Secret Access Key, la región default y el formato de output. Terraform busca esas credenciales automáticamente en ~/.aws/credentials. No necesitás especificarlas en ningún archivo .tf, y definitivamente no debés hacerlo.

¿Qué pasa si modifico el archivo .tf después de un apply?

Terraform compara el estado actual (guardado en terraform.tfstate) con tu nueva configuración y calcula el diff. En el próximo terraform apply, solo aplica los cambios necesarios. Si cambiás el tipo de instancia, puede destruir la instancia existente y crear una nueva (algunos cambios son destructivos). El plan te lo muestra antes de ejecutar.

Conclusión

La guía publicada el 21 de mayo de 2026 en Dev.to demuestra algo que mucha gente posterga por parecer “demasiado complejo”: levantar tu primer servidor con Terraform AWS toma menos de media hora si tenés los prereqs listos. El verdadero valor no está en ahorrarte clicks, está en que ese servidor queda documentado en código, versionable en git, reproducible.

Si administrás servidores manualmente o dependés de la consola web de AWS, el paso siguiente es claro: instalá Terraform, configurá las credenciales, y replicá este ejemplo. Cuando lo hayas hecho una vez, la segunda vez se hace solo, y la décima se hace en segundos con módulos reutilizables.

Fuentes

• Dev.to — Deploying Your First Server with Terraform: A Beginner’s Guide (2026-05-21)
• HashiCorp — Documentación oficial de Terraform
• Amazon Web Services — Documentación de EC2