Mục Lục

Migrating to GCP? First Things First: VPCs

Google Cloud’s Global Network and How to Get Started

As an on-prem developer migrating to the cloud, you might think the first step is to begin by transferring data or VMs up to the cloud. In reality, creating a VPC should be the foundation of your journey. A VPC stands for Virtual Private Cloud and is a private isolated virtual network partition that gives you managed networking functionality for your Google Cloud Platform (GCP) resources. You can think of a VPC as a virtual version of your traditional physical network. It lets you set up private communication between your virtual machines in the cloud, including firewall rules and routing so that you’re protected from external and unwanted access and limit public exposure of your instances.

VPNs VPNs VPNs — Look familiar?

Traditional VPCs are region-bound, meaning more VPNs more often.

In a traditional VPC, the scope is usually bound to a geographic region (like US-West vs US-East), and all the communication between VMs in that region is expected to stay contained. If you want to move beyond that (connect workloads across regions), you will need private connectivity to ensure your workloads aren’t compromised (ie. leveraging a VPN connection across public IPs of the regions). While this seems fine in theory, the overhead and cost associated with your deployment grows with each new region that must be added.

Scaling across regions means scaling VPN gateways and overhead management.

Imagine scaling to hundreds of projects with massive numbers of VPNs and VPN gateways to stitch together. On top of that, you must add multiple routers in each VPC and use them across VPN tunnels to provide dynamic advertisements (BGP sessions) for your subnets, creating a sprawl of routers and BGP sessions you’re managing. While tasks can be easily automated, network management can still include the responsibilities of coordinating policies that cross multiple admin domains (organization, security, network, project, and endpoints).

This might be fine if your company needs complete isolation between VMs in different regions, but if you’re like most companies that want to distribute your workloads across regions and reduce latency when traversing the public internet, you want those VMs to be able to communicate across a private network.

Google’s global VPC

Google’s VPC lies on a global private network.

This is where Google Cloud’s global VPC comes into play. A single Google Cloud VPC can span multiple regions without needing to communicate across the public Internet. It provides the same private gateways for your on-prem hardware, but also gives you global scope between regions, sharable configuration between your projects, and near real-time logging to monitor your application. It also comes with a full suite of support services like Shared VPC, Cloud Router, Firewall support, VPC peering and an industrial strength VPN.

Google’s VPC allows private traffic to move from region to region.

The most impressive feature of GCP’s VPC system is that it allows your VMs to communicate across regions without needing the extra overhead of VPNs to do so. This is all done using the same global underlying network that powers Search, Youtube, and Gmail. This means that Google handles your traffic under the hood by dynamically advertising routes across the VPC, and this is abstracted from the user.

Google Cloud’s VPC is ideal for situations where:

You’re hosting globally distributed multi-tier applications, by creating a VPC with subnets.
Connecting GCP-hosted or externally-hosted databases to Google’s unique machine learning services, by creating a VPC with subnets and VPN access.
Or even Disaster recovery with application replication. Create backup GCP compute capacity, then revert back once the incident is over.

As such, using GCP VPC means that:

You have a simplified network with a single global VPC with regional segmentation, meaning fewer VPNs and routers.
You have simplified management. A single security policy can be applied globally. There are fewer network constructs to break and troubleshoot.

Why this matters

Yes, creating a VPC from the get-go requires a little more planning. But in the case of a migration or hybrid scenario, it’s important to plan out your VPC and subnet ranges to avoid private IP range overlap. This is the main reason why custom mode subnet creation can be ideal on GCP.

In addition:

You can plan for different IP ranges in the cloud than on-prem.
Subnets under the same VPC cannot have overlapping IP ranges. This is so the routing Google is doing under the hood can route traffic to the correct set of VMs.
When setting up hybrid connectivity, you can avoid headaches when extending your intranet to the cloud and finding out you have overlapping IP ranges.

Rest assured, you can find comfort in knowing that on GCP you can extend your subnet IP ranges quickly and easily without interruption in your GCP services.

Google’s VPC allows you to increase subnet IP ranges without disrupting your services. Huzzah!

With that in mind, let’s do a quick walkthrough of how to set up a VPC for your existing on-prem config using the Google VPC.

Your wish is your command

If you prefer to create a VPC through a CLI, Google Cloud has a CLI-based SDK for shell scripting or interactive terminal sessions. You can create a VPC using gcloud commands:

gcloud compute networks create [NETWORK_NAME] \
    --subnet-mode=auto \
    --bgp-routing-mode=[DYNAMIC_ROUTING_MODE]

And you can create a new subnet in a given network:

gcloud compute networks subnets create [SUBNET_NAME] \
    --network=[NETWORK] \
    --range=[PRIMARY_RANGE] \
    --region=[REGION]

If you prefer not to use CLI and are developing an application or prefer a programmatic approach, you can use one of many client libraries that give you a wealth of functionality. You can even write directly to the REST API if you have specific needs. In addition to the tools above, if you need to create larger topologies on a regular cadence you may want to look at Google’s Cloud Deployment Manager.

Weight off your shoulders

In the old networking world you used tangible building blocks like routers, switches, firewalls, cables, and racks. Assembling all the pieces to build inter-connectivity between the end users and the applications took days and weeks. As the network grew, the associated management and cost to operate it also grew disproportionately.

Cloud networking handles this complexity and abstracts if from you by giving you managed software-defined networking. Google’s VPC, in particular, hides much of the complexities associated with the old building blocks. Even with increasingly complex networks and workloads, you can map your on-premise network topologies in Google Cloud with less management and a plethora of tools. Next step in the journey to migration is setting up direct connection to Google’s network. Stay tuned for the next piece.