Skip to main content
In this guide, you’ll learn how to use AWS S3 bucket policies (resource policies) to grant or restrict access for:
  1. Users in the same AWS account
  2. Anonymous (public) users
  3. Users in a different AWS account
You’ll simulate three users using browser tabs with colored labels:
  • Blue: Account 1, User 1 (Bucket Owner)
  • Green: Account 1, User 2
  • Yellow: Account 2, User Admin
Switch among these tabs to verify permissions.

​
Test Environment

​
1. Create the S3 Bucket (User 1)

  1. In the Blue tab, open the AWS S3 Console.
  2. Click Create bucket and configure:
    • Bucket name: kk-resource-policies
    • Region: your choice
    • Object Ownership: Bucket owner preferred
    • Block all public access: Enabled
    • Versioning: Disabled
The image shows an AWS S3 bucket creation page, where settings like bucket name, region, object ownership, and public access are configured.
  1. Confirm creation.
The image shows an AWS S3 Management Console with a notification indicating a bucket named "kk-resource-policies" has been successfully created. The console displays details about the bucket, including its region and access status.
  1. Upload a set of files (e.g., text & log files).
The image shows an AWS S3 Management Console with a successful upload status for 13 files, totaling 7.0 B, all marked as succeeded.
  1. Verify all objects are listed:
The image shows an Amazon S3 bucket interface with a list of files and folders, including text files and directories, along with their details like type, last modified date, and size.
By default, as the bucket owner:
  • Listing and “Open” via console (authenticated) works.
  • Public URL returns AccessDenied:

​
2. Baseline IAM Permissions for User 2

Switch to the Green tab. User 2 currently has only list permissions:
User 2 can list buckets and objects but cannot read or delete data. Opening file1.txt returns AccessDenied.

​
3. Grant User 2 Read Access to logs/

Return to Blue (User 1) and edit the bucket policy under Permissions → Bucket Policy. Add:
Save the policy.

​
Test Read Access

In Green, open logs/log1 → download succeeds.
The image shows an Amazon S3 management console displaying details of an object named "log1" within a bucket. It includes information such as the owner, region, last modified date, and object URL, along with a notification about bucket versioning permissions.
Attempting to open file1.txt (outside logs/) still yields AccessDenied:

​
4. Grant User 2 Delete Access in traces/

Back in Blue, append another statement:
Save and switch to Green:
  • Deleting traces/trace1 → Success
  • Deleting file1.txt → AccessDenied
The image shows an AWS S3 console screen with a "Failed to delete objects" error message, indicating a permission issue with deleting a file named "file1.txt".

​
5. Combining Multiple Actions

You can merge permissions when they apply to the same resource path:
Ensure that all listed actions in one statement target the same ARN pattern.

​
6. Allow Public Read Access to media/

To expose only the media/ prefix publicly:
  1. In Permissions, disable “Block public access” (if enforced).
  2. Add:
After saving, any object under media/ is publicly readable.
The image shows an Amazon S3 console displaying details of a file named "file1.txt," including its properties, size, and object URL. It also highlights that bucket versioning is disabled.

​
7. Grant Cross-Account Access (Account 2)

In Yellow (Account 2, User Admin), test listing:
Back in Blue, append:
Save and retry in Yellow:

​
Summary

You’ve now configured a private S3 bucket and applied these resource policy patterns: With these techniques—granular read, delete, public, and cross-account—you can enforce precise access control over your S3 data.

Watch Video