Top AWS Security Misconfigurations and How to Fix Them

Most AWS Breaches Start as Design Debt

The cloud does not remove security mistakes. It just makes them programmable.

The best-known example remains the Capital One breach, where a web application flaw and an overpowered AWS role turned a limited foothold into broad access to sensitive S3 data. That incident was not "just SSRF" and it was not "just IAM." It was a chain. Cloud incidents often are.

Below are the AWS mistakes that keep showing up in audits and postmortems.

1. Overprivileged IAM Roles

The most expensive AWS mistake is still broad privilege.

Common patterns:

• Wildcard actions such as s3:* or iam:*
• Shared administrative roles for unrelated workflows
• EC2 or Lambda roles with far more access than the application needs
• Stale users and keys that nobody can confidently explain

Fix pattern:

• Use role-specific policies
• Add conditions where appropriate
• Review last-used data and remove dead access
• Prefer short-lived federation over static users

Example:

A reporting Lambda that only needs to read one bucket should not also be able to list users, decrypt unrelated keys, or assume broader roles.

2. Public or Weakly Protected S3 Buckets

S3 exposure remains one of the fastest ways to create a reportable incident.

Checklist:

• Block public access at account and bucket level
• Require encryption and TLS
• Use bucket policies that name exact principals and actions
• Log access to sensitive buckets
• Watch for cross-account sharing that outlived its purpose

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

3. Missing or Incomplete Logging

If CloudTrail is disabled in one account, or data events are missing from sensitive storage, you are effectively choosing slower detection.

Production baseline:

• Organization-wide CloudTrail
• GuardDuty enabled in every relevant region
• Config recording and alerting on critical drift
• Security Hub or equivalent central aggregation
• Protected log destinations with restricted deletion rights

Attackers routinely try to reduce visibility before doing anything loud.

4. IMDS Misuse and Metadata Exposure

The EC2 metadata service is powerful. Misuse of it is dangerous.

Problems:

• IMDSv1 still allowed
• Applications making unsafe server-side requests
• Overpowered instance profiles attached to internet-facing systems

Fix pattern:

• Require IMDSv2
• Reduce instance profile permissions sharply
• Treat SSRF as a cloud-identity risk, not only an application bug

5. Publicly Reachable Admin Paths and Datastores

We still see:

• RDS marked publicly_accessible = true
• Open SSH or RDP to the world
• Public load balancers fronting admin applications without enough extra control
• Security groups copied from old environments and never tightened

A secure VPC design matters more than a long list of individual fixes.

6. Secrets in Environment Variables and Build Systems

AWS-native services make secret handling easier than it used to be, but teams still leak credentials through CI, instance userdata, copied .env files, or Terraform state.

Use:

• Secrets Manager or Parameter Store for application secrets
• OIDC federation for CI instead of long-lived keys
• KMS-backed encryption and rotation where appropriate
• Access logs for secret retrieval on high-risk systems

7. Weak Multi-Account Guardrails

Single-account convenience turns into multi-account confusion quickly.

Use AWS Organizations with:

• SCPs to prevent obviously dangerous actions
• Shared logging patterns
• Baseline Config rules
• Separate production, staging, and sandbox boundaries

Without guardrails, one hand-crafted exception becomes next quarter's incident.

Quick Remediation Priorities

If you need a first pass, start here:

1. Remove broad IAM privileges from exposed workloads
2. Block public access to sensitive buckets and admin services
3. Turn on missing CloudTrail, GuardDuty, and Config coverage
4. Enforce IMDSv2 and reduce instance profile scope
5. Move static secrets out of repos and CI variables

Further Reading

• AWS Security Best Practices
• AWS Well-Architected Security Pillar
• AWS IAM Best Practices
• EC2 Instance Metadata Service

Related SecureCodeReviews guides:

• AWS Security Best Practices
• AWS IAM Privilege Escalation Attacks
• Cloud Security Assessment Checklist

What makes AWS safer is not one feature toggle. It is removing easy attack paths before somebody has a chance to chain them together.