Securing communications and establishing boundary protection

Designing and configuring perimeter security

Web Application and Edge Protection

Inbound traffic from the public internet first hits the Google network edge, where perimeter controls evaluate requests before they reach core application workloads. Google Cloud Armor integrates directly with external Application Load Balancers to defend against Distributed Denial of Service (DDoS) attacks and filter malicious web traffic. Security policies inspect HTTP and HTTPS requests using web application firewall (WAF) rule sets, rate-limiting policies, and custom IP allowlists or denylists. When Cloud Armor detects malicious payloads or unexpected traffic spikes, it drops or redirects the traffic at the global edge. Legitimate requests pass through to the backend services, ensuring that unhealthy or hostile traffic never consumes internal compute resources.

Data Perimeters and Exfiltration Defense

While edge defenses protect incoming web requests, VPC Service Controls establish a boundary around sensitive Google Cloud managed resources to prevent unauthorized data exfiltration. Administrators configure a service perimeter around services like Cloud Storage and BigQuery within one or more projects. The perimeter stops API requests from moving data outside the boundary, even if a user presents valid identity credentials. When secure access across perimeters or from external networks is required, teams define access levels using Access Context Manager or configure explicit ingress and egress rules. This approach enforces zero-trust controls by validating both the network context, such as source IP or client device state, and the caller identity before granting access.

Configuring boundary segmentation

Hierarchical Policies and Workload Isolation

Network segmentation controls how traffic moves between distinct environments and internal workloads within a cloud organization. Security teams use hierarchical firewall policies to enforce non-negotiable security rules at the organization and folder levels before individual project rules are evaluated. Below the organization level, VPC firewall rules filter ingress and egress traffic at the virtual machine level. Instead of relying solely on dynamic IP addresses, rules target service accounts and network tags to bind access directly to workload identity. This strict separation prevents lateral movement, meaning a compromised workload in one tier cannot automatically connect to systems in another tier.

Multi-Tenant Architecture and Shared Networks

Organizations isolate environments like production and development by separating them into distinct VPC networks or segmenting them with Shared VPC. A Shared VPC centralizes network administration, such as subnets, routes, and firewalls, within a designated host project while delegating application management to service projects. To inspect east-west traffic moving between internal tiers, teams can route traffic through third-party virtual appliances using multi-network interface virtual machines. Network policies apply automatically as new instances deploy, ensuring that workloads maintain strict isolation throughout their lifecycle.

Establishing private connectivity

Accessing Google APIs Without External IPs

Workloads often need to interact with Google services and third-party tools without exposing virtual machines to the public internet. Private Google Access allows virtual machine instances that only have internal IP addresses to reach external Google APIs and services. Traffic leaves the instance on an internal IP address and routes directly to Google APIs through internal routing paths, bypassing the public internet entirely. Teams configure DNS to route requests to the restricted.googleapis.com domain when pairing this traffic with VPC Service Controls. This order of operations ensures that private workloads never require public IP addresses to process data or call administrative APIs.

Inter-Network and Hybrid Private Connectivity

Connecting distinct networks together requires choosing between VPC peering, private endpoints, or hybrid physical connections based on route exposure and scale:

• Private Service Connect allows consumer VPC networks to privately access services in producer VPCs or third-party SaaS platforms using local forwarding rules and internal IP addresses, preventing route table overlap.
• VPC Network Peering connects two VPC networks directly with low latency, sharing all subnet routes across the peering connection without traversing the public internet.
• Cloud VPN creates an encrypted, IPsec-secured tunnel between on-premises data centers and VPC networks over the public internet, ideal for lower-bandwidth or backup connections.
• Cloud Interconnect provides a dedicated physical connection or partner-assisted private line directly into Google's network for enterprise workloads requiring high availability and high throughput.