Why Google Cloud doesn’t need a Transit Gateway? …multi-cloud Flexibility | by Antonella Blasetti | Google Cloud – Community | Sep, 2025

Stepping into Flexibility Advantage — GCP Global Networking and Projects

The networking model is only half the story; the other half is the organizational structure. GCP’s combination of a global network and a flexible project structure creates a paradigm that lets you create without borders.

The AWS & Azure Constraint: Regional Scopes and Hard Boundaries

In AWS and Azure, Accounts and Subscriptions are the primary units of management, creating “hard” boundaries for billing, identity, and resources. A resource like a VM is fundamentally tied to both a region and an Account/Subscription. Moving resources between these boundaries is a full migration project, not a simple administrative action. Services like Transit Gateway and Virtual WAN were explicitly created to “stitch together” these otherwise rigidly separated environments, which adds operational overhead.

The GCP Advantage: Global Scope and Project Flexibility

GCP Projects are more lightweight containers for resources, APIs, and billing.

….anyone who experiments with GCP will be amazed at how quickly they accumulate dozens of projects!

Critically, projects can be easily moved between Folders within a central Organization, much like moving a file on a computer; it’s a metadata change, not a resource migration.

The real magic happens when you combine this project flexibility with a Global Shared VPC, where a single, global network can serve resources across dozens of projects, managed by different teams, in any region worldwide.

Use Cases Unlocked by GCP’s Flexibility:

1. The Multi-Tenant SaaS Platform

A SaaS company needing to provide logically isolated environments for each new customer faces a challenge.
The AWS/Azure approach often requires a new Account or Subscription per customer, creating a complex web of Transit Gateways or Virtual WAN connections and a massive operational burden at scale.

The GCP approach is to create a new GCP Project for each customer and attach them as “Service Projects” to a single, central Shared VPC. This central VPC hosts shared services, and each customer is isolated by project boundaries and firewall rules on the same flat, global network. Onboarding is as simple as creating and attaching a project, a process that can be fully automated.

2. Corporate Reorganization or Mergers & Acquisitions

When a company acquires a new business unit, integrating their cloud infrastructure is a major challenge. In AWS/Azure, this can be a long undertaking involving resource migrations between Accounts/Subscriptions, causing downtime and network re-architecture.

In GCP, you can simply move the acquired company’s Projects from their old Organization into a Folder within your Organization. To access central services, you just attach their projects to your existing Shared VPC. This IAM/metadata change takes minutes, not months, dramatically accelerating business integration.

3. Global Application with Regional Data Sovereignty

Consider a single application serving a global audience where European customer data must reside on European soil (GDPR). The AWS/Azure approach requires separate regional VPCs/VNets connected with Transit Gateway or Virtual WAN, meaning you manage multiple distinct networks.

The GCP approach is to deploy the entire application within a single Shared VPC. European components are placed in European subnets, and US components are in US subnets. They communicate seamlessly over Google’s private backbone as if on a local network. Data sovereignty is enforced simply by placing storage in the correct regional location, all while benefiting from a single, unified global network.

Internal vs. External Connectivity: Shared VPC and VPC Peering

It’s crucial to handle tenancy both within and outside your company’s boundaries. For internal multi-tenancy within your organization, you use Shared VPC. It allows different teams in separate Projects to operate under a single, centrally controlled network. For external connectivity with partners or customers in a different GCP Organization, you use VPC Network Peering. It creates a direct, non-transitive, private connection between your VPC and theirs.

Can you peer with a Shared VPC?

Yes, this is a common and powerful pattern. The peering connection is configured on the VPC network itself, which is owned by the Host Project. A network administrator for the Host Project sets up the peering. Once established, resources in the peered VPC can communicate with any resource in any subnet of the Shared VPC, regardless of the Service Project or region, subject to firewall rules. This allows a partner in an external organization to securely access shared services hosted in your global network.

A Final, Critical Point: Flexibility Without Sacrificing Security

It’s a fair question to ask: does all this global flexibility introduce security risks? The answer is a resounding no. In fact, it enables a more modern, robust security posture because GCP’s security model is not primarily dependent on rigid network boundaries. Instead, security is enforced through multiple, overlapping layers centered on identity and data.

This includes granular firewalling through VPC Firewall Rules that create highly specific micro-segmentation. The primary security boundary is Identity and Access Management (IAM), where permissions dictate access regardless of network location. For the highest level of security, VPC Service Controls creates a virtual data perimeter around your GCP services, effectively preventing data exfiltration even if credentials are stolen. This approach shifts the paradigm from a traditional, castle-and-moat network model to a modern zero-trust architecture. Security is not assumed based on network location;
it is continuously verified based on identity, context, and data policies, making the GCP model not only more flexible but strongly secure for the dynamic applications built in the cloud today.

The power of VPC Firewall Rules is a key and amazing part of that topic, and their implementation can be quite different among platforms… but this is another story…next time…maybe….