Percorso di progettazione della rete tra cloud

Questa guida fornisce un percorso di lettura sequenziato tramite Azure Guida alla progettazione della rete per i clienti che si connettono Azure ad Amazon Web Services (AWS), Google Cloud o la migrazione di carichi di lavoro da un altro provider di servizi cloud. Seguire i passaggi numerati per progettare la connettività sicura e monitorata tra Azure e l'infrastruttura cloud esistente.

Perché la scoperta viene prima

La rete multi-cloud connette Azure a uno o più ambienti cloud esterni. È possibile eseguire carichi di lavoro in AWS o Google Cloud che necessitano di connettività privata per Azure servizi oppure è possibile eseguire la migrazione di applicazioni da un altro cloud a Azure mantenendo al tempo stesso la connettività alle applicazioni che rimangono in ritardo. In entrambi i casi, la rete Azure deve integrarsi con un'infrastruttura che non controlli completamente sul lato opposto.

Questo percorso di lettura inizia con la fase di individuazione anziché con la progettazione dell'infrastruttura di Azure. Prima di progettare il componente Azure, devi innanzitutto mappare la topologia multicloud esistente (capire quali carichi di lavoro vengono eseguiti e dove, come i vari ambienti sono collegati e quali flussi di traffico passano tra i diversi cloud). Questo approccio basato innanzitutto sull’analisi preliminare evita di dover rifare il lavoro: se si progetta la rete in Azure senza comprendere la topologia di AWS o di Google Cloud, si rischiano conflitti di indirizzi IP, lacune di connettività e zone d’ombra nella sicurezza.

L'architettura di destinazione usa Azure rete WAN (Virtual Wide Area Network) come hub di transito (l'equivalente Azure di AWS Transit Gateway) con tunnel VPN IPSec a AWS Virtual Private Gateway e Google Cloud VPN. Firewall di Azure in un hub virtuale sicuro controlla tutto il traffico tra cloud e rami. Il DNS richiede un'attenta pianificazione della fase di transizione per garantire la continuità della risoluzione dei nomi tra ambienti cloud durante la migrazione.

Prerequisiti

  • Per orientarsi tra i servizi di rete di Azure disponibili, vedere la panoramica sulla pianificazione e la progettazione della rete di Azure.
  • Completare l'individuazione della topologia degli ambienti AWS e Google Cloud:
    • AWS: eseguire l'hub di migrazione AWS o l'individuazione del carico di lavoro in AWS per l'inventario di cloud privati virtuali (VPC), gateway di transito e connettività tra VPC.
    • Google Cloud: usare il Centro intelligence di rete per eseguire il mapping di reti VPC, allegati di interconnessione cloud e regole del firewall.
  • Documentare i flussi di traffico tra cloud: le applicazioni che comunicano tra cloud, larghezza di banda necessaria, riservatezza della latenza e requisiti di crittografia.
  • Creare un inventario degli intervalli di indirizzi IP in tutti e tre i cloud per identificare le sovrapposizioni.

Percorso di lettura

Le seguenti fasi ti guidano, in ordine sequenziale, nella progettazione della rete multicloud.

Fase 1: individuazione

Iniziare con l'individuazione. Comprendi il tuo ambiente multicloud prima di progettare l'infrastruttura di Azure.

1. Connettività tra aree e multicloud

Questo articolo è il punto di riferimento centrale per le decisioni di progettazione. Eseguire il mapping della topologia multicloud: quali VPN AWS e VPN di Google Cloud necessitano di connettività per Azure, quali flussi di traffico tra cloud e quale modello di architettura si adatta alla scalabilità. Usare la mappatura dei servizi tra provider cloud (Transit Gateway in rete WAN virtuale, Security Groups in Network Security Groups, peering VPC in peering di reti virtuali) per tradurre il design esistente nella terminologia di Azure.

2. rete WAN virtuale di Azure

rete WAN virtuale è il modello di transito consigliato quando si dispone di più VPC, rami, aree o bordi cloud. rete WAN virtuale offre l'equivalente in Azure di AWS Transit Gateway: routing automatizzato, sicurezza centralizzata e scalabilità multisede e multiregione. Valuta se il tuo ambiente multi-cloud giustifica il rete WAN virtuale o se è sufficiente un'architettura hub-and-spoke più semplice con Gateway VPN.

Fase 2: Fondamenti

3. Reti virtuali e subnet

Progettare la rete virtuale Azure come zona di destinazione per i carichi di lavoro migrati o connessi. Eseguire la mappatura dai concetti di AWS VPC e Google Cloud VPC: le subnet VPC diventano subnet di Azure, le zone di disponibilità corrispondono alle zone di disponibilità di Azure e le tabelle di routing seguono modelli simili. Concentrarsi sul dimensionamento delle subnet per i carichi di lavoro che si trovano in Azure.

4. Pianificazione degli indirizzi IP

Pianificare uno spazio di indirizzamento senza sovrapposizioni tra tutti e tre i cloud. Questo passaggio è fondamentale per la connettività tra cloud: se gli intervalli di reti virtuali Azure si sovrappongono agli intervalli VPC AWS o agli intervalli VPC di Google Cloud, non è possibile stabilire tunnel VPN tra di essi. Documenta ogni blocco CIDR in uso in tutti gli ambienti prima di allocare lo spazio di indirizzamento di Azure.

5. Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni

Rispecchia i gruppi di sicurezza di AWS e le regole del firewall di Google Cloud come gruppi di sicurezza di rete di Azure (NSG). Convertire le regole di autorizzazione e negazione esistenti in formato NSG. Usare i gruppi di sicurezza delle applicazioni (ASG) per replicare il raggruppamento basato su tag fornito dai riferimenti ai gruppi di sicurezza di AWS.

Fase 3: Connettività

6. Connettività ibrida

Configurare tunnel VPN IPSec tra Azure e AWS o Google Cloud per il transito tra cloud crittografato. Connetti Gateway VPN di Azure (o le connessioni VPN di rete WAN virtuale) al gateway virtuale privato di AWS e a Google Cloud VPN. Scegliere la larghezza di banda del tunnel in base alle esigenze del traffico tra cloud. Pianificare tunnel ridondanti per evitare singoli punti di errore.

Fase 4: Sicurezza

7. Sicurezza DNS e risoluzione dei nomi privati

Pianificare la strategia di cutover DNS prima di eseguire la migrazione dei carichi di lavoro. Le applicazioni in AWS o Google Cloud risolvono i nomi host che potrebbero dover puntare ad Azure dopo la migrazione. Configurare Resolver privato DNS con endpoint in uscita per la risoluzione dei nomi tra ambienti cloud. Per indicazioni dettagliate sulla migrazione, vedere l'elenco di controllo per il cutover DNS più avanti in questo articolo.

8. Firewall di Azure

Distribuire Firewall di Azure in un hub virtuale sicuro per controllare tutto il traffico tra cloud e rami. Ogni attraversamento di pacchetti tra Azure e AWS o Google Cloud passa attraverso il firewall per la registrazione e l'imposizione dei criteri. Usa le regole di rete per gli schemi di traffico tra cloud e il filtro basato sull'intelligence sulle minacce per bloccare le destinazioni dannose note.

Fase 5: Operazioni

9. Monitoraggio e osservabilità della rete

I cross-cloud estate sono più difficili da risolvere perché non si controllano entrambe le estremità di ogni connessione. Abilitare Azure Network Watcher per il test della connettività, la diagnostica del tunnel VPN e l'acquisizione di pacchetti. Monitorare il tempo di attività del tunnel, la latenza tra i cloud e la velocità effettiva in base ai requisiti di capacità. Impostare avvisi per le disconnessioni del tunnel che influiscono sulla disponibilità delle applicazioni tra cloud.

Articoli condizionali

Includere questi articoli in base ai requisiti specifici:

Condition Articolo Quando includere
Applicazione rivolta al pubblico Internet in ingresso L'applicazione migrata è con connessione Internet (accesso pubblico diretto richiesto)
Applicazione HTTP/HTTPS Web application firewall Il waf di livello 7 è necessario per le applicazioni Web pubbliche
Distribuzione di livello 7 necessaria Recapito e prestazioni delle applicazioni Dopo la migrazione è necessaria una distribuzione del traffico globale o a livello di area
Endpoint pubblici Protezione DDoS Sono previsti requisiti di disponibilità per i servizi esposti al pubblico
Topologia hub-spoke preferita Topologia hub-spoke. Il tuo ambiente multi-cloud è sufficientemente piccolo da non giustificare l'adozione di rete WAN virtuale
Azure multi-area Rete multiregionale La destinazione Azure si estende su più aree oltre la connettività tra cloud
Accesso amministratore della macchina virtuale Accesso per sviluppatori e amministratori È necessario un accesso RDP/SSH sicuro alle macchine virtuali ospitate Azure
Uscita centralizzata Accesso a Internet in uscita I criteri di uscita Internet centralizzati fanno parte della progettazione di destinazione
Ambiente VNet di grandi dimensioni Gestione centralizzata della rete L'ambiente Azure cresce fino a diventare un ambiente multi-sottoscrizione governato
Endpoint privati di PaaS Accesso privato PaaS L'architettura di destinazione include servizi PaaS di Azure con endpoint privati

Elenco di controllo di Cross-Cloud Discovery

Prima di progettare la rete di Azure, mappa i servizi cloud esistenti con gli equivalenti in Azure. Questo mapping accelera le decisioni di progettazione e impedisce aspettative non corrispondenti.

Mapping del servizio da AWS a Azure

Servizio AWS Equivalente di Azure Note
Gateway di transito Rete WAN virtuale di Azure Hub di routing centralizzato per multi-VPC, multi-area, multi-cloud
VPC Rete virtuale di Azure Perimetro di rete isolato con subnet e tabelle di instradamento
VPC Peering Peering reti virtuali Connettività diretta tra due reti virtuali
Gruppi di sicurezza Gruppi di sicurezza di rete (NSG) Filtraggio del traffico con controllo dello stato a livello della subnet o dell’interfaccia di rete
ACL di rete Gruppi di sicurezza di rete (a livello di subnet) I gruppi di sicurezza di rete di Azure combinano le funzioni sia dei gruppi di sicurezza sia delle NACL
Gateway privato virtuale Gateway VPN Punto di terminazione VPN IPSec
Connessione diretta Azure ExpressRoute Connettività privata dedicata (non su Internet pubblico)
Route 53 Zone ospitate private Zone di DNS privato di Azure Risoluzione dei nomi DNS privati all'interno delle reti virtuali
Tabelle di route Route definite dall'utente (UDRs) Routing personalizzato per sovrascrivere gli instradamenti di sistema di Azure o quelli impliciti di AWS
Elastic Load Balancer (ALB/NLB) Azure Load Balancer / Application Gateway Bilanciamento di carico L4 e L7; Application Gateway offre funzionalità WAF simili a quelle di AWS ALB con AWS WAF
AWS WAF Web application firewall di Azure Protezione HTTP/HTTPS di livello 7
Firewall di rete Firewall di Azure Firewall di rete con stato con Intelligence per le minacce

Mapping dei servizi da Google Cloud a Azure

Servizio Google Cloud Equivalente di Azure Note
Rete VPC Rete virtuale di Azure Risorsa globale in Google Cloud; regionale in Azure (usare il peering di VNet tra aree geografiche)
Interconnessione al cloud Azure ExpressRoute Connettività privata dedicata
Cloud VPN Gateway VPN Tunnel VPN IPSec
Cloud NAT Gateway NAT di Azure Accesso a Internet in uscita per le risorse private
Cloud Router Server di route Azure Scambio di instradamento BGP dinamico con appliance virtuali di rete
Cloud Armor Web application firewall di Azure Protezione DDoS di livello 7 e delle applicazioni
Regole del firewall Gruppi di sicurezza di rete Filtraggio del traffico (le regole di Google Cloud sono globali; i gruppi di sicurezza di rete di Azure sono per subnet o per NIC)
Zone private di Cloud DNS Zone di DNS privato di Azure Risoluzione dei nomi privati all'interno delle reti
Centro di intelligence di rete Azure Network Watcher Monitoraggio della rete, diagnostica e visualizzazione della topologia

Elenco di controllo per il cutover DNS.

Il cutover DNS è il passaggio più rischioso per la migrazione tra cloud. Seguire questo elenco di controllo per ridurre al minimo gli errori di risoluzione durante la transizione.

Prima della migrazione

  1. Valori TTL (Time to Live) più bassi per tutti i record DNS che cambiano. Impostare il TTL su 60–300 secondi almeno 48 ore prima del passaggio. Questo passaggio garantisce che le cache scadano rapidamente quando si aggiornano i record.
  2. Documenta tutti i record DNS che puntano all'infrastruttura che stai migrando: record A per i server, record CNAME per i servizi, record MX per la posta elettronica e record SRV per l'individuazione dei servizi.
  3. Configura DNS di Azure Private Resolver con endpoint in uscita nella tua VNet di Azure. Questo sistema di risoluzione inoltra le query per le zone ospitate da AWS/Google Cloud ai server DNS upstream appropriati durante il periodo di coesistenza.
  4. Testare la risoluzione in avanti e inversa dalle reti virtuali Azure ai nomi ospitati da AWS/Google Cloud prima di eseguire la migrazione di qualsiasi carico di lavoro.

Durante la migrazione

  1. Aggiornare i record CNAME per i servizi che passano a Azure. Indirizzare i record CNAME ad Frontdoor di Azure, ad Gestione traffico di Azure o agli endpoint di Gateway applicazione di Azure man mano che ciascun servizio viene migrato.
  2. Aggiornare i record host A per i singoli server di cui viene eseguita la migrazione. Sostituisci gli indirizzi IP di AWS o di Google Cloud con indirizzi IP privati di Azure nelle zone DNS.
  3. Mantenere attiva l'inoltro condizionale in modo che i nomi nelle zone di cui non è stata ancora eseguita la migrazione continuino a essere risolti tramite i server DNS del cloud originale.

Dopo la migrazione

  1. Verificare la risoluzione da tutte le località: i client locali, le reti virtuali di Azure ed eventuali carichi di lavoro rimanenti in AWS o Google Cloud devono essere tutti in grado di risolvere correttamente i nomi migrati.
  2. Aumentare i valori TTL ai livelli di produzione (3.600 secondi o superiori) dopo aver confermato la risoluzione stabile.
  3. Rimuovere i server d'inoltro condizionale per le zone di cui viene eseguita la migrazione completa a DNS di Azure. Mantenere i server d'inoltro solo per le zone che rimangono in AWS o Google Cloud.

Ciò che hai creato

Seguendo questo percorso di lettura, è stata connessa Azure all'ambiente AWS o Google Cloud esistente con transito crittografato, ispezione centralizzata del firewall e connettività monitorata. La progettazione include:

  • Individuazione della topologia multicloud e mapping dei servizi
  • Architettura di transito hub-spoke o rete WAN virtuale
  • Tunnel VPN IPSec per AWS e Google Cloud
  • Firewall di Azure per l'ispezione del traffico tra cloud
  • Passaggio DNS con Private Resolver per la risoluzione dei nomi tra cloud
  • Monitoraggio dell'integrità e delle prestazioni del tunnel con Network Watcher

Passaggi successivi

  • Last updated on