In GCP, subnets are always found across multiple zones (availability zones) within a region. In other words, you can't create subnets on a single zone like AWS. You always need to specify entire regions when creating a subnet.

In addition, unlike AWS, there are no significant concepts of public and private subnets (in AWS, a public subnet has a default route as IGW; on the other hand, a private subnet has a default route as the NAT gateway). This is because all subnets in GCP have a route to an internet gateway.

Instead of subnet-level access control, GCP uses host (instance)-level access control using network tags to ensure network security. This will be described in more detail in the following section.

It might make network administrators nervous; however, GCP best practice gives you a much more simplified and scalable VPC administration because you can add subnets at any time to expand entire network blocks.

One more thing: an interesting and unique concept of GCP VPC is that you can add different CIDR prefix network blocks to a single VPC. For example, if you have custom mode VPC, then add the following three subnets:

• subnet-a (10.0.1.0/24) from us-west1
• subnet-b (172.16.1.0/24) from us-east1
• subnet-c (192.168.1.0/24) from asia-northeast1

The following commands will create three subnets from three different regions with different CIDR prefixes:

$ gcloud compute networks subnets create subnet-a --network=my-custom-network --range=10.0.1.0/24 --region=us-west1
$ gcloud compute networks subnets create subnet-b --network=my-custom-network --range=172.16.1.0/24 --region=us-east1
$ gcloud compute networks subnets create subnet-c --network=my-custom-network --range=192.168.1.0/24 --region=asia-northeast1

The result will be the following web console. If you're familiar with AWS VPC, you won't believe these combinations of CIDR prefixes are available within a single VPC! This means that, whenever you need to expand a network, you can assign another CIDR prefix to the VPC: