Security · Insights · · 4 min read
7 AWS security mistakes we see every week
Repeated misconfigurations that show up in almost every review — why they matter, how to fix them fast, and what to prioritize when you cannot do everything at once.
You do not need a novel zero-day to have a bad week on AWS. Most incidents we help triage start with known misconfigurations that were never prioritized. Here are seven we see in reviews across US teams — plus the fixes that do not require a six-month security program.
How to use this list
If you are time-boxed, fix in this order:
- Identity exposure (keys, MFA, admin sprawl)
- Public data and open admin ports
- Logging blind spots
- Network and encryption defaults
Tools help. Habits matter more: a baseline checklist, a monthly review, and a named owner.
1. Long-lived access keys on humans
IAM users with access keys older than 90 days — often tied to a former contractor’s laptop script.
Why it hurts: Keys get copied into CI, chat, and old laptops. Rotation rarely happens until something breaks.
Fix:
- Move people to IAM Identity Center (SSO)
- Reserve access keys for automation only, with rotation and ownership
- Delete unused users; alert on keys older than your policy (90 days is a common starting line)
Quick check: List IAM users with active access keys and last-used dates. Anything unused for 30+ days is a candidate for deletion.
2. Public S3 buckets (or buckets that became public)
“Temporary” public reads for marketing assets that never got locked down. Sometimes the bucket policy is private while an object ACL or a forgotten website hosting config still leaks.
Why it hurts: One public prefix can expose customer exports, backups, or logs.
Fix:
- Turn on Block Public Access at the account level
- Serve public content through CloudFront with Origin Access Control
- Run IAM Access Analyzer and periodic bucket audits
Quick check: Confirm account-level Block Public Access is on, then review exceptions with an expiration date.
3. Security groups that say 0.0.0.0/0 on admin ports
SSH, RDP, or database ports open to the internet “for debugging.”
Why it hurts: Internet-wide scanners find these in minutes. “Temporary” becomes permanent.
Fix:
- Prefer SSM Session Manager over inbound SSH
- Use a bastion with tight IP allowlists only if you must
- Put databases in private subnets; never expose them publicly
Quick check: Search security groups for ports 22, 3389, 5432, 3306, 1433 open to 0.0.0.0/0 or ::/0.
4. No MFA on privileged roles
AdministratorAccess available without MFA for console users — sometimes still on root for daily work.
Why it hurts: Stolen passwords become full-account compromise.
Fix:
- Enforce MFA in IAM Identity Center permission sets
- Reduce who has admin; prefer scoped permission sets per account
- Keep root credentials locked away; never use root for day-to-day
Quick check: Who can assume admin in production, and is MFA required every time?
5. CloudTrail off or single-region only
No organization trail, logs retained for 14 days, or trails that exist but nobody alerts on.
Why it hurts: Without durable, multi-region logs you cannot investigate incidents or prove what happened for audits.
Fix:
- Organization multi-region trail with log file validation
- Send logs to a dedicated logging account/bucket with restricted write
- Retain long enough for your compliance needs; alert via Security Hub, GuardDuty, or SIEM
Quick check: Is there an org trail covering all regions, and can you find a login event from last month?
6. Default VPC resources treated as “prod”
Workloads launched in the default VPC with default NACLs, shared routing, and no account separation.
Why it hurts: Blast radius grows. One compromised workload sits next to everything else. Prod and sandbox share fate.
Fix:
- Explicit VPC design with private subnets for compute and data
- Separate accounts for prod vs. non-prod via AWS Organizations
- Service control policies that prevent the worst “oops” configurations
Quick check: Is production still running in the default VPC? Are non-prod credentials able to touch prod accounts?
7. Encryption optional “for now”
Unencrypted EBS, RDS without KMS, secrets in plain environment variables or Parameter Store as plain strings.
Why it hurts: Disk snapshots, restored volumes, and leaked env vars become data incidents. “We’ll encrypt later” rarely happens.
Fix:
- Default encryption policies for EBS, S3, and RDS
- Secrets Manager (or SSM SecureString) with clear key ownership
- Document which KMS keys protect which workloads
Quick check: Pick one production database and one app — where do secrets live today?
Prioritization matrix
| Mistake | Typical effort | Risk if ignored |
|---|---|---|
| Human access keys | Low–medium | High |
| Public S3 | Low | High |
| Open admin ports | Low | High |
| MFA on privileged access | Low | High |
| CloudTrail gaps | Medium | High for detection/audit |
| Default VPC as prod | Medium–high | Medium–high |
| Encryption gaps | Medium | Medium–high (and audit-visible) |
What this is not
This list is not a SOC 2 or HIPAA certification program. It is the technical hygiene that keeps findings from repeating while your compliance process does its job. For boundaries between AWS and your team, see the shared responsibility primer. For migration-time controls, use the pre-migration checklist.
If you want a prioritized risk register with actionable findings, start with an AWS Security Baseline Review or book a free discovery call.