Questa guida introduce le best practice e le architetture aziendali tipiche per la progettazione di Virtual Private Cloud (VPC) con Google Cloud. Questa guida è rivolta ad architetti di rete cloud e di sistema che hanno già familiarità con i concetti di Google Cloud networking.
Principi generali e primi passi
Identifica i responsabili delle decisioni, le tempistiche e il lavoro preliminare.
Considera in anticipo la progettazione della rete VPC.
Privilegia la semplicità.
Utilizza convenzioni di denominazione chiare.
Identificare i responsabili delle decisioni, le tempistiche e il lavoro preliminare
Come primo passo nella progettazione della rete VPC, identifica i responsabili delle decisioni, le tempistiche e il lavoro preliminare necessario per garantire di poter soddisfare i requisiti delle parti interessate.
Le parti interessate possono includere proprietari di applicazioni, architetti della sicurezza, architetti di soluzioni e responsabili delle operazioni. Gli stakeholder stessi potrebbero cambiare a seconda che tu stia pianificando la rete VPC per un progetto, una linea di business o l'intera organizzazione.
Parte del lavoro preliminare consiste nel familiarizzare il team con i concetti e la terminologia relativi alla progettazione della rete VPC. I documenti utili includono quanto segue:
- Documentazione di Resource Manager
- Documentazione di Identity and Access Management (IAM)
- Documentazione di Virtual Private Cloud
Considera in anticipo la progettazione della rete VPC
Rendi la progettazione della rete VPC una prima parte della progettazione della configurazione della tua organizzazione in Google Cloud. Potrebbe essere problematico per la tua organizzazione se in un secondo momento devi modificare elementi fondamentali come la segmentazione della rete o la posizione dei workload.
Configurazioni di rete VPC diverse possono avere implicazioni significative per il routing, la scalabilità e la sicurezza. Una pianificazione attenta e una profonda comprensione delle tue considerazioni specifiche ti aiutano a creare una base architetturale solida per i carichi di lavoro incrementali.
Semplifica
Mantenere semplice la progettazione della topologia della rete VPC è il modo migliore per garantire un'architettura gestibile, affidabile e ben compresa.
Utilizzare convenzioni di denominazione chiare
Rendi le convenzioni di denominazione semplici, intuitive e coerenti. In questo modo gli amministratori e gli utenti finali comprendono lo scopo di ciascuna risorsa, dove si trova e come si differenzia dalle altre risorse.
Le abbreviazioni comunemente accettate di parole lunghe aiutano a essere più brevi. L'utilizzo di una terminologia familiare, se possibile, contribuisce alla leggibilità.
Quando stabilisci le convenzioni di denominazione, considera i componenti illustrati nell'esempio seguente:
- Nome dell'azienda: Acme Company:
acmeco - Unità aziendale: risorse umane:
hr - Codice applicazione: sistema di compensazione:
comp - Codice regione: northamerica-northeast1:
na-ne1, europe-west1:eu-we1 - Codici ambiente:
dev,test,uat,stage,prod
In questo esempio, l'ambiente di sviluppo del sistema di compensazione del reparto Risorse umane
si chiama acmeco-hr-comp-eu-we1-dev.
Per altre risorse di networking comuni, considera pattern come questi:
Rete VPC
sintassi:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
esempio:acmeco-hr-dev-vpc-1Subnet
sintassi:{company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
esempio:acmeco-hr-na-ne1-dev-vpc-1-subnet-1
nota: se una subnet contiene risorse in una sola zona, puoi utilizzare "zone-label" anziché "region-label".Regola firewall
sintassi:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
esempio:acmeco-hr-internet-internal-tcp-80-allow-ruleRoute IP
sintassi:{priority}-{VPC-label}-{tag}-{next hop}
esempio:1000-acmeco-hr-dev-vpc-1-int-gw
Indirizzi e subnet
Utilizza subnet in modalità personalizzata nelle reti VPC aziendali.
Raggruppa le applicazioni in un numero inferiore di subnet con intervalli di indirizzi più ampi.
Utilizza le reti VPC in modalità personalizzata
Sebbene le reti in modalità automatica possano essere utili per l'esplorazione iniziale, le reti VPC in modalità personalizzata sono più adatte alla maggior parte degli ambienti di produzione.
Consigliamo alle aziende di utilizzare le reti VPC in modalità personalizzata fin dall'inizio per i seguenti motivi:
- Le reti VPC in modalità personalizzata si integrano meglio negli schemi di gestione degli indirizzi IP esistenti. Poiché tutte le reti in modalità automatica utilizzano lo stesso insieme di intervalli IP interni, gli intervalli IP in modalità automatica potrebbero sovrapporsi quando sono connessi alle reti aziendali on-premise.
- Non puoi connettere due reti VPC in modalità automatica utilizzando il peering di rete VPC perché le relative subnet utilizzano intervalli IP primari identici.
- Tutte le subnet in modalità automatica hanno lo stesso nome della rete. Puoi scegliere nomi unici e descrittivi per le subnet in modalità personalizzata, rendendo le tue reti VPC più comprensibili e gestibili.
- Quando viene introdotta una nuova regione Google Cloud , le reti VPC in modalità automatica ottengono automaticamente una nuova subnet in quella regione. Le reti VPC in modalità personalizzata ricevono nuove subnet solo se le specifichi. Questo può essere importante sia per motivi di sovranità sia per la gestione degli indirizzi IP.
Se non ha risorse, puoi
eliminare la rete default. Non puoi eliminare una rete VPC finché non hai
rimosso tutte le risorse, incluse le istanze di macchine virtuali (VM), che dipendono
da essa.
Per maggiori dettagli sulle differenze tra le reti VPC in modalità automatica e personalizzata, consulta la panoramica delle reti VPC.
Raggruppa le applicazioni in un numero inferiore di subnet con intervalli di indirizzi più grandi
Per convenzione, alcune reti aziendali sono suddivise in molti piccoli intervalli di indirizzi per vari motivi. Ad esempio, questa operazione potrebbe essere stata eseguita per identificare o isolare un'applicazione o mantenere un piccolo dominio di trasmissione.
Tuttavia, ti consigliamo di raggruppare le applicazioni dello stesso tipo in meno subnet, più gestibili con intervalli di indirizzi più grandi nelle regioni in cui vuoi operare.
A differenza di altri ambienti di rete in cui viene utilizzata una subnet mask,Google Cloud utilizza un approccio di networking software-defined (SDN) per fornire una mesh completa di raggiungibilità tra tutte le VM nella rete VPC globale. Il numero di subnet non influisce sul comportamento di routing.
Puoi utilizzare service account o tag di rete per applicare regole firewall o criteri di routing specifici. L'identità in Google Cloud non si basa esclusivamente sull'indirizzo IP della subnet.
Alcune funzionalità VPC, tra cui Cloud NAT, Private Google Access, log di flusso VPC, e intervalli IP alias, sono configurate per subnet. Se hai bisogno di un controllo più granulare di queste funzionalità, utilizza subnet aggiuntive.
Singola rete VPC e VPC condiviso
Inizia con una singola rete VPC per le risorse che hanno requisiti comuni.
Utilizza il VPC condiviso per l'amministrazione di più gruppi di lavoro.
Concedi il ruolo di utente di rete a livello di subnet.
Utilizza un singolo progetto host se le risorse richiedono più interfacce di rete.
Utilizza più progetti host se i requisiti delle risorse superano la quota di un singolo progetto.
Utilizza più progetti host se hai bisogno di criteri di amministrazione separati per ogni VPC.
Inizia con una singola rete VPC per le risorse che hanno requisiti comuni
Per molti casi d'uso semplici, una singola rete VPC fornisce le funzionalità di cui hai bisogno, mentre è più facile da creare, mantenere e comprendere rispetto alle alternative più complesse. Raggruppando le risorse con requisiti e caratteristiche comuni in un'unica rete VPC, inizi a stabilire il confine della rete VPC come perimetro per potenziali problemi.
Per un esempio di questa configurazione, consulta l'architettura di riferimento progetto singolo, rete VPC singola.
I fattori che potrebbero portarti a creare reti VPC aggiuntive includono scalabilità, sicurezza di rete, considerazioni finanziarie, requisiti operativi e Identity and Access Management (IAM).
Utilizza il VPC condiviso per l'amministrazione di più gruppi di lavoro
Per le organizzazioni con più team, il VPC condiviso fornisce uno strumento efficace per estendere la semplicità dell'architettura di una singola rete VPC su più gruppi di lavoro. L'approccio più semplice prevede l'esecuzione del deployment di un singolo progetto host del VPC condiviso con una singola rete VPC condivisa e poi il collegamento dei progetti di servizio del team alla rete del progetto host.
In questa configurazione, i criteri di rete e il controllo per tutte le risorse di networking sono centralizzati e più facili da gestire. I reparti dei progetti di servizio possono configurare e gestire le risorse non di rete, in modo da avere una chiara separazione delle responsabilità per diversi team dell'organizzazione.
Le risorse in questi progetti possono comunicare tra loro in modo più sicuro ed efficiente oltre i confini dei progetti utilizzando indirizzi IP interni. Puoi gestire risorse di rete condivise, come subnet, route e firewall, da un progetto host centrale, in modo da applicare criteri di rete coerenti su tutti i progetti.
Per un esempio di questa configurazione, consulta l'architettura di riferimento Un progetto host, più progetti di servizio, un solo VPC condiviso.
Concedi il ruolo di utente di rete a livello di subnet
L'amministratore VPC condiviso centralizzato può concedere ai membri il ruolo Utente di rete
(networkUser)
a livello di subnet, per un'autorizzazione granulare del progetto di servizio, o per tutte le subnet a livello di progetto host.
Seguendo il principio del privilegio minimo, ti consigliamo di concedere il ruolo utente di rete a livello di subnet all'utente, al account di servizio o al gruppo associato.
Poiché le subnet sono regionali, questo controllo granulare ti consente di specificare le regioni che ogni progetto di servizio può utilizzare per il deployment delle risorse.
Con le architetture VPC condiviso, hai anche la flessibilità di eseguire il deployment di più progetti host VPC condiviso all'interno della tua organizzazione. Ogni progetto host VPC condiviso può quindi ospitare una o più reti VPC condivise. In questa configurazione, ambienti diversi possono applicare criteri diversi.
Per saperne di più, consulta Ruoli IAM per il networking.
Utilizza un unico progetto host se le risorse richiedono più interfacce di rete
Se hai un progetto di servizio che deve eseguire il deployment di risorse in più reti VPC isolate, ad esempio istanze VM con più interfacce di rete, il progetto host deve contenere tutte le reti VPC che forniscono i servizi. Questo perché un progetto di servizio può essere collegato a un solo progetto host.
Utilizza più progetti host se i requisiti delle risorse superano la quota di un singolo progetto
Nei casi in cui i requisiti di risorse aggregate di tutte le reti VPC non possono essere soddisfatti all'interno della quota di un progetto, utilizza un'architettura con più progetti host con una singola retVPC condivisosa per progetto host, anziché un singolo progetto host con più reVPC condivisoise. È importante valutare i requisiti di scalabilità, perché l'utilizzo di un singolo progetto host richiede più reti VPC nel progetto host e le quote vengono applicate a livello di progetto.
Per un esempio di questa configurazione, consulta l'architettura di riferimento per più progetti host, più progetti di servizio e più VPC condivisi.
Utilizza più progetti host se hai bisogno di criteri amministrativi separati per ogni rete VPC
Poiché ogni progetto ha la propria quota, utilizza un progetto host VPC condiviso separato per ogni rete VPC per scalare le risorse aggregate. In questo modo, ogni rete VPC può avere autorizzazioni IAM separate per la gestione di networking e sicurezza, poiché le autorizzazioni IAM vengono implementate anche a livello di progetto. Ad esempio, se esegui il deployment di due reti VPC (rete VPC A e rete VPC B) nello stesso progetto host, il ruolo di amministratore di rete (networkAdmin) si applica a entrambe le reti VPC.
Decidere se creare più reti VPC
Crea una singola rete VPC per progetto per mappare le quote di rete VPC ai progetti.
Crea una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune.
Crea reti VPC in progetti diversi per controlli IAM indipendenti.
Isola i dati sensibili nella propria rete VPC.
Crea una singola rete VPC per progetto per mappare le quote delle risorse VPC ai progetti
Le quote sono vincoli applicati a livello di progetto o di rete. Tutte le risorse hanno una quota predefinita iniziale pensata per proteggerti da un utilizzo imprevisto delle risorse. Tuttavia, molti fattori potrebbero portarti a richiedere una quota maggiore. Per la maggior parte delle risorse, puoi richiedere una quota aggiuntiva.
Ti consigliamo di creare una singola rete VPC per progetto se prevedi di superare le quote di risorse VPC predefinite. In questo modo è più facile mappare gli aumenti di quota a livello di progetto a ogni rete VPC anziché a una combinazione di reti VPC nello stesso progetto.
I limiti sono progettati per proteggere le risorse di sistema in forma aggregata. In genere i limiti non possono essere aumentati facilmente, anche se i team diGoogle Cloud assistenza e vendita possono collaborare con te per aumentare alcuni limiti.
Consulta la pagina Quote e limiti delle risorse VPC per i valori attuali.
L'assistenza Google può aumentare alcuni limiti di scalabilità, ma a volte potrebbe essere necessario creare più reti VPC per soddisfare i requisiti di scalabilità. Se la tua rete VPC deve essere scalata oltre i limiti, discuti il tuo caso con i team di vendita e assistenzaGoogle Cloud per trovare l'approccio migliore per le tue esigenze.
Crea una rete VPC per ogni team autonomo, con servizi condivisi in una rete VPC comune
Alcune implementazioni di grandi aziende coinvolgono team autonomi che richiedono il controllo completo delle rispettive reti VPC. Puoi soddisfare questo requisito creando una rete VPC per ogni unità aziendale, con servizi condivisi in una rete VPC comune (ad esempio strumenti di analisi, pipeline CI/CD e macchine di compilazione, servizi DNS/directory).
Crea reti VPC in progetti diversi per controlli IAM indipendenti
networkAdminsecurityAdminnetworkUsernetworkViewer
Per impostazione predefinita, i controlli IAM vengono implementati a livello di progetto e ogni ruolo IAM si applica a tutte le reti VPC all'interno del progetto.
Se hai bisogno di controlli IAM indipendenti per ogni rete VPC, crea le reti VPC in progetti diversi.
Se hai bisogno di ruoli IAM con ambito limitato a risorse Compute Engine specifiche, come istanze VM, dischi e immagini, utilizza le policy IAM per le risorse Compute Engine.
Isolare i dati sensibili nella propria rete VPC
Per le aziende che si occupano di iniziative di conformità, dati sensibili o dati altamente regolamentati vincolati a standard di conformità come HIPAA o PCI-DSS, spesso sono utili ulteriori misure di sicurezza. Un metodo che può migliorare la sicurezza e semplificare la dimostrazione della conformità consiste nell'isolare ciascuno di questi ambienti nella propria rete VPC.
Connessione di più reti VPC
Scegli il metodo di connessione VPC più adatto alle tue esigenze di costi, prestazioni e sicurezza.
Utilizza gli spoke VPC di Network Connectivity Center.
Utilizza il peering di rete VPC se devi inserire NVA o se la tua applicazione non supporta Private Service Connect.
Utilizza il routing esterno se non hai bisogno della comunicazione tramite indirizzi IP privati.
Utilizza Cloud VPN per connettere le reti VPC che ospitano punti di accesso al servizio non raggiungibili in modo transitivo tramite Network Connectivity Center.
Utilizza appliance virtuali multi-NIC per controllare il traffico tra le reti VPC tramite un dispositivo cloud.
Scegli il metodo di connessione VPC che soddisfa le tue esigenze di costi, prestazioni e sicurezza
Il passaggio successivo dopo aver deciso di implementare più reti VPC è connettere queste reti VPC. Le reti VPC sono spazi tenant isolati all'interno della SDN Andromeda di Google, ma esistono diversi modi per abilitare la comunicazione tra loro. Le sezioni successive forniscono le best practice per la scelta di un metodo di connessione VPC.
I vantaggi e gli svantaggi di ciascun metodo sono riepilogati nella tabella seguente e le sezioni successive forniscono le best practice per la scelta di un metodo di connessione VPC.
| Vantaggi | Svantaggi | |
|---|---|---|
| Spoke VPC di Network Connectivity Center |
|
|
| Peering di rete VPC |
|
|
| Routing esterno (IP pubblico o gateway NAT) |
|
|
| Cloud VPN |
|
|
| Interfacce di rete multiple (multi-NIC) |
|
|
Utilizza gli spoke VPC di Network Connectivity Center
Ti consigliamo di utilizzare gli spoke VPC di Network Connectivity Center quando devi connettere le reti VPC. Gli spoke VPC di Network Connectivity Center consentono il riutilizzo degli indirizzi tra i VPC nello stesso progetto e nella stessa organizzazione o in un progetto e un'organizzazione diversi.
Gli spoke VPC di Network Connectivity Center sono il metodo preferito per connettere le reti VPC per i seguenti motivi:
- Il piano dati è distribuito, quindi non si verifica un collo di bottiglia del gateway. Il traffico attraversa le reti VPC come se le VM si trovassero nella stessa rete VPC.
- Connettività tra reti in diverse organizzazioni. Le reti includono VPC e reti esterne.
- Fino a 250 reti VPC per hub.
- Raggiungibilità transitiva tra i VPC dei punti di accesso al servizio.
- Cloud NAT inter-VPC integrato per consentire il riutilizzo degli indirizzi IP tra i VPC.
- Definisci regole di raggiungibilità di rete utilizzando topologie preimpostate e filtri dei prefissi.
Utilizza il peering di rete VPC se devi inserire NVA o se la tua applicazione non supporta Private Service Connect
Ti consigliamo di utilizzare il peering di rete VPC se devi inserire appliance virtuali di rete (NVA), ad esempio VM firewall. Potresti dover inserire NVA per il traffico che attraversa più reti VPC o per la connettività privata ai servizi non pubblicati utilizzando Private Service Connect.
Quando utilizzi il peering di rete VPC, assicurati che i totali delle risorse necessarie per tutti i peer connessi direttamente non superino i limiti per le istanze VM, il numero di connessioni di peering e le regole di forwarding interno.
Il peering di rete VPC consente a due reti VPC di connettersi internamente tramite la SDN di Google, indipendentemente dal fatto che appartengano allo stesso progetto o alla stessa organizzazione. Il peering di rete VPC unisce il piano di controllo e la propagazione del flusso tra ogni peer, consentendo le stesse caratteristiche di forwarding come se tutte le VM si trovassero nella stessa rete VPC. Quando le reti VPC sono in peering, tutte le subnet, gli intervalli IP alias e le regole di forwarding interno sono accessibili e ogni rete VPC mantiene il proprio firewall distribuito. Il peering di rete VPC non è transitivo.
Utilizza il routing esterno se non hai bisogno della comunicazione con indirizzi IP privati
Se non hai bisogno della comunicazione con indirizzi IP privati, puoi utilizzare il routing esterno con indirizzi IP esterni o un gateway NAT.
Quando viene implementata una rete VPC, viene eseguito il provisioning di una route al gateway internet predefinito di Google con una priorità di 1000. Se questa route esiste e a una VM viene assegnato un indirizzo IP esterno, le VM possono inviare traffico in uscita (egresso) tramite il gateway internet di Google. Puoi anche eseguire il deployment dei servizi dietro una delle numerose offerte di bilanciamento del carico pubblico di Google, che consente di raggiungere i servizi esternamente.
Le VM con indirizzo esterno comunicano tra loro in privato tramite il backbone di Google, indipendentemente dalla regione e dai livelli di servizio di rete. Utilizza le regole firewall di Google Cloud per controllare il traffico in entrata (ingress) esterno alle tue VM.
Il routing esterno è una buona opzione per la scalabilità, ma è importante capire come il routing pubblico influisce sui costi. Per maggiori dettagli, consulta la documentazione sui prezzi di rete.
Utilizza Cloud VPN per connettere le reti VPC che ospitano punti di accesso al servizio non raggiungibili in modo transitivo tramite Network Connectivity Center
La VPN ad alta disponibilità fornisce un servizio gestito per connettere le reti VPC creando tunnel IPsec tra set di endpoint. Se configuri i router Cloud con la modalità di annuncio personalizzata, puoi abilitare il routing transitivo tra le reti VPC e le topologie hub e spoke, come descritto più avanti in questo documento. Utilizzando Network Connectivity Center, puoi utilizzare i tunnel VPN ad alta disponibilità come rete di transito tra le reti on-premise, come spiegato nella documentazione di Cloud VPN.
Cloud VPN non supporta MTU di grandi dimensioni. Per maggiori dettagli, vedi Considerazioni sulla MTU.
Utilizza appliance virtuali per controllare il traffico tra le reti VPC tramite un dispositivo cloud
Le VM con più interfacce di rete sono comuni per le reti VPC che richiedono servizi o sicurezza aggiuntivi tra loro, perché consentono alle istanze VM di colmare la comunicazione tra le reti VPC.
A una VM è consentito avere una sola interfaccia per ogni rete VPC a cui si connette. Per eseguire il deployment di una VM in più reti VPC, devi disporre dell'autorizzazione IAM appropriata per ogni rete VPC a cui si connette la VM.
Quando esegui il deployment di una VM con più interfacce di rete, tieni presente le seguenti caratteristiche:
- Una VM con più NIC può avere un massimo di 8 interfacce.
- Gli intervalli IP delle subnet delle interfacce non devono sovrapporsi.
Connettività del servizio
Private Service Connect consente ai consumer di accedere ai servizi privatamente dall'interno della propria rete VPC senza la necessità di un modello di deployment orientato alla rete. Allo stesso modo, consente ai producer di ospitare questi servizi nelle proprie reti VPC separate e di offrire una connessione privata ai propri consumer all'interno della stessa organizzazione o tra organizzazioni diverse. Private Service Connect consente la connettività ai servizi gestiti di prima e terza parte, il che elimina la necessità di allocazione delle subnet per l'accesso privato ai servizi e il peering di rete VPC.
Private Service Connect offre un modello di sicurezza incentrato sui servizi con i seguenti vantaggi:
- Nessuna dipendenza condivisa
- Autorizzazione esplicita
- Prestazioni a velocità di linea
Private Service Connect è disponibile in diversi tipi che forniscono funzionalità e modalità di comunicazione diverse:
- Endpoint Private Service Connect: gli endpoint vengono implementati utilizzando regole di forwarding che forniscono al consumer un indirizzo IP mappato al servizio Private Service Connect.
- Backend Private Service Connect: i backend vengono implementati utilizzando i gruppi di endpoint di rete (NEG) che consentono ai consumer di indirizzare il traffico al proprio bilanciatore del carico prima che raggiunga un servizio Private Service Connect. Se i backend vengono implementati con un bilanciatore del carico HTTPS, possono supportare i certificati.
- Interfacce Private Service Connect: le interfacce consentono al consumer e al producer di generare traffico, il che abilita la comunicazione bidirezionale. Le interfacce possono essere utilizzate nella stessa rete VPC di endpoint e backend.
Un'alternativa a Private Service Connect è l'accesso privato ai servizi, che consente ai consumer di connettere i servizi del producer tramite il peering di rete VPC. Quando utilizzi l'accesso privato ai servizi, ti consigliamo di prendere in considerazione l'allocazione IP per ogni servizio producer, la sovrapposizione di IP e la quota condivisa.
Progettazione ibrida: connessione di un ambiente on-premise
Utilizza il routing dinamico, se possibile.
Utilizza una rete VPC di connettività per scalare un'architettura hub-and-spoke con più reti VPC.
Dopo aver identificato la necessità di una connettività ibrida e aver scelto una soluzione che soddisfi i requisiti di larghezza di banda, prestazioni e sicurezza, valuta come integrarla nella progettazione della tua VPC.
L'utilizzo del VPC condiviso elimina la necessità che ogni progetto replichi la stessa soluzione. Ad esempio, quando integri una soluzione Cloud Interconnect in un VPC condiviso, tutte le VM, indipendentemente dalla regione o dal progetto di servizio, possono accedere alla connessione Cloud Interconnect.
Utilizza il routing dinamico, se possibile
Il routing dinamico è disponibile in tutte le soluzioni ibride, tra cui VPN ad alta disponibilità, VPN classica, Dedicated Interconnect e Partner Interconnect. Il routing dinamico utilizza router Cloud di Google come speaker Border Gateway Protocol (BGP) per fornire il routing eBGP (External BGP) dinamico.
Il router Cloud non si trova nel piano dati; crea solo route nella SDN.
Il routing dinamico non utilizza tag e il router Cloud non riannuncia mai i prefissi appresi.
Puoi abilitare una delle due modalità del router Cloud, regionale o globale, su ogni rete VPC. Se scegli il routing regionale, router Cloud pubblicizza solo le subnet che si trovano nella regione in cui è implementatrouter Clouder. Il routing globale, d'altra parte, pubblicizza tutte le subnet della rete VPC specificata, indipendentemente dalla regione, ma penalizza le route pubblicizzate e apprese al di fuori della regione. In questo modo viene mantenuta la simmetria all'interno della regione preferendo sempre un'interconnessione locale. Il valore viene calcolato aggiungendo una metrica di penalità (MED) pari a 200 + TTL in millisecondi tra le regioni.
Routing statico
Il routing statico è disponibile solo sulla VPN classica. Il routing statico offre la possibilità di impostare una route di hop successivo che punta a un tunnel Cloud VPN.
Per impostazione predefinita, una route statica si applica a tutte le VM nella rete, indipendentemente dalla regione. Il routing statico consente inoltre agli amministratori di rete di impostare in modo selettivo a quali VM si applica la route utilizzando i tag istanza, che possono essere specificati quando crei una route.
Le route statiche vengono applicate a livello globale all'interno della rete VPC, con la stessa priorità di route. Pertanto, se hai più tunnel in più regioni con lo stesso prefisso e la stessa priorità, una VM utilizzerà ECMP basato sull'hash a 5 tuple in tutti i tunnel. Per ottimizzare questa configurazione, puoi creare un percorso preferito nella regione facendo riferimento ai tag delle istanze per ogni regione e creando i percorsi preferiti di conseguenza.
Se non vuoi che il traffico in uscita (egresso) passi attraverso il gateway internet predefinito di Google, puoi impostare una route statica predefinita preferita per inviare tutto il traffico di nuovo on-premise tramite un tunnel.
Utilizza una rete VPC di connettività per scalare un'architettura hub e spoke con più reti VPC
Se devi scalare un'architettura hub-and-spoke con più reti VPC, configura la connettività ibrida centralizzata in una o più reti VPC dedicate, quindi aggiungi le connessioni ibride e tutti gli spoke VPC a un hub Network Connectivity Center. Devi attivare lo scambio di route con gli spoke VPC. Questa configurazione consente di esportare route statiche o apprese dinamicamente negli spoke VPC per fornire una configurazione centralizzata e scalare in base alla progettazione della rete VPC.
Il seguente diagramma illustra una progettazione della connettività ibrida centralizzata utilizzando Network Connectivity Center:
In alternativa, puoi utilizzare il peering di rete VPC e le route pubblicizzate personalizzate per fornire l'accesso alle connessioni ibride condivise, se non superi i limiti delle risorse e richiedi l'utilizzo di NVA.
Il seguente diagramma illustra la connettività ibrida centralizzata con route personalizzate di peering di rete VPC:
Questo design centralizzato è in contrasto con l'implementazione della connettività ibrida convenzionale, che utilizza tunnel VPN o collegamenti VLAN in ogni singola rete VPC.
Sicurezza della rete
Identifica obiettivi di sicurezza chiari.
Limita l'accesso esterno.
Definisci i perimetri di servizio per i dati sensibili.
Gestisci il traffico con le regole firewall Google Cloud , se possibile.
Utilizzare se possibile un numero inferiore di insiemi di regole firewall più ampi.
Isola le VM utilizzando i service account, se possibile.
Utilizza l'automazione per monitorare i criteri di sicurezza quando utilizzi i tag.
Utilizza strumenti aggiuntivi per proteggere le tue app.
Google Cloud fornisce solide funzionalità di sicurezza per la sua infrastruttura e i suoi servizi, dalla sicurezza fisica dei data center e hardware di sicurezza personalizzato a team dedicati di ricercatori. Tuttavia, la protezione delle tue risorseGoogle Cloud è una responsabilità condivisa. Devi adottare misure appropriate per contribuire a garantire la protezione delle tue app e dei tuoi dati.
Identificare obiettivi di sicurezza chiari
Prima di valutare i controlli di sicurezza cloud-native o cloud-capable, inizia con una serie di obiettivi di sicurezza chiari che tutte le parti interessate concordano come parte fondamentale del prodotto. Questi obiettivi devono enfatizzare la fattibilità, la documentazione e l'iterazione, in modo che possano essere consultati e migliorati durante lo sviluppo.
Limitare l'accesso esterno
Quando crei una risorsa Google Cloud che utilizza una rete VPC, scegli una rete e una subnet in cui risiede la risorsa. Alla risorsa viene assegnato un indirizzo IP interno da uno degli intervalli IP associati alla subnet. Le risorse in una rete VPC possono comunicare tra loro tramite indirizzi IP interni se le regole firewall lo consentono.
Limita l'accesso a internet solo alle risorse che ne hanno bisogno. Le risorse con solo un indirizzo IP interno privato possono comunque accedere a molte API e servizi Google tramite Private Service Connect o l'accesso privato Google. L'accesso privato consente alle risorse di interagire con i servizi Google e Google Cloud chiave rimanendo isolate da internet pubblico.
Inoltre, utilizza i criteri dell'organizzazione per limitare ulteriormente le risorse autorizzate a utilizzare indirizzi IP esterni.
Per consentire alle VM di accedere a internet, utilizza Secure Web Proxy se il traffico può essere scaricato tramite HTTP(S) e vuoi implementare controlli dell'identità. Altrimenti, utilizza Cloud NAT.
Definisci i perimetri di servizio per i dati sensibili
Per i carichi di lavoro che coinvolgono dati sensibili, utilizza i controlli di servizio VPC per configurare i perimetri di servizio attorno alle risorse VPC e ai servizi gestiti da Google e controllare lo spostamento dei dati oltre il confine del perimetro. Utilizzando i Controlli di servizio VPC, puoi raggruppare i progetti e la tua rete on-premise in un unico perimetro che impedisce l'accesso ai dati tramite i servizi gestiti da Google. I perimetri di servizio non possono contenere progetti di organizzazioni diverse, ma puoi utilizzare i bridge di perimetro per consentire la comunicazione tra progetti e servizi in perimetri di servizio diversi.
Gestisci il traffico con le regole firewall, se possibile Google Cloud
Google Cloud VPC include un firewall stateful scalabile orizzontalmente e applicato a ogni VM in modo distribuito. Per i dettagli, consulta la panoramica di Cloud NGFW.
Google Cloud Marketplace offre un ampio ecosistema di soluzioni di terze parti, incluse le VM che forniscono sicurezza avanzata, ad esempio protezione da perdite di informazioni, exploit di applicazioni e escalation di privilegi, rilevano minacce note e sconosciute e applicano il filtro URL. Esistono anche vantaggi operativi nell'avere un unico fornitore che implementa i criteri in tutti i fornitori di servizi cloud e gli ambienti on-premise.
Il traffico viene in genere indirizzato a queste VM specificando le route, con la stessa priorità (per distribuire il traffico utilizzando un hash a 5 tuple) o con priorità diverse (per creare un percorso ridondante), come mostrato nei più percorsi alla subnet Dev nel seguente diagramma.
La maggior parte delle soluzioni richiede VM con più interfacce di rete. Poiché una VM non può avere più di un'interfaccia per rete VPC, quando crei una VM con più interfacce di rete, ogni interfaccia deve essere collegata a una rete VPC separata.
La scalabilità è un aspetto importante da considerare anche quando implementi soluzioni di terze parti nella tua rete VPC per i seguenti motivi:
- Limiti: la maggior parte delle appliance basate su VM deve essere inserita nel percorso dei dati. Ciò richiede una VM con più interfacce di rete che collegano più reti VPC che si trovano nello stesso progetto. Poiché le quote delle risorse VPC sono impostate a livello di progetto, le esigenze aggregate delle risorse in tutte le reti VPC possono diventare limitanti.
- Prestazioni: l'introduzione di un unico punto di strozzatura basato su VM negli attributi di scalabilità orizzontale completa di una rete VPC va contro le metodologie di progettazione del cloud. Per risolvere questo problema, puoi inserire più appliance virtuali di rete (NVA) in un gruppo di istanze gestite dietro un bilanciatore del carico di rete passthrough interno.
Per tenere conto di questi fattori nelle architetture dei requisiti di scalabilità elevata, esegui il push dei controlli di sicurezza negli endpoint. Inizia proteggendo le tue VM e utilizzando le regole firewall. Google CloudQuesta strategia può anche comportare l'introduzione di agenti di ispezione degli endpoint basati sull'host che non modificano l'architettura di inoltro della rete VPC tramite VM con più interfacce di rete.
Per un altro esempio di questa configurazione, consulta l'architettura di riferimento del firewall L7 stateful tra reti VPC.
Utilizzare se possibile un numero inferiore di insiemi di regole firewall più ampi
Su qualsiasi VM può essere programmato solo un certo numero di regole. Tuttavia, puoi combinare molte regole in una definizione di regola complessa. Ad esempio, se tutte le VM nella rete VPC devono consentire esplicitamente 10 porte TCP in entrata, hai due opzioni: scrivere 10 regole separate, ognuna delle quali definisce una singola porta, oppure definire una singola regola che includa tutte e 10 le porte. Definire una singola regola che includa tutte e 10 le porte è l'opzione più efficiente.
Crea un insieme di regole generico che si applichi all'intera rete VPC, quindi utilizza insiemi di regole più specifici per raggruppamenti più piccoli di VM utilizzando i target. In altre parole, inizia definendo regole generali e definisci progressivamente regole più specifiche in base alle esigenze:
- Applica regole firewall comuni a tutte le VM nella rete VPC.
- Applica regole firewall che possono essere raggruppate in più VM, ad esempio un gruppo di istanze di servizio o una subnet.
- Applica regole firewall a singole VM, ad esempio un gateway NAT o un host bastion.
Isolare le VM utilizzando i service account, se possibile
Molte organizzazioni hanno ambienti che richiedono regole specifiche per un sottoinsieme delle VM in una rete VPC. In questi casi, puoi adottare due approcci comuni: l'isolamento della subnet e il filtraggio dei target.
Isolamento della subnet
Con l'isolamento delle subnet, la subnet forma il limite di sicurezza a cui vengono applicate le regole firewall. Google Cloud Questo approccio è comune nei costrutti di networking on-premise e nei casi in cui gli indirizzi IP e il posizionamento di rete fanno parte dell'identità della VM.
Puoi identificare le VM in una subnet specifica applicando un tag, un tag di rete o un account di servizio univoco a queste istanze. In questo modo puoi creare regole firewall che si applicano solo alle VM in una subnet, ovvero quelle con il tag, il tag di rete o iaccount di serviziont associato. Ad esempio, per creare una regola firewall che consenta tutta la comunicazione tra le VM nella stessa subnet, puoi utilizzare la seguente configurazione della regola nella pagina Regole firewall:
- Target: Tag di destinazione specificati
- Tag di destinazione: subnet-1
- Filtro di origine: subnet
- Subnet: seleziona la subnet per nome (ad esempio subnet-1).
Filtro delle destinazioni
Con il filtro di destinazione, tutte le VM si trovano nella stessa subnet o fanno parte di un insieme arbitrario di subnet. Con questo approccio, l'appartenenza alla subnet non è considerata parte dell'identità dell'istanza per le regole firewall. Puoi invece utilizzare tag, tag di rete o service account per limitare l'accesso tra le VM nella stessa subnet. A ogni gruppo di VM che utilizza le stesse regole firewall viene applicato lo stesso tag di rete.
Per illustrare questo concetto, considera un'applicazione a tre livelli (web, app, database) per la quale tutte le istanze vengono implementate nella stessa subnet. Il livello web può
comunicare con gli utenti finali e il livello app, e il livello app può comunicare
con il livello database, ma non è consentita nessun'altra comunicazione tra i livelli. Le istanze
che eseguono il livello web hanno un tag di rete web, le istanze
che eseguono il livello app hanno un tag di rete app e le istanze che eseguono
il livello database hanno un tag di rete db.
Le seguenti regole firewall implementano questo approccio:
| Regola 1: Consenti agli utenti finali → livello web | Target: Tag di destinazione specificati Tag di destinazione: web Filtro di origine: intervalli IP Intervalli IP di origine: 0.0.0.0/0 |
| Regola 2: autorizzazione livello web → livello app | Target: Tag di destinazione specificati Tag di destinazione: app Filtro origine: Tag di origine Tag di origine: web |
| Regola 3: autorizzazione livello app → livello database | Target: Tag di destinazione specificati Tag di destinazione: db Filtro origine: Tag di origine Tag di origine: app |
Tuttavia, anche se è possibile utilizzare i tag di rete per il filtraggio dei target in questo modo, ti consigliamo di utilizzare i tag o gli account di servizio, se possibile. I tag target
non sono controllati dall'accesso e possono essere modificati da chiunque abbia il ruolo instanceAdmin
mentre le VM sono in servizio. I tag e i service account sono controllati dall'accesso, il che significa
che un utente specifico deve essere autorizzato esplicitamente a utilizzare unaccount di serviziot.
Può esistere un solo account di servizio per istanza, mentre possono esserci
più tag. Inoltre, i service account assegnati a una VM possono essere modificati solo quando
la VM è arrestata.
Utilizzare l'automazione per monitorare i criteri di sicurezza quando si utilizzano i tag
Se utilizzi i tag di rete, ricorda che un amministratore dell'istanza può modificarli. In questo modo è possibile aggirare i criteri di sicurezza. Pertanto, se utilizzi i tag di rete in un ambiente di produzione, utilizza un framework di automazione per superare la mancanza di governance IAM sui tag di rete.
Utilizzare strumenti aggiuntivi per proteggere le tue app
Oltre alle regole firewall, utilizza questi strumenti aggiuntivi per proteggere le tue app:
- Utilizza un Google Cloud bilanciatore del carico HTTP(S) globale per supportare l'alta disponibilità e la normalizzazione del protocollo.
- Integra Google Cloud Armor con il bilanciatore del carico HTTP(S) per fornire protezione DDoS e la possibilità di bloccare o consentire indirizzi IP al perimetro di rete.
- Controlla l'accesso alle app utilizzando IAP (IAP) per verificare l'identità dell'utente e il contesto della richiesta per determinare se concedere l'accesso a un utente.
- Fornisci un'unica interfaccia per approfondimenti sulla sicurezza, rilevamento di anomalie e rilevamento di vulnerabilità con Security Command Center.
Servizi di rete: NAT e DNS
Utilizza indirizzi IP esterni fissi con Cloud NAT.
Riutilizza gli indirizzi IP tra i VPC con Cloud NAT.
Utilizza zone DNS private per la risoluzione dei nomi.
Utilizza indirizzi IP esterni fissi con Cloud NAT
Se hai bisogno di indirizzi IP esterni fissi da un intervallo di VM, utilizza Cloud NAT. Un esempio di motivo per cui potresti aver bisogno di indirizzi IP in uscita fissi è il caso in cui una terza parte consente richieste da indirizzi IP esterni specifici. L'utilizzo di Cloud NAT ti consente di avere un numero ridotto di indirizzi IP NAT per ogni regione utilizzati per le comunicazioni in uscita.
Cloud NAT consente inoltre alle istanze VM di comunicare su internet senza disporre di indirizzi IP esterni propri. Google Cloud Le regole firewall sono stateful. Ciò significa che se una connessione è consentita tra un'origine e una destinazione o viceversa, tutto il traffico successivo in entrambe le direzioni sarà consentito finché la connessione è attiva. In altre parole, le regole firewall consentono la comunicazione bidirezionale dopo che è stata stabilita una sessione.
Riutilizzare gli indirizzi IP in più VPC con Cloud NAT
Gli indirizzi IP possono essere riutilizzati in più VPC quando è abilitato Cloud NAT per Network Connectivity Center. Cloud NAT tra VPC è disponibile quando i VPC sono connessi utilizzando gli spoke VPC di Network Connectivity Center. Se gli indirizzi IP VPC si sovrappongono agli intervalli nelle reti esterne, attiva NAT ibrido. Vengono tradotte solo le connessioni avviate dai carichi di lavoro in Google Cloud verso le reti esterne.
Utilizza zone DNS private per la risoluzione dei nomi
Utilizza zone private su Cloud DNS per consentire la risoluzione dei tuoi servizi con DNS all'interno della tua rete VPC utilizzando i relativi indirizzi IP interni senza esporre questo mapping all'esterno.
Utilizza il DNS split horizon per mappare i servizi a indirizzi IP diversi dall'interno della rete VPC rispetto all'esterno. Ad esempio, puoi avere un servizio esposto tramite il bilanciamento del carico di rete da internet pubblico, ma avere un bilanciamento del carico interno che fornisce lo stesso servizio utilizzando lo stesso nome DNS dall'interno della rete VPC.
Accesso API per i servizi gestiti da Google
Utilizza il gateway internet predefinito, se possibile.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita.
Esegui il deployment di istanze che utilizzano le API di Google nella stessa subnet.
Utilizza il gateway internet predefinito, se possibile
L'accesso dalle risorse all'interno della rete VPC alle API di Google segue l'hop successivo del gateway internet predefinito. Nonostante il nome del gateway di hop successivo, il percorso del traffico dalle istanze alle API di Google rimane all'interno della rete di Google.
Per impostazione predefinita, solo le istanze VM con un indirizzo IP esterno possono comunicare con le API e i servizi Google. Se hai bisogno dell'accesso da istanze senza un indirizzo IP esterno, configura gli endpoint Private Service Connect o utilizza la funzionalità di accesso privato Google per ogni subnet. Ciò non rallenta le comunicazioni per le API di Google.
Google Kubernetes Engine (GKE) abilita automaticamente l'accesso privato Google sulle subnet in cui vengono implementati i nodi. Tutti i nodi di queste subnet senza un indirizzo IP esterno sono in grado di accedere ai servizi gestiti da Google.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita
Se devi modificare la route predefinita, aggiungi route esplicite per gli intervalli di indirizzi IP di destinazione dell'API Google.
Negli ambienti in cui la route predefinita (0.0.0.0/0) non utilizza l'hop successivo del gateway internet predefinito, configura route esplicite per gli intervalli di indirizzi IP di destinazione utilizzati dalle API di Google. Imposta l'hop successivo delle route esplicite sul gateway
internet predefinito. Un esempio di questo scenario si verifica quando devi ispezionare tutto
il traffico tramite un dispositivo on-premise.
Esegui il deployment di istanze che utilizzano le API di Google nella stessa subnet
Esegui il deployment delle istanze che richiedono l'accesso alle API e ai servizi Google sulla stessa subnet e abilita l'accesso privato Google per le istanze senza indirizzi IP esterni. In alternativa, configura gli endpoint Private Service Connect.
Se accedi alle API di Google dal tuo ambiente on-premise utilizzando l'accesso privato Google, utilizza Configurazione dell'accesso privato Google per gli host on-premise per accedere ad alcuni servizi Google tramite intervalli di indirizzi IP privati. Prima di attivare questa funzionalità, controlla quali servizi sono supportati, perché l'accesso ad altre API di Google tramite gli indirizzi IP forniti da questo servizio non sarà raggiungibile. L'attivazione di questa funzionalità può richiedere una configurazione DNS aggiuntiva, ad esempio la configurazione delle visualizzazioni DNS.
Se accedi alle API di Google dal tuo ambiente on-premise utilizzando gli endpoint Private Service Connect, consulta Accedere all'endpoint da host on-premise per maggiori dettagli.
Logging, monitoraggio e visibilità
Personalizza la registrazione per casi d'uso specifici e segmenti di pubblico di destinazione.
Aumenta l'intervallo di aggregazione dei log per le reti VPC con connessioni lunghe.
Utilizza il campionamento dei log di flusso VPC per ridurre il volume.
Rimuovi i metadati aggiuntivi quando ti servono solo i dati di IP e porta. Utilizzare Network Intelligence Center per ottenere approfondimenti sulle reti
Personalizzare la registrazione per casi d'uso specifici e segmenti di pubblico di destinazione
Utilizza i log di flusso VPC per il monitoraggio della rete, l'analisi forense, l'analisi della sicurezza in tempo reale e l'ottimizzazione delle spese. Puoi abilitare o disabilitare i log di flusso VPC a livello di subnet. Se i log di flusso VPC sono abilitati per una subnet, raccolgono dati da tutte le istanze VM in quella subnet.
Questi log registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. I tuoi casi d'uso di logging ti aiutano a determinare quali subnet richiedono la registrazione e per quanto tempo.
I log di flusso vengono aggregati per connessione a intervalli di 5 secondi dalle VM Compute Engine e poi esportati in tempo reale. Puoi visualizzare i log di flusso in Cloud Logging ed esportarli in qualsiasi destinazione supportata dalle funzionalità di esportazione di Cloud Logging.
La pagina di importazione dei log in Logging monitora il volume dei log nel tuo progetto e ti consente di disattivare l'importazione di tutti i log o di escludere (eliminare) le voci di log che non ti interessano, in modo da ridurre al minimo gli addebiti per i log che superano l'allocazione mensile.
I log sono una parte fondamentale del successo operativo e della sicurezza, ma non sono utili se non li esamini e non intervieni. Personalizza i log per il pubblico di destinazione, in modo da garantire il successo operativo e di sicurezza per le tue reti VPC.
Per maggiori dettagli, consulta Utilizzo dei log di flusso VPC.
Aumentare l'intervallo di aggregazione dei log per le reti VPC con connessioni lunghe
Per le reti VPC con connessioni per lo più di lunga durata, imposta l'intervallo di aggregazione dei log su 15 minuti per ridurre notevolmente il numero di log generati e per consentire un'analisi più rapida e semplice.
Un esempio di workflow per cui è appropriato aumentare l'intervallo di aggregazione dei log è il monitoraggio della rete, che prevede le seguenti attività:
- Esecuzione della diagnostica di rete
- Filtrare i log di flusso per VM e per applicazioni per comprendere le modifiche al traffico
- Analizzare la crescita del traffico per prevedere la capacità
Utilizza il campionamento dei log di flusso VPC per ridurre il volume
Utilizza il campionamento dei log di flusso VPC per ridurre il volume dei log di flusso VPC, ma potere comunque visualizzare campioni di basso livello e visualizzazioni aggregate.
Un esempio di flusso di lavoro per il quale è appropriato utilizzare il campionamento per ridurre il volume è comprendere l'utilizzo della rete e ottimizzare le spese per il traffico di rete. Questo flusso di lavoro prevede le seguenti attività:
- Stima del traffico tra regioni e zone
- Stima del traffico verso paesi specifici su internet
- Identificare i talker principali
Rimuovere i metadati aggiuntivi quando sono necessari solo i dati di IP e porta
Nei casi d'uso della sicurezza in cui ti interessano solo indirizzi IP e porte, rimuovi i metadati aggiuntivi per ridurre il volume di dati utilizzati in Cloud Logging.
Un esempio di workflow per cui la rimozione dei metadati è appropriata è l'analisi forense della rete, che prevede le seguenti attività:
- Determinare quali IP hanno comunicato con chi e quando
- Identificazione di eventuali indirizzi IP compromessi, rilevati analizzando i flussi di rete
Utilizzare Network Intelligence Center per ottenere informazioni sulle reti
Network Intelligence Center fornisce una console unica per la gestione della visibilità, del monitoraggio e della risoluzione dei problemi di rete. Google Cloud Le sezioni seguenti forniscono dettagli sui componenti di Network Intelligence Center.
Network Topology
Utilizza Network Topology per visualizzare la topologia di rete.
Connectivity Tests
Utilizza Connectivity Tests per diagnosticare i problemi di connettività con le reti VPC.
Performance Dashboard
Utilizza la dashboard delle prestazioni per controllare le prestazioni del networking fisico sottostante alle tue reti virtuali VPC.
Firewall Insights
Utilizza Firewall Insights per comprendere le tue regole firewall e il modo in cui interagiscono.
Network Analyzer
Utilizza Network Analyzer per monitorare le configurazioni di rete VPC e rilevare configurazioni errate e configurazioni non ottimali.
Flow Analyzer
Utilizza Flow Analyzer per comprendere meglio i flussi di traffico VPC.
Architetture di riferimento
Questa sezione mette in evidenza alcune architetture che illustrano alcune delle best practice descritte in questo documento.
Unico progetto, unica rete VPC
Questa architettura di riferimento iniziale include tutti i componenti necessari per implementare architetture ad alta disponibilità in più regioni, con isolamento a livello di subnet e uno SLA del 99,99% per la connessione ai data center on-premise.
Singolo progetto host, più progetti di servizio, singolo VPC condiviso
Basandosi sull'architettura di riferimento iniziale, i progetti host VPC condiviso e più progetti di servizio consentono agli amministratori di delegare le responsabilità amministrative, ad esempio la creazione e la gestione delle istanze, agli amministratori dei progetti di servizio, mantenendo al contempo il controllo centralizzato sulle risorse di rete come subnet, route e firewall.
Più progetti host, più progetti di servizio, più VPC condiviso
Il seguente diagramma illustra un'architettura per l'isolamento VPC, che si basa sul nostro design ad alta disponibilità separando la produzione dagli altri progetti. Esistono molti motivi per prendere in considerazione l'isolamento VPC, tra cui i requisiti di controllo (ad esempio PCI), le considerazioni sulle quote tra gli ambienti o un ulteriore livello di isolamento logico. Sono necessarie solo due interconnessioni (per la ridondanza) per località, ma puoi aggiungere più collegamenti Interconnect a più reti VPC o regioni.
L'utilizzo dell'isolamento può anche introdurre la necessità di replica, in quanto decidi dove inserire i servizi di base come proxy, autenticazione e servizi di directory. L'utilizzo di una rete VPC di servizi condivisi può contribuire a evitare questa replica e consentire di condividere questi servizi con altre reti VPC tramite Network Connectivity Center, centralizzando al contempo l'amministrazione e il deployment.
Firewall L7 stateful tra reti VPC
Questa architettura ha più reti VPC collegate da un'appliance firewall di nuova generazione (NGFW) di livello 7, che funge da bridge multi-NIC tra le reti VPC.
Viene introdotta una rete VPC esterna non attendibile per terminare gli interconnessioni ibride e le connessioni basate su internet che terminano sul segmento esterno del firewall NGFW di livello 7 per l'ispezione. Esistono molte varianti di questo design, ma il principio chiave è filtrare il traffico attraverso il firewall prima che raggiunga le reti VPC attendibili.
Questo design richiede che ogni rete VPC si trovi nel progetto in cui inserisci il NGFW basato su VM. Poiché le quote vengono applicate a livello di progetto, devi considerare l'aggregato di tutte le risorse VPC.
Più reti VPC interconnesse con Network Connectivity Center
Questa architettura ha più reti VPC che si connettono tra loro utilizzando Network Connectivity Center. Viene introdotta una rete VPC di transito per terminare gli interconnessioni ibride e condividere la connettività ibrida in tutti gli altri VPC, evitando la necessità di creare collegamenti VLAN per ogni rete VPC. Questo approccio consolida la connettività esterna e le considerazioni di routing associate. Allo stesso modo, è possibile introdurre una o più reti VPC di servizi condivisi per ospitare servizi comuni come proxy, autenticazione e servizi di directory. Esistono molte varianti di questo progetto, ma il principio chiave è gestire i diversi servizi e tipi di connessione come raggi di un hub Network Connectivity Center che fornisce la connettività any-to-any tra questi. Questa architettura di riferimento è descritta in dettaglio in Connettività inter-VPC di rete cross-cloud utilizzando Network Connectivity Center.
Passaggi successivi
- Cross-Cloud Network per applicazioni distribuite
- Analisi approfondita e best practice di VPC (video di Cloud NEXT'18)
- Topologie di rete ibride e multi-cloud
- Decidi una gerarchia delle risorse per la tua zona di destinazione Google Cloud
- Best practice per la scelta della regione per Compute Engine
- Google Cloud per i professionisti dei data center: networking
- Documentazione VPC
- Panoramica del networking GKE
- Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.