Inline Policy Enforcement for Cloud Security Teams
Cloud security teams rarely set out to lose track of their permissions. It happens quietly, one embedded rule at a time, until an audit or an incident forces the question: who can do what, and who decided that? Inline policy enforcement is how teams answer that question with confidence. It is the practice of governing AWS Identity and Access Management (IAM) inline policies so access stays consistent, visible, and audit-ready, instead of scattered across hundreds of identities where no one can see it.
In this guide, we break down what inline policies are, where they create risk, and how to enforce policy standards at scale. Along the way, we cover when inline policies still make sense, how to audit them, and how to migrate toward a more governable approach.
What Is an Inline Policy in AWS IAM
An AWS inline policy is a set of permissions embedded directly into a single IAM identity, which can be a user, a group, or a role. The policy lives inside that one identity and nowhere else. You cannot reuse it, share it, or attach it to a second identity, because it is not a standalone resource. It exists only as part of the identity it belongs to.
That tight coupling is the defining trait of an AWS IAM inline policy. When you create the identity, the inline policy rides along with it. When you delete the identity, the policy goes too. This one-to-one design can be useful in narrow cases, but it is also the root of the visibility and governance challenges we cover below.
Explore the Future of AI Agent Governance with Drata
Get hands-on with our early-access platform, in development with select enterprises.
Key Characteristics of AWS Inline Policies
A few traits set inline policies apart from other policy types:
One-to-one relationship: Each inline policy is tied to exactly one IAM identity and cannot be shared.
Lifecycle dependency: The policy is deleted automatically when its identity is deleted.
No reusability: You cannot attach the same inline policy to multiple identities.
Embedded storage: The policy is stored as part of the identity itself, not as a separate, managed object.
How Inline Policies Attach to IAM Identities
Inline policies embed into users, groups, and roles rather than attaching as independent resources. You can add one during identity creation, or you can write one onto an existing identity later through a policy update in the console, the command line interface (CLI), or infrastructure-as-code. Either way, the result is the same: the permissions become a private part of that single identity, invisible from any central policy list.
The State of GRC in the Age of AI
Only 13% of IT and security professionals are fully confident they can see every AI tool their teams use. Download The State of GRC in the Age of AI to see what 300 practitioners revealed about governing AI faster than it's outpacing them.
AWS Inline Policies vs Managed Policies
To enforce inline policies well, you first need to know what you are choosing between. AWS gives you two broad approaches: inline policies embedded in one identity, and managed policies that exist on their own and attach to many. Understanding the difference is the foundation for every governance decision that follows.
AWS Managed Policies
An AWS IAM managed policy is a standalone policy that exists as its own resource and can attach to multiple identities. AWS managed policies are created and maintained by AWS itself, covering common job functions and service permissions. Because AWS updates them as services evolve, they offer a convenient, low-maintenance starting point, though you trade away some fine-grained control.
Customer Managed Policies
Customer managed policies are standalone policies that your organization creates and maintains. Like AWS managed policies, they attach to many identities and live independently of any single one. The difference is ownership: you define exactly what they permit, you version them, and you control when they change. This combination of reusability and control makes customer managed policies the workhorse of a well-governed AWS environment.
Key Differences Between Inline and Managed Policies
The table below summarizes how AWS inline policies and AWS IAM managed policies compare across the dimensions that matter most for governance:
Feature | Inline Policies | Managed Policies |
Reusability | Single identity only | Multiple identities |
Versioning | Not supported | Supported |
Central management | No | Yes |
Deletion behavior | Deleted with identity | Persists independently |
Visibility | Scattered across identities | Centralized view |
Security Risks of AWS Inline Policies
Most teams do not notice inline policies until something forces them to. An auditor asks for an access inventory, an incident review traces a breach to an over-permissioned role, or a new hire inherits permissions no one can explain. By then, the risk has already taken root. Because inline policies are invisible from any central view, they create blind spots that grow quietly over time.
Lack of Centralized Visibility
Inline policies hide inside individual identities, so there is no single screen that shows them all. To understand what an inline policy grants, you have to open each user, group, and role one at a time. Across a large environment, that makes it nearly impossible to see the full permission picture, and security teams cannot govern what they cannot see.
Policy Drift and Configuration Sprawl
Without central oversight, inline policies multiply. Different teams write their own one-off permissions to solve immediate problems, and those embedded rules pile up across the account. Over time, the result is configuration sprawl: inconsistent permissions, shadow access, and a posture that drifts further from what security intended—Veza's State of Access Report found compliant permissions dropped from 70% to 55% in a single year as ungoverned access expanded.
Compliance and Audit Challenges
Auditors and compliance frameworks expect documented, reviewable access controls. Scattered AWS inline policies work directly against that expectation. Pulling evidence becomes a manual hunt across identities, and any gap or stale permission becomes a finding. Manual, point-in-time reviews leave room for error, and with half of permission findings taking ~8 months to remediate, they rarely keep pace with how fast cloud environments change. This is precisely where continuous control monitoring closes the gap, surfacing inline policies continuously rather than once a year.
When to Use Inline Policies vs Managed Policies
Inline policies are not all bad. They have legitimate uses, and dismissing them outright would be a mistake. The goal of enforcement is not to ban inline policies, but to make sure each one is a deliberate choice rather than an accident. Managed policies are the sensible default; inline policies are the exception you reach for on purpose.
Appropriate Scenarios for Inline Policies
Reach for an inline policy when the permissions truly belong to one identity and one identity only:
Strict one-to-one relationships: When a policy must never apply to any other identity.
Identity-policy lifecycle coupling: When the policy should be deleted automatically along with its identity.
Preventing unintended attachment: When you need to guarantee the permissions cannot be reused elsewhere.
Appropriate Scenarios for Managed Policies
For nearly everything else, managed policies are the stronger choice:
Standardized permissions: When multiple identities need the same access.
Centralized governance: When you need visibility and control from one place.
Version control requirements: When you need to track and roll back policy changes over time.
Compliance documentation: When auditors require clear, reviewable evidence of access policies.
Best Practices for Inline Policy Enforcement
Strong inline policy enforcement is less about a single fix and more about a set of habits that keep access governable as you grow. The practices below reduce risk, cut audit effort, and keep your environment ready for review at any moment, not just at audit time.
1. Default to Managed Policies Over Inline Policies
Make managed policies the standard and inline policies the documented exception. Managed policies give you reusability, version history, and a central view, so permissions stay consistent and visible. Reserve inline policies for the narrow cases that genuinely require one-to-one coupling, and write down why each one exists.
2. Document and Tag All Inline Policies
Keep an inventory of every inline policy, with a clear note on its purpose and owner. When an inline policy is the right call, that record turns an invisible permission into a governed one. It also gives auditors and teammates the context they need without a manual investigation.
3. Implement Least Privilege Principles
Grant only the permissions an identity actually needs, and no more. Sonrai Security's analysis shows 92% of cloud identities with access to sensitive permissions never use them, reinforcing why least privilege applies to inline policies exactly as it does to any other policy. Scoping each policy tightly limits the blast radius if an identity is ever compromised, and it keeps your permissions defensible under review.
4. Monitor Continuously for Policy Drift
Inline policies change without announcing themselves, so continuous monitoring is essential to catch unauthorized edits and creeping sprawl. Rather than rely on periodic manual sweeps, teams can monitor policy configurations continuously and get real-time alerts when something drifts. Platforms like Drata automate this monitoring, so drift surfaces between audits instead of only at the next review.
28%
Only 28% of organizations monitor their security controls continuously in real time — 72% still rely on periodic assessments.
RegScale State of CCM Report 20265. Automate Policy Reviews and Evidence Collection
Manual reviews are slow, and they age the instant they finish. Automating access reviews and evidence collection keeps controls tested and documented on an ongoing basis. Drata's continuous compliance capabilities streamline this work by collecting evidence automatically and keeping it current, which removes much of the manual burden that makes inline policies so hard to govern.
How to Audit AWS IAM Inline Policies
Before you can enforce a standard, you need to know what already exists. Auditing surfaces every AWS IAM inline policy in your environment so you can decide what to keep, fix, or migrate. You can do this through the console for a quick visual review, or through the CLI when you need to query at scale.
Audit Inline Policies Using AWS Console
The console is the fastest way to spot-check a handful of identities:
Navigate to the IAM dashboard.
Select Users, Groups, or Roles.
Review the Permissions tab for each identity.
Identify any policies marked as inline rather than managed.
Audit Inline Policies Using AWS CLI
For a thorough, repeatable sweep, the CLI is the better tool:
List embedded policies with list-user-policies, list-group-policies, or list-role-policies.
Retrieve the details of each with get-user-policy, get-group-policy, or get-role-policy.
Export the results so you can review and document them.
Even with the CLI, doing this by hand across many accounts is tedious and easy to let slip. A governance, risk, and compliance (GRC) platform can automate the discovery and documentation of inline policies, so the inventory stays current without a recurring manual project.
How to Migrate from Inline Policies to Managed Policies
Cleaning up legacy inline policies is one of the highest-value moves a cloud security team can make. A careful migration replaces scattered, embedded permissions with reusable, centrally managed ones, without breaking the access people rely on. Work through it in deliberate steps.
1. Inventory All Existing Inline Policies
Start by cataloging every inline policy across all IAM identities, using the CLI commands above or automation tooling. You cannot migrate what you have not found, so a complete inventory comes first.
2. Analyze Policy Permissions and Dependencies
Review what each inline policy permits and which identities depend on those permissions. This step tells you which policies can be consolidated, which are duplicates, and which protect something fragile that needs careful handling.
3. Create Equivalent Customer Managed Policies
Build customer managed policies that replicate the necessary permissions in a reusable, centralized form. Group common patterns so several identities can share one policy, which is the whole point of moving away from inline.
4. Test and Validate Access Before Removal
Attach the new managed policies and confirm that access works exactly as expected before you remove anything. Validating first prevents the outages and lockouts that make teams afraid to clean up in the first place.
5. Remove Inline Policies and Document Changes
Once the managed policies are proven, delete the inline policies and record what changed and why. That documentation becomes part of your compliance evidence and saves the next person from reverse-engineering your decisions.
Automating Inline Policy Governance at Scale
Manual approaches hold up for a handful of identities. Across hundreds of accounts and thousands of roles, they break down completely. At enterprise scale, no team can manually track every inline policy, catch every change, and map each one to a control. This is where compliance automation stops being a convenience and becomes a requirement.
Automation platforms can carry the load that manual review cannot:
Continuously scan for inline policies across all of your accounts.
Flag identities that carry inline or directly attached policies, so sprawl does not go unnoticed.
Map policies to compliance controls so your environment stays audit-ready.
Generate evidence automatically for frameworks like SOC 2 and ISO 27001.
Drata's platform brings these capabilities together with continuous control monitoring and automated evidence collection. Its read-only AWS integration includes automated tests such as AWS IAM Group-Based Access Control, which flags IAM users that carry inline or directly attached policies, and AWS IAM Principle of Least Privilege, which checks for overly broad permissions. That gives security teams continuous visibility into IAM configurations, so inline policy governance happens in the background instead of consuming a quarter of every audit cycle.
Strengthen IAM Policy Compliance with Continuous Monitoring
Inline policy enforcement is not a one-time cleanup; it is part of an ongoing cloud compliance strategy. You can inventory and migrate today, but new inline policies will appear tomorrow, and drift will resume the moment monitoring stops. Trust in a cloud environment depends on continuous visibility into who can do what, verified in real time rather than reconstructed once a year.
Inline policies are just one piece of the broader IAM governance puzzle. Teams move faster and sleep better when a platform watches their controls automatically and surfaces risk as it emerges. That is the shift from reactive cleanup to continuous assurance, and it is where modern security teams are headed.
FAQs About Inline Policy Enforcement
How many inline policies can you attach to a single IAM identity in AWS?
AWS does not cap the number of inline policies you can embed in an IAM user, group, or role. Instead, it limits the combined size of all inline policies on each identity: 2,048 characters for a user, 5,120 for a group, and 10,240 for a role. These size limits are fixed and cannot be increased, and AWS does not count white space toward them. AWS publishes the current figures in its IAM and STS quotas documentation, so confirm there before you rely on a specific number.
Can AWS inline policies be versioned like managed policies?
No. Inline policies do not support versioning, so you cannot roll back changes or review policy history the way you can with customer managed policies. Once you edit an inline policy, the previous version is gone, which is one more reason centralized managed policies are easier to govern.
Do inline policies count against AWS IAM policy limits separately from managed policies?
Yes. The size limits on inline policies are separate from the limits on attached managed policies. An identity can hold inline policies up to its character limit and still attach managed policies up to its own managed policy quota, because AWS tracks the two independently.
How do compliance frameworks like SOC 2 address inline policy requirements?
Frameworks such as SOC 2 and ISO 27001 expect documented, reviewable access controls rather than calling out inline policies by name. Scattered inline policies make that evidence harder to produce, so maintaining a centralized inventory and continuous monitoring keeps you aligned with what auditors look for.
What happens to an inline policy when you delete the associated IAM identity?
The inline policy is deleted automatically along with the identity, because it exists only as an embedded part of that user, group, or role. There is no separate resource left behind, which is exactly why inline policies cannot be reused or recovered once their identity is gone.