AWS Landing Zone / Control Tower setup

AWS Control Tower: Where Manual Account Setup Breaks

Accounts created by hand diverge predictably: the first two or three look alike, then the zoo begins. In one, storage encryption and logging to a shared archive are enabled; in another, they are not; in a third, rules were written for a specific task and no one has reviewed them. With ten accounts, you can still keep this in your head; with forty, you cannot.

Environment isolation suffers first. The boundary between production and test environments is held not by architecture but by engineer discipline: as long as an access rule lives in a checklist, sooner or later a test service gets access to production data.

Permissions drift the same way — roles were created at different times for different tasks, and no one can say anymore why a broad permission was left in place.

The cost shows up during audit and scaling.

To answer the question "which accounts have access logging disabled," you have to go through them one by one; a new account is checked against the baseline manually; rolling back a failed change becomes a separate piece of work.

AWS Control Tower addresses exactly this layer: it describes the target organizational unit structure, applies a single settings profile to each account, and records deviations from it.

We examine where manual setup breaks most often and what a governed multi-account environment does instead.

What a Governed Multi-Account Environment Provides

<cite>AWS Control Tower</cite> defines a baseline configuration for all accounts and monitors compliance with it — the governed environment is built around this.

Within it, every new account appears already with networking, logging, access policies, and monitoring, rather than being assembled manually from a checklist.

The first measurable effect is single sign-on.

An employee gets a single user account and task-specific roles instead of a set of keys in each account; permissions are granted through a group directory, so onboarding and offboarding are one operation rather than a tour of a dozen consoles.

The second is account onboarding.

Connecting a new environment according to the procedure takes an hour or two versus several days of manual assembly, while the baseline composition is the same for production, test, and sandbox accounts, so discrepancies between environments do not accumulate.

Third is deviation control. A change made manually in the console goes into the drift report and is either rolled back automatically or formalized as an exception with an owner and expiration date.

The share of accounts living outside the baseline falls from tens of percent to a few, and unaccounted environments without logs stop appearing at all.

Fourth is response speed.

An incident is investigated using unified logs and metrics across all accounts at once, so localization takes tens of minutes instead of hours, and a whole class of failures — direct edits in the production environment with shared keys and active access for departed employees — disappears from the statistics.

Options for Building the Environment: AWS Control Tower vs. Manual Assembly

Choosing an approach is a trade-off between speed of start and degree of control over each rule.

A managed service, such as AWS Control Tower, deploys the baseline environment with ready-made templates: accounts, action logging, audit zones, and restrictions on dangerous operations are enabled immediately.

Manual assembly based on declarative descriptions gives full freedom, but every rule and account template must be written, tested, and maintained by your team. Below are three options that organizations usually choose among.

Pure manual assembly is rarely chosen: more often organizations start with a managed service and add their own rules on top. The limitation is common to all options — rules must live in a repository, and deviations from templates must be detected automatically.

Otherwise the environment diverges from reality within a couple of months, and any of the approaches stops guaranteeing anything.

Implementation Stages: From Audit to Environment Handover

The order of stages here matters more than their content. If you design the organizational unit hierarchy after enabling AWS Control Tower, moving accounts recreates roles, breaks the logging history, and requires rechecking policies. That is why we go from inventory to handover, recording the state of the environment at each step.

1. Account audit. We compile a registry: owner, purpose, active services, connections to external systems. At this step, orphaned accounts and production workloads living in shared organizational units surface.
2. Hierarchy design. We design the organizational unit tree for the team and environment model: sandboxes separately, production separately, and an isolated log archive separately. We agree on the design before enablement — moving things after launch is more expensive.
3. Baseline environment setup. We deploy AWS Control Tower, attach accounts to the organizational structure, and enable centralized log collection. The archive is written to a separate account that cannot be edited from working accounts.
4. Policies and roles. We attach restrictions at the organizational unit level: prohibiting audit disabling, pinning allowed regions, and closing public storage. We grant roles on a least-privilege basis, separately for people and for services.
5. Access. We connect the user directory to permission sets so that access is granted and revoked through a request rather than manual key creation. We move service keys to a secrets store.
6. Pre-handover verification. We run scenarios: creating an account by request, attempting to go beyond policy, revoking access, log writing, and alert delivery.
7. Environment handover. We provide documentation on the hierarchy and policies, standard operation procedures, and an owner map. We stay in touch until your team begins making changes independently.

Access Policies, Service Roles, and Diagrams: What We Hand Over

We hand over not only a working environment but also everything needed to maintain it independently. Configurations, diagrams, and policies live in a repository alongside the infrastructure description, and decisions made are recorded in the documentation. Below is the package composition for AWS Control Tower.

• Baseline environment configuration (landing zone) — parameters of the management account, list of allowed regions, set of guardrail rules, connected audit and centralized logging services.
• Account hierarchy design — a map of organizational units with each one's purpose: production environments, staging, sandbox, shared services, log account. Plus the rule by which a new account lands in the right organizational unit.
• Access policies — permission sets for standard profiles (administrator, developer, auditor, read-only), restrictions at the organizational unit level, conditions based on sign-in source and mandatory second factor.
• Service roles — roles for automatic account creation, cross-account access for audit and log collection; for each one, the minimum required permissions and trust boundaries are described.
• Environment as code — infrastructure is reproduced from a repository: a change goes through review, enters version history, and rolling back a configuration is a normal operation on a commit.
• Review procedures — a schedule for monitoring deviations from the baseline, response procedure, responsible parties, and rules for approving temporary exceptions.
• Environment documentation — a map of accounts and networks, an access matrix, the procedure for connecting a new account, granting permissions, and investigating incidents.

Case Study: A 40-Account Environment Without Manual Settings Edits

The environment was built for four dozen accounts: products, development environments, analytics, and shared services.

Before we were involved, connecting a new account was a manual ritual — an engineer went through a checklist, created roles, enabled event collection, and compared settings by eye.

By the fifth or sixth account, the checklist diverged from reality, and deviations accumulated quietly — until the first review or access incident.

The foundation was AWS Control Tower plus a pre-agreed set of baseline settings: access rules, network boundaries, mandatory event collection, and a ban on public storage.

A new account is deployed from a template and joins the shared environment on its own, and a deviation from the baseline does not wait for a review — the system returns the setting to the specified one and writes an event to the shared log.

Manual operations decreased not "in general" but at specific points: connection stopped being a separate project, and audit stopped being a separate campaign.

The customer's team focuses on the product rather than comparing permissions, and at any moment can see exactly what is recorded in the environment.

How Do Managed Policies Differ from Manual Access Restrictions?

Manual restrictions are a set of individual prohibitions placed across accounts by hand.

When a new account or service appears, the rule is attached again according to a memo, and after a couple of months the memo diverges from reality: somewhere a restriction was forgotten, somewhere it was weakened "temporarily," and the boundaries of authority are determined not by a decision but by a specific engineer's memory.

Managed policies work differently: a rule is defined once at the organization level and inherited by all accounts, including those that will appear tomorrow.

The restriction operates from outside the account, so it cannot be removed from within — even a full administrator cannot raise their permissions above the established boundary.

In AWS Control Tower, this is the core of the model: accounts are born inside defined boundaries rather than configured after the fact.

The second difference is automatic deviation detection: the system continuously compares the actual configuration with the baseline and either returns it to the target state or records the deviation in a report.

A manual set of restrictions remains silent — you learn about disabled logging or storage exposed externally from an incident, not from a daily summary.

From the perspective of authority boundaries, the gain is in role separation: the platform team holds the shared environment and rules, while product teams work freely within their own and do not touch others'.

Expanding permissions becomes a change in one place with a predictable effect on all accounts, rather than a series of local edits. That is why the question shifts from "how many restrictions do we have" to "who sets them and at what level."

Technical Questions Asked Before Starting

Before starting, people usually come with three questions: what to do with existing accounts, what access the contractor needs, and how strict the restrictions will be. Below is how this works in AWS Control Tower, without general promises.

What access does the contractor get?

Through separate roles in the management account, with single sign-on and temporary permissions — we do not use long-lived keys or shared credentials. By default, the role is read-only; expanding permissions is agreed separately and recorded in the log. Access is revoked with one operation, without changing passwords for the customer's team.

Will restrictive policies block working operations?

Policies are introduced in stages: first in monitoring mode, then on a test group of accounts.

Critical scenarios — deployment, network rules, backup — are run in a staging environment before restrictions are enabled, so regressions in build environments are caught before production.

What if the management model turns out to be excessive?

An account can be removed from management while keeping its workloads: the baseline configuration is removed and policies are adjusted. The decisions remain in the documentation, so switching to another scheme does not start from scratch.

Where to Start: Discussing the Task and Implementation Plan

The implementation plan for AWS Control Tower is assembled not from a template but from an inventory of your current account structure.

To come back with an estimate of the task rather than general thoughts, we need a minimal but specific input — from a list of accounts to the requirements your audit checks.

What we request at the start:

• List of accounts and organizations: how many there are now, how they relate to each other, which were created manually and live without an owner.
• Role and access design: who is an administrator today, how permissions are granted, whether there are service accounts with long-lived keys.
• Security requirements: mandatory policies, prohibited actions, log composition and retention period.
• Environment constraints: regions in use, dependencies on specific services, legacy that cannot be switched automatically.
• Decision owner on your side: who approves changes and during which windows it is acceptable to touch working accounts.
• Integration points: where logs and metrics are sent, whether the new structure needs to be connected to current monitoring and alerts.

In response, we send a stage-by-stage work plan, a target account structure design, a set of guardrail policies, the account connection procedure, and a rollback plan.

We fix the starting conditions as the first step — who does what, in what sequence, and how we verify the result at each stage.