Anslutningar mellan regioner och flera moln

Den här artikeln hjälper dig att ansluta Azure arbetsbelastningar i flera regioner och utöka anslutningen till andra molnleverantörer som Amazon Web Services (AWS) och Google Cloud.

Vad den här artikeln beskriver

Den här artikeln beskriver designbesluten för att ansluta Azure virtuella nätverk (VNet) mellan regioner och upprätta nätverksvägar till arbetsbelastningar som körs i andra moln. Du lär dig när du ska använda Global VNet-peering, Virtual WAN, ExpressRoute Global Reach, plats-till-plats-VPN och Azure Route Server för scenarier mellan regioner och flera moln.

Vem behöver den här artikeln

Läs den här artikeln om ett eller flera av dessa villkor gäller:

  • Din arkitektur sträcker sig över flera Azure regioner och behöver privata anslutningar mellan dem.
  • Du måste ansluta Azure arbetsbelastningar till AWS, Google Cloud eller ett annat externt nätverk.
  • Du måste jämföra global VNet-peering, Virtual WAN, ExpressRoute Global Reach, plats-till-plats-VPN eller Azure Route Server.
  • Du måste utforma elastiska anslutningar för haveriberedskap, global expansion eller åtgärder med flera moln.

Tip

Följer du en scenarioväg? Välj ditt scenario överst på sidan för skräddarsydd vägledning. Den grundläggande vägledningen som följer gäller för alla läsare.

Lift-and-shift-fokus: Inkludera den här artikeln i din läsväg endast om migreringen sträcker sig över flera Azure-regioner eller omfattar anslutning till ett annat moln. De flesta lift-and-shift-projekt börjar med en enda region och lägger till anslutningar mellan regioner senare när haveriberedskap eller geografisk expansion prioriteras.

Moderniseringsfokus: Ta med den här artikeln om moderniseringen kräver explicita privata anslutningar mellan regioner utöver vad artikeln om flera regioner omfattar. Du behöver den här vägledningen när ekrar i olika regioner kräver direkta kommunikationsvägar eller när din aktiva-aktiva distribution behöver privat peering mellan regionala hubbar.

Fokus mellan moln: Den här artikeln är ditt centrala designbeslut. Läs den innan du väljer mellan hub-spoke och Virtual WAN för din transitarkitektur mellan moln. Du använder den här artikeln för att identifiera din befintliga topologi för flera moln, mappa tjänster mellan AWS eller Google Cloud och Azure och definiera hur Azure ansluter till arbetsbelastningar som finns kvar i andra moln under migreringen.

Azure tjänster och funktioner

Azure tillhandahåller flera tjänster för anslutningar mellan regioner och flera moln. Varje tjänst hanterar olika skalnings-, bandbredds- och hanteringskrav.

Service Vad det ger När du ska använda detta
Global VNet-Peering Privat anslutning med låg fördröjning mellan virtuella nätverk i olika Azure regioner. Trafiken ligger kvar på Microsoft stamnät. Bandbredden begränsas endast av SKU:n för den virtuella datorn (VM), inte av en gateway. Direktkommunikation mellan två VNets i olika regioner utan en gatewayenhet.
Azure Virtual WAN (standardnivå) Microsoft-hanterad global transithubb som förbinder VNets, filialer och fjärranvändare i alla regioner. Tillhandahåller transitiv routning mellan alla anslutna nätverk. Organisationer med många regioner och filialkontor som behöver alla-till-alla-anslutning utan att behöva hantera enskilda peeringanslutningar.
ExpressRoute via Cloud Exchange Dedikerad anslutning mellan moln via en tredjepartsutbytesleverantör (till exempel Equinix eller Megaport). Tillhandahåller privat anslutning med hög bandbredd till AWS eller Google Cloud. Arkitekturer med flera moln med krav på bandbredds-SLA där trafiken inte får passera det offentliga Internet.
Plats-till-plats-VPN till andra moln Krypterad IPsec-tunnel mellan Azure VPN Gateway och en annan molnleverantörs VPN-gateway (AWS Virtual Private Gateway eller Google Cloud VPN). Multimolnanslutning för testning, utveckling eller produktionsscenarier där dedikerade kretsar inte är motiverade.
Azure Route Server Aktiverar dynamiskt BGP-vägutbyte mellan ditt virtuella nätverk och virtuella nätverksinstallationer (NVA). Infogar rutter som lärts in av NVA i Azure SDN-routningsinfrastrukturen. Anpassad routning med nva:er från tredje part i ett virtuellt hubbnätverk eller komplex routning av flera moln som kräver BGP-spridning till Azure anslutna nätverk.

Så här fungerar global VNet-peering

Global VNet-peering skapar en direktlänk mellan två virtuella nätverk i olika Azure regioner. Länken körs helt över Microsoft stamnät och passerar aldrig det offentliga Internet. När du har konfigurerat en peeringrelation kan resurser i varje virtuellt nätverk kommunicera med hjälp av privata IP-adresser som om de fanns i samma nätverk.

Till skillnad från gateway-baserade metoder skapar peering inte en enskild flaskhals. Bandbredden mellan peer-kopplade virtuella nätverk beror på VM-SKU:n på varje sida. Det finns ingen dedikerad gatewayinstallation som begränsar dataflödet. Den här designen gör Global VNet-peering till alternativet med lägsta svarstid för kommunikation mellan regioner mellan ett litet antal virtuella nätverk.

Peering är dock avsiktligen inte transitiv. Om VNet A peeras med VNet B och VNet B peeras med VNet C, kan trafik från VNet A inte nå VNet C genom VNet B. Varje VNet-par som behöver direkt kommunikation kräver en egen peeringlänk. I en hub-spoke-modell innebär det att du vanligtvis peerkopplar de regionala virtuella hubbnätverken till varandra och använder användardefinierade vägar (UDR) eller NVA:er för att vidarebefordra eker-till-eker-trafik mellan regioner via hubbarna.

Virtual WAN global överföring

Azure Virtual WAN (standardnivå) tar bort behovet av att manuellt konfigurera peering mellan regionala hubbar. När du distribuerar Virtual WAN hubbar i flera regioner etablerar Microsoft automatiskt hub-to-hub-anslutningar via stamnätet. Rutter som har lärts in på en hubb sprids till alla andra hubbar och skapar ett transitnät med full anslutning mellan alla hubbar.

Den här automatiska routningen innebär att ett spoke-VNet som är anslutet till en hubb i östra USA kan nå ett spoke-VNet som är anslutet till en hubb i Västeuropa utan någon ytterligare konfiguration av peering eller routningstabeller. Virtual WAN utökar också den här transitiviteten till avdelningskontor (anslutna via plats-till-plats-VPN eller ExpressRoute) och fjärranvändare (anslutna via punkt-till-plats-VPN). Resultatet är ett fullständigt sammankopplat globalt Microsoft hanterat nätverk.

För trafikkontroll mellan regioner aktiverar du Routningssyfte på skyddade virtuella hubbar. Routing Intent tvingar trafik mellan hubbar via Azure Firewall, vilket ger dig centraliserad insyn och centraliserat framtvingande av principer i alla regioner utan att du behöver driftsätta och hantera enskilda NVA:er i varje hubb.

Så här väljer du

Använd följande beslutstabeller för att välja rätt anslutningsmetod för ditt scenario.

Anslutningsalternativ mellan regioner

Diagram som visar anslutningsmönster mellan regioner, inklusive global VNet-peering, Virtual WAN hub-to-hub-överföring och VPN-sökvägar mellan moln.

Ditt scenario Rekommenderat tillvägagångssätt Varför
Två virtuella nätverk i olika regioner behöver direkt kommunikation Global VNet-Peering Lägst latens jämfört med internetvägar, ingen flaskhals i gatewayen, enkelt att konfigurera. Bandbredden beror på VM-SKU.
Många regioner, många filialer, hanterad transit behövs Azure Virtual WAN (standardnivå) Möjliggör transitiv routning mellan valfria noder via alla anslutna hubbar. Microsoft hanterar routningsinfrastrukturen.
Ansluta lokala platser till varandra via Azure ExpressRoute Global Reach Länkar två ExpressRoute-kretsar så att lokal trafik passerar Microsoft stamnätet. Du behöver inte dirigera trafiken omvägen via Azures virtuella nätverk.
Anpassad routning eller NVA från tredje part i en regional hubb Azure Route Server Aktiverar dynamisk BGP-peering mellan NVA:er och Azure. Rutter som NVA:n har lärt sig injiceras automatiskt i spoke-VNet.

Anslutningsalternativ för flera moln

Ditt scenario Rekommenderat tillvägagångssätt Varför
Hög bandbredd och serviceavtal som krävs för trafik mellan moln ExpressRoute via Cloud Exchange-provider Ger dedikerad kapacitet med förutsägbar svarstid. Exchange-providern ansluter din ExpressRoute-krets till det andra molnets direktanslutningstjänst.
Budgetbegränsade arbetsbelastningar, testning eller arbetsbelastningar med lågt dataflöde VPN från plats till plats Använder befintlig Internetanslutning utan kretskostnader. Lämplig när bandbreddskraven är blygsamma.
Hybrid plus flera moln (lokalt, Azure och ett annat moln) ExpressRoute Global Reach + Cloud Exchange Kombinerar Global Reach för trafik mellan lokala miljöer och Azure med en molnväxel för anslutning mellan Azure och andra moln, vilket skapar ett enhetligt privat stamnät.

Designöverväganden

För de flesta lift-and-shift-migreringar är anslutning mellan regioner en fråga för framtida expansion i stället för ett krav från dag ett. Den första distributionen är sannolikt avsedd för en enda Azure region.

När du planerar för framtida expansion:

  • Global VNet-peering: Använd global VNet-peering mellan regionala virtuella hubbnätverk när du lägger till en andra Azure region. Den här metoden ger dig privata anslutningar med låg fördröjning utan att distribuera en gatewayinstallation. Trafiken går via Microsofts stamnät och skalar utifrån din VM-SKU.
  • Uppskjuten komplexitet: Undvik att distribuera Virtual WAN eller ExpressRoute Global Reach tills din egendom växer bortom två regioner eller du lägger till krav för grenanslutning.
  • DR-förberedelse: Även om anslutningar mellan regioner inte behövs i dag kan du dokumentera vilka arbetsbelastningar som kräver haveriberedskap och planera peeringtopologin i förväg så att du kan distribuera den snabbt när det behövs.

Din moderniserade arkitektur använder driftsättningar i aktiv-aktiv-läge över flera regioner. Peering mellan regioner möjliggör direkt spoke-till-spoke-kommunikation när dina applikationsskikt sträcker sig över regionala gränser.

Viktiga designbeslut för modernisering:

  • Peering mellan regioner för aktiv-aktiv: Anslut hubb-VNeten i din primära region och din sekundära region med peering för att möjliggöra dubbelriktat trafikflöde. Applikationsteam i ContosoBiz- och ContosoCare-spokarna kan nå resurser i båda regionerna via hubbens peeringväg.
  • Dirigering via hubbar: Eftersom global VNet-peering inte är transitiv, ska spoke-trafik mellan regioner dirigeras via den regionala hubbens NVA eller Azure Firewall. Använd användardefinierade vägar (UDR) för att dirigera eker-till-ekertrafik mellan regioner via hubbens brandvägg för inspektion.
  • Selektiv peering: Alla ekrar behöver inte anslutningar mellan regioner. Peera endast hubb-VNeten och använd routspridning för att nå specifika eker-VNet som deltar i aktiv-aktiva arbetsbelastningar.

I den här artikeln utformar du arkitekturen för flera molnanslutningar. Innan du planerar Azure infrastruktur måste du identifiera din befintliga molntopologi och mappa tjänster mellan leverantörer.

Arbetsflöde för upptäckt över flera moln

  1. Identifiera din befintliga topologi: Använd arbetsbelastningsidentifiering på AWS och Google Cloud Network Intelligence Center för att mappa din aktuella VPC-topologi (Virtual Private Cloud), peering-relationer och trafikflödesmönster.
  2. Identifiera trafikflöden: Dokumentera VPC-till-VPC-kommunikation, inkommande och utgående internetvägar och anslutningar från gren till moln i din AWS- eller Google Cloud-miljö.
  3. Mappa tjänster till Azure motsvarigheter: Nyckelmappningar för anslutningsdesign är:
AWS/Google Cloud-tjänsten Motsvarande Azure
Överföringsgateway Azure Virtual WAN
VPC / VPC-nätverk Virtuellt Azure-nätverk
Säkerhetsgrupper/brandväggsregler Nätverkssäkerhetsgrupper (NSG:er)

Fullständiga AWS-till-Azure- och Google Cloud-to-Azure-tjänstmappningar finns i Checklista för identifiering mellan moln.

Beslut om anslutningsarkitektur

När du har slutfört identifieringen och tjänstmappningen bestämmer du:

  • Överföringsmodell: Välj Virtual WAN om du har flera virtuella datorer, grenar, regioner eller molnkanter. Virtual WAN tillhandahåller Azure-motsvarigheten till AWS Transit Gateway med hanterad valfri-till-valfri-routning.
  • Molnöverskridande VPN: Upprätta VPN Gateway-anslutningar från din Virtual WAN-hubb (eller hubb-VNet) till AWS Virtual Private Gateway och Google Cloud VPN. Använd IPsec-tunnlar för krypterad kommunikation mellan moln.
  • Program som finns kvar: Identifiera arbetsbelastningar som finns kvar i AWS eller Google Cloud under migreringen. Dessa arbetsbelastningar behöver beständig anslutning via VPN-tunnlar mellan moln tills migreringen har slutförts.

Förutsättningar

Kontrollera följande krav innan du implementerar anslutningar mellan regioner eller flera moln:

  • Två eller flera Azure regioner med distribuerade virtuella nätverk: Dina arbetsbelastningar måste redan finnas (eller planeras) i flera regioner. Se artikeln om VNet och undernät för planeringsvägledning för virtuella nätverk.
  • Topologi för hub-spoke eller Virtual WAN: Design mellan regioner bygger på en etablerad topologi i varje region. Se artikeln om hub-spoke eller artikeln om Virtual WAN.
  • ExpressRoute-kretsar (för Global Reach): Om du planerar att ansluta till lokala platser behöver du befintliga ExpressRoute-kretsar på varje plats. Se artikeln om hybridanslutning.
  • Åtkomst till konton mellan moln: För vpn- eller exchangeanslutningar i flera moln behöver du administrativ åtkomst till den andra molnleverantörens nätverkskonsol för att konfigurera fjärrsidan av anslutningen.

Säkerhetsfrågor

Anslutningar mellan regioner och flera moln medför specifika säkerhetsproblem som inte finns i distributioner med en enda region.

Trafikkontroll mellan regioner

Global VNet-peering är inte transitiv. Trafik mellan sammankopplade virtuella nätverk går direkt utan att passera genom en brandvägg eller inspektionspunkt. Om du behöver inspektera trafik mellan regioner dirigerar du den via en virtuell nätverksinstallation (NVA) eller Azure Firewall i varje regional hubb.

För Virtual WAN aktiverar du Routningssyfte med privata trafikprinciper på skyddade virtuella hubbar. Routing Intent tvingar trafik mellan hubbar genom Azure Firewall Manager-hanterade brandväggar, vilket ger centraliserad regionsövergripande trafikinspektion. Den här konfigurationen kräver standardnivån Virtual WAN.

Kryptera anslutningar mellan moln

VPN-tunnlar från plats till plats till andra moln krypteras som standard (IPsec/IKE). ExpressRoute-anslutningar via ett molnutbyte är dock privata men inte krypterade på nätverksskiktet. Om du behöver kryptering via ExpressRoute distribuerar du MACsec på ExpressRoute Direct-kretsar eller använder TLS-kryptering på programnivå.

För trafik mellan moln som passerar ett molnutbyte utan VPN-överlägg bör du överväga att distribuera en NVA-baserad IPsec-tunnel i ExpressRoute-sökvägen. Den här metoden lägger till kryptering utan att ge upp bandbredds- och svarstidsfördelarna med en dedikerad krets. Du kan också använda ömsesidig TLS (mTLS) på programnivån så att varje tjänstslutpunkt validerar identitet och krypterar data oavsett den underliggande transporten. Valet beror på om du behöver kryptering på nätverksnivå (all trafik) eller kan framtvinga kryptering på programnivå.

Kostnadsöverväganden

Alla anslutningar mellan regioner medför avgifter för dataöverföring. Global VNet-peering, Virtual WAN-trafik mellan hubbar och VPN Gateway-tunnlar mellan regioner använder alla utgående trafikbaserad prissättning. Priserna varierar beroende på zonpar:

  • Inom samma kontinent (till exempel Östra USA till Västra USA): Lägre pris per GB, vanligtvis i nivå med standardpriser för utgående dataöverföring i regionen.
  • Interkontinentalt (till exempel östra USA till Västeuropa): Högre pris per GB på grund av längre avstånd i stamnätet och interkontinental kapacitet.

Virtual WAN medför en avgift per anslutning för varje spoke-VNet eller filial som är anslutet till en hubb, plus en databehandlingsavgift för trafik som transiterar genom en skyddad hubb som kör Azure Firewall. Den här skiktade prissättningen innebär att Virtual WAN kan kosta mer än enkel global VNet-peering för arkitekturer med bara ett fåtal regioner och få ekrar, men det ger bättre enhetsekonomi i stor skala när dussintals grenar och regioner ansluter.

För anslutning till flera moln medför ExpressRoute via ett molnutbyte portavgifter och avgifter för korsanslutning från exchange-providern, plus Azure ExpressRoute kretsavgifter och det andra molnets direktanslutningsavgifter. Plats-till-plats-VPN undviker kretskostnader men ådrar sig fortfarande standardavgifter för utgående data för data som lämnar Azure.

Vägledning: Samlokalisera arbetsbelastningar med hög trafik i samma region när det är möjligt. Avsätt kommunikationsvägar mellan regioner för synkronisering av kontrollplanet, asynkron replikering och växling vid katastrofåterställning, vilka vanligtvis är flöden med lägre trafikvolym.

Haveriberedskapsmönster

Anslutningar mellan regioner är grundläggande för haveriberedskap (DR). Det mönster du väljer avgör ditt mål för återställningstid (RTO) och mål för återställningspunkter (RPO).

Active-active

Båda regionerna hanterar produktionstrafik samtidigt. En global lastbalanserare (till exempel Azure Front Door eller Azure Traffic Manager) distribuerar begäranden mellan regioner. Om en region misslyckas flyttas trafiken till den överlevande regionen med minimalt avbrott. Det här mönstret ger lägsta RTO (sekunder till minuter) men kräver fullständig infrastruktur i både regioner och dubbelriktad datasynkronisering, vilket ökar kostnaden och komplexiteten.

Active-passive

En region hanterar produktionstrafik medan den andra regionen förblir i vänteläge med fördistribuerad (men potentiellt nedskalad) infrastruktur. Replikeringen håller den passiva regionens data aktuella. Vid fel höjer du upp den passiva regionen och omdirigerar trafik. RTO beror på hur snabbt du skalar upp passiva resurser och slutför dns- eller lastbalanserarens redundans, vanligtvis minuter till tiotals minuter.

Pilotljus

Ett minimalt fotavtryck i den sekundära regionen (databaser som replikeras, kärnnätverk distribueras) utan aktiv beräkning. Vid redundans distribuerar eller skalar du programberäkning och växlar trafik. Detta mönster minimerar kostnaden i normalläge men ökar RTO eftersom beräkningsresurser måste startas upp innan regionen kan betjäna trafik.

I samtliga mönster tillhandahåller anslutning mellan regioner (Global VNet Peering eller hubb-till-hubb i Virtual WAN) den privata datavägen för replikeringstrafik. Se till att dina DR-runbooks tar hänsyn till eventuella fördröjningar i spridning av rutter och verifiera att Network Security Group-regler (NSG-regler) i den sekundära regionen tillåter failovertrafik.

Viktiga begränsningar

Begränsning Impact
Global VNet-peering är inte transitiv Att VNet A är peering-kopplat till VNet B och VNet B är peering-kopplat till VNet C betyder inte att A kan nå C. Du måste peering-koppla A direkt till C eller använda en transitlösning som Virtual WAN.
Virtual WAN Basic-nivån saknar transitivitet Basic Virtual WAN stöder inte transitiv anslutning från VNet till VNet. Använd Standard-nivån för överföring mellan regioner.
ExpressRoute Global Reach kräver Premium SKU:n för anslutningar över geopolitiska gränser Kretsar i olika geopolitiska regioner (till exempel USA och Europa) kräver Premium-tillägget. Standard-SKU-kretsar ansluter endast inom samma geopolitiska gräns.
Aktiv-aktiv VPN Gateway rekommenderas för AWS AWS Virtual Private Gateway skapar två tunnlar per VPN-anslutning. Konfigurera Azure VPN Gateway i aktivt-aktivt läge för att använda alla tillgängliga tunnlar och undvika asymmetrisk routning.

Learn more

Nästa steg

Tip

Utforska på egen hand? Gå tillbaka till översiktsnavigatorn för att hitta nästa artikel efter funktion.

Nästa steg i din lift-and-shift-resa:

Nätverk i flera regioner: Planera anslutning och redundansväxling i flera regioner om migreringen expanderar utanför en region.

Nästa steg i moderniseringsresan:

Nätverksövervakning och observerbarhet: Aktivera observerbarhet mellan regioner för produktionsberedskap.

Nästa steg i din molnöverskridande resa:

Virtual WAN topologi: Använd Virtual WAN som överföringshubb för din multimoln- och multibranchanslutning.

  • Last updated on