STEPHANIE WONG: As your cloud application scales,
you'll eventually be faced with an all too common problem.
How do I maintain tight control over network resources,
but not be a roadblock to teams spinning up the resources they
need to do work?
In this episode of Cloud Networking,
I show you that you can have the best of both worlds using
shared VPCs.
Large organizations with multiple cloud projects
value the ability to share resources
while maintaining logical separation between groups
or departments.
And this makes complete sense.
Centrally network admins are on the hook
to maintain sanity for the overall network,
so sharing resources is critically important.
But every team has special needs,
meaning that it's a constant churn for admins
to have to set up new projects, access policies, billing,
quotas, et cetera, et cetera.
If your company is large enough, this can be a full time job.
That's why Google created shared VPC, which
allows an organization to connect resources
from multiple projects to a common VPC network,
so that they can communicate with each other securely
and efficiently using internal IPs from that network.
When you use shared VPC, you designate a project
as a host project and attach one or more service projects to it.
The VPC networks in the host projects
are called shared VPC networks.
With shared VPC, you can centrally
manage the creation of routes, firewalls, subnet IP ranges,
VPN connections, and more for the entire organization,
and allow developers to own billing, quotas, and IAM
permissions, and autonomously operate
their development projects.
For example, imagine you were the network
admin at an e-commerce company.
You have a single externally facing website application
server that uses services like personalization,
recommendation, and analytics all internally available,
but built by different development teams.
You can have a shared VPC network
with a host project and three service
projects for personalization, recommendation, and analytics
all on different subnets.
With shared VPC, the network and security admin
would set up the overall security policies and the host
project, like restricting which VMs can have public IPs
and access to the internet by setting up
an organization policy that disables
external IP access for VMs.
In this example, the personalization recommendation
and analytic services.
Meanwhile, each team would be able to start spinning up
VMs in their assigned service project
and decide more fine grained details,
like setting up compute resources.
And VMs still get the same network throughput caps and VM
to VM latency as when they're not on shared networks.
Let's dive into how to set up a shared VPC.
At the organizational level, my log in, Stephanie.Wong,
currently has org admin and shared VPC admin privileges.
I can also assign the shared VPC admin role
to somebody else in my org.
Switching over to my host project,
I created a custom VPC called VPC one and two subnets,
development and production.
I also created two firewall rules,
one to allow SSH to all instances
in the network and one to allow ICMP traffic between instances
in these subnets.
In the shared VPC page, first, enable host project
to be the host project by clicking set up shared VPC.
I'm going to select sharing individual subnets.
This option allows you to share specific subnets in the host
project VPC with your service project.
Then select the VPC one dev and prod subnets.
Let's attach two service projects, development
and production.
Make sure the Compute Engine API has
been enabled in each service project before attaching them.
Here, you can edit the default permissions
given to this service project.
Then click Save.
You can now see host project is the shared VPC
host with two subnets, and it has
two attached service projects.
This is also where you can add additional host project users
and admins.
Now I'm going to log into my development project
on our account, John, who only has permission to that project.
Switching to the development project, create a new VM,
and add a development tag.
Then select network shared with me from the host projects,
so that you can select the dev subnet.
Once it's done creating, copy the internal IP of the instance
since you'll need it just in a second.
Next, I'll switch to Mary's account,
who is the owner of the production project.
Create a new VM in the production subnet
and add a production tag.
Making sure to change the zone to the one in the production
subnet region, select the prod subnet.
When both VMs are done creating, you can see.
I can SSH into the prod instance and ping the dev instances
internal IP address since I've created the right firewall
rules and the host project shared VPC.
Now you just want to make sure that when configuring subnet IP
ranges in the same or different regions,
you allow for sufficient IP space between the subnets
for future growth.
Plus GCP lets you expand an existing subnet
without affecting any existing VM's IP address,
and with zero downtime.
How cool is that?
Shared VPC is a powerful feature that
makes GCP more flexible and manageable
for your organization.
Yep, that means you might just have enough time
to go fishing on the weekend without a fire drill
ping interrupting that overhead cast.
To learn more, check out the documentation link below.
And remember, optimizing your network
means freeing up your bandwidth.
[MUSIC PLAYING]