Gateway dell'API nella gestione delle API di Azure

SI APPLICA A: Tutti i livelli di Gestione API

Questo articolo descrive i ruoli e le funzionalità del componente gateway di Gestione API. Confronta anche i gateway che è possibile distribuire.

Informazioni correlate:

Per una panoramica di scenari, componenti e concetti di Gestione API, vedere Che cos'è Gestione API di Azure?
Per altre informazioni sui livelli di servizio e sulle funzionalità di Gestione API di Azure, vedere Confronto delle funzionalità dei livelli di Gestione API di Azure.

Ruolo del gateway

Il gateway di Gestione API (detto anche piano dati o runtime) è il componente del servizio responsabile del proxy delle richieste API, dell'applicazione dei criteri e della raccolta dei dati di telemetria.

In particolare, il gateway:

Funge da facciata per i servizi back-end accettando chiamate API e instradandole ai back-end appropriati
Verifica le chiavi API e altre credenziali, ad esempio JWT e certificati presentati con richieste
Applica le quote di utilizzo e i limiti di frequenza
Facoltativamente, trasforma le richieste e le risposte come specificato nelle istruzioni dei criteri
Se configurato, memorizza le risposte nella cache per migliorare la latenza di risposta e ridurre al minimo il carico nei servizi back-end
Genera log, metriche e tracce per monitoraggio, creazione di report e risoluzione dei problemi

Note

Tutte le richieste al gateway di Gestione API, incluse quelle rifiutate dalle configurazioni dei criteri, vengono conteggiate per limiti di frequenza, quote e limiti di fatturazione configurati se vengono applicati dal livello di servizio.

Gateway gestiti e ospitati autonomamente in API Management

Gestione API offre gateway gestiti e self-hosted:

Gateway gestito integrato - API Management fornisce un unico gateway gestito integrato e predefinito per ogni istanza di API Management in ogni livello di servizio. Quando viene usato il gateway gestito, tutto il traffico dell'API passa attraverso Azure indipendentemente dalla posizione in cui sono ospitati i back-end che implementano le API. Nel livello Premium, facoltativamente, aggiungere e distribuire la capacità del gateway tra più aree.

Note

A causa delle differenze nell'architettura del servizio sottostante, i gateway forniti nei diversi livelli di servizio Gestione API presentano alcune differenze nelle funzionalità. Per informazioni dettagliate, vedere la sezione Confronto tra funzionalità: gateway gestiti e self-hosted.
Gateway del workspace gestito: in Selezionare i livelli di servizio che supportano le aree di lavoro, è anche possibile associare uno o più gateway del workspace gestiti separati a ogni area di lavoro. Un gateway dell'area di lavoro è una risorsa Azure autonoma con le stesse funzionalità di base del gateway gestito predefinito in ogni istanza di Gestione API.
Gateway ospitato autonomamente - Nei livelli di servizio selezionati, il gateway ospitato autonomamente è una versione facoltativa e containerizzata del gateway gestito predefinito. Livelli diversi supportano un numero diverso di gateway ospitati autonomamente. È utile negli scenari ibridi e multicloud in cui è necessario eseguire i gateway da Azure negli stessi ambienti in cui sono ospitati i servizi back-end delle API. Il gateway self-hosted consente ai clienti con infrastruttura IT ibrida di gestire le API ospitate in locale e tra cloud da un singolo servizio di Gestione API in Azure.
- Il gateway self-hosted è inserito nel pacchetto come contenitore Docker basato su Linux e viene comunemente distribuito in Kubernetes, compreso servizio Azure Kubernetes e Kubernetes abilitato per Azure Arc.
- Ogni gateway self-hosted è associato a una risorsa gateway in un'istanza di Gestione API basata sul cloud da cui riceve gli aggiornamenti della configurazione e comunica lo stato.

Suggerimento

Per gestire backend di IA come le API LLM, API Management offre anche una serie di funzionalità di gateway per l'IA che possono essere utilizzate sia con gateway gestiti sia con gateway self-hosted. Queste funzionalità estendono i gateway API esistenti; il gateway di intelligenza artificiale non è un tipo di gateway separato.

Confronto tra funzionalità: gateway gestiti e self-hosted

Le tabelle seguenti confrontano le funzionalità disponibili nei gateway di Gestione API seguenti:

Classico : il gateway gestito disponibile nei livelli di servizio Developer, Basic, Standard e Premium (in precedenza raggruppati come livelli dedicati)
V2 : il gateway gestito disponibile nei livelli Basic v2, Standard v2 e Premium v2
Consumo : il gateway gestito disponibile nel livello A consumo
Self-hosted : il gateway self-hosted facoltativo disponibile in selezionare i livelli di servizio
Area di lavoro: il gateway gestito disponibile in un'area di lavoro in determinati livelli di servizio

Note

Alcune funzionalità dei gateway gestiti e self-hosted sono supportate solo in determinati livelli di servizio o con determinati ambienti di distribuzione per i gateway self-hosted.
Per visualizzare le funzionalità supportate correnti del gateway self-hosted, assicurarsi di eseguire l'aggiornamento alla versione principale più recente dell'immagine del container del gateway self-hosted.
Vedere anche limitazioni del gateway self-hosted.

Infrastructure

Supporto delle funzionalità	Classic	V2	Consumption	Self-hosted	Workspace
Domini personalizzati	✔️	✔️	✔️	✔️	❌
Cache incorporata	✔️	✔️	❌	❌	✔️
Cache compatibile con Redis esterno	✔️	✔️	✔️	✔️	❌
Inserimento della rete virtuale	Sviluppatore, Premium	Premium v2	❌	✔️^1,2	✔️
Endpoint privati in ingresso	✔️	Standard v2, Premium v2	❌	❌	❌
Integrazione della rete virtuale in uscita	❌	Standard v2, Premium v2	❌	❌	✔️
Zone di disponibilità	Premium	Premium v2	❌	✔️¹	❌
Distribuzione in più aree	Premium	❌	❌	✔️¹	❌
Certificati radice CA per la convalida dei certificati	✔️	✔️⁶	❌	✔️³	❌
Certificati di dominio gestito	✔️	❌	✔️	❌	❌
Impostazioni di TLS	✔️	✔️	✔️	✔️	❌
HTTP/2 (da client a gateway)	✔️⁴	✔️⁴	❌	✔️	❌
HTTP/2 (da gateway a back-end)	✔️⁷	❌	❌	✔️⁵	❌
Rilevamento delle minacce API con Defender per le API	✔️	✔️	❌	❌	❌

¹ Dipende dalla modalità di distribuzione del gateway, ma è responsabilità del cliente.
² La connettività all'endpoint di configurazione del gateway self-hosted v2 richiede la risoluzione DNS del nome host dell'endpoint.
³ certificati radice della CA per il gateway autonomamente ospitato vengono gestiti separatamente per ogni gateway.
⁴ Il protocollo client deve essere abilitato.
⁵ Configurare usando i criteri di inoltro della richiesta.
⁶ Configurare i dettagli del certificato della CA per l'autenticazione del certificato back-end nelle impostazioni back-end.
⁷ In anteprima per le istanze del livello classico create a partire da gennaio 2026. Contattare il supporto tecnico per abilitare le istanze del livello classico esistenti.

API di back-end

Supporto delle funzionalità	Classic	V2	Consumption	Self-hosted	Workspace
Specifica OpenAPI	✔️	✔️	✔️	✔️	✔️
Specifica WSDL	✔️	✔️	✔️	✔️	✔️
Specifica WSDL	✔️	✔️	✔️	✔️	✔️
App per la logica	✔️	✔️	✔️	✔️	✔️
Servizio app	✔️	✔️	✔️	✔️	✔️
App per le funzioni	✔️	✔️	✔️	✔️	✔️
App contenitore	✔️	✔️	✔️	✔️	✔️
Service Fabric	Sviluppatore, Premium	❌	❌	❌	❌
GraphQL pass-through	✔️	✔️	✔️	✔️	✔️
GraphQL sintetico	✔️	✔️	✔️¹	✔️¹	❌
WebSocket pass-through	✔️	✔️	❌	✔️	✔️
gRPC pass-through	✔️¹	❌	❌	✔️	❌
OData	✔️	✔️	✔️	✔️	✔️
Microsoft Foundry LLMs e modelli di fornitori diversi da Microsoft	✔️	✔️	✔️	✔️	✔️
Server MCP pass-through	✔️	✔️	❌	✔️	❌
Esportare l'API REST come server MCP	✔️	✔️	❌	✔️	❌
Agente A2A	✔️	✔️	❌	❌	❌
Interruttore in back-end	✔️	✔️	❌	✔️	✔️
Pool di back-end con bilanciamento del carico	✔️	✔️	✔️	✔️	✔️

¹ In anteprima per le istanze di livello classico create a partire da gennaio 2026. Contattare il supporto tecnico per abilitare le istanze del livello classico esistenti.

Policies

I gateway gestiti e auto-ospitati supportano tutti i criteri disponibili all'interno delle definizioni dei criteri con le eccezioni seguenti. Per informazioni dettagliate su ogni criterio, vedere le informazioni di riferimento sui criteri.

Supporto delle funzionalità	Classic	V2	Consumption	Self-hosted¹	Workspace
Integrazione Dapr	❌	❌	❌	✔️	❌
Integrazione del bus di servizio (anteprima)	✔️	✔️	✔️	❌	❌
Risolutori GraphQL e Validazione GraphQL	✔️	✔️	✔️	❌	❌
Ottieni contesto di autorizzazione	✔️	✔️	✔️	❌	❌
Eseguire l'autenticazione con un'identità gestita	✔️	✔️	✔️	✔️	❌
Memorizzazione nella cache di semantica LLM	✔️	✔️	✔️	❌	❌
Limite di velocità e quota	✔️	✔️	✔️²	✔️³	✔️

¹ I criteri configurati che non sono supportati dal gateway self-hosted vengono ignorati durante l'esecuzione dei criteri.
² Il limite di velocità per chiave, quota per chiave e criteri di limite di token LLM non sono disponibili nel livello a consumo.
³ I conteggi dei limiti di frequenza in un gateway self-hosted possono essere configurati per la sincronizzazione locale (tra le istanze del gateway tra i nodi del cluster), ad esempio tramite la distribuzione del grafico Helm per Kubernetes o usando i modelli di distribuzione del portale di Azure. Tuttavia, i conteggi dei limiti di frequenza non vengono sincronizzati con altre risorse del gateway configurate nell'istanza di Gestione API, incluso il gateway gestito nel cloud. Ulteriori informazioni

Monitoraggio API

Per informazioni dettagliate sulle opzioni di monitoraggio, vedere Osservabilità in Gestione API di Azure.

Supporto delle funzionalità	Classic	V2	Consumption	Self-hosted	Workspace
Analisi di API	✔️	✔️¹	❌	❌	❌
Application Insights	✔️	✔️	✔️	✔️²	✔️
Registrazione tramite Hub eventi	✔️	✔️	✔️	✔️	✔️
Metriche in Monitoraggio di Azure	✔️	✔️	✔️	✔️	❌
Agente di raccolta OpenTelemetry	❌	❌	❌	✔️	❌
Log di richieste in Monitoraggio di Azure e Log Analytics	✔️	✔️	❌	❌ ³	❌
Metriche e log locali	❌	❌	❌	✔️	❌
Traccia delle richieste	✔️	✔️	✔️	✔️	✔️

¹ I livelli v2 supportano l'analisi basata su Monitoraggio di Azure.
² Il gateway usa il buffer di memoria predefinito di applicazione Azure Insights e non fornisce garanzie di recapito.
³ Il gateway self-hosted attualmente non invia i log delle risorse (log di diagnostica) a Monitoraggio di Azure. Facoltativamente, inviare metriche a Monitoraggio di Azure o configurare e rendere persistenti i log in locale in cui viene distribuito il gateway self-hosted.

Autenticazione e autorizzazione

I gateway gestiti e self-hosted supportano tutte le opzioni di autenticazione e autorizzazione API disponibili con le eccezioni seguenti.

Supporto delle funzionalità	Classic	V2	Consumption	Self-hosted	Workspace
Gestione credenziali	✔️	✔️	✔️	❌	❌

Velocità effettiva e ridimensionamento del gateway

Important

La velocità effettiva dipende da molti fattori, tra cui il numero e la frequenza delle connessioni client simultanee, il tipo e il numero di criteri configurati, dimensioni del payload, prestazioni dell'API back-end e altri fattori. La velocità effettiva del gateway self-hosted dipende anche dalla capacità di calcolo (CPU e memoria) dell'host in cui viene eseguita. Per determinare in modo accurato la velocità effettiva prevista, eseguire test di carico del gateway usando le condizioni di produzione previste.

Gateway gestito

Per la velocità effettiva massima stimata del gateway nei livelli di servizio di Gestione API, vedere Prezzi di Gestione API.

Important

Usate le cifre relative al throughput solo a scopo informativo. Non basarsi su di essi per la pianificazione della capacità e del budget. Per i dettagli, vedere Prezzi di Gestione API.

Livelli classici
- Ridimensionare la capacità del gateway aggiungendo e rimuovendo le unità di scalabilità o aggiornando il livello di servizio. (Il ridimensionamento non è disponibile nel livello Sviluppatore).
- Nei livelli Basic, Standard e Premium, configurare facoltativamente Monitoraggio di Azure autoscale.
- Nel livello Premium aggiungere e distribuire facoltativamente la capacità del gateway in più aree.
Livelli v2
- Ridimensionare la capacità del gateway aggiungendo e rimuovendo le unità di scalabilità o aggiornando il livello di servizio.
- Configurare facoltativamente la scalabilità automatica di Monitoraggio di Azure.
Livello di consumo
- Le istanze di Gestione API nel livello A consumo vengono ridimensionate automaticamente in base al traffico.

Gateway autonomo

In ambienti come Kubernetesaggiungere più repliche gateway per gestire l'utilizzo previsto.
Facoltativamente, configurare la scalabilità automatica per soddisfare le richieste di traffico.

Gateway dell'area di lavoro

Ridimensionare la capacità aggiungendo e rimuovendo le unità di scalabilità nel gateway dell'area di lavoro.

Limiti di runtime del gateway

La tabella seguente elenca i limiti che si applicano al gateway di Gestione API quando gestisce le richieste e le risposte api.

Limite di runtime	Classic	V2	Consumption
Connessioni back-end simultanee¹ per autorità HTTP	2.048² per unità	2,048	Unlimited
Dimensioni della risposta memorizzate nella cache	2 MiB	2 MiB	2 MiB
Dimensioni del documento dei criteri	512 KiB	512 KiB	16 KiB
Dimensioni payload richiesta	Unlimited	1 GiB	1 GiB
Dimensioni del payload memorizzate nel buffer	500 MiB	2 MiB	2 MiB
Dimensioni del payload di richiesta/risposta nei log di diagnostica	8.192 byte	8.192 byte	8.192 byte
Dimensioni URL richiesta³	Unlimited	16.384 byte	16.384 byte
Lunghezza del segmento di percorso URL	1.024 caratteri	1.024 caratteri	1.024 caratteri
Lunghezza del valore nominato	4.096 caratteri	4.096 caratteri	4.096 caratteri
Dimensioni del corpo della richiesta o della risposta nel validate-content policy	100 KiB	100 KiB	100 KiB
Dimensioni dello schema API usato dai criteri di convalida	4 MB	4 MB	4 MB
Durata totale richiesta	Unlimited	30 secondi	30 secondi
Connessioni WebSocket attive per unità⁴	5,000	5,000	N/A

¹ Le connessioni vengono raggruppate e riutilizzate a meno che non vengano chiuse in modo esplicito dal back-end.
² Il limite è 1.024 nel livello Developer.
³ Comprende una stringa di query lunga fino a 2048 byte.
⁴ Fino a un massimo di 60.000 connessioni per ogni istanza del servizio.

Endpoint di controllo dell'integrità del gateway

In tutti i livelli, ad eccezione del livello a consumo, Gestione API di Azure fornisce un endpoint di controllo dell'integrità del gateway predefinito nel percorso /status-0123456789abcdef. Raggiungere questo endpoint per verificare che il gateway API sia disponibile e funzioni correttamente. Non testa le API back-end, ma solo il gateway stesso.

Una richiesta all'endpoint restituisce una 200 OK risposta HTTP quando il gateway è integro. Gli errori indicano problemi di rete o gateway.

Azure usa internamente questo endpoint per il monitoraggio continuo del contratto di servizio e la convalida dell'integrità del gateway.
I clienti possono integrare le richieste a questo endpoint nei propri strumenti di monitoraggio e probe.
L'endpoint è disponibile per i gateway gestiti (inclusi i gateway a livello di area nelle distribuzioni in più aree), i gateway self-hosted e i gateway dell'area di lavoro.