Before diving into service development, I did the initial AWS setup.
This time, I used AWS Organizations to build a multi-account environment, with a design that assumes Terraform-based IaC (Infrastructure as Code) and GitHub Actions CI/CD down the line.
This post covers the structure I actually built and the reasoning behind it.
Why adopt AWS Organizations from the start?
In AWS, you can technically create everything inside a single account.
But as development progresses, that approach starts causing problems like these.
- Dev and production resources end up mixed together
- Production resources get accidentally deleted or changed
- IAM permissions balloon out of control
- Logs and security become hard to separate after the fact
- Managing multiple projects gets complicated
AWS recommends a multi-account setup to address exactly these problems.AWS Organizations User Guide
What is Organizations?
AWS Organizations is a service for managing multiple AWS accounts together as a group.
Organizations has a concept called an OU (Organizational Unit).
An OU isn't a place where you put EC2 instances or S3 buckets — think of it more like a folder for organizing AWS accounts.
For example,
Root
├── Infrastructure
└── Workloads
you create OUs like this and place AWS accounts inside them.
Using OUs means you can later apply policies — like SCPs (Service Control Policies) — across a whole group of accounts at once.AWS Organizations Best Practices
The structure I went with
I based this on the thinking behind the AWS Security Reference Architecture (AWS SRA), while keeping things simple enough for a small-to-medium dev team.AWS Security Reference Architecture (AWS SRA)
Root
├── Infrastructure
│ ├── Log
│ └── Security
├── Workloads
│ ├── Dev
│ ├── Stg
│ └── Prod
└── Management（管理アカウント）
Infrastructure OU
Houses the AWS accounts needed to operate the infrastructure itself.
Log
The account where audit logs — CloudTrail chief among them — get aggregated.
By default, AWS only lets you look back at 90 days of CloudTrail event history, so if you need to retain it longer, storing it in S3 is the recommended approach.
You can also cut storage costs further by transitioning older logs to S3 Glacier after a set period.
Going forward, I plan to funnel other kinds of audit logs into this account too, not just CloudTrail.
Security
The account for hosting security services like Security Hub, GuardDuty, and AWS Config.
I haven't built this out yet, but I plan to consolidate
- Security Hub
- GuardDuty
- AWS Config
- A CSPM tool down the line
here.
The AWS SRA itself recommends keeping the log account and the security account separate.
Workloads OU
Where applications actually run.
This time I created
- Dev
- Stg
- Prod
these three.
Dev
The environment for validating Terraform and doing application development.
Stg
A staging environment for verification before releasing to production.
Prod
The production environment.
Keeping production in its own account limits the blast radius of accidental operations or permission misconfigurations.
Management Account
The first AWS account you use to create your Organization automatically becomes the Management Account.
This account handles things like
- Managing Organizations
- IAM Identity Center
- Billing management
and similar tasks.
It's not an account you deploy applications into.
Designing email addresses
Every new AWS account you create through Organizations needs its own unique email address.
This time I used plus-addressing.
That way, everything funnels into a single mailbox in practice, while AWS still treats each one as a distinct account.
No IAM users
Creating an IAM user to log in to AWS used to be the standard approach.
These days, though, AWS recommends authenticating through IAM Identity Center (formerly AWS SSO) instead.IAM Identity Center User Guide
Going forward, I plan to adopt this structure:
- Humans → IAM Identity Center
- GitHub Actions → OIDC + IAM Role
- Terraform → IAM Role
for authentication.
The root user is reserved strictly for emergencies.
What's next
With Organizations set up, here's what I'm tackling next.
- Enabling IAM Identity Center
- Designing Permission Sets (Administrator / ReadOnly)
- SSO setup for the AWS CLI
- IaC with Terraform
- Connecting GitHub Actions with OIDC
- Aggregating CloudTrail into the Log account
- Rolling out Security Hub and GuardDuty
Wrap-up
You can always change your AWS setup down the line, but the more you nail down account structure and permission design upfront, the lower your ongoing operational overhead will be.
The multi-account structure I built here draws on AWS best practices and the AWS Security Reference Architecture, simplified enough to stay manageable for a small-to-medium dev team.
Building on this foundation, I'll bring together Terraform, CI/CD, audit logging, and permission management to create an AWS environment that's secure and sustainable to run long-term.