AWS IAM Security: A Practical Guide That Actually Works in Production
Source: Dev.to
Introduction
Most AWS security guides tell you what to do. This guide shows how to implement security in a production environment where developers need to ship code and security can’t be a blocker.
Least‑privilege sounds great in theory, but in practice it’s messy. Developers need permissions to work, yet you can’t hand out AdministratorAccess and hope for the best.
Role‑Based Access
Start with role‑based access, not user‑based. Create IAM roles that map to actual job functions:
| Role | Permissions |
|---|---|
| Developers | Read access to most services; write access to development 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 |
Permission Boundaries
Use permission boundaries as a safety net. Even if a user or role is granted excessive permissions, the boundary limits what can actually be done.
- Set a permission boundary that prevents:
- Granting permissions beyond what is required for the role’s job function.
The 90‑Day Permission Audit
Every quarter, review which permissions are actually being used.
AWS Access Analyzer makes this simple—it shows which permissions have been used in the last 90 days.
MFA Enforcement
MFA should be non‑negotiable:
- IAM users – enable MFA on every single IAM user; no exceptions.
- Policy‑level enforcement – create a policy that denies all actions unless MFA is present, except for the action that enables MFA.
- Console access – require MFA for AWS Management Console login.
- Programmatic access – require MFA when assuming roles (you can’t attach MFA directly to access keys).
MFA Pattern for Developers
- Developers receive long‑term credentials with minimal permissions.
- To perform work, they assume a role that requires MFA.
- The assumed role provides the real permissions for the session.
Access‑Key Rotation
Access keys are permanent credentials and the most commonly leaked.
- Rotation rule: rotate access keys every 90 days (quarterly).
- Automation: use AWS Config rules or custom scripts to detect keys older than 90 days and enforce rotation.
Apply the same rule to console passwords—enable password expiration in your password policy.
Note: If you still rely on long‑term access keys for production workloads, you’re doing it wrong. Use IAM roles wherever possible.
Using IAM Roles Instead of Long‑Term Keys
| Service | Recommended Credential Type |
|---|---|
| EC2 | Instance profile (role) |
| ECS / EKS | Task role or service account |
| Lambda | Execution role |
| Cross‑account | Assume role |
| Developers | AWS SSO or assume‑role with temporary credentials |
Session duration can be set from 1 to 12 hours, with more sensitive roles receiving shorter sessions.
When Long‑Term Keys Are Unavoidable
- CI/CD pipelines
- Third‑party tools
- Legacy applications
In these cases, enforce strict rotation and monitoring.
Network Controls
IAM handles who can do what; network controls dictate where they can connect from.
- Add a condition to IAM policies that requires connections from specific IP ranges (office IPs, VPN endpoints, authorized cloud environments).
- Deny everything else.
This blocks attackers who steal credentials but are not on your network.
VPN for Sensitive Operations
Require a VPN connection for production access, even with valid credentials and MFA.
VPN Profiles
| Profile | Requirements |
|---|---|
| Standard work | Anywhere + MFA |
| Production changes | VPN + MFA |
| Critical operations (IAM changes, security modifications) | VPN + approval workflow |
Accommodate remote work by adding friction rather than outright blocking.
Service Control Policies (SCPs)
If you use AWS Organizations, SCPs are your “nuclear option”—they override all other policies.
Common SCPs
- Prevent disabling CloudTrail or GuardDuty
- Block public S3 buckets
- Restrict instance types to an approved list
- Deny operations in unauthorized regions
Logging & Monitoring
- CloudTrail – enable in every account, every region, with no exceptions.
- GuardDuty and Security Hub – turn on and actively review findings.
Security is not set‑and‑forget; continuous monitoring is essential.
Monthly Audit Checklist
| Area | What to Check |
|---|---|
| Access key age | Keys older than 90 days? Delete or rotate. Unused keys in the last 90 days? Delete. |
| MFA status | Users without MFA? Enforce. Any console logins without MFA? Investigate. |
| Permission usage | Use Access Analyzer for unused permissions. Review overly permissive policies (wildcards, *). |
| Unusual activity | New IAM users/roles, permission changes on critical resources, failed auth attempts, API calls from odd locations, root account usage. |
Prioritizing Improvements
| Timeframe | Focus |
|---|---|
| Week 1 | Critical issues (e.g., missing MFA, overly permissive admin access) |
| Weeks 2‑3 | Important hardening tasks (e.g., SCPs, network restrictions) |
| Month 2 | Ongoing hardening (key rotation automation, logging enhancements) |
| Ongoing | Maintenance, continuous audits, and incremental improvements |
Conclusion
Perfect security doesn’t exist. The goal is to make your AWS environment hard enough that attackers move on to easier targets.
- Enforce MFA everywhere.
- Rotate credentials regularly.
- Apply least‑privilege principles with role‑based access and permission boundaries.
- Restrict network access with IP conditions and VPN requirements.
- Audit continuously.
These practices aren’t flashy, but they work—and they’ll save you from those 3 AM calls when compromised credentials spin up cryptocurrency miners.