Condividi tramite

Funzionalità di rete in un ambiente di App contenitore di Azure

  • Articolo

Le App contenitore di Azure vengono eseguite nel contesto di un ambiente, con la propria rete virtuale.

Per impostazione predefinita, l'ambiente dell'app contenitore viene creato con una rete virtuale generata automaticamente. Per un controllo granulare sulla rete, è possibile fornire una rete virtuale esistente quando si crea un ambiente. Dopo aver creato un ambiente con una rete virtuale generata o esistente, il tipo di rete non può essere modificato.

Le reti virtuali generate assumono le caratteristiche seguenti.

Sono:

  • inaccessibili all'utente perché vengono create nel tenant di Microsoft
  • accessibili pubblicamente tramite Internet
  • solo in grado di raggiungere gli endpoint accessibili da Internet

Inoltre, supportano solo un sottoinsieme limitato di funzionalità di rete, ad esempio restrizioni IP in ingresso e controlli di ingresso a livello di app contenitore.

Usare una rete virtuale esistente se sono necessarie altre funzionalità di rete di Azure, ad esempio:

  • Integrazione con il gateway applicazione
  • Gruppi di sicurezza di rete
  • Comunicazione con le risorse dietro endpoint privati nella rete virtuale

Le funzionalità di rete virtuale disponibili dipendono dalla selezione dell'ambiente.

Selezione ambiente

Per App contenitore sono disponibili due tipi di ambiente diversi, che condividono molte delle stesse caratteristiche di rete con alcune differenze chiave.

Tipo di ambiente Tipi di piano supportati Descrizione
Profili del carico di lavoro A consumo, Dedicato Supporta route definite dall'utente (UDR), uscita tramite gateway NAT e creazione di endpoint privati nell'ambiente dell'app contenitore. La dimensione minima richiesta della subnet è /27.
Solo Consumo Consumo Non supporta route definite dall'utente( UDR), il traffico in uscita tramite gateway NAT, il peering tramite un gateway remoto o altro traffico in uscita personalizzato. La dimensione minima richiesta della subnet è /23.

IP virtuale

A seconda della configurazione IP virtuale, è possibile controllare se l'ambiente dell'app contenitore consente l'ingresso pubblico o l'ingresso solo dall'interno della rete virtuale a livello di ambiente. Questa configurazione non può essere modificata dopo la creazione dell'ambiente.

Livello di accessibilità Descrizione
Esterno Consente all'app contenitore di accettare richieste pubbliche. Gli ambienti esterni vengono distribuiti con un indirizzo IP virtuale in un indirizzo IP esterno accessibile da Internet.
Interno Gli ambienti interni non hanno endpoint pubblici e vengono distribuiti con un indirizzo IP virtuale (VIP) mappato a un indirizzo IP interno. L'endpoint interno è un servizio di bilanciamento del carico interno di Azure e gli indirizzi IP vengono emessi dall'elenco di indirizzi IP privati della rete virtuale personalizzata.

Configurazione della rete virtuale personalizzata

Quando si crea una rete virtuale personalizzata, tenere presenti le situazioni seguenti:

  • Se si vuole che l'app contenitore limiti tutti gli accessi esterni, creare un ambiente app contenitore interno.

  • Se si usa la propria rete virtuale, è necessario fornire una subnet dedicata esclusivamente all'ambiente app contenitore distribuito. Questa subnet non è disponibile per altri servizi.

  • Gli indirizzi di rete vengono assegnati da un intervallo di subnet definito durante la creazione dell'ambiente.

    • È possibile definire l'intervallo di subnet usato dall'ambiente app contenitore.

    • È possibile limitare le richieste in ingresso nell'ambiente esclusivamente alla rete virtuale distribuendo l'ambiente come interno.

Nota

Quando si specifica una rete virtuale personalizzata, vengono create risorse gestite aggiuntive. Queste risorse comportano costi in base alle tariffe associate.

Quando si inizia a progettare la rete intorno all'app contenitore, vedere Pianificare le reti virtuali.

Diagramma del modo in cui gli ambienti di App contenitore di Azure usano una rete virtuale esistente oppure è possibile fornire la propria.

Nota

Lo spostamento di reti virtuali tra gruppi di risorse o sottoscrizioni diversi non è consentito se la rete virtuale è usata da un ambiente app contenitore.

Comportamento del proxy perimetrale HTTP

App contenitore di Azure usa il proxy Envoy come proxy HTTP perimetrale. Transport Layer Security (TLS) viene terminato sul perimetro e le richieste vengono instradate in base alle regole di suddivisione del traffico e il traffico viene instradato all'applicazione corretta.

Le applicazioni HTTP si ridimensionano in base al numero di richieste e connessioni HTTP. Envoy instrada il traffico interno all'interno dei cluster.

Le connessioni downstream supportano HTTP1.1 e HTTP2 ed Envoy rileva e aggiorna automaticamente le connessioni se la connessione client richiede un aggiornamento.

Le connessioni upstream vengono definite impostando la proprietà transport sull'oggetto in ingresso.

Configurazione in ingresso

Nella sezione ingresso è possibile configurare le impostazioni seguenti:

  • Livello di accessibilità: è possibile impostare l'app contenitore come accessibile esternamente o internamente nell'ambiente. Una variabile di ambiente CONTAINER_APP_ENV_DNS_SUFFIX viene usata per risolvere automaticamente il suffisso del nome di dominio completo (FQDN) per l'ambiente. Per le comunicazioni tra app contenitore all'interno dello stesso ambiente, è anche possibile usare il nome dell'app. Per altre informazioni su come accedere alle app, vedere Ingresso in App contenitore di Azure.

  • Regole di suddivisione del traffico: è possibile definire regole di suddivisione del traffico tra revisioni diverse dell'applicazione. Per altre informazioni, vedere Suddivisione del traffico.

Per altre informazioni sui diversi scenari di rete, vedere Ingresso in App contenitore di Azure.

Dipendenze per il portale

Per ogni app in App contenitore di Azure esistono due URL.

Il runtime di App contenitore genera inizialmente un nome di dominio completo (FQDN) usato per accedere all'app. Vedere URL applicazione nella finestra Panoramica dell'app contenitore nel portale di Azure per il nome di dominio completo dell'app contenitore.

Viene generato automaticamente anche un secondo URL. Questo percorso concede l'accesso al servizio di streaming dei log e alla console. Se necessario, potrebbe essere necessario aggiungere https://azurecontainerapps.dev/ all'elenco elementi consentiti del firewall o del proxy.

Porte e indirizzi IP

Le porte seguenti vengono esposte per le connessioni in ingresso.

Protocollo Porte
HTTP/HTTPS 80, 443

Gli indirizzi IP sono suddivisi nei tipi seguenti:

Tipo Descrizione
Indirizzo IP pubblico in ingresso Usato per il traffico dell'applicazione in una distribuzione esterna e per il traffico di gestione sia nelle distribuzioni interne che esterne.
Indirizzo IP pubblico in uscita Usato come IP di origine per le connessioni in uscita che lasciano la rete virtuale. Queste connessioni non vengono instradate verso un VPN. Gli indirizzi IP in uscita possono cambiare nel tempo. L'uso di un gateway NAT o di un altro proxy per il traffico in uscita da un ambiente app contenitore è supportato solo in un ambiente di profili di carico di lavoro.
Indirizzo IP del servizio di bilanciamento del carico interno Questo indirizzo esiste solo in un ambiente interno.

Subnet

L'integrazione della rete virtuale dipende da una subnet dedicata. La modalità di allocazione degli indirizzi IP in una subnet e le dimensioni delle subnet supportate dipendono dal piano in uso in App contenitore di Azure.

Selezionare attentamente le dimensioni delle subnet. Le dimensioni delle subnet non possono essere modificate dopo aver creato un ambiente app contenitore.

I diversi tipi di ambiente hanno requisiti diversi per le subnet:

  • /27 sono le dimensioni minime della subnet necessarie per l'integrazione della rete virtuale.

  • La subnet deve essere delegata a Microsoft.App/environments.

  • Quando si usa un ambiente esterno con ingresso esterno, il traffico in ingresso viene instradato attraverso l'IP pubblico dell'infrastruttura anziché attraverso la subnet.

  • App contenitore riserva automaticamente 12 indirizzi IP per l'integrazione con la subnet. Il numero di indirizzi IP necessari per l'integrazione dell'infrastruttura non varia in base alle esigenze di scalabilità dell'ambiente. Gli indirizzi IP aggiuntivi vengono allocati in base alle regole seguenti, a seconda del tipo di profilo del carico di lavoro in uso. Vengono allocati più indirizzi IP a seconda del profilo del carico di lavoro dell'ambiente:

  • Quando si apporta una modifica a una revisione in modalità di revisione singola, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo per supportare distribuzioni senza tempi di inattività. Ciò influisce sulle repliche o sui nodi supportati reali e disponibili per determinate dimensioni della subnet. La tabella seguente illustra sia gli indirizzi disponibili massimi per ogni blocco CIDR che l'effetto sul ridimensionamento orizzontale.

    Dimensioni della subnet Indirizzi IP disponibili1 Numero massimo di nodi (profilo di carico di lavoro dedicato)2 Numero massimo di repliche (profilo carico di lavoro a consumo)2
    23/ 500 250 2500
    /24 244 122 1.220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 Gli indirizzi IP disponibili sono le dimensioni della subnet meno i 12 indirizzi IP richiesti per l'infrastruttura di App contenitore di Azure.
    2 Questo valore tiene conto delle app in modalità di revisione singola.

Restrizioni relative all'intervallo di indirizzi della subnet

Gli intervalli di indirizzi della subnet non possono sovrapporsi agli intervalli seguenti riservati da Servizi Azure Kubernetes:

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

Inoltre, un ambiente dei profili di carico di lavoro riserva gli indirizzi seguenti:

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

Configurazione della subnet con l'interfaccia della riga di comando

Quando viene creato un ambiente app contenitore, è possibile specificare gli ID risorsa per una singola subnet.

Se si usa l'interfaccia della riga di comando, il parametro per definire l'ID risorsa della subnet è infrastructure-subnet-resource-id. La subnet ospita i componenti dell'infrastruttura e i contenitori di app utente.

Se si usa l'interfaccia della riga di comando di Azure con un ambiente solo a consumo e viene definito l'intervallo di platformReservedCidr, la subnet non deve sovrapporsi all'intervallo IP definito in platformReservedCidr.

Route

Route definite dall'utente

Le route definite dall'utente (UDR) e l'uscita controllata tramite il gateway NAT sono supportate nell'ambiente dei profili di carico di lavoro. Nell'ambiente Solo consumo tali funzionalità non sono supportate.

Nota

Quando si usa una route definita dall'utente con Firewall di Azure in App contenitore di Azure, è necessario aggiungere determinati tag di servizio e FQDN all'elenco elementi consentiti per il firewall. Per altre informazioni, vedere Configurazione della route definita dall'utente con Firewall di Azure.

  • È possibile usare la route definita dall'utente con gli ambienti dei profili di carico di lavoro per limitare il traffico in uscita dall'app contenitore tramite Firewall di Azure o altre appliance di rete.

  • La configurazione della route definita dall'utente viene eseguita all'esterno dell'ambito dell'ambiente App contenitore.

Diagramma della modalità di implementazione della route definita dall'utente per App contenitore.

Azure crea una tabella di route predefinita per le reti virtuali al momento della creazione. Implementando una tabella di route definita dall'utente, è possibile controllare il modo in cui il traffico viene instradato all'interno della rete virtuale. Ad esempio, è possibile creare una route definita dall'utente che instrada tutto il traffico al firewall.

Configurazione della route definita dall'utente con Firewall di Azure

Le route definite dall'utente sono supportate solo in un ambiente di profili di carico di lavoro. Le regole seguenti per l'applicazione e la rete devono essere aggiunte all'elenco elementi consentiti per il firewall a seconda delle risorse in uso.

Nota

Per una guida su come configurare la route definita dall'utente con App contenitore per limitare il traffico in uscita con Firewall di Azure, vedere le procedure per App contenitore e Firewall di Azure.

Regole di applicazione

Le regole dell'applicazione consentono o negano il traffico in base al livello dell'applicazione. Le regole dell'applicazione del firewall in uscita seguenti sono necessarie in base allo scenario.

Scenari FQDN Descrizione
Tutti gli scenari mcr.microsoft.com, *.data.mcr.microsoft.com Questi nomi di dominio completi per Registro Container Microsoft vengono usati da App contenitore di Azure e queste regole dell'applicazione o le regole di rete per Registro Container Microsoft devono essere aggiunte all'elenco elementi consenti quando si usa App contenitore di Azure con Firewall di Azure.
Registro Azure Container Indirizzo-ACR, *.blob.core.windows.net, login.microsoft.com Questi FQDN sono necessari quando si usa App contenitore di Azure con Registro Azure Container e Firewall di Azure.
Azure Key Vault Indirizzo-Azure-Key-Vault, login.microsoft.com Questi FQDN sono necessari oltre al tag di servizio richiesto per la regola di rete per Azure Key Vault.
Identità gestita *.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com*.login.microsoft.com Questi FQDN sono necessari quando si usa l'identità gestita con Firewall di Azure in App contenitore di Azure.
Registro di Docker Hub hub.docker.com, registry-1.docker.io, production.cloudflare.docker.com Se si usa il registro di Docker Hub e si vuole accedervi tramite il firewall, è necessario aggiungere questi FQDN al firewall.
Regole di rete

Le regole di rete consentono o negano il traffico in base al livello di rete e trasporto. Le regole di rete del firewall in uscita seguenti sono necessarie in base allo scenario.

Scenari Tag del servizio Descrizione
Tutti gli scenari MicrosoftContainerRegistry, AzureFrontDoorFirstParty Questi tag di servizio per Registro Container Microsoft vengono usati da App contenitore di Azure e queste regole di rete o le regole dell'applicazione per Registro Container Microsoft devono essere aggiunte all'elenco elementi consenti quando si usa App contenitore di Azure con Firewall di Azure.
Registro Azure Container AzureContainerRegistry, AzureActiveDirectory Quando si usa Registro Azure Container con App contenitore di Azure, è necessario configurare queste regole dell'applicazione usate da Registro Azure Container.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Questi tag di servizio sono necessari oltre all'FQDN per la regola dell'applicazione per Azure Key Vault.
Identità gestita AzureActiveDirectory Quando si usa l'identità gestita con App contenitore di Azure, è necessario configurare queste regole dell'applicazione usate dall'identità gestita.

Nota

Per le risorse di Azure usate con Firewall di Azure non elencate in questo articolo, vedere la documentazione dei tag di servizio.

Integrazione del gateway NAT

È possibile usare il gateway NAT per semplificare la connettività in uscita per il traffico Internet in uscita nella rete virtuale in un ambiente dei profili di carico di lavoro.

Quando si configura un gateway NAT nella subnet, il gateway NAT fornisce un indirizzo IP pubblico statico per l'ambiente. Tutto il traffico in uscita dall'app contenitore viene instradato tramite l'indirizzo IP pubblico statico del gateway NAT.

Accesso alla rete pubblica (anteprima)

L'impostazione di accesso alla rete pubblica determina se l'ambiente delle app contenitore è accessibile da Internet pubblico. L'eventuale modifica di questa impostazione dopo la creazione dell'ambiente dipende dalla configurazione IP virtuale dell'ambiente. La tabella seguente mostra i valori validi per l'accesso alla rete pubblica, a seconda della configurazione IP virtuale dell'ambiente.

IP virtuale Accesso alla rete pubblica supportato Descrizione
Esterno Enabled, Disabled L'ambiente delle app contenitore è stato creato con un endpoint accessibile da Internet. L'impostazione di accesso alla rete pubblica determina se il traffico viene accettato tramite l'endpoint pubblico o solo tramite endpoint privati e l'impostazione di accesso alla rete pubblica può essere modificata dopo la creazione dell'ambiente.
Internal Disabled L'ambiente delle app contenitore è stato creato senza un endpoint accessibile da Internet. L'impostazione di accesso alla rete pubblica non può essere modificata per accettare il traffico da Internet.

Per creare endpoint privati nell'ambiente dell'app Azure Container, l'accesso alla rete pubblica deve essere impostato su Disabled.

I criteri di rete di Azure sono supportati con il flag di accesso alla rete pubblica.

Endpoint privato (anteprima)

Nota

Questa funzionalità è supportata per tutte le aree pubbliche. Le aree governative e cinesi non sono supportate.

L'endpoint privato di Azure consente ai client che si trovano nella rete privata di connettersi in modo sicuro all'ambiente di App Azure Container tramite collegamento privato di Azure. Una connessione di collegamento privato elimina l'esposizione alla rete Internet pubblica. Gli endpoint privati usano un indirizzo IP privato nello spazio indirizzi della rete virtuale di Azure.

Questa funzionalità è supportata sia per i piani a consumo che per i piani dedicati negli ambienti del profilo del carico di lavoro.

Esercitazioni

Considerazioni

  • Gli endpoint privati in App Azure Container supportano solo il traffico HTTP in ingresso. Il traffico TCP non è supportato.
  • Per usare un endpoint privato con un dominio personalizzato e un dominio Apex come tipo di record Hostname, è necessario configurare una zona DNS privata con lo stesso nome del DNS pubblico. Nel set di record configurare l'indirizzo IP privato dell'endpoint privato anziché l'indirizzo IP dell'ambiente dell'app contenitore. Quando si configura il dominio personalizzato con CNAME, l'installazione rimane invariata. Per altre informazioni, vedere Configurare un dominio personalizzato con un certificato esistente o Configurare domini personalizzati con cretificate gestito gratuito.
  • La rete virtuale dell'endpoint privato può essere separata dalla rete virtuale integrata con l'app contenitore.
  • È possibile aggiungere un endpoint privato agli ambienti del profilo del carico di lavoro nuovi ed esistenti.

Per connettersi alle app contenitore tramite un endpoint privato, è necessario configurare una zona DNS privata.

Service sottorisorsa Nome zona DNS privato
App Azure Container (Microsoft.App/ManagedEnvironments) managedEnvironment privatelink. {regionName}.azurecontainerapps.io

Sicurezza dell'ambiente

Nota

Per controllare il traffico in ingresso, è anche possibile usare endpoint privati con una connessione privata a Frontdoor di Azure al posto di gateway applicazione. Questa funzionalità si trova in anteprima.

Diagramma di come bloccare completamente la rete per App contenitore.

È possibile proteggere completamente l'ambiente dei profili del carico di lavoro per il traffico di rete in ingresso e in uscita eseguendo le azioni seguenti:

Crittografia peer-to-peer nell'ambiente di App contenitore di Azure

App contenitore di Azure supporta la crittografia TLS peer-to-peer all'interno dell'ambiente. L'abilitazione di questa funzionalità crittografa tutto il traffico di rete all'interno dell'ambiente con un certificato privato valido nell'ambito dell'ambiente app contenitore di Azure. Questi certificati vengono gestiti automaticamente da App contenitore di Azure.

Nota

Per impostazione predefinita, la crittografia peer-to-peer è disabilitata. L'abilitazione della crittografia peer-to-peer per le applicazioni può aumentare la latenza di risposta e ridurre la velocità effettiva massima in scenari a carico elevato.

L'esempio seguente mostra un ambiente con la crittografia peer-to-peer abilitata. Diagramma del modo in cui il traffico viene crittografato/decrittografato con la crittografia peer-to-peer abilitata.

1 Il traffico TLS in ingresso viene terminato in corrispondenza del proxy di ingresso sul perimetro dell'ambiente.

2 Al traffico da e verso il proxy di ingresso all'interno dell'ambiente viene applicata la crittografia TLS con un certificato privato e decrittografato dal ricevente.

3 Le chiamate effettuate dall'app A all'FQDN dell'app B vengono prima inviate al proxy di ingresso perimetrale e sono crittografate con TLS.

4 Le chiamate effettuate dall'app A all'app B usando il nome dell'app B vengono inviate direttamente all'app B e sono crittografate con TLS.

Le applicazioni all'interno di un ambiente app contenitore vengono autenticate automaticamente. Tuttavia, il runtime di App contenitore non supporta l'autorizzazione per il controllo di accesso tra le applicazioni usando la crittografia peer-to-peer predefinita.

Quando le app comunicano con un client esterno all'ambiente, è supportata l'autenticazione bidirezionale con mTLS. Per altre informazioni, vedere Configurare i certificati client.

È possibile abilitare la crittografia peer-to-peer usando i comandi seguenti.

In fase di creazione:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

Per un'app contenitore esistente:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

DNS

  • DNS personalizzato: se la rete virtuale usa un server DNS personalizzato anziché il server DNS predefinito fornito da Azure, configurare il server DNS per inoltrare le query DNS non risolte a 168.63.129.16. Resolver ricorsivi di Azure usa questo indirizzo IP per risolvere le richieste. Quando si configura il gruppo di sicurezza di rete o il firewall, non bloccare l'indirizzo 168.63.129.16. In caso contrario, l'ambiente app contenitore non funzionerà correttamente.

  • Ingresso dell'ambito della rete virtuale: se si prevede di usare l'ambito della rete virtuale ingresso in un ambiente interno, configurare i domini in uno dei modi seguenti:

    1. Domini non personalizzati: se non si prevede di usare un dominio personalizzato, creare una zona DNS privata che risolve il dominio predefinito dell'ambiente app contenitore nell'indirizzo IP statico dell'ambiente app contenitore. È possibile usare DNS privato di Azure o il proprio server DNS. Se si usa DNS privato di Azure, creare una zona DNS privata con lo stesso nome del dominio predefinito dell'ambiente app contenitore (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io), con un record A. Il record A contiene il nome *<DNS Suffix> e l'indirizzo IP statico dell'ambiente app contenitore.

    2. Domini personalizzati: se si prevede di usare domini personalizzati e si usa un ambiente app contenitore esterno, usare un dominio risolvibile pubblicamente per aggiungere un dominio personalizzato e un certificato all'app contenitore. Se si usa un ambiente app contenitore interno, non è disponibile alcuna convalida per l'associazione DNS, perché è possibile accedere al cluster solo dall'interno della rete virtuale. Creare inoltre una zona DNS privato che risolve il dominio apex nell'indirizzo IP statico dell'ambiente App contenitore. È possibile usare DNS privato di Azure o il proprio server DNS. Se si usa DNS privato di Azure, creare una zona DNS privata con lo stesso nome del dominio apex, con un record A che punta all'indirizzo IP statico dell'ambiente app contenitore.

L'indirizzo IP statico dell'ambiente app contenitore è disponibile nel portale di Azure in Suffisso DNS personalizzato della pagina dell'app contenitore o tramite il comando az containerapp env list dell'interfaccia della riga di comando di Azure.

Risorse gestite

Quando si distribuisce un ambiente interno o esterno nella propria rete, viene creato un nuovo gruppo di risorse nella sottoscrizione di Azure in cui è ospitato l'ambiente. Questo gruppo di risorse contiene i componenti dell'infrastruttura gestiti dalla piattaforma App contenitore di Azure. Non modificare i servizi in questo gruppo o il gruppo di risorse stesso.

Ambienti dei profili di carico di lavoro

Il nome del gruppo di risorse creato nella sottoscrizione di Azure in cui è ospitato l'ambiente è preceduto da ME_ per impostazione predefinita e il nome del gruppo di risorse può essere personalizzato durante la creazione dell'ambiente app contenitore.

Per gli ambienti esterni, il gruppo di risorse contiene un indirizzo IP pubblico usato in modo specifico per la connettività in ingresso all'ambiente esterno e un servizio di bilanciamento del carico. Per gli ambienti interni, il gruppo di risorse contiene solo un Load Balancer.

Oltre alla fatturazione per App contenitore di Azure standard, vengono addebitati i costi seguenti:

Ambiente solo a consumo

Il nome del gruppo di risorse creato nella sottoscrizione di Azure in cui è ospitato l'ambiente è preceduto da MC_ per impostazione predefinita e il nome del gruppo di risorse non può essere personalizzato quando si crea un'app contenitore. Il gruppo di risorse contiene indirizzi IP pubblici usati in modo specifico per la connettività in uscita dall'ambiente e un servizio di bilanciamento del carico.

Oltre alla fatturazione per App contenitore di Azure standard, vengono addebitati i costi seguenti:

Passaggi successivi