43 Misconfigurations Per Account: The Public Cloud Security Tax

The average AWS account carries 43 active misconfigurations at any given time. Not 43 over its lifetime. 43 right now, today, sitting in production.

That number comes from SentinelOne's published cloud security research, and it should stop you for a second. Most engineering teams think of misconfigurations as occasional mistakes: someone left a port open, someone forgot to rotate a key. The data says otherwise. Misconfiguration is not the exception in public cloud. It is the baseline state.

This matters because misconfiguration is now the leading cause of cloud security incidents. Industry research consistently puts the share of cloud security incidents caused directly by misconfiguration at around 23%, and Exabeam's research puts the broader picture in focus: 82% of cloud misconfigurations are caused by human error, not software flaws. The infrastructure is not failing. The people configuring it are running out of capacity to keep up with it.

The Five Misconfigurations You'll Find in Almost Every AWS Account

These aren't exotic vulnerabilities. They're the same five issues, showing up account after account, because they're the predictable result of how public cloud is structured.

1. Open S3 Buckets

S3 storage is private by default, but a single misapplied bucket policy, a public read ACL added for a one-time file share and never removed, or a third-party tool that quietly broadens permissions can expose an entire bucket to the internet. This is the most publicized misconfiguration type because the consequences are visible: leaked data shows up in breach disclosures with a bucket name attached.

2. Weak IAM Policies

AWS Identity and Access Management is powerful, granular, and easy to get wrong. Over-broad policies, wildcard permissions, and roles that accumulate access over time without anyone pruning them are extremely common. A policy written to "just get something working" during a deploy rarely gets revisited once it does.

3. Exposed API Keys

Credentials end up in public GitHub repositories, in CI/CD logs, in client-side JavaScript, and in Slack messages more often than most teams want to admit. Automated scanners crawl public code repositories around the clock looking for exactly this. Once a key is exposed, the time to exploitation is measured in minutes.

4. Over-Permissioned Roles

Service roles and EC2 instance roles are frequently granted far more access than the workload actually requires, because scoping permissions precisely takes more time than granting broad access and moving on. Each over-permissioned role is a larger blast radius if that specific service or instance is ever compromised.

5. Disabled CloudTrail Logging

CloudTrail is AWS's audit log. It is also one of the first things an attacker with sufficient access will try to disable, because it is the record that would otherwise reveal what they did. Even without malicious intent, CloudTrail is sometimes left off in specific regions or for specific event types simply because nobody configured it everywhere.

Why These Aren't Operator Failures

It's tempting to read that list and conclude the problem is careless engineers. That's the wrong conclusion, and it's worth being precise about why.

A modern AWS account isn't one system. It's hundreds of independent services, each with its own permission model, its own defaults, its own configuration surface, and its own way of quietly drifting out of its intended state over time. No single engineer holds a complete mental model of all of it. No single team reviews all of it on a consistent cadence, because reviewing it consistently is itself a full-time job that competes directly with shipping product.

43 misconfigurations per account isn't a statement about how careless any particular team is. It's a statement about what happens when you ask a small team to maintain a unified security baseline across an environment that was never designed to have one. The complexity outpaces the headcount. Every account drifts, because every account is too large and too dynamic for manual oversight to keep pace with it.

This is structural, not personal. And a structural problem needs a structural fix, not a reminder to be more careful.

The Architectural Fix: Remove the Surface Area, Not Just the Symptoms

Security checklists, automated scanners, and policy-as-code tools all help. They also all share the same limitation: they catch misconfigurations after they exist, inside an environment that is still fundamentally built to produce them.

InMotion Cloud takes a different approach. In a managed private cloud environment, the customer doesn't own the hundreds of independent service configurations that create this problem in the first place. InMotion Cloud's engineering team manages the hardware, the hypervisor and OS patching, network configuration and security groups, and storage management as a unified, consistently maintained baseline, not 43 separate surfaces drifting independently. There's no sprawling matrix of IAM policies across dozens of services because the managed layer isn't built as a sprawling matrix.

This is the difference between a managed security posture and an audited one. An audit finds the 43 misconfigurations. A managed architecture means there are far fewer places for them to accumulate.

What This Means for Your Team

If you're running production workloads on AWS today, the data says you almost certainly have misconfigurations in your account right now, not because your team is falling short, but because that's the statistical reality of managing infrastructure at this level of complexity. The honest next step isn't a one-time audit. It's asking whether your team should be carrying that surface area at all.

For teams evaluating whether to keep managing that complexity in-house or shift to a managed private cloud model, the question worth asking isn't "how do we find our misconfigurations." It's "how much of this surface area do we actually need to own."

If you want to see what your environment looks like from a managed architecture standpoint, we can walk through it on a call, no audit checklist, just a direct look at where your surface area sits and what reducing it would actually involve.
Schedule A Call