Azure Landing Zone: perché serve prima di migrare workload nel cloud

Quando un'azienda decide di migrare su Microsoft Azure, la tentazione più comune è iniziare subito: aprire una subscription, caricare le prime macchine virtuali, collegare la VPN aziendale e "vedere come va". Dopo qualche mese arrivano i primi sintomi: subscription sparse e slegate tra loro, policy di sicurezza incoerenti, rete costruita caso per caso, accessi gestiti in modo diverso da un team all'altro, costi che nessuno sa attribuire con precisione. La causa è quasi sempre la stessa: l'ambiente di destinazione è stato creato senza un progetto di fondo.

La soluzione che Microsoft descrive nel Cloud Adoption Framework si chiama Azure Landing Zone (ALZ), ed è il primo componente da costruire in una migrazione — non quello da aggiungere quando i problemi emergono. Questo articolo spiega cos'è, da cosa è composta, perché va progettata prima di migrare e quali competenze servono per realizzarla.

Cos'è un'Azure Landing Zone

Secondo la documentazione ufficiale del Cloud Adoption Framework, un'Azure Landing Zone è un'architettura collaudata e flessibile per governare, mettere in sicurezza e scalare un ambiente Azure multi-subscription. Non è un singolo servizio e non è un prodotto da acquistare: è un insieme di scelte architetturali e di configurazioni — oggi quasi sempre definite come infrastruttura come codice — che definiscono come l'organizzazione usa Azure in modo controllato.

La definizione di Microsoft distingue due componenti:

• Platform landing zone: la fondazione centralizzata che stabilisce governance, sicurezza e risorse condivise per tutti i workload dell'organizzazione. È il livello che appartiene al "platform team" e che non cambia con l'arrivo di nuove applicazioni.
• Application (workload) landing zones: gli ambienti in cui i team di workload distribuiscono e operano le proprie risorse, restando dentro i guardrail definiti dalla piattaforma. Ogni workload ha la propria application landing zone, che contiene tutti gli ambienti necessari (sviluppo, test, produzione), ognuno composto da una o più subscription.

Microsoft suggerisce che la maggior parte delle organizzazioni abbia una sola platform landing zone per ogni tenant Microsoft Entra e che la distribuzione delle application landing zone ai team avvenga con un processo ripetibile (nella terminologia del framework, subscription vending): un modo standardizzato di richiedere, creare e assegnare le subscription ai team di workload.

Quanto all'implementazione, esistono due strade: gli acceleratori forniti da Microsoft (basati su infrastruttura come codice e già allineati alle raccomandazioni) oppure una costruzione personalizzata, realizzata internamente o con il supporto di Microsoft o di partner. Per la maggior parte delle organizzazioni, gli acceleratori rappresentano la via più rapida per ottenere un ambiente allineato alle pratiche raccomandate.

Perché va progettata prima, non dopo

Il punto centrale del titolo è proprio questo: la landing zone non è un progetto parallelo da fare "quando si ha tempo", ma la condizione abilitante della migrazione stessa. Ecco perché.

Il retrofit è molto più costoso. Riorganizzare le subscription, spostare risorse tra management group, introdurre policy a posteriori, ridisegnare la rete e centralizzare il monitoraggio quando i workload sono già in produzione significa pagare due volte lo stesso lavoro. Alcune operazioni, come lo spostamento di risorse tra tenant o tra gerarchie non previste, diventano migrazioni tecniche complesse con rischi di interruzione dei servizi.

Gli ambienti arrivano dopo i team. Se i guardrail vengono attivati quando i workload sono già distribuiti, ogni applicazione migrata nasce fuori standard e richiede interventi di correzione individuali. Al contrario, se il team di workload riceve una subscription "pronta all'uso" — con policy, rete, monitoraggio e accessi già configurati — il tempo per andare in produzione si riduce e la coerenza è garantita per costruzione.

Si evita lo shadow IT. Senza un processo di distribuzione rapido delle subscription, i team di sviluppo possono essere tentati di creare ambienti al di fuori dei canali governati (billing separati, tenant non gestiti): esattamente ciò che il framework indica come conseguenza di un subscription vending lento o assente.

La sicurezza parte dal primo giorno. Con una landing zone, le policy di sicurezza, il controllo degli accessi (RBAC), la rete centralizzata e il monitoraggio sono attivi prima ancora che arrivi il primo workload, non in un secondo momento.

Gli elementi dell'architettura

L'architettura di riferimento di un'Azure Landing Zone è ben definita e si compone di questi blocchi.

Gerarchia di management group. È la struttura di governance dell'ambiente: organizza tutte le subscription e applica gli standard di governance a ogni livello. Una gerarchia ben progettata separa le risorse di piattaforma da quelle di workload e permette di applicare le policy in modo coerente senza complicazioni amministrative inutili.

Subscription di piattaforma. Nell'architettura di riferimento le funzionalità centralizzate vivono in subscription dedicate: una Identity (servizi di dominio e Recovery Services vault), una Connectivity (Azure DDoS Protection, Azure DNS, gateway VPN/ExpressRoute, Azure Firewall e hub di rete peered su più regioni), una Security & Management (workspace Log Analytics, Microsoft Sentinel, dashboard). La scelta di cosa centralizzare dipende dai requisiti: vanno centralizzati solo i servizi che offrono chiari benefici di governance, operatività o costi su più workload.

Subscription di workload. Ogni applicazione ha la propria landing zone, collocata in base alle esigenze in uno dei management group Online, Internal (o "Corp") o Local. Tutte le subscription e le risorse ereditano le policy applicate alla gerarchia: i team hanno flessibilità operativa, ma i controlli di governance e sicurezza restano centralizzati.

Toolset ricorrente. Ogni subscription — di piattaforma o di workload — include un insieme comune di strumenti: Action Groups e Alerts per le notifiche, Cost Management per il budget, assegnazioni di ruoli e di policy, Network Watcher, Microsoft Defender for Cloud e Azure Update Manager per la gestione degli aggiornamenti. Questa uniformità rende l'ambiente gestibile a scala.

Topologia di rete. L'architettura di riferimento prevede due opzioni: hub-spoke classico o Azure Virtual WAN. In entrambi i casi la connettività (VPN, ExpressRoute, firewall, DDoS protection) è centralizzata nella subscription Connectivity e condivisa da tutti i workload.

Le design area del Cloud Adoption Framework

Prima di scegliere come implementare la landing zone, il framework raccomanda di valutare otto aree di progettazione (design areas), che coprono i temi su cui ogni organizzazione deve prendere decisioni esplicite:

• Azure billing e tenant (A) — configurazione corretta di tenant, iscrizioni e modello di fatturazione;
• Identity and access management (B) — il primo confine di sicurezza del cloud pubblico: identità, ruoli e gestione degli accessi;
• Resource organization (C) — progettazione delle subscription e della gerarchia di management group;
• Network topology and connectivity (E) — scelte di rete e connettività;
• Security (F) — controlli e processi per proteggere gli ambienti;
• Management (D, G, H) — baseline di gestione: visibilità, compliance operativa, protezione e ripristino;
• Governance (C, D) — automazione di audit e applicazione delle policy;
• Platform automation e DevOps (I) — strumenti e template per distribuire le landing zone.

Il processo suggerito è semplice: valutare le design area in sequenza, una alla volta, e usare le risposte per orientare le scelte di implementazione. Le decisioni prese in queste aree determinano la fondazione su cui poggeranno tutti i workload futuri.

I principi di progettazione

L'architettura di riferimento si regge su alcuni principi che Microsoft definisce come "bussola" per le decisioni tecniche:

• Subscription democratization — le subscription sono unità di gestione assegnate ai team di business; gli ambienti dev/test/prod sono separati; il processo di distribuzione è self-service; esistono più tipologie di subscription; la gerarchia è scalabile. L'obiettivo è dare autonomia ai team dentro guardrail chiari.
• Policy-driven governance — i guardrail sono implementati con Azure Policy, indipendentemente dallo strumento di deployment: le policy applicano, impongono e verificano la conformità in modo automatico.
• Single control and management plane — si evita di costruire livelli di astrazione proprietari: Azure Resource Manager offre un control plane unico, soggetto a RBAC e policy, per tutte le risorse e tutti i canali di provisioning.
• Application-centric service model — l'attenzione è sulle applicazioni e sui risultati di business, non sul lift-and-shift delle macchine virtuali; IaaS e PaaS vengono trattati allo stesso modo dal punto di vista della sicurezza.
• Alignment with Azure-native design and roadmaps — si preferiscono i servizi nativi di Azure, allineandosi alle roadmap della piattaforma per restare aggiornati sulle nuove capacità.

Il framework è esplicito anche sugli effetti delle deviazioni: policy duplicate, eccezioni, overhead operativo e complessità di integrazione sono il prezzo tipico di chi si allontana dai principi senza una ragione ponderata.

Le competenze per costruire una landing zone

Un'Azure Landing Zone non si configura "sul momento": richiede un team con competenze specifiche in almeno cinque ambiti: identità e accessi (Microsoft Entra ID), rete (hub-spoke o Virtual WAN, ExpressRoute, Azure Firewall), governance (management group, Azure Policy, RBAC), automazione (Bicep, Terraform, pipeline CI/CD) e monitoraggio (Log Analytics, Microsoft Sentinel, Defender for Cloud). Sul piano delle certificazioni Microsoft, i riferimenti sono AZ-900 (fondamenti), AZ-104 (Azure Administrator) e soprattutto AZ-305 (Designing Microsoft Azure Infrastructure Solutions), che copre la progettazione di soluzioni di governance, rete e sicurezza a scala aziendale.

Per chi migra senza queste competenze interne, la strada più realistica è affiancare al proprio team un percorso di formazione mirato, che accompagni dal progetto iniziale alla gestione operativa dell'ambiente.

In sintesi

L'Azure Landing Zone è la decisione architetturale che determina il successo di una migrazione: costruita prima, dà a ogni workload un ambiente sicuro, governato e coerente dal primo giorno; rimandata, trasforma ogni applicazione migrata in un problema di conformità da risolvere a posteriori. La domanda non è se serve, ma quanto costa aspettare a costruirla.

Digital Lab srl accompagna i team IT nell'acquisizione delle competenze Microsoft necessarie a progettare e gestire ambienti Azure a scala aziendale: scopri i corsi Microsoft Azure.