AWS Account Segmentation: Limiting Blast Radius with Organizations and SCPs

Network segmentation limits the blast radius of a successful attack. If an attacker compromises one system, workload, or environment, they should not automatically gain access to everything else. On-premises, that usually means VLANs, firewall rules, and network zones. AWS adds another set of boundaries: accounts, organizational units, and service control policies.

In the cloud, the risk extends beyond unauthorized access to data. An attacker can launch resources, operate in unapproved regions, abuse compute capacity, establish persistence, and generate substantial charges. Segmentation must protect the data and restrict what an attacker can do with the account itself.

AWS Organizations separates workloads and data into accounts based on criticality, sensitivity, and business function. Service control policies, or SCPs, enforce organization-wide limits even when permissions inside an account are too broad.

Account structure

aws organizations list-organizational-units-for-parent \
  --parent-id r-xxxx

Sanitized output:

---------------------------
| Name                    |
|-------------------------|
| Prod                    |
| Dev                     |
| Sandbox                 |
---------------------------

Production and development are separate AWS accounts under different OUs, allowing each environment to have its own boundaries. SCPs do not restrict users or roles in the management account. Keep workloads out of that account and protect it with tightly controlled IAM access.

Protect the management account identity

Account boundaries and SCPs cannot compensate for weak authentication to the identity that administers the organization. Protect the AWS root user and organization administrators with hardware-backed MFA rather than relying only on a password or a copyable one-time code. AWS supports FIDO security keys for MFA.

I use this YubiKey 5 NFC across several identity workflows. Here, its job is narrow but important: protect the sign-in that can change organization-wide controls. It does not replace IAM policy, account separation, or SCPs.

Create the regional boundary

This SCP denies actions outside us-east-1:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonUSEast1",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

This policy sets the maximum permissions available to accounts under the OU. An IAM policy cannot override its explicit deny. In this case, that means launching an EC2 instance outside us-east-1.

Apply the SCP

aws organizations attach-policy \
  --policy-id p-xxxxxxxx \
  --target-id ou-xxxx-dev

aws organizations list-policies-for-target \
  --target-id ou-xxxx-dev \
  --filter SERVICE_CONTROL_POLICY \
  --query 'Policies[].{Name:Name,Description:Description}' \
  --output table

Test EC2 launches

--dry-run checks whether the launch is authorized without creating an instance.

aws ec2 run-instances \
  --profile dev \
  --region us-east-1 \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type t3.micro \
  --subnet-id subnet-xxxxxxxxxxxxxxxxx \
  --dry-run

aws ec2 run-instances \
  --profile dev \
  --region us-west-2 \
  --image-id ami-yyyyyyyyyyyyyyyyy \
  --instance-type t3.micro \
  --subnet-id subnet-yyyyyyyyyyyyyyyyy \
  --dry-run

us-east-1 passes the authorization check:

us-west-2 is blocked:

An error occurred (UnauthorizedOperation) when calling the RunInstances operation:
User: arn:aws:sts::DEV_ACCOUNT_ID:assumed-role/OrganizationAccountAccessRole/scp-launch-test
is not authorized to perform: ec2:RunInstances
with an explicit deny in a service control policy.

With the SCP attached, EC2 launches remain authorized in us-east-1 and are explicitly denied in us-west-2.

Closing thoughts

AWS segmentation extends beyond subnets, route tables, security groups, and firewalls. Accounts separate workloads and data, OUs group accounts by risk and purpose, and SCPs enforce boundaries that IAM policies inside those accounts cannot override.

A compromised development account should not give an attacker room to operate in production, launch resources in every region, disable security visibility, or create a large cloud bill. AWS Organizations and SCPs reduce that blast radius before an incident happens.