What a landing zone is

A landing zone is the part of your cloud that exists before any application does: the organisation, the folders, the projects for each environment, who can access what, where the logs go and how the bill is split. It is boring on purpose. When it is in place, a new team or a new product "lands" in a ready, safe spot instead of improvising one.

Without it, every project is created by whoever needed it that day, with whatever settings seemed right. Six months later nobody can say which project is production, why a contractor still has access, or which team owns half the bill.

Five decisions for day one

  • Organisation and folders. Mirror how you work, not your org chart: for example one folder per product, with one project per environment inside it. Policies set on a folder apply to everything below it.
  • Naming and labels. A short, predictable pattern such as product-env for projects, plus labels for the team, the environment and the cost centre. You will need those labels the day you look at the bill.
  • Identity. Grant access to groups, never to individual people, and sign in through your company identity provider. When someone leaves, removing them from one group removes every access.
  • Network defaults. Decide early whether projects share a network, and make "no public IP unless asked for" the default. Opening something later is easy; finding everything that was left open is not.
  • Logs and billing. Send audit logs to a place application teams cannot delete, and export billing data so you can query it. Both are cheap to set up and very hard to rebuild after an incident.

Keep it as code

Clicking through a console is fine for learning, but a landing zone should live in a repository, written with a tool such as Terraform. Every change is reviewed, every environment is built the same way, and a new project is a short pull request rather than a half-day of settings nobody wrote down.

Start small: the folders, the projects for one product, the groups and the log sink. It does not need to cover every future need on day one. It needs to be the one place where those decisions are made.

If you already have a mess

Most teams read this after the fact, and that is fine. Begin with an inventory: list the projects, who owns them and what runs in each. Then build the new structure next to the old one and move one project at a time, starting with the ones that matter least. Production goes last, once the new foundation has proven itself.

If you would like a second pair of eyes on your structure, book a Cloud Landing Zone Design and Architecture Review: we design and build landing zones with you, as code, and hand them over documented.