Networking Fundamentals for Data Engineering Pipelines

Implement and Manage Load Balancing and Network Services is the practice of distributing data workloads across healthy backends and connecting those backends with private and scalable network services. Cloud Load Balancing (opens in a new tab) is a portfolio of global and regional load balancers where traffic flows from clients to a load balancer frontend and then from the frontend to healthy backends selected by routing rules and health checks. For data pipelines, the load balancer depends on backend services, health checks, firewall rules, and supporting services such as Private Service Connect (PSC) (opens in a new tab), Cloud NAT (opens in a new tab), and Cloud DNS (opens in a new tab) to provide reliable, scalable, and private access to data services and APIs.

1.1Global and Regional Load Balancers for Data Workloads

Global and regional load balancers for data workloads distribute inbound traffic across zonal, regional, or multi-regional backends to increase availability and absorb peak traffic for data APIs and processing front ends. A global external Application Load Balancer can provide cluster selection across Google Kubernetes Engine (GKE) clusters in distinct regions, while a Cloud Service Mesh-managed ingress gateway then provides cluster-specific load balancing and ingress security. This composite ingress model separates the first decision of which cluster receives traffic from the second decision of how traffic is routed inside the cluster. Use application capacity optimization with global load balancing when globally distributed applications face capacity constraints.

GKE configures load balancing through the Kubernetes Gateway API, which is the recommended approach for new applications. In this model, traffic flows from the internet client to a Gateway resource that defines listener ports, protocols, and hostnames as the entry point, then to HTTPRoute rules that route to Services by path, header match, or traffic split, with Policy resources attached to the Gateway, Route, or Service to control the underlying Google Cloud infrastructure. The GKE Gateway controller is Google's implementation of the Gateway API and succeeds the Ingress resource with more expressive routing. For complex microservices, Cloud Service Mesh, built on Istio, adds service-to-service authentication, authorization, encryption, and traffic management behind the edge load balancer.

External access data flow for GKE follows an ordered sequence:

1. Client to load balancer: An internet client sends a request to a Service of type LoadBalancer or a Gateway resource, and the request first reaches the Google Cloud load balancer.
2. Load balancer to node: The load balancer forwards the request to a healthy node in the cluster based on health checks.
3. Node to Pod: The node forwards traffic to the destination Pod on the same or a different node, using kube-proxy on standard clusters or eBPF programs on clusters that use GKE Dataplane V2.

Setting externalTrafficPolicy to Local in the Service avoids the extra hop by sending traffic only to nodes that host healthy Pods, but the tradeoff is uneven distribution if Pods are not evenly spread across nodes.

1.2Choosing a Load Balancer Type

Choosing a load balancer type depends on what layer must make the routing decision and whether client identity and protocol support matter. Application Load Balancer operates at Layer 7 and routes on HTTP attributes, proxy Network Load Balancer terminates TCP or TLS at a proxy for multi-region TCP distribution, and passthrough Network Load Balancer preserves the original packet path without proxy overhead. Combining an API gateway or proxy with an Application Load Balancer provides a more robust front end for API traffic at scale. The gateway acts as a unifying facade that shields clients from backend changes, centralizes security, and creates audit trails between decoupled components, while the load balancer distributes traffic across gateway instances.

Using Cloud Load Balancing with API gateways accomplishes the following for API traffic:

• Provide high-performing APIs with Apigee and Cloud CDN to reduce latency, host APIs globally, and increase availability for peak seasons.
• Implement advanced traffic management across backends and regions.
• Use Cloud Armor as distributed denial of service (DDoS) protection and network security for APIs.
• Manage efficient load balancing across gateways in multiple regions, including multi-region failover for Apigee runtimes.

1.3Hybrid Load Balancing to On-Premises and Other Clouds

Hybrid load balancing extends Cloud Load Balancing to services hosted outside Google Cloud by using hybrid connectivity network endpoint groups (NEGs). Traffic flows from the Google Cloud load balancer frontend to on-premises or other-cloud endpoints through Cloud Interconnect, Cloud VPN, or Cross-Cloud Interconnect, which enables phased workload migrations with minimal service disruption. This pattern also balances requests across Google Cloud and another cloud platform without moving all backends at once. If outbound data transfer from Google Cloud toward other environments is high and sustained, consider Cloud Interconnect or Cross-Cloud Interconnect to optimize performance and potentially reduce transfer charges.

An API gateway or proxy is often deployed in front of diverse hybrid backends to overcome inconsistencies in protocols, APIs, and authentication mechanisms. Apigee and Apigee Hybrid can host enterprise-grade gateways across on-premises, edge, other clouds, and Google Cloud, acting as an intermediate communication layer between legacy and modernized services. For reliability, spread backends across zones and regions, and for performance consider increasing maximum transmission unit (MTU) and using Border Gateway Protocol (BGP) Bidirectional Forwarding Detection (BFD) where supported to speed detection of BGP disruptions. BFD is not supported in BGP sessions for Cloud VPN tunnels or for network virtual appliances configured as Router appliance spokes.

1.4Private Service Connect for Private Data Access

Private Service Connect for private data access enables private, unidirectional access to services and Google APIs using internal IP addresses without traversing the internet. The producer side depends on an internal HTTP(S) or TCP proxy load balancer plus a service attachment published in a PSC subnet, while the consumer side creates a PSC endpoint in its own Virtual Private Cloud (VPC) network that routes to that attachment. The trust boundary sits between consumer and producer VPC networks, so each side controls its own firewall and access policy while traffic stays on Google's internal network.

PSC supports three private patterns for sensitive data pipelines such as retrieval-augmented generation. Private input hosts a Cloud Storage bucket behind a PSC endpoint in the routing VPC so retrieval data is copied over Cloud Interconnect or Cloud VPN using only private addresses. Private inter-service connectivity lets services communicate over internal interfaces or VPC-private addresses. Private output keeps inference results unreachable from the internet by default, so only users in the designated external network can reach the private endpoint of the service.

Deploying PSC for landing-zone and workload VPCs requires coordinated producer and consumer steps. The transit VPC must create a PSC subnet in each region where services are published and consider PSC subnet sizing in the IP plan, then expose each on-premises service through an internal load balancer and PSC service attachment and configure PSC for Google APIs. Each workload VPC enables Private Google Access on subnets so virtual machines (VMs) with only internal addresses can reach Google services, creates a PSC consumer endpoint for each workload consumed from another VPC or on-premises, and creates an internal load balancer with service attachment for each workload it produces. If a workload must be reachable from on-premises, an additional PSC consumer endpoint is created in the transit VPC.

1.5Cloud NAT for Controlled Outbound Access

Cloud NAT for controlled outbound access is a managed regional service that lets private resources initiate outbound internet connections without receiving inbound connections from the internet. Traffic flows from private Pods or VMs with only internal IP addresses to the Cloud NAT gateway, which translates the source address for egress to download updates, packages, or external APIs. The gateway depends on Cloud Router for its control configuration and applies per-region, so workloads in each region that need egress require their own gateway. You can restrict the gateway to specific subnets to limit which workloads can reach the internet.

Create a Cloud NAT gateway in each region where workloads require outbound internet access and customize the source subnets when least-privilege egress is required. At a minimum, enable Cloud NAT logging for ERRORS_ONLY to capture failures, and configure logging to ALL when translation records are needed for audit or troubleshooting. For private GKE clusters, Cloud NAT is the standard path for Pods without public IPs to reach the internet, while Private Google Access is the separate path for reaching Cloud Storage, Cloud SQL, and *.googleapis.com, *.gcr.io, and *.pkg.dev without using the public internet. All GKE clusters also require outbound connectivity to the control plane IP address to function.

1.6Cloud DNS for Global and Hybrid Discovery

Cloud DNS for global and hybrid discovery resolves service names to load balancer frontends and supports routing policies that steer clients across regions and environments. Geolocation DNS routing policies provide a single global DNS name that resolves to different regional load balancers based on client location, which is useful for hybrid applications that run alongside an on-premises deployment where a Google Cloud region exists. Split-horizon DNS returns different records for the same query from internal versus external clients, keeping private endpoints private while exposing public names externally. Configure a reasonably short time to live (TTL) so DNS changes propagate quickly and users can be rerouted to standby systems during bursts or failover.

DNS policy selection aligns with the hybrid architecture pattern and burst behavior. Cloud bursting designs keep Google Cloud resources private with no direct internet access, even when an external load balancer is the entry point, and use DNS policies permanently or only during peak demand from another environment. Monitor traffic sent from Google Cloud to other environments because it is subject to outbound data transfer charges, and use Spot VMs and containers with GKE for portable, non-time-critical batch jobs that can restart if preempted. Reference architectures for hybrid DNS provide validated patterns for forwarding between on-premises resolvers and Cloud DNS.

1.7Securing and Observing Load-Balanced Front Ends

Securing and observing load-balanced front ends combines edge protection, encryption, and VPC controls around the same traffic path. Google Cloud Armor attaches to load balancer frontends to provide edge DDoS defense and web application firewall (WAF) rules, while Google-managed Secure Sockets Layer (SSL) certificates terminate Transport Layer Security (TLS) without managing separate private keys. Enabling caching takes advantage of Cloud CDN's distributed delivery footprint to reduce latency for cacheable API and content responses. Inside the VPC, Cloud Next Generation Firewall (Cloud NGFW) inspects and filters traffic, and Cloud intrusion detection system (IDS) mirrors and inspects north-south traffic for threats.

To expose a private service publicly, use a regional external Application Load Balancer, or use GKE Inference Gateway instead of an Application Load Balancer when the frontend runs on GKE. For private AI workloads, Model Armor can be attached to the Application Load Balancer to evaluate inbound prompts and outbound results before requests reach the serving subsystem, and VPC Service Controls helps prevent data exfiltration across service perimeters. For observability, use VPC Flow Logs with Flow Analyzer for traffic patterns, Firewall Rules Logging with Firewall Insights for rule verification, Connectivity Tests to verify intended paths, and Cloud Logging and Cloud Monitoring for compliance and operations.

Design and Configure VPC Networks and Hybrid Connectivity is the practice of building isolated cloud networks for data pipelines and then linking them securely to on-premises or multicloud sources. A Virtual Private Cloud (VPC) (opens in a new tab) network in custom mode gives the pipeline team full control over subnets per region, while hybrid links carry ingestion traffic from on-premises databases and sensors into Google Cloud without traversing the public internet when private transport is used. Together, subnets, firewall policies, routes, and hybrid attachments determine where data can flow, what is inspected, and how reliably high-volume ingestion performs.

2.1Design Custom-Mode VPC Networks and Subnets

Design of custom-mode VPC networks and subnets creates subnets explicitly per region instead of automatically in every region. Data engineering landing zones use separate projects for the hub VPC network, transit VPC network, and each workload spoke VPC network, and each project enables the Compute Engine API before its network is created. This separation isolates network administration from workload ownership and lets each environment be repeated for development, staging, and production.

Subnets in workload VPC networks host pipeline resources such as virtual machines, Dataflow workers, and Google Kubernetes Engine nodes. Each subnet is created in the regions where workloads run, and Private Google Access is enabled on the subnet so virtual machines with only internal IP addresses can still reach Google APIs and services. Private Service Connect is then configured for Google APIs in the hub, transit, and workload VPC networks, so API traffic stays on private paths. For service-to-service sharing, a workload creates a PSC consumer endpoint to consume a service from another VPC or on-premises, and creates an internal load balancer plus service attachment to produce a service for others, with PSC subnet sizing planned in the IP addressing design.

Centralized outbound internet access is provided by Cloud NAT. A Cloud NAT gateway is created in each region where workloads need outbound access for package downloads or updates, and it can be scoped to only specific subnets. At a minimum, Cloud NAT logging is set to ERRORS_ONLY, while ALL is used when every translation must be logged for audit or troubleshooting.

2.2Enforce Firewall Rules and Hierarchical Policies

Firewall enforcement in Google Cloud combines distributed stateful firewall rules with hierarchical firewall policies that apply consistently across an organization. Design follows least-privilege, also called microsegmentation: block all traffic by default and allow only the specific protocols and ports each workload needs. Firewall rules logging is enabled for visibility into allowed and denied behavior and to feed Firewall Insights.

Rule priority controls evaluation order, with lower numbers evaluated first, so more specific rules must be placed higher than general rules or they will be shadowed. A numbering methodology reserves ranges for different intents:

Hierarchical firewall policies enforce organization-wide exceptions that individual VPC firewalls must not block. Identity-Aware Proxy (IAP) for TCP forwarding is allowed by permitting ingress from 35.235.240.0/20 for TCP ports 22 and 3389. Health checks for Cloud Load Balancing are allowed from well-known ranges for ports 80 and 443, with different ranges for most load balancers versus Network Load Balancing.

2.3Control Routing, Peering, and Centralized Inspection

Control of routing, peering, and centralized inspection determines how VPC routes are learned, shared, and forced through inspection. Cloud Router (opens in a new tab) is a Border Gateway Protocol (BGP) speaker that provides dynamic external BGP routing for HA VPN, Classic VPN, Dedicated Interconnect, and Partner Interconnect. The Cloud Router lives only in the control plane and creates routes in the software-defined network; it never re-advertises learned prefixes and does not carry data-plane traffic.

Cloud Router dynamic routing operates in two modes on each VPC network. Regional routing advertises only subnets that co-reside in the same region as the Cloud Router. Global routing advertises all subnets of the VPC network regardless of region, but penalizes routes learned outside the local region to preserve in-region symmetry by adding a penalty metric equal to 200 plus the inter-region time-to-live in milliseconds. Static routing is available only on Classic VPN, where a static route sets a next-hop Cloud VPN tunnel, applies globally by default, and can be scoped with instance tags; equal-priority tunnels to the same prefix share traffic with 5-tuple hash-based Equal-Cost Multipath (ECMP).

Hub-and-spoke designs share hybrid routes without placing attachments in every spoke. With VPC Network Peering, the hub VPC network enables custom route export and each workload spoke VPC network enables custom route import, so the Cloud Router custom advertised routes for hub and workload subnet ranges flow from the hub to the spokes. For inspection, transit and hub VPC networks route through network virtual appliances fronted by internal TCP/UDP load balancers, where one load balancer carries traffic from the transit VPC to the hub VPC and the other carries the reverse direction. The design deletes the 0.0.0.0/0 route with next-hop default-internet-gateway from the hub and spoke VPC networks and creates a new 0.0.0.0/0 route whose next-hop is the forwarding rule of the appliance load balancer, so all egress is forced through inspection before leaving toward on-premises or the internet.

2.4Establish Secure Hybrid Connectivity for Data Ingestion

Establish secure hybrid connectivity for data ingestion links on-premises and other-cloud data sources to VPC networks for ingestion and processing. Traffic that traverses these links carries all inter-environment pipeline data, so bandwidth, latency, packet loss, and jitter directly affect pipeline throughput and freshness. Google Cloud divides the choice by transport, performance, and encryption needs:

Cloud VPN encrypts traffic between VPN gateways as it traverses the internet, and HA VPN can meet up to 99.99% availability with a conforming architecture. Cloud Interconnect keeps traffic off the public internet, offers more deterministic performance with a service-level agreement (SLA), and can meet up to 99.99% availability with the appropriate dual-region architecture. When encryption is required at the network layer over private transport, use HA VPN over Cloud Interconnect or Media Access Control Security (MACsec) for Cloud Interconnect, including MACsec support on Cross-Cloud Interconnect.

Provisioning follows a consistent order:

1. Provision physical ports: Provision Dedicated Interconnect physical ports in a separate project with the Compute Engine API enabled, a step skipped for Partner Interconnect and Cloud VPN.
2. Create VLAN attachments and BGP sessions: For each region terminating hybrid connectivity, create two virtual local area network (VLAN) attachments, one for each edge availability zone, during which Cloud Routers are selected and BGP sessions are created.
3. Configure peers and advertise routes: Configure peer on-premises or other-cloud routers, and have Cloud Routers advertise hub and workload subnet ranges back on-premises with custom advertised routes.

On-premises services needed by pipelines are exposed into Google Cloud through an internal HTTP(S) or TCP proxy load balancer published with Private Service Connect, so spokes consume them by private endpoint.

2.5Scale Hub-and-Spoke with Network Connectivity Center and Observability

Scale of hub-and-spoke with Network Connectivity Center (NCC) (opens in a new tab) is achieved through an orchestration framework that scales centralized hybrid connectivity across many VPC networks. A central NCC hub connects spoke resources such as VPC networks, router appliances, VPN tunnels, and VLAN attachments. To scale, centralized hybrid connections and all VPC spokes are added to one or more dedicated connectivity VPC networks on the NCC hub with route exchange with VPC spokes enabled, so static and dynamically learned routes are exported to spokes from one place. This centralized NCC model replaces placing VPN tunnels or VLAN attachments in each individual VPC network, while VPC Network Peering with custom advertised routes remains an alternative when resource limits are not exceeded and network virtual appliances must be used.

Network Intelligence Center validates that the design behaves as intended for data flows. The Network Management API must be enabled before Connectivity Tests can run from the API, Google Cloud CLI, or console. The Firewall Insights API must be enabled before Firewall Insights can analyze firewall logging. Together with VPC Flow Logs, Cloud Logging, and Cloud Monitoring, these controls give pipeline teams end-to-end visibility from on-premises ingestion, through hybrid attachments and hub inspection, to workload subnets. Google Kubernetes Engine (GKE) (opens in a new tab) nodes in workload subnets depend on this same visibility to confirm that ingestion paths and firewall decisions work as designed.

Analyze Network Security and Performance for Data Pipelines is the practice of protecting data as it moves between pipeline stages while keeping latency, throughput, and cost under control. In Google Cloud, VPC Service Controls (opens in a new tab) creates a data-trust boundary around projects and Google-managed services, Cloud Next Generation Firewall (Cloud NGFW) (opens in a new tab) controls which virtual machine (VM) traffic is allowed, and observability comes from VPC Flow Logs (opens in a new tab) and Network Intelligence Center (opens in a new tab). Together these controls decide what can leave a perimeter, what can reach a VM, and where pipeline slowdowns or unexpected costs originate.

3.1Define Service Perimeters with VPC Service Controls

Define service perimeters with VPC Service Controls configures a service perimeter around Virtual Private Cloud (VPC) resources and Google-managed services to control movement of data across the perimeter boundary. Inside the perimeter sit grouped projects and an on-premises network; outside the perimeter sit the public internet, other perimeters, and unauthorized Google-managed service copies. Traffic that tries to read or copy sensitive data through a Google-managed service from inside to outside is denied at the boundary, which prevents data exfiltration even when a pipeline identity has broad access inside.

A VPC Service Controls perimeter groups projects and an on-premises network into a single perimeter that blocks data access through Google-managed services such as storage and analytics services used by pipelines. Service perimeters cannot contain projects from different organizations, so cross-organization access must use perimeter bridges that explicitly allow projects and services in different perimeters to communicate. For data pipelines, choose a perimeter when stages in different projects or on-premises must share sensitive datasets without exposing those datasets to other projects or to the internet.

3.2Limit External Access for Pipeline Resources

Limiting external access for pipeline resources means giving pipeline resources only private, internal connectivity unless internet access is explicitly required. When a resource is created in a VPC network, the resource receives an internal IP address from its subnet range, and resources in the VPC network can communicate among themselves through internal IP addresses if firewall rules permit. Resources with only an internal IP address can still reach many Google APIs and services through Private Service Connect or Private Google Access, so pipeline workers remain isolated from the public internet while reading and writing managed services.

Access to the internet is limited to only those resources that need it, with organizational policies further restricting which resources may receive external IP addresses. To allow VMs to access the internet for downloads, use Secure Web Proxy when traffic can be downloaded over HTTP(S) and identity controls are wanted, and otherwise use Cloud NAT. This decision keeps ingestion and transformation VMs private by default and forces egress through a controlled gateway that can be logged and restricted.

3.3Enforce Traffic Control with Cloud Next Generation Firewall

Enforce traffic control with Cloud Next Generation Firewall applies a fully distributed, stateful firewall to each VM rather than passing through a single central device. Because enforcement happens at each VM and scales horizontally, pipeline traffic does not depend on one chokepoint for allow and deny decisions. Traffic can still be steered to third-party virtual appliances by specifying routes, where routes with the same priority distribute traffic using a 5-tuple hash and routes with different priorities create a redundant path.

High-scale pipeline designs must weigh appliance limits against endpoint controls. Most VM-based appliances must bridge multiple VPC networks in the same project with multiple network interfaces, so VPC resource quotas set at the project level can become limiting across all bridged networks. Introducing a single VM-based chokepoint also works against horizontal scalability, which can be mitigated by placing multiple network virtual appliances (NVAs) into a managed instance group behind an internal passthrough Network Load Balancer, or by pushing controls to endpoints through hardened VMs, Google Cloud firewall rules, and host-based inspection agents.

Design firewall rules for pipelines around least privilege and operational clarity:

• Implement least-privilege microsegmentation by blocking all traffic by default and allowing only the specific protocols and ports each workload needs.
• Enable firewall rules logging for visibility into firewall behavior and use Firewall Insights to audit, verify, and optimize rule effects.
• Define a numbering methodology for rule priorities that reserves low numbers for incident response and places more specific rules higher than general rules so specific allows are not shadowed, for example 0-999 for incident response, 1000-1999 for always-blocked traffic, workload-specific rules next, followed by catch-all rules.

Use network firewall policies instead of VPC firewall rules when workloads run on Compute Engine VMs, because policies support granular control with Tags, simpler management, and richer features. Prefer Tags over network tags for firewall selection because of Identity and Access Management (IAM) controls and improved scaling, but create rules based on CIDR ranges for hierarchical firewall policies or Network Connectivity Center peered networks where Tags are not supported.

3.4Tune VPC Flow Logs for Security and Cost Visibility

Tune of VPC Flow Logs for security and cost visibility adjusts subnet-level telemetry that records a sample of network flows that VM instances send and receive for monitoring, forensics, security analysis, and expense optimization. VPC Flow Logs are enabled or disabled at the subnet level, and when enabled for a subnet the logs collect data from all VM instances in that subnet. Flow logs are aggregated by connection at 5-second intervals from Compute Engine VMs and then exported in real time, and logs can be viewed in Cloud Logging and exported to any destination that Cloud Logging export supports.

The default detail and volume are tuned by changing aggregation, sampling, and metadata to match the pipeline question being answered. Longer aggregation reduces record count for stable streams, sampling reduces volume while preserving traffic shape, and removing metadata reduces Logging consumption when only addresses and ports matter.

Tailor logging for its intended audience and review it for action, because logs do not improve security or cost unless someone analyzes anomalies and traffic changes. The logs ingestion page in Logging tracks project log volume and can disable ingestion or exclude unneeded entries to stay within the monthly allotment.

3.5Diagnose Latency, Throughput, and Misconfiguration with Network Intelligence Center

Diagnose latency, throughput, and misconfiguration with Network Intelligence Center uses the single console for Google Cloud network visibility, monitoring, and troubleshooting across configuration, performance, and security. The Performance Dashboard checks the performance of the physical networking underlying VPC virtual networks, which helps separate pipeline application delay from underlying network latency and throughput limits. Connectivity Tests diagnose whether traffic between pipeline endpoints behaves as expected, while Firewall Insights shows how firewall rules interact and whether they block or allow intended flows.

Use the Network Intelligence Center components together to move from symptom to cause:

• Network Topology visualizes the network topology to trace pipeline paths across VPC networks, regions, and hybrid connections.
• Connectivity Tests diagnose connectivity issues with VPC networks by testing expected packet behavior before changing routes or rules.
• Performance Dashboard monitors underlying physical network performance that affects pipeline throughput and latency.
• Firewall Insights provides understandings about firewall rules and how they interact, including shadowed or overly broad rules.
• Network Analyzer monitors VPC network configurations to detect misconfigurations and suboptimal configurations that increase risk or cost.
• Flow Analyzer works with VPC Flow Logs to gain insights into traffic patterns such as top talkers and cross-region flows.

For compliance-sensitive pipelines, enable Firewall Rules Logging selectively because logging incurs costs, enable Connectivity Tests to confirm intended behavior, and use VPC Flow Logs with Flow Analyzer to document traffic patterns. To gain deeper threat insight without blocking production traffic, use Cloud Intrusion Detection System (Cloud IDS) or the Cloud NGFW Enterprise intrusion prevention service in alert mode, which mirrors or inspects traffic and reports malicious activity for response. Cross-Cloud Network (opens in a new tab) designs with NVAs and regional failover depend on this same combination of tests, logs, and analyzers to prove that cross-environment data paths stay correct.

Key Facts

• Cloud Load Balancing distributes inbound traffic from a frontend to healthy backends selected by routing rules and health checks, and depends on backend services, health checks, and firewall rules.
• Private Service Connect enables private, unidirectional access to services and Google APIs using internal IP addresses without traversing the internet, with a producer service attachment and a consumer endpoint in separate Virtual Private Cloud networks.
• Cloud NAT is a managed regional service that lets private Pods and virtual machines initiate outbound internet connections without receiving inbound connections from the internet.
• A VPC Service Controls perimeter cannot contain projects from different organizations, so cross-perimeter access requires a perimeter bridge.
• VPC Flow Logs are enabled at the subnet level, aggregate flows by connection at 5-second intervals from Compute Engine virtual machines, and are exported in real time through Cloud Logging.