Le scelte infrastrutturali di una soluzione Foundry si prendono una volta sola e restano: la gerarchia delle risorse fissa i confini di governance, il tipo di deployment decide dove vengono elaborati i dati e come arriva la fattura, e il modo in cui progetto e deployment entrano in pipeline decide quanto è ripetibile il rilascio. L’esame chiede di motivarle, non di eseguirle nel portale.

Risorsa, progetto, risorse connesse

Microsoft Foundry organizza tutto su tre livelli. La risorsa Foundry è la risorsa Azure di primo livello, di tipo Microsoft.CognitiveServices/accounts con kind AIServices: lì vivono rete, sicurezza e deployment dei modelli. Il progetto è una sottorisorsa accounts/projects ed è il confine di sviluppo, dove i team costruiscono agenti, valutazioni e file riusando deployment e connessioni. Le risorse connesse — Storage, Key Vault, Azure AI Search — restano risorse indipendenti con la propria governance: mettere in privato la risorsa Foundry non mette in privato lo storage collegato.

Questa separazione si riflette su Azure RBAC. Le azioni di control plane (creare deployment e progetti) sono distinte da quelle di data plane (costruire agenti, valutare, caricare file), e le assegnazioni si scopano sia sulla risorsa sia sul progetto; il punto di partenza a minimo privilegio è il ruolo Foundry User a ogni sviluppatore e a ogni identità gestita di progetto. Due distrattori tipici: il primo progetto della risorsa, marcato come default, ha capacità che gli altri non hanno (batch, fine-tuning, stored completion), e alcune API restano solo a livello di risorsa, come Translator. Foundry inoltre non fa failover automatico fra regioni: multi-regione significa risorse separate e instradamento applicativo.

Serverless API o managed compute

Le opzioni di deployment sono due e la documentazione indica la preferita. Il Serverless API è l’opzione più capace: copre tutti i Foundry Models, venduti da Azure e da partner selezionati, include i tipi standard, provisioned, batch e developer, permette elaborazione regionale, per data zone o globale, e offre filtri di contenuto personalizzabili, autenticazione senza chiavi con Microsoft Entra ID e rete privata. Si fattura a token consumati o a capacità riservata con le PTU.

Il managed compute, in anteprima, ospita modelli open-source, di partner o con pesi personalizzati su GPU dedicate: si dimensiona in termini di modello e non di SKU di macchina virtuale, con acceleratori A100 da 80 GB, H100 da 80 GB e MI300X da 192 GB, runtime curati da Microsoft, auto-scaling e scale-to-zero che ferma subito la fatturazione. Sul piano economico cambia tutto: si paga a ora per SKU di acceleratore, non a token, e la quota arriva dal processo di Foundry, separata da quella delle macchine virtuali Azure e non intercambiabile. Un vincolo che spesso decide da solo: in preview il filtro di contenuto non è disponibile sul managed compute. Per il prototipo c’è l’instant access in anteprima, che chiama un modello per nome senza creare deployment, con quota globale separata ma senza modelli fine-tuned né guardrail personalizzati.

I nove tipi di deployment e come si sceglie

Dentro il Serverless API i tipi sono nove, con codici SKU precisi: GlobalStandard, GlobalProvisionedManaged, GlobalBatch, DataZoneStandard, DataZoneProvisionedManaged, DataZoneBatch, Standard, ProvisionedManaged e DeveloperTier. Tre famiglie — standard a consumo, provisioned a capacità riservata, batch asincrono con sconto del 50% e obiettivo di 24 ore — per tre ambiti: globale, data zone (Stati Uniti, Unione Europea, Asia Pacifico) e regione singola. I dati a riposo restano comunque nella geografia designata; cambia dove si elabora l’inferenza.

La regola di partenza è esplicita: iniziare da Global Standard, che esce per primo sui nuovi modelli, costa meno e copre più regioni, e spostarsi solo per un motivo preciso, cioè residenza del dato, throughput riservato o batch. Ne discende un vincolo di pianificazione: i nuovi tipi arrivano nell’ordine Global, Data Zone, regione singola, quindi inchiodare il carico a una regione può significare non avere ancora il modello più recente. Developer serve solo a valutare un modello fine-tuned: 24 ore di vita, nessuna residenza garantita, nessuno SLA.

Configurare deployment e agenti dentro una pipeline

Deployment di modelli e progetti sono control plane, quindi codificabili: Azure CLI, Bicep, ARM, Terraform e SDK di management fanno la stessa cosa. Il flag --allow-project-management va deciso alla creazione della risorsa perché non è più modificabile.

client.accounts.begin_create(
    resource_group_name, foundry_resource_name,
    account={
        "location": "eastus",
        "kind": "AIServices",
        "sku": {"name": "S0"},
        "identity": {"type": "SystemAssigned"},
        "properties": {"allowProjectManagement": True,
                       "customSubDomainName": foundry_resource_name},
    },
).result()

Il deployment del modello si descrive con nome, formato (il provider), versione e SKU, più la capacità, cioè il rate limit in token al minuto, e la policy di guardrail. In Bicep la risorsa è Microsoft.CognitiveServices/accounts/deployments, con sku.name pari al tipo di deployment e raiPolicyName che punta alla policy dei filtri.

az cognitiveservices account deployment create \
  --name $accountName --resource-group $resourceGroupName \
  --deployment-name Phi-4-mini-instruct --model-name Phi-4-mini-instruct \
  --model-version 1 --model-format Microsoft \
  --sku-name GlobalStandard --sku-capacity 1

Lo stesso vale per gli agenti: un prompt agent si definisce anche via SDK o REST dentro la pipeline, ed è il motivo per preferire il codice al portale (controllo di versione, code review, rollout automatico). Le versioni sono snapshot immutabili, in codice l’agente si referenzia come nome_agente:versione, e all’avvio il pattern corretto è get-or-create, trattando un 404 come definitivo. La pubblicazione dà un endpoint stabile, ma i permessi dell’identità di progetto non si trasferiscono all’agente pubblicato: vanno riassegnati.

Da ricordare per l’esame

  • La risorsa Foundry porta governance, rete e deployment; il progetto porta agenti, valutazioni e file; le risorse connesse hanno governance propria.
  • Serverless API è l’opzione preferita e si fattura a token o PTU; il managed compute si fattura a ora per SKU di acceleratore, ha quota separata dalle VM Azure e in preview non offre filtro di contenuto.
  • Si parte da Global Standard e ci si sposta solo per residenza del dato, throughput riservato o batch; i tipi escono nell’ordine Global, Data Zone, regione singola.
  • Dopo la pubblicazione di un agente i permessi dell’identità di progetto non passano all’agente: vanno riassegnati.