Appendix A

Recommended GCP Project Layout

Scope. Seven estate layouts at seven scales, from a two-environment startup to a multi-business-unit enterprise, plus hybrid and multi-cloud placement. Each gives a tree, how it differs from the reference estate, and the trigger to move up. Prerequisites. Chapter 2 for hierarchy mechanics, Chapter 5 for addressing, Chapter 6 for hybrid connectivity. Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; every layout reconciled against Chapter 2 and the fixed CIDR plan; see sources at end.

Chapter 2 gives one SaaS estate (§2.32) and one enterprise estate (§2.33), both at a single mid-size scale. This appendix gives seven, and its subject is scale: what you can safely leave out when the estate is small, what you add as it grows, and — the part no chapter carries — the trigger that says it is time to move up. The trees here are the deliverable; the mechanics behind them belong to Chapter 2 and are cited, never repeated.

The thresholds below are engineering judgment, not documented limits. The only hard numbers are §2.8's folder ceilings (ten levels deep, 300 direct children) and §2.11's 30-character project ID.

From → To	Trigger
A.1 → A.2	A second region; or artifacts and CI leave the security project; or a tenant contracts for isolation (§2.35)
A.3 → A.4	A second region; or retention becomes a legal obligation (§2.22); or a circuit is ordered (→ A.6)
A.4 → A.5	A second group can create projects without central approval — real delegation (§2.34)
any → A.6	On-premises reachability becomes a requirement, not a migration artifact
any → A.7	Only after federation (§4.10) and Private Service Connect (§5.19) are ruled out in writing (§6.16)

A.1 Small SaaS §

The reduced form of §2.32: one region, two environments, seven projects.

organizations/123456789012           rickcollette.domain
├── fldr-bootstrap
│   └── rc-saas-bootstrap-seed-01    Terraform state, factory identity
├── fldr-common
│   ├── rc-saas-shared-net-01        one Shared VPC host, both environments
│   ├── rc-saas-shared-log-01        aggregated sink destination
│   └── rc-saas-shared-sec-01        KMS, Secret Manager, SCC, Artifact Registry
└── fldr-environments
    ├── fldr-development → rc-saas-dev-app-01
    └── fldr-production  → rc-saas-prod-app-01, rc-saas-prod-data-01

What it drops from §2.32. The staging tier and fldr-nonproduction; fldr-sandbox; the separate artifact and CI/CD projects, folded into rc-saas-shared-sec-01; and the development data project. Only us-central1 is built — europe-west1 is reserved in the address plan (§5.6), not deployed.

What it never drops, which is the point. The bootstrap project, the logging project, and the organization policy baseline (§2.30). All three are nearly free at this size and retrofit badly. An estate that skips the seed project puts Terraform state in a workload project, and there is no clean way to separate them afterward (§2.21).

Pitfall. Folding Artifact Registry and CI into the security project is the compromise that expires first. Sharing a project with KMS means sharing its IAM surface, so the first engineer who needs to publish an image gets a grant in the project that holds your keys.

A.2 Large SaaS §

The baseline is §2.32. This is the delta, not a second tree.

Additions to the §2.32 SaaS estate:

fldr-common
  + rc-saas-shared-net-02      2nd Shared VPC host: dev/stg, split from prod
fldr-environments/fldr-development
  + rc-saas-dev-app-9x         ephemeral preview projects, CI-created, TTL 72h
fldr-environments/fldr-production
  + rc-saas-prod-app-02        europe-west1 (10.129.0.0/20, §5.6)
  + rc-saas-prod-data-02       regional data residency
fldr-tenants                   new folder, sibling of fldr-environments
  + rc-saas-prod-app-t0001-01  per-tenant project and CMEK (§2.35)

A second Shared VPC host, because production network administration should not be the same IAM surface as development's (§5.28): one roles/compute.networkUser misgrant should not span both.

fldr-tenants is a sibling of fldr-environments, not a child of production. §2.35 names the project-per-tenant pattern without placing it. Tenant projects carry their own policy and their own delegated support role, and a tenant is not an environment (§2.8).

Preview environments are ephemeral projects, not a fourth environment folder. The -9x ordinal band is reserved for CI-created projects with a TTL, so both the factory (§2.26) and the deletion policy (§2.29) can key on the name.

Judgment. A.2 is terminal for a SaaS product. Growing tenant count is a project-factory and rate-limit problem (§2.26), not a hierarchy problem — the instinct to add folders should be resisted. rc-saas-prod-app-t0001-01 is 25 characters, so four digits of tenant ordinal is the practical ceiling under §2.11.

A.3 Small Enterprise §

The enterprise estate without the business-unit layer.

organizations/210987654321           ent.rickcollette.domain
├── fldr-bootstrap
│   └── rc-ent-bootstrap-seed-01
├── fldr-common
│   ├── rc-ent-shared-net-01         hub VPC, Cloud Router, DNS
│   ├── rc-ent-shared-log-01
│   ├── rc-ent-shared-sec-01
│   └── rc-ent-shared-cicd-01
├── fldr-environments
│   ├── fldr-development   → rc-ent-dev-app-01
│   ├── fldr-nonproduction → rc-ent-stg-app-01
│   └── fldr-production    → rc-ent-prod-app-01, rc-ent-prod-data-01
└── fldr-regulated
    └── fldr-pci           → rc-ent-pci-prod-app-01

It removes the entire BU layer. §2.33 nests fldr-business-units → fldr-bu-<name> → environment folders; A.3 promotes the environment folders straight to the organization and drops two levels. Do not buy the delegation layer before there is anyone to delegate to. A BU folder no separate group administers is pure cost: a second copy of every environment policy, applied and audited per BU, for none of the benefit §2.34 describes.

fldr-regulated survives the reduction, because retrofitting a compliance subtree means moving projects across a policy boundary. It is a sibling of fldr-environments and inherits the organization baseline and nothing else. Region is us-east4.

Pitfall. pci is not in the standard env vocabulary; §2.33 already writes rc-ent-pci-prod-app-01, and the regulated subtree is the documented exception to the four-segment rule rather than a naming error to correct.

A.4 Large Enterprise §

The delta from A.3. §2.33 remains the canonical mid-size reference.

Additions to the A.3 tree:

fldr-bootstrap
  + rc-ent-bootstrap-cicd-01   foundation pipeline, split from the seed project
fldr-common
  + rc-ent-shared-net-02       Interconnect and VLAN attachments only (A.6)
  + rc-ent-shared-log-02       long-retention archive, IAM separate from log-01
  + rc-ent-shared-art-01       Artifact Registry, split out of shared-sec-01
fldr-environments/fldr-production
  + rc-ent-prod-app-02         second region
  + rc-ent-prod-net-01         production service-project network resources
fldr-regulated/fldr-pci
  + rc-ent-pci-prod-sec-01     regime-scoped KMS, admins disjoint from shared-sec

Every addition is one project splitting into two along an IAM seam, and that is the pattern worth naming: at this scale projects divide because two groups need different access to what is inside them, not because they run out of resources. Seed splits from pipeline, Interconnect from the hub VPC, archive from operational logging, regulated keys from shared keys.

Judgment — the appendix's most useful threshold. Move to a business-unit hierarchy when a second group can create projects without the central platform team's approval. That is delegated administration and it is what a BU folder is for (§2.34). "We have departments", "we have separate budgets", and "we have separate products" are not triggers; those are labels (§2.12) and cost centers, and §2.8 says folders should not represent them.

A.5 Multi-Business-Unit Enterprise §

§2.33 prints the multi-BU tree and §2.34 owns the delegation split. What follows is the part neither supplies: the per-BU address allocation, a naming collision, and the ceiling.

Per-BU allocation inside the §2.33 tree:

fldr-bu-manufacturing  mfg   10.132.0.0/16   rc-ent-mfg-prod-app-01
fldr-bu-logistics      lgs   10.133.0.0/16   rc-ent-lgs-prod-app-01
fldr-bu-retail         ret   10.134.0.0/16   rc-ent-ret-prod-app-01
                             10.135.0.0/16   reserved for the next BU (§5.6)

One /16 per business unit, with a gap left for the next. §6.14 says the enterprise landing zone is parameterized by BU, each getting its own allocation out of the environment supernet, but allocates nothing. The /16 granularity is §5.6's second rule applied to a BU rather than a region, so that on-premises route summarization stays one entry per business unit. Note that this is the enterprise estate's own supernet: §5.6's 10.128.0.0/12 reference plan belongs to the SaaS estate, and the two estates are separate organizations that never share address space. What binds here instead is §5.6's fourth rule — the enterprise on-premises range is 172.16.0.0/12, so the cloud side stays inside 10.0.0.0/8 and no BU allocation may stray into it.

Pitfall. The natural abbreviation for a logistics BU is log, which collides with the log function token in <prefix>-<env>-<function>-<nn>. rc-ent-log-prod-app-01 cannot be parsed by position, which breaks the IAM conditions and log filters that key on the name (§2.10, §2.11). Use lgs.

The ceiling is width, not depth. §2.33 does the depth check; the constraint that actually binds is §2.8's 300 direct children, which BU growth consumes under fldr-business-units. Audit burden binds long before 300. There is no layout beyond this one — more business units means more siblings, and giving each its own organization is the anti-pattern §2.34 already names.

A.6 Hybrid Cloud §

Chapter 6 owns hybrid connectivity end to end: HA VPN (§6.3), Dedicated and Partner Interconnect (§6.5, §6.6), Cloud Router design (§6.9), hub-and-spoke (§6.13), the landing zone (§6.14), and hybrid DNS (§6.17). No chapter owns the project layout, which is all this section supplies.

organizations/210987654321           ent.rickcollette.domain
└── fldr-common
    ├── rc-ent-shared-net-01     hub Shared VPC host: VPC, subnets, Cloud Router,
    │                            Cloud DNS zones and forwarding policies
    ├── rc-ent-shared-net-02     Interconnect only: connections and VLAN
    │                            attachments. No workloads, no subnets.
    └── rc-ent-shared-log-01     flow logs, DNS query logs

    on-premises 172.16.0.0/12 ── Interconnect ──▶ rc-ent-shared-net-02
                                                        │ VLAN attachment
                                                        ▼
                                                  rc-ent-shared-net-01 (hub)
                          fldr-environments service projects attach as spokes

Interconnect lives in its own project, separate from the Shared VPC host. Google's security foundations blueprint does the same, with a dedicated project for "Cloud Interconnect connections that provide connectivity between your on-premises environment and Google Cloud". The argument for the split is the book's own: a physical circuit outlives the VPC that consumes it, and the group that orders circuits is not the group that administers subnets (§2.9, §5.28).

Judgment. Scope gcp-network-admins@ent.rickcollette.domain to rc-ent-shared-net-02 and nothing else. The on-premises side stays in 172.16.0.0/12 and the cloud side in 10.0.0.0/8, so a route leak is legible at a glance (§5.7).

A.7 Multi-Cloud §

§6.16 fixes the ordering — federate first, Private Service Connect second, network last. This is that ordering expressed as project layout, and the point of the tree is that the first two options add no network projects at all.

organizations/123456789012           rickcollette.domain
├── fldr-common
│   ├── rc-saas-shared-sec-01    WIF pools and providers, one per external
│   │                            cloud. No network path. The default answer.
│   ├── rc-saas-shared-net-01    PSC service attachments, one endpoint per
│   │                            published service. Address space unshared.
│   └── rc-saas-shared-net-02    only if reachability is justified in writing:
│                                HA VPN or Cross-Cloud Interconnect
└── fldr-environments            unchanged — no per-cloud environment folders

Most multi-cloud requirements are identity requirements. A workload in another cloud that needs a Google API calls it over the internet with a federated credential (§4.10), which adds a pool and a provider in the security project and no network at all.

Cross-Cloud Interconnect provides dedicated connectivity between Google Cloud and another provider, currently AWS, Microsoft Azure, Oracle Cloud Infrastructure, and Alibaba Cloud. Google's landing-zone guidance notes that the on-premises design options apply unchanged to other providers through it, so A.6's layout is reused rather than redesigned.

Pitfall. A folder per cloud provider is the intuitive layout and it is wrong. The boundaries that matter are environment and blast radius, not vendor, and §2.8 lists vendor among the things folders should not represent. The corollary from §6.16 is why the pool project is a security project under organization-level administration: one cloud's administrative identity must never be federated into the other's privileged roles.

Sources §

https://cloud.google.com/architecture/landing-zones/decide-resource-hierarchy (last validated 2026-09-04)
https://cloud.google.com/architecture/landing-zones/decide-network-design (last validated 2026-09-04)
https://cloud.google.com/architecture/blueprints/security-foundations/organization-structure (last validated 2026-09-04)
https://cloud.google.com/network-connectivity/docs/interconnect/concepts/cci-overview (last validated 2026-09-04)