AWS Landing Zone Checklist for Growing Teams

A practical checklist for structuring AWS accounts, identity, networking, logging, guardrails and ownership before cloud growth becomes operational debt.

An AWS landing zone is not simply a collection of accounts or a Control Tower deployment. It is the shared environment, controls and operating model that let teams create workloads without redesigning identity, networking, logging and ownership every time. AWS describes a landing zone as a well-architected, multi-account environment that can serve as a starting point for deploying workloads. The important phrase is starting point: the value comes from how the environment is operated after it is created.

This checklist is designed for teams moving beyond a single production account, preparing for a larger cloud migration, or correcting an AWS estate that grew one exception at a time. It complements our downloadable Cloud Foundation Readiness Checklist, which covers AWS, Azure and Google Cloud.

1. Start with ownership and workload boundaries

Before choosing an organisational-unit hierarchy, list the workloads, environments and owners that the foundation must support. A sensible account boundary usually reflects a meaningful difference in lifecycle, access, risk or financial ownership. Production and non-production workloads should not be separated merely by naming conventions inside one crowded account when the organisation needs stronger isolation.

Record the following for every proposed account:

  • business owner and technical owner;
  • purpose, expected lifetime and data classification;
  • production, non-production, security or shared-service role;
  • approved regions and recovery requirements;
  • cost centre, budget owner and mandatory tags;
  • process for transfer, suspension and closure.

Keep security tooling and central logs outside ordinary workload accounts. AWS Control Tower normally establishes dedicated log archive and audit accounts as part of its shared-account model. That reduces the chance that a workload administrator can silently alter the evidence used to investigate the workload.

The AWS guidance on creating a landing zone is a useful reference, but your account model still needs to reflect your organisation rather than a generic diagram.

2. Make human access federated and temporary

Define one authoritative identity source and use federation for workforce access. Avoid building a parallel collection of long-lived IAM users. Roles should describe a job or support responsibility, not a particular person, and privileged access should be time-bound wherever the available tooling supports it.

The baseline should answer practical questions:

  • How does a new engineer receive access?
  • Who approves production or security access?
  • How quickly is access removed when a person changes role?
  • Where is emergency access stored, tested and reviewed?
  • Which actions require stronger authentication or a separate role?
  • How are machine identities created and rotated?

Root credentials need a specific operating procedure. Protect them with strong multi-factor authentication, prevent routine use and make sure the recovery details belong to the organisation rather than one employee. A foundation is not ready if the only route into a critical account depends on a personal phone number or inbox.

3. Design the network from traffic flows

Do not begin with a large CIDR and assume the rest can be decided later. Document application-to-application, user-to-application, internet ingress, outbound dependency, administrative and on-premises traffic flows. Then decide which connections are allowed, where inspection occurs and which team owns each path.

A workable network baseline normally includes:

  • non-overlapping address allocation for expected growth;
  • private DNS and naming conventions;
  • controlled ingress and egress paths;
  • account and environment segmentation;
  • routing ownership and change review;
  • connectivity monitoring and flow logging;
  • a deliberate choice between centralised and distributed network services.

If on-premises systems remain in use, treat hybrid connectivity as a service with owners, monitoring, failure procedures and route documentation. Our Data Steels AWS migration case study shows why migration and site-to-site connectivity should be planned as one operational change rather than two unrelated tasks.

4. Centralise evidence before workloads arrive

Enable organisation-level activity logging, configuration visibility and security findings early. Decide where logs are aggregated, who can read them, how long they are retained and how changes to the logging pipeline are detected. “Logging enabled” is not a complete control if nobody owns alert triage or can explain retention.

Build a minimum security baseline for every new account. This may include encryption defaults, restrictions on public exposure, required logging, approved regions and controls around privileged IAM changes. Connect the baseline to a documented exception route. Teams need a safe way to explain a legitimate exception, identify its owner and set a review date; otherwise controls are bypassed informally.

Service control policies are useful boundaries, but they do not grant permissions. AWS explains that an SCP defines the maximum permissions available to affected accounts. Test restrictive SCPs in a limited organisational unit before broader rollout, as recommended in the AWS SCP documentation. A root-level policy applied without representative testing can interrupt deployment and support workflows.

5. Build account creation as a product

A landing zone becomes valuable when a team can request a compliant environment and receive the same tested baseline repeatedly. Account vending should apply naming, ownership metadata, identity assignments, logging, security services, network attachments, budgets and the repositories or pipelines used to manage later changes.

Treat the result like an internal product:

  • publish what the platform provides and what the workload team owns;
  • define a support route and service expectations;
  • version reusable Terraform or OpenTofu modules;
  • test changes before promoting them across accounts;
  • document common requests and failure recovery;
  • measure how long it takes to create a usable environment.

Manual approval can remain appropriate for high-risk decisions, but routine creation should not depend on copying configuration from the previous account. Our Cloud Foundations service focuses on turning these recurring decisions into maintainable code, controls and documentation.

6. Include recovery and cost ownership

The foundation should establish how workloads classify recovery needs, where backups are kept and how restoration is proven. A backup job completing successfully is not the same as a recoverable system. Define test frequency, accountable owners and evidence for restoration exercises.

Cost management also starts at the foundation layer. Require ownership and cost-allocation tags, establish budgets and anomaly detection, and decide who reviews shared-service costs. Teams should see the cost of their architecture choices without needing broad billing-administrator access.

7. Validate the operating model

Before calling the landing zone complete, walk through real scenarios:

  1. onboard a new workload and engineer;
  2. deploy a representative service through the approved path;
  3. investigate a suspicious identity or network event;
  4. revoke access and rotate a compromised credential;
  5. restore data or infrastructure from the defined recovery process;
  6. identify the owner and cost of an unexpected resource;
  7. apply and, if necessary, roll back a foundation change.

These exercises expose gaps that architecture diagrams often hide. If the platform team is the only group able to operate the environment, knowledge transfer is not finished.

A practical next step

Score the current environment before buying more tooling. The Cloud Foundation Readiness Checklist gives you 50 concrete checks across ownership, identity, networking, security, recovery, infrastructure delivery and FinOps. Use the lowest-scoring domains to define a first improvement phase, then review the result with the people who will operate it.

If you want an independent view, book a cloud foundation consultation. We can assess the current estate, identify the material risks and produce a staged plan without assuming that every existing component must be rebuilt.