AWS Control Tower: what it solves and why I chose not to use it

AWS Control Tower appears to offer a wonderfully compact answer to a large architectural problem.

I need:

• an AWS organisation;
• multiple accounts;
• central logging;
• security oversight;
• workforce access;
• account provisioning;
• organisation-wide controls;
• compliance visibility;
• protection against configuration drift.

AWS Control Tower says, in effect:

Give me the organisation.

I will assemble a governed
multi-account landing zone.

That is not an empty promise.

AWS Control Tower orchestrates services including AWS Organizations, AWS Service Catalog and AWS IAM Identity Center to establish and govern a multi-account environment. It creates and manages landing-zone resources, applies controls and provides a consolidated view of governance state.

For many organisations, this is an excellent starting point.

It converts a long list of foundational tasks into a supported AWS service.

It can reduce the amount of bespoke landing-zone engineering required before application teams receive usable accounts.

It can also make good multi-account patterns more accessible to a company that needs governance quickly.

bfstore still chose not to use it.

That choice was not based on the belief that Control Tower is bad, inflexible or only suitable for beginners.

The current service is much more flexible than its earlier versions. Landing Zone 4.0 allows organisations to define their own structure, makes several integrations optional and even supports a controls-focused environment without deploying a complete traditional landing zone.

My decision was narrower:

Control Tower was capable of producing much of the environment I needed. It would also have taken ownership of several mechanisms I specifically wanted bfstore to expose, test and explain.

The decision was about project purpose, operating model and learning value.

Not product quality.

A landing zone is more than an organisation

AWS Organizations provides the hierarchy.

It gives me:

• a management account;
• member accounts;
• organisational units;
• consolidated billing;
• organisation policies;
• delegated administration;
• trusted service integrations.

That is not yet a complete landing zone.

A production-ready multi-account environment also needs decisions about:

• account purposes;
• workforce access;
• central logging;
• security administration;
• approved Regions;
• account bootstrapping;
• policy attachment;
• detective controls;
• network ownership;
• backups;
• recovery;
• exception handling;
• account vending;
• evidence.

A simplified landing zone looks more like this:

AWS ORGANISATION
       │
       ├── account structure
       ├── identity and access
       ├── preventive controls
       ├── detective controls
       ├── security visibility
       ├── central logging
       ├── account provisioning
       ├── baseline configuration
       └── governance operations

AWS Control Tower coordinates many of these concerns through AWS-native services.

It does not replace AWS Organizations.

It extends it with an opinionated governance and account-management layer.

That distinction matters.

Control Tower is not a separate cloud-governance universe.

Its controls and resources are implemented through familiar AWS mechanisms such as:

• service control policies;
• resource control policies;
• AWS Config rules;
• CloudFormation hooks;
• CloudFormation StackSets;
• CloudTrail;
• IAM roles;
• IAM Identity Center;
• Service Catalog.

The value is orchestration.

AWS owns more of the assembly, lifecycle and conformity checking.

What Control Tower sets up

A full Control Tower landing zone can establish shared governance capabilities and managed resources around an AWS organisation.

Depending on the selected landing-zone version and configuration, Control Tower can provide or integrate:

• security and logging accounts;
• organisation-level CloudTrail;
• AWS Config recording and aggregation;
• IAM Identity Center access;
• baseline IAM roles;
• managed controls;
• account enrolment;
• Account Factory;
• dashboards for governance and drift.

Landing Zone 4.0 makes integrations such as AWS Config, CloudTrail, IAM Identity Center, security roles and AWS Backup more selectively configurable than in earlier versions. It also removes the earlier requirement that every deployment adopt the same mandatory organisational structure.

This is important because an old description of Control Tower might say:

Control Tower forces every organisation
into one fixed OU structure.

That is no longer a fair description of the current service.

A more accurate model is:

CONTROL TOWER
      │
      ├── managed landing-zone baselines
      ├── optional service integrations
      ├── managed control catalogue
      ├── OU and account governance
      ├── account lifecycle workflows
      └── defined drift workflows

The platform remains prescriptive.

It has become more modular about which prescriptions must travel together.

Those choices are connected. In Landing Zone 4.0, disabling the AWS Config integration also removes detective controls, the full Account Factory and Service Catalog path, Account Factory for Terraform, Account Factory Customization and OU baselines. AWS Organizations account creation, account movement and auto-enrolment provide a lighter alternative.

See the Landing Zone 4.0 feature comparison.

Controls are the governance vocabulary

Control Tower calls its governance rules controls.

Older documentation and discussions may call them guardrails. The terms refer to the same general Control Tower concept.

Controls are enabled against organisational units, but inheritance depends on their behaviour.

Preventive controls flow through nested OUs and affect their accounts, including accounts and OUs that are not registered with Control Tower. Detective and proactive controls do not automatically flow into nested OUs. They must be enabled for the relevant registered OUs and operate only in supported governed Regions.

See Nested OUs in AWS Control Tower.

Preventive controls

Preventive controls stop prohibited actions.

They are implemented through AWS Organizations service control policies, resource control policies or declarative policies.

A request that violates the applicable policy is denied before the action succeeds. Preventive controls work across AWS Regions because the underlying organisation policies govern the account rather than depending on a Regional resource assessment.

REQUEST
   │
   ▼
ORGANISATION POLICY
   │
   ├── permitted → continue
   └── denied    → stop

Detective controls

Detective controls evaluate resources for non-compliance.

They are commonly implemented using AWS Config rules.

They do not necessarily prevent the resource from being created. They identify that the resulting state violates the control.

RESOURCE EXISTS
      │
      ▼
CONFIGURATION EVALUATED
      │
      ├── compliant
      └── violation reported

Proactive controls

Proactive controls assess supported resources before CloudFormation deploys them.

They use CloudFormation hooks managed through Control Tower. A non-compliant resource can be rejected during provisioning rather than discovered afterwards.

CLOUDFORMATION CHANGE
        │
        ▼
PROACTIVE CONTROL
        │
        ├── compliant     → provision
        └── non-compliant → reject

These behaviours answer different governance questions:

That model is one of Control Tower’s strongest features.

It moves governance away from one giant policy document and towards controls with explicit enforcement behaviour.

See Control behaviour and guidance.

Managed controls reduce repeated policy engineering

Without Control Tower, a platform team may need to:

1. identify the policy objective;
2. select an enforcement mechanism;
3. write the SCP, RCP, declarative policy, Config rule or hook;
4. test and deploy it;
5. map it to compliance requirements;
6. monitor it;
7. update it as AWS behaviour changes.

The Control Catalog provides a consolidated catalogue of AWS-managed controls organised around objectives, services and compliance frameworks.

AWS currently describes the catalogue as containing more than 750 managed controls across areas such as security, operations, resilience, cost and compliance. The catalogue can be inspected through the console and APIs, and organisations can use the controls-focused experience without deploying a full traditional landing zone.

This can save substantial effort where an organisation needs:

• consistent control definitions;
• documented policy intent;
• compliance-framework mapping;
• broad service coverage;
• supported control updates;
• governance reporting.

A managed control does not remove the need to understand the policy.

It removes some of the repeated implementation work.

See AWS Control Tower features and the Control Catalog reference.

Mandatory controls protect the integrations you enable

Mandatory controls protect the governance resources on which Control Tower depends.

Landing Zone 4.0 changed how they are introduced. Mandatory controls are no longer enabled by default across every OU. AWS deploys the controls required by the integrations and managed resources selected for the environment.

Once an applicable mandatory control is deployed, it protects the associated Control Tower resources and generally cannot be disabled independently.

This is sensible.

A governance service cannot provide reliable oversight if ordinary account administrators can quietly dismantle its:

• roles;
• logging resources;
• policies;
• configuration recorders;
• cross-account access.

Control Tower therefore owns certain resources and expects them to be changed through supported Control Tower workflows. AWS warns that changing or deleting those resources outside supported methods can leave the environment drifted or in an unknown state.

CUSTOMER-MANAGED RESOURCES

change through ordinary
platform workflows


CONTROL-TOWER-MANAGED RESOURCES

change through supported
Control Tower workflows

For a company that wants AWS to own more of the landing-zone machinery, this is beneficial.

For bfstore, it would have obscured some of the machinery I wanted to operate directly.

See Control behaviour and guidance and considerations for controls and OUs.

Baselines make governance repeatable

A Control Tower baseline is a group of resources and configurations applied to a target.

The AWSControlTowerBaseline is the fuller OU-level baseline. It establishes resources and controls needed for compliance monitoring, auditing, security monitoring and optional access management. Accounts in the target OU receive the baseline through enrolment.

REGISTERED OU
      │
      ▼
CONTROL TOWER BASELINE
      │
      ▼
MEMBER ACCOUNTS RECEIVE
REQUIRED GOVERNANCE RESOURCES

That solves a real problem.

Without a baseline mechanism, every new account risks arriving without required roles, logging, Config recording, access configuration, governance policy or central evidence paths.

Landing Zone 4.0 makes the baseline model less monolithic.

ConfigBaseline can establish the narrower Config resources needed for detective controls without the complete AWSControlTowerBaseline. Central functions are represented through separate baselines, including:

• CentralConfigBaseline;
• CentralSecurityRolesBaseline;
• LogArchiveBaseline;
• IdentityCenterBaseline.

The baseline resources are versioned. Landing-zone or OU baseline changes may require updates, re-registration or account-update workflows.

That creates work.

It also makes the work visible and gives it a supported lifecycle.

See Types of baselines and the Landing Zone 4.0 migration guide.

Specific governance drift becomes a first-class concern

A landing zone begins compliant.

Humans and automation then interact with it.

Someone may edit or detach a managed policy, move an account, disable trusted access, remove a required role or create inheritance differences between an OU and its accounts.

Control Tower detects defined classes of governance drift, including:

• OU and account governance drift;
• control-policy drift;
• trusted-access and required-role drift;
• enabled-control inheritance drift;
• enabled-baseline inheritance drift.

The resulting model is:

EXPECTED GOVERNANCE STATE
          │
          ▼
ACTUAL ORGANISATION STATE
          │
          ▼
SUPPORTED DRIFT DETECTION
          │
          ├── no drift
          └── remediation workflow

Drift detection does not mean every deviation heals itself automatically. Administrators may need to reset a control or baseline, re-register an OU, update an account or repair the landing zone.

It is also not a comprehensive state reconciler.

Control Tower does not generally inspect drift in associated services such as CloudTrail, CloudWatch, IAM Identity Center, CloudFormation or AWS Config. It does not detect arbitrary resource changes inside a baseline.

A complete operating model still needs:

• CloudFormation or IaC drift detection;
• AWS Config resource assessment;
• periodic reconciliation;
• alerts for critical service changes.

Control Tower makes important governance deviations visible. It does not replace every other form of configuration assurance.

See Types of governance drift.

Account Factory solves repeated account vending

A growing organisation should not provision accounts through improvised emails and hand-entered console steps.

A new account normally needs:

• a unique email address;
• OU placement;
• workforce access;
• standard tags;
• security roles;
• logging;
• budgets;
• platform integration;
• ownership metadata.

Control Tower Account Factory provides a supported account-provisioning workflow. Accounts are provisioned into governed OUs and receive the corresponding baselines and controls.

Account Factory Customization can apply a CloudFormation or Terraform-backed Service Catalog blueprint during provisioning or enrolment.

ACCOUNT REQUEST
      │
      ▼
VALIDATED PARAMETERS
      │
      ▼
ACCOUNT FACTORY
      │
      ▼
GOVERNED AWS ACCOUNT
      │
      ▼
CUSTOM BLUEPRINT
      │
      ▼
READY FOR TEAM USE

AWS Organizations can create an account.

Account Factory’s value is delivering one that already belongs to the organisation’s operating model.

The full Account Factory, Service Catalog, AFT and AFC paths depend on the Landing Zone 4.0 AWS Config integration. Without it, AWS points to a lighter workflow based on Organizations and auto-enrolment.

See Account Factory and the Config integration comparison.

AFT adds a Terraform and GitOps workflow

Account Factory for Terraform, usually shortened to AFT, adds a Terraform-oriented account-provisioning and customization workflow around Control Tower.

AFT supports account requests through Git, stores account metadata and audit history, and runs global or account-specific customizations through Terraform, Python, Bash and AWS CLI stages.

GIT ACCOUNT REQUEST
        │
        ▼
AFT PROVISIONING PIPELINE
        │
        ▼
CONTROL TOWER ACCOUNT FACTORY
        │
        ▼
NEW ACCOUNT
        │
        ▼
GLOBAL AND ACCOUNT
CUSTOMISATIONS

AFT requires an existing Control Tower landing zone and deploys into a separate AFT management account. It is intended for account provisioning and customization, not as the general deployment system for application infrastructure.

AFT itself has no separate service fee, but the infrastructure it deploys incurs AWS charges.

For a company vending many accounts, it may be a sensible platform component.

For bfstore’s current account count and learning objectives, it would have introduced another provisioning control plane before the repeated journey had justified it.

See Account Factory for Terraform.

What Control Tower solves well

Control Tower is particularly strong when an organisation needs several capabilities together:

• a supported starting point for a governed multi-account environment;
• consistent account onboarding through Account Factory or AFT;
• a broad catalogue of AWS-managed controls;
• account, OU, baseline, control and drift status;
• staged adoption into an existing AWS Organization;
• optional auto-enrolment when accounts move into governed OUs;
• control mappings that support wider compliance programmes;
• an account and control lifecycle that can scale across teams.

None of these are small benefits.

Control Tower solves real platform work.

What Control Tower does not solve

A Control Tower landing zone is governed infrastructure.

It is not a complete cloud platform.

It does not decide bfstore’s:

• business domains;
• Kubernetes architecture;
• database ownership;
• Kafka topology;
• application identity model;
• network segmentation;
• SLOs;
• backup strategy;
• observability backend;
• deployment model;
• incident response;
• cost allocation;
• multi-cloud architecture.

It also does not remove the need to understand AWS permissions.

A preventive control implemented with an SCP still does not grant an IAM permission.

A detective control still requires someone to interpret and remediate the finding.

A compliant AWS Config rule does not prove the application is secure.

A vended account does not prove the workload belongs in that account.

CONTROL TOWER

governs the landing-zone machinery


PLATFORM ARCHITECTURE

decides how teams build and operate


APPLICATION ARCHITECTURE

decides how bfstore behaves

Control Tower shortens the first journey.

It does not complete the other two.

Why I chose not to use it for bfstore

The decision came from six project-specific considerations.

1. The landing zone is part of the curriculum

bfstore is not only an ecommerce system.

It is also a deliberately inspectable cloud-engineering project.

I wanted to understand and document:

• why each OU exists;
• why each account exists;
• how SCP inheritance works;
• how IAM Identity Center assignments work;
• how CloudTrail is centralised;
• how AWS Config should be organised;
• how delegated administration works;
• which responsibilities belong in the management account;
• how policies fail;
• how they are tested;
• how emergency access interacts with governance.

Control Tower would still require knowledge of those subjects.

It would also make several of their initial implementations arrive as managed baseline resources.

For an enterprise trying to reduce setup work, that is an advantage.

For a learning project trying to expose the setup work, it is a layer of smoked glass.

I did not merely want the answer. I wanted the workings in the margin.

2. The organisation structure was already deliberately designed

bfstore’s structure is not a generic Security, Sandbox and Workloads arrangement.

The organisation separates concerns across OUs and accounts including:

• management;
• security tooling;
• log archive;
• identity;
• network;
• shared services;
• observability;
• backup;
• development;
• staging;
• production;
• sandbox;
• policy testing.

The design is based on:

• failure boundaries;
• policy boundaries;
• operational ownership;
• data flows;
• recovery responsibilities;
• independent platform projects.

Control Tower 4.0 now supports customer-defined organisational structures, so the mere existence of this structure is no longer a strong argument against adopting the service.

The relevant point is sequence.

The structure, accounts, identity assignments and initial policies were already being built deliberately.

Introducing a complete landing zone would have required deciding which existing resources should become Control Tower-managed, which OUs should be registered and how current logging and identity choices should be reconciled with the selected baseline.

That migration would have added product work without addressing an immediate bfstore problem.

3. I wanted a policy-testing laboratory

bfstore has a dedicated bfstore-policy-test account.

Its purpose is to test:

• SCP allow and deny behaviour;
• RCP behaviour;
• policy inheritance;
• exceptions;
• policy syntax;
• service interactions;
• expected and unexpected denial paths.

The desired workflow is:

WRITE POLICY
     │
     ▼
STATIC VALIDATION
     │
     ▼
POLICY-TEST OU OR ACCOUNT
     │
     ▼
POSITIVE TESTS
     │
     ▼
NEGATIVE TESTS
     │
     ▼
EVIDENCE
     │
     ▼
PROMOTE TO REAL OUs

Control Tower provides managed controls whose implementations are already tested and supported by AWS.

That is useful.

It is not the same learning exercise as constructing a custom policy, predicting its evaluation and proving its effect through an explicit harness.

bfstore needs both concepts:

• awareness of AWS-managed controls;
• practical competence building and testing bespoke controls.

The dedicated policy-test account places the second objective in the foreground.

4. Account vending is not yet the bottleneck

Account Factory becomes especially valuable when account creation is repeated frequently.

bfstore currently has a known, finite set of accounts with deliberately assigned purposes.

It is not yet serving:

• dozens of product teams;
• frequent project onboarding;
• temporary account fleets;
• departmental account requests;
• customer-specific environments.

A full account-vending platform would therefore optimise work that is currently infrequent.

The account lifecycle still needs documentation and automation.

It does not yet need a large self-service factory.

This may change later.

A platform should be introduced when its repeated journey exists, not because its architecture diagram is handsome.

5. bfstore already has an infrastructure control-plane direction

bfstore selected:

• OpenTofu-compatible infrastructure;
• TerraKube for infrastructure delivery and governance;
• GitHub Actions;
• reusable cloud modules;
• a private module-registry path;
• later Crossplane capabilities.

AFT supports Terraform and GitOps-style account requests, so it is not philosophically opposed to this stack.

It would still introduce:

• an AFT management account;
• AFT pipelines;
• Service Catalog relationships;
• AFT-specific account metadata;
• customization repositories;
• another lifecycle to upgrade and observe.

That might be justified when AFT owns a large account-vending workload.

It would be excessive while bfstore is still establishing its broader infrastructure-delivery model.

I prefer one visible control plane for each responsibility.

ACCOUNT GOVERNANCE

currently:
explicit organisation and IaC workflow


INFRASTRUCTURE DELIVERY

TerraKube and OpenTofu direction


WORKLOAD DELIVERY

GitHub Actions and Kubernetes tooling

Adding AFT now would create another governance engine before bfstore had enough account churn to feed it.

6. The project needs cloud-neutral reasoning

bfstore is being implemented in this order:

AWS
 │
 ▼
AZURE
 │
 ▼
GCP
 │
 ▼
MULTI-CLOUD CAPSTONE

The objective is not to make all three providers identical.

Provider-native services should be used where they offer real value.

The objective is to understand the underlying pattern clearly enough to recognise its equivalents and differences elsewhere.

Building the AWS landing zone from primitives makes the pattern visible:

ORGANISATION HIERARCHY

ACCOUNT OR SUBSCRIPTION BOUNDARIES

CENTRAL IDENTITY

PREVENTIVE POLICY

DETECTIVE POLICY

CENTRAL LOGGING

ACCOUNT VENDING

DRIFT MANAGEMENT

Control Tower could still be documented and compared.

It simply would not be the machinery through which I first learned the pattern.

Manual does not mean unmanaged

The alternative to Control Tower is not:

Click around the management account
until the organisation looks convincing.

bfstore’s alternative is an explicitly engineered landing zone.

It should include:

• infrastructure as code;
• version-controlled policies;
• policy tests;
• documented account ownership;
• centralised CloudTrail;
• AWS Config design;
• IAM Identity Center;
• delegated administrators;
• account bootstrap procedures;
• drift detection;
• runbooks;
• evidence.

The difference is ownership.

CONTROL TOWER MODEL

AWS manages landing-zone
baselines and control lifecycle


BFSTORE MODEL

bfstore defines, tests and operates
those mechanisms directly

A custom landing zone must reproduce the operational discipline Control Tower would otherwise help provide.

Declining the service does not decline the problem.

It accepts more of it.

What bfstore built instead

The bfstore organisation begins with explicit account boundaries.

BFSTORE MANAGEMENT
        │
        ├── Security
        │   ├── security-tooling
        │   └── emergency-access
        │
        ├── Logging
        │   └── log-archive
        │
        ├── Identity
        │   └── identity
        │
        ├── Network
        │   └── network
        │
        ├── Shared Services
        │   └── shared-services
        │
        ├── Observability
        │   └── observability
        │
        ├── Backup
        │   └── backup
        │
        ├── Workloads
        │   ├── dev
        │   ├── staging
        │   └── prod
        │
        ├── Sandbox
        │   └── sandbox
        │
        └── Policy Test
            └── policy-test

The account names are less important than their responsibilities.

AWS Organizations

Owns:

• hierarchy;
• account membership;
• SCPs;
• RCPs;
• delegated-service access;
• consolidated billing.

IAM Identity Center

Owns:

• workforce sign-in;
• permission sets;
• group assignments;
• temporary account access.

Log archive

Owns:

• organisation CloudTrail;
• selected AWS Config evidence;
• immutable or tightly controlled central logs;
• long-term security evidence.

Security tooling

Owns:

• delegated security services;
• organisation-wide findings;
• security operations;
• investigation access.

Policy test

Owns:

• policy validation;
• expected-denial tests;
• expected-success tests;
• policy evidence before promotion.

Infrastructure repositories

Own:

• policy source;
• OU and account definitions;
• baseline modules;
• deployment workflows;
• change history.

This is not automatically better than Control Tower.

It is more educational and more directly aligned with bfstore’s current purpose.

The costs I accepted

Choosing not to use Control Tower creates work.

bfstore must:

• maintain the account baseline, including roles, logging, access, tags and policies;
• detect drift through AWS Config, CloudTrail, EventBridge, IaC plans and reconciliation;
• place, bootstrap and verify every new account;
• maintain custom SCPs, RCPs, Config rules and other controls as AWS changes;
• build governance reporting rather than receive a consolidated Control Tower view;
• test module, service and policy changes without a Control Tower landing-zone upgrade workflow;
• prove that every account received the intended baseline.

These are not footnotes.

They are the invoice for owning the machinery.

Control Tower is free, its ingredients are not

AWS does not charge an additional fee for Control Tower itself.

Customers pay for the services and resources it enables, including CloudTrail, Config, CloudWatch, Service Catalog and associated storage or processing.

The same is true of a custom landing zone.

Avoiding Control Tower does not avoid the cost of organisation trails, Config evaluations, log storage, security services, automation or engineering time.

CONTROL TOWER COST

underlying AWS services
+
managed design constraints


CUSTOM LANDING-ZONE COST

underlying AWS services
+
engineering and operational ownership

The cheaper option depends on scale, requirements and the value assigned to engineering time.

For bfstore, some of that engineering time is part of the project’s educational output. In a commercial platform team, it would be judged more sternly.

Where I would choose Control Tower

I would strongly consider Control Tower when:

• the organisation is beginning its multi-account journey and needs a supported baseline quickly;
• accounts are created regularly enough for Account Factory or AFT to become a platform product;
• a small cloud team benefits from AWS owning more of the baseline lifecycle;
• managed control definitions and compliance mappings remove meaningful repeated work;
• governance drift is already difficult to see and repair;
• AWS is the organisation’s primary cloud;
• several teams need consistent account and control workflows;
• the company wants AWS support around the landing-zone product.

Control Tower is not an admission that the platform team lacks skill.

It may be evidence that the team is applying its skill to the business-specific layers where differentiation matters.

Landing Zone 4.0 makes future adoption easier

The choice is not permanently binary.

Landing Zone 4.0 supports a controls-focused environment for organisations that already have an AWS Organizations structure and primarily want managed controls. It no longer requires every customer to adopt the complete earlier landing-zone shape.

That gives bfstore several future paths:

• keep managing the custom landing zone;
• use the Control Catalog for research and mapping;
• adopt a controls-focused environment on selected OUs;
• register suitable OUs under fuller governance;
• introduce Account Factory or AFT when account demand justifies it.

Architecture decisions should be revisited when their assumptions change.

See the Landing Zone 4.0 migration guide.

My decision record

The bfstore decision can be expressed compactly.

decision:
  service: AWS Control Tower
  outcome: not-adopted-for-initial-landing-zone

context:
  - organisation and accounts designed explicitly
  - project requires deep AWS governance learning
  - account creation frequency is currently low
  - custom policy-test workflow is a primary objective
  - OpenTofu and TerraKube form the infrastructure direction
  - existing identity and account setup is already in progress
  - AWS will later be compared with Azure and GCP

benefits_declined:
  - managed landing-zone baseline
  - Account Factory
  - managed drift workflows
  - consolidated governance dashboard
  - managed control lifecycle

responsibilities_accepted:
  - account bootstrap
  - policy implementation
  - policy testing
  - drift detection
  - governance reporting
  - baseline upgrades
  - account lifecycle automation

revisit_when:
  - account vending becomes frequent
  - team count grows
  - compliance-control mappings become operationally important
  - custom baseline maintenance becomes disproportionate
  - controls-focused adoption offers clear value

That is more precise than:

We prefer doing things ourselves.

Preferences are not architecture.

Trade-offs are.

The mental model I am keeping

My earlier model was:

AWS CONTROL TOWER

automatic AWS organisation


NO CONTROL TOWER

manual AWS organisation

The stronger model is:

                 GOVERNED MULTI-ACCOUNT FOUNDATION
                              │
              ┌───────────────┴───────────────┐
              │                               │
              ▼                               ▼
       AWS CONTROL TOWER              CUSTOM LANDING ZONE
              │                               │
              ▼                               ▼
      AWS-MANAGED BASELINES          CUSTOMER-MANAGED BASELINES
      MANAGED CONTROLS               CUSTOM CONTROLS
      ACCOUNT FACTORY                CUSTOM ACCOUNT WORKFLOW
      GOVERNANCE DRIFT STATUS        CUSTOM RECONCILIATION

AWS Organizations defines the hierarchy.

Control Tower assembles and operates a managed governance layer around it.

A custom landing zone accepts direct ownership of the same governance responsibilities.

I did not reject Control Tower because it hides poor engineering. I declined it because it successfully hides engineering that this project exists to learn.

For bfstore today, the custom route remains intentional.

Control Tower stays in the architectural catalogue, understood rather than dismissed. The service solves a real problem. I have chosen, for now, to keep that problem where I can see its gears.

References and further reading

• What is AWS Control Tower?
• Landing Zone 4.0 migration guide
• Feature comparison with and without AWS Config integration
• About AWS Control Tower controls
• Control behaviour and guidance
• Nested OUs and control inheritance
• The AWS Control Tower Control Catalog
• Types of baselines
• Types of governance drift
• Account Factory
• Account Factory for Terraform
• AWS Control Tower pricing