GCP (Google Cloud) Networking: Subnets

Google Cloud networking subnets are built upon a set of foundational components that enable flexible, secure, and scalable networking. Here are the key elements:

• VPC Network: The primary container for your network resources. Every subnet exists within a specific Virtual Private Cloud (VPC) network, which organizes routing, firewall rules, and network segmentation.
• Subnet: A regional segment of the VPC network, defined by an IP address range in CIDR notation. Subnets allocate internal IP addresses to resources within a given region, allowing logical and geographic segmentation of workloads.
• Primary and Secondary IP Ranges: The primary range is set at subnet creation and is used for most resources. Optionally, additional secondary ranges can be added for use cases like Kubernetes clusters or alias IPs.
• Firewall Rules: Stateless or stateful rules control what network traffic is allowed to and from resources in each subnet. They help protect your infrastructure by filtering ingress and egress traffic at the network level.
• Routes: Define how packets are forwarded within the VPC network or to connected networks (such as on-premises or the internet). System routes are automatically added to enable internal communication, while custom routes can be configured for specialized routing needs.
• Connectivity Options: Subnets support connectivity to external networks and other VPCs via options such as Cloud VPN, Cloud Interconnect, Shared VPC, and VPC Network Peering.
• Flow Logs (Optional): Enable logging of network flow information for resources in a subnet, enhancing visibility for monitoring, troubleshooting, and security analytics.

Google Cloud VPC networks support two distinct subnet configuration modes, each offering a different level of control and automation:

• Auto Mode: Automatically creates a subnet in each GCP region with pre-assigned IP ranges. This mode is ideal for quick setups or small-scale environments that don’t require custom IP planning. As new GCP regions become available, subnets are automatically created in those regions.
• Custom Mode: Provides full control over where subnets are created, which regions are used, and what IP ranges are assigned. Custom mode is recommended for production environments, larger organizations, and when integrating with existing on-premises networks.

Once a VPC network is created, the subnet mode cannot be changed. It is crucial to choose the correct subnet mode based on your organization’s networking requirements and future scalability needs.

Understanding subnet properties helps you design and manage Google Cloud networks efficiently. Each subnet has several attributes that define its scope, usage, and connectivity:

• Name: A unique identifier for the subnet within the project and region.
• Region: Specifies the geographical area where the subnet and its resources reside. All resources in a subnet must be within the same region.
• IP Address Range (CIDR): Defines the range of internal IPv4 addresses available in the subnet using CIDR notation (e.g., 10.0.1.0/24).
• Secondary IP Ranges: Optional additional CIDR ranges used for specific workloads, such as GKE Pods and Services.
• Gateway Address: The default gateway IP used by resources in the subnet to route traffic outside their own range.
• Private Google Access: Enables or disables the ability for resources without external IP addresses to connect to Google Services privately.
• Flow Logs: Optionally records network traffic information, helpful for monitoring, logging, and analyses.
• IPv6 Ranges: Supports IPv6 CIDR blocks for subnets where dual-stack or IPv6-only deployments are required.
• Purpose: Describes if the subnet is used for general networking, Private Service Connect, or other specific use cases.
• State: Indicates whether the subnet is in a usable state or being created/deleted.

These properties allow fine-grained control over network segmentation, routing, and security within Google Cloud projects.

Working with subnets in Google Cloud involves several key operations to create, modify, and manage your network infrastructure. Below are the most common subnet operations and their use cases:

• Create a Subnet: Create a new subnet within a VPC network by specifying a region and an IP CIDR range. You can also configure secondary IP ranges, enable flow logs, and specify whether the subnet should support Private Google Access.
  
  gcloud compute networks subnets create my-subnet \ --network=my-vpc \ --region=us-central1 \ --range=10.0.1.0/24
• Update a Subnet: Modify an existing subnet to add or update secondary IP ranges, enable or disable flow logs, or toggle Private Google Access without affecting the existing IP allocations.
  
  gcloud compute networks subnets update my-subnet \ --region=us-central1 \ --enable-private-ip-google-access
• View Subnet Details: List and inspect the properties of your subnets to audit configurations or verify deployments.
  
  gcloud compute networks subnets describe my-subnet \ --region=us-central1
• Delete a Subnet: Subnets can only be deleted if no resources (such as VM instances) currently use them. It’s important to clean up dependencies first.
  
  gcloud compute networks subnets delete my-subnet \ --region=us-central1

These operations enable you to manage your subnets throughout their lifecycle with control and precision. Whether you're deploying a new service or reconfiguring your network, these commands provide the foundation.

Follow these step-by-step instructions to create a custom subnet in Google Cloud Platform. This example uses the command line interface (CLI) for demonstration:

1. Choose or create a VPC network:
   If you don’t have a VPC network yet, create one first. For this example, assume the network is named my-vpc.
2. Select a region:
   Decide where you want your subnet to reside. This determines where resources that use this subnet will run. For example, use us-central1.
3. Define the primary IP address range:
   Specify a unique CIDR block for the subnet, such as 10.0.1.0/24.
4. Run the gcloud command:
   Use the following command to create your subnet:
   
   gcloud compute networks subnets create my-custom-subnet \ --network=my-vpc \ --region=us-central1 \ --range=10.0.1.0/24
5. Verify creation:
   After running the command, you can confirm the subnet exists by listing subnets in the region:
   
   gcloud compute networks subnets list \ --network=my-vpc \ --region=us-central1

This process allows you to create subnets tailored to your networking architecture and regional requirements, enabling precise IP management and network segmentation.

Subnets in Google Cloud are essential for structuring, isolating, and scaling your workloads. Below are common use cases, each outlined step by step to illustrate when and why subnets are used:

• Environment Segmentation:
  
  1. Create separate subnets for development, testing, and production environments.
  2. Enforce security boundaries by applying different firewall rules to each subnet.
  3. Isolate resource communication to reduce the blast radius in case of an incident.
• Network Security Isolation:
  
  1. Place frontend (public-facing) and backend (internal-only) workloads in separate subnets.
  2. Apply stricter firewall policies to backend subnets to prevent unauthorized access.
  3. Control external IP assignments to limit exposure to the internet.
• Scaling and IP Management:
  
  1. Allocate non-overlapping address ranges to each subnet to manage large-scale deployments.
  2. Expand IP allocation with secondary ranges for container platforms like GKE.
  3. Segment services and applications for easier IP tracking and reduced conflicts.
• Hybrid and Multi-Region Deployments:
  
  1. Create regional subnets to localize resources and reduce latency.
  2. Integrate on-premises networks with dedicated subnets for hybrid architectures.
  3. Deploy resources closer to user bases by utilizing subnets in multiple geographic regions.
• Regulatory and Compliance Requirements:
  
  1. Establish subnet boundaries to enforce compliance (e.g., data segmentation by region).
  2. Apply logging and monitoring via flow logs for auditing network activity.
  3. Restrict access based on subnet membership to meet regulatory controls.

These use cases demonstrate how thoughtful subnet design empowers robust, secure, and scalable cloud infrastructure tailored to a wide range of organizational needs.

Adopting best practices for subnet design and management ensures your Google Cloud networking is secure, scalable, and efficient. Follow these step-by-step recommendations to maximize network reliability and maintainability:

• Plan IP Ranges Carefully:
  
  1. Use non-overlapping CIDR blocks to avoid conflicts between subnets and VPCs.
  2. Allocate larger ranges than immediately necessary to allow for future growth.
  3. Document your IP scheme for easy audits and troubleshooting.
• Choose Custom Mode for Production:
  
  1. Use custom mode VPC networks to control subnet creation and avoid unwanted IP overlap.
  2. Design your subnets to match organizational boundaries like environment or team.
• Enable Flow Logs and Monitoring:
  
  1. Enable flow logs for all subnets to track, monitor, and analyze network traffic.
  2. Integrate with logging and monitoring tools for real-time insights and alerting.
• Apply Strict Firewall Rules:
  
  1. Follow the principle of least privilege—only allow necessary inbound and outbound traffic.
  2. Segment workloads using subnet-level or VPC-level firewall rules for added security.
• Leverage Private Google Access:
  
  1. Enable Private Google Access in subnets that host resources without external IPs.
  2. This ensures those resources can reach Google APIs securely without exposure to the public internet.
• Review Regularly and Clean Up Unused Subnets:
  
  1. Periodically audit your subnets and IP allocations to ensure they align with current needs.
  2. Delete unused subnets to reduce management overhead and potential security exposure.

Applying these best practices helps you build a network foundation that is secure, adaptable, and ready for future business requirements.