Designvägledning för nätverk i flera moln

Den här guiden innehåller en sekvenserad läsväg via designguiden för Azure nätverk för kunder som ansluter Azure till Amazon Web Services (AWS), Google Cloud eller migrerar arbetsbelastningar från en annan molnleverantör. Följ de numrerade stegen för att utforma säker och övervakad anslutning mellan Azure och din befintliga molninfrastruktur.

Varför upptäckt kommer först

Nätverk mellan moln ansluter Azure till en eller flera externa molnmiljöer. Du kan köra arbetsbelastningar i AWS eller Google Cloud som behöver privat anslutning till Azure tjänster, eller så kan du migrera program från ett annat moln till Azure samtidigt som du behåller anslutningen till program som finns kvar. Hur som helst måste ditt Azure-nätverk integreras med infrastruktur som du inte har fullständig kontroll över på andra sidan.

Den här läsvägen börjar med identifiering i stället för Azure infrastrukturdesign. Du mappar din befintliga topologi för flera moln först (förstå vad som körs var, hur den ansluter och vilken trafik som flödar mellan moln) innan du utformar Azure sidan. Den här upptäcktsbaserade metoden förhindrar omarbetning: om du designar nätverk i Azure utan att först förstå din AWS- eller Google Cloud-topologi riskerar du IP-adresskonflikter, anslutningsproblem och blinda fläckar i säkerheten.

Målarkitekturen använder Azure VIRTUAL Wide Area Network (WAN) som överföringshubb (Azure motsvarighet till AWS Transit Gateway) med IPSec VPN-tunnlar till AWS Virtual Private Gateway och Google Cloud VPN. Azure Firewall i en säker virtuell hubb inspekterar all trafik mellan moln och gren. DNS kräver noggrann planering av övergången för att säkerställa att namnupplösningen fungerar över molngränser under migreringen.

Förutsättningar

  • Läs Azure nätverksplan och designöversikt för orientering om tillgängliga Azure nätverkstjänster.
  • Fullständig topologiidentifiering av dina AWS- och Google Cloud-miljöer:
    • AWS: Kör AWS Migration Hub eller arbetsbelastningsidentifiering på AWS för att inventera virtuella privata moln (VPC), transitgatewayer och inter-VPC-anslutning.
    • Google Cloud: Använd Network Intelligence Center för att mappa VPC-nätverk, Cloud Interconnect-bilagor och brandväggsregler.
  • Dokumentera trafikflöden mellan moln: vilka program som kommunicerar mellan moln, nödvändig bandbredd, svarstidskänslighet och krypteringskrav.
  • Skapa en inventering av IP-adressintervall i alla tre molnen för att identifiera överlappningar.

Din lässökväg

Följande faser vägleder dig genom nätverksdesign mellan moln i följd.

Fas 1: Upptäcktsfasen

Börja med upptäckt. Förstå ditt landskap i flera moln innan du utformar Azure infrastruktur.

1. Anslutningar mellan regioner och flera moln

Den här artikeln är din centrala designbeslutspunkt. Mappa din topologi för flera moln: vilka virtuella AWS-datorer och virtuella Google Cloud-datorer som behöver anslutning till Azure, vilken trafik som flödar mellan moln och vilket arkitekturmönster som passar din skala. Använd tjänstmappningen mellan molnleverantörer (Transit Gateway till Virtual WAN, säkerhetsgrupper till nätverkssäkerhetsgrupper, VPC-peering till VNet-peering) för att översätta din befintliga design till Azure termer.

2. Azure Virtual WAN

Virtual WAN är den rekommenderade transitmodellen när du har flera VPC:er, filialer, regioner eller molnkanter. Virtual WAN tillhandahåller Azure motsvarigheten till AWS Transit Gateway: automatiserad routning, centraliserad säkerhet och multibranch-/multiregionskala. Utvärdera om din multimolnmiljö motiverar Virtual WAN eller om en enklare hub-and-spoke-topologi med VPN Gateway är tillräcklig.

Fas 2: Grundläggande

3. Virtuella nätverk och undernät

Utforma ditt Azure virtuella nätverk som landningszon för migrerade eller anslutna arbetsbelastningar. Mappa från begreppen AWS VPC och Google Cloud VPC: VPC-undernät blir Azure undernät, tillgänglighetszoner mappas till Azure tillgänglighetszoner och routningstabeller följer liknande mönster. Fokusera på storlek på undernät för de arbetsbelastningar som hamnar i Azure.

4. Planering av IP-adresser

Planera icke-överlappande adressutrymme i alla tre molnen. Det här steget är viktigt för anslutningar mellan moln: om dina Azure VNet-intervall överlappar AWS VPC-intervall eller Google Cloud VPC-intervall kan du inte upprätta VPN-tunnlar mellan dem. Dokumentera varje CIDR-block som används i alla miljöer innan du allokerar Azure adressutrymme.

5. Nätverkssäkerhetsgrupper och programsäkerhetsgrupper

Spegla dina AWS-säkerhetsgrupper och Google Cloud-brandväggsregler som Azure nätverkssäkerhetsgrupper (NSG:er). Översätt dina befintliga regler för tillåt och neka till NSG-format. Använd Programsäkerhetsgrupper (ASG: er) för att replikera den taggbaserade gruppering som AWS-säkerhetsgruppens referenser anger.

Fas 3: Anslutning

6. Hybridanslutning

Konfigurera IPSec VPN-tunnlar mellan Azure och AWS eller Google Cloud för krypterad överföring mellan moln. Anslut Azure VPN Gateway (eller Virtual WAN VPN-anslutningar) till AWS Virtual Private Gateway och Google Cloud VPN. Välj tunnelbandbredd baserat på dina trafikbehov mellan moln. Planera för redundanta tunnlar för att undvika enskilda felpunkter.

Fas 4: Säkerhet

7. DNS-säkerhet och matchning av privata namn

Planera din strategi för DNS-övergången innan du migrerar arbetslaster. Program i AWS eller Google Cloud löser värdnamn som kan behöva peka på Azure efter migreringen. Konfigurera Azure DNS private resolver med utgående slutpunkter för namnmatchning mellan moln. Se checklistan för DNS-övergång senare i den här artikeln för stegvis vägledning om migrering.

8. Azure Firewall

Distribuera Azure Firewall i en säker virtuell hubb för att inspektera all trafik mellan moln och gren. Varje paket som passerar mellan Azure och AWS eller Google Cloud passerar genom brandväggen för loggning och principtillämpning. Använd nätverksregler för trafikmönster mellan moln och filtrering av hotinformation för att blockera kända skadliga mål.

Fas 5: Åtgärder

9. Nätverksövervakning och observerbarhet

Det är svårare att felsöka miljöer över flera moln eftersom du inte har kontroll över båda ändarna av varje anslutning. Aktivera Azure Network Watcher för anslutningstestning, VPN-tunneldiagnostik och paketinsamling. Övervaka tunnelupptid, svarstid mellan moln och dataflöde mot dina kapacitetskrav. Ange aviseringar för tunnelfrånkopplingar som påverkar programtillgängligheten mellan moln.

Villkorsstyrda artiklar

Inkludera dessa artiklar baserat på dina specifika krav:

Tillstånd Artikel När ska inkluderas
Publik applikation Internetingress Ditt migrerade program är internetuppkopplad (direkt offentlig åtkomst krävs)
HTTP/HTTPS-applikation Brandvägg för webbprogram Layer 7 WAF behövs för offentliga webbprogram
Layer 7-distribution krävs Leverans och prestanda för program Du behöver global eller regional trafikdistribution efter migreringen
Offentliga slutpunkter DDoS-skydd Du har krav på upptid för tjänster som är riktade mot allmänheten
Nav-och-eker-modell föredras Central- och nodtopologi Din multicloud-miljö är för liten för att motivera Virtual WAN
Azure i flera regioner Nätverk i flera regioner Ditt Azure mål sträcker sig över flera regioner utanför anslutningen mellan moln
Administratörsåtkomst för virtuell dator Utvecklar- och administratörsåtkomst Du behöver säker RDP/SSH-åtkomst till Azure värdbaserade virtuella datorer
Centraliserad utgående trafik Utgående internetåtkomst En centraliserad princip för utgående internettrafik är en del av din målarkitektur
Omfattande VNet-miljö Centraliserad nätverkshantering Azure-sidan utvecklas till en styrd miljö med flera prenumerationer
Privata PaaS-slutpunkter Privat åtkomst till PaaS Målarkitekturen innehåller Azure PaaS-tjänster med privata slutpunkter

Checklista för identifiering i flera moln

Innan du utformar Azure nätverk ska du mappa dina befintliga molntjänster till Azure motsvarigheter. Den här mappningen påskyndar designbesluten och förhindrar felaktiga förväntningar.

AWS till Azure tjänstmappning

AWS-tjänst Motsvarande Azure Noteringar
Överföringsgateway Azure Virtual WAN Centraliserad routningshubb för multi-VPC, flera regioner, multimoln
VPC Virtuellt Azure-nätverk Isolerad nätverksgräns med undernät och routningstabeller
VPC-peering VNet-peering Direktanslutning mellan två virtuella nätverk
Säkerhetsgrupper Nätverkssäkerhetsgrupper (NSG:er) Trafikfiltrering med tillstånd på undernäts- eller nätverksgränssnittsnivå
Nätverks-ACL:er NSG:er (undernätsnivå) Azure NSG:er kombinerar både säkerhetsgrupps- och NACL-funktioner
Virtuell privatgateway VPN-gateway IPSec VPN-avslutningspunkt
Direkt anslutning Azure ExpressRoute Dedikerad privat anslutning (inte via offentligt Internet)
Route 53 privata hostade zoner Azure privata DNS-zoner Privat DNS-namnupplösning inom virtuella nätverk
Routetabeller Användardefinierade vägar (UDR) Anpassad routning för att åsidosätta Azure systemvägar eller AWS-underförstådda vägar
Elastic Load Balancer (ALB/NLB) Azure Load Balancer/Application Gateway L4- och L7-belastningsutjämning; Application Gateway tillhandahåller WAF-funktioner som liknar AWS ALB med AWS WAF
AWS WAF Brandvägg för Azure-webbaserade program Layer 7 HTTP/HTTPS-skydd
Nätverksbrandvägg Azure Firewall Tillståndsbaserad nätverksbrandvägg med hotunderrättelser

Google Cloud till Azure tjänstmappning

Google Cloud-tjänsten Motsvarande Azure Noteringar
VPC-nätverk Virtuellt Azure-nätverk Global resurs i Google Cloud; regional i Azure (använd VNet-peering för flera regioner)
Cloud Interconnect Azure ExpressRoute Dedikerad privat anslutning
VPN i molnet VPN-gateway IPSec VPN-tunnlar
Nat i molnet Azure NAT-gateway Utgående Internetåtkomst för privata resurser
Cloud Router Azure Route Server Dynamiskt utbyte av BGP-rutter med virtuella nätverksenheter
Cloud Armor Brandvägg för Azure-webbaserade program Layer 7 DDoS och programskydd
Brandväggsregler Nätverkssäkerhetsgrupper Trafikfiltrering (Google Cloud-regler är globala; Azure NSG:er är per undernät eller per nätverkskort)
Privata DNS-zoner i molnet Azure privata DNS-zoner Lösning av privata namn i nätverk
Centrum för nätverksintelligens Azure Network Watcher Nätverksövervakning, diagnostik och topologivisualisering

Checklista för DNS-övergång

DNS-omläggning är det mest riskfyllda steget vid migrering mellan moln. Följ den här checklistan för att minimera lösningsfel under övergången.

Före migreringen

  1. Lägre TTL-värden (Time to Live) för alla DNS-poster som ändras. Ange TTL till 60–300 sekunder minst 48 timmar före cutover. Det här steget säkerställer att cacheminnen upphör att gälla snabbt när du uppdaterar poster.
  2. Dokumentera varje DNS-post som pekar på infrastruktur som du migrerar: En post för servrar, CNAME-poster för tjänster, MX-poster för e-post och SRV-poster för tjänstidentifiering.
  3. Konfigurera Azure DNS private resolver med utgående slutpunkter i ditt Azure virtuella nätverk. Den här resolvern vidarebefordrar förfrågningar för hostade zoner på AWS/Google Cloud till lämpliga uppströms-DNS-servrar under samexistensperioden.
  4. Testa framåtriktad och omvänd namnupplösning från Azure-VNet till namn som finns i AWS eller Google Cloud innan några arbetsbelastningar migreras.

Under migreringen

  1. Uppdatera CNAME-poster för tjänster som flyttas till Azure. Peka CNAMEs till Azure Front Door, Azure Traffic Manager eller Azure Application Gateway slutpunkter när varje tjänst migreras.
  2. Uppdatera värd-A-poster för enskilda servrar som migreras. Ersätt IP-adresserna för AWS eller Google Cloud med Azure privata IP-adresser i dina DNS-zoner.
  3. Håll villkorlig vidarebefordring aktiv så att namn i zoner som du ännu inte har migrerat fortsätter att lösas upp via den ursprungliga molnleverantörens DNS-servrar.

Efter migreringen

  1. Kontrollera lösningen från alla platser: lokala klienter, Azure virtuella nätverk och eventuella återstående AWS- eller Google Cloud-arbetsbelastningar måste matcha de migrerade namnen korrekt.
  2. Höj TTL-värden tillbaka till produktionsnivåerna (3 600 sekunder eller senare) när du har bekräftat en stabil upplösning.
  3. Ta bort villkorliga vidarebefordrare för zoner som migreras helt till Azure DNS. Behåll endast vidarebefordrare för zoner som finns kvar i AWS eller Google Cloud.

Det du har skapat

Genom att följa den här läsvägen anslöt du Azure till din befintliga AWS- eller Google Cloud-miljö med krypterad överföring, centraliserad brandväggskontroll och övervakad anslutning. Din design omfattar:

  • Identifiering av topologi för flera moln och tjänstmappning
  • Virtual WAN eller transitnätverksarkitektur med nav-och-ekrar
  • IPSec VPN-tunnlar till AWS och Google Cloud
  • Azure Firewall för trafikkontroll mellan moln
  • DNS-omkoppling med Private Resolver för namnupplösning mellan molnmiljöer
  • Network Watcher övervakning för tunnelhälsa och prestanda

Nästa steg

  • Last updated on