This chapter will explore how to build a network and configure network services for your workloads in Google Cloud. We are going to cover the following topics:
- Virtual Private Cloud
- Hybrid networking
- Securing cloud networks with firewall rules
- Cloud DNS
- Network load balancing
Networking is the foundation of every system architecture. However, connecting internal cloud workloads across projects, exposing services to the internet, or building a hybrid network between an on-premises location and Google Cloud can be challenging. Therefore, it is worth understanding how Google Cloud’s network services portfolio could be used to build secure and reliable architectures.
Throughout this chapter, we will explore the concept of a Virtual Private Cloud (VPC) and its application in securing and connecting networks. Additionally, we will gain insight into the functioning of the DNS service in Google Cloud and identify the appropriate network load balancers for different types of workloads.
A VPC is a networking service for your Google Cloud workloads, such as Compute Engine VMs or GKE. It is commonly referred to as a logical representation of a network in a cloud. Unlike a physical network in a data center, all its complex networking aspects are abstracted, allowing users to focus solely on consumption rather than configuration.
A VPC is a global service that consists of one or more subnets that can be created in the same or different Google Cloud regions. Google Cloud uses subnets to organize and manage resources in a VPC by dividing it into regional segments. A subnet is identified by a region and an IP range defined in Classless Inter-Domain Routing (CIDR) notation. CIDR can be described as a group of IP addresses used by a network (a subnet, in this case). It looks like a regular IP address but ends with a slash and a number. The number after the slash tells you how many addresses are within the range. For example, a CIDR IP address in IPv4 of 10.0.1.0/24 can be used by a subnet that needs 256 IP addresses (from 10.0.1.0 to 10.0.1.255).
Regardless of their region, subnets in the same VPC are seamlessly connected without requiring any extra setup, such as VPN. Communication between workloads in the same VPC is internal and does not travel over the internet.
Please note that it is possible to create multiple VPCs for each project. However, they will be separated from each other by default.
The communication between workloads in the same VPC, but also to different VPCs or external environments, is always controlled by the firewall rules of a VPC. For example, even if VMs in different subnets of the same VPC should be able to communicate with each other, firewall rules that explicitly allow this communication must exist. We will cover firewall rules later in this chapter.
The following diagram shows an example of a project with two VPCs: VPC A and VPC B. Each VPC has three subnets configured in different regions, including Subnet1, Subnet2, and Subnet3 in VPC A, and SubnetA, SubnetB, and SubnetC in VPC B. Subnets within the same VPC are already connected and do not require any additional configuration. However, communication between workloads in different VPCs will require a VPN connection or VPC peering. In both cases, firewall rules must be in place to enable traffic between workloads:
Figure 9.1 – Subnets in the same VPC can communicate with each other. Firewall rules control this communication. Subnets in different VPCs require additional setup to connect
You can create a VPC network, subnets, and firewall rules in Google Cloud Console or using gcloud compute commands. For example, to create my-vpc-network in the my-demo-project project, the following command could be used:
gcloud compute networks create my-vpc-network –project=my-demo-project –subnet-mode=custom –mtu=1460 –bgp-routing-mode=regional
To create a 10.0.0.0/24 subnet called my-first-subnet in my-vpc-network in europe-central2 region, you could use this command:
gcloud compute networks subnets create my-first-subnet –project=my-demo-project –range=10.0.0.0/24 –stack-type=IPV4_ONLY –network=my-vpc-network –region=europe-central2