IAM Policies VS S3 Policies VS S3 Bucket ACLs – What should be used?

In the previous blog, we have learned about IAM policies in AWS. We can use IAM policies to manage access for different users for the S3 bucket. Obviously life is not that simple. With S3 we have Bucket policies and Bucket Access Control Lists ( hereafter referred to as ACLs) which also can be used to manage access to S3 buckets. Let us understand the difference between IAM policies VS S3 Policies and S3 ACLs and when should you use what.

IAM Policies

IAM polices are used to specify which actions are allowed or denied on AWS services/resources for particular user. for example, user Tom can read files from “Production” bucket but can write files in “Dev” bucket where as user Jerry can have admin access to S3.

We can attach IAM policies to users, groups or roles. These users or roles then can perform AWS operations depending on permission granted to them by AWS policy.

Below is sample policy that allows read access to s3 bucket “test-sample-bucket”. Any user or group or role which has below policy attached will be able to read data from this bucket.

S3 Bucket Policies

With S3 bucket policy, you can specify which actions are allowed or denied on that bucket for some user. The user in context of S3 bucket policies is called principal. Principle can be IAM user or AWS root account. That means you can grant access to another AWS account than in which your AWS S3 bucket is created.

S3 bucket policies can be attached to only S3 buckets. You can use them with any other AWS user or service. Below is a sample S3 bucket policy that grants root user of AWS account with ID 112233445566 and the user named Tom full access to S3 bucket.

Note “Principal” statement in S3 bucket policy. Principal has a list of users who have access to this bucket. In the case of IAM policies “Principal” is not necessary as this is derived from user or group or role to which IAM policy is assigned.

In the case of IAM policies, mentioning “Principal” is not necessary as this is derived from the user or group or role to which IAM policy is assigned.

AWS Facts

If you want to try and play around to create S3 bucket policies then AWS has provided policy generator. You can try out creating policies for different scenarios.

S3 Bucket ACL

S3 ACLs is the old way of managing access to buckets. AWS recommends the use of IAM or Bucket policies. But there are still use cases where ACLs give flexibility over policies. That is one of the reasons ACLs are still not deprecated or going to be deprecated any time soon.

The biggest advantage of using ACL is that you can control the access level of not only buckets but also of an object using it. Whereas IAM or Bucket Policies can only be attached to buckets but not to objects in the bucket, Bucket ACLs can be assigned to buckets as well as objects in it.

This means you have a lot of flexibility and control over your S3 resources. You can make some object public in a private bucket or vice versa without any issue.

ACLs can have one of following type of value.

  • “private”
  • “public-read”
  • “public-read-write”
  • “authenticated-read”

So what should I Use?

Now that we have understood the basics of IAM Policy, Bucket Policy, and Bucket ACLs, We can decide in which scenario we should use which type of access control. Below is a table that should help you decide what you should use in your case.

CriteriaIAM PoliciesBucket PoliciesBucket ACLs
AWS RecommendationAWS recommends using IAM policies where you can.You can use bucket policies as its simper way compared to IAM policies.Bucket ACLs is older way of managing access to S3 buckets and generally are not recommended
Environment IAM allows you to centrally manage all permissions to AWS which is easierS3 policies are limited to S3 environment only S3 ACLs are limited to S3 environment only
Use casesIAM Policies can specify permission rules to other AWS Services/resourcesCan only be used with S3Can only be used with S3
ease of use and maintenance IAM policies are easy to maintain when you have a large number of users and you frequently need to make changes to permission levels of users (i.e. user promoted or left organization)S3 policies are easy to create but become difficult to maintain when you lot of users or if you want to make a change to the access level of some user. You might need to update bucket policies for all buckets if some user need more access to S3 bucketsSame as S3 bucket Policies, ACLs are difficult to maintain
Object level controlIAM policies can only be attached to the root level of the bucket and cannot control object-level permissions. Using ACL is that you can control the access level of not only buckets but also of an object using it.If you need to manage object level permissions in S3, then you need to use Bukcet ACLs


I hope you have learned the difference between IAM policies, S3 policies, and S3 ACLs. It is your decision to use one of them depending on your use case. If you have any questions, let me know. See you in the next blog. Cheers.

iam policy vs s3 policy vs s3 acls

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *


  1. Hi,

    Your blog content was superb until the “So what should I Use?” section where in the last criteria “Object level control” you’ve mentioned that neither IAM nor S3 bucket policies can control object level permissions, which absolutely wrong and misleading.

    Reference URL: https://aws.amazon.com/blogs/security/iam-policies-and-bucket-policies-and-acls-oh-my-controlling-access-to-s3-resources/

    Quoting the exact paragraph from the reference URL:

    “You can attach S3 ACLs to individual objects within a bucket to manage permissions for those objects. S3 bucket policies and IAM policies define object-level permissions by providing those objects in the Resource element in your policy statements. The statement will apply to those objects in the bucket. Consolidating object-specific permissions into one policy (as opposed to multiple S3 ACLs) makes it simpler for you to determine effective permissions for your users and roles.”