Field-tested lessons from building real cloud foundations
There’s something different about building something that other people will inherit.
Designing a Google Cloud landing zone is one of those things. It’s not just Terraform scripts and IAM policies — it’s an architectural decision that will either make people move fast with confidence… or force them to tiptoe around fragile setups for years.
I've had the chance to design and implement landing zones for a range of organizations — from fast-scaling startups to large teams with strict compliance needs. No matter the size or sector, the problems rhyme. So do the mistakes.
This post is a reflection. No buzzwords, no copy-paste from Google docs. Just things I’ve learned — the hard way — that I’d want someone else to know if they’re about to build a cloud foundation on GCP.
“This content reflects my personal experience and views. It does not represent any client or employer, and is based solely on public tools and personal knowledge.”
What Is a Landing Zone, Really?
A Landing Zone ( Cloud Foundation as called by Google ) is your cloud’s first impression. It’s the baseline structure that sets the rules: who can do what, where things live, how secure you are by default, and how fast new projects can start.
When it’s done right, teams can spin up environments safely, monitor them effectively, and control costs. When it’s rushed or improvised, it turns into a pile of IAM bandaids, broken VPCs, and “who owns this again?” conversations.
A solid GCP landing zone usually includes:
- Identity & access management
- A well-structured resource hierarchy (org → folders → projects)
- Networking that’s actually segmented and secure
- Billing and budget tracking
- Org-level security policies
- Centralized logging and observability
Why a Landing Zone Matters ?
A landing zone gives your organization a structured way to build in Google Cloud without starting from scratch every time. It’s about setting up a foundation that’s already aligned with best practices — so every team isn’t reinventing the wheel.
It ensures shared components are in place, security policies are enforced by design, and that all cloud environments are spun up through the same, approved infrastructure-as-code process. No shortcuts, no one-off setups.
Instead of teams guessing how to configure projects, networking, or IAM, a landing zone gives them a starting point that’s already vetted — consistent, secure, and ready to scale.
How to Build a Google Cloud Landing Zone (Without Overthinking It)
There’s a lot of talk out there about how to set up a GCP landing zone “the right way.” In my experience, there isn’t just one way — it really depends on who you are, how your team works, and how far down the automation path you want to go.
I’ve helped teams of different sizes get their foundations in place. Sometimes you need a quick setup to test something. Other times, you’re laying down the foundation for a platform dozens of teams will build on. Those are two very different situations.
Here’s how I break down the main options. These aren’t from the docs — they’re from actual projects I’ve worked on.
1. Start With the Console
This is the simplest way to get going. You log into the Cloud Console, follow Google’s setup checklist, and manually create your org, folders, projects, IAM, and so on. It’s all guided. You click through the steps, hit deploy, and you’re done.
It’s great if you’re just learning or doing a one-off test. But if you're thinking long-term, this approach won't scale. There's no version control. You can’t reproduce what you built. And once teams start depending on it, you’re going to hit a wall.
Good for: learning, quick proof of concept
Not great for: repeatability, scale, or security
2. Export the Terraform
Still using the Console — but instead of hitting deploy, you export the Terraform configuration it generates. That gives you a code version of what you set up. You can store it in Git, tweak it, and apply it through Terraform.
This is a decent option for teams starting to move toward infrastructure as code. It’s not fully modular, but it’s way better than just clicking in the UI with no history.
Good for: teams easing into IaC
Bonus: gives you something you can track and improve
3. Use Cloud Foundation Fabric with FAST
This is what I use when things get serious. Google built Cloud Foundation Fabric as a collection of Terraform modules, and FAST is a pre-wired setup using those modules to build a real landing zone.
You get a clean, modular setup that covers networking, IAM, logging, project factories, org policies — all the stuff you'd want in a production environment. You can run it in CI/CD and scale it across business units.
This is what I’d call “enterprise-grade.” If you're supporting more than one team, or you need governance baked in, start here.
Best for: platform teams, security-focused orgs, production rollouts
4. Try Google’s Terraform Example Foundation (TEF)
This one’s more like a reference than a toolkit. TEF is part of Google’s Cloud Foundation Toolkit. It gives you a complete example of how to structure a landing zone — folders, projects, billing, networking — all wired together with Terraform and Cloud Build.
It’s great for learning and testing. Not as flexible as Fabric, but faster to get going. You can use it to understand the flow, then move to something more modular later.
Best for: prototypes, demos, smaller teams
Use it if: you want to see a working example and learn from it
5. Build Your Own from Scratch
You can write everything yourself — org structure, networking, policies — all handcrafted Terraform. I’ve done this before, but only when there’s a really unique need that isn’t covered by Fabric or TEF.
The risk here is complexity. You’re now maintaining everything. And chances are, Google’s open-source modules already solved the problem you’re trying to figure out.
Best for: highly specific environments
Not recommended unless: you have no choice and the skill to support it
What I Recommend (From Experience)
If you’re building a real cloud foundation for more than just one team — use Fabric with FAST. It’s solid, scalable, and you’re not locked into someone else’s opinionated setup.
If you’re learning or prototyping, TEF is a great way to see how things work without investing too much upfront.
And if you're just exploring, sure — click around in the Console. But move on from that as soon as you can.
Quick recap:
- Use Fabric when you’re building for scale
- Use TEF when you’re learning or proving a concept
- Use the Console only to explore — not for anything permanent
Whatever you choose, think about who’s going to maintain it a year from now. That mindset usually points you in the right direction.
Build with the future in mind.
My Go-To Tool: Cloud Foundation Fabric
For most of these foundations, I use Cloud Foundation Fabric (CFF) — Google’s open-source Terraform modules.
This the repo which i forked from the official Google Cloud Foundation Fabric
techwithmohamed
FAST FABRIC Terraform
Cloud Foundation Fabric (CFF) is a set of open-source Terraform modules built by Google. It gives you everything you need to build "production-ready GCP organization" the right way — IAM, networking, logging, org policies, and more — all as modular, reusable code.
FAST is a ready-made blueprint built on top of Fabric. It connects the modules into a complete, production-grade landing zone setup.
Think of it like this:
- Fabric = toolbox of Terraform building blocks
- FAST = full landing zone starter kit, wired and ready
FAST builds your GCP foundation in clear, logical stages. Each stage handles one part of the setup — like identity, networking, or project creation.
Why? Because in real organizations, different teams own different areas. The networking team handles networks. The IAM team handles access. FAST mirrors that structure.
Each stage is like a self-contained unit: it knows what it needs, does its job, and hands off clean outputs to the next stage. This makes it easier to delegate ownership, automate workflows, and avoid breaking things downstream.
The result? A landing zone that’s cleanly organized, secure, and easy to manage — even as your cloud grows.
Lessons From the Field
1. Identity First — Always
Start with Cloud Identity or Google Workspace, and define group-based access from the beginning.
If you delay this, you end up with IAM sprawl: dozens of one-off permissions tied to individual accounts, and zero visibility into who actually owns what.
Tip:
- Avoid assigning roles to individual users
- Do set up SSO early, and manage everything via groups
2. Your Folder Structure Reflects Your Org
I’ve seen teams try to run everything under one folder. It always ends in confusion — especially when it's time to isolate budgets, apply policies, or track usage by business unit.
The structure should reflect how your company operates:
- Separate dev/staging/prod
- Break things out by team or product line
- Apply org policies at folder level for consistent inheritance
Start simple, but scalable.
3. Networking Decisions Are Sticky
Networking is one of those things that feels abstract — until it's not.
Bad subnet layouts, no DNS planning, inconsistent firewall rules — these slow teams down fast.
Tips I stick to:
- Use Shared VPCs with clear host/service separation
- Set up Private Google Access early
- Plan for hybrid or multi-region even if you think you won’t need it
4. Bake Security into the Default, Not the Deadline
Security shouldn’t be a sprint at the end of a migration. It should be how you start.
What I now include by default:
- Org policies to prevent external IPs
- Default deny firewall rules
- CMEK where sensitive data is involved
- VPC Service Controls for tighter perimeters
5. Logging and Monitoring = Visibility and Control
If you don’t log it, you can’t secure it. If you don’t monitor it, you can’t support it.
For me, this means:
- Log sinks to BigQuery for centralized querying
- Budget alerts and cost monitoring dashboards
- Setting SLOs and uptime checks in Cloud Monitoring
- Consistent retention policies across projects
🛠️ Google Cloud Landing Zone in Action
Alongside my day-to-day consulting work, I’ve started building a detailed, hands-on guide that walks through how to set up a production-ready GCP Landing Zone using Cloud Foundation Fabric via FAST.
To keep it real and relatable, I’ve created a fictional company called “Momo” — and the guide will follow how I’d approach building their cloud foundation as if I were their Cloud Architect.
The idea is to walk step-by-step through the kinds of decisions you'd actually face in a real project:
- How do we structure the org?
- What IAM policies make sense?
- What’s the right network setup for scale and security?
The process breaks down into three practical phases:
Phase 1: Design and Architecture — Understanding "Momo's" Needs
Before we touch any Terraform, we start with design. Based on the fictional company Momo’s use case, we'll go through the key architectural decisions you’d make in a real cloud foundation project.
This phase is about asking the right questions and making the right calls in areas like:
- Cloud Identity: How will users and groups be managed? What’s the SSO strategy?
- Resource Management: How should the org, folders, and projects be structured for scale?
- Access Management: Who needs access to what, and how do we enforce least privilege?
- Networking: Shared VPCs? Private access? What does secure and scalable connectivity look like?
- Logging & Monitoring: What’s the baseline for observability and auditability from day one?
- Billing: How do we track costs, set budgets, and separate environments or teams?
- Security: What guardrails and org policies should be enforced globally?
- Infrastructure as Code: How will we automate and version-control the entire setup?
These aren't just technical choices — they're business-aligned design decisions, and they shape how GCP will operate for every team that comes after.
Check this post for ROUND 1 of creating Landing Zone on GCP !
Tech With Mohamed
Phase 2: Setting Up the Org
Here’s roughly how I approach this step :
- First, I create a Cloud Identity tenant. That becomes our directory — users, groups, the whole deal.
- Then, I spin up a Super Admin account. This is the god-mode user. I don’t use it day-to-day — just keep it safe and locked down.
- Next, I verify the company domain and hook it into GCP. That’s what gives us the organization node, the top-level object that all folders and projects live under.
- After that, I define some basic groups:
gcp-admins,networking,billing,developers. Just the usual suspects. - I throw in a few test users and assign them to groups — this helps later when testing IAM and Terraform roles.
It’s a pretty quick phase on paper, but it sets the stage for everything else. If this part’s messy, you’ll feel the pain when teams start spinning up projects or fighting with IAM.
Keep it clean, simple, and locked down early.
Phase 3: Deploy with FAST
I use FAST (Fabric Accelerated Setup Tool) because it saves a ton of time and avoids mistakes you don’t want to discover six months down the line. It’s built on Cloud Foundation Fabric, and gives us a clean, modular way to roll out the landing zone using Terraform.
We’re not just creating projects and VPCs randomly. We’re building out:
- A shared VPC
- Environment folders (like dev, staging, prod)
- Project factories
- Logging and monitoring pipelines
- Org policies and security controls
All of it is done as code — which means it’s repeatable, trackable, and easy to fix or improve later.
I break the work into stages, just like FAST is designed for. Identity, networking, core infra, and so on. Each stage handles one thing well, and feeds into the next. And because everything’s Terraform, it fits into CI/CD and scales as the org grows.
Bottom line: this is where the landing zone goes from theory to real, working infrastructure — built the right way, from day one.
Final Thoughts
Designing a landing zone isn’t just provisioning a few resources. It’s about building the foundation for trust and velocity.
- If you get identity right, everything else is easier.
- If you structure your org and projects well, you’ll scale cleanly.
- If you start secure, you’ll sleep better.
- And if you monitor from the start, you’ll solve problems before they’re problems.
If you’re building (or rebuilding) your landing zone and want to skip some of the painful detours, I’m always open to share what’s worked — and what I’ve learned to avoid.
