The 3 AWS misconfigurations we see in every account
Every AWS account is different, but the same three problems turn up again and again: permissions that are far too broad, S3 buckets that are more open than anyone intended, and logging that is missing when it is needed most. None of them is exotic, and all of them can be fixed in an afternoon.
Why the same three keep appearing
These misconfigurations are not caused by careless engineers. They come from the way small teams work: moving quickly, accepting defaults, and making temporary changes that never get undone. The patterns below are anonymised and generalised from the accounts we see, and they will probably look familiar.
1. Over-permissive IAM
What we see. Users and roles with AdministratorAccess or policies that allow * on every resource, access keys that have not been used for months, and human users without MFA. Often a single IAM user created in the first week of the company still holds full admin rights.
Why it happens. Broad permissions make things work first time. When a deployment fails with an access denied error, granting more access is the fastest way to unblock it, and nobody goes back to narrow it down.
The fix. Remove unused users and access keys, require MFA for every human user, and replace broad policies with ones scoped to what each person or service actually does. IAM Access Analyzer can show which permissions are unused.
How to stop it coming back. Give people access through IAM Identity Center rather than long-lived IAM users, review admin access every quarter, and treat any new * permission as something that needs a second pair of eyes.
2. Public S3 buckets and weak bucket policies
What we see. Buckets that allow public access through a policy or ACL, buckets that were public for a quick test and never closed, buckets with no policy requiring TLS, and older objects uploaded before S3 began encrypting all new objects by default in January 2023.
Why it happens. S3 access is controlled in several places, and it is easy to fix one and miss another. Older buckets, and infrastructure templates copied from old examples, may also predate the Block Public Access and disabled-ACL defaults that AWS introduced for new buckets in April 2023.
The fix. Turn on Block Public Access at account level, check each bucket’s policy and ACLs, and serve genuinely public content through CloudFront with origin access control. Add a bucket policy that denies non-TLS requests. In older buckets, check for objects uploaded before January 2023 that may still be unencrypted, and use SSE-KMS or DSSE-KMS where you need stronger control over the keys.
How to stop it coming back. Keep account-level Block Public Access switched on, so a single bucket change cannot expose data, and check new buckets as they are created rather than at the next review. See our S3 bucket security guide.
3. Missing or incomplete logging
What we see. No CloudTrail trail at all, a trail that only covers one region, a trail that has been stopped, or logs written to a bucket anyone in the account can delete. VPC Flow Logs and S3 access logging are often switched off too.
Why it happens. Logging feels like overhead until the day you need it. CloudTrail’s event history keeps 90 days of management events without any set-up, which makes it easy to assume a trail is not necessary.
The fix. Create a multi-region CloudTrail trail that logs to a private, encrypted S3 bucket, and confirm that it is logging. Turn on VPC Flow Logs for production networks, and access logging for buckets that hold sensitive data.
How to stop it coming back. Protect the log bucket so that logs cannot be quietly deleted, and alert on any change to CloudTrail itself. A trail that is stopped by mistake should be noticed within hours, not months.
How to check your own account
Our guide to five AWS security checks you can run right now covers the root account, S3 Block Public Access, open security groups, CloudTrail and old access keys, with console steps and CLI commands.
If you would rather not repeat those checks by hand, bearhug finds these misconfigurations continuously across every connected account, explains them in plain English and fixes common ones, such as public buckets and missing CloudTrail logging, in one click. See the AWS misconfiguration scanner or read more about AWS CSPM.