What Are AWS Misconfigurations? Common Cloud Risks

A storage bucket gets created for a quick test, set to public so a teammate can grab a file, and never locked back down. Eighteen months later it holds a copy of production data, and a researcher finds it by guessing the bucket name. Nothing was hacked. No exploit ran. The access was configured open, written down in a policy, and forgotten. This is what most AWS incidents look like: not a breach of AWS, but a setting the customer owned and got wrong.

AWS misconfigurations are insecure settings on resources you control: a storage bucket left public, an IAM policy that grants far more than the job needs, a security group that opens a database port to the entire internet, encryption left off, logging never turned on. They are the dominant root cause of cloud incidents because they require no vulnerability. The resource behaves exactly as configured, and it was configured to expose itself. This guide covers the shared responsibility model that puts these settings on you, the misconfiguration categories that recur in real investigations, how each one is exploited, and how to detect and prevent them with the AWS services built for the job. It is written for the people who have to find these settings after the fact: SOC analysts, threat hunters, and DFIR responders working cloud forensics cases.

Why AWS misconfigurations matter: the shared responsibility model

Before any specific setting, the reason misconfigurations land on you. AWS operates a shared responsibility model, and it draws a hard line. In AWS's own words, AWS is responsible for "security of the cloud" and the customer is responsible for "security in the cloud." AWS owns the physical data centers, the hardware, the hypervisor, and the managed-service software. You own everything you put on top: your data, your IAM policies, your network rules, your encryption choices, your operating-system patching on EC2. Getting this side right is the whole of AWS cloud security practice.

A misconfiguration is, by definition, a failure on the customer side of that line. AWS will not stop you from making an S3 bucket public, attaching an administrator policy to a service account, or opening port 3389 to the world, because those are decisions inside your half of the model. The platform gives you secure defaults and the tools to enforce a tight posture, then steps back and does what you tell it. That is why "AWS got breached" almost never describes what happened. The data center held. The configuration did not.

The defender's takeaway is that the entire attack surface here is configuration, and configuration is auditable. Every misconfiguration is a recorded state in an API somewhere, which means it is detectable, queryable, and fixable before someone finds it for you. The rest of this guide is the catalog of what to look for.

The most common AWS misconfigurations

The same handful of mistakes drive most cloud exposure. Each one is a default that was loosened, a permission granted too broadly, or a control that was never turned on.

Public S3 buckets and objects. The classic. A bucket policy, an object ACL, or a disabled Block Public Access setting makes storage readable, or writable, by anyone on the internet. Modern AWS defaults work against this: for new buckets, AWS enables S3 Block Public Access by default and disables ACLs, so a fresh bucket is private unless someone actively opens it. Block Public Access has four settings, BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets, and exposure usually comes from turning these off or overriding them with a bucket policy whose Principal is "*". Older buckets predate the safe defaults and are the ones most often found open.

Over-permissive IAM. Identity and Access Management is where access is decided, and the recurring failure is granting too much of it. The textbook smell is a policy with "Action": "*" on "Resource": "*", which grants every action on every resource. Less obvious versions are nearly as dangerous: a service account with full administrator access because scoping it down "took too long," wildcards on a whole service (s3:*), or use of the account root user for daily work. AWS's guidance is explicit on least privilege: grant only the permissions a task requires, and use roles with temporary credentials rather than long-lived access keys.

Open security groups (0.0.0.0/0). A security group is the instance-level firewall. By default it denies all inbound traffic and allows all outbound, and it is stateful, so return traffic is permitted automatically. The misconfiguration is an inbound rule with the source set to 0.0.0.0/0, which means any IPv4 address on the internet (::/0 is the IPv6 equivalent). Opening 0.0.0.0/0 on a web port like 443 may be intentional. Opening it on SSH (22), RDP (3389), or a database port (3306, 5432) exposes administrative and data services to the entire internet, where automated scanners find them within minutes.

Disabled or unmonitored logging. AWS CloudTrail records API and account activity, and its Event history gives you the last 90 days of management events per Region with no setup. But that default view is not a durable audit log: to retain events beyond 90 days, deliver them to S3, and feed detection, you must create a trail. Accounts that never create a trail, or that disable one, have no reliable record of who did what. Without it, an investigation reconstructs the incident from gaps.

Unencrypted storage. Encryption at rest is not on by default for everything. EBS volumes are unencrypted unless you enable encryption, and Amazon RDS databases can only be encrypted at creation time, not after. Snapshots inherit the encryption state of their source, so an unencrypted volume produces unencrypted snapshots. The fix is to turn on account-level "EBS encryption by default," which is a per-Region setting, and to create RDS instances with encryption enabled from the start.

Public snapshots and RDS instances. A subtler exposure than a public bucket. EBS and RDS snapshots can be shared, and the sharing scope can be set to public, which lets any AWS account restore your data into their own account. AWS warns plainly that a public RDS snapshot means "all AWS accounts can restore a DB instance from your manual DB snapshot and have access to your data." Encrypted snapshots cannot be made public, which is one more reason to encrypt. Separately, an RDS instance set to "publicly accessible" with an open security group is a database reachable from the internet.

How attackers exploit AWS misconfigurations

The exploitation path is short because there is no exploit. The misconfiguration is the access.

A public bucket is found by enumeration. Bucket names share a global namespace, and attackers run wordlists against it, then probe each hit for public read or, worse, public write. A readable bucket leaks whatever is in it. A writable one lets an attacker plant files, including overwriting a static site's JavaScript to attack the site's visitors.

Over-permissive IAM turns one foothold into account-wide control. An attacker who phishes or finds a leaked access key inherits exactly what that identity can do. If the key belongs to an over-privileged service account, the attacker can read every bucket, launch instances for cryptomining, create new admin users for persistence, and disable logging to cover the trail. Least privilege is what bounds that blast radius; its absence is what makes a single leaked key catastrophic.

An open security group is found by scanning. Internet-wide scanners catalog every exposed port continuously, so an SSH or RDP port open to 0.0.0.0/0 is an invitation to credential-stuffing and brute-force attempts that begin within minutes of the port opening. An exposed database port skips the host entirely and attacks the data directly.

Public snapshots are the quiet one. An attacker does not need your account at all. They enumerate publicly shared snapshots across AWS, restore yours into their own account, and mount it to read everything it held. The owning account often never sees a single suspicious API call, because the read happened somewhere else entirely.

How defenders detect and prevent AWS misconfigurations

Because every misconfiguration is a recorded resource state, detection is a query, not a guess. Four AWS services do the heavy lifting, and infrastructure-as-code scanning catches the rest before deployment.

AWS Config records the configuration of your resources over time and evaluates them against rules. It answers "which buckets are public right now," "which security groups allow 0.0.0.0/0 on port 22," and "which EBS volumes are unencrypted," and it flags the noncompliant ones continuously as configurations change.

AWS Security Hub aggregates findings from other services and runs automated checks against security standards, including the CIS AWS Foundations Benchmark and the AWS Foundational Security Best Practices standard. It is the single pane that turns scattered findings into a prioritized list, and the standards encode exactly the misconfigurations in this guide.

Amazon GuardDuty is the threat-detection layer. It continuously analyzes CloudTrail management events, VPC Flow Logs, and DNS logs to flag behavior that looks like compromise: an instance talking to a known command-and-control host, credentials used from an anomalous location, reconnaissance API patterns. Config tells you a door is open; GuardDuty tells you someone walked through it.

AWS CloudTrail is the foundation under all of it. Create a trail, deliver it to S3, and you have the durable record of every API call. For a defender comparing CloudTrail to the metrics-focused CloudWatch, the distinction matters: CloudTrail is the audit log of who did what, and it is the first thing an investigation needs. See the CloudTrail vs CloudWatch breakdown for where each one fits.

Infrastructure-as-code scanning shifts all of this left. When resources are defined in Terraform or CloudFormation, tools like checkov, tfsec, and cfn-nag scan the templates in the pipeline and fail the build on a public bucket or an open security group before it ever reaches AWS. The cheapest misconfiguration to fix is the one that never deploys.

Common AWS misconfigurations, risk, and fix

The catalog in one view. Each row is a setting to check, what it exposes, and the control that closes it.

The pattern across the table is that the fix is almost always "use the secure default and do not loosen it," paired with "turn on the control that proves you did." None of these require a product purchase. They require knowing the setting exists and auditing for it.

The bottom line

AWS misconfigurations are the dominant cause of cloud incidents because they need no exploit. The shared responsibility model puts data, identity, network, and encryption settings on the customer, and a misconfiguration is a failure on that side of the line: a public bucket, an IAM policy that grants everything, a security group open to 0.0.0.0/0, logging never enabled, storage left unencrypted, a snapshot shared with the world. Each is exploited by simply using the access it grants.

The defender's advantage is that every one of these is a recorded resource state. AWS Config queries the posture, Security Hub measures it against known benchmarks, GuardDuty catches active abuse, CloudTrail records the evidence, and IaC scanning stops the bad setting before it deploys. The work is not exotic. It is knowing which defaults to keep, auditing for the ones that were loosened, and turning on the controls that prove your account is configured the way you think it is.