La prima decisione architetturale, prima ancora di scrivere codice, è quale risorsa provisionare in Azure per esporre le capability di AI. La scelta condiziona endpoint, autenticazione, quote e persino quali feature saranno disponibili.
Multi-service vs single-service
Esistono due modelli di provisioning:
- Risorsa multi-service (
Azure AI services): un’unica risorsa che aggrega più servizi — Language, Vision, Speech, Translator, Document Intelligence, Content Safety — dietro un solo endpoint e una sola coppia di chiavi. È la scelta giusta quando un’applicazione consuma più servizi cognitivi e si vuole fatturazione e gestione consolidate, meno risorse da governare e una sola configurazione RBAC. - Risorsa single-service: una risorsa dedicata a un singolo servizio (es. un
Languageo unComputer Vision). Si usa quando serve isolare quote, costi o SKU di un solo servizio, o quando la feature richiede obbligatoriamente una risorsa dedicata (vedi trappole).
In Azure AI Foundry, quando si crea un progetto la risorsa di backing è tipicamente una risorsa Azure AI services/Azure AI Foundry: è l’evoluzione della multi-service, con in più l’accesso al model catalog, al deployment dei modelli e agli agent.
Quando serve un hub/progetto Foundry
Una risorsa standalone basta se l’app deve solo invocare un servizio via REST/SDK (es. estrarre entità, fare OCR, sintesi vocale). Serve invece un hub + project di Foundry quando il lavoro è di tipo generative AI orchestrato:
- deploy e consumo di modelli dal catalogo (inclusi i modelli Azure OpenAI), fine-tuning, valutazioni;
- prompt flow, agenti (Foundry Agent Service), tracing;
- connections condivise verso Storage, Key Vault e altre risorse, con governance a livello di hub.
L’hub è il confine di sicurezza e collaborazione; i project sono i workspace al suo interno che ereditano connections e configurazioni.
Region e SKU (F0 vs S0)
La region non è neutra: non tutti i servizi né tutti i modelli sono disponovunque. Va scelta in base a disponibilità di modelli/feature, data residency/compliance e latenza verso gli utenti. Un modello del catalogo può esistere in una region e non in un’altra.
Il pricing tier (SKU) determina i limiti:
- F0 (Free): gratuito ma con rate limit stringenti (transactions per second) e volume mensile capato; in genere una sola risorsa F0 per subscription per tipo di servizio. Ottimo per dev/test e PoC.
- S0 (Standard): pay-as-you-go, throughput scalabile e quote produzione. È l’unica scelta sensata in produzione.
Il tier si sceglie alla creazione e alcune migrazioni richiedono di ricreare la risorsa.
Endpoint, chiavi ed esposizione via REST/SDK
Ogni risorsa espone:
- un endpoint (URL). Con un custom subdomain (es.
https://mymme.cognitiveservices.azure.com/) si abilita l’autenticazione con Microsoft Entra ID e i private endpoint; l’endpoint regionale supporta invece solo l’auth a chiave. - due chiavi (key1/key2) per consentire la rotazione senza downtime.
L’accesso via REST API avviene con header Ocp-Apim-Subscription-Key:
curl -X POST "$ENDPOINT/language/:analyze-text?api-version=2024-11-01" \
-H "Ocp-Apim-Subscription-Key: $KEY" -H "Content-Type: application/json" -d @body.json
Gli SDK (Python, C#, JS, Java) incapsulano gli stessi endpoint e supportano sia la chiave sia i token Entra ID via DefaultAzureCredential e ruoli come Cognitive Services User, opzione preferibile alle chiavi in produzione (nessun segreto da gestire, integrazione con managed identity).
Trappole tipiche d’esame
- Scenario: devi addestrare un modello custom (Custom Vision, Custom Speech, custom question answering, custom Document Intelligence). → Risposta giusta: provisiona una risorsa single-service dedicata; la multi-service non copre tutti i workflow di training/prediction.
- Scenario: feature ad accesso limitato (es. alcune capability di Face/Vision). → Richiedono registrazione/approvazione e spesso una risorsa dedicata: non basta la chiave multi-service.
- Scenario: l’app deve autenticarsi con Entra ID / managed identity anziché con le chiavi. → Serve la risorsa con custom subdomain; l’endpoint regionale supporta solo l’auth a chiave.
- Scenario: hai bisogno di model catalog, fine-tuning, prompt flow o agenti. → Non basta una risorsa cognitiva standalone: serve un hub/project di Azure AI Foundry.
- Scenario: serve solo qualche chiamata per un PoC a costo zero. → Usa F0, ricordando i limiti di TPS/volume e la regola di una sola F0 per subscription per servizio; per la produzione passa a S0.