Che cosa sono gli agenti ospitati?

Quando si creano applicazioni agentiche usando framework open source, in genere si gestiscono molti problemi trasversali: containerizzazione, configurazione del server Web, sicurezza, persistenza della memoria, ridimensionamento, strumentazione e rollback delle versioni. Queste attività diventano ancora più complesse in ambienti cloud eterogenei.

Gli agenti ospitati nel servizio Foundry Agent risolvono queste sfide per gli utenti di Microsoft Foundry. Gli agenti ospitati chiamano i modelli dal catalogo dei modelli Foundry per eseguire il ragionamento mentre il codice personalizzato gestisce l'orchestrazione. Usando questa piattaforma gestita, è possibile distribuire e gestire gli agenti di intelligenza artificiale in modo sicuro e su larga scala. È possibile usare il codice dell'agente personalizzato o un framework agente preferito con distribuzione e gestione semplificate.

Se si esplorano gli agenti ospitati con un agente di codifica di intelligenza artificiale, la competenza Microsoft Foundry consente di connettere questi concetti alle attività di implementazione, distribuzione e operazioni.

Quando usare gli agenti ospitati

Scegli gli agenti ospitati anziché quelli basati su prompt quando devi:

Porta il tuo codice: usa qualsiasi framework (Agent Framework, LangGraph, Kernel semantico o codice personalizzato) anziché definizioni basate solo su prompt.
Usare protocolli personalizzati - accettare webhook o payload non OpenAI tramite il protocollo Invocations.
Controllare le risorse di calcolo : specificare CPU e memoria per la sandbox dell'agente.
Eseguire carichi di lavoro con stato: rendere persistenti i file e lo stato tra i vari turni tramite $HOME e l'endpoint /files.
Gestire in modo resiliente attività di lunga durata - preservare il lavoro dell’agente in corso durante le interruzioni del processo e riprodurre ai client che si riconnettono i risultati trasmessi in streaming.

Come funziona

Si impacchetta l'agente come immagine del contenitore e lo si carica in Registro Azure Container. Quando si esegue la distribuzione, il servizio Agent esegue il pull dell'immagine, assegna un Microsoft Entra ID dedicato (identità agente) ed espone un endpoint dedicato per l'agente.

Durante l'esecuzione, Agent Service alloca le risorse di calcolo per la sessione e inoltra le richieste al container. Il codice dell'agente gestisce tali richieste e può chiamare i modelli Foundry, gli strumenti della casella degli strumenti e i servizi downstream Azure usando l'identità dell'agente. La piattaforma gestisce la scalabilità, la persistenza dello stato della sessione, l'osservabilità e la gestione del ciclo di vita.

Il diagramma seguente mostra come viene divisa la responsabilità. Si è proprietari del codice eseguito all'interno della sandbox. La piattaforma gestisce l'endpoint, l'identità, il ridimensionamento e lo stato della sessione correlati ad esso.

Importante

Quando si usano agenti ospitati con altri prodotti e servizi Microsoft, è necessario leggere tutta la documentazione pertinente per tali prodotti e servizi e comprendere i rischi correlati e le considerazioni sulla conformità.

Se si usa l'agente ospitato con server, agenti, codice di terze parti o modelli Direct non di Azure ("Sistemi di Terze Parti"), lo si fa a proprio rischio. I sistemi di terze parti sono prodotti non Microsoft ai sensi delle condizioni del prodotto Microsoft e sono disciplinati dalle proprie condizioni di licenza di terze parti. L'utente è responsabile di qualsiasi utilizzo e costi associati.

È consigliabile esaminare tutti i dati condivisi e ricevuti da sistemi di terze parti e riconoscere le procedure di terze parti per la gestione, la condivisione, la conservazione e la posizione dei dati. Analogamente, se ci si connette o si integra con servizi Microsoft e funzionalità non Foundry, è importante esaminare le procedure relative ai dati. È tua responsabilità gestire se i tuoi dati fluiranno oltre i confini di conformità e geografici della tua organizzazione e le eventuali implicazioni correlate, nonché garantire che siano predisposti i permessi, i confini e le approvazioni appropriati.

L'utente è responsabile di esaminare e testare attentamente le applicazioni compilate nel contesto dei casi d'uso specifici e di prendere tutte le decisioni e le personalizzazioni appropriate. Ciò include l'implementazione di mitigazioni di intelligenza artificiale responsabili, ad esempio metaprompt, filtri di contenuto o altri sistemi di sicurezza, e garantire che le applicazioni soddisfino gli standard di qualità, affidabilità, sicurezza e attendibilità appropriati. Vedi la nota sulla trasparenza di Foundry Agent Service.

Concetti chiave

Agenti ospitati

Gli agenti ospitati sono applicazioni di intelligenza artificiale agentiche containerizzate che vengono eseguite su Agent Service. A differenza degli agenti basati su prompt, definiti interamente tramite prompt e configurazione degli strumenti nel portale Foundry, gli agenti ospitati sono il tuo codice, pacchettizzato come immagine container. Si sceglie il framework, si controlla il comportamento di runtime e si distribuisce l'immagine nell'infrastruttura gestita da Microsoft.

La piattaforma gestisce automaticamente il ciclo di vita del contenitore in base all'attività, il provisioning delle risorse quando si crea una versione e il deprovisioning quando viene raggiunto il timeout di inattività.

Modello di isolamento

Gli agenti ospitati vengono eseguiti in sandbox isolate su macchine virtuali differenti per ogni sessione. Ogni sessione ottiene una sandbox dedicata con un file system permanente ($HOME e /files) abilitando la scalabilità a zero, la ripresa con stato e l'avvio a freddo prevedibile. Le sessioni sono isolate l'una dall'altra e lo stato viene ripristinato automaticamente quando una sessione viene ripresa dopo l'inattività.

Protocolli: risposte, invocazioni e invocazioni (WebSocket)

I contenitori dell'agente ospitato possono esporre uno o più protocolli. Ogni protocollo viene fornito da una libreria leggera che gestisce il server HTTP o WebSocket, i controlli di integrità e l'integrazione openTelemetry. I protocolli Risposte, Chiamate e Chiamate (WebSocket) sono disponibili in tutte le aree che supportano gli agenti ospitati.

Quale protocollo è necessario usare?

Scenario	Protocollo	Perché
Chatbot o assistente per conversazioni	Risposte	La piattaforma gestisce la cronologia delle conversazioni, gli eventi di streaming e il ciclo di vita della sessione, usando qualsiasi SDK compatibile con OpenAI come client.
Domande & risposte in più turni con RAG o strumenti	Risposte	Threading ID conversazione predefinito e gestione dei risultati degli strumenti.
Elaborazione in background e asincrona	Risposte	`background: true` con polling e cancellazione gestiti dalla piattaforma. Acconsentire esplicitamente separatamente quando il gestore deve eseguire il ripristino dopo un'interruzione del processo.
Agente pubblicato in Teams o Microsoft 365	Risposte + Attività	Il protocollo Risposte alimenta la logica dell'agente; la piattaforma collega automaticamente le risposte al protocollo Activity per il recapito dei canali.
Ricevitore webhook (GitHub, Stripe, Jira e così via)	Invocazioni	Il sistema esterno invia il proprio formato di payload: non è possibile modificarlo in modo che corrisponda a /responses.
Elaborazione non conversazionale (classificazione, estrazione, batch)	Invocazioni	L'input è costituito da dati strutturati, non da un messaggio di chat. JSON arbitrario in, JSON arbitrario out.
Protocollo di streaming personalizzato (AG-UI e così via)	Invocazioni	AG-UI e altri protocolli agent-UI non sono compatibili con OpenAI. È necessario un controllo SSE non elaborato.
Bridge di protocollo (GitHub Copilot, sistemi proprietari)	Invocazioni	Il chiamante ha un proprio protocollo che non esegue il mapping a /responses.
Agente vocale in tempo reale (microfono in ingresso, voce in uscita)	Invocazioni (WebSocket)	Streaming bidirezionale tramite una singola connessione persistente. Abbina Pipecat, LiveKit o Voice Live nel tuo contenitore. Vedere Creare un agente vocale.

Suggerimento

Non sono sicuro? Iniziare con le risposte. È sempre possibile aggiungere un endpoint chiamate in un secondo momento. Un agente ospitato può supportare entrambi i protocolli contemporaneamente.

Il protocollo che scegli determina il payload che il contenitore riceve e in che misura la piattaforma gestisce per te il ciclo di vita delle sessioni, dello streaming e delle attività in background. Un singolo agente può supportare più protocolli, quindi questa scelta non è permanente. Usare l'albero delle decisioni seguente per selezionare un punto di partenza.

Confronto tra protocolli

	Risposte	Invocazioni
Migliore per	La maggior parte degli agenti: la piattaforma gestisce la cronologia delle conversazioni, il ciclo di vita di streaming e l'esecuzione in background	Agenti che necessitano di controllo HTTP completo, payload personalizzati o flussi di lavoro asincroni a esecuzione prolungata
Payload	Contratto per risposte compatibili con OpenAI	JSON arbitrario tramite /invocazioni: si definisce lo schema
Client SDK	Qualsiasi SDK compatibile con OpenAI (Python, JS, C#) funziona in modo predefinito	Client personalizzato: si definisce il contratto
Cronologia delle sessioni	Gestito dalla piattaforma tramite ID conversazione	È possibile gestire le sessioni (in memoria, Cosmos DB e così via)
Streaming	ResponseEventStream gestito dalla piattaforma con eventi del ciclo di vita	SSE non elaborato: formatta e scrivi direttamente gli eventi
Background/esecuzione prolungata	Modalità in background e polling integrati; ripristino resiliente facoltativo per le risposte in background memorizzate	Attività resilienti nell’SDK AgentServer; definisci endpoint di polling o di streaming

La modalità in background e l'esecuzione resiliente risolve diversi problemi. La modalità in background consente al lavoro di continuare anche dopo che la richiesta iniziale ha restituito una risposta. L'esecuzione resiliente mantiene il lavoro dopo l'arresto del processo di hosting. Per il modello di recupero e le responsabilità dell'applicazione, vedere Resilienza per gli agenti ospitati a esecuzione prolungata.

Protocolli aggiuntivi

Gli agenti ospitati supportano anche il protocollo Activity per Teams e l'integrazione del canale Microsoft 365. Quando si usa il protocollo Risposte per la logica dell'agente e si pubblica in canali Microsoft 365, ad esempio Teams, la piattaforma collega automaticamente le risposte al protocollo Attività per la distribuzione di canali, senza cablaggi separati. Il protocollo A2A supporta la delega da agente a agente. I protocolli supportati possono essere combinati in un singolo agente.

Identità e endpoint dell'agente

Ogni agente ospitato distribuito in un progetto Foundry ottiene il proprio dedicated Microsoft Entra ID (identità agente) e dedicated endpoint, entrambi creati automaticamente in fase di distribuzione. Non è necessario configurare manualmente le identità gestite o il routing.

L'endpoint è disponibile immediatamente dopo la distribuzione. La pubblicazione non è necessaria per l'accesso a livello di codice:

Risposte: {project_endpoint}/agents/{name}/endpoint/protocols/openai/responses
Chiamate: {project_endpoint}/agents/{name}/endpoint/protocols/invocations
Invocazioni (WebSocket): wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
A2A (versione di anteprima): {project_endpoint}/agents/{name}/endpoint/protocols/a2a

Gli endpoint attivi dipendono dai protocolli dichiarati nella definizione della versione dell'agente. Impostare questa definizione nel servizio azure.ai.agent in azure.yaml quando si utilizza azd, o tramite protocol_versions quando si utilizza SDK.

Sono coinvolte due identità:

Identità	Ambito	Scopo
Microsoft Entra ID (identità dell'agente, per agente)	Creato automaticamente in fase di distribuzione	Identità con cui il contenitore dell'agente esegue l'autenticazione in fase di esecuzione. Usato per la chiamata al modello, l'accesso agli strumenti e i servizi di Azure downstream.
Identità gestita del progetto (a livello di progetto)	Assegnato automaticamente dal sistema nel progetto Foundry	Utilizzato dalla piattaforma per le operazioni di infrastruttura, ad esempio come Lettore del repository del Container Registry nel registro dei contenitori. Non è l'identità di runtime dell'agente.

Per impostazione predefinita, l'identità dell'agente può accedere all'inferenza del modello tramite l'endpoint del progetto e l'archiviazione della sessione. Per le risorse esterne (ad esempio una propria archiviazione di Azure), assegnare manualmente i ruoli RBAC al Microsoft Entra ID dell'agente. Per altre informazioni, vedere Accesso dell'agente oltre le impostazioni predefinite.

Se integrati tramite canali Microsoft 365 (ad esempio Teams), gli agenti ospitati possono operare in due modalità di gestione delle identità a seconda della modalità di chiamata:

Scenari richiamati dall'utente (interattivo): se è presente un token utente, la piattaforma supporta i flussi OAuth 2.0 On-Behalf-Of (OBO). In questo caso, l'agente può invocare i servizi downstream per conto dell'utente utilizzando le autorizzazioni delegate dell'utente, in conformità ai criteri del tenant di Microsoft Entra ID.
Scenari autonomi o in background: se non è disponibile alcun token utente, l'agente si autentica usando il proprio ID Microsoft Entra (identità dell'agente), in genere tramite l'identità gestita, per accedere ai servizi downstream.

In entrambi i casi, l'agente mantiene il proprio Microsoft Entra ID dedicato per l'autenticazione, l'autorizzazione e la verificabilità. Per altre informazioni, vedere Concetti relativi alle applicazioni agent e alle identità degli agenti.

Sessioni e conversazioni

Gli agenti ospitati usano sessioni e conversazioni per gestire lo stato. Il modo in cui funziona dipende dal protocollo.

Sessioni

Un ID sessione identifica una sessione logica con stato persistente, inclusi $HOME e file caricati tramite l'endpoint /files. La piattaforma effettua il provisioning dell'ambiente di calcolo su richiesta e ripristina lo stato persistente su di esso.

Persistenza dello stato: il contenuto di $HOME e /files viene salvato in modo permanente tra turni e periodi di inattività. Quando le risorse di calcolo diventano inattive e vengono ripristinate (in una nuova infrastruttura o esistente), lo stato della sessione viene automaticamente recuperato.
Isolamento: ogni sessione è isolata da altre sessioni.
Ciclo di vita automatico: le sessioni vengono create al primo utilizzo. La piattaforma esegue automaticamente il provisioning e il deprovisioning dell'ambiente di calcolo.
Durata sessione: è possibile configurare il timeout di inattività per ogni versione dell'agente da 5 a 60 minuti, con un valore predefinito di 15 minuti. Se non arriva alcuna richiesta all'interno di tale finestra, la piattaforma esegue il deprovisioning del calcolo e mantiene lo stato della sessione. La piattaforma elimina definitivamente una sessione dopo 30 giorni di inattività.
API di gestione delle sessioni: elencare le sessioni, terminare le sessioni e caricare o scaricare file per sessione.

Conversazioni

Un ID della conversazione è un registro duraturo della cronologia della conversazione (messaggi, chiamate di strumenti e risposte) archiviato in Foundry.

Persistenza: la cronologia delle conversazioni viene archiviata in Foundry e viene mantenuta indipendentemente dallo stato di calcolo.
Accesso tra canali: gli utenti possono accedere alla stessa conversazione dal playground, dall'API, da Teams o da altri canali pubblicati.

Il funzionamento delle sessioni e delle conversazioni per ciascun protocollo

Protocollo di risposta: l'identificativo di conversazione è il concetto principale. La piattaforma gestisce automaticamente la cronologia delle conversazioni e associa un ID sessione a ogni conversazione. La piattaforma restituisce l'ID sessione al client, che può usarlo per caricare i file tramite l'endpoint /files, rendendo tali file disponibili per il calcolo della conversazione.

Protocollo di invocazione: l'ID sessione è il concetto principale. Il client gestisce direttamente l'ID sessione per mantenere lo stato tra le interazioni. Il client può caricare il contenuto tramite l'endpoint /files usando l'ID sessione per renderlo disponibile per la sessione. Non esiste una cronologia di conversazione gestita dalla piattaforma, ovvero lo stato viene gestito nel proprio codice.

Ciclo di vita di calcolo della sessione

Stato	Che succede
Attivo	Il calcolo è in esecuzione. Le richieste vengono instradate ad esso. Sono disponibili i contenuti di $HOME e /files.
Inattivo	Nessuna richiesta per il timeout di inattività configurato. La piattaforma rilascia le risorse di calcolo e mantiene persistente lo stato della sessione ($HOME, `/files`).
Ripreso	Viene nuovamente fatto riferimento allo stesso ID sessione. La piattaforma fornisce nuove risorse di calcolo e ripristina lo stato persistente.

Il calcolo segue la sessione, non la singola richiesta. La piattaforma effettua il provisioning di una sandbox all'avvio di una sessione e la rilascia quando scade il timeout di inattività configurato dopo la richiesta più recente. Quando la sessione riprende, la piattaforma ripristina $HOME e /files, in modo che il codice trovi i file scritti in precedenza. Il diagramma seguente mostra come una richiesta passa attraverso questi stati.

Sicurezza e gestione dei dati

Considerare un agente ospitato come il codice dell'applicazione di produzione.

Importante

Usare sistemi di terze parti a proprio rischio e implementare sempre mitigazioni di intelligenza artificiale responsabili appropriate. L'utente è responsabile della gestione di tutti i dati che potrebbero fluire al di fuori dei limiti geografici e di conformità dell'organizzazione. Scopri di più.

Non inserire segreti nelle immagini del contenitore o nelle variabili di ambiente. Usare identità e connessioni gestite e archiviare i segreti in un archivio segreto gestito. Per indicazioni, vedere Impostare una connessione Key Vault.
Prestare attenzione a strumenti e server non Microsoft. Se l'agente chiama gli strumenti supportati da non servizi Microsoft, alcuni dati potrebbero essere trasmessi a tali servizi. Esaminare i criteri di condivisione, conservazione e posizione dei dati per qualsiasi servizio non Microsoft connesso.

Dettagli della piattaforma

Versionamento

Ogni chiamata per creare una versione produce una versione dell'agente non modificabile. La versione è uno snapshot dell'immagine del contenitore, dell'allocazione delle risorse, delle variabili di ambiente e della configurazione del protocollo. Per aggiornare l'agente, creare e distribuire una nuova versione.

Un endpoint agente serve una versione alla volta e instrada 100% del traffico verso tale versione. La suddivisione del traffico tra versioni non è supportata.

Le variabili di ambiente sono il meccanismo principale per passare la configurazione al contenitore in fase di esecuzione, ad esempio l'endpoint del progetto, il nome della distribuzione del modello e le impostazioni personalizzate. Vengono impostati per versione e non sono modificabili dopo la creazione della versione.

Osservabilità

Gli agenti ospitati offrono un'osservabilità integrata. La piattaforma inserisce automaticamente un stringa di connessione di Application Insights nel contenitore dell'agente tramite variabili di ambiente. Gli agenti che usano le librerie di protocolli generano tracce OpenTelemetry per impostazione predefinita, visualizzate nella risorsa di Application Insights collegata in Ricerca>transazioni o prestazioni.

Per indicazioni sulla configurazione e l'analisi, vedere Abilitare la traccia nel progetto.

Casella degli strumenti in Foundry

Gli agenti ospitati hanno accesso completo agli strumenti gestiti da Foundry, tra cui Interprete del codice, Ricerca Web (con ricerca personalizzata Bing), Azure AI Search, OpenAPI, MCP, A2A, Skills e altro ancora. È possibile connettere questi strumenti tramite un endpoint MCP della casella degli strumenti di cui è stato effettuato il provisioning nel progetto Foundry anziché aggiungerli direttamente alla definizione dell'agente. La casella degli strumenti offre l'autenticazione consolidata tra pass-through di identità OAuth, identità dell'agente, autenticazione basata su chiave e altro ancora. Se si usa Microsoft Agent Framework, connettersi tramite FoundryToolbox in Python o AddFoundryToolboxes in .NET anziché un client MCP generico. Altri runtime si connettono tramite librerie client MCP standard. Per informazioni dettagliate, vedere Gestire la casella degli strumenti basata su finalità in Foundry.

Supporto linguistico

Gli agenti ospitati supportano Python e C#. È possibile usare qualsiasi framework agente: le librerie di protocolli sono indipendenti dal framework. Per esempi che usano Microsoft Agent Framework, LangGraph e codice personalizzato, vedere il repository foundry-samples.

Dimensioni sandbox

Le sandbox dell'agente ospitato supportano le combinazioni di CPU e memoria seguenti:

CPU (unità centrale di elaborazione)	Memory
0,5 vCPU	1 GiB
1 vCPU	2 GiB
2 vCPU	4 GiB

Archiviazione delle sessioni

Ogni sessione ha un oggetto persistente $HOME. La piattaforma preserva il proprio contenuto quando esegue il deprovisioning delle risorse di calcolo allo scadere del timeout di inattività configurato. La piattaforma ripristina il contenuto quando la sessione riprende, in modo che i file scritti in $HOME restino disponibili anche dopo periodi di inattività. La piattaforma scrive i file caricati tramite l'endpoint /files in $HOME, dove condividono la stessa risorsa di archiviazione. Ogni sessione ha un budget totale su disco fino a 20 GiB a 1 vCPU o superiore, che si riduce proporzionalmente per i livelli CPU più piccoli. La piattaforma riserva circa 20% di tale budget per l'uso del sistema e non è visibile o disponibile per l'agente. Il resto viene condiviso tra l'immagine del contenitore, $HOMEe qualsiasi altra posizione scrivibile nel contenitore.

Scalabilità e dimensionamento corretto

Gli agenti ospitati scalano per sessione, non per replica. La piattaforma crea una nuova sandbox isolata da vm per ogni sessione su richiesta e mantiene attivo il calcolo mentre le richieste continuano. Ogni richiesta reimposta il timer di inattività. Quando scade il timeout di inattività configurato dopo la richiesta più recente, la piattaforma disattiva le risorse di calcolo della sandbox e salva lo stato della sessione.

Il timeout di inattività può essere da 5 a 60 minuti e il valore predefinito è 15 minuti. La piattaforma elimina definitivamente una sessione dopo 30 giorni di inattività. Non c’è alcun conteggio delle repliche da configurare né alcun warm pool da dimensionare.

Poiché ogni sessione viene eseguita nel proprio sandbox, i valori di CPU e memoria impostati in una versione dell'agente descrivono una singola sessione, non il footprint aggregato dell'agente. La fatturazione si basa su CPU e memoria consumate nell’insieme di tutte le sessioni attive, quindi il sovradimensionamento moltiplica i costi per il numero di sessioni simultanee.

Per le dimensioni corrette, eseguire un carico di lavoro rappresentativo ed esaminare l'utilizzo delle risorse nella risorsa di Application Insights collegata:

Aprire la risorsa Di App Insights nel portale di Azure e selezionare Investigate>Performance.
Esaminare LA CPU, la memoria disponibile, la frequenza delle richieste e la durata media delle richieste nell'intervallo di tempo testato.

Confrontare i picchi osservati con la CPU e la memoria allocata. Se i picchi sostenuti superano circa il 70% dell’allocazione, aumenta l’allocazione della versione successiva dell’agente; se i picchi rimangono ben al di sotto di tale soglia, riducila per ridurre il costo. Ripetere sempre dopo una modifica, perché ogni nuova versione non è modificabile.

Rete privata

Gli agenti ospitati supportano la distribuzione all'interno delle risorse Foundry isolate dalla rete e possono usare un Rete virtuale di Azure fornito dal cliente per il traffico in uscita. Ciò consente agli agenti nelle distribuzioni foundry isolate dalla rete di raggiungere risorse private, ad esempio database o API interne. Per altre informazioni, vedere Configurare le reti virtuali.

Nota

I progetti Foundry creati dopo il 25 giugno 2026 supportano un Registro Azure Container privato (protetto dalla rete) per l'immagine dell'agente. I progetti creati prima di tale data richiedono che il Registro di sistema rimanga raggiungibile tramite il relativo endpoint pubblico. I progetti esistenti non sono interessati. Per altre informazioni, vedere Limitazioni.

Limiti, prezzi e disponibilità

Tariffe

La fatturazione del runtime di hosting gestito si basa sull'utilizzo delle risorse di CPU e memoria durante le sessioni attive. Per le tariffe correnti, vedere la pagina dei prezzi di Foundry.

Disponibilità dell'area

Gli agenti ospitati sono attualmente disponibili nelle aree seguenti:

Australia orientale
Brasile meridionale
Canada centrale
Canada East
Central US
East US
Stati Uniti orientali 2
Francia centrale
Germania centro-occidentale
Italy North
Giappone orientale
Japan West
Corea centrale
Stati Uniti centro-settentrionali
Norvegia orientale
Polonia centrale
Sudafrica settentrionale
Stati Uniti centro-meridionali
India meridionale
Asia sud-orientale
Spagna centrale
Svezia centrale
Svizzera settentrionale
Svizzera occidentale
UAE North
UK South
UK West
Stati Uniti centro-occidentali
West Europe
Stati Uniti occidentali
Stati Uniti occidentali 3