Backends remotos: S3, Azure, GCS y HCP Terraform

Los backends remotos son esenciales para trabajar en equipo: permiten compartir el estado, habilitar el locking y mantener los secretos fuera del disco local. Esta guía cubre los backends más usados y sus diferencias clave.

Contenido

Backend local (default)
Backend S3 (AWS)
Backend Azure Storage
Backend GCS (Google)
Backend HCP Terraform
Configuración parcial y migración

Backend local (default)

Si no configuras un backend, Terraform usa el backend local por defecto. El estado se almacena en terraform.tfstate en el directorio de trabajo.

✅ Ventajas del backend local

• Sin configuración necesaria — funciona de inmediato
• Ideal para aprender y experimentar
• Perfecto para proyectos personales de una persona

⚠️ Limitaciones del backend local

• Locking solo en la misma máquina — no sirve para equipos
• Estado en disco local — no compartido
• Secretos en texto plano en el sistema de archivos
• Sin historial de versiones del estado

# Backend local explícito (equivalente al comportamiento por defecto)
terraform {
  backend "local" {
    path = "terraform.tfstate"    # ruta del archivo de estado
  }
}

# O simplemente no definir ningún backend — el local es el default

Backend S3 (AWS)

El backend S3 es el más usado en entornos AWS. Almacena el estado en un bucket S3 y, desde Terraform 1.11, hace locking nativo con un archivo .tflock en el propio bucket (use_lockfile = true). El locking con DynamoDB (dynamodb_table) está deprecado.

terraform {
  backend "s3" {
    bucket         = "mi-empresa-terraform-state"  # nombre del bucket S3
    key            = "prod/vpc/terraform.tfstate"  # ruta del archivo dentro del bucket
    region         = "us-east-1"                   # región del bucket

    # Locking nativo en S3 (Terraform 1.11+) — crea <key>.tflock en el bucket
    use_lockfile   = true                          # sin esto no hay locking

    # Cifrado en reposo
    encrypt        = true                          # SSE-S3 o SSE-KMS
    kms_key_id     = "arn:aws:kms:..."             # opcional: usar KMS específico

    # Perfil AWS (alternativa a variables de entorno)
    profile        = "mi-perfil-aws"               # opcional
  }
}

# Legacy (deprecado): dynamodb_table = "terraform-state-lock"
# con una tabla DynamoDB cuya clave primaria es LockID (String)

Argumento	Requerido	Descripción
bucket	✅ Sí	Nombre del bucket S3 donde se almacena el estado
key	✅ Sí	Ruta del objeto dentro del bucket (ej: prod/tfstate)
region	✅ Sí	Región AWS del bucket
use_lockfile	❌ No*	* Sin esto no hay locking. Lock nativo en S3 (1.11+); reemplaza a dynamodb_table (deprecado).
encrypt	❌ No	Si true, habilita cifrado SSE del archivo de estado
kms_key_id	❌ No	ARN de la clave KMS para SSE-KMS (más seguro que SSE-S3)

Backend Azure Storage

Azure Storage proporciona locking nativo mediante Blob Leases, sin necesidad de un recurso adicional (igual que S3 con use_lockfile).

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "samiempresatfstate"     # nombre único global
    container_name       = "tfstate"                # blob container
    key                  = "prod.terraform.tfstate" # nombre del blob

    # Autenticación (varias opciones):
    # 1. Variables de entorno ARM_* (recomendado en CI/CD)
    # 2. Azure CLI (az login) para uso local
    # 3. Managed Identity en VMs/AKS
  }
}

# Ventaja sobre S3: el locking es automático via Blob Lease
# No necesitas un recurso adicional para el locking

Backend GCS (Google Cloud Storage)

GCS también proporciona locking nativo, simplificando la configuración respecto a S3.

terraform {
  backend "gcs" {
    bucket  = "mi-empresa-terraform-state"    # nombre del bucket GCS
    prefix  = "terraform/prod"               # prefijo para los objetos de estado

    # Autenticación: usa Application Default Credentials (gcloud auth)
    # O: credentials = "/ruta/a/service-account.json" (no recomendado hardcodear)
  }
}

# GCS soporta locking nativo vía object locking
# No necesita recurso adicional (igual que Azure, diferente a S3)

Backend HCP Terraform / cloud

HCP Terraform (antes Terraform Cloud) tiene una integración especial más profunda que los backends de almacenamiento tradicionales: no solo almacena el estado sino que también ejecuta los planes y applies remotamente.

# Opción 1: Bloque cloud (recomendado para HCP Terraform)
terraform {
  cloud {
    organization = "mi-empresa"

    workspaces {
      name = "prod-vpc"          # workspace específico
      # O por tags:
      # tags = ["prod", "networking"]
    }
  }
}

# Opción 2: Backend "remote" (forma antigua, aún soportada)
terraform {
  backend "remote" {
    organization = "mi-empresa"

    workspaces {
      name = "prod-vpc"
    }
  }
}

# Autenticación: terraform login
# O: variable de entorno TF_TOKEN_app_terraform_io

🎯 cloud vs remote backend

El bloque cloud es la forma moderna de conectar con HCP Terraform (introducido en Terraform 1.1). El backend remote es el método antiguo que sigue funcionando. Para nuevas configuraciones, usa siempre el bloque cloud.

Configuración parcial y migración

La configuración parcial de backend permite no hardcodear información sensible (credenciales, nombres de buckets) directamente en los archivos .tf.

# CONFIGURACIÓN PARCIAL — no hardcodes credenciales en el bloque backend
terraform {
  backend "s3" {
    # Solo la configuración estática (no sensible):
    region  = "us-east-1"
    encrypt = true
    # bucket y key se pasan en init
  }
}

# Pasar la config restante en terraform init:
terraform init   -backend-config="bucket=mi-empresa-tfstate"   -backend-config="key=prod/vpc/terraform.tfstate"   -backend-config="use_lockfile=true"

# O desde un archivo HCL (sin el bloque terraform {}):
# backend.hcl:
#   bucket         = "mi-empresa-tfstate"
#   key            = "prod/vpc/terraform.tfstate"
#   use_lockfile   = true

terraform init -backend-config=backend.hcl

# MIGRACIÓN DE ESTADO entre backends:
# 1. Cambia el bloque backend en el .tf
# 2. Ejecuta:
terraform init -migrate-state
# Terraform preguntará confirmación para mover el estado

Backend	Locking	Cifrado nativo	Config extra para locking
Local	✅ Sí	❌ No	Ninguno (bloqueo de archivo, solo en la misma máquina)
S3	✅ Sí	✅ Sí	use_lockfile = true (DynamoDB legacy, deprecado)
Azure Storage	✅ Sí	✅ Sí	Ninguno (Blob Lease automático)
GCS	✅ Sí	✅ Sí	Ninguno (nativo)
HCP Terraform	✅ Sí	✅ Sí	Ninguno (automático)

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Un equipo quiere usar el backend S3 para el estado de Terraform pero necesita que no aparezcan credenciales ni el nombre del bucket en los archivos .tf del repositorio. ¿Cuál es la solución correcta?

¿Listo para poner a prueba "Backends remotos: S3, Azure, GCS y HCP Terraform"?

Pon a prueba lo que aprendiste con preguntas originales del examen Terraform Associate.

Iniciar simulacro Terraform Associate

Sin límite de simulacros con plan Pro

Inicia sesión para llevar tu progreso.

AnteriorEstado de Terraform: propósito, locking y driftState management SiguienteComandos de state, import y workspacesState management