Netwerken in azure Container Apps-omgeving

Azure Container Apps worden uitgevoerd in de context van een omgeving, met een eigen virtueel netwerk (VNet).

Uw Container App-omgeving wordt standaard gemaakt met een VNET dat automatisch voor u wordt gegenereerd. Voor gedetailleerde controle over uw netwerk kunt u een bestaand VNET opgeven wanneer u een omgeving maakt. Zodra u een omgeving met een gegenereerd of bestaand VNET hebt gemaakt, kan het netwerktype niet worden gewijzigd.

Gegenereerde VNets hebben de volgende kenmerken.

Dit zijn:

• niet toegankelijk voor u terwijl ze worden gemaakt in de tenant van Microsoft
• openbaar toegankelijk via internet
• alleen toegankelijke eindpunten voor internet kunnen bereiken

Verder bieden ze alleen ondersteuning voor een beperkte subset van netwerkmogelijkheden, zoals toegangsbeheer voor inkomend IP-adres en toegangsbeheer op app-niveau op containerniveau.

Gebruik een bestaand VNet als u meer Azure-netwerkfuncties nodig hebt, zoals:

• Integratie met Application Gateway
• Netwerkbeveiligingsgroepen
• Communicatie met resources achter privé-eindpunten in uw virtuele netwerk

De beschikbare VNet-functies zijn afhankelijk van uw omgevingsselectie.

Omgevingsselectie

Container Apps heeft twee verschillende omgevingstypen, die veel van dezelfde netwerkkenmerken delen met enkele belangrijke verschillen.

Type omgeving	Beschrijving	Ondersteunde abonnementstypen
Workloadprofielen	Ondersteunt door de gebruiker gedefinieerde routes (UDR) en uitgaand verkeer via NAT Gateway. De minimale vereiste subnetgrootte is /27.	Verbruik, toegewezen
Alleen verbruik	Biedt geen ondersteuning voor door de gebruiker gedefinieerde routes (UDR), uitgaand verkeer via NAT Gateway, peering via een externe gateway of andere aangepaste uitgaande verbindingen. De minimale vereiste subnetgrootte is /23.	Verbruik

Toegankelijkheidsniveaus

U kunt configureren of uw container-app alleen openbare toegangsbeheerobjecten of toegangsbeheerobjecten toestaat vanuit uw VNet op omgevingsniveau.

Toegankelijkheidsniveau	Beschrijving
Extern	Hiermee kan uw container-app openbare aanvragen accepteren. Externe omgevingen worden geïmplementeerd met een virtueel IP-adres op een extern openbaar IP-adres.
Intern	Interne omgevingen hebben geen openbare eindpunten en worden geïmplementeerd met een virtueel IP-adres (VIP) dat is toegewezen aan een intern IP-adres. Het interne eindpunt is een interne Load Balancer (ILB) van Azure en IP-adressen worden uitgegeven vanuit de aangepaste VNet-lijst met privé-IP-adressen.

Aangepaste VNet-configuratie

Houd rekening met de volgende situaties wanneer u een aangepast VNet maakt:

• Als u wilt dat uw container-app alle externe toegang beperkt, maakt u een interne Container Apps-omgeving.

• Als u uw eigen VNet gebruikt, moet u een subnet opgeven dat exclusief is toegewezen aan de Container App-omgeving die u implementeert. Dit subnet is niet beschikbaar voor andere services.

• Netwerkadressen worden toegewezen vanuit een subnetbereik dat u definieert als de omgeving wordt gemaakt.

  • U kunt het subnetbereik definiëren dat wordt gebruikt door de Container Apps-omgeving.

  • U kunt binnenkomende aanvragen beperken tot de omgeving uitsluitend naar het VNet door de omgeving als intern te implementeren.

Notitie

Wanneer u uw eigen virtuele netwerk opgeeft, worden er extra beheerde resources gemaakt. Voor deze resources worden kosten in rekening gebracht tegen hun bijbehorende tarieven.

Als u begint met het ontwerpen van het netwerk rond uw container-app, raadpleegt u Virtuele netwerken plannen.

Notitie

Het verplaatsen van VNets tussen verschillende resourcegroepen of abonnementen is niet toegestaan als het VNet wordt gebruikt door een Container Apps-omgeving.

Gedrag van HTTP Edge-proxy

Azure Container Apps maakt gebruik van de Envoy-proxy als edge HTTP-proxy. Transport Layer Security (TLS) wordt beëindigd aan de rand en aanvragen worden gerouteerd op basis van hun regels voor het splitsen van verkeer en routeert verkeer naar de juiste toepassing.

HTTP-toepassingen worden geschaald op basis van het aantal HTTP-aanvragen en -verbindingen. Envoy routeert intern verkeer binnen clusters.

Downstreamverbindingen ondersteunen HTTP1.1 en HTTP2 en Envoy detecteert en upgradet verbindingen automatisch als de clientverbinding een upgrade vereist.

Upstream-verbindingen worden gedefinieerd door de transport eigenschap in te stellen op het object inkomend verkeer.

Configuratie voor inkomend verkeer

Onder de sectie Inkomend verkeer kunt u de volgende instellingen configureren:

• Toegankelijkheidsniveau: U kunt uw container-app instellen als extern of intern toegankelijk in de omgeving. Een omgevingsvariabele CONTAINER_APP_ENV_DNS_SUFFIX wordt gebruikt om automatisch het FQDN-achtervoegsel (Fully Qualified Domain Name) voor uw omgeving op te lossen. Wanneer u communiceert tussen container-apps binnen dezelfde omgeving, kunt u ook de naam van de app gebruiken. Zie Inkomend verkeer in Azure Container Apps voor meer informatie over het openen van uw apps.

• Regels voor het splitsen van verkeer: u kunt regels voor het splitsen van verkeer tussen verschillende revisies van uw toepassing definiëren. Zie Verkeer splitsen voor meer informatie.

Zie Inkomend verkeer in Azure Container Apps voor meer informatie over verschillende netwerkscenario's.

Portal dependencies (Portal-afhankelijkheden)

Voor elke app in Azure Container Apps zijn er twee URL's.

De Container Apps-runtime genereert in eerste instantie een FQDN (Fully Qualified Domain Name) die wordt gebruikt voor toegang tot uw app. Zie de toepassings-URL in het venster Overzicht van uw container-app in Azure Portal voor de FQDN-naam van uw container-app.

Er wordt ook een tweede URL voor u gegenereerd. Deze locatie verleent toegang tot de streamingservice voor logboeken en de console. Indien nodig moet u mogelijk toevoegen https://azurecontainerapps.dev/ aan de acceptatielijst van uw firewall of proxy.

Poorten en IP-adressen

De volgende poorten worden weergegeven voor binnenkomende verbindingen.

Protocol	Poort(en)
HTTP/HTTPS	80, 443

IP-adressen worden onderverdeeld in de volgende typen:

Type	Description
Openbaar ip-adres voor inkomend verkeer	Wordt gebruikt voor toepassingsverkeer in een externe implementatie en beheerverkeer in zowel interne als externe implementaties.
Uitgaand openbaar IP-adres	Wordt gebruikt als het IP-adres 'van' voor uitgaande verbindingen die het virtuele netwerk verlaten. Deze verbindingen worden niet gerouteerd naar een VPN. Uitgaande IP-adressen kunnen na verloop van tijd veranderen. Het gebruik van een NAT-gateway of een andere proxy voor uitgaand verkeer vanuit een Container Apps-omgeving wordt alleen ondersteund in een omgeving met workloadprofielen.
IP-adres van interne load balancer	Dit adres bestaat alleen in een interne omgeving.

Subnet

Integratie van virtuele netwerken is afhankelijk van een toegewezen subnet. Hoe IP-adressen worden toegewezen in een subnet en welke subnetgrootten worden ondersteund, is afhankelijk van welk abonnement u gebruikt in Azure Container Apps.

Selecteer de grootte van het subnet zorgvuldig. Subnetgrootten kunnen niet worden gewijzigd nadat u een Container Apps-omgeving hebt gemaakt.

Verschillende omgevingstypen hebben verschillende subnetvereisten:

Omgeving voor workloadprofielen

• /27 is de minimale subnetgrootte die is vereist voor de integratie van virtuele netwerken.

• Uw subnet moet worden gedelegeerd aan Microsoft.App/environments.

• Wanneer u een externe omgeving met extern inkomend verkeer gebruikt, routeert inkomend verkeer via het openbare IP-adres van de infrastructuur in plaats van via uw subnet.

• Container Apps reserveert automatisch 12 IP-adressen voor integratie met het subnet. Het aantal IP-adressen dat is vereist voor infrastructuurintegratie, verschilt niet op basis van de schaalvereisten van de omgeving. Aanvullende IP-adressen worden toegewezen volgens de volgende regels, afhankelijk van het type workloadprofiel dat u gebruikt, worden toegewezen, afhankelijk van het workloadprofiel van uw omgeving:

  • Toegewezen workloadprofiel: naarmate uw container-app wordt uitgeschaald, heeft elk knooppunt één IP-adres toegewezen.

  • Workloadprofiel verbruik: elk IP-adres kan worden gedeeld tussen meerdere replica's. Plan bij het plannen van het aantal IP-adressen voor uw app 1 IP-adres per 10 replica's.

• Wanneer u een wijziging aanbrengt in één revisiemodus, wordt de vereiste adresruimte gedurende een korte periode verdubbeld om implementaties zonder downtime te ondersteunen. Dit is van invloed op de werkelijke, beschikbare ondersteunde replica's of knooppunten voor een bepaalde subnetgrootte. In de volgende tabel ziet u zowel de maximaal beschikbare adressen per CIDR-blok als het effect op horizontale schaal.

  Subnetgrootte	Beschikbare IP-adressen1	Maximum aantal knooppunten (toegewezen workloadprofiel)2	Maximum aantal replica's (workloadprofiel verbruik)2
  /23	500	250	2500
  /24	244	122	1,220
  /25	116	58	580
  /26	52	26	260
  /27	20	10	100

  ¹ De beschikbare IP-adressen zijn de grootte van het subnet minus de 12 IP-adressen die vereist zijn voor de Azure Container Apps-infrastructuur.
  ² Dit houdt rekening met apps in de modus voor één revisie.

Alleen verbruiksomgeving

• /23 is de minimale subnetgrootte die is vereist voor de integratie van virtuele netwerken.

• De Container Apps-runtime reserveert minimaal 60 IP-adressen voor infrastructuur in uw VNet. Het gereserveerde bedrag kan maximaal 256 adressen verhogen naarmate apps in uw omgeving worden geschaald.

• Naarmate uw apps worden geschaald, wordt er een nieuw IP-adres toegewezen voor elke nieuwe replica.

• Wanneer u een wijziging aanbrengt in één revisiemodus, wordt de vereiste adresruimte gedurende een korte periode verdubbeld om implementaties zonder downtime te ondersteunen. Dit is van invloed op de werkelijke, beschikbare ondersteunde replica's voor een bepaalde subnetgrootte.

Beperkingen voor subnetadresbereiken

Omgeving voor workloadprofielen

Subnetadresbereiken kunnen niet overlappen met de volgende bereiken die zijn gereserveerd door Azure Kubernetes Services:

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

Daarnaast behoudt een omgeving voor workloadprofielen de volgende adressen in:

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

Alleen verbruiksomgeving

Subnetadresbereiken kunnen niet overlappen met de volgende bereiken die zijn gereserveerd door Azure Kubernetes Services:

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

Als u uw container-apps-omgeving hebt gemaakt met een aangepaste service-CIDR, moet u ervoor zorgen dat het subnet van uw container-app (of een peered subnet) geen conflict veroorzaakt met het CIDR-bereik van uw aangepaste service.

Subnetconfiguratie met CLI

Als er een Container Apps-omgeving wordt gemaakt, geeft u resource-id's op voor één subnet.

Als u de CLI gebruikt, is infrastructure-subnet-resource-idde parameter voor het definiëren van de resource-id van het subnet. Het subnet host infrastructuuronderdelen en gebruikers-app-containers.

Als u de Azure CLI gebruikt met een omgeving met alleen verbruik en het bereik platformReservedCidr is gedefinieerd, mag het subnet niet overlappen met het IP-bereik dat is gedefinieerd in platformReservedCidr.

Routes

Door de gebruiker gedefinieerde routes (UDR)

Door de gebruiker gedefinieerde routes (UDR) en gecontroleerde uitgaand verkeer via NAT Gateway worden ondersteund in de omgeving met workloadprofielen. In de omgeving Alleen verbruik worden deze functies niet ondersteund.

Notitie

Wanneer u UDR gebruikt met Azure Firewall in Azure Container Apps, moet u bepaalde FQDN's en servicetags toevoegen aan de acceptatielijst voor de firewall. Zie UDR configureren met Azure Firewall voor meer informatie.

• U kunt UDR gebruiken in omgevingen met workloadprofielen om uitgaand verkeer van uw container-app te beperken via Azure Firewall of andere netwerkapparaten.

• Het configureren van UDR wordt uitgevoerd buiten het bereik van de container-apps-omgeving.

Azure maakt bij het maken een standaardroutetabel voor uw virtuele netwerken. Door een door de gebruiker gedefinieerde routetabel te implementeren, kunt u bepalen hoe verkeer binnen uw virtuele netwerk wordt gerouteerd. U kunt bijvoorbeeld een UDR maken waarmee al het verkeer naar de firewall wordt gerouteerd.

UDR configureren met Azure Firewall

Door de gebruiker gedefinieerde routes worden alleen ondersteund in een omgeving met workloadprofielen. De volgende toepassings- en netwerkregels moeten worden toegevoegd aan de acceptatielijst voor uw firewall, afhankelijk van de resources die u gebruikt.

Notitie

Voor een handleiding over het instellen van UDR met Container Apps om uitgaand verkeer met Azure Firewall te beperken, gaat u naar container-apps en Azure Firewall.

Toepassingsregels

Toepassingsregels staan verkeer toe of weigeren op basis van de toepassingslaag. De volgende regels voor uitgaande firewalltoepassingen zijn vereist op basis van het scenario.

Scenario's	FQDN's	Beschrijving
Alle scenario's	mcr.microsoft.com, *.data.mcr.microsoft.com	Deze FQDN's voor Microsoft Container Registry (MCR) worden gebruikt door Azure Container Apps. Deze toepassingsregels of de netwerkregels voor MCR moeten worden toegevoegd aan de acceptatielijst bij het gebruik van Azure Container Apps met Azure Firewall.
Azure Container Registry (ACR)	Uw ACR-adres, *.blob.core.windows.netlogin.microsoft.com	Deze FQDN's zijn vereist bij het gebruik van Azure Container Apps met ACR en Azure Firewall.
Azure Key Vault	Uw Azure-Key-Vault-adres, login.microsoft.com	Deze FQDN's zijn vereist naast de servicetag die is vereist voor de netwerkregel voor Azure Key Vault.
Beheerde identiteit	*.identity.azure.net, , , login.microsoftonline.com*.login.microsoftonline.com*.login.microsoft.com	Deze FQDN's zijn vereist bij het gebruik van een beheerde identiteit met Azure Firewall in Azure Container Apps.
Docker Hub Registry	hub.docker.com, , registry-1.docker.ioproduction.cloudflare.docker.com	Als u docker Hub-register gebruikt en toegang wilt krijgen via de firewall, moet u deze FQDN's toevoegen aan de firewall.

Netwerkregels

Netwerkregels staan verkeer toe of weigeren op basis van de netwerk- en transportlaag. De volgende uitgaande firewallnetwerkregels zijn vereist op basis van het scenario.

Scenario's	Servicetag	Beschrijving
Alle scenario's	MicrosoftContainerRegistry, AzureFrontDoorFirstParty	Deze servicetags voor Microsoft Container Registry (MCR) worden gebruikt door Azure Container Apps en deze netwerkregels of de toepassingsregels voor MCR moeten worden toegevoegd aan de acceptatielijst bij het gebruik van Azure Container Apps met Azure Firewall.
Azure Container Registry (ACR)	AzureContainerRegistry, AzureActiveDirectory	Wanneer u ACR gebruikt met Azure Container Apps, moet u deze toepassingsregels configureren die worden gebruikt door Azure Container Registry.
Azure Key Vault	AzureKeyVault, AzureActiveDirectory	Deze servicetags zijn vereist naast de FQDN voor de toepassingsregel voor Azure Key Vault.
Beheerde identiteit	AzureActiveDirectory	Wanneer u Beheerde identiteit gebruikt met Azure Container Apps, moet u deze toepassingsregels configureren die worden gebruikt door Beheerde identiteit.

Notitie

Raadpleeg de documentatie over servicetags voor Azure-resources die u gebruikt met Azure Firewall die niet in dit artikel worden vermeld.

Nat-gatewayintegratie

U kunt NAT Gateway gebruiken om uitgaande connectiviteit voor uitgaand internetverkeer in uw virtuele netwerk te vereenvoudigen in een omgeving met workloadprofielen.

Wanneer u een NAT-gateway configureert in uw subnet, biedt de NAT-gateway een statisch openbaar IP-adres voor uw omgeving. Al het uitgaande verkeer van uw container-app wordt gerouteerd via het statische openbare IP-adres van de NAT-gateway.

Omgevingsbeveiliging

U kunt uw omgeving voor werkbelastingprofielen voor inkomend en uitgaand netwerkverkeer volledig beveiligen door de volgende acties uit te voeren:

• Maak uw interne container-app-omgeving in een workloadprofielenomgeving. Raadpleeg workloadprofielen beheren met de Azure CLI voor stappen.

• Integreer uw Container Apps met een Application Gateway.

• Configureer UDR om al het verkeer via Azure Firewall te routeren.

Peer-to-peer-versleuteling in de Azure Container Apps-omgeving

Azure Container Apps ondersteunt peer-to-peer TLS-versleuteling binnen de omgeving. Als u deze functie inschakelt, wordt al het netwerkverkeer in de omgeving versleuteld met een privécertificaat dat geldig is binnen het bereik van de Azure Container Apps-omgeving. Deze certificaten worden automatisch beheerd door Azure Container Apps.

Notitie

Peer-to-peer-versleuteling is standaard uitgeschakeld. Het inschakelen van peer-to-peer-versleuteling voor uw toepassingen kan de latentie van reacties verhogen en de maximale doorvoer in scenario's met hoge belasting verminderen.

In het volgende voorbeeld ziet u een omgeving waarin peer-to-peer-versleuteling is ingeschakeld.

¹ Binnenkomend TLS-verkeer wordt beëindigd bij de ingangsproxy aan de rand van de omgeving.

² Verkeer van en naar de ingangsproxy in de omgeving is TLS versleuteld met een privécertificaat en ontsleuteld door de ontvanger.

³ Aanroepen van app A naar de FQDN van app B worden eerst verzonden naar de edge-ingangsproxy en zijn TLS versleuteld.

⁴ Aanroepen van app A naar app B met de app-naam van app B worden rechtstreeks naar app B verzonden en zijn VERSLEUTELD met TLS.

Toepassingen in een Container Apps-omgeving worden automatisch geverifieerd. De Container Apps-runtime biedt echter geen ondersteuning voor autorisatie voor toegangsbeheer tussen toepassingen met behulp van de ingebouwde peer-to-peer-versleuteling.

Wanneer uw apps communiceren met een client buiten de omgeving, wordt verificatie in twee richtingen met mTLS ondersteund. Zie Clientcertificaten configureren voor meer informatie.

Azure-CLI

U kunt peer-to-peer-versleuteling inschakelen met behulp van de volgende opdrachten.

Bij het maken:

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

Voor een bestaande container-app:

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

ARM-sjabloon

U kunt mTLS inschakelen in de ARM-sjabloon voor Container Apps-omgevingen met behulp van de volgende configuratie.

{
  ...
  "properties": {
       "peerTrafficConfiguration":{
            "encryption": {
                "enabled": "true|false"
            }
        }
  ...
}

DNS

• Aangepaste DNS: Als uw VNet gebruikmaakt van een aangepaste DNS-server in plaats van de standaard door Azure geleverde DNS-server, configureert u uw DNS-server om niet-opgeloste DNS-query's door te sturen naar 168.63.129.16. Recursieve azure-resolvers gebruiken dit IP-adres om aanvragen op te lossen. Wanneer u uw NSG of firewall configureert, blokkeert u het 168.63.129.16 adres niet, anders werkt uw Container Apps-omgeving niet correct.

• Inkomend verkeer van VNet-bereik: als u van plan bent om inkomend verkeer van VNet-bereiken in een interne omgeving te gebruiken, configureert u uw domeinen op een van de volgende manieren:

  1. Niet-aangepaste domeinen: als u geen aangepast domein wilt gebruiken, maakt u een privé-DNS-zone waarmee het standaarddomein van de Container Apps-omgeving wordt omgezet in het statische IP-adres van de Container Apps-omgeving. U kunt Azure Privé-DNS of uw eigen DNS-server gebruiken. Als u Azure Privé-DNS gebruikt, maakt u een privé-DNS-zone met de naam het standaarddomein van de Container App-omgeving (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) met een A record. De A record bevat de naam *<DNS Suffix> en het statische IP-adres van de Container Apps-omgeving.

  2. Aangepaste domeinen: als u van plan bent om aangepaste domeinen te gebruiken en een externe Container Apps-omgeving gebruikt, gebruikt u een openbaar omzetbaar domein om een aangepast domein en certificaat toe te voegen aan de container-app. Als u een interne Container Apps-omgeving gebruikt, is er geen validatie voor de DNS-binding, omdat het cluster alleen toegankelijk is vanuit het virtuele netwerk. Maak bovendien een Privé-DNS-zone waarmee het apexdomein wordt omgezet in het statische IP-adres van de Container Apps-omgeving. U kunt Azure Privé-DNS of uw eigen DNS-server gebruiken. Als u Azure Privé-DNS gebruikt, maakt u een Privé-DNS zone met de naam apexdomein, met een A record die verwijst naar het statische IP-adres van de Container Apps-omgeving.

Het statische IP-adres van de Container Apps-omgeving is beschikbaar in Azure Portal in aangepast DNS-achtervoegsel van de pagina container-app of met behulp van de Azure CLI-opdracht az containerapp env list .

Beheerde resources

Wanneer u een interne of externe omgeving in uw eigen netwerk implementeert, wordt er een nieuwe resourcegroep gemaakt in het Azure-abonnement waarin uw omgeving wordt gehost. Deze resourcegroep bevat infrastructuuronderdelen die worden beheerd door het Azure Container Apps-platform. Wijzig de services in deze groep of de resourcegroep zelf niet.

Omgeving voor workloadprofielen

De naam van de resourcegroep die is gemaakt in het Azure-abonnement waarin uw omgeving wordt gehost, wordt standaard voorafgegaan door ME_ de naam van de resourcegroep en de naam van de resourcegroep kan worden aangepast wanneer u uw container-app-omgeving maakt.

Voor externe omgevingen bevat de resourcegroep een openbaar IP-adres dat specifiek wordt gebruikt voor binnenkomende connectiviteit met uw externe omgeving en een load balancer. Voor interne omgevingen bevat de resourcegroep alleen een Load Balancer.

Naast de standaardfacturering voor Azure Container Apps wordt u gefactureerd voor:

• Eén standaard statisch openbaar IP-adres voor uitgaand verkeer als u een interne of externe omgeving gebruikt, plus één standaard statisch openbaar IP-adres voor inkomend verkeer als u een externe omgeving gebruikt. Als u meer openbare IP-adressen nodig hebt voor uitgaand verkeer vanwege SNAT-problemen, opent u een ondersteuningsticket om een onderdrukking aan te vragen.

• Eén standaard load balancer.

• De kosten van verwerkte gegevens (in GB's) omvatten zowel inkomend als uitgaand verkeer voor beheerbewerkingen.

Alleen verbruiksomgeving

De naam van de resourcegroep die is gemaakt in het Azure-abonnement waarop uw omgeving wordt gehost, wordt standaard voorafgegaan door MC_ de naam van de resourcegroep en de naam van de resourcegroep kan niet worden aangepast wanneer u een container-app maakt. De resourcegroep bevat openbare IP-adressen die specifiek worden gebruikt voor uitgaande connectiviteit vanuit uw omgeving en een load balancer.

Naast de standaardfacturering voor Azure Container Apps wordt u gefactureerd voor:

• Eén standaard statisch openbaar IP-adres voor uitgaand verkeer. Als u meer IP-adressen nodig hebt voor uitgaand verkeer vanwege SNAT-problemen (Source Network Address Translation), opent u een ondersteuningsticket om een onderdrukking aan te vragen.

• Twee standaard load balancers als u een interne omgeving of één standaard load balancer gebruikt als u een externe omgeving gebruikt. Elke load balancer heeft minder dan zes regels. De kosten van verwerkte gegevens (in GB's) omvatten zowel inkomend als uitgaand verkeer voor beheerbewerkingen.

Volgende stappen

• Implementeren met een externe omgeving
• Implementeren met een interne omgeving