If you set up an AWS Landing Zone in 2022 or 2023, the chances are you reached for AWS Control Tower, accepted most of the defaults, and shipped a few dozen accounts that looked clean on day one. Two years in, the same Landing Zone is starting to push back. Account creation slows. SCP changes feel risky. The shared services account has become a tar pit no team wants to touch. The honeymoon is over.
This is not a failure of Control Tower. It is a predictable inflection point. Control Tower is a sensible starting position for a Landing Zone — it gives you Organisations, a Log Archive, an Audit account, and a defensible baseline. What it does not give you is an operating model for what happens once you cross fifty accounts, half a dozen business units, and your first real audit. That is where most UK enterprises we work with run into trouble.
The first signs your Landing Zone is the constraint
The symptoms are consistent across regulated industries — financial services, public sector, healthcare — wherever multi-account is taken seriously. The platform team starts spending more time defending the Landing Zone than evolving it. New account requests sit in a queue behind a manual review. Security exceptions accumulate in a spreadsheet because there is no clean path to express them in code. Engineers route around the platform because the platform has stopped helping them ship.
If any of that sounds familiar, the problem is rarely Control Tower itself. It is that Control Tower was treated as the destination rather than the entry point.
Four failure modes we see again and again
Account Factory drift. Control Tower's Account Factory is fine for the first thirty or forty accounts. Beyond that, customisations accumulate. Someone adds a new VPC pattern for the data team. Someone else bolts on a guardrail for the trading platform. The blueprint forks quietly. Six months later nobody can describe what a "standard" account actually contains, and reconciliation becomes a manual job. We have seen platform teams burn entire sprints just trying to bring stray accounts back into compliance with a baseline that itself has drifted.
SCP sprawl with no policy testing. Service Control Policies are powerful and brittle in equal measure. A poorly scoped Deny on s3:PutBucketPolicy can break logging pipelines you forgot existed. Most organisations write SCPs in the console, attach them to OUs by hand, and discover the blast radius in production. There is no unit test, no policy simulation, no review process beyond "Bob looked at it." Once you have more than ten SCPs across multiple OUs, the combined policy surface is genuinely difficult to reason about.
The shared services tar pit. Every Landing Zone ends up with one or two accounts that everyone touches — networking, DNS, CI/CD runners, central observability. They start lean and end up as the most fragile, most contested, least documented part of the estate. Change windows pile up. Every team wants priority. Eventually the shared services account becomes the place where deployments go to die. The fix is not to add more change control. It is to redesign so that fewer things need to live there in the first place.
Log archive blast radius. The Log Archive account looks fine until your CloudTrail organisation trail is producing a few terabytes a month and you realise nobody has reviewed the retention or lifecycle policies since launch. We have walked into estates spending five-figure monthly sums on logs that nobody queries, because the original Landing Zone deployed a defensive default and the FinOps function never went back to revisit it. The same applies to GuardDuty findings, Config snapshots, and Access Analyzer output.
The patterns that actually scale
Treat account vending as a product, not a ticket. Once you have more than a handful of teams, account requests need to flow through a self-service interface with versioned templates, a clear ownership model, and policy-as-code guardrails. This is where Backstage and Crossplane earn their place. A developer raises a request, the platform composes the account from declared building blocks, and the Landing Zone configuration is generated rather than authored by hand. Account Factory becomes an implementation detail underneath, not the surface engineers interact with.
SCP-as-code with policy testing. SCPs belong in version control, with policy simulation in CI before merge. Tools like Conftest, OPA, and AWS's own policy validation APIs let you assert that a proposed SCP does not break legitimate workloads in a sandbox before it reaches production. This sounds obvious. It is rarely done. Without it, SCP changes are a roll of the dice — and the more SCPs you accumulate, the worse the odds.
Detective controls alongside preventive ones. Heavy reliance on Deny SCPs makes the platform brittle and forces engineers to route around it. A more durable pattern is preventive guardrails for the small set of things that are genuinely existential — root account use, region restrictions, public S3 — paired with detective controls in AWS Config, GuardDuty, and Security Hub for everything else. This shifts the conversation from "we blocked you" to "we noticed, here is what to do," which is the conversation engineers in regulated industries actually want to have.
Document the exceptions. Every regulated estate has them. The defence workload that needs a deliberate carve-out from the standard SCP. The healthcare account that runs in a specific region for data residency. Exceptions are not the problem; undocumented, unowned exceptions are. We have seen audits go badly purely because the platform team could not produce a paper trail for why a particular OU had a different guardrail set. Treat exceptions as first-class artefacts with an owner, a review date, and a written justification.
A pragmatic migration path
You do not need to rip out Control Tower. In almost every engagement we run, the right move is to keep Control Tower as the underlying mechanism for Organisations management and the defensive baseline, and layer a proper platform engineering capability on top of it. Account vending moves to a self-service portal. SCPs and AWS Config rules move into a Git repository with CI. The shared services account is decomposed into smaller, purpose-built accounts owned by individual teams.
That migration takes months, not weeks. It is most effective when run as a programme with senior engineering leadership embedded — not as a series of disconnected tickets thrown over to the platform squad. The estates that get stuck are usually the ones that tried to fix the Landing Zone with the same team that is also running the day-to-day platform. Without dedicated engineering capacity, the urgent always crowds out the important.
How Kineticor Can Help
Kineticor works with UK enterprises whose AWS Landing Zones have outgrown their original design. We bring senior engineers who have built and operated multi-account estates in regulated industries, alongside consulting judgement on what to fix first and what to leave alone. We do not parachute in a deck and disappear — we work inside your platform team, ship the patterns, and hand over a Landing Zone your engineers can actually evolve. If you are seeing the symptoms in this post, get in touch.
— Danish
Danish Muhammad
Founder, Kineticor
I help businesses achieve their vision by making the cloud work for them — efficiently, securely, and at scale. Beyond technical solutions, I focus on solving real-world challenges, aligning cloud strategy with business goals, and building high-performing teams. My background is technical delivery; my passion is solving people problems. Connect on LinkedIn.