S3 Bucket Policy: What It Is and When to Use It

Definition

An Amazon S3 Bucket Policy is a resource-based AWS Identity and Access Management (IAM) policy that you attach directly to an S3 bucket. It provides granular control over which actions principals (users, roles, services, or other accounts) can perform on the bucket and the objects within it, and under what conditions those actions are permitted or denied.

How It Works

An S3 Bucket Policy is a JSON document that defines access permissions. When a request is made to S3, AWS evaluates all applicable policies—including IAM user/role policies and the bucket policy—to determine whether to allow or deny the request. The evaluation logic follows a key principle: an explicit Deny in any policy always overrides an Allow.

The structure of a bucket policy consists of one or more statements, each containing the following core elements:

• Version: Specifies the policy language version, typically "2012-10-17".
• Statement: A container for one or more individual permission rules.
• Sid (Statement ID): An optional identifier for a statement, useful for organization and management.
• Effect: Can be Allow or Deny.
• Principal: The user, account, service, or other entity that is allowed or denied access. This is a key element for granting public or cross-account access. You can specify an AWS account ARN, an IAM user/role ARN, a service principal (e.g., logging.s3.amazonaws.com), or a wildcard (*) for anonymous access.
• Action: The specific S3 API operations the statement applies to, such as s3:GetObject (read an object) or s3:PutObject (write an object).
• Resource: The Amazon Resource Name (ARN) of the bucket and/or objects the statement affects. For example, arn:aws:s3:::my-example-bucket/* refers to all objects within the my-example-bucket.
• Condition: Optional constraints that must be met for the policy to apply. This is a powerful feature for enforcing security controls, such as restricting access to a specific range of IP addresses (aws:SourceIp), requiring requests to use HTTPS (aws:SecureTransport), or mandating server-side encryption on object uploads.

Key Features and Limits

• Resource-Based Control: Policies are attached directly to the S3 bucket, providing a centralized point of access management for that specific resource.
• Policy Size Limit: An S3 bucket policy document is limited to a maximum size of 20 KB.
• Cross-Account Access: Bucket policies are the most direct and common method for granting other AWS accounts permission to access objects in your bucket without needing to configure complex IAM roles.
• Public Access Management: While bucket policies can grant public (anonymous) access, this is strongly governed by the S3 Block Public Access feature. This account-level or bucket-level safety feature is enabled by default for all new buckets and will override any policy that allows public access, preventing accidental data exposure.
• Fine-Grained Conditions: Supports a wide range of condition keys to enforce specific security requirements, such as restricting access to a Virtual Private Cloud (VPC) endpoint or based on object tags.

Common Use Cases

1. Hosting a Static Website: Granting public, read-only access to all objects in a bucket by allowing the s3:GetObject action for an anonymous principal ("Principal": "*"). This use case requires disabling S3 Block Public Access for the bucket.
2. Granting Cross-Account Access: Allowing a specific partner's AWS account to programmatically upload or download objects, which is common in data sharing and data lake scenarios.
3. Enforcing Encryption: Denying any s3:PutObject request if it does not include a header specifying server-side encryption, ensuring all data written to the bucket is encrypted at rest.
4. Restricting Access to a Corporate Network: Allowing access to sensitive data only if the request originates from a trusted range of IP addresses associated with a corporate office or VPN.
5. Creating a Log Bucket: Permitting an AWS service, like AWS CloudTrail or Elastic Load Balancing, to write log files to a centralized bucket by specifying its service principal.

Pricing Model

There is no additional charge for creating, managing, or using S3 Bucket Policies. Costs are incurred based on standard Amazon S3 usage, which includes:

• Storage: Per-GB-month cost, which varies by S3 storage class.
• Requests and Data Retrievals: Charges for actions like PUT, COPY, POST, LIST, and GET.
• Data Transfer: Data transferred out of an S3 bucket to the internet or other AWS Regions incurs charges, though data transfer into S3 is free.

You can estimate your S3 costs using the AWS Pricing Calculator.

Pros and Cons

Pros:

• Provides centralized, explicit control over all permissions for a single bucket.
• The simplest and most direct way to grant cross-account access to S3 resources.
• Powerful conditional logic allows for implementing sophisticated security controls (e.g., IP-based restrictions, encryption enforcement).
• Essential for specific use cases like granting anonymous access for static website hosting.

Cons:

• The 20 KB policy size limit can be a constraint for buckets with extremely complex, fine-grained permission requirements.
• A misconfigured policy can inadvertently expose sensitive data, although the S3 Block Public Access feature provides a critical safeguard against this.
• Managing many unique bucket policies across an organization can become complex without automation and clear auditing procedures.

Comparison with Alternatives

S3 Bucket Policies vs. AWS IAM Policies

• Type: A bucket policy is a resource-based policy attached to an S3 bucket. An IAM policy is an identity-based policy attached to a user, group, or role.
• Scope: A bucket policy defines who can access this specific bucket. An IAM policy defines what resources (including S3 buckets) this specific user/role can access.
• When to Use: Use a bucket policy for bucket-wide permissions, especially for granting cross-account or public access. Use an IAM policy to manage permissions for your users and roles across multiple AWS services. For access within the same account, either can be used, but for cross-account access, both the IAM policy of the principal and the bucket policy of the resource must grant permission.

S3 Bucket Policies vs. S3 Access Control Lists (ACLs)

• Legacy vs. Modern: ACLs are a legacy access control mechanism that predates IAM. AWS strongly recommends using bucket policies and IAM policies for modern access control.
• Granularity: Bucket policies offer far more detailed control through conditions and a wider range of specifiable actions. ACLs provide only basic permissions like READ, WRITE, and FULL_CONTROL.
• Management: For all new S3 buckets created today, ACLs are disabled by default to simplify access management. Policies provide a centralized, easier-to-audit method of controlling bucket access.

Exam Relevance

S3 Bucket Policies are a core topic on several AWS certification exams, particularly those focused on architecture, security, and development.

• Certifications: AWS Certified Solutions Architect – Associate (SAA-C03) & Professional (SAP-C02), AWS Certified Security – Specialty (SCS-C02), AWS Certified Developer – Associate (DVA-C02).
• Key Topics to Know:
  • The fundamental difference between resource-based (bucket policy) and identity-based (IAM policy) policies.
  • The policy evaluation logic, especially that an explicit Deny always wins.
  • How to correctly configure a policy for cross-account access.
  • The critical role of S3 Block Public Access and how it overrides policies that grant public access.
  • Using the Condition element to enforce security controls like requiring MFA, restricting by IP address, or forcing encryption.

Frequently Asked Questions

Q: What is the difference between an S3 Bucket Policy and an IAM Policy?

A: An S3 Bucket Policy is a resource-based policy attached directly to an S3 bucket to control who can access it. An IAM policy is an identity-based policy attached to a user, group, or role to control what they can access across all of AWS. For an action to be allowed, the permissions must be granted by the bucket policy, the IAM policy, or both, and not be explicitly denied by either.

Q: How do I grant access to an S3 bucket to another AWS account?

A: The most straightforward way is to use a bucket policy. You add a statement with "Effect": "Allow" and specify the ARN of the target AWS account in the Principal element (e.g., "Principal": {"AWS": "arn:aws:iam::123456789012:root"}). The IAM user or role in the other account must also have an IAM policy that allows it to perform the desired S3 actions.

Q: I created a bucket policy to make my bucket public, but I still get "Access Denied." Why?

A: The most likely reason is that the S3 Block Public Access settings are enabled for the bucket or your entire account. These settings are on by default for all new buckets and act as a safety guardrail by overriding bucket policies and ACLs that would otherwise grant public access. To host a public website, you must intentionally disable these settings for that specific bucket.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.