How AspireNXT designs enterprise AWS landing zones for large, multi-account environments
An enterprise AWS landing zone is the foundation every workload inherits: accounts, guardrails, identity, network, and logging, all in place before the first application moves. Skip it, and each migration wave builds its own version of those controls. Six months later, you have forty accounts configured forty different ways, and a security team that cannot say who can reach what.
This article covers how AspireNXT designs landing zones for large enterprises running multi-account environments on AWS. It follows the design decisions in the order we make them, the automation that keeps the environment consistent, and the mistakes that cost the most to fix later.
Why the landing zone comes before the first workload
A landing zone is a pre-configured, secure, multi-account AWS environment that gives workloads a governed place to run. It is not a deliverable you finish and shelve. It is the baseline against which every future account, team, and application is measured.
The case for building it first is practical. Retrofitting guardrails onto running workloads means negotiating with application owners, scheduling change windows, and accepting that some accounts will never fully conform. Build the baseline first, and every workload arrives into a structure that already enforces your policies.
Large organizations have a second reason. A single AWS account has hard boundaries for permissions, quotas, and blast radius. Put production, development, security tooling, and shared services in one account, and IAM policies alone have to hold all of that apart. Separate accounts give you isolation that does not depend on every policy being written perfectly. AWS documents this reasoning in its multi-account strategy guidance, and it matches what we see in practice.
Multi-account foundation: AWS Organizations and organizational units
The foundation starts with AWS Organizations. The management account sits at the root, and we keep it nearly empty. It holds billing and organization-level administration. No workloads, no engineering access, no shared tooling.
Beneath it, we group accounts into organizational units (OUs) that reflect how policy applies, not how the org chart looks. A typical structure includes:
Security OU: the dedicated security tooling account and the log archive account
Infrastructure OU: the shared services account and the network account
Workloads OU: split into production and non-production, with workload accounts beneath each
Sandbox OU: where engineers experiment and where we test policy changes before they reach anything real
Suspended OU: where decommissioned accounts land, with deny-all policies attached
The dedicated accounts each have a job. The security account runs detective services and gives the security team a place to operate without touching workload accounts. The log archive account receives logs from across the organization and is locked down so that even administrators in workload accounts cannot alter them. The shared services account hosts common tooling such as directory services, CI/CD runners, and artifact repositories. The network account owns routing, firewalls, and connectivity.
Workload accounts are separated by environment. Production, staging, and development do not share an account, and in larger estates a single application's environments get their own accounts too. This adds a little governance overhead and removes a great deal of incident scope. A compromised development credential cannot reach production data, because the account boundary does not disappear when someone misconfigures IAM.
OU design is where large enterprises most often overthink. Keep the hierarchy shallow. Every level of nesting is another place where a service control policy can interact with something unexpected. Design OUs around where policy genuinely differs, and add depth only when a real control requires it.
Guardrails: SCPs, preventive controls, and detective controls
Guardrails make the structure enforceable. We think about them in two categories.
Preventive controls stop an action from happening. In AWS, these are service control policies (SCPs) applied at the OU or account level. Typical examples include denying the ability to disable logging, restricting workloads to approved regions, blocking the creation of public storage, and preventing member accounts from leaving the organization.
Detective controls flag a condition after the fact. They watch for configuration drift, such as an unencrypted volume or a security group open to the internet, and surface it to the security team.
You need both. Preventive controls are blunt and absolute, so reserve them for things that should never happen. Detective controls cover everything where context matters and a blanket denial would break legitimate work.
Where AWS Control Tower fits
We use AWS Control Tower as an orchestration layer. It sets up the multi-account structure, applies a baseline set of controls, and provisions accounts through Account Factory. The AWS Control Tower documentation describes its controls as guardrails covering preventive, detective, and proactive behaviors. It is the reference we point clients to when explaining what the service manages and what it leaves to them.
Control Tower is a starting point, not the whole design. Large enterprises almost always need controls beyond the managed set, a custom network topology, and integration with existing identity and ticketing systems. We treat Control Tower as the scaffolding that keeps the baseline consistent, then extend it with infrastructure as code for everything specific to the client.
Test SCPs in a sandbox OU first
SCPs are powerful and unforgiving. A policy that denies an action denies it for every principal in scope, including the automation your own teams depend on. We have a firm rule: no SCP reaches a production OU until it has run in a sandbox OU that mirrors the structure it will govern.
The test is straightforward. Attach the policy to the sandbox OU, run the actual workflows, including deployment pipelines, backup jobs, and incident response runbooks, and watch for denied calls. Policies that look correct on paper routinely block something nobody remembered. Finding that in a sandbox is a minor inconvenience. Finding it during a production deployment is an outage.
Identity and access: centralized sign-in and least privilege
Identity in a multi-account environment fails in a predictable way. IAM users accumulate in individual accounts, each with its own long-lived credentials, and nobody can say who has access to what.
We centralize sign-in with AWS IAM Identity Center, connected to the client's existing identity provider. Engineers authenticate once against the corporate directory and receive short-lived credentials for the accounts they are assigned. When someone leaves the company, disabling them in the directory removes their AWS access everywhere. There is no account-by-account cleanup.
Access is defined through permission sets, which are reusable templates mapped to groups and assigned to specific accounts. Four principles guide how we write them:
Start from the job function, not from a list of services. A platform engineer, a data analyst, and a security auditor need different things.
Grant the minimum the role needs to do its work, then widen deliberately when a real need appears.
Separate read-only, deployment, and administrative permission sets so that elevated access is an explicit, auditable choice.
Keep break-glass access for emergencies tightly controlled and monitored, with every use reviewed.
Least privilege is easy to endorse and hard to sustain. The practical approach is to start restrictive and make requesting additional access fast. If getting permissions takes a week, people find workarounds, and the workarounds are worse than the permissions would have been.
Network design: hub-and-spoke and centralized inspection
Network architecture is where landing zone decisions are hardest to reverse, so we settle the traffic model early. The design has to account for three flows:
Ingress: traffic from the internet or partners into your environment
Egress: traffic from workloads out to the internet and external services
East-west: traffic between workloads and between VPCs
The common pattern for large environments is hub-and-spoke. A central network account owns a transit layer, and workload VPCs attach to it as spokes. That gives you one place to manage routing and one place to insert inspection. Where security requirements call for it, we route traffic through a centralized inspection VPC with firewalling, so ingress, egress, and cross-VPC traffic all pass through controls the security team owns.
Centralized inspection has tradeoffs. It concentrates traffic, which concentrates both visibility and potential bottlenecks, and it adds a dependency every workload shares. The right choice depends on your compliance requirements and traffic volumes. Some estates are better served by distributed controls with strong standards.
Hybrid connectivity deserves the same attention. Most enterprise migrations run for months or years with workloads split between data centers and AWS. We design the connection to on-premises networks, whether through VPN or dedicated links, as a first-class part of the landing zone. IP address planning belongs here too. Overlapping CIDR ranges between AWS and on-premises networks are a classic problem: trivial to prevent now, painful to resolve once workloads depend on the addresses.
Centralized logging and security visibility
Logs are only useful if they exist when you need them, and they can only be trusted if the people being audited cannot modify them. That is why the log archive account is a fixed part of every design.
We configure organization-wide audit trails and configuration recording so that activity in every account flows to the log archive account automatically. New accounts are enrolled by default, not because someone remembered to enable logging. Retention, encryption, and access controls on the archive are defined once and apply everywhere.
The security account then provides the operational view: aggregated findings from detective services and a single place for the security team to triage. The aim is that an analyst can answer "what happened, in which account, and by whom" without requesting access to forty different environments.
Account vending and provisioning automation
In a large enterprise, new accounts are requested constantly. If creating one takes a ticket and two weeks, teams stack workloads into existing accounts to avoid the wait, and the boundaries you designed erode.
We automate account vending so that a new account is a request, not a project. With Account Factory in Control Tower and infrastructure as code, a requested account arrives already placed in the correct OU, enrolled in logging, attached to the network, wired to Identity Center, and tagged. The whole baseline is defined as code, version-controlled, and reviewed like any other change.
This matters for consistency over time. The thirtieth account should match the third in its baseline, and the only way to guarantee that is to make the baseline a repeatable artifact instead of a checklist someone follows. Drift detection then tells you when an account has strayed.
Cost allocation, tagging, and NxtOps
A multi-account structure improves cost visibility, because the account is a natural unit of attribution. It does not make allocation automatic. Without a tagging standard, you can see which account spent money but not which team, product, or project it belongs to.
We define the tag schema as part of the landing zone, not after it: owner, cost center, environment, application. Tagging requirements are enforced through policy where possible and checked through detective controls where not. Account vending applies baseline tags automatically, so no new account starts untagged.
Many of our clients run more than one cloud, so cost visibility has to span them. NxtOps is AspireNXT's multi-cloud FinOps platform, and it builds on the allocation structure the landing zone establishes. The tagging and account design we put in place gives a FinOps practice reliable data to work with. A cost platform is only as good as the structure beneath it, which is why we set that structure up first.
Observability with ObserveX
A landing zone should be observable from the start. ObserveX is AspireNXT's observability accelerator, and it deploys inside the customer's cloud environment. That placement matters for enterprises with data residency and security concerns, because telemetry stays within boundaries you control instead of flowing to an external platform.
Building observability into the baseline means every new workload account inherits monitoring conventions instead of each team assembling its own. It also gives the operations team consistent signals across the estate when something goes wrong.
Handoff to day-2 managed services
A landing zone that nobody operates decays. Policies collect exceptions, accounts drift, and the clean structure you built becomes a historical artifact. We design with day-2 operations in mind from the beginning.
That means documented runbooks, a clear ownership model for each account type, and defined processes for policy changes, account requests, and incident response. For clients who want it, our managed services teams take over operation of the environment after the build, so the people who understand the design keep running it. For clients who prefer to operate it themselves, the handoff includes the code, documentation, and walkthroughs they need to do that confidently.
Common mistakes to avoid
These are the errors that cost the most to correct:
Putting workloads in the management account. It is the one account you cannot afford to compromise, and it should hold nothing else.
Designing OUs around the org chart. Policy boundaries and reporting lines rarely match. Structure OUs around where controls differ.
Pushing SCPs straight to production. Test in a sandbox OU first, every time.
Planning IP addressing late. Overlapping ranges with on-premises networks are expensive to unwind.
Treating the landing zone as a one-time project. Without ownership and an update process, it drifts.
Leaving tagging for later. Retroactive tagging across hundreds of resources rarely gets finished.
Relying on manual account creation. Inconsistent accounts are the root of most governance problems.
Frequently asked questions
What is an enterprise AWS landing zone?
It is a pre-configured, governed, multi-account AWS environment that provides the baseline for security, networking, identity, logging, and cost management. Workloads are deployed into it and inherit its controls.
How long does it take to build a landing zone?
It depends on the number of accounts, the network complexity, existing identity systems, and compliance requirements. We scope this with each client during discovery instead of quoting a universal timeline.
Do we need AWS Control Tower?
Not strictly, but it provides a consistent starting point for account structure, baseline controls, and account provisioning. Most large enterprises use it as the orchestration layer and extend it with custom infrastructure as code.
Can we build the landing zone while migrating?
You can run them in parallel, but the foundation needs to be in place before production workloads move. Early waves can land in the baseline as it matures, provided the guardrails and network are ready first.
How many AWS accounts should we start with?
Enough to enforce the separations that matter: management, security, log archive, shared services, network, and workload accounts split by environment. Add workload accounts as teams and applications onboard.
Who maintains the landing zone after it is built?
That is a decision for each organization. Some operate it internally, and others hand it to a managed services partner. Either way, ownership needs to be explicit and documented.
How AspireNXT can help scope your landing zone
AspireNXT is an AWS Services Partner with 13+ years of delivery experience. The landing zone work described above is what our Cloud and AI teams do before migration begins. We map your accounts, guardrails, identity model, and network to your compliance and operating requirements, then build and hand off an environment your teams can run.
If you are planning a migration, or partway through one without a solid foundation, we can help you scope the landing zone and multi-account structure that fits your estate. Set up a call with our Cloud and AI teams to discuss your goals and next steps, and reach us through aspirenxt.com.
Build the foundation before you build on it
A landing zone is the least visible part of an AWS migration and the one that determines how well everything after it goes. Multi-account structure, enforceable guardrails, centralized identity, a deliberate network, and automated provisioning turn cloud adoption from a series of one-off decisions into a repeatable practice.
None of these decisions is exotic. They are well documented in the AWS multi-account guidance. What separates a durable landing zone from a fragile one is making those decisions early, encoding them as code, and assigning someone to own them. Do that before the first workload moves, and every migration wave after it gets easier.
Comments