Cloud Security
Common AWS misconfigurations are rarely clever. They are open buckets, wildcard policies, forgotten keys and missing logs, and they stay on the list year after year because they are easy to create and easy to miss. This guide covers ten of the most common AWS misconfigurations, with a command to check each and the fix.
These come from the CIS AWS Foundations Benchmark, AWS’s own security guidance and the patterns that recur in public cloud breach reports, not from any client of ours. Commands need the AWS CLI configured with read access, for example the managed SecurityAudit policy. Check each against your own environment before running changes.
What are the most common AWS misconfigurations?
The most common AWS misconfigurations fall into four groups: identity (root account, wildcard policies, old keys), data exposure (public buckets and databases, no encryption), network (open security groups, IMDSv1) and visibility (missing CloudTrail and alerts). Fixing these covers most of the avoidable risk in a typical account.
1. Root account without MFA or with access keys
The root user can do anything and is not limited by IAM policies, so a stolen root credential is the worst case. It should have MFA, no access keys, and be used only for the few tasks that require it.
Check:
aws iam get-account-summary --query 'SummaryMap.[AccountMFAEnabled,AccountAccessKeysPresent]'Fix: Enable a hardware or virtual MFA device for root, delete any root access keys, and store the credentials offline with a documented break-glass process.
2. Public S3 buckets and no account-level Block Public Access
One public bucket holding the wrong data is a classic AWS breach. Block Public Access at account level stops new public exposure by default, so a single mistaken policy cannot expose a bucket.
Check:
aws s3control get-public-access-block --account-id YOUR_ACCOUNT_IDFix: Turn on all four Block Public Access settings for the account, then create explicit exceptions for the rare bucket that must be public, such as a static website.
3. Wildcard IAM policies
A policy that allows Action: "*" on Resource: "*" turns any compromised credential into full account access. Broad managed policies attached to application roles are a common variant.
Check:
aws iam get-account-authorization-details --filter LocalManagedPolicyFix: Replace wildcards with the specific actions and resources a role needs. IAM Access Analyzer can generate a least-privilege policy from real CloudTrail activity.
4. Old and unused access keys
Long-lived keys leak into repositories, laptops and CI logs, and unused ones are pure risk. Keys from former staff or retired systems are the usual culprits.
Check:
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -dFix: Disable keys unused for 90 days, rotate the rest, and replace keys with roles and temporary credentials wherever the workload allows it.
5. Security groups open to the world
Rules that allow SSH (22), RDP (3389) or database ports from 0.0.0.0/0 invite constant scanning and brute force.
Check:
aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
--query 'SecurityGroups[].[GroupId,GroupName]'Fix: Restrict sources to known ranges, and use AWS Systems Manager Session Manager instead of exposing management ports at all.
6. CloudTrail not enabled in every region
Without a multi-region trail you have gaps in the record exactly where an attacker would prefer to work, in regions you do not use.
Check:
aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail,LogFileValidationEnabled]'Fix: Create a multi-region trail with log file validation, deliver it to a locked-down bucket, ideally in a separate logging account.
7. Instance metadata service version 1 still allowed
IMDSv1 can be abused through server-side request forgery to steal an instance role’s credentials. IMDSv2 requires a session token and blocks that simple route.
Check:
aws ec2 describe-instances --query 'Reservations[].Instances[?MetadataOptions.HttpTokens==`optional`].InstanceId'Fix: Require tokens on existing instances with aws ec2 modify-instance-metadata-options --instance-id ID --http-tokens required, and set IMDSv2 as the default for new launches.
8. Unencrypted EBS volumes, snapshots and databases
Encryption at rest is cheap to enable, and unencrypted data is a finding in almost every framework. It is also much harder to retrofit than to switch on early.
Check:
aws ec2 get-ebs-encryption-by-defaultFix: Enable aws ec2 enable-ebs-encryption-by-default in every region, encrypt RDS instances at creation, and use KMS keys you control for sensitive data.
9. Publicly accessible databases
A database with a public endpoint and a weak password is an easy target. Databases belong in private subnets.
Check:
aws rds describe-db-instances \
--query 'DBInstances[?PubliclyAccessible==`true`].DBInstanceIdentifier'Fix: Move the instance to a private subnet, set it as not publicly accessible, and reach it through the application tier or a private connection.
10. No alerting on high-risk events
Misconfigurations happen. The real damage comes from not noticing. Missing alarms for root use, console logins without MFA or security group changes let problems sit for months.
Check:
aws cloudwatch describe-alarms --query 'MetricAlarms[].AlarmName'Fix: Create alarms for the events in the CIS AWS Foundations Benchmark, enable GuardDuty, and route alerts to a channel with a named owner.
How do you find common AWS misconfigurations at scale?
Use automated checks for breadth and a person for judgement. AWS Security Hub with the CIS standard, AWS Config rules and open-source scanners such as Prowler find most of the items above across every account and region. A human then decides which findings are reachable in your setup and in what order to fix them.
Turn the checks into a routine. Run them after every major change, and put the high-signal ones into Config rules or Security Hub so they alert you the moment a setting drifts, not at the next annual review.
How often should you check for common AWS misconfigurations?
Check continuously for the high-signal items and review everything at least once a year or after a major change. Accounts drift as people join, leave and ship, so a clean result today says little about next quarter. Automated rules close that gap between reviews.
A sensible rhythm is continuous automated checks, a monthly look at open findings, and an independent review annually or whenever you migrate, acquire or prepare for an audit. The same logic applies to Azure, where the equivalents are Microsoft Entra ID settings, storage account exposure, open network security groups and Defender for Cloud recommendations, covered in our Azure security assessment checklist.
Which common AWS misconfiguration should you fix first?
Fix anything that exposes data or access to the internet first: public buckets, open security groups, public databases and the root account. Then fix identity weaknesses such as wildcard policies and old keys, then close the visibility gaps. Exposure outranks hygiene, because an attacker only needs one open door.
What do these misconfigurations have in common?
Almost all of them are defaults left in place or shortcuts that were never revisited. Someone opened a port for a test, widened a policy to unblock a deadline, or never turned on logging in a new region. That is why a repeatable checklist beats clever tooling. Our AWS security audit checklist turns these checks into a full review, and our guide to AWS IAM mistakes goes deeper on the identity ones.
If you want an independent review, our AWS security audit covers every area above, with ranked findings and exact fixes quoted at a fixed price. Book a free 20-minute assessment to get started.
The bottom line
Most common AWS misconfigurations are cheap to find and cheap to fix once you look. Check the root account, public exposure, IAM, encryption, logging and alerting, and make the checks routine rather than occasional.
Last updated: 11 October 2026 · Written by AegisElligent.