AWS IAM Best Practices Multi-Account
February 13, 2026
|
AWS
IAM
Security
Root lockdown, SSO, permission boundaries.
AWS IAM Best Practices for Multi-Account Environments
IAM is the foundation of AWS security. In a multi-account environment managed by AWS Organizations, IAM complexity increases significantly. This guide covers the essential practices for securing identity across your entire AWS footprint.
Root Account Lockdown
- Enable MFA — Use a hardware security key (YubiKey) for the root account
- Remove access keys — Root accounts should have zero programmatic access
- Use only for account-level tasks — Changing support plans, closing accounts, restoring IAM permissions
- Set up root email alias — Use a distribution list, not a personal email
AWS SSO (Identity Center)
Centralize user management with AWS IAM Identity Center:
# Permission Set for developers
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ecs:Describe*",
"ecs:List*",
"logs:*",
"cloudwatch:*",
"s3:Get*",
"s3:List*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"iam:*",
"organizations:*",
"ec2:*VPC*",
"ec2:*Subnet*"
],
"Resource": "*"
}
]
}Permission Boundaries
Limit the maximum permissions that IAM entities can have:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:CreateRole",
"iam:DeleteRole",
"organizations:*",
"account:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "*",
"Resource": "arn:aws:iam::*:role/Admin*",
"Condition": {
"StringNotLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/Admin*"
}
}
}
]
}Service Control Policies (SCPs)
SCPs enforce guardrails across all accounts in your organization:
# Deny regions outside allowed list
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["us-east-1", "us-west-2", "eu-west-1"]
},
"ForAnyValue:StringNotLike": {
"aws:PrincipalArn": "arn:aws:iam::*:role/OrganizationAdmin"
}
}
}
]
}
# Require encryption on S3 buckets
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}]
}Multi-Account IAM Strategy
| Account | Purpose | IAM Strategy |
|---|---|---|
| Management | Billing, Organizations | Minimal access, root lockdown |
| Security | CloudTrail, GuardDuty, Config | Read-only cross-account roles |
| Shared Services | CI/CD, DNS, monitoring | Service-specific roles |
| Production | Live workloads | Strict SCPs, deployment roles only |
| Development | Dev/test environments | Broader permissions, less restrictive SCPs |
Access Key Hygiene
- Prefer IAM roles over access keys — EC2 instance profiles, ECS task roles, Lambda execution roles
- Rotate keys every 90 days — Automate with AWS Config rule
access-keys-rotated - Monitor unused keys — Delete keys not used in 90+ days
- Never embed keys in code — Use environment variables or Secrets Manager
Eazy SaaS Tip: We set up AWS Identity Center (SSO) with MFA as the first step for every multi-account engagement. Combined with SCPs and permission boundaries, this provides defense in depth for IAM — even if a single policy is misconfigured, other layers prevent privilege escalation.