Blogs

What makes Google Cloud Platform (GCP) Networking Service different from other Cloud Providers?

Intro

During my preparation for the GCP Associate Cloud Engineer Exam, I first got myself a free tier account which usually lasts 3 months. This allowed me to play with the Cloud Console as it’s the fastest way to get to know a cloud provider’s services and offers. Being already familiar with Amazon Web Services (AWS), Microsoft Azure, and Oracle Cloud Infrastructure (OCI), I didn’t expect to see much difference in the core infrastructure services. That’s where I was actually wrong because I found something very peculiar that didn’t take long to notice. The service in question was Google Cloud Platform (GCP) Networking, the Virtual Private Cloud (VPC) to be precise. Today, we will see what makes this network resource so special when coming from another Cloud provider along with some features that are specific to Google’s VPC.

 

GCP VPC contains no CIDR Block

Unlike any other Cloud platform, there is no VPC level CIDR block (Classless Inter-Domain Routing) range in GCP. The only level where the CIDR Block range is defined is in a subnet. If like me, you come from AWS or Microsoft Azure, this will first confuse you and it will take you a moment to process this curiosity. Here’s why!

First Google Cloud Platform Networking Takeaways

• Virtual Private Clouds (VPCs) are global resources; routing traffic between regions is automatic(no manual peering needed between regions)
• Subnets are regional resources (not within availability zones); traffic transparently moves across zones
• Routes are associated with the VPC. They can be restricted to instances via instance tags or service accounts
• VPC Can enable private (internal IP) access to some GCP services (eg BQ, GCS)
• GCP assigns regional internal IP addresses for VM instances, LBs, GKE pods (Kubernetes on Google Cloud)/nodes, and services

The below table can help visualize at which level the networking resources are defined for each Cloud platform.

• CIDR block size: The range is similar to Azure’s Vnet  (min /29,  max /8)

Subnets

In GCP the subnet is the only resource where a CIDR block range is defined. Each subnet is dedicated to a region and can contain different IP ranges as long as they don’t overlap. Global by nature, a VPC can even have multiple subnets within different regions with the same CIDR Block range which makes it unique in the cloud networking space.

• Let’s rather see how it works in practice by jumping right into the console and navigating to the VPC Network Section.

Each new project starts with a default network including 28 subnets in 28 regions worldwide and 4 default firewall rules.

My first reaction was obviously “why?”, but the short answer is because of the benefits of having multiregional subnets seamlessly routed with each other allowing their resources to communicate across regions.    

Subnet creation mode: There are two 

• Automatic Mode *
  With Auto mode, one subnet from each region is automatically created within it. These subnets (28) use a set of predefined IP ranges that fit inside 10.128.0.0/9 CIDR block. New subnets are automatically added for new regions to auto mode VPCs (inside the same CIDR Block)

• Custom Mode   
  This mode allows you to create custom subnets in specific regions with multiple CIDR block ranges 

   * No VPC peering is allowed between auto mode VPCs due to their IP range overlap

Example  

• Let’s create a custom mode VPC and explore the flexibility of its options (aka how far can we go). 

• Starting simple, I created a subnet with a /16 range in us-east1 region. I also added another subnet with the same IP range on a different region (us-west1).

• Now If I enter another subnet in us-east1 that overlaps with the first subnet, the Console will never warn me about it until I click create. In other cloud platforms, checks are done before creation hence are more intuitive. 

 

Secondary IP Range

A subnet may have a secondary CIDR range, from which a secondary IP range of a VM may be allocated(alias IP).

The range must not overlap with any already defined subnet primary/secondary range in the region, or else you get an error.

 

Expendable IP range

You can always expand the IP range of an instance’s subnet even after creation. This will allow you to avoid headaches when all your IPs run out and you have new instances to provision in the same subnet. See CLI command below

expand-ip-range command

$  gcloud compute networks subnets expand-ip-range MYSUBNET --region=us-central1 --prefix-length=16

• Here we reduced the prefix length from /17 to /16 which will make more addresses available for devices within this subnet.
• You can edit a subnet CIDR range as long as the new range can contain the old subnet’s CIDR range. A broader prefix will create conflict and trigger an error. 

 

GCP Firewall

Firewall rules are global resources akin to security groups that filter instance-based data flow and can be applied via Instances/ network tags, service accounts, and Instance Groups.

FIREWALL RULES

• Firewall rules are stateful and can have both allow and deny rules but are not sharable between VPC networks
• Firewall rules can be automatically applied to all instances. Default rules allow all egress traffic to all destinations while denying all ingress traffic from all sources
• Priority can be 0 – 65535, the default being 1000

• Firewall Targets: Every firewall rule in GCP must have a target that defines the instances to which it applies
  • All instances: All instances in the VPC network which is the default target tag
  • Network tags: Are added to an instance or a template for Instance Groups at/after creation in order for a firewall rule to be applied to these instances
  • Service account

Ingress Rules
The source can be either IP range, service accounts or network tag depending on the target type. You can use a combination of IP ranges + tags or IP ranges + service accounts but not both tags and service accounts in the same rule.

Egress Rules
The destination is always an IP range no matter the type of target chosen.

• Firewall Rules Logging:
  Similar to AWS VPC Flow Log, it logs traffic to and from GCEs for each rule. Each time the rule is applied to allow or deny traffic, a connection record is created. Connection records can be viewed in Cloud Logging.

 

Shared VPC

Within an Organization, VPCs can be shared among multiple projects and paired with other VPCs so a centralized team can manage network security.

Components

1. Host Project: will own the Shared VPC (enabled by Shared VPC admin)
2. Service Projects: will be attached/granted access to the Shared VPC in the host project within the same org (enabled by Shared VPC admin)

Consideration and limits

1. A service project can only be attached to a single host project.
2. Service project can’t be a host project and a standalone VPC Network is an unshared VPC Network
3. Shared VPC Admin for a given host project is typically its project owner as well.
4. If linked projects are in different folders, the admin must have Shared VPC Admin rights on both folders
5. Two options for sharing networks:
   • All host project subnets
   • Individual subnets to share

 

Unicast vs Anycast

Both are addressing methods that allow packets to reach the destination across the internet but only one is using google private network(anycast). The other difference between these two is the overall effectiveness and latency of route traffic.

• Unicast:
  Traditional routing where only one unique device in the world can be the next hop (one-to-one association)

• GCP Anycast:
  Where multiple devices can be the next-hop but the closest is the most ideal target.
  In Anycast IP network, the IP request is routed to the nearest Google server region/location. Once the traffic is inside the Google Cloud Network, it is routed through the Google Private Network Infrastructure to minimize latency. This is found on GCP load balancers that have Anycast IP defined.

 

Internet Access in a VPC

As for Azure, as soon as you enable an external IP address to an instance; It’ll immediately have internet access or NAT gateway if exists. No concept of a public subnet like we find in AWS.

 

CONCLUSION

• Knowing the breadth of the networking features in GCP, this is just a drop in the ocean but you get enough to start.
• I hope that the above write-up could help you grasp more about network characteristics that are unique to GCP
• I probably also wrote this concentrated cheat sheet for me in case I need a refresh!
• If you want to learn more about the networking differences between GCP and AWS or Azure here are two excellent articles on the matter:
  • • GCP Networking: GCP vs AWS
    • Cloud Networking: Azure vs GCP

More from this Author