Multi-Cloud VPN: uniamo AWS, Azure e Yandex Cloud tramite Transit Gateway e Virtual WAN

Introduzione: perché il Multi-Cloud VPN è fondamentale per il business e perché ora

Collegare più cloud in una rete unica, sicura e affidabile non è più un dettaglio tecnico raro, ma una necessità operativa. Nel 2026, molte aziende stanno abbandonando strategie monoclaud per adottare ambienti multi-cloud: così si distribuiscono i rischi, si ottimizzano i costi, si rispettano le norme di localizzazione dati e si accelera il time-to-market. La domanda è: come collegare AWS, Azure e Yandex Cloud in modo stabile, scalabile senza problemi e con audit di sicurezza impeccabili?

Questa guida è il tuo manuale pratico. Esamineremo concetti base e avanzati, illustreremo architetture collaudate basate su AWS Transit Gateway e Azure Virtual WAN, collegheremo Yandex Cloud e siti on-premises, per concludere con monitoraggio, automazione ed economia. Troverai istruzioni step-by-step, checklist, template di progettazione, consigli per l’alta disponibilità, soluzioni per reti sovrapposte e casi di riferimento concreti.

Basi: concetti fondamentali del Multi-Cloud VPN

Componenti chiave

• VPC/VNet/Reti in Yandex Cloud: reti private isolate con routing a livello di hypervisor. La pianificazione dello spazio indirizzi CIDR è la base della resilienza. Si consiglia di assegnare blocchi non sovrapposti per dominio (prod, non-prod, shared) e regione.
• IPsec VPN (IKEv2): standard industriale di cifratura a livello 3. Usato in Site-to-Site tra cloud e con on-prem. Supporta suite crittografiche con PFS (Perfect Forward Secrecy) e accelerazioni hardware (AES-GCM).
• BGP: protocollo dinamico di routing su tunnel protetti, che permette l’annuncio e il ritiro automatico di prefissi, la creazione di ECMP multipath e il controllo delle priorità di traffico (AS-Path prepending, MED, comunità).
• Hub-and-Spoke: topologia centrale dove l’hub gestisce routing, segmentazione e ispezione servizi (FW, IDS/IPS), mentre gli spoke sono VPC/VNet applicativi.
• AWS Transit Gateway (TGW): backbone regionale L3 che aggrega VPC, VPN e Direct Connect. Gestisce tabelle di routing e propagazione dei prefissi tra attachment.
• Azure Virtual WAN (vWAN): rete globale Microsoft che semplifica il collegamento di filiali, VPN, ExpressRoute e VNet, spesso utilizzata come hub multi-cloud per la sua ampia copertura geografica.
• Yandex Cloud VPN: gateway IPsec gestiti con routing dinamico (BGP) e alta disponibilità tramite più tunnel/zone. Per alte prestazioni, usa Cloud Interconnect o router virtuali.

Modello di sicurezza e segmentazione

• Segmentazione a L3: definizione di zone di trust (prod, dev, servizi condivisi, partner). Controllo del routing tra zone tramite tabelle TGW/vWAN e policy firewall.
• Controllo a L4-L7: firewall cloud (Azure Firewall in Secure Hub, AWS Network Firewall o NGFW di terze parti). Ispezione traffico, TLS decryption dove permesso, IDS/IPS, sicurezza DNS.
• Principi Zero Trust: accesso minimo necessario, autorizzazione esplicita per i servizi, lease brevi, validazione continua di tunnel e rotte.

Fattori di stabilità

• MTU/MSS: la MTU utile si riduce per l’incapsulamento IPsec. Configura MSS clamping (di solito 1350-1380) sui gateway border per evitare frammentazione e perdite.
• DPD e reinizializzazioni: Dead Peer Detection e timing di rekey. Allinea le durate di IKE SA e Child SA su entrambe le estremità.
• ECMP e active-active: più tunnel con costi uguali migliorano capacità aggregata e resilienza.
• NAT-T: trasporto IPsec su UDP/4500 in caso di NAT lungo il percorso. Obbligatorio se si connette via internet con indirizzi variabili.

Approfondimento: aspetti avanzati poco trattati

CIDR sovrapposti: come gestirli

I blocchi ereditati 10.0.0.0/8 spesso si sovrappongono in fusioni e migrazioni multi-cloud. Soluzioni:

• NAT di confine: in Azure si può usare VPN NAT sul gateway (bidirezionale/monodirezionale) per tradurre prefissi. In AWS e Yandex si usa virtual router (VyOS/FRR) o NGFW con NAT.
• Segmentazione e reindirizzamento: il re-IP graduale è la strategia più pulita ma costosa durante la migrazione. Combina con NAT temporanei per servizi critici.
• Routing specifico per prefisso: separa subnet conflittuali in tabelle TGW/vWAN distinte, senza propagazione automatica; importa solo prefissi necessari tramite rotte statiche.

Ingegneria BGP nel cloud

• ASN: in AWS TGW si può scegliere ASN privato (default 64512, range esteso disponibile oltre 4200000000). In Azure vWAN hub e gateway VPN usano ASN privati di servizio, con ASN locale configurabile per on-prem/peer. Assicurati unicità.
• Priorità traffico: AS-Path prepending e MED per definire tunnel attivi e standby. Nel singolo provider spesso basta la preferenza locale in routing table.
• Sommario prefissi: aggrega reti a /16-/20 dove possibile per ridurre chatter e rischio saturazione tabelle.

Capacità e SLA

• Limiti tunnel: sui gateway VPN gestiti esistono soglie di throughput per tunnel e aggregate. Progetta sulla base di P95+ N+1 con margine 20-30%.
• Multi-region: minimizza l’hairpin. Hub regionali vicini agli utenti abbassano latenza e costi di egress.
• Quando serve trasporto privato: se P99 sensibile a jitter, valuta collegamenti privati (Direct Connect, ExpressRoute) fino a un punto di interscambio e IPsec da lì al terzo cloud. Più complesso ma predicibile.

Sicurezza: profili crittografici e chiavi

• Suite crittografiche: AES-256-GCM con PFS (DH Group 14/19/20) è un buon compromesso. Coordina le durate (es. IKE 8h, Child 1h) e usa margini nel rekey.
• Gestione chiavi: conserva PSK in secret manager (AWS Secrets Manager, Azure Key Vault, Yandex Lockbox). Automatizza la rotazione.
• Logging: attiva flow logs, audit cambiamenti e metriche stato tunnel.

Pratica 1: AWS Transit Gateway come hub multi-cloud

Quando scegliere

Se operi già su AWS, con carichi e funzioni concentrate lì, e vuoi connettere Azure e Yandex Cloud con pochi componenti aggiuntivi, TGW è il router centrale, Azure e Yandex saranno siti VPN.

Schema

VPC (prod/dev/shared) sono connessi al TGW. Per ogni cloud esterno si crea un VPN attachment con due tunnel. BGP diffonde prefissi tra VPC e cloud esterni. Tabelle di routing TGW separate garantiscono segmentazione.

Istruzioni passo passo

1. Piano indirizzi: assegna CIDR unici per VPC e reti Azure VNet e Yandex. Definisci matrice di accesso (chi accede a chi e con quali porte).
2. Crea TGW: scegli un ASN privato (es. 64520). Imposta tabelle di routing per zone di trust: prod-rt, dev-rt, external-rt.
3. Attach VPC: configura attachment VPC con relative tabelle TGW. Abilita propagation solo dove servono.
4. Connessione Azure: prendi IP pubblici di Azure VPN Gateway (active-standby o active-active). In AWS crea Customer Gateway, poi Site-to-Site VPN verso Azure. Scegli Transit Gateway attachment, IKEv2, suite crittografiche. Attiva BGP, assegna /30 per tunnel in accordo con template Azure.
5. Connessione Yandex Cloud: simile, configura Customer Gateway con IP pubblici Cloud VPN Yandex. Attiva 2 tunnel BGP (zone diverse), ASN unici. Accordare lifetimes e DPD.
6. Routing: attiva propagation prefissi VPN in external-rt; associa selectiveexternal-rt alle VPC necessarie. Disabilita propagazione automatica in prod-rt/dev-rt, importa solo prefissi richiesti.
7. Segmentazione e FW: traffico tra VPC e reti esterne passa da VPC di ispezione con NGFW (GWLB o appliance). Imposta routing via endpoint firewall.
8. Test: verifica sessioni BGP, prefissi, MTU/MSS. Iperf3 per throughput, test smoke delle app, esportazioni metriche.

Schema Terraform

• Moduli: tgw, attachments, vpn, route-tables, firewall-vpc.
• Variabili: asn, cidr_map, bgp_params, ike_params, fw_endpoints.
• Pipeline: plan — security review — apply in dev, poi change set in prod.

Checklist hub TGW

• ASN unici e profili IKE coordinati.
• Due tunnel per connessione, ECMP attivo.
• Isolamento rotte per tabella, associazione/propagazione esplicita.
• MSS clamping su interfacce di border.
• Flow Logs e CloudWatch Alarms per stato tunnel.

Pratica 2: Azure Virtual WAN come backbone globale

Quando scegliere

Fortemente presente in Azure, con molte filiali o necessità di ottimizzare routing globale via backbone Microsoft. Hub vWAN prossimo agli utenti assicura latenza prevedibile, VPN NAT rimedia a CIDR sovrapposti.

Schema

Si crea una Virtual WAN e uno o più Virtual Hub (nelle regioni utente). Si collegano VNet (spoke) e VPN site: AWS (via TGW VPN o VGW), Yandex Cloud (via Cloud VPN). Si abilita Secure Hub con Azure Firewall per ispezione.

Istruzioni

1. Crea vWAN e Virtual Hub: scegli regione(i), SKU VPN Gateway, e se serve Secure Hub (Azure Firewall).
2. Collega VNet: tramite connessioni hub con routing policy (propagazione/associazione).
3. Connessione AWS: in Azure crea VPN Site con IP tunnel AWS. In AWS crea Site-to-Site VPN per Azure con TGW attachment. Abilita BGP su entrambi i lati.
4. Connessione Yandex Cloud: similmente, VPN Site in Azure, tunnel a Yandex VPN. Se CIDR sovrapposti, configura VPN NAT su Azure Gateway (policy inbound/outbound a seconda dei casi).
5. Routing in vWAN: imposta propagation e association alle route table necessarie, limita propagazione in VNet sensibili. Esporta solo prefissi aggregati.
6. Ispezione traffico: tramite Azure Firewall in Secure Hub, configura regole DNAT/SNAT se serve, filtri FQDN, modalità IDS.
7. Testing e SLO: monitor BGP e tunnel con Azure Monitor, logging FW, controllo latenza P95/99.

Caratteristiche vWAN

• Routing flessibile con più tabelle nell’hub.
• NAT integrato su VPN Gateway facilita M&A.
• Integrazione forte con filiali e SD-WAN CPE.

Pratica 3: Connettere Yandex Cloud ad AWS e Azure

Opzioni

• Via AWS TGW: Yandex Cloud VPN Site-to-Site verso TGW. Minimo componenti in Yandex, BGP dinamico, due tunnel in zone diverse. Ideale se hub AWS.
• Via Azure vWAN: Yandex Cloud VPN Site-to-Site verso hub virtuale. Facile per usare NAT Azure in caso di conflitti indirizzi.
• Via router virtuali: VyOS/FRR in Yandex e AWS/Azure per protocolli non standard (es. WireGuard per replica inter-cloud, se policy lo permettono).

Integrazione Yandex Cloud VPN passo passo

1. Piano e zone: scegli zona(e) Yandex per VPN gateway. Garantire resilienza minimo 2 tunnel per cloud.
2. Crea Cloud VPN: configura gateway con parametri IKEv2, suite crittografiche, lifetimes. Indica IP pubblici gateway AWS/Azure.
3. BGP: assegna ASN privato Yandex, coordina indirizzi /30 per BGP e prefissi da annunciare (sommari ambientali).
4. Rotte e tabelle: lega tabelle di routing a subnet e servizi. Invia esplicitamente traffico verso prefissi remoti via VPN gateway, evitando rotte internet locali.
5. Verifica: stabilità BGP, log IPsec, caduta un tunnel non deve interrompere connessione.

Prestazioni e quando serve Interconnect

Se il carico è costante e sensibile al jitter (es. DB sincroni), valuta trasporto privato fino a un punto di interscambio e IPsec da lì. Yandex Cloud Interconnect offre SLA predicibili, poi IPsec può estendersi ad AWS/Azure dallo stesso interscambio.

Pratica 4: Alta disponibilità, automazione ed esercizio

Pattern HA

• Multi-tunnel: almeno due tunnel tra ogni coppia di domini. Meglio in zone o hub regionali diverse.
• ECMP: routing equiparato per banda totale e convergenza rapida.
• Salute rotte: mascheramento automatico prefissi in degrado (route health injection), integrazione con manager di health-check.
• Traffic steering: active-active su flussi meno critici, active-passive su flussi sensibili a jitter.

Osservabilità e SLO

• Metriche: stato tunnel (up/down), conteggio rekey, pacchetti persi, banda per tunnel, flapping BGP, latenza P50/P95/P99, perdite, jitter.
• Log: IPsec/IKE, flow logs, eventi firewall. Correlazione su bus di log unificato.
• Alert: violazioni SLO, anomalie banda, aumento RTT, caduta rotte, superamento costi egress.

Automazione e IaC

• Terraform: moduli comuni per AWS, Azure e Yandex. Parametrizza profili crittografici, ASN, schema route. Separa stati per ambiente, usa backend remoti e lock.
• CI/CD: PR workflow, analisi statica, preview piani, sicurezza segreti. Calendario cambi e canary rollout per modifiche di rete.
• Drift detection: validazione periodica, policy "no change manuali" in prod.

Testing

• Unit test IaC: policy-as-code (regex su suite crittografiche, restrizioni porte).
• Chaos drills: disattivazione tunnel singolo, degrado suite, caduta di zona. Verifica convergenza e mantenimento SLO.
• Stress test: iperf3 bidirezionale, profilazione packet loss con MSS variabile.

Pratica 5: Sicurezza e compliance out-of-the-box

Profilo minimo sicuro

• AES-256-GCM con PFS attivo, DH group 14/19, solo IKEv2.
• Rinnovo Child SA ogni 60 minuti, IKE 8 ore, DPD 10-15 sec, 3-5 tentativi.
• MSS clamping a 1360 (regola dopo test PMTUD).
• Bloccare rotte ampie (es. 0.0.0.0/0) in BGP se non deliberate tramite hub con ispezione.

Segmentazione accessi

• Tabelle routing separate su TGW/vWAN per prod/dev/partner.
• Ispezione del traffico inter-zone via firewall obbligatoria.
• Controllo DNS ed egress tramite proxy/firewall.

Segreti e gestione chiavi

• Conservazione PSK/certificati in secret manager con rotazione pianificata.
• RBAC e accesso break-glass con audit.

Pratica 6: Economia e prestazioni

Modello costi

• Componenti: costo gateway (a ora/throughput), traffico egress/ingress, trattamento rotte TGW/vWAN, ispezione FW, NAT.
• Topologia: hub locali riducono egress interregionali, hub nord-sud centralizzato può diventare collo di bottiglia costoso.
• Ridondanza: tunnel N+1 aumentano costo ma assicurano stabilità. Bilancia con SLO.

Ottimizzazioni

• Sommario rotte invece di migliaia di piccoli prefissi.
• Località traffico: mantenere traffico in regione.
• Spegnimento automatico tunnel inutilizzati in ambienti test secondo calendario.

Pratica 7: Gestione di casi complessi

CIDR sovrapposti con downtime minimo

1. Inventario conflitti: quali subnet comunicano realmente.
2. NAT temporaneo di confine (Azure VPN NAT o FW NAT) per coppie in conflitto.
3. Re-IP graduale in finestre di manutenzione. Controllo compatibilità retrograda.
4. Rimozione NAT temporanei e semplificazione routing.

Caso WireGuard/OpenVPN sopra i cloud

Per replica inter-cloud o porte non standard, usa router virtuali (Linux+WireGuard, VyOS, FRR) e termina in VPC/VNet separato con integrazione routing TGW/vWAN. Valuta requisiti sicurezza e compliance.

Errori tipici: cosa evitare

• Propagazione automatica totale: genera connessioni indesiderate e amplia blast radius.
• CIDR identici: risparmio iniziale si traduce in re-IP di mesi dopo.
• Ignorare MTU/MSS: timeout inspiegabili e cadute sporadiche sono quasi sempre dovuti a frammentazione.
• Statico invece di BGP: rotte manuali scalano male e sono rischiose in caso di guasti.
• Nessuna ispezione: L3 puro senza controllo porte e FQDN non supera audit.
• Un solo hub per tutte le regioni: latenza e costi egress crescono esponenzialmente.
• Segreti in file di testo: PSK in chiaro è strada certa a incidente.

Strumenti e risorse: cosa usare nella pratica

Servizi cloud

• AWS: Transit Gateway, Site-to-Site VPN, Network Firewall, CloudWatch, VPC Flow Logs, Gateway Load Balancer.
• Azure: Virtual WAN, VPN Gateway (incluso VPN NAT), Azure Firewall (Secure Hub), Azure Monitor, Network Watcher.
• Yandex Cloud: Cloud VPN, Security Groups, Route Tables, Cloud Interconnect, Yandex Monitoring e Log.

Router virtuali e NGFW

• VyOS, FRR (BGP), StrongSwan/Libreswan, pfSense, e anche NGFW commerciali (Palo Alto, Fortinet, Check Point, Cisco) per policy complesse, NAT e ispezione.

IaC, test e monitoraggio

• Terraform (multi-cloud), Terragrunt per struttura.
• InSpec/OPA/Conftest per policy-as-code.
• iperf3, tcptraceroute, mtr per verifiche di rete.
• Prometheus/Grafana, exporter VPN e BGP, alert su SLO.

Avvio rapido per proof of concept

Per POC o demo, quando serve rapidamente un VPN aziendale tra team di sviluppo e ambienti multi-cloud, vpn.how è un’opzione pratica. È un server VPN personale con IP dedicato (non condiviso), supporta WireGuard, OpenVPN, IKEv2, L2TP, SSTP — scegli il protocollo adatto alle tue esigenze e limiti di rete. Sono disponibili location a Mosca, San Pietroburgo, Amsterdam, Francoforte, Londra, New York, San Jose, Chicago, Singapore, Sydney, Madrid, Helsinki, Stoccolma, Varsavia, Copenaghen, Stavanger. Accetta carte russe (inclusi Tinkoff e Ozon), SBP, USDT/BTC. Tariffe da 490 ₽ al giorno e da 2490 ₽ al mese con sconti su periodi lunghi, avvio del server in 5 minuti dopo il pagamento, senza log. Ideale per un rapido ambiente di test e ricognizione di rete senza lunghe procedure di acquisto. Per ambienti di produzione è consigliabile costruire infrastrutture gestite proprie o considerare VPN con standard ГОСТ a seconda dei requisiti normativi.

Casi reali e risultati: cosa dimostra la pratica

Caso 1: Fintech, hub su AWS TGW

Contesto: oltre 120 microservizi in AWS, analisi in Azure, parte della logica di pagamento in Yandex Cloud per requisiti di localizzazione. Soluzione: TGW come hub, due tunnel verso Azure e Yandex, BGP con sommario, VPC di ispezione con NGFW. Risultati: P95 latenza AWS↔Azure 28-35 ms (EU), resilienza alla perdita tunnel con degradazione banda max 35%, audit PCI DSS superato grazie a segmentazione chiara e logging. Ottimizzazione egress con risparmio ~18% nel primo trimestre.

Caso 2: Data/ML, hub su Azure vWAN

Contesto: DWH e pipeline ML in Azure, API ad alto carico in AWS, Yandex Cloud per inferenza locale. Soluzione: Virtual WAN con due hub (Europa Occidentale e Orientale), VPN verso AWS TGW e Yandex Cloud VPN, Azure Firewall in Secure Hub, VPN NAT per subnet in conflitto. Risultati: risolti conflitti indirizzi senza downtime, throughput ~2-3 Gbps aggregato su 4 tunnel, riduzione incidenti del 40% dopo unificazione osservabilità.

Caso 3: M&A e CIDR sovrapposti

Contesto: fusione di due aziende con 10.0.0.0/8 parzialmente condiviso. Soluzione: NAT temporaneo su Azure VPN, routing tramite vWAN con tabelle isolate, re-IP graduale delle subnet critiche, poi totale abbandono di NAT. Risultati: zero downtime per servizi clienti, riduzione complessità routing del 60% dopo re-IP completato.

FAQ: domande frequenti

1. BGP è obbligatorio o va bene anche statico?

Per un pilota statico può andare. In produzione con crescita BGP è necessario: riduce errori umani, velocizza convergenza e offre priorità flessibili.

2. Quale politica di cifratura scegliere?

AES-256-GCM con PFS e IKEv2. Durate coordinate, margine rekey e DPD. Auditing esterno preferisce suite standardizzate.

3. WireGuard va bene per le aziende?

Sì, come opzione ad alte prestazioni, ma verifica compliance e requisiti di logging. Più spesso usato in router virtuali assieme a IPsec.

4. Come gestire MTU?

Parti da MSS 1360, abilita PMTUD, monitora frammentazione. Se problemi, abbassa MSS a 1350-1340.

5. CIDR sovrapposti: serve sempre re-IP?

Non sempre. A breve termine aiuta NAT su VPN Gateway (Azure) o NGFW. Strategicamente re-IP è raccomandato o il debito tecnico cresce.

6. Come controllare i costi?

Localizza traffico, aggrega rotte, evita routing nord-sud unico, analizza egress e FW processing, spegni ambienti non usati.

7. Qual è la scelta migliore per hub: TGW o vWAN?

Se il baricentro è AWS, TGW; se Azure o molte filiali/SD-WAN, vWAN. Spesso si usano ibridi con hub regionali in entrambi.

8. Quale SLA si può raggiungere?

VPN su internet realisticamente 99.9-99.95 con tunnel multipli e regioni diverse. Per critici, canali privati + IPsec, monitoraggio e RHI.

9. Come integrare l’ispezione?

Con VPC/VNet di ispezione con NGFW e routing mirato (UDR, tabelle TGW, hub sicuro vWAN). Log e automazione delle regole.

10. DNS multi-cloud?

Risoluzione zonale con forwarding condizionale tra resolver cloud, caching, controllo egress DNS e protezione da leak.

Conclusione: road map per una rete multi-cloud affidabile

Una rete unificata tra AWS, Azure e Yandex Cloud è un processo maturo, gestito e auditabile. Parti da piano indirizzi e requisiti traffico, scegli hub (TGW o vWAN), standardizza profili crittografici, abilita BGP e segmentazione, ispeziona traffico, automatizza con Terraform e CI/CD, e supporta con metriche e SLO. Per POC agisci con rapidità e pragmatismo; per produzione giustifica SLO, prevedi N+1, pianifica esercizio, osservabilità e budget. Otterrai una rete che funziona, scala, supporta audit e resiste a imprevisti.

Appendice: checklist rapida di progettazione

• Piano indirizzi: CIDR unici, aggregabilità, matrice di accesso.
• Hub: TGW o vWAN (o entrambi), regionalità, tabelle di routing.
• Crittografia: IKEv2, AES-GCM, PFS, durate, DPD.
• Tunnel: almeno 2 per connessione, ECMP, zonizzazione.
• Routing: BGP, prepending, MED, sommario, RHI.
• Segmentazione e FW: hub ispezione, policy L7, controllo egress.
• MTU/MSS: parte da 1360, valida, regola.
• IaC: Terraform, policy-as-code, CI/CD, segreti.
• Osservabilità: metriche, log, alert, SLO, drill regolari.
• Economia: localizzazione traffico, egress, spegnimento ambienti, SKU gateway.