Il dominio Azure architecture and services vale il 35-40% dell’esame AZ-900. Se conosci a memoria i servizi core con almeno un caso d’uso ciascuno, hai già passato mezzo esame. In questa guida ti presento i servizi che compaiono più spesso nelle domande, raggruppati nei 3 pilastri classici: Compute, Storage, Networking.
Se stai iniziando ora la preparazione, prima leggi la guida completa AZ-900 per orientarti sul blueprint. Poi torna qui per approfondire questa sezione critica.
Compute — dove gira il tuo codice
Compute = capacità di calcolo (CPU + RAM + eventualmente GPU). Azure offre quattro grandi famiglie. La tabella riassuntiva ti dà l’orientamento; sotto approfondisci ogni servizio con il caso d’uso principale.
| Servizio | Modello | Cosa gestisci tu | Cosa gestisce Azure | Quando sceglierlo |
|---|---|---|---|---|
| Virtual Machines | IaaS | OS, patch, runtime, app | Hardware, hypervisor | Lift-and-shift, software legacy, controllo totale |
| App Service | PaaS | Solo il codice o container | OS, web server, patch, scaling | Web app o API nuove, deploy rapido |
| Functions | Serverless | Solo la funzione | Tutto il resto, esecuzione on-demand | Event-driven, burst, workload discontinui |
| ACI e AKS | Container | Immagine + manifest | Runtime container (e control plane Kubernetes su AKS) | Microservices (AKS) o container one-shot (ACI) |
Azure Virtual Machines (VM) — IaaS classico
Una VM Azure è una macchina virtuale Windows o Linux con OS, disco, network. Sei responsabile di patch, security updates, backup, configurazione firewall del sistema. Microsoft gestisce solo l’hardware sottostante e l’hypervisor.
Quando usarla: lift-and-shift di app on-premises esistenti, software legacy che richiede OS-level access, workload custom (database Oracle, SAP, ecc.), quando serve controllo totale.
| Variante | Cosa fa | Caso d’uso tipico |
|---|---|---|
| Virtual Machine Scale Sets (VMSS) | Gruppi di VM identiche che scalano automaticamente in base a metriche CPU, memoria o richieste HTTP | Architetture stateless auto-scaling (web tier, pool API) |
| Spot VMs | Capacità inutilizzata Azure con sconto fino al 90%, revocabile da Microsoft con 30s di preavviso | Batch job, rendering, CI/CD workers, workload tolleranti alle interruzioni |
Azure App Service — PaaS per web app
Piattaforma managed per web app (.NET, Node.js, PHP, Python, Java, Ruby), API REST e mobile backend. Tu deployi il codice (via Git, GitHub Actions, ZIP, Docker), Microsoft gestisce OS, web server (IIS/Nginx), patch, scaling.
Feature killer: auto-scaling out-of-the-box, deployment slot (blue-green deploy con swap istantaneo), custom domain + SSL Let’s Encrypt automatico, backup schedulati.
Quando usarla: la larga maggioranza delle web app nuove. Salti a VM solo se serve installare qualcosa che App Service non permette (driver del sistema, servizi background persistenti tipo WCF windows service, ecc.).
Azure Functions — Serverless event-driven
Codice che gira in risposta a eventi: un file caricato su Blob, un messaggio in Queue, uno schedule cron, una HTTP call, un evento IoT. Non gestisci server: scrivi la funzione, la deployi, Azure la esegue on-demand.
| Plan | Modello di billing | Cold start | Quando sceglierlo |
|---|---|---|---|
| Consumption | Pay-per-execution, con quota gratuita mensile inclusa | Sì | Burst, workload discontinui, prototipi |
| Premium | Istanze pre-warmed + VNet integration | No | Workload latency-sensitive, integrazione network privato |
| App Service | Function condivide un piano App Service già esistente | No | Riutilizzo di capacità già acquistata |
Casi d’uso tipici: webhook di terze parti, image processing on upload, scheduled tasks (backup, cleanup), API micro-endpoint, event stream processing (con Event Hub o Cosmos DB change feed).
Container: ACI e AKS
| Servizio | Cosa gestisce Azure | Orchestrazione | Billing | Caso d’uso |
|---|---|---|---|---|
| Azure Container Instances (ACI) | Runtime del container singolo o gruppo piccolo | No | Pay per second | Burst compute, job one-shot, task schedulati |
| Azure Kubernetes Service (AKS) | Control plane Kubernetes (gratuito) | Sì, Kubernetes | Paghi solo i node worker | Microservices in produzione con auto-scaling, self-healing, rolling update |
Storage — dove risiedono i dati
Storage Azure è raggruppato in Storage Account (contenitore logico) che espone 4 servizi principali:
Blob Storage — file non strutturati
Il servizio più usato in assoluto. Blob = Binary Large OBject: qualsiasi file (immagine, video, PDF, log, backup DB, ZIP, ML dataset, ecc.). Acceduto via HTTP/HTTPS con URL diretto o API SDK. Due leve ti fanno risparmiare in bolletta: access tier (quanto spesso leggi il dato) e ridondanza (a quale disastro deve sopravvivere).
Access tier — pilastro del cost optimization. Sono una caratteristica del Blob Storage: dischi e file share hanno logiche di tiering diverse.
| Tier | Accesso tipico | Retention minima | Costo di storage | Latenza di lettura |
|---|---|---|---|---|
| Hot | Frequente | Nessuna | Il più alto dei quattro | Millisecondi |
| Cool | Poco frequente | 30 giorni | Inferiore a Hot, ma con costi di accesso più alti | Millisecondi |
| Cold | Raro | 90 giorni | Inferiore a Cool, costi di accesso ancora più alti | Millisecondi |
| Archive | Circa 1 volta all’anno (backup, compliance) | 180 giorni | Il più basso dei quattro | Ore (richiede rehydration) |
Ridondanza — sceglila in base al disastro da cui vuoi proteggerti:
| Sigla | Copie totali | Location | Sopravvive a | Costo relativo |
|---|---|---|---|---|
| LRS (Locally Redundant Storage) | 3 | Stesso datacenter | Rack failure (non a un datacenter failure) | Minimo |
| ZRS (Zone-Redundant Storage) | 3 | 3 Availability Zone nella stessa region | Perdita di un intero datacenter | Medio-basso |
| GRS (Geo-Redundant Storage) | 6 | 3 in region primaria + 3 in una region pair geograficamente distante | Disastro regionale | Medio-alto |
| GZRS (Geo-Zone-Redundant Storage) | 6 | ZRS in region primaria + LRS in region pair | Perdita di datacenter + disastro regionale | Massimo |
Disk Storage — virtual disk per VM
Sono i dischi montati come drive di una VM (C:, D: su Windows; /dev/sda su Linux). Vengono in 4 performance tier:
- Standard HDD — magnetic, per workload dev/test non-critical
- Standard SSD — SSD entry-level, per workload production con IOPS moderati
- Premium SSD — SSD alte prestazioni, per DB e workload IOPS-intensive
- Ultra Disk — massima performance, con IOPS e throughput configurabili indipendentemente dalla dimensione del disco, per SAP HANA e Oracle mission-critical
File Storage — SMB share cloud
Share SMB 3.0 o NFS montabili contemporaneamente da più VM Azure e/o da on-premises. Utile per: file server condiviso (Excel, PDF, media), lift-and-shift di app che si aspettano un file share Windows, home directory user in scenari VDI.
Alternativa a costruire un file server VM classico — Azure Files è managed, backup automatici, snapshot self-service.
Queue e Table Storage — message queue e NoSQL leggero
- Queue Storage — coda di messaggi asincrona per disaccoppiare producer e consumer (es. web app che manda job a un worker background).
- Table Storage — NoSQL key-value molto economico. Superato da Cosmos DB Table API per casi production con SLA critici, ma resta valido per workload budget-sensitive.
Networking — come le risorse comunicano
Il networking Azure è cloud-first ma familiare a chi viene dal mondo on-premises. Concetti chiave AZ-900:
Virtual Network (VNet)
Il network isolato privato dentro Azure. Ogni risorsa (VM, App Service integrato, Function integrata) può essere collegata a una VNet. Le VNet hanno:
- CIDR range (es.
10.0.0.0/16) — spazio di indirizzi privati - Subnet che dividono il CIDR in porzioni (es.
10.0.1.0/24per web tier,10.0.2.0/24per DB tier) - Network Security Groups (NSG) — firewall stateful a livello subnet/NIC per allow/deny traffic
VPN Gateway
Connessione crittografata site-to-site tra la tua VNet Azure e la tua rete on-premises (o point-to-site tra Azure e singoli PC remote). Usa IPsec/IKE. Banda condivisa via internet — latenza variabile, buono per workload non critical o hybrid dev/test. Il costo dipende dallo SKU del gateway e dal traffico in uscita: calcolalo sul calcolatore prezzi ufficiale Azure, perché i listini cambiano spesso.
ExpressRoute
Link privato dedicato tra la tua rete on-premises (o datacenter partner) e Azure, senza passare per internet. Fornito da provider come Colt, Equinix, Retelit. Banda dedicata (dai circuiti standard nell’ordine dei Mbps/Gbps fino a 100 Gbps con ExpressRoute Direct), latenza deterministica, compliance-friendly per workload regolamentati (finance, sanità, PA).
Quando ExpressRoute vince su VPN: SAP prod, database mirroring cross-region, media streaming real-time, workload con SLA stringenti sul network.
Azure DNS
Nameserver DNS managed per gestire domini pubblici. Se hai contoso.com puoi hostarlo su Azure DNS invece di GoDaddy o Cloudflare. Integrato con Azure services (App Service, Traffic Manager, ecc.). Prezzo trascurabile.
Azure Front Door e Application Gateway
Non sono nel core AZ-900 ma vale la pena conoscerli superficialmente:
- Front Door — CDN + WAF globale, load balancing L7 tra region multiple
- Application Gateway — load balancer L7 regionale + WAF integrato
- Azure Load Balancer — LB L4 regionale, per traffico TCP/UDP raw
- Traffic Manager — routing DNS-based tra endpoint (region-level failover)
Come studiare questi servizi per l’esame
Regola pratica: per ognuno dei servizi sopra, devi saper rispondere in 30 secondi a 3 domande:
- Cosa fa (una frase)
- Un caso d’uso concreto (un esempio real-world)
- Come si differenzia dai servizi affini (VM vs App Service, Blob vs Disk vs File, VPN vs ExpressRoute)
Il test pratico più veloce è aprirsi il portale Azure gratuito, navigare al catalog services (Create a resource → Categories) e leggere ogni service description ufficiale. Toccando con mano fissa i concetti molto meglio della sola teoria.
Poi validi con la simulazione AZ-900 di CertUp — le domande sul dominio “Azure services and architecture” ti forzano proprio a matchare caso d’uso ↔ servizio.
Il tuo prossimo passo su Azure
Una volta interiorizzati i pilastri Compute, Storage e Networking, il passo successivo è capire dove ti porta l’AZ-900 dentro il percorso Microsoft. La cert Fundamentals è valida a vita e sblocca un badge Credly che puoi mettere su LinkedIn: da lì il percorso naturale prosegue con le Associate — oggi AZ-104 (Azure Administrator) è la tappa più solida, affiancata da AZ-700 (networking) — e più avanti con le Expert (AZ-305, AZ-400).
Una precisazione sulle date, perché molti percorsi in giro indicano ancora la coppia “AZ-104 + AZ-204”: AZ-204 (Azure Developer Associate) si è ritirato il 31 luglio 2026. Non è più sostenibile né prenotabile, quindi quella coppia non è più una strada percorribile: conviene puntare su AZ-104 e, per il profilo sviluppatore, controllare sulla pagina ufficiale Microsoft quale esame ha preso il posto di AZ-204 prima di comprare il voucher. Stessa avvertenza per il profilo sicurezza: AZ-500 (Azure Security Engineer) si ritira il 31 agosto 2026, quindi ha senso solo se riesci a sostenerlo entro quella data. Le date cambiano spesso: tienile sotto controllo nel calendario dei ritiri e degli esami in scadenza.
Se stai ancora scegliendo da quale Fundamentals partire, sappi che il vecchio confronto “AZ-900 o MS-900?” non ha più senso: MS-900 (Microsoft 365 Fundamentals) è stato ritirato il 31 marzo 2026. Attenzione anche ad AI-900, che trovi ancora citato in molti percorsi online: è stato ritirato il 30 giugno 2026 e sostituito da AI-901 — se ti interessa l’area AI, prepara direttamente quello (cosa cambia fra AI-900 e AI-901). Le Fundamentals ancora sostenibili accanto ad AZ-900 sono quindi PL-900 (Power Platform), SC-900 (security, compliance e identity), DP-900 (dati) e AI-901 (intelligenza artificiale). Per orientarti sul blueprint dell’esame resta valida la guida completa AZ-900.