An account gets moved from Workloads_Test to Workloads_Prod, the way it should when a workload graduates. Nothing about the move itself is visible from the outside: the account still runs, the applications inside it don’t notice a thing. What doesn’t necessarily happen, at least not until a recent AWS update, is the account automatically picking up the customizations that Prod is supposed to enforce. It just sits there, moved but not fully reconfigured, until someone runs an audit or a security review turns up a production account missing something every other production account has. That’s drift, and it’s the quiet kind: nothing broke, nothing alerted, the account is just no longer what it’s supposed to be.

This is the last post in the series. Part 1 covered the foundational decision between Control Tower, LZA, AFT, or custom, and the account structure underneath it. Part 2 covered the guardrails and identity layer. Part 3 covered the network. This one is about keeping the whole thing running once it’s live: account vending at real scale, why Control Tower detects drift automatically but doesn’t fix it for you, and the pipeline that should sit between a proposed change and a real account.

Account vending once you’re past the first dozen accounts

Account Factory, Control Tower’s built-in vending machine, is fine for an organization provisioning a handful of accounts a year through a small central team. It gets uncomfortable once account creation needs to be self-service for multiple teams, each with slightly different customization needs, at a pace of dozens a month. That’s the gap Account Factory for Terraform fills, covered in more detail in Part 1: a Terraform file describing the account request, a git push, and a pipeline that provisions the account and then runs both global customizations, everything every account gets, and account-specific ones.

The OU-move problem in the opening above was a real, specific gap. Until a July 2026 update, moving an AFT-managed account between OUs didn’t automatically re-run its customizations, so an account that changed environments could sit there missing whatever configuration its new OU expected until someone manually triggered a re-run. AFT can now do this automatically, opted in through a single configuration flag, and the fix specifically skips the bootstrap and provisioning phases on re-application so it only redoes the customization work, not the whole account setup. It’s a small operational detail, but it’s exactly the kind of gap that turns into a finding six months after nobody was looking.

There’s also a built-in rehearsal space worth using deliberately: AWS’s own recommended OU structure includes a PolicyStaging OU specifically for testing changes to controls and policies before applying them everywhere else. If you’re vending accounts fast enough that a bad guardrail could hit a dozen new accounts before anyone notices, that OU stops being optional.

Drift: detected automatically, fixed manually

Control Tower detects drift on its own, continuously, using read-only calls against AWS Organizations that show up as ordinary CloudTrail events. When it finds something, a moved account, a modified SCP, a changed baseline, it publishes a notification through SNS, aggregated into the Audit account, exactly the kind of thing worth subscribing a real person or a real automation to rather than letting it sit unread in a console tab.

What Control Tower doesn’t do by default is fix what it finds. Resolving drift is a manual step in almost every case: Reset from the landing zone settings page, Re-register an OU, or calling ResetEnabledControl and ResetEnabledBaseline directly against the API. The one exception is inheritance drift from an account moving between OUs, which you can now hand off to auto-enrollment so Control Tower fixes it the moment it happens rather than waiting for someone to notice and click Repair.

The Security OU lockout from Part 2 is the sharpest version of this. If a managed SCP on that OU gets modified, detached, or deleted, Control Tower will tell you plainly that the Log Archive and Audit accounts may no longer be functioning correctly, and it will refuse to let you view or manage the landing zone until the problem is fixed, explicitly warning against provisioning new accounts in the meantime. It’s one of the few places in AWS where the platform locks the door rather than just logging a warning, which is a reasonable design given what’s actually at stake if logging silently stops working across an entire organization.

The mechanics look like this:

The detection side of this is solid out of the box. The gap almost every team eventually hits is remediation: automatic detection creates an assumption of automatic fixing that isn’t actually true, and the first time that gap matters is usually during an incident, not during a calm afternoon of reading documentation.

Testing changes before they reach a real account

Every SCP, RCP, and control from Part 2 is code, or should be, living in a repository with the same PR review and testing discipline as application code. AWS’s own guidance on this treats policy as code as a first-class governance pillar: version it, review it, and, critically, test it before it touches an actual account.

For a long time, testing an SCP before deploying it meant either reasoning about it by hand or standing up a throwaway account to try it against, because the IAM Policy Simulator explicitly didn’t evaluate SCPs, only identity and resource policies. That changed very recently: the simulator moved into the IAM console itself and picked up the ability to simulate SCPs as part of the evaluation, including how they interact with identity and resource policies and with condition keys like Region restrictions. That’s a real gap closing, not a minor UI refresh, and it changes what a reasonable pre-merge check looks like for a landing zone repository. Pair it with AWS CloudFormation Guard for the infrastructure-as-code side, validating templates locally before they ever reach a pipeline, and route the whole thing through the PolicyStaging OU mentioned earlier as the last rehearsal before a change reaches production OUs.

As a pipeline, that’s:

None of this is complicated engineering. It’s the same discipline any team already applies to application code, applied to the policies that happen to control blast radius across an entire organization instead of one service.

Closing out the series

Four posts back, the starting problem was account sprawl outrunning anyone’s ability to track it by hand. The path through that turned out to be less about picking the fanciest tool and more about sequencing: get the account and OU shape right before it’s expensive to change, decide deliberately between Control Tower alone, Control Tower plus LZA, or Control Tower plus AFT based on an actual forcing function rather than which one sounds more sophisticated, put SCPs and RCPs to work as the enforcement layer with logging that survives an audit, plan the network and the CIDR space before account one exists, and then treat the whole thing, guardrails included, as code that gets tested before it ships.

None of these four posts describe an exotic architecture. They describe the boring, well-worn version of a landing zone that AWS itself keeps refining, quietly, a few percentage points at a time: RCP coverage expanding, the policy simulator finally learning to test SCPs, AFT closing a drift gap that existed for years. Building one isn’t really the hard part. Keeping up with how the primitives underneath it keep changing is the part that actually takes ongoing attention, which is as good a reason as any to revisit this series in a year and see how much of it is already out of date.