Nelle architetture enterprise e in particolare nei settori regolamentati come il bancario, la gestione del parco macchine virtuali storicamente si è affidata al modello dell'infrastruttura mutabile. In questi contesti, i server a lunga vita e i sistemi transazionali legacy sono spesso una realtà imprescindibile: per governarli con rigore, piattaforme enterprise di automazione centralizzata come Ansible Automation Platform (AAP) giocano un ruolo essenziale, coordinando patch di sicurezza, inventari dinamici e playbook idempotenti nel pieno rispetto dei vincoli di compliance e auditabilità.

Accanto a questa prassi consolidata, la maturazione dei servizi cloud-native su AWS ha reso possibile adottare una strategia complementare e ad alta efficienza per i tier applicativi, i microservizi e i carichi scalabili: l'infrastruttura immutabile (immutable infrastructure). In questo modello, le istanze di calcolo non vengono manutenute o riconfigurate in-place nel tempo, ma vengono considerate entità effimere e sostituibili (cattle): ogni modifica a livello di sistema operativo, patch di sicurezza o upgrade di runtime si traduce nella creazione di una nuova immagine certificata a monte e nella sostituzione controllata dell'istanza in esecuzione.

In questo articolo analizzeremo come ingegnerizzare su Amazon Web Services un'infrastruttura Linux realmente immutabile, combinando una pipeline di baking a due livelli con HashiCorp Packer (Golden AMI e Silver AMI), il disaccoppiamento dello stato persistente su Amazon EFS, l'orchestrazione continua del calcolo tramite EC2 Auto Scaling Groups e il deployment dell'applicazione via AWS CodeDeploy.

Paradigmi a Confronto: Quando Scegliere la Sostituzione rispetto alla Manutenzione In-Place

Comprendere i punti di forza di entrambi i modelli consente all'architetto cloud di adottare la soluzione ottimale per ciascun carico di lavoro aziendale:

• Il Modello Mutabile Governato (es. AAP): Ideale e spesso inevitabile per database relazionali complessi con storage locale, appliance certificate di terze parti o sistemi monolitici core banking con cicli di rilascio rigidi. La convergenza in-place, orchestrata centralmente tramite Ansible Automation Platform, assicura tracciabilità, minimizza i disservizi attraverso riavvii coordinati e applica policy di sicurezza uniformi senza dover ricostruire la macchina da zero.
• Il Modello Immutabile Cloud-Native: Perfetto per il tier web, microservizi stateless, backend API e worker di elaborazione batch. Rimuove alla radice il rischio di disallineamento (configuration drift), rende l'ambiente di produzione identico bit-per-bit a quello di collaudo e trasforma il patching ordinario in una procedura standardizzata di sostituzione automatica.

La tabella seguente riassume i trade-off e i contesti di applicazione ideali dei due approcci:

Architettura a Cinque Layer: Dalla Compilazione al Lifecycle

Per realizzare un'architettura che sia al contempo resiliente, conforme alle normative e snella dal punto di vista operativo ed economico, abbiamo strutturato la soluzione su cinque livelli integrati in tre macro-componenti logici:

Ingrandisci

Layer 1 & 2: La Pipeline di Baking a Due Livelli con Packer

Uno dei dilemmi tipici nella creazione di immagini immutabili è la granularità del bake: creare un'unica grande AMI per ogni singolo microservizio (fat image) oppure utilizzare immagini minime configurate interamente a runtime (thin image)?

La soluzione enterprise ottimale adotta un approccio a due livelli:

• Livello 1 — Golden AMI: Gestita dal team di Cloud Platform e Cyber Security. Parte da un'immagine upstream certificata (es. Amazon Linux 2023 o RHEL 9) e applica l'hardening del sistema operativo secondo lo standard CIS Benchmark Level 1, configura gli agenti centrali di telemetria e sicurezza (AWS Systems Manager Agent, CloudWatch Agent, CrowdStrike Falcon o Wazuh) e inietta le Root CA certificate dell'organizzazione.
• Livello 2 — Silver AMI: Gestita dai team DevOps applicativi. Utilizza come sorgente (source_ami_filter) l'ultima Golden AMI approvata e installa le dipendenze di runtime del servizio (es. Node.js LTS, OpenJDK, Python virtual environment, Nginx reverse proxy preconfigurato, parametri di ottimizzazione del kernel sysctl).

Configurazione Packer HCL: Golden AMI

Il file seguente mostra la definizione dichiarativa in HCL della Golden AMI con installazione degli agenti e hardening base:

packer {
  required_plugins {
    amazon = {
      version = ">= 1.3.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

variable "aws_region" {
  type    = string
  default = "eu-west-1"
}

source "amazon-ebs" "golden_linux" {
  region                  = var.aws_region
  instance_type           = "t3.medium"
  ami_name                = "golden-ami-al2023-cis-{{timestamp}}"
  ami_description         = "Enterprise Golden AMI based on Amazon Linux 2023 with CIS Baseline"
  encrypt_boot            = true
  ssh_username            = "ec2-user"
  associate_public_ip_address = false

  source_ami_filter {
    filters = {
      name                = "al2023-ami-2023.*-kernel-6.1-x86_64"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    owners      = ["amazon"]
    most_recent = true
  }

  tags = {
    Name        = "Golden-AMI-AL2023"
    Environment = "Core-Shared"
    ManagedBy   = "Platform-Security"
  }
}

build {
  sources = ["source.amazon-ebs.golden_linux"]

  # 1. Aggiornamento base e installazione agenti enterprise
  provisioner "shell" {
    inline = [
      "sudo dnf update -y --releasever=latest",
      "sudo dnf install -y amazon-cloudwatch-agent amazon-ssm-agent amazon-efs-utils",
      "sudo systemctl enable amazon-ssm-agent",
      "sudo systemctl enable amazon-cloudwatch-agent"
    ]
  }

  # 2. Hardening CIS e tuning kernel
  provisioner "shell" {
    inline = [
      "echo 'net.ipv4.tcp_syncookies = 1' | sudo tee -a /etc/sysctl.d/99-cis.conf",
      "echo 'net.ipv4.conf.all.accept_redirects = 0' | sudo tee -a /etc/sysctl.d/99-cis.conf",
      "echo 'fs.file-max = 2097152' | sudo tee -a /etc/sysctl.d/99-cis.conf",
      "sudo sysctl --system"
    ]
  }
}

Configurazione Packer HCL: Silver AMI

La Silver AMI eredita direttamente dalla Golden AMI approvata, riducendo i tempi di compilazione a meno di tre minuti:

packer {
  required_plugins {
    amazon = {
      version = ">= 1.3.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

variable "aws_region" {
  type    = string
  default = "eu-west-1"
}

source "amazon-ebs" "silver_runtime" {
  region                  = var.aws_region
  instance_type           = "t3.medium"
  ami_name                = "silver-ami-nodejs22-nginx-{{timestamp}}"
  ami_description         = "Application Silver AMI with Node.js 22 LTS, Nginx and CodeDeploy Agent"
  encrypt_boot            = true
  ssh_username            = "ec2-user"
  associate_public_ip_address = false

  # Eredita dinamicamente dall'ultima Golden AMI convalidata
  source_ami_filter {
    filters = {
      name                = "golden-ami-al2023-cis-*"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    owners      = ["self"]
    most_recent = true
  }

  tags = {
    Name        = "Silver-AMI-WebRuntime"
    Environment = "Production"
    Role        = "Application-Server"
  }
}

build {
  sources = ["source.amazon-ebs.silver_runtime"]

  provisioner "shell" {
    inline = [
      "sudo dnf install -y nginx nodejs ruby wget",
      "# Installazione ufficiale agente AWS CodeDeploy",
      "cd /home/ec2-user",
      "wget https://aws-codedeploy-${var.aws_region}.s3.${var.aws_region}.amazonaws.com/latest/install",
      "chmod +x ./install",
      "sudo ./install auto",
      "sudo systemctl enable codedeploy-agent",
      "sudo systemctl enable nginx",
      "rm -f ./install"
    ]
  }
}

Layer 3 & 4: Storage Disaccoppiato con EFS e Resilienza ad Unico Nodo

Un errore frequente nella progettazione di macchine virtuali su cloud è l'utilizzo del volume root EBS per archiviare dati di sessione, caricamenti di file o asset applicativi. In un'architettura immutabile, il disco EBS è considerato rigorosamente effimero: quando un'istanza viene terminata, il suo volume EBS deve essere distrutto senza esitazione.

Per garantire la persistenza dei dati e consentire l'immutabilità dei nodi, l'intero stato dinamico viene delegato ad Amazon EFS (Elastic File System), file system scalabile, multi-Availability Zone e completamente gestito, montato all'avvio via NFS v4.1 con cifratura del traffico in transito tramite TLS.

Resilienza ed Efficienza dei Costi: Il Pattern Single-Instance HA

Non tutti i carichi aziendali richiedono cluster distribuiti con decine di nodi costantemente attivi. Molti workload interni (sistemi gestionali, micro-backend, server di build, ambienti batch) necessitano di elevata disponibilità ma presentano budget contenuti.

Grazie alla combinazione di Auto Scaling Group impostato a capacità fissa (min_size = 1, max_size = 1, desired_capacity = 1) e Amazon EFS per lo storage condiviso, otteniamo una resilienza enterprise al minor costo possibile: 1. Self-Healing Istantaneo: Se l'istanza EC2 subisce un guasto hardware nell'Availability Zone A o il sistema operativo va in kernel panic, l'Auto Scaling Group rileva il mancato superamento dell'health check di EC2. 2. Sostituzione Automatica Cross-AZ: L'ASG termina l'istanza non funzionante e ne avvia istantaneamente una nuova, posizionandola nell'Availability Zone B (se configurato su subnet multi-AZ). 3. Ricollegamento Trasparente dei Dati: La nuova istanza esegue il bootstrap, rimonta lo share EFS cifrato su /var/www/shared e torna immediatamente operativa senza perdita di un singolo byte di dati.

Layer 5: Convergenza Applicativa con AWS CodeDeploy

Un altro snodo critico dell'architettura riguarda la frequenza di rilascio del codice applicativo: se ogni deploy di un fix di due righe richiedesse il bake di un'intera Silver AMI (tempo medio: 3-5 minuti per Packer + 5 minuti per l'Instance Refresh dell'ASG), la velocità di sviluppo dei team crollerebbe.

La soluzione consiste nel separare il ciclo di vita dell'infrastruttura da quello del codice:

• Frequenza Mensile / Quindicinale: Refresh immutabile delle AMI (OS, kernel security patch, librerie di runtime).
• Frequenza Quotidiana / Continua: Distribuzione del codice applicativo tramite AWS CodeDeploy.

Il Meccanismo di Hook e Bootstrap

All'avvio di una nuova istanza (per scale-out, self-healing o rolling refresh dell'AMI):

1. La macchina si avvia dalla Silver AMI con l'agente CodeDeploy attivo.
2. L'integrazione tra Auto Scaling Group e CodeDeploy aggancia l'istanza nello stato di Pending:Wait attraverso un Lifecycle Hook di Auto Scaling.
3. CodeDeploy scarica l'ultima release applicativa memorizzata su Amazon S3, estrae il pacchetto ed esegue le istruzioni del file appspec.yml.
4. Solo al superamento dell'hook ValidateService, CodeDeploy segnala il successo all'Auto Scaling Group, che completa il transitorio e apre il traffico di rete.

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/application
hooks:
  BeforeInstall:
    - location: scripts/validate_efs_mount.sh
      timeout: 60
      runas: root
  AfterInstall:
    - location: scripts/configure_application.sh
      timeout: 120
      runas: root
  ApplicationStart:
    - location: scripts/start_service.sh
      timeout: 60
      runas: root
  ValidateService:
    - location: scripts/health_check.sh
      timeout: 45
      runas: root

Orchestrazione Terraform: Launch Template e Instance Refresh

L'integrazione di questi componenti viene formalizzata tramite Infrastructure as Code con Terraform/OpenTofu, configurando la policy di instance_refresh direttamente nel blocco dell'Auto Scaling Group:

resource "aws_launch_template" "immutable_worker" {
  name_prefix   = "immutable-worker-"
  image_id      = data.aws_ami.latest_silver.id
  instance_type = "t3.medium"

  iam_instance_profile {
    name = aws_iam_instance_profile.worker_profile.name
  }

  vpc_security_group_ids = [aws_security_group.worker_sg.id]

  # User data minimale per montaggio EFS cifrato via TLS
  user_data = base64encode(<<-EOF
    #!/bin/bash
    set -euo pipefail
    mkdir -p /var/www/shared
    # Montaggio Amazon EFS con TLS e opzioni di resilienza NFS
    mount -t efs -o tls,iam ${aws_efs_file_system.shared_storage.id}:/ /var/www/shared
    echo "${aws_efs_file_system.shared_storage.id}:/ /var/www/shared efs _netdev,tls,iam 0 0" >> /etc/fstab
  EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "Immutable-Worker-Node"
      Environment = "Production"
    }
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "immutable_asg" {
  name_prefix         = "asg-immutable-"
  vpc_zone_identifier = var.private_subnet_ids
  min_size            = 1
  max_size            = 2
  desired_capacity    = 1

  launch_template {
    id      = aws_launch_template.immutable_worker.id
    version = "$Latest"
  }

  # Configurazione dell'Instance Refresh automatico
  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 100
      instance_warmup        = 300
      checkpoint_delay       = 120
    }
    triggers = ["tag"]
  }

  lifecycle {
    create_before_destroy = true
    ignore_changes        = [desired_capacity]
  }
}

Il Ciclo di Vita Mensile Automatizzato

Il valore supremo dell'infrastruttura immutabile emerge nella gestione ordinaria e ricorrente delle patch. Anziché dedicare notti o fine settimana all'applicazione manuale di aggiornamenti tramite SSH, l'intero ciclo viene affidato a una schedulazione mensile automatizzata (es. ogni primo lunedì del mese via Amazon EventBridge e AWS Step Functions o pipeline CI/CD):

1. Trigger Automatico della Golden Pipeline: EventBridge avvia il build Packer della Golden AMI, che preleva l'ultima immagine ufficiale Amazon Linux, applica le patch di sicurezza del kernel e valida i controlli CIS.
2. Scansione e Approvazione: La nuova Golden AMI viene scansionata da Amazon Inspector o Trivy. Al superamento dei quality gate di sicurezza, viene marcata con il tag Status = Approved.
3. Compilazione a Cascata della Silver AMI: Il tag attiva la pipeline della Silver AMI, che eredita dalla nuova Golden, installa i runtime applicativi aggiornati e genera la Silver AMI finale.
4. Aggiornamento del Launch Template: La pipeline CI/CD aggiorna il Launch Template con la nuova Silver AMI (version = $Latest).
5. Esecuzione dell'Instance Refresh: Viene invocata l'API StartInstanceRefresh dell'Auto Scaling Group. L'ASG avvia la nuova istanza, CodeDeploy distribuisce l'ultima versione stabile dell'applicazione, e la vecchia macchina viene ritirata e terminata in modo pulito.

Conclusioni: Affidabilità Predicibile

Adottare l'infrastruttura immutabile su AWS con Packer, Auto Scaling, CodeDeploy ed EFS trasforma il patching e la manutenzione ordinaria da evento rischioso ad attività ingegneristica standardizzata, deterministica e invisibile.

Eliminando il configuration drift e separando in modo netto il computo effimero dallo stato persistente, l'infrastruttura acquisisce una resilienza innata: ogni singolo server è sostituibile in qualsiasi momento, i ripristini sono immediati e il carico operativo del team si azzera, garantendo al contempo la massima sicurezza e conformità ai più severi requisiti enterprise.