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

AccountPurposeIAM Strategy
ManagementBilling, OrganizationsMinimal access, root lockdown
SecurityCloudTrail, GuardDuty, ConfigRead-only cross-account roles
Shared ServicesCI/CD, DNS, monitoringService-specific roles
ProductionLive workloadsStrict SCPs, deployment roles only
DevelopmentDev/test environmentsBroader permissions, less restrictive SCPs

Access Key Hygiene

  1. Prefer IAM roles over access keys — EC2 instance profiles, ECS task roles, Lambda execution roles
  2. Rotate keys every 90 days — Automate with AWS Config rule access-keys-rotated
  3. Monitor unused keys — Delete keys not used in 90+ days
  4. 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.