Most AWS security guides tell you WHAT to do. This one tells you HOW to actually implement it in a real environment where developers need to ship code and security can't be a blocker.
After hardening IAM for multiple production environments, here's the security baseline that balances protection with productivity.
The Foundation: Least Privilege Access
Least privilege sounds great in theory. In practice, it's messy. Developers need permissions to work, but you can't hand out AdministratorAccess and hope for the best.
Here's the approach that works:
Start with role-based access, not user-based. Instead of managing permissions per person, create roles based on actual job functions:
Developers: Read access to most services, write access to dev environments only
DevOps/SRE: Elevated access for infrastructure management, restricted for production changes
Security team: Audit and compliance permissions across all accounts
Finance: Read-only access for cost analysis
Use permission boundaries. This is your safety net. Even if someone grants excessive permissions, the boundary limits what they can actually do.
Set a permission boundary that prevents:
Creating IAM users or roles without approval
Modifying security group rules on production
Disabling CloudTrail or GuardDuty
Launching instances in unauthorized regions
The 90-day permission audit. Every quarter, review what permissions are actually being used. AWS Access Analyzer makes this simple - it shows you which permissions have been used in the last 90 days.
If a permission hasn't been used? Remove it. Start tight, expand when needed. Not the other way around.
MFA Enforcement: No Exceptions
MFA should be non-negotiable. Not "recommended." Not "optional for non-production." Mandatory.
For IAM users, enable MFA on every single IAM user. No exceptions. The person who says "I'll add it later" is the one whose credentials will get compromised.
Go further: enforce MFA at the policy level. Users without MFA can't do ANYTHING except add MFA to their account.
For console access, require MFA for AWS Console login. This is straightforward and catches the most common attack vector - stolen passwords.
For programmatic access, here's where it gets tricky. You can't use MFA with access keys directly, but you can require MFA for assuming roles.
The pattern: developers get long-term credentials with minimal permissions. To do actual work, they assume a role that requires MFA. The role has the real permissions.
This means even if access keys leak, attackers can't use them without the MFA device.
Access Keys and Password Rotation: The Boring Stuff That Matters
Access keys are permanent credentials. They don't expire. They're also the most commonly leaked credentials.
The rotation strategy: Set a hard rule: access keys rotate every 90 days. Not yearly. Quarterly.
Why 90 days? It's frequent enough to limit exposure but not so frequent that people start writing keys down or storing them insecurely.
Automated enforcement. Don't rely on people remembering to rotate keys. Set up automated checks:
CloudWatch Events trigger on keys older than 80 days
Lambda function sends a notification to the key owner
At 90 days, automatically disable the key
At 100 days, delete it
Yes, this will break things. That's intentional. Broken things get fixed quickly.
Passwords follow the same rule. Console passwords should rotate every 90 days. Enable password expiration in your password policy.
Some teams push back: "We'll forget passwords if we change them too often!"
Use a password manager. Problem solved.
Short-Lived Credentials: The Better Way
Here's the real talk: if you're still using long-term access keys for production workloads, you're doing it wrong.
Use IAM roles wherever possible
- EC2 instances: instance profiles
- ECS/EKS: task roles or service accounts
- Lambda: execution roles
- Cross-account: assume role These credentials are temporary, rotate automatically, and never leave AWS.
For developers: use AWS SSO or assume role. Instead of giving developers long-term keys, give them the ability to assume roles with temporary credentials.
Session duration: 1-12 hours, depending on the role. More sensitive roles get shorter sessions.
The access key exception. Sometimes you genuinely need long-term keys - CI/CD pipelines, third-party tools, legacy applications.
For these: separate AWS account for automation, minimal permissions, keys rotated every 30 days, and heavily monitored.
IP Whitelisting and VPN: Network-Level Security
IAM handles authentication and authorization. Network controls handle WHERE people can connect from.
Restrict console access by IP. Add a condition to your IAM policies that requires connections from specific IP ranges.
Allow from:
- Office IP addresses
- VPN endpoints
- Authorized cloud environments
- Deny everything else. This stops attackers who steal credentials but aren't on your network.
VPN for sensitive operations. For production access, require a VPN connection. Even with valid credentials and MFA, you can't touch production unless you're on the VPN.
Set up different VPN profiles:
Standard VPN: general AWS access
Production VPN: production environment access only, additional authentication required
The work-from-home consideration. In 2026, people work from anywhere. Don't block remote work, just add friction for sensitive operations.
Standard work: works from anywhere with MFA Production changes: requires VPN connection Critical operations (IAM changes, security modifications): requires VPN + approval workflow
Account-Level Controls: The Last Line of Defense
Individual IAM controls are important. Account-level controls are critical.
Service Control Policies (SCPs). If you're using AWS Organizations, SCPs are your nuclear option. They override everything.
Common SCPs:
- Prevent disabling CloudTrail or GuardDuty
- Block public S3 buckets
- Restrict instance types to the approved list
- Deny operations in unauthorized regions
CloudTrail everywhere: Every account, every region, always on. No exceptions.
Send logs to a separate security account where developers can't access them. Attackers love disabling logging first.
GuardDuty and Security Hub: Turn them on. Actually review the findings. Too many teams enable these services and then ignore the alerts.
Integrate with your ticketing system so findings become actionable tasks, not dashboard noise.
The Audit Checklist: What to Check Monthly
Security isn't set-and-forget. Here's what you should audit every month:
Access key age
- Any keys older than 90 days? Why?
- Any unused keys in the last 90 days? Delete them.
MFA status
- Which users don't have MFA? Chase them down.
- Any console logins without MFA? Investigate.
Permission usage
- Check Access Analyzer for unused permissions
- Review overly permissive policies
- Look for wildcard permissions (:)
Unusual activity
- New IAM users or roles created
- Permission changes on critical resources
- Failed authentication attempts
- API calls from unusual locations
Root account usage
Root account should NEVER be used for daily operations
Any root account activity? Better have a good reason.
The Implementation Roadmap
Don't try to fix everything at once. Here's the priority order:
Week 1: Critical
Enable MFA for all users
Audit and remove AdministratorAccess where not needed
Set up CloudTrail if you haven't already
Week 2-3: Important
Implement access key rotation
Set up IP restrictions for console access
Create permission boundaries
Month 2: Hardening
Move to role-based access
Implement short-lived credentials
Set up automated compliance checks
Ongoing: Maintenance
Monthly security audits
Quarterly permission reviews
Continuous monitoring and alerts
The Reality Check
Perfect security doesn't exist. Your goal isn't to make AWS accounts impenetrable - it's to make them hard enough to attack that hackers move to easier targets.
Enforce MFA. Rotate credentials. Use least privilege. Restrict network access. Audit regularly.
These aren't exciting. They're not bleeding-edge. But they work.
And they'll save you from that 3 AM call when someone spins up cryptocurrency miners using your compromised credentials.
Top comments (1)
Mostly agree, especially on MFA and killing long-term keys. Not fully convinced that forced password rotation add much on top of role-based access with MFA, but still a solid take.