AWS IAM Best Practices for Startups

Why IAM Matters

AWS Identity and Access Management (IAM) is the foundation of your AWS security posture. Get it right, and you have a solid security foundation. Get it wrong, and you're one misconfigured policy away from a breach.

The challenge: IAM is complex, and the default settings prioritize convenience over security.

The Golden Rules of IAM

1. Never Use Root Credentials

The AWS root account has unlimited access to everything. It should be:

• Protected with MFA (hardware key preferred)


• Used only for account-level tasks that require root


• Never used for day-to-day operations


• Never given access keys

Action: Enable MFA on root, then lock those credentials away.

2. Implement Least Privilege

Every user, role, and service should have only the permissions they need to do their job — nothing more.

Instead of:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

Use:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::my-bucket/uploads/*"
}

3. Use Roles, Not Users, for Applications

Applications running on AWS should use IAM roles, not IAM users with access keys.

For EC2: Use instance profiles
For ECS: Use task roles
For Lambda: Use execution roles
For EKS: Use IRSA (IAM Roles for Service Accounts)

4. Enable MFA Everywhere

Multi-factor authentication should be required for:

• All human users (no exceptions)


• Sensitive operations (even for roles)


• Root account (hardware key)

Enforce with policy:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

5. Use AWS Organizations and SCPs

For multi-account setups, use Service Control Policies (SCPs) to set guardrails across all accounts.

Example: Deny disabling CloudTrail:

{
  "Effect": "Deny",
  "Action": [
    "cloudtrail:DeleteTrail",
    "cloudtrail:StopLogging"
  ],
  "Resource": "*"
}

Common IAM Mistakes

Mistake 1: Wildcard Permissions

Using "Action": "" or "Resource": "" is almost never necessary and creates massive security risk.

Mistake 2: Long-Lived Access Keys

Access keys that never rotate are a ticking time bomb. If you must use access keys:

• Rotate them regularly (90 days max)


• Use AWS Secrets Manager to manage rotation


• Prefer short-lived credentials via STS

Mistake 3: Sharing Credentials

Never share IAM users between people or applications. Create individual identities for everything.

Mistake 4: Not Using Permission Boundaries

Permission boundaries limit the maximum permissions a user or role can have, even if their policy grants more.

Mistake 5: Ignoring Unused Permissions

Review IAM Access Analyzer findings and remove unused permissions. AWS tells you what's not being used — listen.

IAM Security Checklist

• Root account has MFA enabled (hardware key)


• Root account has no access keys


• All human users have MFA enabled


• No wildcard permissions in production policies


• Applications use roles, not access keys


• Access keys are rotated every 90 days or less


• IAM Access Analyzer is enabled


• CloudTrail logs all IAM actions


• Unused users and roles are removed


• SCPs enforce organization-wide guardrails

Tools for IAM Security

• IAM Access Analyzer — Finds overly permissive policies


• AWS Config — Monitors IAM configuration compliance


• CloudTrail — Logs all IAM actions


• Prowler — Open source AWS security scanner


• ScoutSuite — Multi-cloud security auditing

Start Here

If you're just getting started with IAM security:

• Today: Enable MFA on root and all human users


• This week: Review and remove wildcard permissions


• This month: Migrate applications from access keys to roles


• Ongoing: Review IAM Access Analyzer findings weekly

Need Help?

AWS IAM can be overwhelming. If you want help implementing least-privilege access and securing your AWS accounts, let's talk.