[{"data":1,"prerenderedAt":183},["ShallowReactive",2],{"service-articles-en-aws-security-foundation":3},[4],{"id":5,"title":6,"body":7,"category":170,"date":171,"description":13,"extension":172,"meta":173,"navigation":174,"order":156,"path":175,"published":176,"seo":177,"service":178,"stem":179,"summary":180,"updated":181,"__hash__":182},"blog\u002Fen\u002Fblog\u002Faws-multi-account-terraform.md","Building a Secure AWS Multi-Account Structure with Terraform",{"type":8,"value":9,"toc":154},"minimark",[10,14,19,38,42,45,48,53,56,59,63,66,93,96,100,103,107,110,114,122,125,129,132,135,138,142,145],[11,12,13],"p",{},"Many companies run production, testing, and internal tools in a single AWS account. That works until one wrong permission or one compromised credential puts everything at risk at once. A clean account structure prevents exactly that, and Terraform keeps it manageable as it grows.",[15,16,18],"h2",{"id":17},"key-takeaways","Key takeaways",[20,21,22,26,29,32,35],"ul",{},[23,24,25],"li",{},"An account boundary isolates mistakes and attacks more strongly than an IAM policy alone can.",[23,27,28],{},"Four account types cover most real needs: management, security with log archive, shared services, and one workload account per environment.",[23,30,31],{},"Terraform modules with separate state per account keep the structure maintainable as it grows.",[23,33,34],{},"Changes to production accounts go through a reviewed pipeline only, never through a manual apply from a laptop.",[23,36,37],{},"Central, immutable logging in a dedicated account means a compromised account cannot erase its own evidence.",[15,39,41],{"id":40},"why-a-single-aws-account-is-not-enough","Why a single AWS account is not enough",[11,43,44],{},"Early on, it's tempting to run everything in a single AWS account and leave the separation to IAM policies and tags. I've moved away from that model every time, because an account boundary is a fundamentally stronger isolation primitive than a policy.",[11,46,47],{},"A misconfigured IAM policy or a compromised credential in a single-account setup has a blast radius that spans your entire footprint. Production, staging, and shared tooling all sit behind the same perimeter.",[49,50,52],"h3",{"id":51},"what-account-boundaries-give-you","What account boundaries give you",[11,54,55],{},"Split those workloads across separate accounts and a mistake in one environment simply can't reach another. There's no policy to misconfigure your way around a hard account boundary.",[11,57,58],{},"Two more benefits come with it. Least privilege becomes easier to reason about, because permissions are scoped to what an account contains instead of being enumerated resource by resource. And cost attribution becomes trivial: every euro in an account belongs to a known team or workload, without tagging discipline doing the heavy lifting.",[15,60,62],{"id":61},"a-pragmatic-aws-account-structure","A pragmatic AWS account structure",[11,64,65],{},"The structure I default to has four building blocks:",[20,67,68,75,81,87],{},[23,69,70,74],{},[71,72,73],"strong",{},"Management account"," at the root, purely for billing and organization-wide policy.",[23,76,77,80],{},[71,78,79],{},"Security and log-archive account",", which receives read-only copies of every other account's logs and holds no workloads of its own.",[23,82,83,86],{},[71,84,85],{},"Shared-services account"," for things like a container registry or CI runners that every environment needs but shouldn't own.",[23,88,89,92],{},[71,90,91],{},"Per-environment workload accounts"," (dev, staging, production), each isolated from the others.",[11,94,95],{},"This isn't exotic. The structure mirrors what AWS Organizations and AWS Control Tower expect anyway. It also keeps the mental model simple: if you can name the account, you know what's allowed to happen in it.",[15,97,99],{"id":98},"terraform-that-scales-with-your-account-structure","Terraform that scales with your account structure",[11,101,102],{},"None of this is manageable by hand once you have more than two or three accounts. So I express the entire structure in Terraform.",[49,104,106],{"id":105},"reusable-modules-and-separate-state","Reusable modules and separate state",[11,108,109],{},"Reusable modules cover the pieces that repeat across accounts: networking, IAM baselines, and logging. State is kept separate per account and environment, so a change in staging can never touch production's state file.",[49,111,113],{"id":112},"no-manual-changes-to-production","No manual changes to production",[11,115,116,117,121],{},"Rollouts are automated end to end. There is no manual ",[118,119,120],"code",{},"terraform apply"," from someone's laptop against a live account. If a change needs to happen, it goes through the same reviewed pipeline every time.",[11,123,124],{},"That is what makes the account structure trustworthy in the first place, because the isolation is only as good as the process that maintains it.",[15,126,128],{"id":127},"iam-and-central-logging-as-the-foundation","IAM and central logging as the foundation",[11,130,131],{},"Inside that structure, I keep IAM roles scoped to least privilege by default. Service roles get exactly the permissions their workload needs, and nothing is granted \"just in case.\"",[11,133,134],{},"Every account ships its CloudTrail and CloudWatch logs to the central log-archive account. There they are immutable from the perspective of the accounts that generated them.",[11,136,137],{},"That combination means a compromised workload account can't erase its own evidence. A review of what happened never depends on trusting the account under investigation.",[15,139,141],{"id":140},"what-this-means-for-your-company","What this means for your company",[11,143,144],{},"For management, a clean account structure comes down to one plain question: how large is the damage when something goes wrong? In a single account, a mistake or an attack can potentially affect everything, meaning production, test environments, and internal tools at the same time. With separate accounts it stays contained to one area, and the central log archive provides solid evidence of what happened.",[11,146,147,148,153],{},"That pays off at the latest when customers, insurers, or auditors ask about your security measures, for example in connection with NIS2. You can get a sense of where your own AWS environment stands today with the ",[149,150,152],"a",{"href":151},"\u002Fen\u002Ftools\u002Faws-security-check","free AWS security check",".",{"title":155,"searchDepth":156,"depth":156,"links":157},"",2,[158,159,163,164,168,169],{"id":17,"depth":156,"text":18},{"id":40,"depth":156,"text":41,"children":160},[161],{"id":51,"depth":162,"text":52},3,{"id":61,"depth":156,"text":62},{"id":98,"depth":156,"text":99,"children":165},[166,167],{"id":105,"depth":162,"text":106},{"id":112,"depth":162,"text":113},{"id":127,"depth":156,"text":128},{"id":140,"depth":156,"text":141},"Articles","July 28, 2026","md",{},true,"\u002Fen\u002Fblog\u002Faws-multi-account-terraform","2026-07-28",{"title":6,"description":13},"aws-security-foundation","en\u002Fblog\u002Faws-multi-account-terraform","An AWS multi-account structure built with Terraform limits the damage from mistakes and attacks. Which accounts you need and how central logging protects them.","2026-11-06","KMfSmQtCTH_Y9TK5pDfIrmWpa-0SqXVJ9F3Xax8C6rQ",1794305788748]