Peered VPCs in Google Cloud versus AWS

The VPC Boundary

VPCs are a logical boundary within a public cloud. The actual contents of this logical boundary are physical networking constructs, including subnets, IP addresses, routes and such. In AWS, when you create an account, you get a default VPC, with a few default components.

In GCP, your gsuite subscription or your top level organization is not associated with any default VPC. That’s the first difference between AWS and GCP VPCs.

The second difference is the crucial one (so I am going to highlight it )

In GCP, all VPCs, including their associated routes and firewall rules, are global resources.

Why do we even need more than one VPC?

In AWS, if you have multiple accounts, you automatically have multiple VPCs.

In GCP, although you don’t need multiple VPCs, some customers are keen to keep resources within each VPC isolated (ideally, GCP wants you to do this via Projects, not VPCs).

Bottomline, in both clouds, you can end up with multiple VPCs.

VPCs can talk to each other (i.e. resources in VPCs can talk to each other), using either sharing or peering. 

These two options are discussed in this post.

Peering of VPCs

 VPCs are global entities on GCP. Peering is not needed to communicate between regions.

However, organizations may want to separate their deployments in different VPCs for isolation purposes

VPC Network peering allows private connectivity between two VPC networks, regardless of whether they belong to the same project or the same organization. Note the terminology — it’s the NETWORK that’s peered, not the VPC (VPCs are global entities in GCP. They are NOT associated with a region or a zone.).

Sharing of a VPC (in Google Cloud vs AWS)

   A SHARED VPC, on the other hand, is suited for sharing network resources from MULTIPLE projects to a common VPC network. This provides projects the ability to talk to each other using Private IPs etc.

In AWS, the biggest problem used to be the tight coupling of accounts and networks (VPCs and subnets could not be shared outside the account ).

 VPC sharing allows customers to share subnets with other AWS accounts within the same AWS Organization. This allows efficiencies such as higher density in subnets, efficient use of VPNs and AWS Direct Connect.

Costs can be optimized through reuse of NAT gateways, VPC interface endpoints, and intra-Availability Zone traffic.

 Essentially, AWS can now decouple accounts and networks. Customers can now have fewer, larger, centrally managed VPCs.

 What use is VPC Peering?

Earlier, you could only exchange subnet routes,  but not any custom routes using VPC peering. For example, if you created a BGP dynamic route in one VPC via Cloud Router, it couldn’t be used or wasn’t visible from any of its peered VPCs.

As of 2019, Google announced that you can now exchange any type of routes between two peered VPC networks, including static routes, subnet routes and dynamic BGP routes.

Using a peered VPC service with static routes
Many applications or services are using static routes instead of subnets routes for connectivity. An example is using Equal Cost Multi-Path (ECMP) with static routes to load balance traffic to multiple third party appliances. Starting now, you can set up your VPC peering so that two VPCs exchange their static routes; this means that those appliances are available from another VPC. You can do this by configuring import/export policies on a VPC peering connection.

The Project Boundary in GCP

GCP defines something called a Project. Multiple Projects do not require that each Project have its own network.

 In fact, you could create one large development network within GCP (global or regional) and then create unique development Projects to isolate resources for each development team.

 The fact that all these resources are in the same network does not diminish the security that the Project boundary creates. This makes things like shared services and security auditing tools much easier to orchestrate since they can have cross Project access.

  This is a much cleaner solution to isolating resource access. If you have had conversations with AWS customers explaining the hurdles in providing resource based access control, within the same account and network, you will appreciate the Google project boundary.

What do Projects have to do with VPCs?

A project can have multiple VPC networks. Resources in different VPCs can be connected as long as there are no overlaps in the IP address spaces.

What about IP addresses for my instances?

VPC networks do not contain publicly routable IP addresses. However, each instance’s network interface can have a
public IP address in addition to a private IP address.

Like private IP addresses, public IP addresses are not guaranteed to persist across instance restarts.

Configure a static public IP address if you need public IP addressing that doesn’t change.

Dynamic allocation of a public IP address through the GCP API is also possible (and useful for automation).

If you need multiple private IP addresses on a single network interface, you need to configure a network interface with an IP address alias range (at the OS level).

You must configure IP addresses from the alias range in the instance’s operating system because GCP does not distribute them through DHCP.

Next Steps?

This was meant to be a broad overview of networking in GCP – and how it differs from the AWS world.  Hopefully, it will help you get started with Google Cloud.

Looking for a certified Google Cloud Architect? Try setting up a time with Anuj Varma