STEPHANIE WONG: As your cloud number grows,
how do you connect each VPC without the headache of setting
up a mountain of VPNs?
And don't get me started about the performance overhead.
Well, there's a brilliant feature
I'd like to introduce to you to save you from all of that--
VPC Peering.
Stay tuned.
[MUSIC PLAYING]
As a very hand-wavy explanation, cloud providers
build their network with a series of data centers
which they position around the world in strategic locations.
Since there's already internet topography,
they can rely on the public internet
to deal with the connections between these data centers
without having to do too much additional lifting, which
is fine, but introduces a large problem of security
for your data.
Any content from the public internet
is vulnerable to all sorts of behavior, not to mention
the performance issues, which is why corporations utilize
virtual private networks, VPNs, and virtual private clouds,
VPCs.
These allow customers and employees
to securely access cloud resources despite being
on the public internet.
Now, as your cloud footprint grows and your team complexity
grows, one thing that starts to happen
is something called VPC islanding.
That is, as you start to enable more data center regions to be
used by your service, you start to get more and more complexity
overhead to bootstrap, manage, and maintain these VPCs in each
of your regions.
Thankfully, Google Cloud has an answer for this headache.
By default, all VPCs on Google Cloud
are global, meaning you don't need
to set up a VPC for each region, which is pretty nice.
You get to build it once and move on.
But this doesn't work for every organization.
Some structures need more fine-grained control
over VPC deployment, effectively needing
to redeploy different VPCs across different regions
for isolation purposes.
And for this, we need to setup VPC peering.
This is useful in cases where you have several network
administrative domains.
For example, you might have a VPC for the finance department
and another for the accounting department.
The finance department needs access to all the resources
that are in their accounting department,
and the accounting department needs access
to all the resources in the finance department.
Or imagine that you have two VPCs connected via VPC peering,
and you'd like to reach both of them
from an on-prem network with a single VPN.
This is a very common use case, as many managed services
and GCP use VPC peering, including Cloud SQL.
Behind the scenes, VPC peering uses our global virtual network
backbone to create a connection by allowing networks
to exchange routes.
It isn't a gateway or a VPN connection
and doesn't rely on a separate piece of hardware
so that there's no single point of failure or a bandwidth
bottleneck.
Let's walk through setting up VPC peering.
What we're doing today is creating a VPC
peering so a WordPress deployment in one network
can communicate privately with a MySQL deployment
in another network.
In this project, I have two VPCs, VPC 1 and VPC 2,
with non-overlapping IP ranges, and I want
to set up peering between them.
I've also deployed a WordPress and MySQL instance in each VPC,
respectively.
To create a peering connection between the two VPCs,
head to the VPC peering page and click the Create Connection
button.
Click Continue, then enter a name
for the peering connection, and select the source
and destination networks.
This one is from VPC 1 to VPC 2.
While that's creating, repeat the above process,
and create a second peering connection,
this time reversing the source and destination
networks, VPC 2 to VPC 1.
Once created, the two networks will automatically
connect to each other, and you'll
see a green check mark confirming peering is active.
Over on the routing page, you can
see it's automatically created routes between the two
networks, and we now have a full mesh topology.
Once the networks are connected, the next step
is to configure the firewall to enable traffic between them.
For security reasons, you should only
allow access to the specific ports
and from trusted source IP addresses.
I've already created a firewall rule
that allows TCP access from the WordPress network
to the MySQL instance on port 3306.
The next step is to ensure that the deployments in the two VPCs
are able to communicate with each other.
At the time of peering, GCP checks
to see if there are any subnets with overlapping IP
ranges between the two networks or any
of their peered networks.
If there is overlap, there's routing issues,
and peering can't be established.
I'll try to connect to the MySQL instance
from the WordPress instance.
Here, I've connected to the WordPress instance using SSH.
After entering my route username and password and the private IP
of the WordPress instance, I can run the command
to view all available databases and confirm that the connection
is successful.
And that's it.
We can confirm VPC peering is established,
and the two instances in the different VPCs
are communicating over private IPs.
As you can see, VPC peering gives you
security, performance, and manageability.
To learn more, check out the documentation linked below,
stay tuned for the next episode, and remember,
optimizing your network means freeing up your bandwidth.
[MUSIC PLAYING]