Skip to main content
In this guide, explore how to work with Amazon S3 access points by creating a demo bucket, uploading files, simulating multiple users, and configuring granular access controls. We’ll cover creating access points for different user groups such as developers and finance, and demonstrate how access point policies work alongside bucket policies.

​
Creating the Demo Bucket

Begin by creating a demo S3 bucket named KK-AccessPoint with default settings. Once the bucket is created, upload a demo file (for example, beach.jpg) to test file accessibility.
The image shows the Amazon S3 console interface for creating a new bucket, with fields for bucket name, AWS region, and object ownership settings.
The image shows an Amazon S3 console interface with a bucket named "kk-access-point" in the US East (N. Virginia) region. The bucket and its objects are not public, and the interface includes options to manage the bucket.
As the bucket owner, click the Open button after uploading to verify access to the file.

​
Simulating Multiple Users

To simulate different users accessing the S3 bucket, open separate browser tabs. For instance, use: • Blue tab – User One (bucket owner)
• Green tab – User Two
• Yellow tab – User Three
The image shows an Amazon S3 console interface displaying details of an object named "beach.jpg," including its size, type, and S3 URI.
Next, validate the user permissions in the IAM Management Console. In this demo, User Three has CloudShell access only and no permissions to interact with S3 buckets.
The image shows an AWS Identity and Access Management (IAM) console screen, displaying user details and permissions, including a policy named "AWSCloudShellFullAccess." The console access is enabled without MFA, and no permissions boundary is set.

​
Testing File Access Via CloudShell

AWS CloudShell, with the AWS CLI pre-installed, allows you to run commands without setting up a local CLI environment. While testing, you might observe that although the bucket owner can list bucket contents, Users Two and Three receive a “403 Forbidden” error when trying to copy the file. For example, in a CloudShell session as the bucket owner:
Attempting the same command under User Two or User Three’s session will produce a similar forbidden error, confirming that initially only the bucket owner has access. When re-testing as the main user, the same error persists:

​
Creating Access Points

Access points allow you to delegate access control to specific groups. In this demo, we’ll create two access points — one for developers and one for finance.

​
Step 1: Create the Developer Access Point

  1. In the S3 console, select your bucket and navigate to “Access Points.”
  2. Click Create Access Point.
  3. Enter a name (e.g., developers) and select the KK-AccessPoint bucket.
  4. For network origin, choose “open up to the Internet” (unless you require a specific VPC).
  5. Skip the initial access point policy configuration and click Create.
The image shows a web interface for creating an access point in Amazon S3, with fields for access point name, bucket selection, AWS region, and network origin settings.

​
Step 2: Create the Finance Access Point

Repeat the process to create another access point for the finance team (e.g., named finance):
  1. Follow the same steps as above.
  2. Name the access point (e.g., finance) and select KK-AccessPoint.
  3. Leave the policy default for now.
The image shows an Amazon S3 console interface displaying access points for a bucket named "kk-access-point," with two access points listed: "developers" and "finance."
Later, you will update the access point policies to define who can access the underlying bucket.

​
Understanding Access Point Policies

Access point policies are similar to bucket policies but reference the access point ARN rather than the bucket ARN. Below is a sample access point policy:
Note the following: • The policy specifies a principal and allowed actions.
• The resource section references the access point ARN, distinctly different from a typical bucket ARN.
Ensure that permissions granted in an access point policy are also allowed by the underlying bucket. You can either delegate control from the bucket or include the access point policy in the bucket policy.
To delegate control from the bucket, modify your bucket policy as shown below:
This delegation allows all access points attached to the bucket to manage their own policies independently.
The image shows an Amazon Web Services (AWS) interface for managing S3 access point policies, indicating that public access is blocked due to active Block Public Access settings. There are options to edit statements and choose services on the right side.

​
Configuring Access Point Policies

​
For the Developers Access Point

To allow User Two (a developer) to perform S3 operations using the developers access point, update the access point policy as follows:
If listing bucket contents is required, add the s3:ListBucket action. See the example below:

​
For the Finance Access Point

Similarly, set up a policy for the finance access point to allow a designated finance user (or group) to execute S3 operations:
(Be sure to update the ARNs and access point names to reflect your specific configuration.) After making these changes, save the policies and verify the updated configuration on the access point’s Permissions tab.
The image shows an Amazon S3 console screen with the "Permissions" tab open for a bucket named "kk-access-point." It displays settings related to blocking public access and bucket policies.
The image shows an Amazon S3 console screen focused on the "Permissions" tab for an access point named "developers." It displays settings for blocking public access and the access point policy details.

​
Testing Access Through the Access Points

With the proper policies in place, test the new access points using the AWS CLI. Instead of addressing the bucket directly, use the ARN of the access point. For example, to list objects through the developers access point:
Assuming the policy is configured correctly, you will see the objects (e.g., beach.jpg). To download the file using the access point:
Similarly, test the finance access point by executing:
  1. Listing objects:
  2. Copying the file:
You can also test uploads by copying a new file (e.g., test1) into the bucket via the designated access point. This customized approach provides greater control over how different user groups interact with your S3 bucket.

​
Conclusion

By leveraging S3 access points, you can delegate access control to distinct user groups—such as developers and finance—simplifying permissions management and enhancing security. Each access point features its own ARN and policy, enabling granular control over data access within a shared S3 bucket. For further details on S3 best practices and advanced configurations, refer to the AWS S3 Documentation. Happy cloud computing!

Watch Video