AWS foundation planning

AWS Landing Zone Planning Checklist

Published 16 Jun 2026 Updated 16 Jun 2026

Use this checklist to assess whether an AWS landing zone is ready for production workloads, migration waves, security governance and long-term operations.

Foundation

Start with the landing zone decisions that are hardest to change later

An AWS landing zone is more than an initial account setup. It becomes the operating foundation for identity, security, networking, audit evidence, workload separation and cost visibility. The first planning step is to define the account model and governance rules before production teams begin building in AWS.

  • Choose the management account ownership model and keep it free from normal workloads.
  • Define organisational units for production, non-production, security, shared services and sandbox use cases.
  • Decide which AWS Regions are approved for workloads and which need to be explicitly denied.
  • Agree the baseline tagging model before cost allocation and automation depend on it.

Planning checkpoint: if you cannot explain where a new workload account will sit, who owns it and which controls apply by default, the landing zone is not ready for scale.

Identity and access

Make access centralised before teams create local exceptions

Identity is one of the most expensive areas to retrofit. AWS IAM Identity Center, permission sets, break-glass access and role boundaries should be designed together so teams can move quickly without creating long-lived credentials or inconsistent administrator access.

  • Connect the landing zone to the organisation identity provider where appropriate.
  • Define permission sets for platform, security, operations, developer and read-only roles.
  • Create a documented break-glass process with monitoring and review.
  • Remove individual IAM users unless there is a controlled exception.

Planning checkpoint: every human access route should be traceable, time-bounded where possible and visible to security operations.

Guardrails

Use preventive and detective controls deliberately

Guardrails work best when they support the operating model rather than block delivery unpredictably. Preventive controls should stop activity the business never wants. Detective controls should surface drift, misconfiguration and policy exceptions quickly enough for teams to act.

  • Apply service control policies for high-risk actions such as disabling logging or using unapproved Regions.
  • Use AWS Config and Security Hub to detect drift and weak configurations.
  • Document exception handling so teams know how to request a temporary deviation.
  • Test controls against real deployment pipelines before broad rollout.

Planning checkpoint: a landing zone control is only useful if the business knows who reviews violations and what happens next.

Logging and evidence

Design audit evidence as a platform capability

Centralised logging is one of the main reasons to invest in the landing zone early. CloudTrail, AWS Config, VPC Flow Logs, workload logs and security findings should be routed to accounts and storage patterns that preserve evidence while keeping operational access practical.

  • Create log archive and security/audit accounts with tightly controlled access.
  • Enable organisation-level CloudTrail and protect log storage from modification.
  • Plan retention by regulatory need, operational value and storage cost.
  • Make evidence retrieval part of the runbook, not a one-off investigation.

Planning checkpoint: if an auditor asked for account activity and configuration history, the team should know where it is, who can access it and how long it is retained.

Network and workload readiness

Separate the landing zone from workload migration planning, but make them meet

A landing zone should be ready for actual workloads, not just pass a foundation review. Network segmentation, DNS, hybrid connectivity, ingress and egress controls, inspection points and shared services should be mapped against the first migration waves.

  • Confirm VPC patterns for shared, workload and inspection accounts.
  • Decide how hybrid connectivity, DNS forwarding and firewalling will work.
  • Map the first migration candidates to account, subnet, routing and security patterns.
  • Validate that CI/CD and infrastructure-as-code pipelines can deploy into the governed model.

Planning checkpoint: a secure landing zone still fails if the first workload team has to bypass it to meet delivery dates.

Operations and cost

Plan the operating model before the account count grows

Landing zones create repeatability, but repeatability still needs ownership. Define who provisions accounts, responds to findings, updates guardrails, reviews spend, manages exceptions and keeps shared services current.

  • Create an account vending and lifecycle process for request, approval, baseline and retirement.
  • Define alert ownership for Security Hub, GuardDuty, Config and operational monitoring.
  • Set budget, anomaly and tagging reports before spend becomes fragmented.
  • Schedule regular landing zone drift and maturity reviews.

Planning checkpoint: the best landing zone is not the one with the most controls; it is the one the organisation can operate consistently.

Useful references

Use the checklist alongside AWS and Cloudwrxs planning resources

This checklist should sit beside AWS documentation and Cloudwrxs service planning, not replace them. AWS Control Tower and Landing Zone Accelerator provide implementation patterns, while Cloudwrxs helps translate those patterns into a business-ready cloud foundation.

Useful next reads: AWS Landing Zones benefits, AWS Services, Well-Architected Review, AWS Control Tower planning documentation, and Landing Zone Accelerator on AWS.

Next step: if your AWS foundation already exists, use this checklist as a remediation review. If it does not exist yet, use it before the first production workload is approved.

Planning FAQ

Common questions before the decision

When do we need an AWS landing zone rather than a single AWS account?

A landing zone becomes important when multi-account governance, environment separation, central logging, identity, networking and cost controls matter more than the speed of creating a single AWS account.

Is AWS Control Tower enough on its own?

Control Tower provides a useful foundation, but it does not decide the account model, network design, exception process, operating responsibilities or workload intake pattern. Those decisions still need to be documented before production use.

What should be reviewed before the build starts?

Start with account ownership, identity model, security accounts, log archive account, network design, SCP guardrails, compliance requirements, support model and cost-governance plan.

Resource preview

What the checklist covers

The checklist covers governance decisions that should be settled before the landing zone becomes the foundation for production workloads.

  • Account structure, environments and account ownership
  • Networking, DNS, hybrid connectivity and transit paths
  • Identity, roles, privileged access and break-glass paths
  • Preventive and detective guardrails, logging and alerting
  • Operating model, cost governance, tagging and workload onboarding
Downloadable planning resource

Download the AWS landing zone planning checklist

Use the CSV checklist to turn account structure, networking, identity, governance, operations and cost decisions into a practical review path.

Download CSV checklist

Plan an AWS foundation that teams can actually use

Cloudwrxs helps organisations design, remediate and operate AWS landing zones that support secure cloud adoption, migration and governance.

Talk to Cloudwrxs