What breaks when AWS default roles are granted AmazonS3FullAccess?

Why This Matters for Security Teams

Granting AmazonS3FullAccess to a default AWS role breaks the assumption that the role is limited to one service’s narrow job. Once that boundary is gone, the role can read and alter object data used by CloudFormation stacks, SageMaker jobs, EMR pipelines, and Glue workflows. That creates a direct path from one compromised workload into multiple others, turning ordinary storage permissions into a control-plane and data-plane risk.

This is not just about over-permissioning. It is about workload identity being trusted to act on assets that other services implicitly depend on. Current guidance from the OWASP Non-Human Identity Top 10 treats excessive privilege on service identities as a primary failure mode, and NHI Management Group has documented how pervasive that problem is in practice in the Ultimate Guide to NHIs. In practice, many security teams discover the blast radius only after a workload has already altered downstream inputs, rather than through intentional design review.

How It Works in Practice

Default AWS roles are often created to let a managed service read a specific bucket, write logs, or fetch a configuration object. When AmazonS3FullAccess is attached, that role no longer has a bounded relationship to a single dataset. It can enumerate buckets, inspect objects, replace model inputs, tamper with IaC artifacts, or poison data pipelines that trust S3 as a source of truth. In effect, S3 becomes a cross-service dependency layer that an attacker can use for lateral movement.

That matters because modern AWS workloads do not consume S3 in isolation. CloudFormation may load templates from buckets, SageMaker may fetch training data or model artifacts, EMR may process staged files, and Glue may ingest scripts or catalog inputs. If any of those services trust the bucket contents, a compromised role can change execution behavior without ever touching the target service directly.

• Use least privilege on each workload role, scoped to exact bucket ARNs and object prefixes.
• Separate read, write, and delete permissions so one role cannot rewrite trusted inputs.
• Apply bucket policies and object ownership controls to prevent cross-account or cross-role abuse.
• Require logging and alerting for unusual list, put, delete, and overwrite activity on sensitive buckets.
• Review whether the role can reach buckets used by automation, not just application data.

The Amazon AWS Hacked Accounts Crypto-Mining research shows how quickly compromised cloud identities can be repurposed once access is too broad, and the Codefinger AWS S3 ransomware attack illustrates the operational impact of S3 abuse when storage is no longer a passive dependency. These controls tend to break down when legacy default roles are reused across multiple pipelines because the original service boundary is already blurred.

Common Variations and Edge Cases

Tighter S3 scoping often increases deployment overhead, requiring organisations to balance fast service enablement against the risk of hidden dependency coupling. The hard part is not just permission size, but understanding which buckets are effectively part of a service’s runtime contract.

There is no universal standard for this yet, but current guidance suggests treating buckets that carry templates, model artifacts, scripts, and configuration as high-trust inputs. That means a role may need read access to one prefix while being denied write access everywhere else, especially if downstream services execute code or load infrastructure definitions from the bucket.

Edge cases appear when teams rely on shared buckets for convenience, when service teams inherit roles from older automation, or when data scientists and platform engineers both assume S3 objects are immutable. In those environments, AmazonS3FullAccess can silently collapse separation of duties even if the application itself looks segmented.

For broader identity context, the Ultimate Guide to NHIs — Key Challenges and Risks is useful for understanding why excessive privileges and weak lifecycle controls so often travel together. The practical takeaway is simple: if a role can rewrite shared inputs, it can influence more than storage, and that is where the blast radius starts.

Related resources from NHI Mgmt Group

• What breaks when AWS access is granted through broad admin roles?
• What breaks when MongoDB roles are granted broadly for convenience?
• What breaks when AI access is granted with broad Contributor roles?
• What breaks when organisations cannot see how access is granted through roles, groups, and trust relationships?