Questa guida illustra le best practice e le architetture aziendali tipiche per la progettazione di Virtual Private Cloud (VPC) con Google Cloud. Questa guida è rivolta agli architetti di rete cloud e architetti di sistema che hanno già familiarità con il networking di Google Cloud concetti.
Principi generali e primi passi
identifica i responsabili decisionali, le tempistiche e le attività preliminari.
Valutare in anticipo la progettazione della rete VPC.
Semplicità.
Utilizza convenzioni di denominazione chiare.
Identifica i responsabili delle decisioni, le tempistiche e le attività preliminari
Come primo passaggio nella progettazione della rete VPC, identifica i responsabili decisionali, le tempistiche e il lavoro preliminare necessari per assicurarti di poter soddisfare i requisiti degli stakeholder.
Gli stakeholder potrebbero includere proprietari di applicazioni, architetti della sicurezza, soluzioni architetti e responsabili operativi. Gli stakeholder potrebbero cambiare a seconda che tu stia pianificando la tua rete VPC per a un progetto, a una linea di business o all'intera organizzazione.
Parte del lavoro preliminare consiste nell'iniziare ad acquisire familiarità con i concetti e la terminologia relativi alla progettazione della rete VPC. I documenti utili includono seguenti:
- Documentazione di Resource Manager
- Documentazione di Cloud Identity and Access Management
- Documentazione di Virtual Private Cloud
Considera in anticipo la progettazione della rete VPC
Rendi la progettazione della rete VPC una parte iniziale della progettazione configurazione organizzativa in Google Cloud. Può essere dannoso per la tua organizzazione se in un secondo momento dovrai modificare aspetti fondamentali come il modo in cui la rete è segmentata o la posizione dei carichi di lavoro.
Configurazioni di rete VPC diverse possono avere implicazioni per il routing, la scalabilità e la sicurezza. Una pianificazione attenta e una conoscenza approfondita delle tue considerazioni specifiche ti aiutano a creare una solida base di architettura per i carichi di lavoro incrementali.
Massima semplicità
Mantenere semplice la progettazione della topologia di rete VPC è il modo migliore per garantire un'architettura gestibile, affidabile e ben compresa.
Usa 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 con la brevità. Utilizzo dell'opzione la terminologia, ove possibile, migliora la leggibilità.
Considera i componenti illustrati nell'esempio seguente quando definisci le convenzioni di denominazione:
- 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 di ambiente:
dev,test,uat,stage,prod
In questo esempio, l'ambiente di sviluppo per il sistema di compensazione del reparto delle risorse umane è denominato acmeco-hr-comp-eu-we1-dev.
Per altre risorse di networking comuni, prendi in considerazione 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 la 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 le subnet in modalità personalizzata nelle reti VPC aziendali.
Raggruppa le applicazioni in un numero inferiore di sottoreti con intervalli di indirizzi più ampi.
Usa reti VPC in modalità personalizzata
Quando avvii il tuo primo progetto, viene impostata la rete predefinita, ovvero una rete VPC in modalità automatica denominata default. Le reti in modalità automatica creano automaticamente subnet e route di subnet corrispondenti i cui intervalli IP principali sono CIDR /20 in ogni regione di Google Cloud utilizzando un insieme prevedibile di intervalli di indirizzi RFC 1918. La rete default include anche alcune regole firewall precompilate.
Sebbene le reti in modalità automatica possano essere utili per le prime esplorazioni, 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 i dispositivi sono connessi con le 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 principali identici.
- Le subnet in modalità automatica hanno tutte lo stesso nome della rete. Puoi scegliere nomi univoci e descrittivi per le subnet in modalità personalizzata, rendendo le reti VPC più comprensibili e gestibili.
- Quando viene introdotta una nuova regione Google Cloud, le reti VPC in modalità automatica ricevono automaticamente una nuova subnet in quella regione. Le reti VPC in modalità personalizzata ricevono nuove subnet solo se specifichi che li rappresentano. Questo può essere importante sia per la sovranità sia per la gestione degli indirizzi IP motivi.
Se non contiene 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 ulteriori dettagli sulle differenze tra la modalità automatica e quella personalizzata per le reti VPC, consulta Panoramica della rete VPC.
Raggruppa le applicazioni in meno subnet con intervalli di indirizzi più ampi
Convenzionalmente, alcune reti aziendali sono separate in molti indirizzi di piccole per vari motivi. Ad esempio, potrebbe essere stato fatto 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, più gestibili con intervalli di indirizzi più ampi nelle regioni 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 un mesh completo di raggiungibilità tra tutte le VM nella rete VPC globale. Il numero di subnet non influisce sul comportamento di routing.
Puoi utilizzare account di servizio o tag di rete per applicare criteri di routing o regole firewall specifici. L'identità in Google Cloud non si basa solo sull'indirizzo IP della subnet.
Alcune funzionalità VPC, tra cui Cloud NAT, Accesso privato Google, Log di flusso VPC e intervalli IP alias, sono configurate per subnet. Se hai bisogno di un controllo più dettagliato di queste funzionalità, per utilizzare subnet aggiuntive.
Rete VPC singola e VPC condiviso
inizia con una singola rete VPC per le risorse con requisiti comuni.
Utilizzare un 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 un'unica rete VPC per le risorse con requisiti comuni
Per molti casi d'uso semplici, una singola rete VPC fornisce le funzionalità necessarie, e al contempo è più facile da creare, mantenere e comprendere rispetto alle applicazioni alternative. 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 progetto singolo, rete VPC singola di riferimento.
Fattori che potrebbero portarti a creare reti VPC aggiuntive includono scalabilità, sicurezza di rete, considerazioni finanziarie, operativi e gestione di identità e accessi (IAM).
Uso di un VPC condiviso per l'amministrazione di più gruppi di lavoro
Per le organizzazioni con più team, VPC condiviso fornisce uno strumento efficace per estendere la semplicità dell'architettura di un singolo in più gruppi di lavoro. L'approccio più semplice prevede l'esecuzione del deployment di un singolo progetto host del VPC condiviso con un singola rete VPC condiviso e quindi collegare i 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 centralizzate 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 in modo efficiente oltre i confini dei progetti usando 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 a tutti i progetti.
Per un esempio di questa configurazione, consulta Singolo progetto host, più progetti di servizio, singolo VPC condiviso di riferimento.
Concedi il ruolo di utente di rete a livello di subnet
L'amministratore centralizzato della VPC condiviso può concedere ai membri IAM l'utente di rete
(networkUser)
a livello di subnet, per un'autorizzazione
dettagliata del progetto di servizio,
o per tutte le subnet a livello di progetto host.
Secondo il principio del privilegio minimo, consigliamo di concedere alla rete a livello di subnet per l'utente, l'account di servizio gruppo.
Poiché le subnet sono a livello di regione, questo controllo granulare ti consente regioni che ogni progetto di servizio può utilizzare per il deployment delle risorse.
Con le architetture VPC condivise, hai anche la flessibilità di eseguire il deployment Progetti host del VPC condiviso all'interno della tua organizzazione. Ogni progetto host VPC condivisa può quindi ospitare una o più reti VPC condivise. In questo automatica, ambienti diversi possono applicare facilmente criteri diversi le preoccupazioni dei clienti.
Per saperne di più, consulta Ruoli IAM per la rete.
Utilizza un singolo 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 non sia possibile soddisfare i requisiti aggregati delle risorse di tutte le reti VPC all'interno della quota di un progetto, utilizza un'architettura con più progetti host con singola rete VPC condiviso per progetto host, anziché un singolo progetto host con in più reti VPC condiviso. È importante valutare i requisiti della bilancia, 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 Più progetti host, più progetti di servizio, più architetture di riferimento VPC condivise.
Utilizza più progetti host se hai bisogno di criteri di amministrazione separati per ogni rete VPC
Poiché ogni progetto ha la propria quota, utilizza un 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 della rete e della 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,
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 in una rete VPC dedicata.
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 rete. Tutte le risorse hanno una quota predefinita iniziale pensata per proteggerti da un utilizzo imprevisto delle risorse. Tuttavia, molti fattori potrebbero indurti 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 crescere oltre quote predefinite delle risorse VPC. 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 del sistema in modo aggregato. In genere, i limiti non possono essere aumentati facilmente, anche se il team di assistenza e di vendita di Google Cloud può collaborare con te per aumentare alcuni limiti.
Consulta Quote e limiti delle risorse VPC per i valori correnti.
L'Assistenza Google può aumentare alcuni limiti di scalabilità, ma a volte può verificarsi anche devi creare più reti VPC per soddisfare i tuoi requisiti di scalabilità. Se la tua rete VPC richiede di andare oltre i limiti, discuti il tuo caso I team di vendita e assistenza di Google Cloud illustrano l'approccio migliore per i tuoi requisiti.
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 build machine, servizi DNS/Directory). Per ulteriori informazioni sulla creazione di una rete VPC comune per i servizi condivisi, consulta la sezione relativa ai servizi condivisi.
Creare reti VPC in progetti diversi per controlli IAM indipendenti
Una rete VPC è una risorsa a livello di progetto con controlli IAM (Identity and Access Management) granulari a livello di progetto, inclusi i seguenti ruoli:
networkAdminsecurityAdminnetworkUsernetworkViewer
Per impostazione predefinita, il deployment dei controlli IAM viene eseguito a livello di progetto e di ogni IAM si applica a tutte le reti VPC all'interno del progetto.
Se hai bisogno di controlli IAM indipendenti per rete VPC, crea le tue reti VPC in in modo programmatico a gestire i progetti.
Se hai bisogno di ruoli IAM con ambito di risorse Compute Engine specifiche, come Le istanze VM, i dischi e le immagini utilizzano Criteri IAM per le risorse Compute Engine.
Isola i dati sensibili nella propria rete VPC
Per le aziende che si occupano di iniziative di conformità, dati sensibili o ai dati regolamentati, vincolati da standard di conformità come HIPAA o PCI-DSS, ulteriori misure di sicurezza spesso hanno senso. Un metodo che può migliorare la sicurezza e semplificare la verifica della conformità è 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 in termini di costi, prestazioni e sicurezza.
Utilizza il peering di rete VPC se non superi i limiti di risorse.
Utilizza il routing esterno se non hai bisogno di comunicare con indirizzi IP privati.
Utilizza Cloud VPN per connettere reti VPC che altrimenti supererebbero i limiti aggregati del gruppo di peering.
Utilizza Cloud Interconnect per controllare il traffico tra le reti VPC tramite un dispositivo on-premise.
Utilizza appliance virtuali multi-NIC per controllare il traffico tra le reti VPC tramite un dispositivo cloud.
Crea un VPC di servizi condivisi se più reti VPC devono accedere alle risorse comuni ma non tra loro.
Scegli il metodo di connessione VPC più adatto alle tue esigenze in termini di costi, prestazioni e sicurezza
Il passaggio successivo dopo aver deciso di implementare più reti VPC è collegarle. Le reti VPC sono spazi tenant isolati all'interno del database Andromeda SDN, ma esistono diversi modi per attivare la comunicazione tra loro. La le sezioni successive forniscono le best practice per scegliere un metodo di connessione VPC.
La vantaggi e svantaggi di ciascuno sono riassunti nella seguente tabella e le sezioni successive forniscono best practice per scegliere una connessione VPC. .
| Vantaggi | Svantaggi | |
|---|---|---|
| Rete VPC Peering |
|
|
| Routing esterno (IP pubblico o un gateway NAT) |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect - Dedicato o partner |
|
|
| Più interfacce di rete (multi-NIC) |
|
|
Utilizza il peering di rete VPC se non superi i limiti di risorse
Ti consigliamo di utilizzare il peering di rete VPC quando devi connettere reti VPC e non puoi utilizzare un singolo VPC condiviso, a condizione che i totali delle risorse necessarie per tutti i peer connessi direttamente non superino i limiti relativi a istanze VM, numero di connessioni di peering e regole di inoltro interno.
Il peering di rete VPC consente a due reti VPC di connettersi tra loro internamente tramite la rete SDN di Google, indipendentemente dal fatto che appartengano o meno allo stesso progetto o alla stessa organizzazione. Il peering di rete VPC unisce il piano di controllo e la propagazione del flusso tra ciascun peer, consentendo le stesse caratteristiche di inoltro come se tutte le VM si trovassero nella stessa rete VPC. Quando le reti VPC vengono in peering, tutte le subnet, gli intervalli IP alias e le regole di forwarding interno e ogni rete VPC mantiene il proprio firewall distribuito. Il peering di rete VPC non è transitivo.
Il peering di rete VPC è il metodo preferito per connettere le reti VPC per i seguenti motivi:
- Nessun collo di bottiglia del gateway: il traffico viene inoltrato tra i peer come se le VM erano nella stessa rete VPC.
- Fatturazione: non vengono addebitati costi aggiuntivi. La fatturazione avviene come se le VM si trovassero nella stessa rete VPC.
Utilizza il routing esterno se non hai bisogno di comunicare con indirizzi IP privati
Se non hai bisogno di comunicare con indirizzi IP privati, puoi utilizzare il routing esterno con indirizzi IP esterni o un gateway NAT.
Quando viene eseguito il deployment di una rete VPC, viene eseguita una route al gateway internet predefinito di Google di cui è stato eseguito il provisioning con una priorità pari a 1000. Se questa route esiste e a una VM viene assegnato un indirizzo IP esterno, le VM possono inviare traffico in uscita (di entrata) tramite il gateway internet di Google. Puoi anche implementare i servizi dietro una delle numerose offerte di bilanciamento del carico pubblico di Google, che consente di raggiungerli dall'esterno.
Le VM indirizzate esternamente comunicano tra loro privatamente tramite indipendentemente dalla regione e Network Service Tiers. 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 in che modo il routing pubblico influisce sui costi. Per maggiori dettagli, consulta Documentazione sui prezzi di rete.
Usa Cloud VPN per connettere reti VPC che altrimenti supererebbero i limiti aggregati del gruppo di peering
La VPN ad alta disponibilità fornisce un servizio gestito per connettere le reti VPC creando tunnel IPsec tra insiemi di endpoint. Se configuri i router Cloud con la modalità di annuncio personalizzata, puoi attivare il routing transitivo tra le reti VPC e le topologie hub-and-spoke come descritto più avanti in questo documento. Utilizzando Network Connectivity Center, puoi utilizzare i tunnel VPN ad alta disponibilità rete di transito tra reti on-premise, come spiegato nella documentazione di Cloud VPN.
Cloud VPN non supporta MTU di grandi dimensioni. Per maggiori dettagli, consulta Considerazioni sulla MTU.
Utilizzare Cloud Interconnect per controllare il traffico tra le reti VPC tramite un dispositivo on-premise
Cloud Interconnect estende la tua rete on-premise alla rete di Google tramite una connessione a disponibilità elevata e a bassa latenza. Puoi utilizzare Dedicated Interconnect per connetterti direttamente a Google o utilizzare Partner Interconnect per connetterti a Google tramite un provider di servizi supportato.
Dedicated Interconnect fornisce un servizio L2 ad alta velocità tra Google e un provider di colocation o una sede on-premise. In questo modo, puoi utilizzare attrezzature di routing on-premise per il routing tra le reti VPC e utilizzare i servizi di sicurezza e ispezione on-premise esistenti per filtrare tutto il traffico tra le reti VPC. Tutto il traffico tra le due reti VPC ha una latenza aggiuntiva a causa di un round trip aggiuntivo attraverso il sistema on-premise.
Partner Interconnect offre funzionalità simili, Possibilità di connettersi direttamente con un fornitore di livello L3 e di far sì che il fornitore tra le reti VPC. In questo modo, puoi accedere agli indirizzi IP interni della tua rete on-premise e delle reti VPC di Google Cloud senza un dispositivo NAT o un tunnel VPN.
Poiché molte appliance di sicurezza aziendale possono essere utilizzate su Google Cloud, utilizzando VM con più interfacce di rete, utilizzando Cloud Interconnect per instradare il traffico tra Le reti VPC non sono necessarie, tranne nei rari casi in cui tutto il traffico deve fluire attraverso un'appliance on-premise grazie ai criteri aziendali.
Utilizza le appliance virtuali per controllare il traffico tra le reti VPC tramite un dispositivo cloud
Più VM con interfaccia di rete sono comuni per le reti VPC che richiedono sicurezza o servizi aggiuntivi tra di loro, perché più VM con interfaccia di rete consentono alle istanze VM di fare da ponte per la comunicazione tra le reti VPC.
Una VM può 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.
Tieni presente le seguenti caratteristiche quando esegui il deployment di una VM con più NIC:
- Una VM con più NIC può avere un massimo di 8 interfacce.
- Gli intervalli IP delle subnet delle interfacce non devono sovrapporsi.
Crea una VPC di servizi condivisi se più reti VPC devono accedere a risorse comuni, ma non tra di loro
Una rete VPC fornisce un mesh completo di raggiungibilità globale. Per questo motivo, i servizi condivisi e le pipeline di integrazione continua che si trovano nella stessa rete VPC non richiedono particolari considerazioni in termini di connettività, in quanto sono intrinsecamente accessibili. VPC condiviso estende questo concetto, consentendo ai servizi condivisi di risiedere in un progetto isolato fornendo al contempo connettività ad altri servizi o consumatori.
Gli approcci ai servizi condivisi includono Private Service Connect, peering di rete VPC e Cloud VPN. Usa Private Service Connect a meno che tu non sia in grado di farlo per qualche motivo. Puoi utilizzare il peering di rete VPC per connetterti a una rete VPC di servizi condivisi se non superi i limiti aggregati delle risorse e non vuoi configurare endpoint per ogni servizio. Puoi anche utilizzare Cloud VPN per connetterti reti VPC di servizi condivisi che altrimenti supererebbero i limiti aggregati del gruppo di peering.
Private Service Connect consente di rendere un servizio ospitato in un'unica rete disponibili per le VM in un'altra rete creando un endpoint speciale sulla rete di consumatori. La configurazione di Private Service Connect indirizza quindi il traffico per quel servizio tra le due reti.
I consumatori possono utilizzare i propri indirizzi IP interni per accedere ai servizi senza uscire dalle proprie reti VPC o utilizzare indirizzi IP esterni. Traffico rimanente interamente all'interno di Google Cloud. Private Service Connect fornisce accesso orientato ai servizi tra consumer e producer con controllo granulare sul modo in cui viene eseguito l'accesso ai servizi.
Nel modello di peering di rete VPC, ogni rete VPC crea una relazione di peering con rete VPC comune di servizi condivisi per garantire connettività. Peering di rete VPC introduce considerazioni sulla scalabilità, poiché i limiti di scalabilità si applicano agli e l'uso delle risorse di tutti i peer.
Il peering di reti VPC può essere utilizzato anche in combinazione con l'accesso privato ai servizi e l'API Service Networking. Con l'API Service Networking, puoi consentire ai clienti della stessa organizzazione o di un'altra organizzazione di utilizzare un servizio che fornisci, ma lasciando loro scegliere l'intervallo di indirizzi IP che viene connesso utilizzando il peering di rete VPC.
Cloud VPN è un'altra alternativa. Poiché Cloud VPN stabilisce la raggiungibilità tramite tunnel IPsec gestiti, non ha i limiti aggregati del peering di rete VPC. Cloud VPN utilizza un gateway VPN per la connettività e non considera la risorsa aggregata e usare il peer IPsec. Gli svantaggi di Cloud VPN includono l'aumento (tunnel VPN e traffico in uscita), l'overhead di gestione richiesto tunneling e l'overhead delle prestazioni di IPsec.
Progettazione ibrida: connessione di un ambiente on-premise
Utilizza il routing dinamico quando 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 nel design della VPC.
Utilizzo VPC condiviso riduce la necessità che ogni progetto replica 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.
Routing dinamico
Il routing dinamico è disponibile su tutte le soluzioni ibride, tra cui VPN ad alta disponibilità, VPN classica, Dedicated Interconnect e Partner Interconnect. Il routing dinamico utilizza il router Cloud di Google come speaker BGP (Border Gateway Protocol) per fornire il routing BGP esterno (eBGP) dinamico.
il router Cloud non si trova nel piano dati; ma crea route solo l'SDN.
Il routing dinamico non utilizza i tag e il router Cloud non annunci mai nuovamente i prefissi appresi.
Puoi abilitare una delle due modalità del router Cloud: a livello di regione o globale, su ogni rete VPC. Se scegli il routing regionale, il router Cloud pubblicizza solo le sottoreti che coabitano nella regione in cui è implementato. Il routing globale, invece, pubblicizza tutte le subnet della rete VPC specificata, indipendentemente dalla regione, ma penalizza le route annunciate e appreso al di fuori dell'area geografica. In questo modo viene mantenuta la simmetria all'interno della regione, preferendo sempre un'interconnessione locale e viene calcolata aggiungendo una metrica di penalizzazione (MED) pari a 200 + TTL in millisecondi tra le regioni.
Routing statico
Il routing statico è disponibile solo nella VPN classica. Offerte di routing statico la possibilità di impostare una route hop successivo che punta a un tunnel Cloud VPN.
Per impostazione predefinita, una route statica si applica a tutte le VM della rete, indipendentemente dalla regione. Statica Inoltre, il routing consente agli amministratori di rete di impostare selettivamente le VM si applica utilizzando i tag di istanza, che possono essere specificati quando crei percorso.
Le route statiche vengono applicate a livello globale all'interno della rete VPC, con la stessa priorità tra loro. Pertanto, se hai più tunnel in più regioni al con lo stesso prefisso con la stessa priorità, una VM utilizzerà un ECMP basato su hash a 5 tuple in tutti i tunnel. Per ottimizzare questa configurazione, puoi creare un percorso in-regione preferito facendo riferimento ai tag istanza per ogni regione e creando percorsi preferiti di conseguenza.
Se non vuoi che il traffico in uscita passi attraverso le impostazioni predefinite di Google gateway Internet, puoi impostare una route statica predefinita preferita per inviare tutti il traffico di ritorno on-premise attraverso un tunnel.
Utilizza una rete VPC di connettività per scalare un'architettura hub-and-spoke con più reti VPC
Se hai bisogno di scalare un'architettura hub e spoke con più reti VPC, configura una connettività ibrida centralizzata in una rete VPC dedicata e peer-to- altre che utilizzano route annunciate personalizzate. In questo modo, le route statiche o dinamiche acquisite possono essere esportate nelle reti VPC peer per fornire una configurazione centralizzata e scalare la progettazione della rete VPC.
Ciò è in contrasto con il deployment della connettività ibrida convenzionale, che utilizza Tunnel VPN o collegamenti VLAN in ogni singola rete VPC.
Il seguente diagramma illustra la connettività ibrida centralizzata con route personalizzate del peering di 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 native di Google Cloud, se possibile.
Se possibile, utilizza un numero minore di set di regole firewall più ampi.
Isola le VM utilizzando gli account di servizio, se possibile.
Utilizzare l'automazione per monitorare i criteri di sicurezza quando si utilizzano i tag.
Utilizza strumenti aggiuntivi per proteggere e mettere al sicuro le tue app.
Google Cloud offre funzionalità di sicurezza efficaci in tutta la sua infrastruttura e nei suoi servizi, dalla sicurezza fisica dei data center e dell'hardware di sicurezza personalizzato ai team di ricercatori dedicati. Tuttavia, la protezione delle tue risorse Google Cloud è una responsabilità condivisa. Devi adottare misure appropriate per contribuire a garantire la protezione delle tue app e dei tuoi dati.
Identifica obiettivi di sicurezza chiari
Prima di valutare i controlli di sicurezza cloud-native o abilitati per il cloud, con una serie di chiari obiettivi di sicurezza che tutte le parti interessate come parte fondamentale del prodotto. Questi obiettivi devono sottolineare la realizzabilità, la documentazione e l'iterazione, in modo che possano essere utilizzati come riferimento e migliorati durante lo sviluppo.
Limita accesso esterno
Quando crei una risorsa Google Cloud che utilizza una rete VPC, devi scegliere una rete e una sottorete in cui risiede la risorsa. La risorsa è assegnata un indirizzo IP interno da uno degli intervalli IP associati alla subnet. Le risorse in una rete VPC possono comunicare tra loro tramite IP interno se le regole firewall lo consentono.
Limita l'accesso a internet solo alle risorse che ne hanno bisogno. Risorse solo un indirizzo IP interno privato può comunque accedere a molte API di Google e tramite Private Service Connect o Accesso privato Google. L'accesso privato consente alle risorse di interagire con i principali servizi Google e Google Cloud rimanendo isolate dalla rete internet pubblica.
Inoltre, utilizza i criteri dell'organizzazione per limitare ulteriormente le risorse che possono utilizzare indirizzi IP esterni.
Tuttavia, prima di bloccare l'accesso a internet, valuta l'impatto sulle istanze VM. Il blocco dell'accesso a internet può ridurre il rischio di esfiltrazione dei dati, ma può anche bloccare il traffico legittimo, incluso quello essenziale per gli aggiornamenti software e le API e i servizi di terze parti. Senza accesso a internet, possono accedere alle istanze VM solo tramite una rete on-premise connesso tramite un tunnel Cloud VPN, un gateway Cloud Interconnect o Identity-Aware Proxy. Utilizzando Cloud NAT, le macchine virtuali possono avviare il traffico in uscita connessioni a internet per traffico essenziale specifico senza esporre delle connessioni pubbliche in entrata.
Definisci i perimetri di servizio per i dati sensibili
Per i carichi di lavoro che coinvolgono dati sensibili, utilizza Controlli di servizio VPC per configurare i perimetri di servizio attorno alle tue risorse VPC e e controllare il movimento dei dati attraverso il confine del perimetro. Con 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 perimetrali per consentire progetti e servizi in diverse perimetri di servizio per comunicare.
Gestisci il traffico con le regole firewall native di Google Cloud quando possibile
Il VPC di Google Cloud include un firewall stateful L3/L4 in orizzontale scalabili e applicati a ogni VM in modo distribuito. Questo firewall è configurato mediante criteri firewall gerarchici, rete globale e regionale i criteri firewall e le regole firewall VPC. Consulta le Panoramica di Cloud Firewall per maggiori dettagli.
Google Cloud Marketplace offre un ampio ecosistema di soluzioni di terze parti, tra cui VM che svolgono le seguenti attività: forniscono sicurezza avanzata, ad esempio protezione da fughe di informazioni, exploit di applicazioni e riassegnazione dei privilegi; rilevano minacce note e sconosciute e applicano il filtro degli URL. Esistono vantaggi operativi derivanti dall'implementazione da parte di un unico fornitore dei criteri da provider di servizi cloud e ambienti on-premise.
In genere il traffico viene instradato a queste VM specificando le route, con la stessa priorità (distribuire il traffico utilizzando un hash a 5 tuple) o con priorità diverse (per creare un percorso ridondante), come illustrato nelle alla subnet Dev nel diagramma seguente.
La maggior parte delle soluzioni richiede più VM con interfaccia 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 anche quando esegui il deployment di soluzioni di terze parti nella tua rete VPC per i seguenti motivi:
- Limiti: la maggior parte delle appliance basate su VM deve essere inserita nei dati del tuo percorso di apprendimento. Ciò richiede una VM con più interfacce di rete che colleghi più reti VPC che risiedono in lo stesso progetto. Poiché le quote delle risorse VPC sono impostate a livello di progetto, le esigenze aggregate di risorse in tutte le reti VPC possono diventare limitanti.
- Prestazioni: l'introduzione di un singolo punto di saturazione basato su VM negli attributi di scalabilità completamente orizzontale di una rete VPC è in contrasto con le metodologie di progettazione del cloud. Per mitigare questo problema, puoi posizionare più reti virtuali 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 su larga scala, esegui il push i controlli di sicurezza agli endpoint. Per iniziare, migliora la protezione delle VM e utilizza Google Cloud le regole del firewall. Questa strategia può anche comportare l'introduzione di agenti di ispezione degli endpoint basati su host che non modificano l'architettura di inoltro della rete VPC tramite più VM con interfaccia 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
È possibile programmare solo un determinato numero di regole su qualsiasi VM. Tuttavia, puoi combinare molte regole in una singola 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, ciascuna che definisce una singola porta, o 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.
Creare una serie di regole generica applicabile all'intera rete VPC, quindi utilizzare altri di regole specifiche per raggruppamenti più piccoli di VM target. In altre parole, inizia definendo regole generali e, se necessario, definisci gradualmente regole più specifiche:
- Applica regole firewall comuni a tutte le VM nella rete VPC.
- Applica regole firewall che possono essere raggruppate su più VM, ad esempio un gruppo di istanze di servizio o subnet.
- Applica regole firewall a singole VM, ad esempio un gateway NAT o un bastion .
Se possibile, isola le VM utilizzando gli account di servizio
Molte organizzazioni dispongono di ambienti che richiedono regole specifiche per di VM in una rete VPC. In questi casi, puoi adottare due approcci comuni: isolamento della sottorete e filtro dei target.
Isolamento della subnet
Con l'isolamento delle subnet, subnet costituisce il confine di sicurezza attraverso il quale vengono applicate le regole firewall di Google Cloud. Questo approccio è comune nei costrutti di reti on-premise e nei casi in cui gli indirizzi IP e il posizionamento della rete fanno parte dell'identità della VM.
Puoi identificare le VM in una sottorete 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 di una sottorete, ovvero quelle con il tag, il tag di rete e l'account di servizio associati. Ad esempio, per creare una regola firewall che consenta tutte le comunicazioni 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 in base al nome (esempio: subnet-1).
Filtro dei target
Con il filtro dei target, tutte le VM si trovano nella stessa subnet o fanno parte di un insieme arbitrario di subnet. Con questo approccio, l'appartenenza alle subnet è considerata parte dell'identità dell'istanza per le regole firewall. Puoi invece Utilizzare tag, tag di rete o account di servizio per limitare l'accesso tra le VM nello stesso una subnet. Ogni gruppo di VM che utilizza le stesse regole firewall ha la stessa rete applicato.
Per esemplificare, prendiamo in considerazione un'applicazione a tre livelli (web, app, database) per la quale tutte le istanze sono dipiattate nella stessa subnet. Il livello web può comunicare con gli utenti finali e con il livello dell'app, mentre il livello dell'app può comunicare con il livello del database, ma non sono consentite altre comunicazioni tra i livelli. La
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 di database ha un tag di rete db.
Le seguenti regole firewall implementano questo approccio:
| Regola 1: autorizza gli 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: livello web consentito → livello app | Target: Tag di destinazione specificati Tag di destinazione: app Filtro sorgente: Tag sorgente Tag sorgente: web |
| Regola 3: livello app consentito → livello database | Target: tag di destinazione specificati Tag di destinazione: db Filtro di origine: Tag di origine Tag di origine: app |
Tuttavia, anche se è possibile utilizzare i tag di rete per filtrare i target in questo modo, ti consigliamo di utilizzare i tag o gli account di servizio, se possibile. Tag di destinazione
non sono soggetti al controllo dell'accesso e possono essere modificati da un utente con l'instanceAdmin
mentre le VM sono in servizio. I tag e gli account di servizio sono controllati dall'accesso, ovvero
che un utente specifico deve essere esplicitamente autorizzato a utilizzare un account di servizio.
Può esistere un solo account di servizio per istanza, mentre possono essere presenti più tag. Inoltre, gli account di servizio assegnati a una VM possono essere modificati solo quando
la VM viene 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. Ciò può eludere le norme di sicurezza. Perciò, se utilizzi i tag di rete in una di produzione, usa un framework di automazione per superare dell'assenza di governance IAM per i tag di rete.
Utilizzare strumenti aggiuntivi per proteggere le app
Oltre alle regole firewall, utilizza questi strumenti aggiuntivi per proteggere le tue app:
- Utilizza un bilanciatore del carico HTTP(S) globale di Google Cloud per supportare l'alta disponibilità e la normalizzazione del protocollo.
- Integra Google Cloud Armor con il bilanciatore del carico HTTP(S) per garantire la protezione dagli attacchi DDoS e la capacità per bloccare o consentire gli indirizzi IP sul perimetro della rete.
- Controlla l'accesso alle app utilizzando IAP (IAP) per verificare l'identità dell'utente e il contesto della richiesta per determinare se un utente deve essere concesso l'accesso.
- Offre un'unica interfaccia per gli insight sulla sicurezza, il rilevamento di anomalie e il rilevamento delle vulnerabilità Security Command Center.
Servizi di rete: NAT e DNS
Utilizza indirizzi IP esterni fissi con Cloud NAT.
Utilizza zone DNS private per la risoluzione dei nomi.
Utilizzare 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 del motivo per cui potresti aver bisogno di indirizzi IP in uscita fissi è il caso in cui una terza parte consenta richieste da indirizzi IP esterni specifici. Utilizzo Cloud NAT ti consente di avere un numero ridotto di indirizzi IP NAT per ogni regione utilizzata per le comunicazioni in uscita.
Cloud NAT consente inoltre alle istanze VM di comunicare su internet senza avere indirizzi IP esterni propri. Firewall Google Cloud sono stateful, Ciò significa che se è consentita una connessione tra un'origine e un target o un target e una destinazione, quindi tutto il traffico successivo in sarà consentita finché la connessione è attiva. In altre parole, le regole firewall consentono la comunicazione bidirezionale dopo l'instaurazione di una sessione.
Usa zone DNS private per la risoluzione dei nomi
Utilizza le funzionalità di zone private su Cloud DNS per consentire la risoluzione dei tuoi servizi con il DNS all'interno della tua rete VPC, utilizzando indirizzi IP interni senza esporre questa mappatura all'esterno.
Utilizza le funzionalità di DNS split Horizon per mappare i servizi a indirizzi IP diversi all'interno della rete VPC dall'esterno. Ad esempio, puoi esporre un servizio tramite rete dalla rete internet pubblica, ma dispongono di bilanciamento del carico interno Fornire lo stesso servizio utilizzando lo stesso nome DNS dall'interno della rete VPC.
Accesso API per i servizi gestiti da Google
Se possibile, utilizza il gateway internet predefinito.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita.
Esegui il deployment di istanze che utilizzano le API Google nella stessa sottorete.
Se possibile, utilizza il gateway internet predefinito
L'accesso dalle risorse della rete VPC alle API di Google segue l'impostazione predefinita nell'hop successivo del gateway internet. Nonostante il nome del gateway di hop successivo, il percorso del traffico dalle istanze alle API 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 server per l'indirizzo IP, configurare gli endpoint Private Service Connect o utilizzare Funzionalità di accesso privato Google per ogni subnet. Questo non rallenta le comunicazioni per le API di Google.
Google Kubernetes Engine (GKE) abilita automaticamente Accesso privato Google sulle subnet in cui vengono dispiacchiati i nodi. Tutti i nodi su Queste subnet senza indirizzo IP esterno sono in grado di accedere i servizi di machine learning.
Aggiungi route esplicite per le API di Google se devi modificare la route predefinita
Se devi modificare il percorso predefinito, aggiungi percorsi espliciti per Google Intervalli IP di destinazione API.
In ambienti in cui la route predefinita (0.0.0.0/0) non utilizza la route predefinita
hop successivo del gateway internet, configura route esplicite per
intervalli di indirizzi IP di destinazione
usato dalle API di Google. Imposta l'hop successivo delle route esplicite sul gateway internet predefinito. Un esempio di questo scenario è quando è necessario esaminare tutti
il traffico attraverso un dispositivo on-premise.
Esegui il deployment di istanze che utilizzano le API di Google sulla stessa subnet
Esegui il deployment di istanze che richiedono l'accesso alle API e ai servizi Google nella 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, consulta la sezione Configurazione dell'accesso privato Google per gli host on-premise per accedere ad alcuni servizi Google tramite intervalli di indirizzi IP privati. Controlla quale servizi supportati prima di attivare questa funzione in quanto l'accesso ad altre API di Google tramite gli indirizzi IP forniti da questo servizio non saranno raggiungibili. Attivazione in corso può richiedere un'ulteriore configurazione DNS, come la configurazione Visualizzazioni.
Se accedi alle API di Google dal tuo ambiente on-premise utilizzando 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 previsti.
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 hai bisogno solo di dati IP e delle porte.
Personalizza il logging 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 attivare o disattivare i log di flusso VPC a livello di subnet. Se i log di flusso VPC sono abilitati per una subnet, vengono raccolti i dati di tutte le istanze VM al suo interno.
Questi log registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. I casi d'uso di logging ti aiutano a determinare per quali subnet vuoi attivare il logging 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 dei flussi 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 in il tuo progetto e ti consente di disabilitare l'importazione o l'esclusione di log di tutti i log che non ti interessano, in modo da poter ridurre al minimo gli addebiti per i log rispetto all'allocazione mensile.
I log sono una parte fondamentale del successo operativo e della sicurezza, ma non sono utili a meno che tu non li esamini e intervieni. Personalizza i log per pubblico di destinazione, che aiuta a garantire il successo operativo e di sicurezza di alle tue reti VPC.
Per maggiori dettagli, vedi 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 abilitare un'analisi più rapida e semplice.
Un flusso di lavoro di esempio per cui aumentare l'intervallo di aggregazione dei log più appropriato è il monitoraggio della rete, che prevede le seguenti attività:
- Esecuzione della diagnostica di rete
- Filtrare i log di flusso per VM e applicazioni per comprendere le modifiche al traffico
- Analisi della crescita del traffico per prevedere la capacità in corso...
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, mantenendo possono vedere campioni di basso livello e visualizzazioni aggregate.
Un esempio di flusso di lavoro per cui è appropriato l'utilizzo del campionamento per ridurre il volume è comprendere l'utilizzo della rete e ottimizzare la spesa per il traffico di rete. Questo flusso di lavoro prevede le seguenti attività:
- Stimare il traffico tra regioni e zone
- Stima del traffico verso paesi specifici su internet
- Identificazione dei principali talker
Rimuovere metadati aggiuntivi quando sono necessari solo i dati IP e della porta
Nei casi d'uso per la sicurezza in cui ti interessano solo indirizzi IP e porte,rimuovi i metadati aggiuntivi per ridurre il volume di dati consumati in Cloud Logging.
Un flusso di lavoro di esempio per il quale la rimozione dei metadati è appropriata è quella analisi forensi, che comprendono le seguenti attività:
- Determinare quali IP hanno comunicato con chi e quando
- Identificare gli indirizzi IP compromessi, individuati mediante l'analisi dei flussi di rete.
Architetture di riferimento
Questa sezione mette in evidenza alcune architetture che illustrano alcune delle best practice descritte in questo documento.
Progetto singolo, singola rete VPC
Questa architettura di riferimento iniziale include tutti i componenti necessari per eseguire il deployment di architetture altamente disponibili in più regioni, con isolamento a livello di sottorete e un SLA (accordo sul livello del servizio) 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, sui progetti host del VPC condiviso e più progetti di servizio consentono agli amministratori di delegare le responsabilità, come la creazione e la gestione delle istanze, nei confronti del progetto di servizio Gli amministratori mantengono al contempo il controllo centralizzato sulle risorse di rete, subnet, route e firewall.
Più progetti host, più progetti di servizio, più VPC condivise
Il seguente diagramma illustra un'architettura per l'isolamento VPC, che si basa sul nostro design ad alta disponibilità separando i prodotti da quelli in modo programmatico a gestire i progetti. Ci sono molti motivi per considerare l'isolamento del VPC, compresi i requisiti di audit (come PCI), le considerazioni sulle quote tra ambienti o solo un altro livello all'isolamento logico. Sono necessarie solo due interconnessioni (per la ridondanza) per località, ma è possibile aggiungere più collegamenti di interconnessione a più reti VPC regioni da questi.
L'utilizzo dell'isolamento può anche comportare la necessità di replica, poiché devi decidere dove collocare 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 consentirti di condividere questi servizi con altre reti VPC tramite il peering di rete VPC, centralizzando al contempo l'amministrazione e il deployment.
Firewall L7 stateful tra reti VPC
Questa architettura ha più reti VPC collegate da un'appliance NGFW (Next-Generation Firewall) L7, che funziona come un bridge multi-NIC tra le reti VPC.
Viene introdotta una rete VPC esterna non attendibile per terminare le interconnessioni ibride e le connessioni basate su internet che terminano parte esterna della NGFW L7 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 la NGFW basata su VM. Poiché le quote vengono applicate a livello di progetto, devi considerare l'insieme di tutte le risorse VPC.
Passaggi successivi
- Approfondimento e best practice di VPC (video Cloud NEXT '18)
- Topologie di rete ibride e multi-cloud
- Decidi una gerarchia delle risorse per la zona di destinazione di 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 di GKE
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.