STEPHANIE WONG: For an on-prem developer looking to migrate to the cloud, one of the first things you have a need for is to set up a network. But there are some key differences between your traditional on-prem network setup and the cloud's software-defined networks or virtual private clouds. In this episode of GCP Networking End-to-End, I'll be covering what a VPC is, how it differs on Google Cloud Platform, and how to set one up.
Stay tuned. [MUSIC PLAYING] A VPC stands for Virtual Private Cloud, and is a private, isolated virtual network partition that provides 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 and the cloud, including firewall rules and routing, so that you're protected from external and unwanted access and limit public exposure of your instances. In a traditional VPC, the scope is usually bound to a geographic region, like US West versus US East, and all the work and communication between VMs in that region are expected to stay contained. If you want to move beyond that, connect workloads across regions, you need to somehow have a way to provide for private connectivity to ensure your workloads aren't compromised, which usually means leveraging a VPN connection across public IPs of the regions.
While this seems fine in theory, in practice, the overhead and costs associated with your deployment grows with each new region that must be added. Imagine scaling to hundreds of projects with massive numbers of VPNs and VPN gateways to stitch together. On top of that, you have to add multiple routers in each VPC and use them across VPN tunnels to provide dynamic advertisements or BGP sessions for your subnets.
Subnets is just a fancy way of saying an IP segment in a VPC, while BGP is the protocol that helps route traffic to subnets. Now you have a sprawl of many routers and BGP sessions you're managing. Now while a task can be easily automated, network management can still include the responsibilities of coordinating policies that cross multiple admin domains, teams, and resources like organization, security, projects, networks, and endpoints.
This might be fine if your company needs complete isolation between VMs in different regions. But if you're like most companies who want to distribute your workloads across regions and reduce latency when traversing the public internet, you'll want those VMs to be able to communicate across a private network. This is where Google Cloud Global VPC comes into play.
A single Google Cloud VPC can span multiple regions without communicating 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 lets you increase the IP space of any subnet without any workload shutdown or downtime, not to mention a full suite of support services, like shared VPC, Cloud Router, firewall support, VPC peering, and an industrial-strength VPN.
But I'll get to all of that in a later episode. Now, the really cool thing about 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, so you don't have to. Google Cloud VPC is ideal for situations where you're hosting globally distributed multi-tier applications by creating a VPC with subnets, or 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 to it 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.
With that in mind, let's do a quick walk-through of how to set up a VPC for your existing on-prem config using the Google VPC. First, go to the VPC Networks page in the Google Cloud Platform console. Now you see we have a default VPC with subnets in each region created.
In a true hybrid setup, it's common to get rid of the default VPC, as you already have an on-premise network with an IP address scheme setup, which means the default VPC might have overlapping IP ranges. Click Create VPC Network, enter a name for the network. We'll choose Automatic for the subnet creation mode for now.
Now for this example, Auto mode is an ideal situation for us since it makes setup easier. When using Auto mode, the VPC will create a subnet automatically-- again, a fancy way of saying a block of IP addresses for a region-- where the subnet IP falls within predefined IP ranges so that we don't have to do the math ourselves. Again, you can select Custom to avoid overlapping IP ranges to your on-prem network.
Note also that I didn't create VPC in a region. It's global. But you do select region for a subnet.
Now, in the Firewall Rules section, you can select one or more predefined firewall rules that address common use cases for connectivity to VMs. Likewise, you can create your own rules, or use none if you like to roll the dice on security. We'll be covering more on firewall rules in a later episode.
Again, for simplicity's sake, we'll choose the dynamic routing mode for the VPC network, and then we click Create. Now to test if our VPC network is working properly, we're going to create a new instance in a region, and then ping it to see what its IP address is. Let's go to the Compute Engine tab, and create an instance.
Now I'm going to leave all this as default for the sake of brevity. The important thing is down under Show More and the Network tab. We click Network and change it from Default to vpc1, which you can see changes the subnetwork.
Let's click Create. And once it's spun up, you can see that it's internal IP address matches that of what our subnet was. Even with increasingly complex networks and workloads, you can map your on-premise network topologies in Google Cloud.
Stay tuned for the next piece. And remember, optimizing your network means freeing up your bandwidth.
