Uitgaande internettoegang: uitgaand verkeer vanuit Azure beheren

In dit artikel wordt uitgelegd hoe u uitgaande internettoegang kunt beheren vanuit Azure virtuele netwerken. Het vergelijkt NAT Gateway, Azure Firewall en gecombineerde uitgaande patronen om u te helpen bij het kiezen van een voorspelbare, veilige methode voor uw workloads.

Wat in dit artikel wordt behandeld

Controle op uitgaand verkeer bepaalt hoe uw Azure-workloads het openbare internet bereiken. Een goed ontworpen uitgaande strategie biedt voorspelbare openbare IP-adressen, voorkomt uitputting van SNAT-poorten en filtert optioneel uitgaande verbindingen per bestemming.

Note

In dit artikel worden begrippen behandeld die specifiek zijn voor uitgaand verkeer. Zie Azure Firewall en verkeersinspectie voor volledige firewalldekking.

Wie heeft dit artikel nodig

Lees dit artikel als een of meer van deze voorwaarden van toepassing zijn:

  • Uw workloads hebben gecontroleerde uitgaande toegang tot internet nodig voor updates, API's of externe services.
  • U hebt voorspelbare openbare IP-adressen nodig voor uitgaande verbindingen.
  • U moet SNAT-poortuitputting voorkomen of uitgaande connectiviteit schalen voor workloads met een hoge verbinding.
  • U moet kiezen tussen NAT-gateway, Azure Firewall of een gecombineerd patroon voor uitgaand beheer en inspectie.

Tip

Volgt u een scenariopad? Selecteer uw scenario bovenaan de pagina voor op maat gemaakte richtlijnen. De volgende kernrichtlijnen zijn van toepassing op alle lezers.

Focus op lift-and-shift: Uw gemigreerde VM's hebben gecontroleerde uitgaande internettoegang nodig. Centraliseer al het uitgaande verkeer via de hubfirewall om consistent beveiligingsbeleid af te dwingen voor gemigreerde workloads.

Lees dit artikel als u:

  • Implementeer workloads die internet moeten bereiken voor updates, API-aanroepen of services van derden.
  • U wilt uitgaand beheer centraliseren via Azure Firewall in het hub-VNet.
  • U moet standaard uitgaande toegang uitschakelen voor gemigreerde workloads en deze vervangen door een expliciete uitgaande methode.
  • Een vast, voorspelbaar openbaar IP-adres vereisen voor uitgaande verbindingen.

Focus van de modernisering: Alle spoke-VNets leiden uitgaand verkeer via de hubfirewall met behulp van door de gebruiker gedefinieerde routes (UDR). Dit gecentraliseerde uitgaand model is integraal voor uw beveiligingsarchitectuur, omdat app-teams geen door IT beheerde beveiligingscontroles kunnen omzeilen.

Lees dit artikel als u:

  • Het is nodig om af te dwingen dat alle workloads in de spoke (AKS, App Service, VM’s) hun uitgaande verkeer via de hub-firewall routeren.
  • Op UDR gebaseerde routering van elke spoke naar de Azure Firewall in de hub voor consistent uitgaand verkeerbeleid.
  • Vereisen dat de hubfirewall fungeert als SNAT voor alle uitgaande verbindingen.
  • Moet SNAT-poortuitputting voorkomen voor workloads met een hoog aantal verbindingen.

Focus op meerdere clouds: Neem gecentraliseerd uitgaand verkeer op als uw doelontwerp een beheerd internetuitgangsbeleid vereist. Anders loopt cross-cloudverkeer via het transitpad (Azure Firewall in een beveiligde virtuele hub) en heeft u geen afzonderlijke configuratie voor uitgaand verkeer nodig.

Lees dit artikel als u:

  • Gecentraliseerd internetuitgangsbeleid in uw Azure landingszone nodig.
  • Wilt u dezelfde Azure Firewall delen voor zowel cross-cloud transit inspectie als internetuitgangen.
  • Vervang standaard uitgaande toegang voordat deze wordt uitgefaseerd.

Azure services en functies

In de volgende tabel worden de services en functies beschreven die beschikbaar zijn voor uitgaande internettoegang in Azure virtuele netwerken.

Service ofwel functie Wat het biedt Wanneer gebruikt u het?
Standaard uitgaande toegang (buiten gebruik gesteld) Azure wijst automatisch een tijdelijk openbaar IP-adres toe voor uitgaande verbindingen. Het toegewezen IP-adres is niet voorspelbaar en kan zonder kennisgeving worden gewijzigd. Niet gebruiken voor nieuwe implementaties. Vervang door NAT Gateway of Azure Firewall. Zie Beveiligingsoverwegingen.
Azure NAT Gateway Beheerde SNAT-service met vaste, voorspelbare openbare IP-adressen. Biedt 64.512 SNAT-poorten per openbaar IP-adres, maximaal 16 openbare IP-adressen (in totaal meer dan 1 miljoen poorten). Geen inhoudsfiltering. Workloads met uitsluitend uitgaand verkeer die een vast uitgaand IP-adres nodig hebben, toepassingen met een groot aantal verbindingen en scenario's waarin SNAT-poortuitputting een risico vormt.
Azure Firewall Volledige laag 3–7-inspectie voor uitgaand verkeer. FQDN-filtering, URL-filtering, webcategorieën en IDPS (Premium SKU). Gecentraliseerd beleidsbeheer. Wanneer u wilt bepalen met welke bestemmingen uw resources verbinding maken, niet alleen dat ze uitgaande toegang hebben.
NAT-gateway + Azure Firewall NAT Gateway verwerkt SNAT-schaalaanpassing op het firewallsubnet. Azure Firewall zorgt voor inspectie en filtering. Er treedt geen dubbele NAT op. Productieomgevingen die zowel schaalbaar uitgaand netwerkverkeer als inhoudsbewuste filtering nodig hebben. Aanbevolen architectuur voor bedrijfsworkloads.
VM met openbaar IP-adres (uitgaand) De virtuele machine gebruikt een eigen openbaar IP-adres voor uitgaand verkeer. Geen gecentraliseerd besturingselement of filteren. Niet gebruiken in productie. Geen gecentraliseerd beheer, onvoorspelbaar op schaal en profiteert niet van gedeelde SNAT-resources.

Hoe te kiezen

Diagram met drie uitgaande routes vanuit een virtueel workloadnetwerk via NAT Gateway, Azure Firewall of beide.

Uitgaande toegang beheren

Gebruik de volgende tabel om een uitgaande methode te selecteren op basis van uw vereisten.

Uw behoeften Aanbevolen aanpak Waarom
Alleen een vast uitgaand IP-adres, geen filtering nodig NAT-gateway Biedt voorspelbare openbare IP-adressen met automatische toewijzing van SNAT-poorten. Geen inspectieoverhead of filterkosten. Eenvoudigste optie die gereed is voor productie.
FQDN-filtering, URL-filtering of verkeersinspectie Azure Firewall Hiermee filtert u uitgaande verbindingen op doel-FQDN of URL. Premium SKU voegt IDPS- en TLS-inspectie toe voor geavanceerde detectie van bedreigingen.
Vast uitgaand IP-adres en inhoudsfiltering NAT-gateway + Azure Firewall NAT Gateway op het AzureFirewallSubnet biedt schaalbare SNAT. De firewall inspecteert verkeer voordat het het netwerk verlaat. Het beste van beide mogelijkheden.
Niet gebruiken voor nieuwe implementaties Standaardtoegang voor uitgaand verkeer of openbaar IP-adres van VM De standaard uitgaande toegang wordt buiten gebruik gesteld. Openbare IP-adressen van vm's bieden geen gecentraliseerd beheer. Beide zijn ongeschikt voor productieworkloads.

NAT-gateway versus Azure Firewall voor uitgaand verkeer

Gebruik de volgende vergelijking om inzicht te hebben in de afwegingen tussen NAT Gateway en Azure Firewall wanneer deze onafhankelijk worden gebruikt.

Vermogen NAT-gateway Azure Firewall
SNAT-poorten 64.512 per openbaar IP-adres (maximaal 16 IP's, meer dan 1 miljoen in totaal) 2.496 per openbaar IP-adres per backend-exemplaar (max. 250 IP-adressen)
Verkeer filteren Geen: geeft al het uitgaande verkeer door FQDN-regels, URL-filtering, webcategorieën, netwerkregels
IDPS- en TLS-inspectie Niet beschikbaar Alleen Premium-SKU
Throughput Lijnsnelheid voor het subnet (geen gepubliceerde bovengrens voor SNAT) Tot 100 Gbps (Premium), 30 Gbps (Standard), 250 Mbps (Basic)
Kostenmodel Resources per uur + per GB verwerkte gegevens Resource per uur + gegevens per GB verwerkt (hogere basiskosten)
Complexiteit van routering Koppelt rechtstreeks aan een subnet, geen UDR nodig Vereist UDR (0.0.0.0/0 → privé-IP van de firewall) op workloadsubnetten
Gebruiksscenario Uitgaande verbindingen met een hoog volume die vaste IP-adressen nodig hebben Gereguleerde omgevingen waarvoor egressfiltering en logging vereist zijn

Routeringsprioriteit voor uitgaand verkeer

Azure evalueert uitgaande methoden in de volgende prioriteitsvolgorde. Methoden met een hogere prioriteit overschrijven lagere prioriteit in hetzelfde subnet:

  1. UDR naar een virtueel apparaat of virtuele netwerkgateway: overschrijft alle andere uitgaande methoden, waaronder NAT Gateway.
  2. NAT-gateway: heeft prioriteit boven openbare IP-adressen op instantieniveau en uitgaande regels van de load balancer.
  3. Openbaar IP-adres op exemplaarniveau op de virtuele machine.
  4. Uitgaande regels voor de load balancer.
  5. Standaardsysteemroute naar internet (Microsoft deze optie voor nieuwe implementaties buiten gebruik gesteld).

Important

Een door de gebruiker gedefinieerde route (UDR) met bestemming 0.0.0.0/0 die verwijst naar een virtueel apparaat (zoals Azure Firewall) overschrijft NAT Gateway. Dit gedrag is standaard bedoeld voor de gecombineerde NAT-gateway en firewallarchitectuur. De UDR voor workloadsubnetten dwingt verkeer door de firewall te lopen, terwijl NAT Gateway op het AzureFirewallSubnet de uiteindelijke uitgaande IP-adressen levert.

Gecombineerde architectuur: NAT-gateway + Azure Firewall

Het aanbevolen productiepatroon voor uitgaand bedrijf combineert beide services:

  1. Workloadsubnetten hebben een UDR die 0.0.0.0/0-verkeer verzendt naar het Azure Firewall privé-IP-adres.
  2. Azure Firewall het uitgaande verkeer inspecteert en filtert met behulp van netwerkregels, toepassingsregels of beide.
  3. NAT Gateway koppelt aan het AzureFirewallSubnet en biedt schaalbare SNAT voor de uitgaande verbindingen van de firewall.
  4. Er treedt geen dubbele NAT op. De firewall verzendt verkeer naar NAT Gateway met behulp van het privé-IP-adres en NAT Gateway past SNAT eenmaal toe met behulp van de openbare IP-adressen.

Deze architectuur biedt u gecentraliseerde inspectie met schaalbare SNAT. Het AzureFirewallSubnet heeft geen extra UDR's nodig omdat NAT Gateway automatisch uitgaand internetverkeer routeert wanneer dit is gekoppeld.

Note

Standard NAT Gateway is een zonegebonden resource en biedt geen ondersteuning voor zone-redundante implementaties. Als u een zone-redundante Azure Firewall implementeert, gebruikt u NAT Gateway V2 (StandardV2 SKU) voor zone-redundante SNAT. Standard NAT Gateway wordt een enkel storingspunt bij een uitval van een beschikbaarheidszone in combinatie met een zone-redundante firewall. Zie NAT Gateway-SKU's voor meer informatie.

Uitleg van de gegevensstroom

In de volgende volgorde ziet u hoe één uitgaande aanvraag door de gecombineerde architectuur stroomt:

  1. Een VM in een workloadsubnet start een TCP-verbinding met een externe API (bijvoorbeeld api.contoso.com:443).
  2. De UDR van het subnet komt overeen met 0.0.0.0/0 en verzendt het pakket naar het Azure Firewall privé-IP-adres.
  3. Azure Firewall evalueert de verbinding met toepassingsregels en netwerkregels. Als een toepassingsregel met een FQDN-toestaanvermelding overeenkomt, staat de firewall de verbinding toe.
  4. De firewall verzendt het toegestane pakket vanuit een eigen interface op het AzureFirewallSubnet.
  5. NAT Gateway, gekoppeld aan het AzureFirewallSubnet, voert SNAT uit. Het vertaalt het privé-bron-IP-adres van de firewall naar een van de openbare IP-adressen en wijst een SNAT-poort uit de pool toe.
  6. Het antwoord van de externe API keert terug naar het openbare IP-adres van de NAT-gateway. NAT Gateway voert omgekeerde vertaling uit en levert het pakket weer aan de firewall.
  7. De firewall verzendt het antwoord naar de oorspronkelijke VM via de bestaande verbindingsstatus.

In deze end-to-end-stroom inspecteert de firewall precies één keer verkeer en past NAT Gateway SNAT precies één keer toe, zonder dubbele NAT.

Bewaking en diagnostiek

Bewaak uw uitgaande infrastructuur om capaciteitsproblemen te detecteren voordat deze van invloed zijn op workloads:

  • Metrische gegevens van NAT Gateway: Bewaak het totale aantal SNAT-verbindingen, het aantal SNAT-verbindingen (per status) en de beschikbaarheid van gegevenspaden in Azure Monitor. Stel waarschuwingen in wanneer het SNAT-poortgebruik groter is dan 80% toegewezen capaciteit.
  • Azure Firewall logboeken: schakel diagnostische instellingen in om logboeken naar Log Analytics te verzenden. Gebruik de logboekcategorieën AzureFirewallApplicationRule en AzureFirewallNetworkRule om toegestane en geweigerde uitgaande verbindingen te controleren.
  • Verbindingsmonitor: gebruik Network Watcher Verbindingsmonitor om end-to-end-connectiviteit van workload-VM's naar externe eindpunten te testen. Verbindingsmonitor detecteert toenames in latentie en verbindingsfouten die kunnen duiden op SNAT-uitputting of een onjuiste firewallconfiguratie.
  • Metrische gegevens van firewall: Houd doorvoer, aantal regels bereikt en SNAT-poortgebruik bij om de juiste grootte van uw firewall-SKU te bepalen en hot-regels te identificeren.

Ontwerpoverwegingen

Gebruik Azure Firewall voor alle uitgaande communicatie van gemigreerde workloads. Deze aanpak biedt u gecentraliseerde FQDN-filtering, logboekregistratie en detectie van bedreigingen vanaf dag één:

  • Standaard uitgaande toegang uitschakelen: Voor nieuwe implementaties worden subnetten standaard ingesteld op privé (geen automatisch uitgaand verkeer). Voor bestaande VNets vervangt u standaard uitgaand verkeer expliciet door Azure Firewall uitgaand verkeer om te voorkomen dat u vertrouwt op onvoorspelbare, niet-gecontroleerde openbare IP-adressen.
  • UDR voor workloadsubnetten: Maak een door de gebruiker gedefinieerde route (0.0.0.0/0 → Azure Firewall privé-IP) op elk subnet van de spoke-workload. Deze configuratie leidt al het voor internet bestemde verkeer via de hubfirewall.
  • NAT Gateway op AzureFirewallSubnet: Koppel NAT Gateway aan het firewallsubnet voor schaalbare SNAT. Deze combinatie biedt voorspelbare UITGAANDE IP-adressen en vermijdt SNAT-poortuitputting.
  • Start met ruime toestaanregels, verstreng deze geleidelijk: Sta tijdens de migratie uitgaand verkeer toe naar de bestemmingen die uw toepassingen nodig hebben (Windows Update, pakketbronnen, API's van derden). Nadat de migratie is gestabiliseerd, controleert u firewalllogboeken en beperkt u deze tot bekende FQDN's.

Op UDR gebaseerde routering van elke spoke naar de hubfirewall vormt de basis voor uw model voor uitgaande beveiliging. Appteams kunnen door IT beheerde uitgaande controles niet omzeilen:

  • UDR in elk spoke-VNet: Elk spoke-workloadsubnet heeft een routetabel met 0.0.0.0/0 → hub Azure Firewall privé-IP. Deze configuratie zorgt ervoor dat AKS-knooppunten, subnetten die met App Service VNet zijn geïntegreerd en VM's hun uitgaande verkeer via de firewall routeren.
  • Hubfirewall als SNAT: Azure Firewall voert bron-NAT uit voor alle uitgaande verbindingen. Alle spoke-workloads delen de uitgaande IP-adressen van de firewall, wat het opnemen in de allow-list van de firewall van de partner vereenvoudigt.
  • NAT-gateway voor SNAT-schaalaanpassing: Koppel NAT Gateway aan het AzureFirewallSubnet. Met 16 openbare IP-adressen (meer dan 1 miljoen SNAT-poorten) verwerkt u workloads met een hoog aantal verbindingen, zoals AKS-clusters met veel pods die externe API-aanroepen maken.
  • Toepassingsregels voor FQDN-beheer: Gebruik Azure Firewall toepassingsregels om uitgaand verkeer per FQDN te beperken. App-teams vragen FQDN om vermeldingen via een wijzigingsbeheerproces toe te staan. Standaard weigeren voorkomt exfiltratie van gegevens.

Azure Firewall in de beveiligde virtuele hub inspecteert zowel verkeer tussen cloudoverdrachten als uitgaand internetverkeer. Het delen van één firewall voor beide paden vereenvoudigt de architectuur:

  • Virtuele hubfirewall beveiligen voor uitgaand verkeer: Als u Virtual WAN implementeert met een beveiligde hub, verwerkt Azure Firewall in de hub internetuitgangen voor alle verbonden VNets. Configureer het routeringsbeleid voor internetverkeer van de beveiligde hub om 0.0.0.0/0 via de firewall te verzenden.
  • Uitgaand verkeer en cross-cloudoverdracht delen dezelfde firewall: Verkeer dat bestemd is voor internet en verkeer dat bestemd is voor AWS/Google Cloud via IPSec-tunnels, passeren beide Azure Firewall voor inspectie. Dit ontwerp betekent dat u één regelset voor alle uitgaande paden behoudt.
  • Centraliseer alleen indien nodig: Als uw ontwerp voor meerdere clouds geen gecentraliseerde internetuitgang vereist (bijvoorbeeld workloads die alleen communiceren tussen clouds), kunt u deze configuratie overslaan en alleen afhankelijk zijn van de firewallinspectie tussen clouds.

Prerequisites

Voordat u uitgaande verkeerscontroles implementeert, controleert u de volgende punten:

  • Er wordt een virtueel netwerk ingericht met subnetten die zijn afgestemd op uw workloads. Zie Virtuele netwerken en subnetten voor richtlijnen voor het ontwerpen van subnetten.
  • U begrijpt door de gebruiker gedefinieerde routes (UDR's) en hoe ze de standaardroutering Azure overschrijven. Zie Virtuele netwerken en subnetten voor UDR-configuratiedetails.
  • Uw firewallsubnet heeft de juiste grootte als u Azure Firewall gebruikt. Het AzureFirewallSubnet vereist minimaal /26 (64 adressen).
  • U kent uw SNAT-schaalvereisten. Bereken pieken in gelijktijdige uitgaande verbindingen om te bepalen hoeveel openbare IP-adressen van NAT Gateway u nodig hebt (64.512 poorten per IP).

Beveiligingsoverwegingen

Vervang standaard-uitgaande toegang

De standaard uitgaande toegang wordt buiten gebruik gesteld. Voor API-versies die na 31 maart 2026 zijn uitgebracht, worden nieuwe virtuele netwerken standaard ingesteld op privésubnetten (geen automatisch uitgaand verkeer). Bestaande virtuele netwerken worden niet beïnvloed, maar u moet migreren naar een expliciete uitgaande methode. Zie de standaarddocumentatie voor uitgaande toegang voor meer informatie.

Note

Bestaande virtuele netwerken en VM's die momenteel gebruikmaken van standaard uitgaande toegang blijven werken. Het toegewezen openbare IP-adres is echter niet voorspelbaar, biedt geen filters en triggers Azure Advisor waarschuwingen. Plan de migratie naar NAT Gateway of Azure Firewall ongeacht de tijdlijn voor buitengebruikstelling.

UDR-routering voor gecentraliseerde firewallinspectie

Wanneer u Azure Firewall gebruikt om uitgaand verkeer te beheren, maakt u op elk workloadsubnet een UDR aan met:

  • Bestemming: 0.0.0.0/0
  • Type van de volgende hop: Virtueel apparaat
  • Volgend hopadres: Azure Firewall privé-IP-adres (bijvoorbeeld 10.0.1.4)

Deze configuratie zorgt ervoor dat al het internetverkeer van workloadsubnetten door de firewall wordt doorgegeven voor inspectie. Zonder deze UDR omzeilt het verkeer de firewall en gebruikt het rechtstreeks de uitgaande methode die op het subnet is geconfigureerd.

Uitputting van SNAT-poorten voorkomen

SNAT-poortuitputting treedt op wanneer een workload meer gelijktijdige uitgaande verbindingen opent dan de beschikbare poortinventaris ondersteunt. Symptomen zijn onregelmatige verbindingstime-outs, TCP RST-pakketten op uitgaande verbindingen en mislukte HTTP-aanvragen met socketfouten. Toepassingslogboeken bevatten fouten 'adres dat al in gebruik is' of 'kan aangevraagde adressen niet toewijzen'. Uitputting manifesteert doorgaans onder belasting wanneer veel kortstondige verbindingen snel worden geopend met hetzelfde doel-IP en dezelfde poort.

Om uitputting te voorkomen:

  • Nat Gateway gebruiken voor workloads met een hoog aantal uitgaande verbindingen. Elk openbaar IP-adres biedt 64.512 SNAT-poorten met dynamische toewijzing voor alle resources in het subnet.
  • Voeg openbare IP-adressen toe aan uw NAT-gateway als de bewaking het poortgebruik van meer dan 80%laat zien. Voeg maximaal 16 openbare IP-adressen toe.
  • Gebruik groepsgewijze verbindingen in toepassingscode om bestaande verbindingen opnieuw te gebruiken in plaats van nieuwe verbindingen te openen voor elke aanvraag.
  • Diversifiëer waar mogelijk doeleindpunten . SNAT-poorttoewijzing is per doel-IP-/poort-tuple, dus het distribueren van verkeer over meerdere doel-IP-adressen vermindert de poortdruk.
  • Verminder niet-actieve time-outs om poorten sneller vrij te maken. De standaardtime-out voor inactiviteit van NAT Gateway is 4 minuten. Verlaag deze waarde voor workloads die veel kortstondige verbindingen maken.

Netwerkbeveiligingsgroepen vullen het beheer van uitgaand verkeer aan

Netwerkbeveiligingsgroepen (NSG's) en methoden voor uitgaand verkeer hebben verschillende doelen en werken samen. NSG's filteren verkeer op IP-adres en poort op subnet- of NIC-niveau. NAT Gateway en Azure Firewall bepalen hoe verkeer het internet bereikt. Gebruik beide lagen voor diepgaande verdediging. Zie netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen voor NSG-ontwerprichtlijnen.

Overwegingen voor geforceerde tunneling

Geforceerde tunneling via on-premises kan latentie veroorzaken en afhankelijkheid toevoegen aan de on-premises firewall. Overweeg Azure Firewall voor uitgaande inspectie als lage latentie belangrijk is. Als compliance vereist dat inspectie on-premises plaatsvindt, test u de end-to-endlatentie vanuit de workloadsubnetten en zorg ervoor dat het on-premisestraject aan de doorvoervereisten kan voldoen zonder een knelpunt te vormen.

Exfiltratie van gegevens voorkomen

Azure Firewall FQDN-filtering voorkomt exfiltratie van gegevens door uitgaande verbindingen met alleen goedgekeurde domeinnamen te beperken. Definieer toepassingsregels die verkeer naar specifieke FQDN's (bijvoorbeeld *.blob.core.windows.net of api.partner.com) toestaan en alle andere uitgaande verbindingen weigeren. Deze aanpak zorgt ervoor dat gecompromitteerde workloads geen gegevens kunnen verzenden naar door aanvallers beheerde eindpunten.

Meer informatie

Volgende stappen 

Tip

Zelf verkennen? Ga terug naar de overzichtsnavigator om uw volgende artikel per mogelijkheid te vinden.

De volgende stap in uw lift-and-shift-traject:

Configureer uw hubfirewall: stel Azure Firewall in voor gecentraliseerde controle van oost-west en uitgaand verkeer.

Vervolgens in uw moderniseringstraject:

Configureer uw hubfirewall: stel Azure Firewall in als SNAT/DNAT in uw hub om al het verkeer te verwijderen voordat deze de app-laag bereikt.

De volgende stap in uw cross-cloudtraject:

Cross-cloudmonitoring instellen: Cross-cloudomgevingen zijn moeilijker te diagnosticeren. Bewaking tot stand brengen voordat u live gaat.

  • Last updated on