Infrastructure as Code su Azure: facciamo chiarezza

Disclaimer

Questa articolo NON è:

• Bicep vs Terraform: chi vince;
• “Devi assolutamente usare X”;
• Una feature comparison dettagliata di vari tool IaC.

Ma piuttosto:

• Come scegliere in base al tuo contesto;
• Best practice universali;
• Decisioni consapevoli.

Infrastructure as Code: che cosa è?

L’Infrastructure as Code è una pratica che consiste nel definire e gestire l’infrastruttura tramite codice dichiarativo e versionato, rendendo il provisioning delle risorse ripetibile, coerente e automatizzabile.

IaC su Azure: il landscape attuale

ARM Templates

Facciamo un passo indietro: oggi probabilmente tutti conoscete o avete sentito parlare di Bicep e Terraform, ma come siamo arrivati qui?

Gli ARM Templates sono stati il primo modo “ufficiale” per fare IaC su Azure. Sono JSON, verbosi, complessi, ma completi. Ancora oggi supportati al 100% e talvolta necessari per feature molto nuove non ancora disponibili in Bicep. La maggior parte di voi probabilmente non inizierà nuovi progetti con ARM, ma è importante sapere che esistono — perché Bicep, in fondo, compila proprio in ARM.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountNamePrefix": {
      "type": "string",
      "defaultValue": "stamc",
      "metadata": {
        "description": "Prefix for the storage account name."
      }
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    },
    "skuName": {
      "type": "string",
      "defaultValue": "Standard_LRS",
      "allowedValues": [ "Standard_LRS", "Standard_GRS", "Standard_ZRS" ]
    }
  },
  "variables": {
    "storageAccountName": "[concat(parameters('storageAccountNamePrefix'), uniqueString(resourceGroup().id))]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-05-01",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "[parameters('skuName')]"
      },
      "kind": "StorageV2",
      "properties": {
        "minimumTlsVersion": "TLS1_2",
        "supportsHttpsTrafficOnly": true,
        "allowBlobPublicAccess": false
      }
    }
  ],
  "outputs": {
    "storageAccountId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
    }
  }
}

I pilastri di un ARM template:

• Parameters — valori forniti durante il deployment (es. nomi, password, SKU).
• Variables — valori riutilizzabili nel template per semplificare la sintassi.
• Functions — espressioni per creare valori dinamici (es. concat(), uniqueString()).
• Resources — l’elenco delle risorse da creare con le loro proprietà.
• Outputs — valori restituiti dopo il deployment (es. l’indirizzo IP pubblico creato).

Bicep

DSL dichiarativo creato da Microsoft specificamente per Azure. Nasce nel 2020 come evoluzione degli ARM template, verbosi e difficilmente leggibili e debuggabili per noi povere persone che lavorano con le infrastrutture su Azure. Pulito, leggibile, compila in ARM prima del deployment, integrato con tutto l’ecosistema Azure: VS Code, CLI, Portal.

Quando ha senso:

• Progetti Azure-only;
• Team che non hanno esperienza con tool IaC;
• Velocità di onboarding prioritaria.

Terraform

Linguaggio HCL, dichiarativo, nato per essere multi-cloud. Provider per Azure, AWS, GCP e centinaia di altri servizi. Ecosistema maturo, community enorme, state management robusto. La sintassi è un po’ diversa da quella di Bicep e la differenza principale tra i due è che Terraform mantiene lo stato dell’infrastruttura su uno state file.

Quando ha senso:

• Multi-cloud o possibilità futura di multi-cloud;
• Team che già usa Terraform per altre piattaforme;
• Necessità di gestire risorse non-Azure insieme ad Azure.

OpenTofu

OpenTofu, il fork open source di Terraform sotto Linux Foundation.

Source

Nel 2023 HashiCorp ha modificato la licenza di Terraform da open-source a Business Source License (BSL 1.1). Per la maggior parte degli usi (sviluppo, produzione, CI/CD con Azure DevOps o GitHub Actions, consulenza) è ancora gratuito. Il divieto principale è: non potete usare Terraform per costruire un prodotto che compete direttamente con HCP Terraform.

La community ha reagito immediatamente creando un fork del progetto: nasce così OpenTofu, sotto Linux Foundation, con licenza MPL 2.0 — vera open source, nessuna restrizione commerciale.

L’esperienza di sviluppo è praticamente identica:

• Provider azurerm identico (stesso codice, stessi maintainer Microsoft);
• Sintassi HCL identica;
• State file compatibile.

Il consiglio pragmatico:

• Nuovi progetti — valutate OpenTofu se l’open source vero vi importa o avete policy aziendali stringenti;
• Progetti esistenti su Terraform — non c’è urgenza di migrare, siete nella legalità. Monitorate l’evoluzione;
• HCP Terraform users — rimanete su Terraform ufficiale.

Altri tool

Esistono altri player e tool complementari:

• Pulumi — DSL che permette di scrivere infrastruttura in linguaggi come TypeScript, Python o C#.
• Ansible — Configuration management e provisioning procedurale/imperativo.

Pulumi: IaC scritta in linguaggi general-purpose come TypeScript, Python o C#.

Source

Ansible: configuration management e provisioning procedurale.

Deep Dive: Bicep e Terraform

Comparazione di sintassi tra Bicep e Terraform: concetti simili, esperienza di sviluppo diversa.

Gestione dello stato: due approcci diversi

Il mio codice IaC dice “voglio una VM, uno storage account e un database”, maa su Azure ha già deploiato delle risorse: come fanno a sapere Bicep e Terraform cosa esiste, cosa creare, cosa modificare o cosa eliminare?

Serve una rappresentazione dello stato corrente.

Bicep e Terraform lo gestiscono in modo completamente diverso.

Terraform — State management esterno

Terraform salva la mappatura tra il vostro codice e le risorse reali in un file terraform.tfstate.

Pro:

• Performance e scoping — lo state file fornisce a Terraform la lista precisa delle risorse gestite. Le API Azure Resource Manager vengono interrogate per ottenere lo stato attuale e per rilevare eventuali differenze rispetto a quanto contenuto nello state file;
• Pianificazione (Plan) — permette di vedere esattamente cosa verrà creato, modificato o distrutto prima di procedere;
• Cross-resource — può collegare risorse gestite in diverse sottoscrizioni o persino su cloud diversi;
• Controllo totale — terraform state list, terraform state show, terraform state mv per riorganizzare.

Contro:

• Complessità — bisogna gestire un backend (es. Azure Blob Storage) per salvare lo stato in modo sicuro e condiviso;
• Rischio corruzione/lock — se il file di stato si corrompe o resta bloccato, l’infrastruttura diventa difficile da gestire;
• Dati sensibili — il file di stato contiene segreti in chiaro (es. password DB) e va protetto rigorosamente.

IMPORTANTE — Terraform non cifra lo state file lato client: i secret restano in chiaro all’interno del file.

Su Azure Blob Storage l’encryption at rest è già attiva di default, ma chiunque abbia permessi di lettura sul blob vede comunque i valori. Mitigazioni: RBAC granulare sul container dello state (least privilege), audit log abilitati.

Bicep — State management nativo (stateless)

Bicep non ha un file di stato locale: ogni volta che eseguite un comando interroga direttamente Azure. Delega tutto ad Azure Resource Manager. Ogni deployment viene salvato nella Deployment History del resource group o subscription, con template usato, parametri, timestamp, chi ha deployato e risultato.

Bicep what-if: limiti da conoscere

Il what-if deve interrogare le API di Azure in tempo reale per confrontare il codice con la realtà. È un’ottima guida visiva, ma non è un contratto garantito al 100% come il plan di Terraform. Problemi noti: rumore visivo, falsi positivi sulle sostituzioni, dipendenze a catena.

Mitigazioni:

• Evitate il nesting eccessivo — mantenete una struttura “flat” richiamando i moduli dal main.bicep invece di annidarli come matrioske;
• Passate ID, non oggetti — passate ai moduli nested gli ID delle risorse (stringhe) invece di interi oggetti risorsa: aiuta il motore di previsione;
• Deployment in fasi — per infrastrutture massicce, separate la Foundation (Networking/IAM) dalle Apps. Il what-if diventa molto più preciso per entrambi i livelli.

Framework decisionale

I fattori che contano davvero quando si sceglie tra Bicep e Terraform:

Fattore	Bicep	Terraform
Curva di apprendimento	Bassa	Medio/Alta
Background ideale	Azure-focused	Esperienza precedente DevOps multi-cloud
Dimensione team / complessità	Team piccolo e “Azure-only”	Ambiente multi-team che richiede standardizzazione tra piattaforme cloud

Dove gira la vostra infrastruttura?

Se siete 100% Azure e lo rimarrete, Bicep è una scelta naturale: nativo, meno complessità. Se oggi avete Azure + AWS, o Azure + on-premise con risorse gestite via Terraform providers, allora Terraform vi dà un linguaggio unificato.

La domanda “e se un domani…” è legittima ma non fatevi paralizzare. Se oggi siete su Azure e non avete piani concreti di multi-cloud, partire con Bicep è ok: migrare più avanti è possibile se serve.

Il vostro team

• Bicep ha una curva di apprendimento più bassa: un team di developer che conoscono Azure ma non hanno mai fatto IaC è produttivo in giorni. È stateless: non dover configurare e proteggere un backend per il file di stato velocizza i flussi di lavoro in piccoli team.
• Terraform richiede un po’ più di tempo (HCL, state management, provider configuration), ma se il team già lo usa per altre cose o ha esperienza DevOps multi-cloud, è un vantaggio riutilizzare quella conoscenza. Vince quando il team deve gestire non solo Azure, ma anche AWS, Google Cloud o servizi SaaS (Cloudflare, Datadog).

Quanto è complessa la vostra infrastruttura?

Single cloud → Bicep va benissimo. Decine di subscription, requisiti di audit stringenti, team distribuiti che deployano in parallelo → Terraform con remote state, locking e workspace vi dà più controllo e meno rischi di conflitti.

Terraform brilla quando l’infrastruttura attraversa confini: Kubernetes, Datadog, PagerDuty, GitHub… centinaia di provider. Una vera lingua franca per orchestrare risorse eterogenee.

Best practice universali

Ok, avete scelto il tool.

Ora come lo usate bene?

Queste 4 regole valgono per Bicep, Terraform e qualunque altro strumento IaC. Se le seguite, eviterete il 90% dei problemi.

1. Versionamento e GitOps

Il flusso GitOps applicato all’IaC: ogni modifica passa da Git e da una pipeline CI/CD.

Source

Ogni modifica passa da una PR, viene revisionata, mergiata, poi deployata automaticamente. Zero modifiche manuali sul portale Azure Non esiste “tanto è una cosa veloce”.

• Branch strategy chiara e consistente (trunk-based o GitFlow, scegliete);
• Tag per release, .gitignore corretto: mai committare state files, .terraform, secret;
• Mai deployare senza vedere cosa succederà. Bicep: az deployment group what-if. Terraform: terraform plan. Sempre. Salvate il plan, fate review, poi apply.

Pipeline tipica:

1. Validate — syntax check;
2. Plan / What-if — preview changes + policy check;
3. Deploy — solo dopo approval manuale per prod;
4. Verify — smoke tests.

Aggiungete Policy as Code (Azure Policy) per i guardrail: “nessuna VM senza backup”, “solo SKU approvati”. Queste policy prevengono errori prima che succedano.

2. Immutabilità

L’immutabilità è un obiettivo (anche se costoso): serve a combattere il configuration drift. Se avete paura di distruggere e ricreare tutto da zero in 10 minuti, significa che il codice non riflette davvero la realtà — ed è un rischio.

Per cambiare una configurazione critica, Blue/Green deployment invece di modifica manuale dal portale:

1. Creo una nuova versione accanto a quella vecchia (Green);
2. Testo le modifiche;
3. Sposto il traffico sulla nuova e solo dopo spengo la vecchia.

3. Modularizzazione

Don’t Repeat Yourself. Se deployate la stessa cosa più volte (es. VNet + Subnet + NSG), create un modulo. I moduli rendono il codice riutilizzabile, testabile, manutenibile.

• Input essenziali, output strategici — un modulo deve nascondere la complessità, non solo spostarla.
• Esempio: un modulo “Storage Account sicuro” dovrebbe includere già le policy di crittografia e l’obbligo di HTTPS, senza che l’utente debba ricordarsi di attivarle.
• Naming conventions consistenti — non rg-prod-001 in un posto e prod-resourcegroup in un altro. Le linee guida del Cloud Adoption Framework (CAF) sono un ottimo punto di partenza.

4. Gestione dei secret

• MAI hardcodare secret nel codice;
• Utilizzare Azure Key Vault;
• I parametri sensibili passati a runtime, non devono essere versionati;
• Utilizzare Managed Identity dove possibile, invece di service principal con password.

Funzionalità	Terraform	Bicep
Persistenza secret	Gestito dall’utente (rischio leak nel backend)	NO (nessun file di stato): transitorio, esiste solo durante il deploy
Protezione output	Attributo sensitive	Decoratore @secure()
Integrazione Key Vault	Richiede blocco data source	Key Vault interrogato durante il deploy
Sicurezza storage	Delegata al servizio di storage	Gestita da Azure

OpenTofu 1.7 introduce la crittografia nativa dello stato, ma richiede una configurazione esplicita e la gestione di chiavi esterne.

Per Terraform in particolare:

• Stato remoto + encryption at rest;
• RBAC granulare per limitare l’accesso allo stato;
• Audit logs per tracciare gli accessi;
• Keyword sensitive ed ephemeral (Terraform 1.10+) nelle variabili/output sensibili — i valori non finiscono nello state;
• Mai scrivere secret nel codice: usate data "azurerm_key_vault_secret" per leggerli a runtime senza memorizzarli nei .tf.

Per Bicep — approccio “Zero-Secret”:

• Stateless: nessun secret registrato localmente;
• Decoratore @secure(): il valore non viene mai salvato nei log di deployment né visualizzato nel portale;
• Key Vault referenziato direttamente nei parametri: il segreto non passa mai per la macchina che esegue il deployment.

Azure Verified Modules (AVM)

Azure Verified Modules: l’iniziativa ufficiale Microsoft per moduli IaC pre-costruiti e supportati.

Azure Verified Modules è l’iniziativa open source ufficiale Microsoft per fornire moduli Bicep e Terraform pre-costruiti, testati e supportati.

Gli Azure Verified Modules seguono le best practice Azure out-of-the-box, con documentazione completa: parametri, esempi d’uso, architettura, test.

Sono divisi in due categorie:

• Resource modules — deploy di una singola risorsa con tutte le sue configurazioni e sotto-risorse;
• Pattern modules — combinano più resource module per deployare architetture complete (es. AKS cluster production-ready con networking, RBAC, monitoring e node pools già dimensionati).

Le due categorie di Azure Verified Modules: resource modules e pattern modules.

Source

⚠️ Importante:

• Non coprono ancora ogni servizio Azure;
• Alcuni moduli sono in preview;
• Astraggono complessità, ma bisogna sapere bene cosa fanno: non usateli ciecamente;
• Testare sempre gli upgrade prima di rilasciare in produzione;

Takeaway: prima di scrivere Bicep da zero, controllate se esiste un modulo AVM. Vi farà risparmiare tempo e vi insegnerà best practice vedendo come è fatto.

Azure Landing Zones (ALZ)

Le ALZ forniscono una Platform Foundation per automatizzare Governance, Networking (Hub & Spoke), Identity e Logging.

• Policy-as-Code — Azure Policy (integrate in Bicep/Terraform) per impedire la creazione di risorse non conformi;
• Subscription Vending — processo automatizzato (via pipeline) che consegna agli sviluppatori una nuova sottoscrizione già “blindata” e pronta all’uso;
• ALZ-Bicep — la soluzione nativa di Microsoft, moduli pronti su GitHub, ottimizzati per chi vuole integrazione totale con l’ecosistema Azure;
• ALZ-Terraform (CafModules) — la scelta per chi usa Terraform Cloud/Enterprise, gestita tramite il provider azurerm con moduli enterprise-grade.

⚠️ Importante: valutate se è davvero il caso di usarle! Per un professionista IaC è fondamentale capire quando le ALZ sono un acceleratore e quando diventano un freno burocratico:

Criterio	SÌ alle ALZ se…	NO alle ALZ se…
Scala	Decine di sottoscrizioni, dipartimenti diversi, networking Hub & Spoke complesso	Startup o piccolo team con una sola sottoscrizione e 2-3 applicazioni
Velocità vs Governance	Priorità a controllo, compliance (banche, sanità), sicurezza perimetrale	Prototipazione rapida (PoC), ambienti sandbox usa-e-getta
Maturità del team	Team Platform dedicato in grado di gestire i moduli ALZ	Team che sta appena imparando le basi: ALZ introduce centinaia di risorse e policy “sotto il cofano” difficili da debuggare

PMI? ALZ for SMB

Per chi non rientra nello scenario enterprise esiste una variante dedicata: Azure Landing Zones for Small and Medium Businesses (ALZ for SMB).

È una versione “snellita” della ALZ classica, pensata per aziende con poche sottoscrizioni e team IT ridotti: meno management group, networking semplificato (tipicamente single-VNet o hub minimale al posto del classico Hub & Spoke), guardrail essenziali invece dell’intero set di policy enterprise.

Disponibile sia in Bicep che in Terraform (con il modulo Azure/avm-ptn-alz-smb/azurerm), è un buon punto di partenza per chi vuole comunque una baseline di governance senza la complessità dell’ALZ “full”.

Azure Developer CLI (azd)

azd è il fast track per passare dal codice locale a un’applicazione funzionante su Azure. Nel 2026 è diventato lo standard per il Local-to-Cloud.

• Ottimo strumento per chi vuole avvicinarsi al mondo IaC, ma anche per i più navigati per sfruttare best practice e velocizzare lo sviluppo;
• Supporta sia Bicep che Terraform;
• Ricca template library AZD Awesome: MS + community;
• È possibile realizzare template custom.

Ha ancora senso imparare IaC nel 2026?

La risposta è SÌ, più di prima! Ma in modo diverso.

• Non è più “scrivere righe di codice” — scrivere HCL o Bicep a mano sta diventando un’attività di nicchia.
• È governance e policy — nel 2026 l’IaC è il linguaggio con cui diamo regole al cloud. Non dichiariamo solo “voglio una VM”, ma “voglio una VM che rispetti queste 10 policy di sicurezza”.
• È il Single Source of Truth — senza IaC non esiste tracciabilità. In un mondo dove l’infrastruttura cambia ogni ora, il file di codice è l’unico modo per sapere cosa abbiamo pagato e perché.

L’impatto dell’AI agentica sull’IaC

Un agent è un’entità autonoma e goal-oriented: riceve un obiettivo, ragiona, pianifica una serie di operazioni, decide quali strumenti/skills utilizzare ed esegue operazioni in autonomia, anche su più iterazioni.

Esempi di agent: IaC expert, Security expert, Cloud expert.

Agent vs Skills

Agent e Skills: gli agent definiscono il ruolo, le skills danno il contesto operativo per i task ricorrenti.

Source

C’è differenza tra usare l’AI come un chatbot e usare un agent, e c’è ulteriore differenza tra usare un agent e usare le skills.

• Agent — definito in agents.md, può rappresentare un ruolo o uno scopo (esperto di IaC, di sicurezza, di cloud).
• Skills — istruzioni specifiche e dettagliate (.md) su come performare un task nel modo che vogliamo. Contengono informazioni sul ruolo e su quando devono essere utilizzate.

In pratica le skills danno contesto agli agent e si usano per i task ricorrenti: generazione moduli Terraform, generazione pipeline CI/CD, scrittura documentazione…

Il nuovo flusso

Non scrivo più i file .tf: dico all’agente

“Configura un ambiente di produzione ridondato per questa app Node.js, rispettando il budget di 200€/mese e i requisiti GDPR”

L’agente genera, valida e applica il codice IaC.

Il nuovo ruolo del Cloud Engineer

• Validare il piano proposto dall’AI;
• Definire i guardrail entro cui l’AI può muoversi;
• Gestire l’architettura logica, lasciando la sintassi alla macchina.

Automatizzate tutto quello che potete, usate l’AI per velocizzare la creazione dei template, ma restate voi i piloti. Il cloud è troppo costoso per lasciarlo guidare completamente dall’AI senza supervisione.

Azure-skills

Azure-skills è il plugin open source con cui Microsoft prova a rendere gli agenti AI davvero produttivi su Azure fornendo:

• una collezione di skill — istruzioni mirate per scenari concreti come preparare un’app per il deploy, validarla prima di azd up, fare diagnostica, analizzare i costi, scegliere il ruolo RBAC giusto, lavorare con AKS, AI Search o Foundry. Ogni skill descrive non solo cosa fare, ma anche quando è il caso di usarla e cosa evitare;
• un layer MCP — l’Azure MCP Server (più Foundry MCP) che dà all’agente strumenti reali per interrogare risorse, leggere pricing in tempo reale, eseguire query su Log Analytics, e così via.

Il valore non è tanto nel singolo prompt, ma nel fatto che guida ed esecuzione viaggiano insieme: l’agente sceglie la skill giusta e poi ha gli strumenti per applicarla davvero. Funziona su parecchi host (VS Code, Copilot CLI, Claude Code, Cursor, Gemini CLI, IntelliJ) ed è installabile con un comando.

Per chi fa IaC è particolarmente utile perché skill come azure-prepare, azure-validate, azure-deploy ed azure-enterprise-infra-planner incorporano le best practice viste in questo articolo — AVM, what-if/plan, RBAC con least privilege, preflight checks.

APEX — Agentic Platform Engineering eXperience for Azure

Per vedere fino a dove può spingersi l’agentic InfraOps in uno scenario realistico, date un’occhiata a APEX di Jonathan Vella (Microsoft): un workflow multi-agent open source che parte da un requisito di platform engineering espresso in linguaggio naturale e arriva a codice Bicep o Terraform deploy-ready, validato e conforme.

Cosa lo rende interessante per chi fa IaC su Azure:

• Multi-agent orchestration — un orchestratore coordina agenti specializzati (Architect, IaC Planner, CodeGen Bicep/Terraform, Challenger per le review) lungo una pipeline a step: requisiti → architettura → governance → piano IaC → codice → deploy → as-built docs;
• Pricing in tempo reale — un Azure Pricing MCP interroga l’Azure Retail Prices API mentre l’agente progetta, così la stima dei costi è parte del design e non un’attività a valle;
• Compliance e guardrail integrati — checklist Well-Architected, security baseline e policy validation eseguite automaticamente prima che il codice esca dalla pipeline;
• Azure Verified Modules first — gli agenti preferiscono comporre AVM esistenti invece di scrivere risorse da zero, riducendo drasticamente il codice custom da mantenere;
• Human-in-the-loop esplicito — approval gate in punti chiave (design, plan, apply): l’agente propone, voi decidete cosa va in produzione;
• Accelerator template + MicroHack — sono disponibili un template repository per partire subito su un nuovo progetto e un MicroHack didattico per provare il flusso end-to-end in autonomia.

Più che una demo, è una reference implementation di come dovrebbe essere fatta una piattaforma agentica per InfraOps su Azure nel 2026: agenti che collaborano, guardrail automatici, costi visibili durante il design e l’umano che resta il pilota.

Se l’agentic IaC vi interessa, è il punto di partenza che vi consiglio.

Conclusioni

Nel 2026 la scelta tra Bicep e Terraform è secondaria rispetto a tre priorità concrete: Governance, Policy e Single Source of Truth.

Entrambi i tool sono maturi e supportati — la decisione dipende dal vostro contesto, dai vincoli di compliance e dalle competenze del team, non da differenze tecniche abissali.

L’IaC agentica cambia il flusso di lavoro, non il vostro ruolo: l’agent acquisisce i requisiti, genera i moduli, suggerisce i fix, produce la documentazione, mentre voi definite i guardrail, validate l’architettura e ne mantenete il controllo.