What is the difference between Bucket ACLs and Bucket Policies?

Amazon S3 provides two primary mechanisms for controlling access to buckets and objects: Access Control Lists (ACLs) and Bucket Policies. Both serve the purpose of defining permissions, but they differ significantly in functionality, granularity, and use cases.

Bucket ACLs (Access Control Lists) :

Definition:
Bucket ACLs are a legacy method to control access at the bucket or object level. They allow you to grant basic permissions to specific AWS accounts or predefined groups.

Key Features:

  • Granularity: Apply permissions at both the bucket and object level.
  • Scope: Permissions are limited to simple read and write operations.
  • Supported Actions: Supports basic permissions such as READ, WRITE, and FULL_CONTROL.
  • Predefined Groups: ACLs allow granting access to groups such as Authenticated Users and Everyone.

Use Cases:

  • Sharing objects publicly (e.g., for websites or downloads).
  • Granting access to a specific AWS account for a particular object.

Example:
Granting the "Read" permission to the public :

json
{
  "Grantee": {
    "Type": "Group",
    "URI": "http://acs.amazonaws.com/groups/global/AllUsers"
  },
  "Permission": "READ"
}


Bucket Policies :

Definition:
Bucket policies are JSON-based documents that provide a more comprehensive and flexible way to define permissions for buckets and objects.

Key Features:

  • Granularity: Apply permissions at the bucket level but can include conditions to target specific objects.
  • Scope: Supports complex permissions using conditions, such as IP restrictions, specific AWS services, or time-based access.
  • Supported Actions: Supports a wide range of S3 operations beyond just READ and WRITE.
  • Condition Support: Enables the use of conditions to control access based on factors like IP addresses, VPC, user agents, or request time.

Use Cases:

  • Enforcing security policies, such as restricting access to specific IP addresses.
  • Granting cross-account access with conditions.
  • Allowing temporary access through pre-signed URLs or time-based restrictions.

Example:
Restricting access to a specific IP address range:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.168.1.0/24"
        }
      }
    }
  ]
}