Tutorial Terraform su AWS: automatizzare il deployment di un agente su EC2

Ho passato ore a cliccare nella Console AWS, avviando manualmente istanze EC2, configurando security group e, inevitabilmente, commettendo errori che richiedono ore per essere risolti. Ti suona familiare? Crei un’istanza nella zona di disponibilità sbagliata, dimentichi di taggare una risorsa o passi un pomeriggio a ricreare la stessa configurazione del mese scorso perché non hai documentato i passaggi. 

Il provisioning manuale dell’infrastruttura non è solo noioso: è soggetto a errori, non scala e non è possibile da auditare. È qui che Terraform cambia le carte in tavola. Immagina di definire l’intera infrastruttura AWS in file di testo che puoi gestire con il controllo di versione, revisionare e distribuire automaticamente. Niente più clic su decine di schermate. Niente più conversazioni del tipo "ma sulla mia macchina funzionava" con il tuo team.

In questo tutorial ti mostro come automatizzare l’infrastruttura AWS con Terraform, concentrandoci su un esempio reale: il provisioning di un’istanza EC2 con un agente SSM (Systems Manager) avviato automaticamente al bootstrap. Alla fine, avrai compreso i fondamenti dell’Infrastructure as Code e avrai codice funzionante da distribuire subito sul tuo account AWS.

Se sei alle prime armi con AWS, valuta di seguire uno dei nostri corsi, come AWS Concepts, Introduction to AWS Boto in Python, oppure AWS Security and Cost Management. 

Che cos’è Terraform?

Terraform è uno strumento open-source di Infrastructure as Code (IaC) creato da HashiCorp che ti permette di definire, effettuare il provisioning e gestire le risorse cloud usando HashiCorp Configuration Language (HCL). 

Invece di cliccare nelle console cloud o scrivere script bash imperativi, dichiari l’infrastruttura che desideri nei file di configurazione e Terraform si occupa dei dettagli per realizzarla. Questo passaggio da un approccio imperativo a uno dichiarativo rappresenta un cambiamento fondamentale nel modo in cui pensiamo alle risorse cloud. 

Approccio imperativo vs. dichiarativo per avviare un’istanza AWS EC2

Con gli approcci imperativi, scrivi istruzioni passo-passo: "prima crea questo security group, poi attendi che esista, poi avvia questa istanza con quel security group, poi collega questo volume, poi crea questi tag". Sei tu a dover gestire l’ordine esatto e gli errori a ogni passaggio. 

Con l’approccio dichiarativo di Terraform, definisci semplicemente lo stato finale: "Voglio un’istanza EC2 con queste specifiche, collegata a questo security group, con questi tag". Terraform analizza le dipendenze, determina l’ordine corretto ed esegue il piano. Se qualcosa fallisce, sa esattamente dove si è fermato.

Perché scegliere Terraform in particolare per AWS? 

1. Primo, l’ecosistema della community è enorme: troverai moduli, esempi e soluzioni per quasi ogni servizio AWS immaginabile. 
2. Secondo, Terraform è provider-agnostico. Lo impari una volta e le stesse competenze e pattern funzionano su AWS, Azure, GCP e altre piattaforme. Eviti il vendor lock-in mantenendo un flusso di lavoro coerente. 
3. Terzo, il sistema di gestione dello state di Terraform traccia ogni risorsa, rendendo aggiornamenti e modifiche prevedibili. Terraform sa cosa hai creato e può modificarlo o distruggerlo in sicurezza.

Prima di passare alla configurazione pratica, è fondamentale capire tre concetti chiave che costituiscono le fondamenta di Terraform:

• Risorse: sono i componenti dell’infrastruttura che crei—istanze EC2, bucket S3, security group. 
• Provider: sono plugin che permettono a Terraform di interagire con le diverse piattaforme; il provider AWS traduce l’HCL in chiamate API AWS. 
• HCL: è la sintassi leggibile che userai per definire l’infrastruttura, progettata per essere espressiva e semplice.

Chiariti questi fondamentali, prepariamo l’ambiente per iniziare a costruire infrastruttura reale. 

Configurare l’ambiente AWS per Terraform

Prima di scrivere qualsiasi codice Terraform, devi installare la CLI e configurare le credenziali AWS. Ecco come fare entrambi i passaggi.

Installa Terraform

L’installazione di Terraform varia in base al sistema operativo:

• Su macOS, usa Homebrew: prima installa il tap di HashiCorp con brew tap hashicorp/tap, poi installa Terraform con brew install hashicorp/tap/terraform. 

• Su Windows, scarica il binario da hashicorp.com e aggiungilo al PATH, oppure usa Chocolatey: choco install terraform. 

• Su Linux, scarica il pacchetto appropriato o usa il gestore pacchetti della tua distribuzione. 

Una volta installato, verifica l’installazione eseguendo terraform version.

Configura le credenziali AWS

Configurare le credenziali AWS richiede un account AWS, una access key e una secret da IAM. Non usare mai l’account root. Crea invece un utente IAM con accesso programmatico e permessi appropriati (AdministratorAccess). L’approccio standard usa il file delle credenziali AWS in ~/.aws/credentials:

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEYOfferto da

In alternativa, imposta le variabili d’ambiente: AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY. Per ambienti di produzione, usa ruoli IAM associati a istanze EC2 o sistemi CI/CD invece di credenziali a lunga durata.

Se stai pensando di usare un ecosistema diverso da quello di Amazon o vuoi semplicemente una panoramica di come si confrontano i “big three”, ti consiglio di leggere questo confronto tra servizi AWS, Azure e GCP per Data Science & AI.

Distribuire un agente su EC2 con Terraform su AWS

Con le basi pronte, costruiamo qualcosa di reale: un’istanza EC2 che installa automaticamente l’agente SSM all’avvio.

Impostare la struttura del progetto

I progetti Terraform beneficiano di un approccio chiaro e strutturato. Crea tre file: main.tf per le definizioni delle risorse, variables.tf per gli input e outputs.tf per i valori che ti serviranno dopo il deployment. Questa separazione mantiene il codice ordinato e manutenibile.

 aws-terraform
├── main.tf
├── output.tf
└── variables.tfOfferto da

Ecco perché è importante: quando i progetti crescono, mettere tutto in un unico file diventa ingestibile. Le variabili ti permettono di riutilizzare lo stesso codice in ambienti diversi (dev, staging, production) cambiando gli input. Gli output forniscono i valori di cui avrai bisogno, come ID o indirizzi IP delle istanze, senza doverli cercare manualmente nella Console AWS.

Scrivere la configurazione della risorsa EC2

Ora creiamo l’infrastruttura: un’istanza EC2 con l’agente SSM preinstallato. Nel file main.tf, aggiungi la seguente configurazione:

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"
}Offerto da

Configurazione di un’istanza Terraform EC2

Il blocco data interroga AWS per ottenere l’AMI Amazon Linux 2 più recente. I filtri garantiscono che ottieni il tipo di immagine corretto e owners = ["amazon"] assicura l’uso di AMI ufficiali di Amazon. Questo approccio funziona in tutte le regioni senza modifiche: Terraform trova automaticamente l’AMI regionale corretta.

La parte cruciale è user_data: uno script shell che viene eseguito al primo avvio dell’istanza. Lo script scarica e installa l’agente SSM, quindi ne abilita l’avvio automatico. Il ruolo IAM fornisce i permessi necessari a SSM per gestire l’istanza.

Lo stesso pattern funziona per qualsiasi agente. Vuoi CloudWatch per log e metriche? Modifica lo script user_data per installare l’agente CloudWatch. Il principio resta identico: definisci cosa vuoi installare e Terraform garantisce che accada su ogni istanza.

Nel file output.tf, puoi aggiungere, ad esempio, l’ID dell’istanza. Poi, una volta eseguiti tutti i comandi Terraform che vedremo nel prossimo capitolo, il valore verrà mostrato nel terminale.

output "instance_id" {
  description = "EC2 instance ID for SSM connection"
  value       = aws_instance.web_server.id
}Offerto da

Inizializzare e applicare la configurazione

Scritta la configurazione, il flusso di lavoro di Terraform prevede tre comandi. Per prima cosa, il comando seguente scarica il plugin del provider AWS e prepara la directory:

terraform initOfferto da

terraform init

Poi, terraform plan mostra esattamente cosa Terraform creerà, modificherà o distruggerà. Questa anteprima ti permette di intercettare errori prima di apportare modifiche reali:

terraform planOfferto da

terraform plan

Rivedi attentamente l’output. Vedrai l’istanza EC2, il ruolo IAM, l’instance profile e l’associazione della policy che Terraform creerà.

Infine, terraform apply esegue le modifiche. Terraform chiede conferma prima di procedere. Digita yes dopo aver eseguito questo comando:

terraform applyOfferto da

terraform apply

Se tutto funziona, vedrai il seguente messaggio una volta che le risorse sono state create. 

Conferma: risorse Terraform create

In pochi minuti avrai un’istanza EC2 in esecuzione con SSM configurato, accessibile senza chiavi SSH. Assicurati di controllare la Console AWS per vedere le risorse appena create.

Gestire lo state di Terraform su AWS S3

Dopo aver eseguito i comandi sopra, nella directory vedrai un nuovo file chiamato terraform.tfstate. Il file di state di Terraform mappa la tua configurazione alle risorse AWS reali. Vediamo il file per capirne il contenuto.

Comprendere il file di state

Il file di state contiene ogni dettaglio dell’infrastruttura distribuita: ID delle risorse, indirizzi IP e dipendenze. Terraform confronta questo state con la tua configurazione e con lo stato reale su AWS per determinare quali azioni intraprendere. Se perdi il file di state, Terraform perde la traccia di tutto ciò che ha creato.

Mantenere lo state sul tuo laptop è rischioso. Se il computer si blocca, lo state scompare. Se più membri del team lavorano sulla stessa infrastruttura, gli state locali in conflitto causano corruzione. La soluzione: archiviazione remota dello state.

Per un approfondimento su S3 ed EFS, dai un’occhiata a questo tutorial sullo storage AWS.

Configurare un backend S3 remoto

Il backend S3 di Terraform archivia lo state in una posizione centralizzata e durevole, accessibile a tutto il team. Per prima cosa, 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=EnabledOfferto da

Il versioning è fondamentale: ti permette di ripristinare versioni precedenti dello state in caso di incidenti.

Ora aggiungi la configurazione del backend al tuo codice 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
  }  
}Offerto da

Esegui di nuovo terraform init per migrare lo state locale su S3. Terraform chiederà conferma prima di spostare il file di state.

Backend remoto S3 per Terraform

Dopo l’esecuzione del comando, il bucket S3 conterrà il nuovo file di state. Puoi verificarlo nella console AWS.

Lock dello state con file di lock nativi S3

Avrai notato che abbiamo aggiunto il seguente parametro nel file main.tf: use_lockfile = true. Questa impostazione abilita la funzionalità più recente di Terraform: il lock dello state nativo su S3. In passato serviva una tabella DynamoDB separata per il locking.

Lock dello state in Terraform

Questa semplificazione elimina un intero servizio AWS dal tuo setup mantenendo la stessa protezione contro le race condition. Più ingegneri possono lavorare in sicurezza sull’infrastruttura, sapendo che solo le modifiche di una persona alla volta verranno applicate.

Scalare l’infrastruttura con Terraform su AWS

Quando l’infrastruttura cresce, valori hardcoded e codice copiato-incollato diventano un incubo di manutenzione. Il sistema di variabili e i moduli di Terraform risolvono il problema.

Refactoring con variabili di input

In precedenza abbiamo creato il file variables.tf. Ora puoi spostare i valori che erano hardcoded in main.tf in questo nuovo file che conterrà le nostre variabili:

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"
}Offerto da

Ora fai riferimento alle variabili nelle tue risorse nel file 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
  }
}Offerto da

Nota che i bucket AWS S3 sono univoci, quindi non puoi usare variabili nella regione nel parametro backend di main.tf. Qui devi mantenere la regione hardcoded, ad esempio “eu-central-1”, invece di var.region_aws.

Ora che abbiamo definito le variabili, puoi anche definire ambienti diversi, come sviluppo o produzione, in cui le variabili possono differire. Questo si fa creando nuovi file con estensione .tfvars.

Per esempio, puoi creare un terraform-dev.tfvars per lo sviluppo e un terraform-prod.tfvars per la produzione:

Sviluppo:

aws_region    = "eu-central-1"
instance_type = "t2.micro"Offerto da

Produzione:

aws_region    = "eu-central-1"
instance_type = "t3.medium"Offerto da

Poi puoi distribuire nei diversi ambienti specificando il file appropriato:

terraform apply -var-file="terraform-dev.tfvars”Offerto da

Le variabili risolvono il problema dei valori specifici per ambiente, ma come evitare di duplicare interi pattern di infrastruttura? Qui entrano in gioco i moduli.

Creare moduli di risorse riutilizzabili

I moduli impacchettano risorse correlate in componenti riutilizzabili. Il modo migliore per usarli è creare una cartella dedicata. Ad esempio, puoi creare una struttura come questa:

modules/
  ec2-with-ssm/
    main.tf
    variables.tf
    outputs.tfOfferto da

Puoi spostare il file variables.tf creato in precedenza (o crearne uno nuovo) nella cartella del modulo. La modifica chiave avviene nel file main.tf. Quello nel modulo conterrà le nostre risorse. Quindi tutto, dall’AMI fino al fondo del file, va spostato lì:

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"
}Offerto da

Per sostituire il cambiamento, mantieni il resto del file ma aggiungi un blocco module che fa riferimento al modulo specifico.

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
}Offerto da

Ora, se esegui i comandi init, plan e apply con questa configurazione, distribuirai le stesse risorse di prima. La differenza è che i moduli ti permettono di lanciare infrastrutture con configurazioni simili riutilizzabili. Sono la chiave per scalare Terraform oltre i progetti semplici.

Passiamo ora a un altro tema importante: la sicurezza.

Best practice di sicurezza per Terraform su AWS

Il codice dell’infrastruttura richiede lo stesso rigore di sicurezza del codice applicativo. È quindi fondamentale proteggere i tuoi deployment Terraform.

Gestire segreti e dati sensibili

Non committare mai segreti su Git. Mai. Usa AWS Secrets Manager per i valori sensibili. Puoi utilizzare la seguente risorsa in Terraform:

resource "aws_secretsmanager_secret" "example" {
  name = "example"
}Offerto da

Per segreti specifici per ambiente, puoi usare variabili d’ambiente con prefisso TF_VAR_. 

Ad esempio, potresti usare variable "aws_access_key" {} nel file variables.tf ed esportarla nel terminale con export TF_VAR_aws_access_key=<access_key_value>. Terraform carica automaticamente questi valori come variabili senza esporli nel codice.

Gestire il configuration drift

Un altro tema importante è il drift. Si verifica quando qualcuno modifica l’infrastruttura tramite la Console AWS o la CLI, bypassando Terraform. Esegui regolarmente terraform plan per rilevare il drift. L’output mostra le risorse esistenti che non corrispondono alla tua configurazione.

Quando compare drift, hai due scelte: aggiornare il codice Terraform per allinearlo alla realtà, oppure eseguire terraform apply per riportare l’infrastruttura allo stato desiderato. La scelta giusta dipende dal fatto che la modifica manuale fosse intenzionale.

Pulire le risorse

Infine, è importante rimuovere tutte le risorse quando sai che non servono più, per evitare costi inutili. Puoi ripulire le risorse con il seguente comando:

terraform destroyOfferto da

Rivedi attentamente il piano di distruzione. Terraform eliminerà ogni risorsa che ha creato. In produzione, valuta l’uso di terraform destroy -target per rimuovere risorse specifiche invece di tutto.

Conclusione

Hai imparato il flusso di lavoro core di Terraform: definire l’infrastruttura in codice, visualizzare in anteprima le modifiche con plan, applicarle con apply e tracciare tutto con la gestione dello state. Abbiamo coperto il deployment di EC2 con installazione automatica dell’agente, lo spostamento dello state su S3 con lock nativo, la scalabilità con variabili e moduli e la sicurezza con la gestione dei segreti.

Tratta il codice dell’infrastruttura con lo stesso rigore del codice applicativo. Usa il controllo di versione, richiedi code review per le modifiche e testa prima in ambienti non di produzione. Le pipeline CI/CD possono automatizzare terraform apply, rendendo gli aggiornamenti dell’infrastruttura fluidi quanto i deployment applicativi.

Il tuo prossimo passo: esplora GitHub Actions o GitLab CI per eseguire automaticamente Terraform quando fai push del codice. Questo approccio Infrastructure as Code, combinato con l’automazione, trasforma il modo in cui i team gestiscono le risorse cloud, sostituendo il lavoro manuale in console con un’infrastruttura affidabile, ripetibile e versionata.

Il mio consiglio è di fare leva su queste conoscenze e iscriverti allo skill track AWS Cloud Practitioner (CLF-C02) che ti insegna tutto ciò che serve per ottenere la certificazione CLF-C02 di Amazon.