Running AWS Control Tower without a platform team

You read the prescriptive guidance, clicked through the setup, and stood up an AWS Control Tower landing zone before lunch. The mandatory controls switched on. A few accounts moved into organizational units that finally matched how the company is built: production over here, the sandbox where engineers break things over there. The dashboard showed green. You closed the laptop feeling like you had just done the work of a platform team without being one.

Then the next quarter happened. An engineer needed a one-off permission to ship a deadline feature, so someone widened a policy and meant to revert it. A new account got vended for a vendor integration, then drifted off the baseline because nobody enrolled it the same way. A detective control flagged the same thing every week, into a channel that scrolls.

None of this is a Control Tower failure. The setup did exactly what it promised. The question Control Tower never answers for you is the one that decides whether any of it still means something in six months: who runs it on the quiet weeks. That is what this is about, and the answer is not a platform org you cannot staff.

Control Tower is good at the part it owns. AWS describes it as a way to set up and govern a multi-account environment, orchestrating AWS Organizations, AWS Service Catalog, and IAM Identity Center to build a landing zone, then applying controls (sometimes called guardrails) to keep your accounts from drifting away from best practices (AWS Control Tower documentation). It vends new accounts from a template through Account Factory and gives central administrators a dashboard to watch the whole estate.

Read that list again and notice what every item assumes: a person on the other end. The same documentation describes three kinds of controls, preventive, detective, and proactive, and three categories of guidance, mandatory, strongly recommended, and elective (AWS Control Tower documentation). Picking which strongly recommended controls you enforce is a judgment call. A detective control reports non-conformance; it does not decide whether the non-conforming thing is an emergency or a Tuesday. Account Factory standardizes provisioning only if someone insists every new account goes through it.

The setup is the tool doing its job. The governance is the operating that happens after, and Control Tower hands that part to you.

Here is where small teams quietly lose the thread. AWS has a specific word for the failure mode: drift, the divergence from your intended baseline that accumulates as people make changes directly in the accounts (AWS documents drift detection in Control Tower). Control Tower can detect a lot of it. Detecting is not the same as deciding, and it is nowhere near the same as fixing.

The drift is rarely dramatic. It looks like the ordinary friction of a growing company:

• A policy widened for one deadline and never narrowed back, because the person who widened it is now three sprints deep in something else.
• An account created outside Account Factory during a rushed integration, so it never inherited the baseline everything else has.
• An elective control everyone agreed to "turn on later," where later never arrived and no one is sure who owned the decision.

Each of these is small. None of them pages anyone. They add up into an environment where the dashboard is still green for the things it checks and increasingly wrong about the thing you care about, which is whether your accounts still behave the way you decided they should.

A guardrail you set and stopped tending is not governance. It is a snapshot of an intention you had one afternoon.

The reframe that gets a small team unstuck is the same one that applies to most of the AWS stack. You are not missing the platform layer. Control Tower is the platform layer, and you already turned it on. What a dedicated platform team provides is not a tool you lack. It is a standing habit: someone reviews drift on a schedule, decides what to remediate and what to accept, keeps the control baseline matched to how the company runs today, and makes sure every new account goes through the front door, not around it.

That work does not need a platform org. It needs an owner and a cadence. Concretely, governing Control Tower on a small team comes down to a handful of recurring jobs:

• Review drift on a rhythm, not on luck. Someone looks at what diverged since last time and decides, account by account, what gets pulled back to baseline and what is a legitimate exception worth recording.
• Keep the baseline honest. As the company changes, the set of enforced controls changes with it. A baseline that fits the company at 15 people will quietly stop fitting at 60.
• Hold the front door. Every new account goes through Account Factory with the same controls, so the estate stays uniform and stops accumulating snowflakes.
• Leave a record. What drifted, what you decided, and why, written down where your next auditor or enterprise buyer can read it without booking a meeting.

This is the part we run inside accounts that already have Control Tower set up. The customer keeps the AWS-native design they chose. We supply the standing operation Control Tower was never going to supply on its own: the human reviewing drift, tuning the baseline, and recording the decisions, on the quiet weeks as much as the loud ones.

The honest caveat: if you are running hundreds of accounts with bespoke landing zone customizations and a roadmap that needs full-time platform engineering, build that team. Operating coverage is for the long stretch where you have the platform, you need it governed well, and you cannot yet justify a department to do it.

Go back to that afternoon when the dashboard went green and you felt like a platform team of one. You were right that the setup was a one-person job. The misread almost every small team makes is assuming the governing would be a one-time job too.

Control Tower gives you the guardrails. It does not give you the discipline to keep them meaningful as the company changes underneath them, because that was never a feature it could ship. That part is people doing a small thing reliably: reviewing drift, deciding, recording, repeating. A small team can have that without a platform org. It has to decide, on purpose, who owns it.

So here is the question worth carrying into next quarter, before the policy gets widened for the next deadline: when your landing zone drifts, and it will, who notices, who decides, and where does the decision get written down?