What makes GCP networking service different from other Cloud providers

by CloudDudein Uncategorizedon Posted on

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 & offering. Being already familiar with AWS, Azure, and Oracle Cloud, I didn’t expect to see much difference on 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 GCP networking, the 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 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 Azure, this will first confuse you and it will take you a moment to process this curiosity :). Here’s why!

First GCP Networking takeaways

  • 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/nodes, and
    services

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

This image has an empty alt attribute; its file name is image-2.png

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

CIDR Block size difference between Cloud providers

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.

This image has an empty alt attribute; its file name is image-5.png

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 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).  

    This image has an empty alt attribute; its file name is image-12.png 

  • 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).

    This image has an empty alt attribute; its file name is image-8.png

  • 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. 
    This image has an empty alt attribute; its file name is image-9.png 

 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).

This image has an empty alt attribute; its file name is image-10.png

The range must not overlap with any already defined subnet primary/secondary range in the region, or else you get an error.This image has an empty alt attribute; its file name is image-11.png

 

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 is 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 which 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

      This image has an empty alt attribute; its file name is image-13.png

           Ingress Rules
           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.

This image has an empty alt attribute; its file name is image-15.png

         Egress Rules
         Destination is always an IP range no matter the type of the 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 a 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 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)
      This image has an empty alt attribute; its file name is image-16.png

  • 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.
    This image has an empty alt attribute; its file name is image-17.png

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 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: