La progettazione della connettività cloud, cuore dell’esame ENCC, non parte mai dal protocollo ma dal modello architetturale che il cliente ha scelto. Prima di decidere se attestare un tunnel IPsec, una connessione privata dedicata o una fabric SD-WAN, il progettista deve capire dove risiedono i workload e come vengono erogati. Modelli di deployment e modelli di servizio sono le due dimensioni che governano questa scelta.
Modelli di deployment
I quattro modelli descrivono chi possiede e dove sta l’infrastruttura, e ognuno impone un percorso di connettività diverso.
| Modello | Descrizione | Impatto sulla connettività |
|---|---|---|
| Public | Risorse su infrastruttura condivisa di un provider | Un solo path verso un provider: VPN IPsec su Internet o interconnessione privata dedicata |
| Private | Infrastruttura dedicata (on-prem o hosted) a uso esclusivo | Connettività interna/data center, spesso senza attraversare Internet pubblico |
| Hybrid | Combinazione di private/on-prem e un cloud pubblico, con orchestrazione tra i due | Estensione controllata on-prem → un provider; routing e indirizzamento gestibili in modo lineare |
| Multicloud | Uso di due o più cloud provider distinti simultaneamente | Interconnessione tra provider eterogenei: routing inter-cloud, transito, indirizzamento e policy molto più complessi |
Il punto critico d’esame è la differenza tra hybrid e multicloud. Hybrid lega il mondo on-premises a un cloud: il dominio di routing rimane relativamente contenuto e l’indirizzamento è negoziato con un solo provider. Multicloud implica che due o più provider vengano interconnessi tra loro, spesso con overlap di indirizzi RFC 1918, tabelle di routing separate e nessuna fiducia reciproca nativa. Questo introduce la necessità di un transit hub (colocation, cloud exchange come Equinix o Megaport, oppure un router virtuale come Catalyst 8000V), di BGP per lo scambio dinamico di prefissi tra le VPC/VNet dei diversi provider e frequentemente di NAT per risolvere le sovrapposizioni di indirizzamento. Un ambiente può essere sia hybrid sia multicloud contemporaneamente: i termini non si escludono, ma non sono sinonimi.
Modelli di servizio
I tre modelli descrivono quanto stack gestisce il provider e quanto resta al cliente, condizionando cosa deve raggiungere la connettività.
- IaaS — Il cliente controlla VM, subnet, routing e security group. Qui il progettista di rete ha piena visibilità: può attestare VPN, SD-WAN o interconnessioni private direttamente sulla VPC/VNet e annunciare i prefissi via BGP. È lo scenario in cui la connettività L3 punto-a-cloud è più ricca.
- PaaS — Il provider gestisce il runtime; il cliente espone servizi tramite endpoint gestiti. La connettività si sposta verso private endpoint / private link e integrazione DNS, più che verso il routing classico.
- SaaS — Applicazione consumata via HTTPS. Non si progetta un path L3 verso i server: la connettività riguarda breakout Internet ottimizzato (tipicamente Cisco SD-WAN Cloud OnRamp for SaaS), scelta del best path e sicurezza del traffico, non tunnel verso data center.
Collegare requisiti a percorso
La scelta finale nasce dall’incrocio tra modello e requisiti non funzionali:
- Banda elevata e sostenuta (backup, replica DB, migrazioni): spinge verso interconnessioni private dedicate anziché VPN su Internet, per throughput prevedibile.
- Bassa latenza e jitter (voce, transazioni real-time): richiede path privati o cloud on-ramp geograficamente vicini, evitando l’imprevedibilità del transito Internet.
- SLA stringenti: le VPN IPsec su Internet ereditano l’SLA “best effort” della rete pubblica; un contratto con garanzie di uptime e banda impone una connessione privata con SLA end-to-end.
- Ridondanza: dual-path (private + VPN di backup) o multi-region per rispettare gli obiettivi di disponibilità.
In pratica: un workload IaaS in hybrid con replica notturna e SLA severo → interconnessione privata con BGP e VPN di backup. Un consumo SaaS → SD-WAN Cloud OnRamp for SaaS con breakout locale. Un ambiente multicloud → transit hub con routing e NAT per gestire l’interconnessione tra provider.
Trappole tipiche d’esame
- “Hybrid e multicloud sono la stessa cosa” → FALSO. Hybrid = on-prem + un cloud; multicloud = più provider interconnessi tra loro, con routing e indirizzamento molto più complessi. Se lo scenario cita due provider distinti che devono comunicare, la risposta è multicloud/transit, non un semplice tunnel hybrid.
- SLA garantito richiesto per traffico ad alta banda → NON scegliere VPN IPsec su Internet, che è best-effort; opta per una interconnessione privata dedicata con SLA contrattuale.
- Scenario SaaS che chiede “ottimizzazione del path” → NON progettare connettività L3/BGP verso i server; la risposta corretta è SD-WAN Cloud OnRamp for SaaS con breakout Internet ottimizzato.
- Multicloud con overlap di indirizzi RFC 1918 → serve NAT (e/o re-indirizzamento) al transit hub; annunciare i prefissi sovrapposti via BGP senza traduzione causa conflitti di routing.
- PaaS trattato come IaaS → errore: nel PaaS non si controllano subnet e route table; la connettività passa da private endpoint e DNS, non da tunnel verso VM.