Access control best practices - Amazon Simple Storage Service

Access control best practices

Amazon S3 provides a variety of security features and tools. The following scenarios should serve as a guide to what tools and settings you might want to use when performing certain tasks or operating in specific environments. Proper application of these tools can help maintain the integrity of your data and help ensure that your resources are accessible to the intended users.

Creating a new bucket

When creating a new bucket, you should apply the following tools and settings to help ensure that your Amazon S3 resources are protected. 

S3 Object Ownership for simplifying access control

S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to disable access control lists (ACLs) and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3. By default, when another AWS account uploads an object to your S3 bucket, that account (the object writer) owns the object, has access to it, and can grant other users access to it through ACLs. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket. As a result, access control for your data is based on policies, such as IAM policies, S3 bucket policies, virtual private cloud (VPC) endpoint policies, and AWS Organizations service control policies (SCPs).

Object Ownership has three settings that you can use to control ownership of objects uploaded in your bucket and disable or enable ACLs:

ACLs disabled
  • Bucket owner enforced (recommended) – ACLs are disabled, and the bucket owner automatically owns and has full control over every object in the bucket. ACLs no longer affect permissions to data in the S3 bucket. The bucket uses policies exclusively to define access control.

ACLs enabled
  • Bucket owner preferred – The bucket owner owns and has full control over new objects that other accounts write to the bucket with the bucket-owner-full-control canned ACL.

  • Object writer (default) – The AWS account that uploads an object owns the object, has full control over it, and can grant other users access to it through ACLs.

For more information, see Controlling ownership of objects and disabling ACLs for your bucket.

Block Public Access

S3 Block Public Access provides four settings to help you avoid inadvertently exposing your S3 resources. You can apply these settings in any combination to individual access points, buckets, or entire AWS accounts. If you apply a setting to an account, it applies to all buckets and access points that are owned by that account. By default, the Block all public access setting is applied to new buckets created in the Amazon S3 console. 

For more information, see The meaning of "public".

If the S3 Block Public Access settings are too restrictive, you can use AWS Identity and Access Management (IAM) identities to grant access to specific users rather than disabling all Block Public Access settings. Using Block Public Access with IAM identities helps ensure that any operation that is blocked by a Block Public Access setting is rejected unless the requesting user has been given specific permission.

For more information, see Block public access settings.

Grant access with IAM identities

When setting up accounts for new team members who require S3 access, use IAM users and roles to ensure least privileges. You can also implement a form of IAM multi-factor authentication (MFA) to support a strong identity foundation. Using IAM identities, you can grant unique permissions to users and specify what resources they can access and what actions they can take. IAM identities provide increased capabilities, including the ability to require users to enter login credentials before accessing shared resources and apply permission hierarchies to different objects within a single bucket.

For more information, see Example 1: Bucket owner granting its users bucket permissions .

Bucket policies

With bucket policies, you can personalize bucket access to help ensure that only those users you have approved can access resources and perform actions within them. In addition to bucket policies, you should use bucket-level Block Public Access settings to further limit public access to your data.

For more information, see Using bucket policies.

When creating policies, avoid the use of wildcard characters in the Principal element because it effectively allows anyone to access your Amazon S3 resources. It's better to explicitly list users or groups that are allowed to access the bucket. Rather than including a wildcard for their actions, grant them specific permissions when applicable.

To further maintain the practice of least privileges, Deny statements in the Effect element should be as broad as possible and Allow statements should be as narrow as possible. Deny effects paired with the "s3:*" action are another good way to implement opt-in best practices for the users included in policy condition statements.

For more information about specifying conditions for when a policy is in effect, see Amazon S3 condition key examples.

Buckets in a VPC setting

When adding users in a corporate setting, you can use a virtual private cloud (VPC) endpoint to allow any users in your virtual network to access your Amazon S3 resources. VPC endpoints enable developers to provide specific access and permissions to groups of users based on the network the user is connected to. Rather than adding each user to an IAM role or group, you can use VPC endpoints to deny bucket access if the request doesn’t originate from the specified endpoint.

For more information, see Controlling access from VPC endpoints with bucket policies.

Storing and sharing data

Use the following tools and best practices to store and share your Amazon S3 data.

Versioning and Object Lock for data integrity

If you use the Amazon S3 console to manage buckets and objects, you should implement S3 Versioning and S3 Object Lock. These features help prevent accidental changes to critical data and enable you to roll back unintended actions. This capability is particularly useful when there are multiple users with full write and execute permissions accessing the Amazon S3 console.

For information about S3 Versioning, see Using versioning in S3 buckets. For information about Object Lock, see Using S3 Object Lock.

Object lifecycle management for cost efficiency

To manage your objects so that they are stored cost effectively throughout their lifecycle, you can pair lifecycle policies with object versioning. Lifecycle policies define actions that you want S3 to take during an object's lifetime. For example, you can create a lifecycle policy that will transition objects to another storage class, archive them, or delete them after a specified period of time. You can define a lifecycle policy for all objects or a subset of objects in the bucket by using a shared prefix or tag.

For more information, see Managing your storage lifecycle.

Cross-Region Replication for multiple office locations

When creating buckets that are accessed by different office locations, you should consider implementing S3 Cross-Region Replication. Cross-Region Replication helps ensure that all users have access to the resources they need and increases operational efficiency. Cross-Region Replication offers increased availability by copying objects across S3 buckets in different AWS Regions. However, the use of this tool increases storage costs.

For more information, see Replicating objects.

Permissions for secure static website hosting

When configuring a bucket to be used as a publicly accessed static website, you must disable all Block Public Access settings. It is important to only provide s3:GetObject actions and not ListObject or PutObject permissions when writing the bucket policy for your static website. This helps ensure that users cannot view all the objects in your bucket or add their own content.

For more information, see Setting permissions for website access.

Amazon CloudFront provides the capabilities required to set up a secure static website. Amazon S3 static websites only support HTTP endpoints. CloudFront uses the durable storage of Amazon S3 while providing additional security headers like HTTPS. HTTPS adds security by encrypting a normal HTTP request and protecting against common cyberattacks.

For more information, see Getting started with a secure static website in the Amazon CloudFront Developer Guide.

Sharing resources

There are several different ways that you can share resources with a specific group of users. You can use the following tools to share a set of documents or other resources to a single group of users, department, or an office. Although they can all be used to accomplish the same goal, some tools might pair better than others with your existing settings.

S3 Object Ownership

S3 Object Ownership is an Amazon S3 bucket-level setting that you can use to disable ACLs and take ownership of every object in your bucket, simplifying access management for data stored in Amazon S3. By default, when another AWS account uploads an object to your S3 bucket, that account (the object writer) owns the object, has access to it, and can grant other users access to it through ACLs. You can use Object Ownership to change this default behavior so that ACLs are disabled and you, as the bucket owner, automatically own every object in your bucket. As a result, access control for your data is based on policies. For more information, see Controlling ownership of objects and disabling ACLs for your bucket.

User policies

You can share resources with a limited group of people using IAM groups and user policies. When creating a new IAM user, you are prompted to create and add them to a group. However, you can create and add users to groups at any point. If the individuals you intend to share these resources with are already set up within IAM, you can add them to a common group and share the bucket with their group within the user policy. You can also use IAM user policies to share individual objects within a bucket.

For more information, see Allowing an IAM user access to one of your buckets.

Access control lists

As a general rule, we recommend that you use S3 bucket policies or IAM policies for access control. Amazon S3 ACLs are the original access control mechanism in Amazon S3 that predates IAM. If you already use S3 ACLs and you find them sufficient, there is no need to change. However, certain access control scenarios require the use of ACLs. For example, when a bucket owner wants to grant permission to objects, but not all objects are owned by the bucket owner, the object owner must first grant permission to the bucket owner. This is done using an object ACL.

A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you must control access for each object individually. With Object Ownership, you can disable ACLs and rely on policies for access control. When you disable ACLs, you can easily maintain a bucket with objects uploaded by different AWS accounts. You, as the bucket owner, own all the objects in the bucket and can manage access to them using policies.


If your bucket uses the bucket owner enforced setting for S3 Object Ownership, you must use policies to grant access to your bucket and the objects in it. Requests to set ACLs or update ACLs fail and return the AccessControlListNotSupported error code. Requests to read ACLs are still supported.

For more information about using ACLs, see Example 3: Bucket owner granting permissions to objects it does not own.


When trying to share specific resources from a bucket, you can replicate folder-level permissions using prefixes. The Amazon S3 console supports the folder concept as a means of grouping objects by using a shared name prefix for objects. You can then specify a prefix within the conditions of an IAM user's policy to grant them explicit permission to access the resources associated with that prefix. 

For more information, see Organizing objects in the Amazon S3 console using folders.


If you use object tagging to categorize storage, you can share objects that have been tagged with a specific value with specified users. Resource tagging allows you to control access to objects based on the tags associated with the resource that a user is trying to access. To do this, use the ResourceTag/key-name condition within an IAM user policy to allow access to the tagged resources.

For more information, see Controlling access to AWS resources using resource tags in the IAM User Guide.

Protecting data

Use the following tools to help protect data in transit and at rest, both of which are crucial in maintaining the integrity and accessibility of your data.

Object encryption

Amazon S3 offers several object encryption options that protect data in transit and at rest. Server-side encryption encrypts your object before saving it on disks in its data centers and then decrypts it when you download the objects. As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects. When setting up server-side encryption, you have three mutually exclusive options:

  • Server-side encryption with Amazon S3 managed keys (SSE-S3)

  • Server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS)

  • Server-side encryption with customer-provided keys (SSE-C)

For more information, see Protecting data using server-side encryption.

Client-side encryption is the act of encrypting data before sending it to Amazon S3. For more information, see Protecting data using client-side encryption.

Signing methods

Signature Version 4 is the process of adding authentication information to AWS requests sent by HTTP. For security, most requests to AWS must be signed with an access key, which consists of an access key ID and secret access key. These two keys are commonly referred to as your security credentials.

For more information, see Authenticating Requests (AWS Signature Version 4) and Signature Version 4 signing process.

Logging and monitoring

Monitoring is an important part of maintaining the reliability, availability, and performance of your Amazon S3 solutions so that you can more easily debug a multi-point failure if one occurs. Logging can provide insight into any errors users are receiving, and when and what requests are made. AWS provides several tools for monitoring your Amazon S3 resources:

  • Amazon CloudWatch

  • AWS CloudTrail

  • Amazon S3 Access Logs

  • AWS Trusted Advisor

For more information, see Logging and monitoring in Amazon S3.

Amazon S3 is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, a role, or an AWS service in Amazon S3. This feature can be paired with Amazon GuardDuty, which monitors threats against your Amazon S3 resources by analyzing CloudTrail management events and CloudTrail S3 data events. These data sources monitor different kinds of activity. For example, S3 related CloudTrail management events include operations that list or configure S3 projects. GuardDuty analyzes S3 data events from all of your S3 buckets and monitors them for malicious and suspicious activity.

For more information, see Amazon S3 protection in Amazon GuardDuty in the Amazon GuardDuty User Guide.