Sai Dilip
← Back to portfolio

Field notes · Multi-Account AWS Architecture

How I think about designing a multi-account AWS Organization

A landing-zone approach shaped by 8+ years of enterprise AWS work — the account structure, the identity model, the security backbone, and the environments I'd stand up if I were starting from zero. Read it as a reference checklist, or as the story of how I actually arrived at it.

Starting point

Multi-account AWS architecture takes real discipline. Most environments evolve this way — a single account at first, growing account-by-account as the need shows up. But if I were starting a brand-new AWS Organization today, here's the core structure I'd put in place from day one.

01Organizations & account structure

  • Stand up AWS Organizations from the management account to define the account structure.
  • Create accounts and organizational units (OUs) around how the business actually separates workloads and risk.
  • Apply Service Control Policies (SCPs) at the OU level as the outer guardrail.
  • Use Control Tower to automate the landing-zone rollout — governance, security baselines, and org-wide policy in one pass.

02Identity & access

  • Use IAM Identity Center as the single point for users and groups — create groups first, then assign users to them.
  • Build permission sets per account and assign each one to a group, so access stays legible at a glance.
  • Decide early how AWS identity maps to your company's existing identity system. If an Active Directory already exists, domain-join Identity Center to it.
  • That domain join matters more than it looks: when someone leaves the company, their AWS access is revoked automatically along with everything else — no orphaned IAM users to chase down.

03Security architecture

Log Archive & Audit accounts

Control Tower requires both — set them up as part of the initial landing zone, not as an afterthought.

Security account (delegated administrator)

Assign it as delegated admin for Security Hub, GuardDuty, and Inspector. GuardDuty covers threat detection (including DDoS patterns); Inspector scans Lambda, EC2, and containers org-wide. This account becomes the single pane of glass — logs from every account centralize here.

AWS Config + conformance packs

Enable AWS Config org-wide and deploy conformance packs — bundles of Config rules — out to every account from the Security account. Beyond the compliance-drift detection, the resource inventory Config builds turned out to be genuinely useful for cost visibility: it made it much easier to spot and alert on billing anomalies, because you already have a live, per-account record of what resources actually exist and when they changed.

  • Turn on the Security Hub frameworks that actually match the business — that's what gives you a real compliance score against the standards that matter, not a generic one.
  • Enable Trusted Advisor.
  • Route logs and metrics through CloudWatch, then build incident management and alerting on top of that centralized view.

04Environment structure

Four environments, minimum: Sandbox, Development, UAT, Production. Terraform, CloudFormation, and CI/CD pipelines (GitHub Actions or similar) map infrastructure-as-code deployments to each one, so promotion between environments is a pipeline decision, not a manual one.

05Design for where you're headed, not just where you are

This is the lesson that cost the most to learn: build for the architecture you'll need in a year, not only the environment in front of you right now.

  • Shared infrastructure — a network firewall, core networking, shared services — usually doesn't need to be duplicated per environment. A dedicated Shared Services / Networking account avoids that duplication and the cost that comes with it.
  • The same logic applies to identity infrastructure: one Active Directory service can typically support both Dev and Prod. You don't need two.
  • The pattern to watch for: if a service would be identical in Dev and Prod, it probably belongs in a shared account, not copied twice.
In short

Organizations for account structure and SCPs, Identity Center for identity and permissions, a Security account as delegated admin running Security Hub, GuardDuty, Inspector, and AWS Config conformance packs for org-wide visibility, four environments wired to IaC pipelines, and a Shared Services account so you're not paying twice for the things every environment needs.

Multi-account AWS architecture takes a lot of discipline, and honestly, I don't think anyone arrives at a good version of it on the first try. In my experience it's an evolution — you start small, with one account doing everything, and you build out from there as the need shows up. But if you asked me today, cold, to start a brand-new AWS Organization from zero, I already know exactly where I'd begin.

I'd start with AWS Organizations, run from the management account, to set the account structure — creating accounts, building out OUs, and putting Service Control Policies in place. Alongside that I'd bring in Control Tower to automate the rollout of governance and security policy across the org, so it's not something every team reinvents by hand.

Permission sets come next, and I'll be honest — early on I wasn't even sure which service owned that piece, Organizations or Identity Center. It's Identity Center. That's where I'd create users and groups, and I've learned to always do groups first, then assign users into them. Then I build permission sets per account and attach each one to a group, so every group stays cleanly maintained instead of turning into an unmanaged pile of one-off grants.

Then there's the question of how your AWS users actually plug into the rest of the company. Say you already have eighty employees with an identity system in place — you don't want to manage AWS access as a separate universe. I'd stand up an AD server and domain-join IAM Identity Center to it.

That domain join is the detail that matters most: when someone leaves the company, their AWS access disappears automatically with everything else. No stray IAM user quietly sitting around with access nobody remembers granting.

That covers accounts and identity — Organizations for the structure, SCPs enabled as the guardrail, Identity Center for permissions. Now comes the part I actually enjoy most: security.

Building the security backbone

Control Tower requires a Log Archive account and an Audit account, so those get created as part of the initial build, not bolted on later. Third, I always create a dedicated Security account, and I use it as the delegated administrator for the security services across the whole org — Inspector, Security Hub, GuardDuty.

GuardDuty is what I lean on to catch things like DDoS activity. Inspector scans everything — Lambda functions, EC2 instances, containers — across every account in the organization, so I get one consolidated view instead of checking account by account. That Security account also becomes my operational home base: it pulls logs from every account so I can work from one centralized place instead of hopping between them.

One I almost left out, and shouldn't have: AWS Config, with conformance packs deployed out to every account from that same Security account. I built those packs to catch compliance drift — a rule silently disabled, a resource that fell out of policy — but the side benefit surprised me. Config keeps a live inventory of every resource in every account, and that inventory turned out to be one of the best signals I had for catching billing anomalies early. If something unexpected spins up, you're not waiting for it to show up on a bill three weeks later — the resource record and the alert are already there.

Inside Security Hub, I turn on the frameworks that actually fit the business and the organization — that's what gives you a real compliance score against standards that matter to you, not a generic checklist. I turn on Trusted Advisor too. And with CloudWatch pulling in logs and metrics from everywhere, you finally have enough visibility to build real incident management and alerting on top of it.

Environments, and the mistake I don't want to repeat

I'd always stand up Sandbox, Dev, UAT, and Production. That's where Terraform, CloudFormation, GitHub, and CI/CD come in — infrastructure as code that knows exactly which environment it's supposed to land in.

But here's the part I'd tell my earlier self, straight from experience: think past what you're building right now. On one project, we built everything with Dev in mind and only Dev — and it worked, until Production showed up and we realized we needed to retrofit shared infrastructure we should have planned for from the start.

Looking back, it made far more sense to share one resource across Dev and Prod than to duplicate it — a network firewall, a networking diagram, a piece of shared infrastructure. One Shared Services or Networking account instead of paying twice.

The same logic carries over to identity infrastructure. You probably don't need a separate Active Directory for Dev and a separate one for Prod — one AD service can support both. The pattern I watch for now, on every new build: if a piece of infrastructure would end up identical in Dev and Prod, that's my signal it belongs in a shared account from the start, not copied twice and reconciled later.

What I'd tell someone starting from scratch

Organize accounts with Organizations and SCPs. Manage identity with IAM Identity Center, and domain-join it to your existing directory if you have one. Centralize security in a dedicated Security account acting as delegated admin, with Security Hub, GuardDuty, Inspector, and Trusted Advisor all feeding it. Stand up four environments wired to infrastructure as code. And before you build anything, ask which pieces are going to be identical across every environment — because those belong in a shared account from day one, not retrofitted after Production forces the question.