After conducting over 120 AWS cloud security audits across industries from healthcare to financial services, certain misconfigurations appear with near-perfect consistency. These are not exotic edge cases — they are fundamental errors that result from the speed of cloud adoption outpacing security maturity. Here are the seven we find in almost every engagement.

1. Wildcard IAM Policies

IAM policies using Action: "*" or Resource: "*" grant far more access than any role legitimately requires. We find these in CI/CD pipelines, Lambda execution roles, and developer sandbox accounts that were never cleaned up. Least-privilege IAM must be enforced programmatically — manual review alone does not scale.

2. Publicly Readable S3 Buckets

Despite AWS's account-level public access block, organisations regularly have buckets created by third-party tools or older Terraform modules that expose internal documents and credential files. We found a publicly readable S3 bucket containing a database backup with 2.3 million customer records in a FTSE 250 audit last quarter.

3. Long-Lived, Unrotated IAM Access Keys

Long-lived IAM user access keys — some over three years old — appear in every audit. AWS Secrets Manager and IAM role assumption for application access eliminates this risk entirely. A single commit to a public repository is enough to expose them.

4. CloudTrail Coverage Gaps

CloudTrail is frequently enabled only in a single region, or with data events disabled, or logging to a bucket in the same account. Effective audit logging requires multi-region trails, S3 data event logging, and log delivery to an immutable cross-account archive.

5. Unencrypted Parameter Store Secrets

We routinely find database credentials, API keys, and signing secrets in unencrypted standard parameters accessible to any role with ssm:GetParameter permissions — which is often far too broad.

6. Security Groups with 0.0.0.0/0 Ingress

Overly permissive security groups are endemic, particularly on development infrastructure promoted to production without hardening. RDP and SSH exposed to the internet are the highest-risk variants.

7. IMDSv1 Enabled on EC2 Instances

IMDSv1 is vulnerable to SSRF attacks that allow credential theft from the metadata endpoint. Enforce IMDSv2 at the account level via Service Control Policy — this takes under ten minutes and eliminates an entire attack class.