Standing Up a Multi-Account Landing Zone Before Any Workload Ships

At Digitspot, before any client workload gets deployed, the recurring first conversation is which account it runs in and who can see it. A landing zone answers that question once, in writing, instead of re-litigating it on every project.

Why six accounts, not one

The Security OU (Log Archive, Audit) is isolated from the Workload OU (Dev, Test, Prod) so a mistake in a dev account structurally cannot touch production logs or security tooling. That separation lives at the account boundary, not just in an IAM policy — because IAM policies can be misconfigured, but account boundaries are much harder to cross by accident.

Account Factory over manual account creation

AWS Service Catalog's Account Factory means every new account starts from the same baseline — network, logging, guardrails — instead of a checklist someone might skip under deadline pressure. It's the same instinct behind a Bash and Python script I wrote for a different engagement, which turned a 3-day manual infrastructure and data migration process into 5–10 minutes. A landing zone applies that same idea one layer up, before a single workload exists.

What CloudFormation StackSets buy you here

StackSets push the account baseline — guardrails, a logging role, an AWS Config aggregator — to every account in an OU automatically the moment a new account joins. A new Dev account is compliant on day one, not after a manual follow-up someone has to remember to do.

The part clients don't ask for but need

A landing zone is invisible when it's working, which is exactly why I write the account structure and the reasoning behind it into a Solution Design Document — so the next engineer, or the client's own team six months later, doesn't have to reverse-engineer why the accounts are shaped this way.

Governance you have to explain from memory isn't governance — it's a habit that leaves with the person who set it up.

Where this pattern earns its keep

Once the landing zone exists, every workload that follows — the multi-region EKS platform, the Cape Town serverless application — starts from a governed account instead of a blank AWS account with default settings. The landing zone isn't a separate project; it's what makes the rest of the portfolio possible.