Terraform por sí solo no sabe nada de AWS, ni de Azure, ni de ninguna nube. Necesita un «traductor» que sepa hablar con cada plataforma. Ese traductor es el provider. En este subcapítulo entenderás qué es un provider, cómo Terraform se comunica con AWS y cómo se configura. Es la pieza que conecta tu código con la nube real.

Un provider es un complemento (plugin) que le enseña a Terraform a comunicarse con una plataforma concreta. El provider de AWS sabe cómo crear, leer, modificar y borrar recursos de AWS a través de su API.

Analogía: Terraform es como una persona que quiere dar instrucciones en muchos países distintos. El provider es el intérprete/traductor que conoce el idioma de cada país. El provider de AWS «habla AWS»; el de Azure «habla Azure». Tú das las instrucciones en HCL y el provider las traduce al idioma de la nube correspondiente.

Esto es lo que hace que Terraform sea multi-nube (recuerda el Capítulo 9): el mismo Terraform usa distintos providers para hablar con distintas plataformas. Hay cientos de providers: AWS, Azure, GCP, Kubernetes, GitHub, Cloudflare, y muchos más.

El flujo, simplificado, es este:

1. Tú escribes lo que quieres en HCL (resource "aws_instance"...).
2. Terraform procesa tu código.
3. El provider de AWS traduce eso en llamadas a la API de AWS (las mismas que usa la consola web por detrás).
4. AWS crea/modifica/borra los recursos reales.

Cada recurso que empieza por aws_ (como aws_instance, aws_s3_bucket) lo gestiona el provider de AWS.

En tu código declaras qué provider quieres usar y lo configuras. Esto suele ir en un bloque terraform (para fijar la versión) y un bloque provider:

Desglosemos:

• El bloque terraform { required_providers { ... } } declara que necesitas el provider de AWS, de dónde descargarlo (hashicorp/aws) y qué versión (~> 5.0 significa «versión 5.x»).
• El bloque provider "aws" { ... } lo configura: aquí indicas, por ejemplo, la región donde trabajar (recuerda el Capítulo 3).

Por qué fijar la versión importa: los providers se actualizan y a veces cambian su comportamiento. Fijar la versión (~> 5.0) garantiza que tu código siga funcionando igual aunque salgan versiones nuevas. Es una buena práctica para evitar sorpresas.

Para que AWS le deje crear recursos, Terraform necesita credenciales (recuerda IAM, Capítulo 7). Pero, muy importante, las credenciales no se escriben en el código. Hay formas seguras de proporcionarlas:

⚠️ Regla de seguridad crítica: NUNCA escribas claves de acceso dentro de tu código .tf. Si lo subes a Git, estarías filtrando tus credenciales (recuerda los desastres del Capítulo 7). En su lugar, usa el AWS CLI, variables de entorno o, lo mejor, roles de IAM (subcapítulo 7.4). Terraform las recoge automáticamente del entorno, sin que aparezcan en el código.

Antes de poder usar un provider, hay que descargarlo. Eso lo hace el comando terraform init, que es el primer comando que ejecutas en cualquier proyecto de Terraform.

init lee tu configuración, descarga los providers necesarios y deja todo listo para plan y apply (recuerda el ciclo del subcapítulo 9.4). Lo ejecutas:

• La primera vez que empiezas un proyecto.
• Cada vez que añades un provider nuevo o cambias su versión.
• (También configura el backend del estado, que veremos en el subcapítulo 11.3.)

Así, el ciclo completo de Terraform es en realidad: init → plan → apply → ... → destroy.

Para casos avanzados, puedes usar varios providers a la vez o el mismo provider con configuraciones distintas. Por ejemplo, desplegar en dos regiones de AWS usando dos configuraciones del provider AWS con alias:

Esto es útil para arquitecturas multi-región (Capítulo 26) o multi-cuenta (Capítulo 30). No te preocupes por ello ahora; basta con saber que es posible.

• Un provider es el «traductor» que permite a Terraform hablar con una plataforma. El provider de AWS traduce tu HCL en llamadas a la API de AWS.
• Gracias a los providers, Terraform es multi-nube (hay cientos: AWS, Azure, GCP, Kubernetes…).
• Se declara con required_providers (fijando la versión, buena práctica) y se configura con el bloque provider (región, etc.).
• Las credenciales NUNCA van en el código: usa AWS CLI, variables de entorno o, mejor, roles de IAM.
• terraform init descarga los providers y es el primer comando que ejecutas en un proyecto.

En el siguiente subcapítulo veremos el concepto más característico (y a veces confuso) de Terraform: el archivo de estado (terraform.tfstate) y por qué es tan importante.