This post discusses a few real world scenarios for organizations moving to Google Cloud.

The  idea is to understand how multiple VPC architectures in GCP, especially those leveraging Shared VPCs (read this post for an in depth Shared VPC understanding), can map to real world org network teams and layouts.

Scenario 1 - Shared VPC with Prod and Non Prod Requierments

  • You are tasked with building a shared VPC.
  • Your Production and Staging departments can communicate with each other, but only via specific networks.
  • Your network and security team has strict controls over which routes are exposed between departments.

Solution

You might  think that you can get away with a single shared VPC here, and define individual subnets to create separation .
However, that is not going to provide the route separation or the firewall rules separation (since rules are defined at the common VPC level).
  • What you want to do is create TWO Shared VPCs - one for PROD and one for NON PROD.
  • Creating two shared vpc in the same project Host lets you use vpc peering to connect the two VPCs. Also, each VPC can now have it's own firewall rules and routes.

   Reference architecture Google Cloud

Scenario 2 -  An on-premises data center located in the United States, with departmental regions across the world

 

  1. Oregon (US West) and New York (US East) have provisioned Dedicated Interconnects connected to Cloud regions us-west1 (primary HQ) and us-east4 (backup)
  2. Multiple regional offices in Europe and Asia, will be using Google Cloud
  3. Regional data processing is required in Europe and Asia.
  4. Centralized Network Administration is a requirement
  5. Security Team requires a virtual inline security appliance to perform L7 inspection for URL filtering. Only ONE  appliance may be deployed (in any one US region)

Solution

At first glance, this seems like a lot. However, Shared VPCs make several of these tasks possible.

  1. Create 2 VPCs in a shared VPC host project.
  2. Create a 2 NIC Instance in the host project
  3. Attach NIC0 to uswest1 (Oregon) subnet of the host project; attach NIC1 to useast1  (New York) subnet of the host project.
  4. Deploy the L7 Security Appliance in the US region of choice (e.g. Oregon).
  5. Configure Custom Routes to pass all traffic through this Appliance. Next Hop should be configured to be this appliance instance.

Scenario (Transitive VPC Peering)

You need to establish network connectivity between three Virtual Private Cloud networks, Sales, Marketing, and Finance

Users should be able to access resources in all three VPCs.

Configure VPC peering between the Sales VPC and the Finance VPC.

Configure VPC peering between the Marketing VPC and the Finance VPC.

As you now realize, users cannot connect to resources in the Sales VPC and the Marketing VPC, since VPC Peering isn't transitive.

Solution

Instead of simply peering VPCs, you needed to define Full Mesh VPC Peering

Need a hands-on, GCP Consultant?

Need help with your GCP journey?  Start the conversation today.