AWS / Guide 2

Account structure and access

AWS Organizations, OUs and guardrail policies, IAM Identity Center, IAM roles, and protecting the root user.

In AWS, the account is the boundary that matters most: for security, for billing, and for how much damage one mistake can do. A good structure uses many accounts, groups them in AWS Organizations, and gives people access through IAM Identity Center rather than IAM users. Getting this right early is far easier than untangling one busy account later.

The hierarchy

Policies attached to an OU apply to every account below it. Unlike Azure, AWS has no resource-group layer; tags (Guide 3) do that job.

A practical layout

This follows the AWS multi-account guidance, trimmed to what most organisations need:

Root
├── Management account        billing and Organizations only: no workloads
├── Security OU
│   ├── log-archive           CloudTrail and Config logs, locked down
│   └── security-tooling      GuardDuty, Security Hub delegated admin
├── Infrastructure OU
│   └── network               Transit Gateway, shared VPCs, DNS, egress
├── Workloads OU
│   ├── Prod OU               payroll-prod, web-prod ...
│   └── NonProd OU            payroll-test, notes-test ...
├── Sandbox OU                personal experiments, with budgets and auto-cleanup
└── Suspended OU              closed or quarantined accounts, deny-all SCP

• Keep the management account empty. Service control policies don't apply to it, so anything running there is outside your guardrails.
• One account per workload per environment. Production and test in the same account means test credentials can reach production data.
• AWS Control Tower sets up this layout (log archive, audit account, guardrails, account factory) in an afternoon. Use it for new organisations; retrofitting an existing one takes more care but is still worth it.

Guardrails with organization policies

Organization policies set limits that no one in an account can exceed, not even an administrator:

SCPs worth having early: deny leaving the organisation, deny turning off CloudTrail, GuardDuty and Config, deny unused regions (with exceptions for global services), and deny creating IAM users' access keys outside a break-glass role. Test an SCP on the Sandbox OU first: a mistake can lock administrators out of every account below it.

# Which SCPs apply to an account (directly; OUs above it apply too)
Get-ORGPolicyForTarget -TargetId 111122223333 -Filter SERVICE_CONTROL_POLICY | Select-Object Name, Id

# The OU tree
$root = Get-ORGRoot
Get-ORGOrganizationalUnitList -ParentId $root.Id | Select-Object Name, Id

Access with IAM Identity Center

IAM Identity Center is where people sign in. Connect it to your identity provider (Microsoft Entra ID, Okta, Google) so joiners and leavers flow through automatically with SCIM, then grant access as permission set + group + account:

Always assign to groups, never to individual users. For standing admin access, use Identity Center with a temporary elevated access tool (AWS offers a reference solution, TEAM) so administrators request the Admin set for a few hours with a reason.

IAM roles and least privilege

Inside an account, everything that isn't a person uses an IAM role: EC2 instance profiles, Lambda execution roles, cross-account roles. Rules worth writing down:

• No IAM users for people. The only IAM users left should be for systems that can't assume a role, each with an owner and a key rotation date. Get-AwsIamCredentialReport.ps1 finds the rest.
• Start from AWS managed policies, then narrow. IAM Access Analyzer can generate a policy from the actions a role actually used in CloudTrail, and flags unused roles, keys and permissions.
• Check trust policies. A role that trusts "AWS": "*" or an unknown account ID is a door. Access Analyzer's external access findings list them.
• Use conditions. aws:PrincipalOrgID on resource policies, aws:SourceIp or aws:SourceVpc where it fits, and MFA conditions for sensitive actions.
• Permissions boundaries let developers create roles for their own apps without being able to create a role more powerful than themselves.

Protect the root user

Every account has a root user that can do anything, including closing the account. AWS now requires MFA on root users in all account types. With Organizations, go further: turn on centralised root access management (IAM > Root access management) to remove root credentials from member accounts entirely. The management account can then perform the few root-only tasks (such as unlocking a bucket policy that denies everyone) as a short, audited session. Keep the management account's root user with a hardware MFA key, in a safe, with an alert on every sign-in.

Examples to try

From aws.ravindran.in: IAM policies, types of IAM policies (identity, resource, boundaries), and STS and role assumption.