Connectiviteit tussen regio's en meerdere clouds

Dit artikel helpt u bij het verbinden van Azure workloads in meerdere regio's en het uitbreiden van de connectiviteit met andere cloudproviders, zoals Amazon Web Services (AWS) en Google Cloud.

Wat in dit artikel wordt behandeld

In dit artikel worden de ontwerpbeslissingen besproken voor het verbinden van Azure virtuele netwerken (VNets) tussen regio's en het tot stand brengen van netwerkpaden naar workloads die worden uitgevoerd in andere clouds. U leert wanneer u globale VNet-peering, Virtual WAN, ExpressRoute Global Reach, site-naar-site-VPN en Azure Route Server gebruikt voor scenario's tussen regio's en meerdere clouds.

Wie heeft dit artikel nodig

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

  • Uw architectuur omvat meerdere Azure regio's en heeft privéconnectiviteit tussen deze regio's nodig.
  • U moet Azure workloads verbinden met AWS, Google Cloud of een ander extern netwerk.
  • U moet globale VNet-peering, Virtual WAN, ExpressRoute Global Reach, site-naar-site-VPN of Azure Route Server vergelijken.
  • U moet tolerante connectiviteit ontwerpen voor herstel na noodgevallen, wereldwijde uitbreiding of multicloudbewerkingen.

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.

Lift-and-shiftfocus: Neem dit artikel alleen op in uw leespad als uw migratie meerdere Azure-regio’s omvat of verbinding heeft met een andere cloud. De meeste lift-and-shift-projecten beginnen met één regio en voegen later connectiviteit tussen regio's toe wanneer herstel na noodgevallen of geografische uitbreiding een prioriteit wordt.

Moderniseringsfocus: Neem dit artikel op als voor uw modernisering expliciete privéconnectiviteit tussen regio's is vereist, buiten wat in het artikel voor meerdere regio's wordt besproken. U hebt deze richtlijnen nodig wanneer spokes in verschillende regio's directe communicatiepaden vereisen of wanneer uw actief-actieve implementatie privépeering nodig heeft tussen regionale hubs.

Focus op meerdere clouds: Dit artikel is uw centrale ontwerpbeslissing. Lees het voordat u kiest tussen hub-spoke en Virtual WAN voor uw architectuur voor doorvoer tussen clouds. U gebruikt dit artikel om uw bestaande multicloudtopologie te ontdekken, services toe te wijzen tussen AWS of Google Cloud en Azure en te definiëren hoe Azure verbinding maakt met workloads die tijdens de migratie in andere clouds blijven.

Azure services en functies

Azure biedt verschillende services voor connectiviteit tussen regio's en meerdere clouds. Elke service heeft betrekking op verschillende schaal-, bandbreedte- en beheervereisten.

Dienst Wat het biedt Wanneer gebruikt u het?
Globale VNet-peering Privéconnectiviteit met lage latentie tussen VNets in verschillende Azure regio's. Verkeer blijft op de Microsoft backbone. Bandbreedte wordt alleen beperkt door de SKU van de virtuele machine (VM), niet door een gateway. Directe communicatie tussen twee VNets in verschillende regio's zonder gatewayapparaat.
Azure Virtual WAN (Standard-laag) Door Microsoft beheerde wereldwijde transithub die VNets, vestigingen en externe gebruikers in alle regio's verbindt. Biedt transitieve routering tussen alle verbonden netwerken. Organisaties met veel regio's en filialen die een-op-een-connectiviteit nodig hebben zonder afzonderlijke peeringverbindingen te beheren.
ExpressRoute via Cloud Exchange Dedicated cross-cloud-verbinding via een externe exchangeprovider van derden (zoals Equinix of Megaport). Biedt een privéverbinding met hoge bandbreedte met AWS of Google Cloud. Architecturen met meerdere clouds met SLA-vereisten voor bandbreedte waarbij verkeer niet via het openbare internet mag gaan.
Site-to-site-VPN naar andere cloudomgevingen Versleutelde IPsec-tunnel tussen Azure VPN-gateway en de VPN-gateway van een andere cloudprovider (AWS Virtual Private Gateway of Google Cloud VPN). Multicloudconnectiviteit voor test-, ontwikkelings- of productiescenario's waarbij toegewezen circuits niet worden gerechtvaardigd.
Azure Route Server Hiermee kunt u dynamische BGP-routeuitwisseling tussen uw VNet en virtuele netwerkapparaten (NVA's) inschakelen. Injecteert NVA-geleerde routes in de Azure SDN-routeringsinfrastructuur. Aangepaste routering met NVA's van derden in een hub-VNet of complexe multicloudroutering waarvoor BGP-doorgifte is vereist voor Azure verbonden netwerken.

Hoe globale VNet-peering werkt

Globale VNet-peering maakt een directe koppeling tussen twee virtuele netwerken in verschillende Azure regio's. De koppeling loopt volledig over de Microsoft backbone en gaat nooit via het openbare internet. Nadat u een peeringrelatie hebt geconfigureerd, kunnen resources in elk VNet communiceren met behulp van privé-IP-adressen alsof ze zich in hetzelfde netwerk bevinden.

In tegenstelling tot gatewaygebaseerde benaderingen vormt peering geen centraal knelpunt. De bandbreedte tussen gekoppelde VNets is afhankelijk van de VM-SKU aan beide kanten. Er is geen toegewezen gatewayapparaat dat de doorvoer beperkt. Dit ontwerp maakt Global VNet-peering de optie met de laagste latentie voor communicatie tussen regio's tussen een klein aantal VNets.

Peering is echter standaard niet transitief. Als VNet A-peers met VNet B en VNet B-peers met VNet C zijn, kan verkeer van VNet A geen VNet C bereiken via VNet B. Voor elk paar VNets waarvoor directe communicatie nodig is, is een eigen peeringkoppeling vereist. In een hub-spoke-model betekent dit dat u de regionale hub-VNets doorgaans aan elkaar koppelt en door de gebruiker gedefinieerde routes (UDR's) of NVA's gebruikt om spoke-to-spoke-verkeer door te sturen tussen regio's via de hubs.

Virtual WAN wereldwijd transitverkeer

Azure Virtual WAN (Standard-laag) maakt het overbodig om peering tussen regionale hubs handmatig te configureren. Wanneer u Virtual WAN hubs in meerdere regio's uitrolt, brengt Microsoft automatisch hub-naar-hub-verbindingen via de backbone tot stand. Routes die in de ene hub zijn geleerd, worden doorgegeven aan alle andere hubs, waardoor een any-to-any transit-infrastructuur wordt gemaakt.

Deze automatische routering betekent dat een spoke-VNet dat is verbonden met een hub in VS - oost, een spoke-VNet kan bereiken dat is verbonden met een hub in Europa - west zonder extra peering- of routetabelconfiguratie. Virtual WAN breidt deze transitiviteit ook uit naar filialen (verbonden via site-naar-site-VPN of ExpressRoute) en externe gebruikers (verbonden via punt-naar-site-VPN). Het resultaat is een volledig verbonden, wereldwijd door Microsoft beheerd netwerk.

Schakel Routing Intent in op beveiligde virtuele hubs voor verkeersinspectie tussen regio's. Routing Intent leidt inter-hubverkeer via Azure Firewall, zodat u in alle regio's centraal inzicht en centrale handhaving van beleid hebt zonder in elke hub afzonderlijke NVA's uit te rollen en te beheren.

Hoe te kiezen

Gebruik de volgende beslissingstabellen om de juiste connectiviteitsbenadering voor uw scenario te selecteren.

Connectiviteitsopties tussen regio's

Diagram met connectiviteitspatronen tussen regio's, waaronder Wereldwijde VNet-peering, Virtual WAN hub-naar-hub-transit en VPN-paden tussen clouds.

Uw scenario Aanbevolen aanpak Waarom
Twee VNets in verschillende regio's hebben directe communicatie nodig Globale VNet-peering Laagste latentie ten opzichte van internetpaden, geen knelpunt voor gateways, eenvoudig te configureren. De bandbreedte is afhankelijk van de VM-SKU.
Veel regio's, veel vertakkingen, beheerde doorvoer nodig Azure Virtual WAN (Standard-laag) Biedt transitieve any-to-any-routering voor alle verbonden hubs. Microsoft beheert de routeringsinfrastructuur.
On-premises sites met elkaar verbinden via Azure ExpressRoute Global Reach Koppelt twee ExpressRoute-circuits, zodat on-premises verkeer de Microsoft backbone doorkruist. U hoeft geen hairpin te maken via Azure VNets.
Aangepaste routering of NVA’s van derden in een regionale hub Azure Route Server Maakt dynamische BGP-peering mogelijk tussen NVA's en Azure. Routes die door de NVA zijn aangeleerd, worden automatisch toegevoegd aan spoke-VNets.

Connectiviteitsopties voor meerdere clouds

Uw scenario Aanbevolen aanpak Waarom
Hoge bandbreedte en SLA vereist voor cross-cloudverkeer ExpressRoute via Cloud Exchange-provider Biedt toegewezen capaciteit met voorspelbare latentie. De exchange-provider verbindt uw ExpressRoute-circuit met de direct connect-service van de andere cloud.
Budgetbeperkte, voor testen bedoelde of laagdoorvoerwerkbelastingen Site-to-site-VPN Maakt gebruik van bestaande internetverbinding zonder circuitkosten. Geschikt wanneer bandbreedtevereisten bescheiden zijn.
Hybride plus multicloud (on-premises, Azure en een andere cloud) ExpressRoute Global Reach + Cloud Exchange Combineert Global Reach voor on-premises naar-Azure transit met een clouduitwisseling voor Azure-naar-andere-cloudconnectiviteit, waardoor een geïntegreerde privé-backbone ontstaat.

Ontwerpoverwegingen

Voor de meeste lift-and-shift-migraties is connectiviteit tussen regio's een toekomstige uitbreidingsoverweging in plaats van een dagelijkse vereiste. De eerste implementatie is waarschijnlijk gericht op één Azure regio.

Wanneer u van plan bent voor toekomstige uitbreiding:

  • Globale VNet-peering: Gebruik globale VNet-peering tussen regionale hub-VNets wanneer u een tweede Azure regio toevoegt. Deze benadering biedt u privéconnectiviteit met lage latentie zonder een gatewayapparaat te implementeren. Verkeer blijft op het Microsoft-backbone en schaalt mee met uw VM-SKU.
  • Uitgestelde complexiteit: Vermijd het implementeren van Virtual WAN of ExpressRoute Global Reach totdat uw estate meer dan twee regio's overschrijdt of als u vertakkingsconnectiviteitsvereisten toevoegt.
  • DR-voorbereiding: Zelfs als connectiviteit tussen regio's vandaag niet nodig is, documenteer welke workloads noodherstel vereisen en plan de peeringtopologie vooraf, zodat u deze snel kunt implementeren wanneer dat nodig is.

Uw gemoderniseerde architectuur maakt gebruik van actief-actieve implementaties in verschillende regio's. Peering tussen regio's maakt directe spoke-to-spoke-communicatie mogelijk wanneer uw toepassingslagen regionale grenzen omvatten.

Belangrijke ontwerpbeslissingen voor modernisering:

  • Interregionale peering voor actief-actief: Koppel de hub-VNets van uw primaire regio en back-upregio om bidirectionele verkeersstromen mogelijk te maken. Applicatieteams in de ContosoBiz- en ContosoCare-spokes kunnen resources in beide regio's bereiken via het hub-peeringpad.
  • Routeren via hubs: Aangezien globale VNet-peering niet-transitief is, routeert u spoke-verkeer tussen regio's via de regionale hub NVA of Azure Firewall. Gebruik door de gebruiker gedefinieerde routes (UDR's) om spoke-to-spoke-verkeer tussen regio's via de hubfirewall te leiden voor inspectie.
  • Selectieve peering: Niet alle spokes hebben connectiviteit tussen regio's nodig. Maak alleen peering met de hub-VNets en gebruik routepropagatie om specifieke spoke-VNets te bereiken die deelnemen aan actieve-actieve workloads.

In dit artikel ontwerpt u uw architectuur voor connectiviteit met meerdere clouds. Voordat u de Azure-infrastructuur plant, moet u eerst uw bestaande cloudtopologie in kaart brengen en services tussen providers in kaart brengen.

Cloudoverschrijdende detectiewerkstroom

  1. Ontdek uw bestaande topologie: Gebruik Workloaddetectie in AWS en Google Cloud Network Intelligence Center om uw huidige VPC-topologie (Virtual Private Cloud), peeringrelaties en verkeersstroompatronen toe te wijzen.
  2. Verkeersstromen identificeren: Documenteer VPC-naar-VPC-communicatie, inkomende en uitgaande internetpaden en vertakkings-naar-cloudverbindingen in uw AWS- of Google Cloud-omgeving.
  3. Koppel services aan Azure-equivalenten: De belangrijkste toewijzingen voor het connectiviteitsontwerp zijn:
AWS/ Google Cloud-service Equivalent van Azure
Transitgateway Azure Virtual WAN
VPC / VPC-netwerk Azure Virtueel Netwerk
Beveiligingsgroepen/firewallregels Netwerkbeveiligingsgroepen (NSG's)

Zie de controlelijst voor cross-clouddetectie voor volledige AWS-naar-Azure en Google Cloud-to-Azure-servicetoewijzingen.

Beslissingen over connectiviteitsarchitectuur

Nadat u de detectie en servicemapping hebt voltooid, bepaalt u het volgende:

  • Transitmodel: Kies Virtual WAN als u meerdere VPN's, vertakkingen, regio's of cloudranden hebt. Virtual WAN biedt het Azure equivalent van AWS Transit Gateway met beheerde any-to-any-routering.
  • VPN voor meerdere clouds: Implementeer VPN Gateway verbindingen van uw Virtual WAN hub (of hub-VNet) naar AWS Virtual Private Gateway en Google Cloud VPN. IPsec-tunnels gebruiken voor versleutelde communicatie tussen clouds.
  • Toepassingen die blijven: Identificeer workloads die tijdens de migratie in AWS of Google Cloud blijven. Deze workloads hebben permanente connectiviteit nodig via de cross-cloud VPN-tunnels totdat de migratie is voltooid.

Prerequisites

Voordat u connectiviteit tussen regio's of meerdere clouds implementeert, moet u de volgende vereisten controleren:

  • Twee of meer Azure regio's met geïmplementeerde VNets: uw workloads moeten al bestaan (of gepland) in meerdere regio's. Zie het artikel VNets en subnetten voor richtlijnen voor VNet-planning.
  • Hub-spoke of Virtual WAN topologie: ontwerpen voor meerdere regio's bouwen voort op een gevestigde topologie in elke regio. Zie het hub-spoke-artikel of het Virtual WAN-artikel.
  • ExpressRoute-circuits (voor Global Reach): Als u van plan bent om on-premises sites te verbinden, hebt u bestaande ExpressRoute-circuits op elke locatie nodig. Zie het artikel over hybride connectiviteit.
  • Toegang tot meerdere cloudaccounts: Voor VPN met meerdere clouds of exchange-connectiviteit hebt u beheerderstoegang nodig tot de netwerkconsole van de andere cloudprovider om de externe kant van de verbinding te configureren.

Beveiligingsoverwegingen

Connectiviteit tussen regio's en meerdere clouds introduceert specifieke beveiligingsproblemen die niet bestaan in implementaties in één regio.

Inspectie van verkeer in meerdere regio's

Globale VNet-peering is niet transitief. Verkeer tussen gepeerde VNets stroomt rechtstreeks zonder via een firewall of inspectiepunt te gaan. Als u verkeer tussen regio's wilt inspecteren, routeert u het via een virtueel netwerkapparaat (NVA) of Azure Firewall in elke regionale hub.

Schakel voor Virtual WAN routeringsintentie in op beveiligde virtuele hubs met privéverkeersbeleid. Routeringsintentie dwingt verkeer tussen hubs via door Azure Firewall Manager beheerde firewalls te lopen, wat gecentraliseerde inspectie van verkeer tussen regio's mogelijk maakt. Voor deze configuratie is de Standard-Virtual WAN-laag vereist.

Verbindingen tussen clouds versleutelen

Site-naar-site VPN-tunnels naar andere clouds worden standaard versleuteld (IPsec/IKE). ExpressRoute-verbindingen via een clouduitwisseling zijn echter privé, maar niet versleuteld op de netwerklaag. Als u versleuteling via ExpressRoute nodig hebt, implementeert u MACsec op ExpressRoute Direct-circuits of gebruikt u TLS-versleuteling op toepassingslaag.

Voor cross-cloudverkeer dat een clouduitwisseling doorkruist zonder VPN-overlay, kunt u overwegen een OP NVA gebaseerde IPsec-tunnel binnen het ExpressRoute-pad te implementeren. Met deze methode wordt versleuteling toegevoegd zonder de voordelen van bandbreedte en latentie van een toegewezen circuit op te geven. U kunt ook wederzijdse TLS (mTLS) op de toepassingslaag gebruiken, zodat elk service-eindpunt identiteit valideert en gegevens versleutelt, ongeacht het onderliggende transport. De keuze is afhankelijk van of u netwerklaagversleuteling (all-traffic) nodig hebt of versleuteling op de toepassingslaag kunt afdwingen.

Kostenoverwegingen

Voor alle connectiviteit tussen regio's worden kosten in rekening gebracht voor gegevensoverdracht. Wereldwijde VNet-peering, Virtual WAN-inter-hubverkeer en regio-overschrijdende VPN Gateway-tunnels maken allemaal gebruik van prijsstelling op basis van uitgaand verkeer. Tarieven variëren per zonepaar:

  • Intra-continental (bijvoorbeeld VS - oost naar VS - west): een lager tarief per GB, doorgaans binnen het bereik van de standaardtarieven voor uitgaand verkeer in de regio.
  • Inter-continental (bijvoorbeeld VS - oost naar Europa - west): hoger per GB-tarief vanwege langere backbone-afstanden en cross-continentale capaciteit.

Virtual WAN voegt kosten per verbindingseenheid toe voor elke spoke-VNet of vestiging die aan een hub is gekoppeld, plus kosten voor gegevensverwerking voor verkeer dat via een beveiligde hub loopt waarop Azure Firewall wordt uitgevoerd. Deze gelaagde prijsstructuur betekent dat Virtual WAN meer kan kosten dan eenvoudige Global VNet-peering voor architecturen met slechts een paar regio's en weinig aangesloten netwerken, maar het biedt gunstigere kostenefficiëntie per eenheid op schaal wanneer tientallen vestigingen en regio's worden verbonden.

Voor multicloudconnectiviteit via ExpressRoute via een cloudexchange zijn poorttarieven en cross-connecttarieven van de exchangeprovider verschuldigd, plus kosten voor Azure ExpressRoute-circuits en direct-connectkosten van de andere cloudprovider. Site-naar-site-VPN vermijdt circuitkosten, maar er worden nog steeds standaard uitgaande kosten in rekening gebracht voor gegevens die Azure verlaten.

Richtlijn: Plaats workloads met veel verkeer indien mogelijk in dezelfde regio. Reserveer paden tussen regio's voor synchronisatie van besturingsvlakken, asynchrone replicatie en failover voor herstel na noodgevallen, die doorgaans stromen met een lager volume zijn.

Patronen voor herstel na noodgevallen

Connectiviteit tussen regio's is fundamenteel voor herstel na noodgevallen (DR). Het patroon dat u kiest, bepaalt uw beoogde hersteltijd (RTO) en RPO (Recovery Point Objective).

Active-active

Beide regio's bedienen gelijktijdig productieverkeer. Een globale load balancer (zoals Azure Front Door of Azure Traffic Manager) verdeelt aanvragen over regio's. Als één regio uitvalt, verschuift het verkeer met minimale onderbreking naar de overlevende regio. Dit patroon levert de laagste RTO (seconden tot minuten), maar vereist volledige infrastructuur in beide regio's en bidirectionele gegevenssynchronisatie, waardoor de kosten en complexiteit toenemen.

Active-passive

Eén regio verwerkt productieverkeer, terwijl de tweede regio stand-by staat met vooraf uitgerolde (maar mogelijk afgeschaalde) infrastructuur. Met replicatie blijven de gegevens van de passieve regio actueel. Bij een storing promovt u de passieve regio en het omleiden van verkeer. RTO is afhankelijk van hoe snel u passieve resources omhoog schaalt en de failover van DNS of load balancer voltooit, meestal minuten tot tientallen minuten.

Pilootlicht

Een minimale aanwezigheid in de secundaire regio (databases replicerend, kernnetwerkinfrastructuur uitgerold) zonder actieve rekenresources. Bij failover implementeert of schaalt u de rekenkracht van toepassingen en schakelt u het verkeer over. Dit patroon minimaliseert de kosten in de stabiele toestand, maar verhoogt de RTO omdat rekenbronnen eerst moeten worden opgestart voordat de regio verkeer kan afhandelen.

In alle scenario's biedt interregionale connectiviteit (Global VNet Peering of Virtual WAN inter-hub) het privédatapad voor replicatieverkeer. Zorg ervoor dat uw DR-runbooks rekening houden met eventuele vertragingen in routepropagatie en controleer of de regels van de Network Security Group (NSG) in de secundaire regio failoververkeer toestaan.

Belangrijke beperkingen

Beperking Impact
Globale VNet-peering is niet transitief VNet A die is gekoppeld aan VNet B en VNet B die is gekoppeld aan VNet C, betekent niet dat A C kan bereiken. U moet A rechtstreeks koppelen aan C of een transitoplossing gebruiken, zoals Virtual WAN.
Virtual WAN Basic-laag ontbreekt transitiviteit Basic Virtual WAN biedt geen ondersteuning voor transitieve VNet-naar-VNet-connectiviteit. Gebruik de Standard-laag voor transit tussen regio's.
ExpressRoute Global Reach vereist Premium SKU voor geopolitieke verbindingen Voor circuits in verschillende geopolitieke regio's (bijvoorbeeld VS en Europa) is de Premium-invoegtoepassing vereist. Standaard-SKU-circuits maken alleen verbinding binnen dezelfde geopolitieke grens.
Actief-actief VPN Gateway aanbevolen voor AWS AWS Virtual Private Gateway maakt twee tunnels per VPN-verbinding. Configureer Azure VPN-gateway in de modus actief-actief om alle beschikbare tunnels te gebruiken en asymmetrische routering te voorkomen.

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:

Netwerken voor meerdere regio's: plan connectiviteit en failover voor meerdere regio's als uw migratie zich verder uitbreidt dan één regio.

Vervolgens in uw moderniseringstraject:

Netwerkbewaking en waarneembaarheid: schakel waarneembaarheid in verschillende regio's in voor productiegereedheid.

De volgende stap in uw cross-cloudtraject:

Virtual WAN topologie: gebruik Virtual WAN als de transithub voor uw multicloud- en multibranch-connectiviteit.

  • Last updated on