Ontwerppad voor netwerken in meerdere clouds

Deze handleiding biedt een stapsgewijs leestraject door de Azure Networking Design Guide voor klanten die Azure verbinden met Amazon Web Services (AWS) of Google Cloud, of workloads migreren vanaf een andere cloudprovider. Volg de genummerde stappen voor het ontwerpen van beveiligde, bewaakte connectiviteit tussen Azure en uw bestaande cloudinfrastructuur.

Waarom detectie het eerst komt

Netwerken tussen clouds verbinden Azure met een of meer externe cloudomgevingen. U kunt workloads uitvoeren in AWS of Google Cloud die privéconnectiviteit nodig hebben voor Azure services, of u kunt toepassingen van een andere cloud migreren naar Azure terwijl u verbinding houdt met toepassingen die achterblijven. In beide gevallen moet uw Azure netwerk worden geïntegreerd met de infrastructuur die u niet volledig aan de andere kant kunt beheren.

Dit leespad begint met detectie in plaats van Azure infrastructuurontwerp. U brengt eerst uw bestaande multicloudtopologie in kaart (zodat u begrijpt welke onderdelen waar draaien, hoe alles met elkaar is verbonden en welk verkeer er tussen clouds stroomt) voordat u de Azure-zijde ontwerpt. Deze detectie-eerste benadering voorkomt dat u opnieuw werkt: als u Azure netwerken ontwerpt zonder inzicht te krijgen in uw AWS- of Google Cloud-topologie, riskeert u conflicten met IP-adressen, connectiviteitsproblemen en beveiligingsblinde vlekken.

Uw doelarchitectuur maakt gebruik van Azure Virtual Wide Area Network (WAN) als de transit-hub (het Azure equivalent van AWS Transit Gateway) met IPSec VPN-tunnels naar AWS Virtual Private Gateway en Google Cloud VPN. Azure Firewall in een beveiligde virtuele hub inspecteert al het verkeer tussen clouds en vertakkingen. DNS vereist een zorgvuldige cutoverplanning om naamresolutie tijdens de migratie tussen clouds te laten functioneren.

Prerequisites

  • Lees het Azure netwerkplan en ontwerpoverzicht voor oriëntatie op beschikbare Azure netwerkservices.
  • Volledige topologiedetectie van uw AWS- en Google Cloud-omgevingen:
    • AWS: Voer AWS Migration Hub of Workload Discovery uit op AWS om virtuele privéclouds (VPN's), transitgateways en inter-VPC-connectiviteit te inventariseren.
    • Google Cloud: Gebruik Network Intelligence Center om VPC-netwerken, Cloud Interconnect-koppelingen en firewallregels in kaart te brengen.
  • Documenteer verkeersstromen tussen clouds: welke toepassingen communiceren tussen clouds, vereiste bandbreedte, latentiegevoeligheid en versleutelingsvereisten.
  • Maak een inventaris van IP-adresbereiken in alle drie de clouds om overlappingen te identificeren.

Uw leespad

De volgende fasen leiden u stapsgewijs door het ontwerp van meerdere cloudnetwerken.

Fase 1: Detectie

Begin met verkennen. Inzicht in uw landschap met meerdere clouds voordat u Azure infrastructuur ontwerpt.

1. Connectiviteit tussen regio's en meerdere clouds

Dit artikel is uw centrale ontwerpbeslissingspunt. Wijs uw topologie met meerdere clouds toe: welke AWS-VPN's en Google Cloud-VPN's connectiviteit nodig hebben met Azure, welk verkeer tussen clouds stroomt en welk architectuurpatroon past bij uw schaal. Gebruik de servicetoewijzing tussen cloudproviders (transitgateway naar Virtual WAN, beveiligingsgroepen naar netwerkbeveiligingsgroepen, VPC-peering naar VNet-peering) om uw bestaande ontwerp te vertalen in Azure termen.

2. Azure Virtual WAN

Virtual WAN is het aanbevolen transitmodel wanneer u meerdere VPN's, vertakkingen, regio's of cloudranden hebt. Virtual WAN biedt het Azure equivalent van AWS Transit Gateway: geautomatiseerde routering, gecentraliseerde beveiliging en schaal met meerdere regio's. Evalueer of uw overschrijdende cloudomgeving Virtual WAN rechtvaardigt of of een eenvoudigere hub-and-spoke met VPN Gateway voldoende is.

Fase 2: Basisbeginselen

3. Virtuele netwerken en subnetten

Ontwerp uw Azure VNet als landingszone voor gemigreerde of verbonden workloads. Kaart van AWS VPC- en Google Cloud VPC-concepten: VPC-subnetten worden Azure subnetten, beschikbaarheidszones worden toegewezen aan Azure beschikbaarheidszones en routetabellen volgen vergelijkbare patronen. Focus op de dimensionering van subnetten voor de workloads die in Azure worden geplaatst.

4. Planning van IP-adressen

Plan niet-overlappende adresruimte in alle drie de clouds. Deze stap is essentieel voor connectiviteit tussen clouds: als uw Azure VNet-bereiken overlappen met AWS-VPC-bereiken of Google Cloud VPC-bereiken, kunt u er geen VPN-tunnels tussen maken. Documenteer elk CIDR-blok dat in alle omgevingen wordt gebruikt voordat Azure adresruimte wordt toegewezen.

5. Netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen

Zet uw AWS-beveiligingsgroepen en Google Cloud-firewallregels om naar Azure-netwerkbeveiligingsgroepen (NSG's). Vertaal uw bestaande regels voor toestaan en weigeren in NSG-indeling. Gebruik ASG's (Application Security Groups) om de op tags gebaseerde groepering te repliceren die AWS-beveiligingsgroepverwijzingen bieden.

Fase 3: Connectiviteit

6. Hybride connectiviteit

Stel IPSec VPN-tunnels in tussen Azure en AWS of met Google Cloud voor versleuteld cross-cloudverkeer. Verbind Azure VPN-gateway (of Virtual WAN VPN-verbindingen) met AWS Virtual Private Gateway en Google Cloud VPN. Kies tunnelbandbreedte op basis van uw behoeften voor cross-cloudverkeer. Voorzie redundante tunnels om enkele uitvalpunten te voorkomen.

Fase 4: Beveiliging

7. DNS-beveiliging en privénaamomzetting

Stel uw DNS-omschakelstrategie op voordat u workloads gaat migreren. Toepassingen in AWS of Google Cloud lossen hostnamen op die mogelijk na de migratie moeten verwijzen naar Azure. Configureer Azure DNS Private Resolver met uitgaande eindpunten voor naamomzetting tussen cloudomgevingen. Zie de controlelijst voor DNS cutover verderop in dit artikel voor stapsgewijze migratierichtlijnen.

8. Azure Firewall

Implementeer Azure Firewall in een beveiligde virtuele hub om al het verkeer tussen clouds en vertakkingen te controleren. Elk pakket dat doorloopt tussen Azure en AWS of Google Cloud, doorloopt de firewall voor het afdwingen van logboekregistratie en beleid. Gebruik netwerkregels voor verkeerspatronen in meerdere clouds en filteren op bedreigingsinformatie om bekende schadelijke bestemmingen te blokkeren.

Fase 5: Bewerkingen

9. Netwerkbewaking en waarneembaarheid

Meerdere cloudomgevingen zijn moeilijker om problemen op te lossen, omdat u niet beide uiteinden van elke verbinding beheert. Schakel Azure Network Watcher in voor connectiviteitstests, diagnostische gegevens van VPN-tunnel en pakketopname. Bewaak de uptime van de tunnel, latentie tussen clouds en doorvoer op basis van uw capaciteitsvereisten. Stel waarschuwingen in voor tunnelonderbrekingen die van invloed zijn op de beschikbaarheid van applicaties over meerdere clouds heen.

Voorwaardelijke artikelen

Neem deze artikelen op basis van uw specifieke vereisten op:

Condition Artikel Wanneer moet ik opnemen?
Openbare toepassing Inkomend internetverkeer Uw gemigreerde toepassing is internetgericht (directe openbare toegang vereist)
HTTP/HTTPS-applicatie Firewall voor webapplicaties Laag 7 WAF is nodig voor openbare webtoepassingen
Laag 7-distributie nodig Levering en prestaties van toepassingen U hebt wereldwijde of regionale verkeersdistributie nodig na de migratie
Openbare eindpunten DDoS-beveiliging U hebt beschikbaarheidseisen voor publiek toegankelijke services
Voorkeur voor hub-and-spoke Hub-and-spoke-topologie Uw cross-cloud estate is klein genoeg dat Virtual WAN niet gerechtvaardigd is
Azure voor meerdere regio's Netwerken voor meerdere regio's Uw Azure doel omvat meerdere regio's buiten de connectiviteit tussen clouds
VM-beheerderstoegang Toegang voor ontwikkelaars en beheerders U hebt beveiligde RDP-/SSH-toegang nodig tot Azure gehoste VM's
Gecentraliseerd uitgaand verkeer Uitgaande internettoegang Gecentraliseerd beleid voor uitgaand internetverkeer maakt deel uit van uw doelontwerp
Grote VNet-omgeving Gecentraliseerd netwerkbeheer De Azure-omgeving groeit uit tot een goed beheerde multisubscriptionomgeving
Privé-eindpunten van PaaS Privétoegang van PaaS Uw doelarchitectuur bevat Azure PaaS-services met privé-eindpunten

Checklist voor cloudoverschrijdende detectie

Voordat u Azure netwerken ontwerpt, moet u uw bestaande cloudservices toewijzen aan Azure equivalenten. Deze afstemming versnelt ontwerpkeuzes en voorkomt verkeerde verwachtingen.

Toewijzing van AWS-services aan Azure-services

AWS-service Equivalent van Azure Aantekeningen
Transitgateway Azure Virtual WAN Gecentraliseerde routeringshub voor multi-VPC, multiregio, multicloud
VPC Azure Virtueel Netwerk Geïsoleerde netwerkgrens met subnetten en routetabellen
VPC-peering VNet-peering Directe connectiviteit tussen twee virtuele netwerken
Beveiligingsgroepen Netwerkbeveiligingsgroepen (NSG's) Statusafhankelijke verkeersfiltering op subnet- of netwerkinterfaceniveau
Netwerk-ACLs NSGs (op subnetniveau) Azure NSG's combineren zowel beveiligingsgroep- als NACL-functies
Virtuele privégateway VPN Gateway IPSec VPN-beëindigingspunt
Directe verbinding Azure ExpressRoute Toegewezen privéconnectiviteit (niet via openbaar internet)
Route 53 privé-gehoste zones Privé-DNS-zones van Azure Privé-DNS naamomzetting binnen virtuele netwerken
Routetabellen Door gebruikers gedefinieerde routes (UDR) Aangepaste routering om Azure systeemroutes of impliciete AWS-routes te overschrijven
Elastic Load Balancer (ALB/NLB) Azure Load Balancer/Application Gateway L4- en L7-taakverdeling; Application Gateway biedt WAF-mogelijkheden die vergelijkbaar zijn met AWS ALB met AWS WAF
AWS WAF Azure Web Application Firewall HTTP-/HTTPS-beveiliging op laag 7
Netwerkfirewall Azure Firewall Stateful netwerkfirewall met bedreigingsinformatie

Toewijzing van Google Cloud-services aan Azure-services

Google Cloudservice Equivalent van Azure Aantekeningen
VPC-netwerk Azure Virtueel Netwerk Wereldwijde resource in Google Cloud; regionaal in Azure (VNet-peering gebruiken voor meerdere regio's)
Cloudinterconnectie Azure ExpressRoute Toegewezen privéconnectiviteit
Cloud-VPN VPN Gateway IPSec VPN-tunnels
Cloud NAT Azure NAT-gateway Uitgaande internettoegang voor privébronnen
Cloudrouter Azure Route Server Dynamische BGP-routeuitwisseling met virtuele netwerkapparaten
Cloud Armor Azure Web Application Firewall DDoS- en toepassingsbeveiliging op laag 7
Firewallregels Netwerkbeveiligingsgroepen Verkeer filteren (Google Cloud-regels zijn globaal; Azure NSG's zijn per subnet of per NIC)
Privézones voor CLOUD-DNS Privé-DNS-zones van Azure Privénaamomzetting binnen netwerken
Centrum voor netwerkintelligentie Azure Network Watcher Visualisatie van netwerkbewaking, diagnostische gegevens en topologie

Controlelijst voor DNS-overschakeling

DNS cutover is de hoogste risicostap bij cross-cloudmigratie. Volg deze controlelijst om oplossingsfouten tijdens de overgang te minimaliseren.

Vóór de migratie

  1. Verlaag de TTL-waarden (Time to Live) voor alle DNS-records die wijzigen. Stel TTL in op 60-300 seconden ten minste 48 uur voor cutover. Deze stap zorgt ervoor dat caches snel verlopen wanneer u records bijwerkt.
  2. Documenteer elke DNS-record die verwijst naar de infrastructuur die u migreert: A-records voor servers, CNAME-records voor services, MX-records voor e-mail en SRV-records voor servicedetectie.
  3. Configureer de Azure DNS Private Resolver met outbound-eindpunten in uw Azure VNet. Deze resolver stuurt query's door voor AWS/Google Cloud gehoste zones naar de juiste upstream DNS-servers tijdens de co-existentieperiode.
  4. Test voorwaartse en omgekeerde naamomzetting van Azure VNets naar namen die worden gehost in AWS/Google Cloud voordat u workloads migreert.

Tijdens de migratie

  1. Werk CNAME-records bij voor services die worden verplaatst naar Azure. Wijs CNAME's naar Azure Front Door-, Azure Traffic Manager- of Azure Application Gateway-eindpunten naarmate elke service wordt gemigreerd.
  2. Werk host A-records bij voor afzonderlijke servers die worden gemigreerd. Vervang de IP-adressen van AWS of Google Cloud door Azure privé-IP-adressen in uw DNS-zones.
  3. Houd voorwaardelijke doorsturing actief zodat namen in zones die u nog niet hebt gemigreerd, via de DNS-servers van de oorspronkelijke cloud worden opgelost.

Na migratie

  1. Controleer de naamomzetting vanaf alle locaties: on-premises clients, Azure-VNets en eventuele resterende AWS- of Google Cloud-workloads moeten alle gemigreerde namen correct kunnen omzetten.
  2. Verhoog TTL-waarden terug naar productieniveaus (3.600 seconden of hoger) nadat u een stabiele resolutie hebt bevestigd.
  3. Verwijder voorwaardelijke doorstuurservers voor zones die volledig zijn gemigreerd naar Azure DNS. Gebruik forwarders alleen voor zones die in AWS of Google Cloud blijven.

Wat u hebt gebouwd

Door dit leespad te volgen, hebt u Azure verbonden met uw bestaande AWS- of Google Cloud-omgeving met versleutelde overdracht, gecentraliseerde firewallinspectie en bewaakte connectiviteit. Uw ontwerp omvat:

  • Detectie van multicloudtopologie en servicetoewijzing
  • Virtual WAN of hub-and-spoke-architectuur voor transit
  • IPSec VPN-tunnels naar AWS en Google Cloud
  • Azure Firewall voor inspectie van verkeer tussen clouds
  • DNS-omschakeling met Private Resolver voor cloudoverschrijdende naamresolutie
  • Network Watcher bewaking voor tunnelstatus en -prestaties

Volgende stappen 

  • Last updated on