We’ve talked about security posture and Amazon Web Services (AWS) security basics, like securing containers in the unique environment that AWS offers. So in this article, we’ll go deeper into the real-world pain points, trade-offs, and strategic challenges of security posture in AWS.
Where does shared responsibility confusion leave gaps between CSPM tools and AWS-native tooling? What are the limitations of going native? And how can teams handle misconfigurations at scale, AWS tagging, and IaC drift? What about multi-account AWS environments? It’s all about making sure teams understand the options and the benefits they’ll get from each — as well as the challenges down each path.
First Things First: What is CSPM in AWS?
Cloud Security Posture Management (CSPM) is the continuous assessment of the AWS environment to identify and reduce misconfigurations, policy violations, and compliance risks. It’s a category of controls that map the cloud’s infrastructure state to compliant expectations.
Native Tools for AWS Posture Management
Native AWS services offer tools that can set the stage for a strong security posture:
- AWS Config tracks configuration changes and assesses them against rules.
- AWS Security Hub amasses findings from multiple services, from GuardDuty to Config and Inspector. It’s AWS’s central dashboard for security posture and compliance standards, like CIS Benchmarks.
- Amazon GuardDuty provides threat detection, though findings are often considered part of posture visibility.
- AWS Trusted Advisor offers account-level recommendations around security and risk tolerance.
Together, they let teams monitor the basics, like S3 bucket permissions, IAM encryption status, and public exposure. But they cover only AWS, and hybrid and multi-cloud organizations find they’ll need more comprehensive tools to cover other cloud services.
Nevertheless, Amazon’s native tools are useful: they’re tailor-made for AWS’ ecosystem, integrated from day one, and aligned with AWS’ shared responsibility model.
AWS Posture Management is More Fragmented than Other Cloud Services
AWS comes with native posture management tools, but those aren’t the only way that CSPM might look different in Amazon’s cloud. The cloud itself is unique and comes with the following differentiators:
- Posture is more fragmented across services by design. GCP and Azure centralize much of their security configuration, but AWS spreads security-relevant configurations across services, from KMS key policies to IAM policies, Lambda variables, API gateway security definitions, and S3 bucket policies.
- Identity is central. In AWS, identity means EC2 instances, Lambda functions, users, and federated roles. AWS’ flexible IAM model lets teams create complicated role chains, transitive permissions, and policy inheritance. It also leaves room for plenty of misconfigurations.
- Multi-account complexity is the norm. A multi-account strategy provides isolation and governance but posture tools can treat accounts as silos. In other clouds, account-level abstraction is simpler. But in AWS, organization-wide posture means stitching together dozens or hundreds of decentralized configurations.
- IaC Drift and ephemerality can break static posture models. AWS environments are driven by IaC and dynamic infrastructure, like Fargate and autoscaling groups. Drift is inevitable. In AWS, posture must be continuously validated against how infrastructure behaves, not just how it was initially defined.
- Tradeoffs between safety and flexibility are allowed. AWS comes with extra flexibility, and that gives teams the room to define their own granular permissions and custom resource policies. They’ll need to decide if custom encryption bests simplicity, if broad IAM roles are better than operational ease, and if they want to customize runtime or standardize it. CSPM with rigid best practices aren’t built for AWS.
Where Native Tools Fall Short
AWS tools are foundational, even in a flexible AWS environment. But used alone, they’re not comprehensive and can’t make up for some of the fundamental complexities of posture management in an AWS environment. Some key limitations include:
- Account coverage: Native tools work best at the account level, not across an entire organization’s posture.
- No graph-based content: Native tools don’t correlate relationships between resources, identities, and data.
- No drift detection via Infrastructure as code (IaC): There’s no built-in way to compare deployed infrastructure to IaC-defined intent.
- No multi-cloud visibility: Native AWS tools cover AWS, not Google Cloud Platform (GCP) or Azure.
- Limited remediation: Config can trigger remediation via Lambda, but teams need to build these pipelines themselves.
Gaps in AWS-Native CSPM: Where’s the Ongoing Risk?
AWS tools focus on flagging violations and misconfigurations in isolation — they weren’t created to manage the full picture of cloud risk. But it means teams are left on their own to answer, “What’s exploitable and matters most right now?”
According to an AWS survey, about half of clients responding use AWS Secrets Manager, 54% use IAM roles, and 41% use AWS Parameter store, with a trend toward greater adoption of AWS-native security services in general, suggesting many mid-size and enterprises rely on native tools even as they add third-party tools to the mix.
What missing pieces are key to know when thinking about living with (or eliminating) the limitations that come from AWS posture management tools?
Misconfiguration Notifications Won’t Come with Exploit Context
Security Hub might flag an open security group, but it won’t tell you if anything sensitive is exposed behind it. For instance, a wide-open port on an EC2 instance might get flagged, but it could be shielded by a VPC endpoint and unused. In the meantime, another instance with a clean configuration profile is running an outdated container with lateral movement risk and could be invisible to AWS-native posture tools.
Identity and Access Management (IAM) Risks Lack Behavior Awareness
Context is a challenge with AWS tools in general, and identity is no outlier. So while AWS Config can detect over-permissive IAM roles, it can’t tell teams who is using them or why. AWS tools may see a dormant IAM role with administrator access that’s never rotated and unused, that is, until a compromised CI/CD pipeline assumes it to deploy malware. GuardDuty won’t trigger unless there’s overt abuse, and Config won’t alert unless there’s a custom rule for unused credentials.
Cross-Account Federated Identity Relationships
Posture tools treat each AWS account on its own, which is a challenge for organizations using federated identity, account delegation, or service-based assume-role chaining. Here’s what it can look like: a user in a staging account has permission to assume a role in production. Individually, each role looks fine. Together, however, they form a privilege escalation path across boundaries, but teams will never know about it without graph-based identity correlation.
Static Snapshots vs Dynamic Risk
Posture tools typically evaluate resources at one moment in time, but workloads evolve, and posture that looks compliant may not stay that way. For instance, S3 buckets that are encrypted and private may not stay that way after a misconfigured Lambda function grants temporary access. Config won’t catch it unless someone manually writes a periodic check for this specific scenario.
Here are related examples of native-tool gaps that need to be filled for comprehensive AWS posture management.
| CSPM Gap | What’s Missed | Real-World Example |
| Tag-based Resource Ownership | No security context when the resource lacks tags or follows inconsistent naming. | An untagged RDS instance containing sensitive data is not included in compliance scans, and there’s no alert when PII is made public. |
| Data Sensitivity Awareness | CSPM flags exposure but doesn’t know if the exposed data matters. | Security Hub alerts on a public S3 bucket, but it doesn’t contain any important images. Private but accessible buckets, on the other hand, aren’t flagged. |
| Chained Misconfigurations | No correlation between individually low-risk issues that together create a breach path. | A container with no egress restrictions and permissive roles can exfiltrate secrets, but won’t result in an alert if each config looks benign on its own. |
| Temporal Drift and Ephemeral Architecture | Changes between CSPM scans are invisible. | A new EC2 instance spun up by autoscaling doesn’t inherit expected logging configs and is compromised quickly, then terminated before the next scheduled CSPM check-in. |
| Custom Logic and App-Aware Posture | NAtive CSPMs don’t integrate with application-level logic or secrets management tooling. | Lambda functions using hardcoded secrets can pass config checks because encryption is enabled, while there are no alerts on secret rotation failure. |
AWS-native tools are necessary. But they’re not sufficient. They don’t know how the cloud environment is behaving, and blind spots come from those missed escalation paths and alerts without context or prioritization. That’s why runtime-aware CSPM is key to elevating AWS-native CSPM to truly modern, comprehensive protection.
Why Runtime Protection?
Most CSPM tools, including AWS cloud-native ones, envision the cloud as a template that can be scanned, compared to best practices, and then approved. That’s helpful, but it’s also a static and idealized view of an environment that’s, in reality, constantly changing.
The issue is that misconfigurations don’t equal risk unless they’re used. And secure configurations don’t mean safety if the environment changes at runtime.
Configuration vs Behavior
Security groups can look fine until a process begins making unexpected outbound calls. An IAM role might seem appropriately scoped until it’s assumed by an automatic workflow that begins seeking secrets it has never accessed before. These aren’t configuration issues. They’re behavioral changes. And that means they won’t get picked up by CSPM tools alone.
Posture tells teams what could go wrong. Moving to a runtime mindset means looking at what is currently going wrong for more immediate remediation and results.
Risk is a Moving Target
Time is another issue with static posture management. Runtime solves the problem, reacting as the cloud changes. A container image could be replaced in a CI/CD push. A serverless function could gain a new dependency. A credential may be short-lived.
Static posture checks, even frequent ones, lag behind dynamic runtime observation.
Prioritization Without Runtime Is Just Guesswork
CSPM can generate long lists of misconfigurations. But without runtime data, which are pressing? It’s challenging to find out. Are open ports actually being scanned? Is an overly-permissive role actively used? Is a public bucket serving traffic?
Runtime-aware systems do what AWS-native tools can’t: correlate misconfigurations, identities, and containers to make for more accurate prioritization.
Upwind Augments (and Eventually Supercedes) AWS’s Native CSPM Powers
For teams with AWS-native tools as a baseline, Upwind can help build a stronger security posture by adding:
- Correlations of misconfigurations across accounts and services
- Identity context
- Runtime telemetry
- Prioritization of actual risk in addition to a mere checklist of violations
And for those going deeper, a CNAPP like Upwind can eventually replace AWS tools. CNAPPs can still ingest data from AWS Config or CloudTrail, but they will also enforce policies through their own policy-as-code engines and generate alerts in a centralized dashboard.
To see how Upwind grounds security posture management in what’s happening across cloud environments in real time, schedule a demo.
FAQ
What is Amazon Security Hub?
It’s a central aggregation point for security findings across AWS services like GuardDuty, Inspector, and Config. It helps security teams consolidate alerts and track compliance. What can teams do in AWS Security Hub?
- Aggregate findings from AWS-native tools and some third-party integrations
- Map issues to standards like CIS Benchmarks and PCI-DSS
- See basic dashboards for filtering
- Identify areas for manual remediation
- See findings that can be noisy and lack runtime and identity context
Who needs CSPM for AWS?
Any organization running production workloads in AWS needs CSPM to maintain visibility, reduce misconfigurations, and stay compliant. As environments scale, manual reviews and native tools increasingly fall short. Some key situations where CSPM is helpful include:
- Organizations using AWS for sensitive data or customer-facing apps
- Teams with multiple AWS accounts or federated identity access
- Companies subject to compliance regulations like CIS, HIPAA, SOC 2, and more
- Teams managing short-lived infrastructure like containers, serverless, or IaC
- Organizations that need to prioritize risks better, based on behavior
AWS-native tools are a good starting point, but not a full CSPM solution for AWS. They won’t correlate risks across services or accounts, prioritize based on runtime activity, or account for multi-cloud or hybrid infrastructures.
Does AWS Config count as a complete CSPM solution?
No, AWS Config is a building block, not a full CSPM. It tracks resource changes and evaluates them against the rules. However, it can’t correlate, prioritize, and respond to issues. AWS Config monitors configuration drift and enforces rules, but it lacks identity, data sensitivity, and runtime context. It won’t rank risk or relate findings across accounts. And it will mean manual effort to build remediation pipelines. In large, dynamic, multi-account environments, broader CSPM solutions make more sense.
How do posture risks change in a multi-account environment?
In multi-account AWS environments, posture risk is harder to detect, correlate, and contain. Misconfigurations may look harmless in isolation, but they form real threats when combined across accounts.
Multi-account risks include privilege escalation paths that span accounts, siloed posture tools that miss lateral movement, inconsistent tagging, and challenging enforcement across an organization’s entire ecosystem. The solution? Centralize identity and posture management across all AWS accounts using AWS Organizations and a CSPM or CNAPP that supports cross-account graph analysis.
Why is identity risk so hard to identify in AWS?
AWS identity is decentralized, flexible, and can be indirect, so it’s simple to grant access, but challenging to trace who can do what.
Permissions are split across IAM roles, resource policies, and service permissions. And access happens via assume-role, not direct user assignment. Federated identities and third-party integrations pose yet more access points. And IAM policies can look secure individually, but combine into risks that aren’t easy to see.
The bottom line: identities interact in AWS. And most tools don’t cover their behavior.
