Common AWS misconfigurations: the 10 to check first
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. This guide covers those three in depth, then seven more common misconfigurations, each with the AWS Security Hub control that flags it and how to fix it.
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.
Seven more common AWS misconfigurations
The three above are the ones we see in almost every account. These seven are also common, and each one maps to an AWS Security Hub control, so you can see whether it affects you in the Security Hub console. All of them are part of the AWS Foundational Security Best Practices standard.
-
Network ports open to the internet
Security Hub flags it as:
EC2.19Security groups should not allow unrestricted access to ports with high risk (Critical), andEC2.18Security groups should only allow unrestricted incoming traffic for authorized ports (High).Why it matters: SSH, RDP and database ports open to
0.0.0.0/0are scanned constantly by automated tools looking for weak passwords and unpatched services.The fix: Remove the open rules, restrict access to known addresses or other security groups, and use Systems Manager Session Manager instead of open SSH. Our EC2.19 guide walks through it.
-
A root user with access keys or no MFA
Security Hub flags it as:
IAM.4IAM root user access key should not exist andIAM.9MFA should be enabled for the root user (both Critical).Why it matters: The root user can do anything in the account, and IAM policies cannot restrict it. A leaked root key or password means a full account compromise.
The fix: Delete any root access keys, turn on MFA for the root user (a hardware key is strongest), and use the root user only for the few tasks that need it.
-
Databases reachable from the internet
Security Hub flags it as:
RDS.2RDS DB Instances should prohibit public access, as determined by the PubliclyAccessible configuration (Critical).Why it matters: A publicly accessible database is one weak password or unpatched flaw away from a breach, if its network rules let traffic in.
The fix: Set the instance to not publicly accessible, and allow connections only from your application’s security group.
-
Public snapshots
Security Hub flags it as:
EC2.1Amazon EBS snapshots should not be configured to be publicly restorable andRDS.1RDS snapshot should be private (both Critical).Why it matters: A public snapshot lets any AWS account restore a full copy of your disk or database. Snapshots are often shared for a migration or a test and never made private again.
The fix: Make the snapshots private, share them only with specific AWS accounts, and turn on block public access for EBS snapshots in each Region you use.
-
Unencrypted storage
Security Hub flags it as:
EC2.7EBS default encryption should be enabled andRDS.3RDS DB instances should have encryption at-rest enabled (both Medium).Why it matters: Encryption at rest protects data on disks and backups, and auditors for SOC 2, ISO 27001 and PCI DSS will ask about it.
The fix: Turn on EBS encryption by default in every Region. RDS encryption can only be set when a database is created, so encrypt an existing one by copying a snapshot with encryption and restoring from the copy.
-
Instances that still allow IMDSv1
Security Hub flags it as:
EC2.8EC2 instances should use Instance Metadata Service Version 2 (IMDSv2) (High).Why it matters: The older metadata service can let a flaw such as server-side request forgery read an instance’s temporary credentials. Our AWS misconfiguration breaches guide shows how that played out at Capital One.
The fix: Require IMDSv2 on existing instances and in your launch templates, and set it as the default for new instances in each Region.
-
GuardDuty switched off
Security Hub flags it as:
GuardDuty.1GuardDuty should be enabled (High).Why it matters: Without threat detection, signs of compromise such as unusual API calls or credential misuse go unnoticed.
The fix: Enable GuardDuty in every Region, including ones you do not use, so activity there is still watched. New accounts get a 30-day free trial.
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.