S3 Storage

S3 Access: How to Store Objects With Different Permissions In the Same Amazon S3 Bucket

All Amazon S3 buckets and the objects in them are private by default, but there are various identity and S3 access control options available for users to adjust permissions for objects within each S3 bucket. It’s important for any enterprise organization planning on using Amazon S3 storage to have a good understanding of these options to effectively manage permission to their Amazon S3 resources.

This article takes a look at managing access to Amazon S3 objects and how to effectively store multiple objects with different permissions within the same S3 bucket.

Use the links below to jump down to the sections on:

Amazon S3 Access Management Overview

When it comes to maintaining access and security control to resources, most public cloud platforms operate on a shared responsibility model between the customers and the cloud provider. In the case of AWS cloud, AWS is responsible for maintaining the underlying cloud infrastructure security while the customers are responsible for managing and maintaining the access to the customer data stored on the cloud infrastructure.

With an abstracted service such as Amazon S3, customers are required to manage all aspects of the data they store there, including the access permissions to the objects stored within Amazon S3 buckets and their ongoing management and operational tasks. Amazon S3 provides various options to control the access to the customer data stored on S3. One way to do this is via permissions and various IAM roles.

Amazon S3 Access Configuration Options

There are a number of different S3 access configuration options available within Amazon S3 that are important to familiarize before we can look into the details.

  • Amazon S3 Access Policy: An Amazon S3 access policy describes who has access to what and at what level of permission in Amazon S3. An access policy is typically attached to S3 resources (such as buckets and objects, which are known as bucket policies) or to an AWS user (known as user policies). Both of these policies are expressed using a JSON file and can be used to permit all of the available actions in Amazon S3.

    • Bucket policy: A resource-based policy that can be used to grant permissions to S3 buckets and the objects inside them. The bucket owner can create and associate a bucket policy with an S3 bucket, and the permissions defined in the bucket policy are then applied to all the S3 objects owned by the bucket owner inside the bucket (objects not owned by the bucket owner do not inherit these permissions from a bucket policy).

    • User Policy: Similar to a bucket policy, user policies can be used to also grant permissions to S3 buckets and objects inside them. However, the user policies are associated with the AWS Identity and Access Management (IAM) users and user groups.

    An access policy typically contains the following elements:

    • Sid: Security identifier
    • Effect: Security permission (either “allow” or “deny”)
    • Principle: The user account associated with the policy (in a bucket policy, this principle can be: an account, a user, or a service)
    • Action: Specific Amazon S3 operation to which the permission will map
    • Resource: Buckets, objects, access points, and jobs to which the access permissions are applied
    • Conditions: Specific conditions such as object name prefixes applicable to the resources above
  • S3 Access Control List (ACL): This is a list of access permissions (grants) and the users to whom the permissions have been granted (grantees). Amazon S3 ACLs use a S3-specific XML-based schema and ACLs are used in general to grant basic read/write permissions to AWS accounts. ACLs exist at the object level as well as the S3 bucket level. It should be noted that ACLs only support a limited set of Amazon S3 permissions. To change any advanced permissions, such as those requiring permissions for bucket sub-resources, you will need to leverage access policies instead.

Amazon S3 Object Access Management

All Amazon S3 resources and their related sub-resources are private by default and only accessible by the AWS account that created them. Access to S3 objects must be explicitly granted to other users for wider access.

There are multiple ways to define access to the objects stored inside Amazon S3 buckets. These can be leveraged by customers to store multiple S3 objects with different permissions inside the same S3 bucket.

Using Bucket Policy

A bucket policy can be leveraged by the bucket owner to grant permissions to the bucket and the objects inside the bucket that are owned by the bucket owner. A bucket policy can be created using the AWS Policy Generator easily.

See the below example of an Amazon bucket policy that defines the access permission to the AWS bucket named “chan-s3-eu-west-2-bucket-01.” The bucket policy has been configured with multiple statements:

  • Statement1: Grants “allow” access (effect) to all S3 operations (actions) to all user principles. This is applicable to all S3 objects (resource) inside the bucket whose names end with “.jpg.”

  • Statement2: Grants “deny” access to all S3 operations to all user principles. This is applicable to all S3 objects inside the bucket whose names end with “.pdf.”


This bucket policy therefore enables different access permissions to different objects within the same S3 bucket, providing S3 users with a great deal of flexibility when storing various objects in the same bucket.

Bucket policies are used specifically to manage permissions between different AWS accounts and their users. Refer to the AWS documentation for additional bucket policy examples here.

Using User Policy

With AWS IAM, multiple users can be created within the same AWS account and user policies can be associated with these accounts to manage their S3 access permissions for objects.

Refer to the example below using the same S3 bucket where a specific user policy has been defined to achieve customized permissions to a specific development user account (development-user-chan-s3-eu-west-2-bucket-01).


  1. This section defines the allow permissions to execute the S3 action ListBucket (enables the user to list the contents of the bucket) which is applied to the S3 bucket “chan-s3-eu-west-2-bucket-01” where the S3 object name contains the “Development/” prefix.

    In other words, this section grants the user permission to list the contents of the “Development” folder inside the “chan-s3-eu-west-2-bucket-01” S3 bucket.
  2. This section defines the “allow” permission to execute Amazon S3 operations: GetObjects (get the list of objects) and PutObjects (upload / add objects) which is applied to the S3 bucket “chan-s3-eu-west-2-bucket-01/Development” location.

    In other words, this section grants permission for the user to read and write objects into the Development folder inside the same bucket.
  3. Finally, this section explicitly denies the user permission to any other folder within the “chan-s3-eu-west-2-bucket-01” S3 bucket, restricting the user’s access to only the “Development” folder and the objects inferred to be in it.

This user policy can be associated with a specific user as illustrated below. In this example, it has been associated with an AWS IAM user named “development-user-chan-s3-eu-west-2-bucket-01” which will grant the above customized permissions and restrictions to just this user.


ACL-Based Access

In addition to bucket and user policies, you can also leverage Access Control Lists (ACLs) in order to control access to objects in an S3 bucket. Both S3 buckets and objects have ACLs that can be leveraged to grant access to S3 objects.

It should be noted however that AWS recommends the use of access policies over ACLs where possible due to the scalability and manageability associated with the former. Unless there is an unusual requirement where customers need to control access to specific objects individually, it is recommended to disable the ACLs where possible.

Object ACLs

Access controls are defined explicitly in the object ACL. This method provides a specific and a granular way to maintain access permissions at the individual S3-object level inside a bucket. Object ACLs can be leveraged when different access permissions (other than what’s defined via bucket or user policies) need to be defined for each object within the same S3 bucket. In addition, object ACLs can also be leveraged for unique scenarios such as when managing access permissions to S3 objects that are not owned by the bucket owner (therefore not inherited via bucket policies).

See the below example where, using the same Amazon S3 bucket as above, a specific object (titled “vpn-05072cb0f5bd00442.txt”) has been explicitly given public read access using the object’s ACL.


Bucket ACLs

Access controls can also be defined explicitly at the Amazon S3 bucket level. See the below example of how the same S3 bucket has been given the “Read” access to everyone for public access to the bucket.

However, bucket ACL’s are only recommended to be used for granting permission to specific AWS services (such as CloudFront) rather than user permissions.



As illustrated above, Amazon S3 objects can be permissioned using a combination of S3 bucket policies, user policies and object ACLs to achieve a complex mix of different access permissions in the same bucket. Enterprise organizations with complex, advanced S3 storage use cases can leverage this flexibility offered by Amazon S3 in order to meet their complex object storage requirements.  

For even more security and other benefits and uses for AWS storage, consider the capabilities you can gain with NetApp Cloud Volumes ONTAP as a data management layer for your AWS account. Learn more about Enterprise Data Security for Cloud File Sharing with Cloud Volumes ONTAP, storage efficiencies to lower storage costs, automatic tiering of EBS block storage to S3, hybrid and multicloud data mobility.


  • What is S3 access?

    In the simplest terms, S3 access is the act of accessing the data stored within a bucket. This can be achieved through a number of different means and, by default, by the owner of the bucket. The permissions for each S3 bucket can be adjusted to allow other users to access the data in that bucket.

  • How do I access my S3 bucket?

    A bucket owner (or anyone else with the proper permissions) can access an Amazon S3 bucket by using the console, or programmatically using RESTful commands. Users can also access their buckets using either path-style or virtual-hosted–style URLs.

  • Who can access an S3 bucket?

    An S3 bucket can be accessed by the bucket owner by default. That permission can be changed to include other AWS users within the same AWS account as the owner’s and also users from other AWS accounts.
Yifat Perry, Product Marketing Lead

Product Marketing Lead