Every cloud engagement I start begins the same way: before a single workload moves, we build the ground it will stand on. A landing zone is not a product you buy — it is a small set of opinionated decisions about accounts, networks, identity and guardrails that every later decision inherits. Get it right once and migrations feel boring. Get it wrong and every project pays interest forever.
Start with accounts, not VPCs
The most common mistake I see is a single production account holding everything. My baseline is five: management, security-tooling, logging, shared-network, and one workload account per environment per team grouping. Blast radius is a feature — an engineer with admin in dev should hold zero power over the ledger database.
- Management account holds nothing but the organization and SSO — no workloads, ever.
- Security-tooling hosts GuardDuty, Config aggregators and the break-glass pipeline.
- Logging is append-only; even platform admins cannot delete, only expire by policy.
- Workload accounts are stamped out by Terraform, never clicked into existence.
Networks follow the org chart
I segment with a hub-and-spoke model: shared services live in the hub, workloads in spokes, and every spoke-to-spoke call crosses an inspection point. It sounds strict until the first incident, when you can answer "what can reach the database?" in one query instead of three meetings.
Guardrails, not gates
Preventive controls (SCPs, policy-as-code) handle the non-negotiables — regions, encryption, no public buckets. Everything else is detective with a Slack alert and an owner. Teams move fast because the rules are code-reviewed, versioned, and explain themselves when they fire.
Deploy this foundation in week one and the migration in week six is just logistics. Skip it and week six is archaeology. I know which one I charge less for — and it's the boring one.
- Landing Zone
- AWS
- Terraform
- Governance
