DEV Community

Yash
Yash

Posted on

How to Set Up a Secure Multi-Account AWS Structure: A Step-by-Step Guide

#aws #security #infrastructure #devops

How to Set Up a Secure Multi-Account AWS Structure: A Step-by-Step Guide

A single AWS account for everything is the most common DevOps mistake I see in early-stage companies. This guide shows you how to set up the right account structure from the beginning.

## Why Multiple Accounts?

Isolation, security, and cost visibility.

When everything is in one account, a mistake in development can affect production. A compromised credential can access everything. Cost allocation requires complex tagging instead of natural account-level separation.

Separate accounts give you natural blast radius limits and clear ownership.

## The Recommended Account Structure

 Root (Management) Account
 ├── Production Account
 ├── Staging Account
 ├── Development Account
 └── Shared Services Account
  ├── Centralized logging
  ├── Security tooling
  └── CI/CD tooling
Enter fullscreen mode Exit fullscreen mode

This is a starting point. Larger organizations add more accounts for specific teams, compliance requirements, or regional isolation. Start here and expand as needed.

## Step 1: Create an AWS Organization

In your existing AWS account (which becomes the Management account):

  1. Navigate to AWS Organizations in the console
  2. Click "Create an organization"
  3. Enable all features (not just consolidated billing)

The Management account should have no workloads. It exists to manage billing, apply organization-level policies, and govern member accounts.

## Step 2: Create Member Accounts

In AWS Organizations, you can create new accounts directly. Each account gets its own email address.

Use email aliases if you have a domain:

These new accounts start clean. No resources. No legacy configuration. This is a feature.

## Step 3: Set Up Organizational Units (OUs)

Organize accounts into OUs:

 Root
 ├── Production OU
 │ └── Production Account
 ├── Non-Production OU
 │ ├── Staging Account
 │ └── Development Account
 └── Infrastructure OU
  └── Shared Services Account
Enter fullscreen mode Exit fullscreen mode

OUs let you apply Service Control Policies (SCPs) to groups of accounts.

## Step 4: Apply Service Control Policies

SCPs are guardrails that apply across accounts regardless of IAM permissions. Useful defaults:

Deny root account actions (except in Management):

 {
  "Statement": [{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
  "StringLike": {
  "aws:PrincipalArn": "arn:aws:iam::*:root"
  }
  }
  }]
 }
Enter fullscreen mode Exit fullscreen mode

Restrict regions (only allow your operating regions):

 {
  "Statement": [{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
  "StringNotEquals": {
  "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
  }
  }
  }]
 }
Enter fullscreen mode Exit fullscreen mode

Apply SCPs to OUs, not individual accounts. Changes to an OU SCP apply to all accounts in that OU automatically.

## Step 5: Set Up Cross-Account Access

Create an IAM Role in each member account that your engineers can assume from the Management account or your identity provider.

In each member account:

 {
  "Version": "2012-10-17",
  "Statement": [{
  "Effect": "Allow",
  "Principal": {
  "AWS": "arn:aws:iam::MANAGEMENT_ACCOUNT_ID:root"
  },
  "Action": "sts:AssumeRole"
  }]
 }
Enter fullscreen mode Exit fullscreen mode

Your engineers assume this role when they need to work in that account. No permanent IAM Users in member accounts.

## Step 6: Centralize Logging

Enable CloudTrail in all accounts and aggregate to the Shared Services account.

In each member account:

  • Enable CloudTrail
  • Send logs to an S3 bucket in the Shared Services account

In the Shared Services account:

  • Create the central S3 bucket with a bucket policy that allows member accounts to write

This gives you a single place to audit all activity across all accounts.

## Step 7: Enable AWS Config

AWS Config tracks resource changes across your accounts. Enable it in all member accounts and aggregate findings to the Shared Services account.

This gives you: a history of every configuration change, compliance checking against your policies, and resource inventory across all accounts.

## The Time Investment

Setting this up from scratch: 1-2 days for someone who has done it before, 1-2 weeks for a first timer.

Migrating to this structure from a single-account setup: 2-6 weeks depending on how much is already running.

Starting with this structure on day one: 1-2 days.

The math on when to do it is straightforward. Do it on day one.

What questions do you have about multi-account AWS setup?

Top comments (0)