S3 IAM vs Bucket Policies: Differences, Examples, and When to Use Each

Simple explanation

An IAM policy answers the question: “What is this identity allowed to do?” It is attached to an IAM user, group, or role, and can grant or deny access to any AWS service including S3. IAM policies are the right tool when you want to control what your application roles, developers, or automation accounts can do inside your own AWS account.

A bucket policy answers the question: “Who is allowed to access this bucket?” It is attached directly to the S3 bucket, not to any user. Because it lives on the bucket, it can grant access to principals outside your account: other AWS accounts, AWS service principals like CloudFront, or even anonymous public users.

The two systems overlap. Both can allow or deny the same S3 actions. The difference is where the policy is attached and what kinds of principals it can reach.

For access within a single AWS account, an IAM policy on the role or user is usually all you need. For anything involving other accounts, AWS services, or bucket-wide security controls like enforcing HTTPS, you need a bucket policy.

Quick answer

IAM policies vs bucket policies at a glance

When to use IAM policies

IAM policies are the right choice for granting access to identities inside your own AWS account. They are managed through IAM, which means you can apply the same policy to multiple roles or update access centrally without touching the bucket.

Use an IAM policy when:

• Your application role needs S3 access. Attach a policy to the Lambda function’s execution role or EC2 instance profile. The policy can scope access to a specific bucket and prefix. No bucket policy required.
• A developer or team needs read access. Attach the policy to the IAM user, group, or SSO permission set. Keep it scoped to the specific buckets and prefixes they need.
• You want least-privilege access to a prefix. IAM policies support Resource with prefix-level ARNs like arn:aws:s3:::my-bucket/uploads/*, so you can grant write access to one folder without exposing the whole bucket. See the least privilege guide for patterns.
• You want to reuse permissions across multiple resources. An IAM policy can reference multiple S3 buckets, letting one role access the buckets it needs without defining a policy on each bucket separately.

For the mechanics of how IAM policies are structured, see IAM policy structure.

When to use bucket policies

Bucket policies are required any time the entity accessing the bucket is not an IAM identity in your account.

Use a bucket policy when:

• Another AWS account needs access. A bucket policy is the only way to grant access to an external account. The external account’s user or role also needs an IAM policy on their side, and both sides must allow.
• CloudFront or another AWS service needs to read objects. Services like CloudFront authenticate with a service principal, not an IAM role in your account. A bucket policy is the correct mechanism.
• You need to enforce HTTPS across all principals. A bucket policy with a Deny on non-HTTPS requests applies to every caller, including those allowed by IAM policies. This is the standard pattern for bucket-wide security enforcement.
• You want to centrally manage who can access one bucket. If access decisions should live on the bucket itself for auditing, compliance, or simplicity, a bucket policy keeps everything in one place.
• You need to allow public access. Only a bucket policy with "Principal": "*" can make objects publicly readable. Block Public Access must also be configured appropriately at the account and bucket level.

For a broader view of S3 security controls, see S3 security best practices.

How S3 permission evaluation works

When a request arrives at S3, AWS evaluates all applicable policies and determines the result in this order:

1. Explicit Deny wins. If any policy (IAM or bucket) contains an explicit "Effect": "Deny" that matches the request, the request is denied. No other policy can override an explicit Deny.

2. Allow grants access. If any applicable policy grants an "Effect": "Allow" and there is no explicit Deny, the request is allowed.

3. Implicit Deny is the default. If no policy explicitly allows the action, the request is denied. This is the default for all S3 actions.

Same-account access: When an IAM user or role in the same account makes a request, S3 checks both the IAM policy and any bucket policy that exists. Either one can grant access. An explicit Deny in either overrides any Allow elsewhere.

Cross-account access: When a principal from an external account makes a request, both sides must independently allow the action. The bucket policy must allow the external principal, and the external account’s IAM policy must allow the S3 actions. If either side is missing an Allow, the request is denied even if the other side is fully permissive.

The explicit Deny rule

This matters most in three situations:

• HTTPS enforcement. A bucket policy with a Deny on non-HTTPS requests applies to every caller, including those with IAM Allows.
• Overly broad Deny statements. A poorly scoped Deny on "Principal": "*" can accidentally block AWS services from writing to your bucket.
• SCPs. A service control policy in AWS Organizations can deny S3 actions before the request even reaches your IAM policy or bucket policy.

Real examples

Same-account IAM role: read and write to a prefix#

Attach this IAM policy to the role used by your application server or Lambda function. No bucket policy is needed for same-account access.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AppRoleUploadsAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-app-assets/uploads/*"
    },
    {
      "Sid": "AppRoleListPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-app-assets",
      "Condition": {
        "StringLike": {
          "s3:prefix": "uploads/*"
        }
      }
    }
  ]
}

CloudFront: read objects from a private bucket#

This bucket policy allows a specific CloudFront distribution to read objects. The Condition block scopes access to one distribution so no other CloudFront distribution can access the bucket. See S3 buckets explained for background on origin access control.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontOAC",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-static-site/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

Cross-account: allow an external account to upload objects#

This bucket policy allows an IAM role in account 987654321098 to upload objects. That account’s IAM policy must also allow the S3 actions. The bucket policy alone is not enough.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CrossAccountUpload",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:role/DataPipelineRole"
      },
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": "arn:aws:s3:::my-shared-bucket/incoming/*"
    }
  ]
}

Deny all non-HTTPS requests#

This bucket policy applies to every principal, including those allowed by IAM policies. Because it uses an explicit Deny, it cannot be overridden.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-app-assets",
        "arn:aws:s3:::my-app-assets/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

IAM policies vs bucket policies vs ACLs

S3 also has a third access control mechanism: access control lists (ACLs). ACLs predate IAM and bucket policies and are now considered legacy.

ACLs are applied per-object and use a fixed set of permissions (READ, WRITE, FULL_CONTROL). They cannot express conditions, cannot reference IAM roles, and are harder to audit than policies. For most workloads, you should not use them.

Object Ownership is the setting that controls whether ACLs are active at all. When Object Ownership is set to Bucket owner enforced, the current AWS default for new buckets, ACLs are disabled entirely and all access control is handled through IAM policies and bucket policies.

For any new bucket or access control design, use IAM policies and bucket policies. They are more expressive, consistent with the rest of AWS access control, and far easier to audit. For conditions-based access patterns, such as restricting access by IP, VPC, MFA, or encryption state, see IAM policy conditions.

Practical use cases

Internal application in one AWS account Attach an IAM policy to the application’s execution role. Scope it to the specific bucket and prefix. No bucket policy is needed unless you also want to enforce HTTPS or restrict VPC access.

Sharing a bucket with another AWS account Add a bucket policy allowing the external account’s role. Confirm that the external account also has an IAM policy allowing the S3 actions. Without both, the request will be denied.

Serving content through CloudFront Use Origin Access Control (OAC) and a bucket policy that allows the CloudFront service principal scoped to your specific distribution. Keep the bucket private and do not use a public bucket policy.

Enforcing organisation-wide bucket access rules Use a bucket policy with Deny statements for broad security controls, for example denying HTTP access or requiring encryption on upload. These controls apply to all callers regardless of their IAM policies.

Troubleshooting an S3 access denied error Access denied errors are often caused by a missing Allow in either the IAM policy or the bucket policy, or by an explicit Deny in one overriding the other. Use the troubleshooting checklist below as a starting point. CloudTrail records S3 data events and provides the exact evaluation reason when access is denied.

VPC endpoint restricting S3 access When traffic routes through a VPC endpoint for S3, the endpoint may have its own policy controlling which buckets it can reach. This is separate from both IAM policies and bucket policies. See VPC endpoint policies for how endpoint policies interact with the rest of access evaluation.

Troubleshooting checklist

When you receive an S3 AccessDenied error, work through these checks:

• Who is the caller? Run aws sts get-caller-identity to confirm the IAM principal making the request. Access denied errors are sometimes caused by the wrong role being assumed.
• Does the IAM policy allow the action? Check the IAM policy attached to the role or user. Confirm the correct bucket ARN and action are included.
• Does the bucket policy allow or deny the caller? Check the bucket policy using aws s3api get-bucket-policy --bucket <name>. Look for explicit Deny statements that may match the caller.
• Is there an explicit Deny anywhere? An explicit Deny in any policy, IAM, bucket policy, SCP, or permission boundary, overrides all Allows.
• Is Block Public Access blocking a public policy? Check account-level and bucket-level Block Public Access settings if you are trying to enable public access.
• Is Object Ownership preventing ACL-based access? If you are relying on ACLs, check whether Object Ownership is set to Bucket owner enforced.
• Is a VPC endpoint policy restricting access? If the request routes through a VPC endpoint, the endpoint policy may not allow the bucket or action. Check the endpoint policy separately.
• Is an SCP restricting S3 actions? If the account is part of an AWS Organisation, a service control policy may be denying the action before it reaches the bucket. Check SCPs in AWS Organizations.
• Check CloudTrail for the exact reason. S3 data events logged in CloudTrail include an errorCode and errorMessage that identify which policy caused the denial.