A growing software company begins with one AWS account and a handful of engineers. Two years later, it has dozens of accounts, inconsistent billing tags, overlapping administrator roles, and logging settings that vary by team. A new security lead suggests adopting AWS Control Tower, assuming that switching on a landing zone will instantly bring every account into compliance. The platform team discovers that a landing zone creates governance structure and control mechanisms, but it cannot make old architectural choices disappear or replace explicit operating ownership.
The central task is designing the boundaries of a multi-account organization: which workloads need isolation, who can change their permissions, where audit evidence belongs, and how new accounts inherit safe defaults. These decisions connect naturally with AWS Solutions Architect Professional architecture work, yet they should be made for the organization’s real risk and delivery model rather than a generic certification diagram.
Organize accounts around durable boundaries
An AWS account provides a stronger administrative and billing boundary than a collection of projects sharing one account. Separate production and development environments when different change controls, incident blast radii, or access needs justify it. High-risk datasets, shared network services, security operations, and customer workloads may need their own accounts. The goal is not to maximize account count; it is to put meaningful isolation between activities that should not compromise one another.
Organizational units group accounts for policy administration. An OU should reflect shared governance needs, not every reporting-line change. A team reorganization should not require a risky move of hundreds of resources. Some companies use a workload hierarchy alongside dedicated shared-services, sandbox, and security accounts; others have simpler needs. Document why the grouping exists and how new accounts will be placed before automating account creation.
Early designs often confuse production and nonproduction as the only distinction that matters. A nonproduction account containing masked customer data can still be sensitive. A centralized networking account may carry routes that affect many production systems. Classify accounts using data, operational criticality, and delegated authority as well as environment labels. That classification drives guardrails and evidence requirements far more effectively than a uniform account template.
Understand the landing-zone version before copying diagrams
AWS Control Tower has evolved, and older diagrams are not a reliable description of all deployments. In landing-zone version 3.3 and earlier, its structure included a Security OU with the Log Archive and Audit shared accounts. Version 4.0 changed the model: the Security OU is no longer mandatory, and integrations such as AWS Config, AWS CloudTrail, certain security roles, and AWS Backup can be selected according to architectural need. Organizations can define their own structure while using a dedicated controls capability.
This flexibility places more responsibility on architects. If logging integration is optional, choosing not to enable it does not eliminate the need for organization-wide security evidence. If the company already operates a logging architecture, teams must determine whether to retain it, integrate it, or migrate carefully. An environment with no dependable audit pipeline is not made secure by the word ‘landing zone’ on a console page.
Version-specific behavior also affects migration. Moving an existing organization into Control Tower can expose naming assumptions, prior guardrails, account baselines, or deployed logging resources. Inspect actual landing-zone version, enabled integrations, registered OUs, and enrolled account state before following a runbook. Treat documentation screenshots as starting clues, not executable policy for an arbitrary estate.
Separate preventive controls from detective evidence
Preventive controls limit what a principal can do. Service control policies can constrain permissions across organizational boundaries; other controls may constrain configurations or permitted operations. Detective controls identify drift or noncompliant states after they occur. A preventive rule that blocks disabling required security evidence differs fundamentally from a detective rule that reports an unencrypted resource. Both may be valuable, but they answer different risk questions.
Not every preventive denial improves security. A broad service block may prevent legitimate incident response or new functionality while creating hard-to-diagnose authorization failures. Pilot policies against representative accounts and test exception handling. A control that protects audit logs should be more restrictive than a preference for a naming tag, and the process for changing either should reflect its consequences. Policies require review just as application code does.
Detective findings need accountable owners. If a configuration rule marks a resource noncompliant, who investigates it, by when, and with what evidence? Does the finding represent a genuine violation or a narrowly approved exception? A dashboard full of unresolved issues is not the same as control. Tie alerts to remediation workflow, record decisions, and periodically reassess controls that generate persistent noise without identifying meaningful risk.
Build an account-vending and enrollment path
A landing zone is only valuable if people can obtain governed accounts without resorting to unmanaged alternatives. Define how teams request accounts, what information is required, who approves the request, and which baseline services are provisioned automatically. Account identifiers, owner contacts, network connectivity, budgets, incident contacts, retention requirements, and lifecycle state should become first-class metadata. A new account with no owner quickly becomes a liability.
Account Factory and associated automation can streamline this workflow, but provisioning does not replace lifecycle management. Projects end, teams change, and some accounts must be quarantined or closed. Define ownership transfers, break-glass recovery, backup disposition, and decommissioning from the beginning. If creating an account takes an hour but closing one takes six months of detective work, the operating model is incomplete.
Existing accounts require different care from clean new accounts. Discover unregistered accounts and map their dependencies before enrollment. A central logging integration might conflict with a preexisting trail or retention strategy. A preventive control could break a critical deployment role. Sequence enrollment by risk, build a rollback plan, and confirm that security evidence continues to reach the intended destinations during transition.
Design identity, logging, and networking together
Central identity federation should provide repeatable workforce access while reducing long-lived account-specific users. Privileged access deserves explicit controls, independent audit, and a recovery path if the identity provider is unavailable. Cross-account roles should be narrowly defined by purpose and constrained through IAM and organizational policy. A landing zone that centralizes all privileges in one broadly trusted role merely moves the concentration of risk.
Logging architecture must also respect account and regional boundaries. CloudTrail and configuration evidence may need central aggregation, retention policies, encryption keys, and access separation from the operators being audited. Version 4.0’s optional integrations mean architects must verify their particular choices and responsibilities. Incident responders need evidence they can trust even when an application team has lost control of its account.
Network architecture should not be an afterthought of account vending. Shared transit routing, DNS, inspection points, and private service access can become dependencies for many accounts. A central network can simplify governance but also magnify outages and change risk. Consider failure isolation, route ownership, regional scope, and how sandbox accounts reach shared services. The best account layout supports the network and security model without forcing unnecessary centralized bottlenecks.
Prove the controls work under failure
A control is not established simply because its configuration is visible. Test whether an unauthorized role can disable logging, whether the expected identity can recover a locked account, whether an unenrolled account is detectable, and whether guardrails continue operating after organizational changes. Some tests should be performed in dedicated nonproduction accounts because deliberate denial or misconfiguration can disrupt real workloads.
Consider a developer who tries to create a public storage bucket in a restricted account. A preventive policy may reject the operation; a detective control may identify a misconfiguration after creation. The desired behavior must be explicit. A successful denial must not obscure who can grant an exception, and a detective finding must not be celebrated if no one ever acts. Tests should capture expected outcome, actual enforcement point, and usable audit evidence.
Changes to OUs or organization policy can affect many accounts at once. Require change review for high-blast-radius updates, use staged application, and maintain an emergency recovery procedure. A broken policy could prevent a critical operator from responding during an incident. Balancing centralized enforcement with tested operational recovery is one of the most consequential multi-account design choices.
Measure governance as an operating service
Metrics for a landing zone should describe outcomes: percentage of owned accounts properly enrolled, completeness and freshness of audit evidence, time to remediate high-severity drift, number of unmanaged exceptions, and turnaround time for legitimate account requests. Counting enabled controls or created accounts says little about security if the estate remains full of unresolved findings. Track how the service improves risk management without blocking reasonable delivery.
A governance team should document what it will do when a control objective conflicts with another legitimate obligation. For example, incident responders may need temporary access that normal operators should never hold, while auditors still expect a traceable record of emergency action. The answer is not permanent administrator access for everyone. Define a limited emergency role, independent approval or retrospective review, time-bounded use, and evidence that is protected from the same outage being investigated. Test this pathway before a real incident makes experimentation dangerous.
The same principle applies to account exceptions. A research team may need an AWS service not yet permitted by its OU. The exception request should describe the use case, data classification, operational owner, acceptable alternatives, duration, and compensating controls. A good landing zone gives the team an accountable path to a decision. One that simply blocks the service indefinitely may push experimentation into personal or unmanaged accounts where central controls provide no protection.
A well-designed landing zone makes good infrastructure choices easier for teams. New services begin with known identities, networks, logs, controls, and accountable owners. Experts working in AWS cloud security still need to validate those controls against actual threats and version-specific behavior. Control Tower provides valuable orchestration and guardrails; governance succeeds when the architecture, change process, and evidence system remain credible as the organization grows.