Reti VPC

Una rete Virtual Private Cloud (VPC) è una versione virtuale di una rete fisica all'interno della rete di produzione di Google, Andromeda.

Una rete VPC esegue le seguenti operazioni:

• Fornisce connettività per Istanze di macchine virtuali (VM) Compute Engine.
• Offre bilanciatori del carico di rete passthrough interni nativi e sistemi proxy per dei bilanciatori del carico delle applicazioni interni.
• Si connette alle reti on-premise utilizzando i tunnel Cloud VPN e Collegamenti VLAN per Cloud Interconnect.
• Distribuisce il traffico dai bilanciatori del carico esterni di Google Cloud a di backend.

I progetti possono contenere più reti VPC. A meno che non crei un criterio dell'organizzazione che lo vieta, i nuovi progetti iniziano con un predefinita (una rete VPC in modalità automatica) con una una subnet (subnet) in ogni regione.

Importante: questa pagina descrive le reti VPC, che sono rispetto alle reti legacy. Le reti legacy non possono non essere più creati e non sono consigliati per la produzione perché non supportare funzionalità di networking avanzate. Puoi convertire un modello a una rete VPC in ogni rete. Per visualizzare il tipo di rete esistente, vedi Visualizza .

Reti e subnet

I termini subnet e subnetwork sono sinonimi. Vengono utilizzati in modo intercambiabile nella console Google Cloud, nei comandi gcloud e nella documentazione dell'API.

Una subnet non è la stessa cosa di una rete (VPC). Le reti e le subnet sono tipi di risorse diversi in Google Cloud.

Per ulteriori informazioni, vedi Subnet.

Istanze di macchine virtuali

Un'istanza di macchina virtuale (VM) Compute Engine è una macchina virtuale ospitati sull'infrastruttura di Google. I termini istanza Compute Engine, Istanza VM e VM sono due sinonimi. Sono utilizzati in modo intercambiabile Console Google Cloud, riferimento a Google Cloud CLI e documentazione API.

Le istanze VM includono Cluster Google Kubernetes Engine (GKE) dell'ambiente flessibile di App Engine, e altri prodotti Google Cloud basati su di Compute Engine.

Per ulteriori informazioni, consulta Istanze di macchine virtuali nella documentazione di Compute Engine.

Specifiche

Le reti VPC hanno le seguenti proprietà:

• Reti VPC, tra cui route e firewall associate di regole, sono risorse globali. Non sono associati a una determinata regione o zona.

• Le subnet sono risorse a livello di regione.

• Ogni subnet definisce un intervallo di indirizzi IPv4. Subnet in modalità personalizzata Le reti VPC possono anche avere un intervallo di indirizzi IPv6.

• Il traffico da e verso le istanze può essere controllato con il firewall di rete . Le regole sono implementate sulle VM stesse, quindi il traffico può essere controllato e registrato solo quando esce o arriva a una VM.

• Le risorse all'interno di una rete VPC possono comunicare tra loro utilizzando indirizzi IPv4 interni, indirizzi IPv6 interni o IPv6 esterni di rete, in base alle regole firewall di rete applicabili. Per ulteriori informazioni, vedi comunicazione all'interno della rete.

• Le istanze con indirizzi IPv4 o IPv6 interni possono comunicare con Google API e servizi. Per ulteriori informazioni informazioni, vedi Opzioni di accesso privato per Google Cloud.

• L'amministrazione della rete può essere protetta nei ruoli di Identity and Access Management (IAM).

• Un'organizzazione puoi utilizzare un VPC condiviso per mantenere in un progetto host comune. Autorizzato Le entità IAM di altri progetti nella stessa organizzazione possono e creano risorse che usano subnet della rete VPC condiviso.

• Le reti VPC possono essere connesse ad altri VPC in reti di progetti o organizzazioni diverse utilizzando Peering di rete VPC.

• Le reti VPC possono essere connesse in modo sicuro in ambienti ibridi utilizzando Cloud VPN o Cloud Interconnect.

• Supporto delle reti VPC GRE incluso quello su Cloud VPN e Cloud Interconnect. Le reti VPC non supportano GRE per Cloud NAT o per regole di forwarding per il bilanciamento del carico e l'inoltro del protocollo. Supporto per GRE consente di terminare il traffico GRE su una VM da internet (IP esterno (indirizzo IP interno) e Cloud VPN o Cloud Interconnect (IP interno ). Il traffico decapsulato può quindi essere inoltrato a un destinazione. GRE consente all'utente di utilizzare servizi come Secure Access Service Edge (SASE) e SD-WAN.

  Nota: il supporto GRE per VPN e Interconnect è stato testato solo con GRE versione 0. Inoltre, il supporto per il traffico GRE non include l'assistenza da Google Cloud per risolvere i problemi della tua rete overlay.

• Le reti VPC supportano IPv4 e IPv6 unicast. Le reti VPC non supportano trasmissione o multicast all'interno della rete.

  Per ulteriori informazioni sugli intervalli di subnet IPv6, consulta Subnet.

Esempio di rete VPC

L'esempio seguente illustra una rete VPC in modalità personalizzata tre subnet in due regioni:

Esempio di rete VPC (fai clic per ingrandire)

• La Subnet1 è definita come 10.240.0.0/24 nella regione us-west1.
  • Due istanze VM nella zona us-west1-a si trovano in questa subnet. La sua proprietà intellettuale entrambi provengono dall'intervallo di indirizzi disponibile in subnet1.
• La Subnet2 è definita come 192.168.1.0/24 nella regione us-east1.
  • Due istanze VM nella zona us-east1-b si trovano in questa subnet. La sua proprietà intellettuale entrambi provengono dall'intervallo di indirizzi disponibile in subnet2.
• Subnet3 è definita come 10.2.0.0/16, anch'essa nella regione us-east1.
  • un'istanza VM nella zona us-east1-b e una seconda istanza nella zona La zona us-east1-c si trova in subnet3 e riceve ciascuna un indirizzo IP dal relativo disponibile. Poiché le subnet sono risorse a livello di regione, le istanze associare le proprie interfacce di rete a qualsiasi subnet nello stesso che contiene le rispettive zone.

Vincoli dei criteri dell'organizzazione

• Ogni nuovo progetto viene avviato con un VPC predefinito Google Cloud. Puoi disattivare la creazione di reti predefinite creazione di un criterio dell'organizzazione con il vincolo compute.skipDefaultNetworkCreation. I progetti che ereditano questo criterio non avranno una rete predefinita.

• Puoi controllare le seguenti configurazioni IPv6 utilizzando l'organizzazione :

  • Disabilita l'utilizzo di IPv6 esterno della rete VPC: se il criterio è impostato su true, il parametro Il vincolo constraints/compute.disableVpcExternalIpv6 ti impedisce o configurando subnet a doppio stack con intervalli IPv6 esterni.

  • Disabilita l'utilizzo di IPv6 interno di VPC: se questo valore è impostato su true, Il vincolo constraints/compute.disableVpcInternalIpv6 ti impedisce o configurando subnet a doppio stack con intervalli IPv6 interni.

  • Disabilita tutto l'utilizzo di IPv6: se viene impostato su true, il parametro Il vincolo constraints/compute.disableAllIpv6 disattiva la creazione di o tutte le risorse coinvolte nell'utilizzo di IPv6.

Per ulteriori informazioni sui vincoli, consulta Criteri dell'organizzazione vincoli.

Modalità di creazione subnet

Google Cloud offre due tipi di reti VPC: in base alla modalità di creazione delle subnet:

• Quando una rete VPC in modalità automatica viene viene creata, una subnet per ogni regione viene creato automaticamente al suo interno. Queste subnet create automaticamente utilizzano un insieme di intervalli IPv4 predefiniti che rientrano in 10.128.0.0/9 Blocco CIDR. Man mano che nuove regioni Google Cloud diventano disponibili, le nuove subnet vengono aggiunte automaticamente alle reti VPC in modalità automatica utilizzando un intervallo IP di quel blocco. Oltre al modello creato automaticamente, puoi aggiungere altre subnet manualmente alle reti VPC in modalità automatica nelle regioni scelte da te Intervalli IP esterni a 10.128.0.0/9.

• Quando una rete VPC in modalità personalizzata viene vengono create, non vengono creato automaticamente. Questo tipo di rete offre il controllo completo sulle subnet e sui relativi intervalli IP. Sei tu a decidere quali subnet creare nelle regioni che scegli utilizzando gli intervalli IP da te specificati.

Puoi passare dalla modalità automatica alla modalità personalizzata . Si tratta di una conversione unidirezionale; le reti VPC in modalità personalizzata in modalità automatica. Per aiutarti a decidere che il tipo di rete soddisfi le tue esigenze, vedi le considerazioni per le reti VPC in modalità automatica.

Rete predefinita

A meno che tu non scelga di disattivarlo, ogni nuovo progetto inizia con una rete predefinita. La rete predefinita è un VPC in modalità automatica con regole firewall IPv4 precompilate. La rete predefinita non ha regole firewall IPv6 precompilate.

Considerazioni sulle reti VPC in modalità automatica

Le reti VPC in modalità automatica sono facili da configurare e da usare e sono particolarmente adatta ai casi d'uso con questi attributi:

• La creazione automatica di subnet in ogni regione è utile.

• Gli intervalli IP predefiniti delle subnet non si sovrappongono ai che useresti per diversi scopi (ad esempio, le connessioni Cloud VPN alle risorse on-premise).

Tuttavia, le reti VPC in modalità personalizzata sono più flessibili più adatti alla produzione. I seguenti attributi evidenziano i casi d'uso in cui Le reti VPC in modalità personalizzata sono consigliate o obbligatorie:

• Non è necessario creare automaticamente una subnet in ogni regione.

• Creare automaticamente nuove subnet non appena sono disponibili nuove regioni potrebbero sovrapporsi agli indirizzi IP usati da subnet create manualmente o o può interferire con la pianificazione generale della rete.

• Devi avere il controllo completo sulle subnet create Rete VPC, inclusi gli intervalli di indirizzi IP e le regioni utilizzati.

• Prevedi di connettere la tua rete VPC a un'altra rete:

  • Poiché le subnet di ogni rete VPC in modalità automatica utilizzano stesso intervallo predefinito di indirizzi IP, non puoi connettere la modalità tra loro tramite il peering di rete VPC o Cloud VPN.

  • Poiché l'intervallo CIDR 10.128.0.0/9 in modalità automatica fa parte della RFC 1918 di indirizzi IP esterni, le reti esterne a Google Cloud potrebbero attualmente in futuro, utilizza un intervallo CIDR sovrapposto.

• Vuoi creare subnet con intervalli IPv6. VPC in modalità automatica le reti non supportano le subnet a doppio stack.

Importante: le reti di produzione devono essere pianificate in anticipo. È consigliabile utilizzi le reti VPC in modalità personalizzata in produzione.

Intervalli di subnet IPv4

Ogni subnet ha un intervallo di indirizzi IPv4 principale. Gli indirizzi interni principali per le risorse seguenti provengono dall'intervallo principale della subnet: istanze VM, bilanciatori del carico interni e forwarding del protocollo interno. In via facoltativa, Aggiungere intervalli di indirizzi IP secondari a una subnet, utilizzati solo dall'IP alias intervalli di classificazione. Tuttavia, puoi configurare intervalli IP alias per dall'intervallo principale o secondario di una subnet.

Ogni intervallo IPv4 principale o secondario per tutte le subnet in un VPC La rete deve essere un blocco CIDR valido univoco. Fai riferimento alle limiti di rete per il numero di indirizzi IP secondari che puoi definire.

Le subnet IPv4 non devono necessariamente formare un blocco CIDR contiguo predefinito, se lo desideri. Ad esempio, le reti VPC in modalità automatica e creare subnet che rientrano in un intervallo IP predefinito in modalità automatica.

Quando crei una subnet in una rete VPC in modalità personalizzata, scegli quale intervallo IPv4 utilizzare. Per ulteriori informazioni, consulta la sezione Informazioni , subnet vietata di pubblicazione e lavorare con il subnet.

Esistono quattro indirizzi IP inutilizzabili in ogni intervallo di subnet IPv4 principale. Per Per saperne di più, consulta Indirizzi inutilizzabili negli intervalli di subnet IPv4.

Le reti VPC in modalità automatica vengono create con una subnet per regione la data di creazione e ricevere automaticamente nuove subnet in nuove regioni. Le subnet hanno solo intervalli IPv4 e tutti gli intervalli di subnet rientrano nel CIDR 10.128.0.0/9 bloccare. Le parti non utilizzate di 10.128.0.0/9 verranno riservate per il futuro all'utilizzo di Google Cloud. Per informazioni sull'intervallo IPv4 utilizzato in cui regione, consulta Intervalli di subnet IPv4 in modalità automatica.

Intervalli di subnet IPv6

Quando crei una subnet a doppio stack in una rete VPC in modalità personalizzata, scegli se la subnet è configurata con un intervallo di subnet IPv6 interno, o un intervallo di subnet IPv6 esterno.

• Gli intervalli di subnet IPv6 interne utilizzano indirizzi locali univoci (ULA).

  • Gli ULA vengono utilizzati per le comunicazioni da VM a VM all'interno del VPC reti. Gli ULA per IPv6 sono analoghi a RFC 1918 per IPv4. Gli ULA non sono raggiungibili da internet e non sono pubblicamente instradabili.

• Gli intervalli di subnet IPv6 esterne utilizzano unicast globale indirizzi IP (GUA).

  • Le GUA possono essere utilizzate per le comunicazioni da VM a VM all'interno reti VPC e sono anche instradabili su internet.

Per ulteriori informazioni sugli intervalli di subnet IPv6, consulta Subnet.

Reti che supportano subnet a doppio stack

Puoi creare un modello a doppio stack subnet in una rete VPC in modalità personalizzata.

Le subnet a doppio stack non sono supportate sulle reti VPC in modalità automatica. inclusa la rete predefinita. Le subnet a doppio stack non sono supportate nella versione legacy reti.

Se vuoi aggiungere una rete VPC in modalità automatica a doppio stack, puoi:

1. Convertire la rete in modalità automatica in personalizzata .

2. Crea nuovo doppio stack subnet o converti alle subnet esistenti a doppio stack.

Route e regole firewall

Route

Le route definiscono i percorsi dei pacchetti che escono dalle istanze (traffico in uscita). Per maggiori dettagli sui tipi di route Google Cloud, consulta Route.

Modalità di routing dinamico

A ogni rete VPC è associata una modalità di routing dinamico, controlla il comportamento di tutti i suoi Router Cloud. I router Cloud gestiscono le sessioni BGP per Google Cloud prodotti per la connettività.

Per una descrizione delle opzioni della modalità di routing dinamico, consulta Effetti della modalità di routing nella documentazione del router Cloud.

Annunci di routing e indirizzi IP interni

I seguenti indirizzi IP sono pubblicizzati all'interno di una rete VPC:

• Indirizzi IPv4 interni a livello di regione

  Utilizzato per l'indirizzo di subnet IPv4 principale e secondario intervalli

• Indirizzi IPv6 interni ed esterni a livello di regione

  Utilizzato per gli indirizzi di subnet IPv6 interne ed esterne intervalli

• Indirizzi IPv4 interni globali

  Utilizzata per gli endpoint di Private Service Connect per Google API

Se connetti le reti VPC utilizzando il peering di rete VPC, che utilizzano indirizzi IPv4 privati vengono sempre scambiati. Puoi controllare se vengono scambiati intervalli di subnet che utilizzano indirizzi IPv4 pubblici utilizzati privatamente. Globali gli indirizzi IPv4 interni non vengono mai scambiati tramite il peering. Per ulteriori dettagli, consulta il peering di rete VPC documentazione.

Quando connetti una rete VPC a un'altra rete, ad esempio una rete on-premise, utilizzando un prodotto per la connettività Google Cloud come Appliance Cloud VPN, Cloud Interconnect o router:

• Puoi pubblicizzare gli indirizzi IP interni della rete VPC su un'altra rete (ad esempio una rete on-premise).
• Sebbene la connettività tra una rete VPC e un'altra rete ad esempio una rete on-premise, possono utilizzare il routing privato fornito da un per il prodotto di connettività Google Cloud, gli indirizzi IP dell'altra rete potrebbero anche essere instradabili pubblicamente. Tieni presente questo aspetto se una rete on-premise utilizza indirizzi IP instradabili pubblicamente.
• Istanze VM in una rete VPC contenente intervalli di subnet con indirizzi IP pubblici utilizzati privatamente non possono connettersi a indirizzi che usano gli stessi indirizzi IP pubblici.
• Presta particolare attenzione quando fai pubblicità a indirizzi IP pubblici utilizzati privatamente per un'altra rete (ad esempio una rete on-premise), soprattutto quando possono pubblicizzare questi indirizzi IP pubblici su Internet.

Regole firewall

Sia i criteri firewall gerarchici che Le regole firewall VPC si applicano ai pacchetti inviati da e verso istanze VM (e risorse che dipendono da VM, ad esempio nodi di Google Kubernetes Engine). Entrambi i tipi di firewall controllano il traffico anche tra le VM nella stessa rete VPC.

Per monitorare quale regola firewall ha consentito o negato una determinata connessione, consulta Logging delle regole firewall.

Comunicazioni e accesso

Comunicazione all'interno della rete

Le route di subnet generate dal sistema definiscono i percorsi per l'invio del traffico tra di istanze gestite all'interno della rete utilizzando indirizzi IP interni. Per uno poter comunicare con un'altra istanza, le regole firewall appropriate devono anche perché ogni rete ha un firewall implicito di negazione per il traffico in entrata.

Ad eccezione della rete predefinita, devi creare esplicitamente una priorità più alta regole firewall in entrata per consentire la comunicazione tra le istanze. La rete predefinita include diverse regole firewall oltre a quelle implicite, inclusa la regola default-allow-internal, che consente il passaggio da istanza a istanza la comunicazione all'interno della rete. La rete predefinita include anche il traffico in entrata che consentono protocolli come RDP e SSH.

Anche le regole incluse nella rete predefinita vengono presentate sotto forma di opzioni da applicare alle nuove reti VPC in modalità automatica create utilizzando la console Google Cloud.

Requisiti per l'accesso a internet

Affinché un'istanza abbia un traffico in uscita, è necessario che siano soddisfatti i seguenti criteri accesso a internet:

• La rete deve avere una route gateway internet predefinito o una route personalizzata valida il cui intervallo IP di destinazione è il più generale (0.0.0.0/0). Questo percorso definisce il percorso di internet. Per ulteriori informazioni, vedi Route.

• Le regole firewall devono consentire il traffico in uscita dall'istanza. A meno che non venga sostituito da una regola di priorità più elevata, la regola di autorizzazione implicita per il traffico in uscita e il traffico in uscita da tutte le istanze.

• Una delle seguenti condizioni deve essere vera:

  • L'istanza deve avere un indirizzo IP esterno. Un indirizzo IP esterno può assegnate a un'istanza quando si trova creato o dopo che è stato creato.

  • L'istanza deve essere in grado di utilizzare Cloud NAT o un proxy basato su istanze che è la destinazione di una route 0.0.0.0/0 statica.

Comunicazioni e accesso per App Engine

Le regole firewall VPC si applicano alle risorse in esecuzione ad esempio una rete VPC, ad esempio le VM di Compute Engine. Per Istanze App Engine, le regole firewall funzionano come segue:

• Ambiente standard di App Engine: Solo le regole firewall di App Engine si applicano al traffico in entrata. Poiché Le istanze dell'ambiente standard di App Engine non vengono eseguite all'interno rete VPC, le regole firewall VPC non applicabili.

• Ambiente flessibile di App Engine: Le regole firewall di App Engine e VPC si applicano al traffico in entrata per via del traffico. Il traffico in entrata è consentito solo se consentito da entrambi i tipi di le regole del firewall. Per il traffico in uscita, si applicano le regole del firewall VPC.

Per ulteriori informazioni su come controllare l'accesso ad App Engine vedi Sicurezza delle app.

Traceroute a indirizzi IP esterni

Per motivi interni, Google Cloud aumenta il contatore TTL dei pacchetti che attraversano gli hop successivi nella rete Google. Strumenti come traceroute e mtr potrebbero fornire risultati incompleti perché il TTL non scade su alcune . Gli hop che si trovano all'interno della rete di Google potrebbero essere nascosti quando invii e pacchetti dalle istanze Compute Engine alle destinazioni su internet.

Il numero di hop nascosti varia in base a Network Service Tiers dell'istanza, regione e altri fattori. Se ci sono pochi hop, è possibile per tutte per nasconderli. Gli hop mancanti in un risultato traceroute o mtr no significa che il traffico in uscita viene eliminato.

Non esiste una soluzione alternativa per questo comportamento. Devi tenerne conto se configurare il monitoraggio di terze parti che si connette a un indirizzo IP esterno associate a una VM.

Importante: le statistiche sulla perdita di probe sono un componente dei test traceroute, ma è importante quando si analizzano i risultati dei test. traceroute e mtr per impostazione predefinita utilizzano un probe basato su ICMP. La generazione della risposta al probe ICMP è in genere a frequenza limitata (o disattivata) nei router che risiedono nel percorso di rete del tuo un probe e possono causare la mancanza di risposte al probe. In questo caso, potresti notare una perdita del probe negli hop di routing intermedi, ma questo non dovrebbe riflettere le prestazioni end-to-end. Se si cerca la perdita di pacchetti, l'unico hop di solito conta è l'hop di destinazione.

Limiti di velocità effettiva in uscita

Le informazioni sulla velocità effettiva di rete sono disponibili nella Pagina Larghezza di banda della rete in Compute Engine documentazione.

Dimensione pacchetto

Puoi trovare informazioni sulle dimensioni del pacchetto in Unità massima di trasmissione.

Unità massima di trasmissione

Per ulteriori informazioni sull'impostazione dell'unità massima di trasmissione (MTU) per un alla rete VPC e alle rispettive VM connesse, consulta Unità massima di trasmissione.

Per informazioni sulla modifica della MTU di una rete VPC, eseguendo la migrazione di VM tra reti VPC con impostazioni MTU diverse, consulta Modifica dell'impostazione della MTU di un VPC Google Cloud.

Protocolli supportati

Google Cloud supporta solo i seguenti protocolli e intestazioni di estensioni:

• Pacchetti di dati IPv4 tra le VM: tutti i protocolli IPv4.
• Pacchetti di dati IPv4 tra le VM e internet: ICMP, IPIP, TCP, UDP, GRE Protocolli ESP, AH e SCTP.
• Pacchetti di dati IPv6 tra le VM e tra le VM e internet: AH, Protocolli ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP e UDP e le opzioni di destinazione e le intestazioni delle estensioni Fragments. Tuttavia, posizionando l'intestazione Opzioni di destinazione dopo l'intestazione Framment in un pacchetto di dati IPv6 non è supportata.
• Inoltro del protocollo:AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP e UDP protocolli

Per consentire i pacchetti di dati dei protocolli supportati, devi configurare regole firewall o regole di forwarding del protocollo in base ai tuoi requisiti.

Rendimento della rete

Latenza

È possibile trovare la latenza misurata tra regioni per le reti Google Cloud nella nostra piattaforma dashboard. La dashboard mostra la latenza mediana tra regioni di Google Cloud e metriche e metodologia di esecuzione della velocità effettiva per riprodurre questi risultati utilizzando Benchmarker PerfKit.

Google Cloud in genere misura latenze di andata e ritorno inferiori a 55 μs al 50° percentile e latenze di coda inferiori a 80 μs al 99° percentile tra le istanze VM c2-standard-4 nella stessa zona.

Google Cloud in genere misura latenze di andata e ritorno inferiori a 45 μs alla 50° percentile e latenze di coda inferiori a 60 μs al 99° percentile tra istanze VM c2-standard-4 nella stessa rete a bassa latenza (criterio di posizionamento "compatto"). R criterio di posizionamento compatto riduce la latenza di rete garantendo che le VM si trovino fisicamente nella stessa rete a bassa latenza.

Metodologia: la latenza all'interno della zona viene monitorata tramite un prober blackbox che esegue costantemente Netperf Benchmark TCP_RR tra una coppia di VM di tipo c2 in ogni zona e c2. Raccoglie i risultati P50 e P99 per la configurazione con e senza criterio di posizionamento compatto. Misure di benchmark TCP_RR il rendimento di richieste/risposte misurando il tasso di transazione. Se le tue richiedono la migliore latenza possibile, si consiglia di utilizzare le istanze c2.

Perdita pacchetti

Google Cloud monitora la perdita di pacchetti tra regioni misurando regolarmente e la perdita di andata e ritorno tra tutte le regioni. Scegliamo come target la media globale di questi inferiori allo 0,01% .

Metodologia: una blackbox vm-to-vm prober monitora la perdita di pacchetti per ogni coppia di zone utilizzando i ping e aggrega i risultati in un'unica o una metrica di valutazione. Questa metrica viene monitorata con una finestra di un giorno.

Passaggi successivi

• Crea, modifica o elimina reti e subnet VPC.

Provalo

Se non hai mai utilizzato Google Cloud, crea un account per valutare in che modo Le prestazioni del VPC diversi scenari. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Prova VPC gratuitamente