S3 Bucket Policies vs. ACLs vs. IAM Policies (Cheat Sheet)

Understanding when to use S3 Bucket Policies versus S3 ACLs versus AWS IAM Policies can easily make your head spin. To make sense of it, we’ve created text-based and image-based cheat sheets (available at the end of this article). These cheat sheets are straight from our Introduction to AWS Security course.

First, let’s go through a quick explanation and summary of each.

S3 Bucket Policies

As the name implies, S3 Bucket Policies are applied directly to an S3 bucket to not only control bucket access but also to control specific object permissions for objects that reside within that bucket.

If you create a new S3 bucket and start uploading objects to that bucket, you’ll want to make sure they’re properly protected…but you’re uploading those objects for a specific purpose and that purpose may involve granting access to the objects to applications, services, or people.

In order to grant that access without making those objects or buckets public, you can create bucket policies.

S3 ACLs

S3 ACLs were one of the original security controls for S3 a few years back, but they are no longer recommended for most use cases since S3 Bucket Policies have replaced them as the best option for securing buckets and objects.

Only if you cannot solve your use case with bucket policies should you entertain using S3 ACLs.

AWS IAM Policies

IAM policies are applied to IAM users, groups, and roles, which helps provide centralized access management for AWS resources. They are not specific to S3, they are used to control access permissions across all of AWS.

While you can protect buckets and objects with bucket policies, those are applied to S3 buckets. What about when you create IAM users, groups, or roles, and you want to give those resources access to S3 resources? Not only could you do that with bucket policies, but you can also apply those permissions with IAM policies.

That means you can use S3 Bucket Policies in conjunction with IAM Policies for multiple layers of security.

For example, you may have granted permissions via S3 Bucket Policies, but as you create a new IAM role, you would want to attach an IAM policy to that role that grants access as well. Or vice versa — you might grant access to an object via an IAM policy attached to the role, but the Bucket Policy explicitly denies that access which means the role will not have access.

Summary

In general, avoid using S3 ACLs unless they are necessary. They’ve been mostly replaced by S3 Bucket Policies.

Use S3 Bucket Policies to set baseline security for specific buckets and their objects.

Use IAM Policies to grant users, groups, or roles access to AWS resources and services, including S3 buckets or objects.

Text-based Cheat Sheet

	S3 Bucket Policies	S3 ACLs	IAM Policies
Scope	Applied to an S3 bucket to control bucket access, but can also control specific object permissions	Applied to buckets or to an individual object. Older access control method that’s no longer recommended to use if it can be avoided	Applied to IAM users, groups, and roles across the AWS account
Syntax	JSON-based policies	XML-based policies written in a specific format	JSON-based policies
Flexibility	Provide granular control with powerful conditions and fine-grained permissions	Provide basic access control but have fewer options for advanced permissions	Provide centralized access management for various AWS services, not just S3
Permissions	Can define access controls for both bucket-level and object-level operations	Can define access controls for individual objects and bucket-level operations, such as `READ`, `WRITE`, `READ_ACP`, `WRITE_ACP`, and `FULL_CONTROL`	Can define access controls for various AWS services, including S3, at a fine-grained level
Principal-Based	Identify the principal (role, user, group, or AWS account) and define their access permissions	Identify the user or group and define their access permissions	Define permissions for IAM users, groups, and roles by attaching policies to them
IAM Integration	Can reference IAM users, groups, and roles in policies to grant additional permissions or restrict access	Can use canonical user IDs to grant permissions to an AWS account (or even email addresses but they get converted to canonical user IDs), or can use a URI to grant permissions to a predefined group	Create and manage IAM policies separately from S3 bucket policies. IAM policies can be attached to IAM entities for S3 access control
Examples	Grant read access to all objects in a bucket to a specific IAM role	Grant write access to a specific object to an external AWS account user	Grant full access to an S3 bucket to an IAM group, while restricting delete permissions for specific IAM users