7. GCP Networking Basics: VPCs, Subnets, and routing tables.

Introduction: Virtual Private Clouds

VPC is a secure, individual, private cloud-computing model hosted within a public cloud. Imagine your Virtual Private Cloud (VPC) as a dedicated, secure slice of Google's vast cloud infrastructure. It's your private network where you have full control over how resources communicate with each other and the outside world. Think of it as a virtualized version of your own company's private data center, only hosted remotely by Google.

With VPCs, you can run code, store sensitive data, host websites, and perform any task you typically associate with a traditional private cloud environment. Using sophisticated network controls like subnets, firewall rules, and custom routes, you can shape traffic flows, isolate groups of resources, and connect your GCP-based systems to both the internet and your existing on-premises infrastructure when needed.

To learn more about how VPCs work, let's go into subnets.

Subnets

What are subnets?

Subnets are logical subdivisions of your VPC. They let you organize resources based on function, security requirements, or geographic location. Each subnet is assigned a range of IP addresses from the VPC's overall address space. Resources within a subnet can communicate freely with each other by default.

Every subnet is assigned a specific range of IP addresses (CIDR block) drawn from the broader VPC's overall IP address space. For example, in a VPC with address space 10.0.0.0/16, you might have:

• Subnet A: 10.0.1.0/24

• Subnet B: 10.0.2.0/24

Machines within the same subnet generally communicate freely. But traffic crossing subnet boundaries requires routing rules (more on that later!), just like how offices need doorways to interact with other offices.

The Relationship Between VPCs and Subnets:

Think of a VPC as a large building and subnets as the individual rooms within that building. Your VPC defines the overall network perimeter, and subnets create different compartments for specific purposes.

Why use subnets?

• Organization: Group similar resources together, such as all your web servers in one subnet and database servers in another.

• Security: Restrict traffic flow between subnets. For example, a sensitive subnet holding financial data could be isolated from front-end web servers.

• Scalability: As your project grows, subnets make it easier to add resources without completely restructuring your network.

IP Addressing in GCP

Within your VPC(s), Google Cloud utilizes both internal and external IP addresses to enable seamless communication and control where traffic flows. Understanding these addresses is crucial for effective network configuration.

Internal vs. External

• Internal IP Addresses: Used for communication within your VPC and sometimes peered networks. These addresses are not reachable from the public internet, enhancing security and reducing reliance on public addresses.

• External IP Addresses: Assigned to resources that require accessibility from the public internet, such as websites or services with open APIs. They are unique addresses that route globally.

Ephemeral vs. Static

• Ephemeral IPs: These are dynamically assigned by GCP when resources are created and may change if a resource is stopped and restarted. This suits resources where having a consistent address is less important.

• Static IPs: You can reserve specific IP addresses within GCP. These are linked to your account and won't change during a resource's lifetime. They are often used for services requiring long-term address stability, such as databases and VPN endpoints.

Regional vs. Global

• Regional IPs: Tied to a specific GCP region. Most resources will use regional internal and external IP addresses.

• Global IPs: Some specialized services (primarily load balancers) leverage global IP addresses. Traffic directed to a global IP can be intelligently routed to resources across multiple regions, providing high availability and geographic fault tolerance.

Routes and routing tables

Routes are instructions telling your network how to forward data packets towards a destination. Every time a resource in your VPC wants to send data to another resource or to the internet, it relies on route instructions. These routes work together in something called a "routing table."

Routing Table

Each subnet is associated with a routing table. This table lists destinations (often as IP address ranges) and the "next hop" for reaching them. "Next hop" types can be various things: another VM in the subnet (direct delivery), a Gateway device, used for reaching other networks, often the "default gateway" to the internet or some special service endpoints within GCP.

VPC routing tables are built-in so you don't have to provision or manage a router. These are used to forward traffic from one instance to another within the same network, across subnetworks, or even between Google Cloud zones, without requiring an external IP address.

Example of a routing table for a webserver subnet:

Connecting Google VPC networks to other networks

VPC Peering

VPC peering allows the establishment of a relationship between two VPCs to exchange traffic. This proves useful when a VPC in one project needs to communicate with a VPC in another project. VPC Peering enables direct private communication between two VPC networks, even if they belong to different projects or organizations. Imagine it as building virtual bridges between cloud islands. It allows seamless integration, improves performance and security and optimizes cost.

Some users want to connect their VPC networks to other networks in their system, such as on-premise networks or networks in other clouds. There are several effective ways to achieve this.

1. Cloud VPN: One option is to start with a Virtual Private Network connection over the internet and use Cloud VPN to create a tunnel connection. To make the connection dynamic, a Google Cloud Router can be used.

2. Direct peering: This means putting a router in the same public data center as a Google point of presence and using it to exchange traffic between networks. This gives you direct access from your on-premises network through a service provider's network to Google.

3. Dedicated interconnect: Unlike Direct peering which isn't covered by a Service Level Agreement, this option can result in an SLA of up to 99.99% if the connections have topologies that meet Google's specifications.

4. Partner interconnect: This provides connectivity between an on-premises network and a VPC network through a supported service provider. It is useful if a. data center is in. a physical location that can't access a dedicated interconnect colocation facility.

5. Cross-Cloud interconnect: This helps establish high-bandwidth dedicated connectivity between Google Cloud and another cloud service provider. It supports the adoption of an integrated multicloud strategy.