This chapter covers multi-tenancy patterns on Google Cloud Platform (GCP), a critical topic for the ACE exam as it tests your ability to design secure, isolated environments for multiple customers or teams within a single GCP organization. Multi-tenancy questions appear in roughly 10-15% of exam questions, often intertwined with IAM, networking, and resource hierarchy. You will learn how to leverage projects, folders, shared VPCs, and IAM policies to achieve tenant isolation, resource sharing, and cost tracking, all while adhering to the principle of least privilege.
Jump to a section
Multi-tenancy on GCP is like an apartment building owned by a property management company. The building itself (the physical infrastructure) is shared among all tenants (customers), but each tenant has a separate, locked unit (project or VPC) with its own lease agreement (IAM policies). The property manager (Google) maintains common areas like the lobby, elevators, and plumbing (networking, storage, compute resources), but tenants cannot access each other's units without explicit permission. Each tenant has their own mailbox (service account) to receive mail (API calls) and can install their own locks (firewall rules) on their doors. The building's address (IP range) is shared, but internal extensions (private IPs) are unique per unit. If a tenant wants to allow a guest (cross-project access) into their unit, they issue a temporary key (shared VPC or VPC peering) with specific access times and areas. The property manager ensures that one tenant's loud music (noisy neighbor) doesn't disrupt others by enforcing quiet hours (resource quotas and rate limiting) and can evict tenants who violate rules (suspension for policy violations). This model allows Google to maximize resource utilization while maintaining strict isolation and compliance for each tenant.
What is Multi-Tenancy and Why Does It Exist?
Multi-tenancy in cloud computing refers to a single instance of software or infrastructure serving multiple distinct customer organizations (tenants). On GCP, this is achieved through a combination of resource hierarchy (organizations, folders, projects), IAM policies, and networking constructs like Shared VPC and VPC peering. The primary goals are: - Isolation: Ensure tenants cannot access each other's data or resources unless explicitly allowed. - Resource Efficiency: Share underlying infrastructure (e.g., physical servers, networks) to reduce costs. - Manageability: Centralize administration while delegating control to tenants. - Compliance: Meet regulatory requirements for data segregation (e.g., HIPAA, GDPR).
The ACE exam focuses on how to implement these patterns using GCP's native services, not third-party tools.
How Multi-Tenancy Works Internally on GCP
GCP's multi-tenancy is built on a hierarchical resource model. At the top is the Organization node, which represents your company. Below that are Folders (for departments or teams), then Projects (the primary isolation boundary), and finally Resources (VMs, buckets, etc.). Each level has associated IAM policies that grant roles to principals (users, groups, service accounts).
Project as the Isolation Boundary: Each project is a separate namespace with its own:
APIs and services (enabled per project)
Billing account (projects can be linked to different billing accounts)
VPC networks (default or custom)
Firewall rules
IAM policies (project-level roles apply to all resources in the project)
Service accounts (created per project)
By default, resources in different projects cannot communicate unless you explicitly enable networking via Shared VPC or VPC peering. This provides strong isolation.
Shared VPC (XPN): Allows an organization to create a common VPC network in a host project and share its subnets with service projects. This enables:
Centralized control of firewall rules and routes.
Efficient IP address utilization.
Simplified network management.
Service projects can have their own IAM policies but use the host project's network.
VPC Peering: Connects two VPCs (even in different projects) so they can communicate using internal IPs. This is useful for multi-tenant SaaS where the provider's VPC needs to talk to tenant VPCs.
Key Components, Values, and Defaults
Organization Node: Created automatically when you sign up with a G Suite or Cloud Identity domain. Cannot be deleted.
Folders: Can be nested up to 10 levels deep. Provide a way to group projects and apply policies hierarchically.
Projects: Identified by a unique Project ID (globally unique, 6-30 characters), Project Name (not unique), and Project Number (auto-assigned, globally unique). Default quotas apply per project (e.g., 5 VPC networks per project, 100 firewall rules per network).
Service Accounts: Can be created per project. Default service account (project number-compute@developer.gserviceaccount.com) is created automatically. Service accounts can be granted roles across projects (impersonation).
IAM Roles: Three types: Primitive (owner, editor, viewer), Predefined (e.g., roles/compute.networkAdmin), and Custom. Policies are inherited from parent to child unless overridden.
Shared VPC: Requires an organization. The host project must be configured to share subnets. Service projects can use up to 100 subnets from a host project (default quota).
VPC Peering: Supports up to 25 peerings per VPC. Peering is transitive? No, VPC peering is not transitive. Traffic must go through the peering connection directly.
Configuration and Verification Commands
Creating a Shared VPC:
1. Enable the compute.googleapis.com API in the host project.
2. Define a shared VPC network with subnets.
3. Use gcloud compute shared-vpc enable command:
gcloud compute shared-vpc enable HOST_PROJECT_ID4. Attach service projects:
gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID --host-project HOST_PROJECT_IDGrant IAM roles to service project admins (e.g., roles/compute.networkUser on subnets).
Verification: - List shared VPC host projects:
gcloud compute shared-vpc list-host-projects- List associated projects:
gcloud compute shared-vpc get-host-project SERVICE_PROJECT_IDVPC Peering: 1. Create a VPC in each project. 2. Create a peering connection from one VPC to the other:
gcloud compute networks peerings create PEERING_NAME --network=VPC_NAME --peer-project=PEER_PROJECT_ID --peer-network=PEER_VPC_NAME3. Repeat on the peer side (peering must be established from both ends). 4. Verify with:
gcloud compute networks peerings list --network=VPC_NAMEInteraction with Related Technologies
Cloud IAM: Multi-tenancy relies heavily on IAM for access control. Use roles like roles/resourcemanager.projectIamAdmin to delegate project management. For Shared VPC, the roles/compute.networkUser role on subnets allows service project resources to use those subnets.
Cloud Billing: Each project can have its own billing account, enabling cost segregation. Use labels and billing export to track costs per tenant.
Cloud Audit Logs: Enable data access logs to monitor cross-project access. Audit logs are per project but can be aggregated at the organization level.
VPC Service Controls: Provide additional security perimeters to prevent data exfiltration across projects.
Cloud KMS: Use Customer-Managed Encryption Keys (CMEK) per project to ensure tenant data is encrypted with tenant-specific keys.
Define the Resource Hierarchy
Start by setting up your organization node. If you don't have a G Suite or Cloud Identity domain, you can use a free Cloud Identity tenant. Next, create folders to represent your business units (e.g., folders for 'Engineering', 'Sales', 'Finance'). Within each folder, create projects for each tenant. For example, a SaaS company might have a folder per customer, with projects for production, staging, and development. Ensure that the hierarchy is no more than 10 levels deep. Apply organization-level IAM policies for admins, and folder-level policies for departmental admins. This structure allows you to enforce policies (e.g., allowed locations, resource quotas) at the folder level, which automatically applies to all child projects.
Configure IAM Policies for Isolation
At the project level, grant minimal roles to tenant users. For each tenant project, create a custom role or use predefined roles like `roles/viewer` or `roles/editor` as needed. Avoid using primitive roles (owner, editor, viewer) because they are too broad. Use service accounts for workloads, and grant them only the necessary permissions. For cross-project access, use IAM conditions to restrict access based on attributes like IP address or time. For example, a support team member might have `roles/compute.instanceAdmin` on a tenant project but only during business hours. Use `gcloud projects add-iam-policy-binding` to assign roles. Regularly audit permissions using the IAM Recommender.
Set Up Networking with Shared VPC
If tenants need to communicate with each other or with a central service, use Shared VPC. Choose a host project (often a 'common' project) and create a VPC with custom subnets. Do not use auto-mode subnets because they create unpredictable IP ranges. Enable Shared VPC on the host project using `gcloud compute shared-vpc enable`. Then attach each tenant's service project to the host project. Grant the `roles/compute.networkUser` role on specific subnets to the service project's service accounts. This allows tenant resources (e.g., Compute Engine VMs) to use those subnets. Ensure that firewall rules are centrally managed in the host project. For complete isolation, use separate subnets per tenant and firewall rules that deny traffic between subnets.
Implement Cost Tracking and Quotas
Assign labels to resources (e.g., `tenant=acme-corp`, `environment=production`) to track costs per tenant. Enable billing export to BigQuery to analyze spending. Set per-project quotas to prevent a tenant from consuming all resources. Use the `gcloud compute project-info set-usage-bucket` to export usage data. For shared resources (e.g., a load balancer in the host project), allocate costs based on usage metrics. Use Cloud Monitoring to set alerts on quota usage. Remember that per-project defaults (e.g., 5 VPC networks, 100 firewall rules) can be increased via quota requests, but they apply to all projects in the organization.
Monitor and Audit Access
Enable Cloud Audit Logs for all projects, especially for data access and admin activity. Use the Logs Explorer to search for cross-project access attempts. Set up sink to export logs to a central BigQuery dataset for long-term retention. Use Cloud Asset Inventory to track resource changes across projects. For compliance, use VPC Service Controls to prevent data exfiltration from tenant projects. Regularly review IAM policies with the Policy Analyzer to identify overly permissive roles. For example, a service account in a tenant project should not have `roles/iam.serviceAccountUser` on the host project unless necessary.
Scenario 1: SaaS Provider with Isolated Customer Environments
A SaaS company hosts its application on GCP and needs to provide each customer with an isolated environment. They create a folder per customer (e.g., Customers/AcmeCorp), and within that folder, projects for production, staging, and development. Each customer's production project uses a Shared VPC in a central host project for networking, with a dedicated subnet and firewall rules that only allow traffic from the customer's IP range. The host project also hosts shared services like a central database and monitoring. IAM roles are granted at the project level, with customers having roles/compute.instanceAdmin but not roles/iam.serviceAccountAdmin to prevent privilege escalation. Costs are tracked using labels and exported to BigQuery, where the finance team runs queries per customer. A common mistake is forgetting to set VPC Service Controls, leading to potential data exfiltration if a customer's VM is compromised. Performance is generally fine, but if one customer runs a data-intensive job, it can saturate the shared subnet. To mitigate, they set per-project quotas and use network tags to prioritize traffic.
Scenario 2: Enterprise with Departmental Isolation
A large enterprise uses GCP for multiple departments (HR, Finance, Engineering). Each department gets a folder, and within that, projects for different applications. They use Shared VPC with a host project per department to keep networking separate. For example, HR's host project has a VPC with subnets for HR apps, and Finance's host project has its own VPC. They use VPC peering between the HR and Finance host projects only for necessary integrations (e.g., payroll data). IAM policies are inherited from folders, so department admins can manage their own projects. The challenge is managing overlapping IP ranges—they use custom subnets with non-overlapping CIDRs (e.g., 10.1.0.0/16 for HR, 10.2.0.0/16 for Finance). Misconfiguration often occurs when a service account from one department is granted access to another department's project, so they use IAM conditions to restrict access by department. They also use Cloud Armor to protect shared services.
Scenario 3: Multi-Tenant Data Analytics Platform
A company offers a data analytics platform where each tenant's data is stored in separate BigQuery datasets within a shared project. They use IAM conditions to restrict access to datasets based on the user's domain (e.g., user@acme.com can only query acme_* datasets). They also use VPC Service Controls to prevent data exfiltration from the shared project. Performance is managed by setting per-tenant slot reservations in BigQuery. The biggest risk is accidental data exposure due to misconfigured IAM, so they regularly audit with the Policy Analyzer and use Data Loss Prevention (DLP) to scan for sensitive data.
What the ACE Tests
Objective 1.1: "Planning and configuring network topologies, including multi-tenancy." The exam expects you to:
Understand the difference between Shared VPC and VPC peering.
Know how to set up a resource hierarchy with folders and projects.
Apply IAM policies correctly at each level.
Identify when to use Shared VPC vs. VPC peering vs. separate projects.
Troubleshoot common networking issues like IP overlap or peering transitivity.
Common Wrong Answers and Why
"VPC peering is transitive." This is false. VPC peering is not transitive; if VPC A is peered with VPC B, and VPC B is peered with VPC C, traffic from A to C must go through B explicitly. The exam loves testing this.
"Shared VPC allows service projects to create their own subnets." Wrong. Subnets are created only in the host project; service projects can only use those subnets.
"You can nest folders up to 20 levels." Wrong. The limit is 10 levels.
"Projects can belong to multiple folders." Wrong. A project can belong to only one folder.
"Primitive roles are recommended for multi-tenancy." Wrong. They are too broad; use predefined or custom roles.
Specific Numbers and Terms
Organization node: created automatically with Cloud Identity.
Folder nesting: max 10 levels.
Projects: max 5000 per organization (default).
VPC peering: max 25 per VPC.
Shared VPC: host project can have up to 100 service projects (default).
Subnets per VPC: max 500 (default).
Firewall rules per VPC: 1000 (default).
Edge Cases and Exceptions
Cross-project service account impersonation: A service account in one project can be granted roles in another project. This is often used for automation but can be a security risk if not properly scoped.
Shared VPC with multiple host projects: A service project can only be attached to one host project at a time. To use multiple host VPCs, you need to use VPC peering between host projects.
Default VPC: New projects come with a default VPC (auto-mode). For multi-tenancy, you should delete it and create custom VPCs to avoid IP overlap.
Organization policy constraints: You can set constraints like constraints/compute.restrictVpcPeering to limit peering to specific projects.
How to Eliminate Wrong Answers
If the question mentions sharing subnets across projects, it's Shared VPC.
If the question mentions connecting two VPCs with internal IPs without a VPN, it's VPC peering.
If the question mentions cost tracking per tenant, think labels and billing export.
If the question mentions isolating tenants completely, think separate projects with no networking (or VPC Service Controls).
The project is the primary isolation boundary for multi-tenancy on GCP.
Shared VPC allows centralized subnet sharing and firewall management across service projects.
VPC peering connects two VPCs but is not transitive and requires non-overlapping IP ranges.
Folders can be nested up to 10 levels deep; each project belongs to exactly one folder.
Use IAM conditions to restrict access based on attributes like time or IP address.
Labels and billing export to BigQuery enable cost tracking per tenant.
Default quotas: 5 VPC networks per project, 100 firewall rules per network (can be increased).
Avoid primitive IAM roles in multi-tenant environments; use predefined or custom roles.
VPC Service Controls provide an additional security perimeter to prevent data exfiltration.
Cloud Audit Logs and Policy Analyzer help monitor and audit cross-project access.
These come up on the exam all the time. Here's how to tell them apart.
Shared VPC
Centralized network management in a host project.
Service projects use subnets from the host project; no IP overlap issues.
Firewall rules are managed centrally in the host project.
Requires organization; host project must be in the same organization.
Supports up to 100 service projects per host (default).
VPC Peering
Connects two independent VPCs, possibly in different organizations.
Each VPC maintains its own subnets; IP ranges must not overlap.
Firewall rules are managed separately in each VPC.
No organization required; works across projects and organizations.
Up to 25 peerings per VPC; not transitive.
Mistake
Shared VPC allows service projects to create their own subnets.
Correct
Subnets are created only in the host project. Service projects can only use the subnets shared with them; they cannot create or modify subnets in the host project.
Mistake
VPC peering is transitive.
Correct
VPC peering is not transitive. If VPC A is peered with VPC B, and VPC B with VPC C, traffic from A to C must go through B (or use a separate peering). GCP does not support transitive peering.
Mistake
Projects can belong to multiple folders.
Correct
A project can belong to exactly one folder. It cannot be in multiple folders simultaneously.
Mistake
Primitive roles (owner/editor/viewer) are fine for multi-tenancy.
Correct
Primitive roles are too broad and grant permissions across all resources in a project. They should be avoided in multi-tenant setups; use predefined or custom roles instead.
Mistake
You can use the same VPC peering for both IPv4 and IPv6 traffic.
Correct
VPC peering supports only IPv4 traffic. IPv6 is not supported over peering connections.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, Shared VPC only works within the same organization. All projects (host and service) must belong to the same GCP organization. For cross-organization connectivity, use VPC peering or Cloud VPN.
Shared VPC allows a host project to share its subnets with service projects within the same organization, centralizing network management. VPC peering connects two independent VPCs (even across organizations) to communicate using internal IPs, but each VPC manages its own subnets and firewalls. Peering is not transitive.
By default, a host project can have up to 100 service projects. This quota can be increased by requesting a quota increase from Google Cloud Support.
No, a project cannot be both a host project and a service project simultaneously. It can only serve one role in a Shared VPC setup.
Deleting the host project will delete the Shared VPC network and all its subnets. Service projects will lose network connectivity. Resources in service projects that depend on the shared subnets (e.g., VMs with internal IPs) will become inaccessible. Always migrate resources before deleting.
Use labels on resources (e.g., `tenant:acme`) and export billing data to BigQuery. You can then query by labels to see costs per tenant. For shared resources like load balancers in the host project, allocate costs based on usage metrics or fixed percentages.
Yes, but it is not recommended. Auto-mode subnets create unpredictable IP ranges (one per region), which can cause IP overlap with other VPCs if you later need to peer. Use custom subnets for better control.
You've just covered Multi-Tenancy Patterns on GCP — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?