Landing zones and infrastructure as code, explained

Before you deploy a single workload to the cloud, the decisions you make about account structure, identity, networking, and logging will either give you a stable foundation to build on or a tangle of technical debt that follows you for years. A landing zone is how you make those decisions deliberately, once, and in a form your whole team can inspect, review, and rebuild.

What a landing zone actually is

A landing zone is the baseline environment you provision before workloads arrive. It is not a product you buy or a checklist you tick once. It is a set of agreed decisions, expressed as infrastructure, that answers three questions: who can do what, where do workloads live, and how do we know when something goes wrong?

In practice, a landing zone covers five interconnected concerns: placing production, staging, development, and shared services in distinct accounts so that a mistake in development cannot affect production; managing users, groups, and roles from one place rather than accumulating per-account credentials scattered across teams; defining virtual networks with sensible address ranges and keeping compute in private subnets; routing API activity logs and resource configuration events to a dedicated log archive that application teams cannot modify or delete; and applying policies that prevent obviously harmful configurations before they reach production. Each concern is straightforward on its own. The reason organisations invest in a deliberate landing zone is that getting them wrong independently creates compounding problems.

How the three major clouds provide the building blocks

Each hyperscaler has its own vocabulary for the same underlying concepts, and each provides mature, first-party tooling to build a landing zone with.

On AWS, the root construct is AWS Organizations, which groups multiple accounts under a single management account. AWS Control Tower builds on top of Organizations to provision new accounts through an Account Factory and to apply Service Control Policies as preventive guardrails across your account hierarchy. Identity within accounts is managed through AWS IAM, while AWS IAM Identity Center provides federated single sign-on across all accounts from one place.

On Azure, Management Groups sit above subscriptions and allow Azure Policy to be applied hierarchically so that every subscription inherits a consistent set of rules. The Azure landing zones reference architecture defines a standard set of subscriptions for platform services, connectivity, identity, and workloads. Microsoft Entra ID is the identity plane that spans every subscription in your tenant without any additional configuration.

On Google Cloud, the Organisation sits at the root of the resource hierarchy. Folders group projects by environment or team, and projects are the unit of billing and IAM policy boundary. Cloud IAM policies inherit down through the hierarchy, so a policy applied at the folder level propagates automatically to every project beneath it. For teams who want to manage that hierarchy declaratively, Config Controller, part of Anthos Config Management, applies policy and configuration through a Kubernetes-style resource model.

The names differ across all three. The concepts, namely hierarchy, environment separation, centralised identity, and inherited policy, are consistent throughout.

Infrastructure as code: the reasoning before the tooling

Infrastructure as code means describing your cloud resources in configuration files that live in version control, are reviewed like any other change, and are applied by a repeatable, automated process rather than by someone working through a web console. Defining your infrastructure this way from the start is what makes environments reproducible rather than assembled by hand, and it is the single discipline that makes everything else in a landing zone manageable as the organisation grows.

The practical consequences are concrete. Every change to your infrastructure has a commit, an author, and a review record, so you can see exactly when a network rule was loosened and who approved it. The same configuration files that provision your staging environment provision production, which removes the "I did it slightly differently for prod" class of surprise. Running a plan against a live environment immediately surfaces any manual change that has caused your actual state to diverge from your declared state. And because a plan can run automatically on every pull request, reviewers see the infrastructure change alongside the application change before anything is applied.

The main tools in use today are Terraform and its open-source fork OpenTofu, which are cloud-agnostic and carry a large ecosystem of community modules. AWS CloudFormation is AWS-native and requires no separate state file to manage. Azure Bicep is Azure-native with a cleaner authoring experience than the underlying ARM JSON it compiles to. For Google Cloud, Deployment Manager is the native option, while Config Controller suits teams who already work with Kubernetes tooling. Terraform and OpenTofu are the most common choice for teams working across more than one cloud, because the same working patterns transfer between providers.

A right-sized approach for startups

Enterprise landing zones can span dozens of accounts, multiple network transit hubs, dedicated security operations teams, and months of design work. That is not where a ten-person startup should begin, and starting there would waste both time and money that early-stage companies do not have.

A practical sequence for a startup looks like this.

1. Separate environments first. At minimum, a production account and a non-production account give you the most important property: a boundary that prevents a development mistake from touching production.
2. Establish centralised identity. AWS IAM Identity Center, Microsoft Entra ID, or Google Cloud's Workforce Identity Federation can each federate to an existing identity provider. Google Workspace is a common anchor in South Africa and integrates cleanly with all three clouds.
3. Adopt infrastructure as code from the beginning. Even a single configuration file in a repository is a better starting point than a console-provisioned environment. You can refactor and extend later; you cannot reconstruct what someone clicked through two years ago.
4. Set a budget alert. AWS Budgets, Azure Cost Management, and Google Cloud Budget Alerts all provide threshold notifications at no extra cost. A budget alert has saved more teams from an unexpected bill than any other single control.
5. Add baseline guardrails. A Service Control Policy on AWS, an Azure Policy initiative, or a Google Cloud Organisation Policy that blocks resource creation outside your approved regions, prevents public object storage, and requires encryption at rest addresses the most common and expensive misconfigurations.

Add centralised logging, more refined network segmentation, and stricter policies as your workloads grow and your compliance picture becomes clearer. The goal on day one is a foundation you can extend, not a finished enterprise architecture. Our cloud migration guide for startups covers how a landing zone fits into the broader sequence of getting your first workloads onto a hyperscaler.

Guardrails, least privilege, and cost visibility

Guardrails come in two categories. Preventive guardrails, which include Service Control Policies in AWS, Azure Policy deny effects, and Organisation Policies in Google Cloud, stop non-compliant resources from being created at all. Detective guardrails, which include AWS Config rules, Azure Policy audit effects, and Google Cloud Security Command Center findings, alert you when something drifts out of compliance after the fact. Both categories serve a purpose, and a mature landing zone uses both.

Least-privilege identity and access management means that roles and service accounts carry only the permissions they need for the task they perform. This matters for security, and it matters specifically under POPIA, South Africa's Protection of Personal Information Act, which requires that access to personal information be limited to those with a legitimate purpose. Operationalising that principle in your IAM configuration is one of the most direct ways to demonstrate compliance. Our article on POPIA and security foundations for South African startups covers the practical IAM controls in detail.

Consistent resource tagging connects your landing zone to cost management. Every resource tagged with its environment, team, and cost centre from the moment it is created gives you the data you need to slice your cloud bill accurately. Without that discipline in place from the start, cost attribution becomes guesswork as your environment grows. Our post on cloud engineering for small teams explains how to make tagging a non-negotiable part of your infrastructure module interface rather than an afterthought.

State management and automation

Terraform and OpenTofu track what they have provisioned in a state file. That file must be stored remotely and shared across your team so that no two applies can run simultaneously against the same environment. AWS S3 with DynamoDB locking, Azure Blob Storage, and Google Cloud Storage are all standard remote state backends for their respective clouds.

In a continuous integration pipeline, the standard pattern runs a plan automatically on every pull request and posts the proposed changes as a review comment, so that reviewers see the infrastructure diff alongside the application change. The apply then runs automatically on merge to the main branch using the saved plan, which means no engineer is typing a live apply command against production from a local terminal. Tools such as Atlantis and Spacelift automate this workflow, and it can equally be implemented directly in GitHub Actions or GitLab CI without adding another platform dependency.

How Lambdaserve helps

Lambdaserve is a South African software studio and cloud-engineering practice working across Azure, Google Cloud, and AWS. AWS engagements are delivered in partnership with Datagnu. Whether you are setting up your first landing zone, bringing an ad-hoc cloud environment under infrastructure-as-code discipline, or preparing a foundation ahead of a larger migration, we work alongside your team to get the structure right so that everything built on top of it is easier to operate, audit, and grow.

Written by the Lambdaserve team as general, informational guidance for founders and engineers. It is not legal, financial or tax advice. Third-party product names, programmes and logos belong to their respective owners and are referenced for identification only.