programa
Profesional de AWS Cloud (CLF-C02)
10 h
He pasado innumerables horas haciendo clic en la consola de AWS, iniciando manualmente instancias EC2, configurando grupos de seguridad e, inevitablemente, cometiendo errores que llevan horas depurar. ¿Te suena familiar? Creas una instancia en la zona de disponibilidad incorrecta, olvidas etiquetar un recurso o pasas una tarde recreando la configuración exacta que creaste el mes pasado porque no documentaste los pasos.
El aprovisionamiento manual de infraestructura no solo es tedioso, sino que también es propenso a errores, no es escalable y es imposible de auditar. Ahí es donde Terraform lo cambia todo. Imagina definir toda tu infraestructura de AWS en archivos de texto que puedes controlar por versiones, revisar e implementar automáticamente. Ya no tendrás que hacer clic en docenas de pantallas. Se acabaron las conversaciones del tipo «pero en mi ordenador funcionaba» con tu equipo.
En este tutorial, te mostraré cómo automatizar la infraestructura de AWS utilizando Terraform, centrándome en un ejemplo real: aprovisionar una instancia EC2 con un agente SSM (Systems Manager) iniciado automáticamente. Al final, comprenderás los fundamentos de la infraestructura como código y tendrás un código funcional que podrás implementar inmediatamente en tu propia cuenta de AWS.
Si eres nuevo en AWS, considera la posibilidad de realizar uno de nuestros cursos, como Conceptos de AWS, Introducción a AWS Boto en Pythono Seguridad y gestión de costes de AWS.
¿Qué es Terraform?
Terraform es una herramienta de código abierto de infraestructura como código (IaC) creada por HashiCorp que te permite definir, aprovisionar y gestionar recursos en la nube utilizando el lenguaje de configuración de HashiCorp (HCL).
En lugar de hacer clic en consolas en la nube o escribir scripts bash imperativos, declaras la infraestructura que deseas en archivos de configuración y Terraform se encarga de los detalles para hacerla realidad. Este cambio de una infraestructura imperativa a una declarativa representa un cambio fundamental en la forma en que concebís los recursos en la nube.
Enfoque imperativo frente a declarativo para lanzar una instancia AWS EC2
Con los enfoques imperativos, escribes instrucciones paso a paso: «primero crea este grupo de seguridad, luego espera a que exista, después inicia esta instancia con ese grupo de seguridad, luego adjunta este volumen y, por último, crea estas etiquetas». Eres responsable de la secuencia exacta y de los errores de manipulación en cada paso.
Con el enfoque declarativo de Terraform, solo tienes que definir el estado final: Quiero una instancia EC2 con estas especificaciones, conectada a este grupo de seguridad y con estas etiquetas. Terraform analiza las dependencias, determina el orden correcto y ejecuta el plan. Si algo falla, Terraform sabe exactamente dónde se ha quedado.
¿Por qué elegir Terraform específicamente para AWS?
- En primer lugar, el ecosistema de la comunidad es enorme, y encontrarás módulos, ejemplos y soluciones para casi todos los servicios de AWS imaginables.
- En segundo lugar, Terraform es independiente del proveedor. Apréndelo una vez y podrás aplicar las mismas habilidades y patrones en AWS, Azure, GCP y otras plataformas. Evita la dependencia de un proveedor concreto y mantén un flujo de trabajo coherente.
- En tercer lugar, el sistema de gestión de estado de Terraform realiza un seguimiento de todos los recursos, lo que hace que las actualizaciones y los cambios sean predecibles. Terraform sabe lo que has creado y puede modificarlo o destruirlo de forma segura.
Antes de sumergirte en la configuración práctica, debes comprender tres conceptos clave que constituyen la base de Terraform:
- Los recursos son los componentes de infraestructura que creas: instancias EC2, buckets S3, grupos de seguridad.
- Los proveedores son complementos que permiten a Terraform interactuar con diferentes plataformas; el proveedor AWS traduce tu HCL a llamadas a la API de AWS.
- HCL es la sintaxis legible por humanos que utilizarás para definir la infraestructura, diseñada para ser expresiva y sencilla.
Una vez aclarados estos conceptos básicos, preparemos tu entorno para empezar a construir la infraestructura real.
Configuración del entorno AWS de Terraform
Antes de escribir cualquier código Terraform, necesitas tener instalada la CLI y configurar las credenciales de AWS. Déjame explicarte ambos.
Instalar Terraform
La instalación de Terraform varía según el sistema operativo:
-
En macOS, utiliza Homebrew: primero instala HashiCorp tap con
brew tap hashicorp/tapy, a continuación, instala Terraform conbrew install hashicorp/tap/terraform. -
En Windows, descarga el binario desde hashicorp.com y añádelo a tu PATH, o utiliza Chocolatey:
choco install terraform. -
En Linux, descarga el paquete adecuado o utiliza el gestor de paquetes de tu distribución.
Una vez instalado, verifica la instalación ejecutando terraform version.
Configurar las credenciales de AWS
Para configurar las credenciales de AWS, necesitas una cuenta de AWS, una clave de acceso y un secreto de IAM. Nunca utilices tu cuenta de root. En su lugar, crea un usuario de IAM con acceso programático y los permisos adecuados (AdministratorAccess). El enfoque estándar utiliza el archivo de credenciales de AWS en ~/.aws/credentials:
[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEYComo alternativa, configura las variables de entorno: AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY. Para entornos de producción, utiliza roles de IAM asociados a instancias EC2 o sistemas CI/CD en lugar de credenciales de larga duración.
Si estás pensando en utilizar un ecosistema diferente al de Amazon o simplemente quieres obtener una buena visión general de cómo se comparan los «tres grandes», te recomiendo leer esta comparación de servicios de AWS, Azure y GCP para ciencia de datos e inteligencia artificial.
Implementación de un agente EC2 con Terraform en AWS
Ahora que ya tenemos la base, construyamos algo real: una instancia EC2 que instale automáticamente el agente SSM al iniciarse.
Configuración de la estructura del proyecto
Los proyectos de Terraform se benefician de un enfoque claro y estructurado. Crea tres archivos: main.tf para las definiciones de recursos, variables.tf para las entradas y outputs.tf para los valores que necesitarás después de la implementación. Esta separación mantiene tu código organizado y fácil de mantener.
aws-terraform
├── main.tf
├── output.tf
└── variables.tfHe aquí por qué es importante: a medida que los proyectos crecen, mezclar todo en un solo archivo se vuelve imposible de mantener. Las variables te permiten reutilizar el mismo código en diferentes entornos (desarrollo, staging, producción) cambiando las entradas. Los resultados proporcionan los valores que necesitarás, como ID de instancia o direcciones IP, sin necesidad de buscar manualmente en la consola de AWS.
Escribir la configuración de recursos EC2
Ahora vamos a crear la infraestructura: una instancia EC2 con el agente SSM preinstalado. En el archivo main.tf, agrega la siguiente configuración:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
}
provider "aws" {
region = "eu-central-1"
}
data "aws_ami" "amazon_linux" {
most_recent = true
filter {
name = "name"
values = ["amzn2-ami-hvm-*-x86_64-gp2"]
}
filter {
name = "virtualization-type"
values = ["hvm"]
}
owners = ["amazon"]
}
resource "aws_instance" "web_server" {
ami = data.aws_ami.amazon_linux.id
instance_type = "t2.micro"
iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
user_data = <<-EOF
#!/bin/bash
cd /tmp
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent
EOF
tags = {
Name = "TerraformWebServer"
}
}
resource "aws_iam_instance_profile" "ssm_profile" {
name = "ec2-ssm-profile"
role = aws_iam_role.ssm_role.name
}
resource "aws_iam_role" "ssm_role" {
name = "ec2-ssm-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ec2.amazonaws.com"
}
}]
})
}
resource "aws_iam_role_policy_attachment" "ssm_policy" {
role = aws_iam_role.ssm_role.name
policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}
Configuración de la instancia EC2 de Terraform
El bloque ` data ` consulta AWS para obtener la AMI más reciente de Amazon Linux 2. Los filtros garantizan que obtengas el tipo de imagen adecuado, y owners = ["amazon"] garantiza que estés utilizando AMI oficiales de Amazon. Este enfoque funciona en todas las regiones sin modificaciones: Terraform encuentra automáticamente la AMI regional correcta.
La parte crucial es user_data: un script de terminal que se ejecuta cuando la instancia se inicia por primera vez. Este script descarga e instala el agente SSM y, a continuación, lo habilita para que se inicie automáticamente. La función IAM proporciona los permisos que SSM necesita para administrar la instancia.
El mismo patrón funciona para cualquier agente. ¿Quieres CloudWatch para registros y métricas? Solo tienes que modificar el script user_data para instalar el agente CloudWatch en su lugar. El principio sigue siendo el mismo: define lo que deseas instalar y Terraform se encarga de que se instale en todas las instancias.
En el archivo output.tf, puedes añadir, por ejemplo, el ID de la instancia. A continuación, una vez que ejecuten todos los comandos de Terraform que voy a explicar en el siguiente capítulo, el valor aparecerá en la terminal.
output "instance_id" {
description = "EC2 instance ID for SSM connection"
value = aws_instance.web_server.id
}Inicialización y aplicación de la configuración
Una vez escrita la configuración, el flujo de trabajo de Terraform tiene tres comandos. En primer lugar, el siguiente comando descarga el complemento del proveedor AWS y prepara tu directorio:
terraform init
terraform init
En segundo lugar, terraform plan muestra exactamente lo que Terraform creará, modificará o destruirá. Esta vista previa te permite detectar errores antes de realizar cambios reales:
terraform plan
plan de terraform
Revisa cuidadosamente el resultado. Verás la instancia EC2, la función IAM, el perfil de instancia y el archivo adjunto de política que creará Terraform.
Por último, terraform apply ejecuta los cambios. Terraform solicita confirmación antes de continuar. Escribe «yes» después de ejecutar este comando:
terraform apply
aplicar terraform
Si todo funciona correctamente, aparecerá el siguiente mensaje una vez creados los recursos.
Confirmación: Recursos Terraform creados
En cuestión de minutos, tendrás una instancia EC2 en funcionamiento con SSM configurado, accesible sin claves SSH. Asegúrate de consultar la consola de AWS para ver los recursos creados recientemente.
Gestión del estado de Terraform en AWS S3
Después de ejecutar los comandos anteriores, verás un nuevo archivo en el directorio llamado terraform.tfstate. El archivo de estado de Terraform asigna tu configuración a recursos reales de AWS. Repasemos este archivo para comprender su contenido.
Comprender el archivo de estado
El archivo de estado contiene todos los detalles sobre tu infraestructura implementada: ID de recursos, direcciones IP y dependencias. Terraform compara este estado con tu configuración y el estado real de AWS para determinar qué acciones tomar. Si pierdes el archivo de estado, Terraform perderá el rastro de todo lo que ha creado.
Guardar datos en tu ordenador portátil es peligroso. Si tu máquina se bloquea, el estado desaparece. Si varios miembros del equipo trabajan en la misma infraestructura, los estados locales conflictivos provocan corrupción. La solución: almacenamiento remoto de estado.
Para obtener información detallada sobre S3 y EFS, consulta este tutorial sobre almacenamiento de AWS.
Configuración de un backend S3 remoto
El backend S3 de Terraform almacena el estado en una ubicación centralizada y duradera accesible para todo tu equipo. Primero, crea un bucket S3:
aws s3api create-bucket \
--bucket datacamp-terraform-state \
--region eu-central-1 \
--create-bucket-configuration LocationConstraint=eu-central-1
aws s3api put-bucket-versioning \
--bucket datacamp-terraform-state \
--versioning-configuration Status=EnabledEl control de versiones es fundamental: te permite recuperarte de accidentes volviendo a versiones anteriores.
Ahora, añade la configuración del backend a tu código Terraform:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
backend "s3" {
bucket = "datacamp-terraform-state"
key = "terraform.tfstate"
region = "eu-central-1"
use_lockfile = true
}
}Ejecuta de nuevo terraform init para migrar tu estado local a S3. Terraform solicitará confirmación antes de mover el archivo de estado.
Backend remoto Terraform S3
Después de ejecutar el comando, el bucket S3 contendrá el nuevo archivo de estado. Puedes comprobarlo en la consola de AWS.
Estado de bloqueo con archivos de bloqueo S3 nativos
Probablemente hayas visto que hemos añadido el siguiente comando al archivo main.tf: use_lockfile = true . Esta configuración habilita la función más reciente de Terraform: el bloqueo de estado S3 nativo. Anteriormente, se necesitaba una tabla DynamoDB independiente para el bloqueo.
Estado de bloqueo de Terraform
Esta simplificación elimina todo un servicio de AWS de la configuración de tu infraestructura, al tiempo que proporciona la misma protección contra las condiciones de carrera. Varios ingenieros pueden trabajar en la infraestructura de forma segura, sabiendo que solo se aplicarán los cambios de una persona a la vez.
Ampliación de la infraestructura con Terraform en AWS
A medida que tu infraestructura crece, los valores codificados y el código copiado y pegado se convierten en una pesadilla para el mantenimiento. El sistema de variables y los módulos de Terraform resuelven este problema.
Refactorización con variables de entrada
Anteriormente, creamos el archivo variables.tf. Ahora puedes mover los valores, que anteriormente estaban codificados de forma fija en main.tf, a este nuevo archivo que contendrá nuestras variables:
variable "aws_region" {
description = "AWS region for resources"
type = string
default = "eu-central-1"
}
variable "instance_type" {
description = "EC2 instance type"
type = string
default = "t2.micro"
}Ahora haz referencia a las variables de tus recursos en el archivo main.tf:
provider "aws" {
region = var.aws_region
}
resource "aws_instance" "web_server" {
instance_type = var.instance_type
# ... rest of configuration
tags = {
Environment = var.environment
}
}Ten en cuenta que los buckets de AWS S3 son únicos, por lo que no puedes utilizar variables en la región en el parámetro backend de main.tf. Aquí, debes mantener tu región codificada de forma fija, como “eu-central-1” en lugar de var.region_aws.
Ahora que ya hemos definido nuestras variables, también puedes definir diferentes entornos, como desarrollo o producción, en los que las variables pueden variar. Esto se hace creando nuevos archivos con la extensión .tfvars.
Por ejemplo, puedes crear un terraform-dev.tfvars para desarrollo y un terraform-prod.tfvars para producción:
Desarrollo:
aws_region = "eu-central-1"
instance_type = "t2.micro"Producción:
aws_region = "eu-central-1"
instance_type = "t3.medium"A continuación, puedes implementar en los diferentes entornos especificando el archivo adecuado:
terraform apply -var-file="terraform-dev.tfvars”Las variables resuelven el problema de los valores específicos del entorno, pero ¿qué pasa con la duplicación de patrones completos de infraestructura? Ahí es donde los módulos se vuelven esenciales.
Creación de módulos de recursos reutilizables
Los módulos agrupan recursos relacionados en componentes reutilizables. La mejor manera de utilizar los módulos es creando una carpeta específica. Por ejemplo, puedes crear una estructura de directorios como esta:
modules/
ec2-with-ssm/
main.tf
variables.tf
outputs.tfPuedes mover el archivo variables.tf creado anteriormente (o crear uno nuevo) a la carpeta del módulo. El cambio clave se produce en el archivo main.tf. El del módulo debe contener nuestros recursos. Así que todo, desde el AMI hasta el final del archivo, se moverá allí:
data "aws_ami" "amazon_linux" {
most_recent = true
filter {
name = "name"
values = ["amzn2-ami-hvm-*-x86_64-gp2"]
}
filter {
name = "virtualization-type"
values = ["hvm"]
}
owners = ["amazon"]
}
resource "aws_instance" "web_server" {
ami = data.aws_ami.amazon_linux.id
instance_type = var.instance_type
iam_instance_profile = aws_iam_instance_profile.ssm_profile.name
user_data = <<-EOF
#!/bin/bash
cd /tmp
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent
EOF
tags = {
Name = "TerraformWebServer"
}
}
resource "aws_iam_instance_profile" "ssm_profile" {
name = "ec2-ssm-profile"
role = aws_iam_role.ssm_role.name
}
resource "aws_iam_role" "ssm_role" {
name = "ec2-ssm-role"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ec2.amazonaws.com"
}
}]
})
}
resource "aws_iam_role_policy_attachment" "ssm_policy" {
role = aws_iam_role.ssm_role.name
policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}Para reemplazar este cambio, mantén el resto del archivo, pero añade un parámetro de módulo que haga referencia al módulo específico.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
backend "s3" {
bucket = "datacamp-terraform-state"
key = "terraform.tfstate"
region = "eu-central-1"
use_lockfile = true
}
}
provider "aws" {
region = var.aws_region
}
module "web_server" {
source = "./modules/ec2-with-ssm"
instance_type = var.instance_type
}Ahora, si ejecutas los comandos init, plan y apply con esta configuración, terminarás implementando los mismos recursos que antes. La diferencia es que los módulos te permiten lanzar infraestructuras con configuraciones similares que se pueden reutilizar. Son fundamentales para ampliar Terraform más allá de proyectos sencillos.
Ahora pasemos a otro tema importante: la seguridad.
Prácticas recomendadas de seguridad para Terraform en AWS
El código de infraestructura requiere el mismo rigor de seguridad que el código de aplicación. Por lo tanto, es fundamental proteger tus implementaciones de Terraform.
Gestión de secretos y datos confidenciales
Nunca guardes secretos en Git. Siempre. Utiliza AWS Secrets Manager para valores confidenciales. Puedes utilizar el siguiente recurso en Terraform para hacerlo:
resource "aws_secretsmanager_secret" "example" {
name = "example"
}Para los secretos específicos del entorno, puedes utilizar variables de entorno con el prefijo TF_VAR_.
Por ejemplo, puedes utilizar variable "aws_access_key" {} en el archivo variables.tf y exportarlo en la terminal con export TF_VAR_aws_access_key=. Terraform carga automáticamente estos valores como variables sin exponerlos en el código.
Gestión de desviaciones en la configuración
Otro tema importante relacionado con la configuración es la deriva. Esto ocurre cuando alguien modifica la infraestructura a través de la consola o la CLI de AWS, sin pasar por Terraform. Ejecuta terraform plan con regularidad para detectar desviaciones. El resultado del plan muestra los recursos que existen pero que no coinciden con tu configuración.
Cuando aparece una desviación, tienes dos opciones: actualizar tu código Terraform para que coincida con la realidad o ejecutar « terraform apply » para forzar que la infraestructura vuelva al estado deseado. La elección correcta depende de si el cambio manual fue intencionado.
Limpieza de recursos
Por último, también es importante eliminar todos los recursos una vez que sabemos que no los necesitamos, para evitar costes innecesarios. Puedes limpiar los recursos con el siguiente comando:
terraform destroyRevisa cuidadosamente el plan de destrucción. Terraform eliminará todos los recursos que haya creado. Para la producción, considera la posibilidad de utilizar terraform destroy -target para eliminar recursos específicos en lugar de todo.
Conclusión
Has aprendido el flujo de trabajo básico de Terraform: definir la infraestructura en código, previsualizar los cambios con plan, aplicarlos con apply y realizar un seguimiento de todo con la gestión del estado. Cubrimos la implementación de EC2 con instalación automática de agentes, trasladamos el estado a S3 con bloqueo nativo, escalamos con variables y módulos, y protegimos la infraestructura con la gestión de secretos.
Trata el código de infraestructura con el mismo rigor que el código de aplicación. Utiliza el control de versiones, exige revisiones del código para los cambios y realiza primero las pruebas en entornos que no sean de producción. Las canalizaciones CI/CD pueden automatizar terraform apply, haciendo que las actualizaciones de la infraestructura sean tan fluidas como las implementaciones de aplicaciones.
Tu próximo paso: explora GitHub Actions o GitLab CI para ejecutar Terraform automáticamente cuando envíes código. Este enfoque de infraestructura como código, combinado con la automatización, transforma la forma en que los equipos gestionan los recursos en la nube, sustituyendo el trabajo manual en la consola por una infraestructura fiable, repetible y con control de versiones.
Mi recomendación es que aproveches estos conocimientos y te inscribas en el curso AWS Cloud Practitioner (CLF-C02) , que es un programa que te enseña todo lo que necesitas saber para obtener la certificación CLF-C02 de Amazon.
