Overview of Managing Access

lifecycle – Stores lifecycle configuration information (see Object Lifecycle Management).

website – Stores website configuration information if you configure your bucket for website hosting (see Hosting a Static Website on Amazon S3.

versioning – Stores versioning configuration (see PUT Bucket versioning).

policy and acl (access control list) – Store access permission information for the bucket.

cors (cross-origin resource sharing) – Supports configuring your bucket to allow cross-origin requests (see Cross-Origin Resource Sharing (CORS)).

logging – Enables you to request Amazon S3 to save bucket access logs.

acl – Stores a list of access permissions on the object. This topic discusses how to use this subresource to manage object permissions (see Managing Access with ACLs).

restore – Supports temporarily restoring an archived object (see POST Object restore). An object in the Glacier storage class is an archived object. To access the object, you must first initiate a restore request, which restores a copy of the archived object. In the request, you specify the number of days that you want the restored copy to exist. For more information about archiving objects, see Object Lifecycle Management.

The AWS account that you use to create buckets and objects owns those resources.

If you create an AWS Identity and Access Management (IAM) user in your AWS account, your AWS account is the parent owner. If the IAM user uploads an object, the parent account, to which the user belongs, owns the object.

A bucket owner can grant cross-account permissions to another AWS account (or users in another account) to upload objects. In this case, the AWS account that uploads objects owns those objects. The bucket owner does not have permissions on the objects that other accounts own, with the following exceptions:

Resource-based policies – Bucket policies and access control lists (ACLs) are resource-based because you attach them to your Amazon S3 resources.

User policies – You can use IAM to manage access to your Amazon S3 resources. You can create IAM users, groups, and roles in your account and attach access policies to them granting them access to AWS resources, including Amazon S3.

For more information about IAM, see the AWS Identity and Access Management (IAM) product detail page.

The following is an example of a user policy. You cannot grant anonymous permissions in an IAM user policy, because the policy is attached to a user. The example policy allows the associated user that it's attached to perform six different Amazon S3 actions on a bucket and the objects in it. You can attach this policy to a specific IAM user, group, or role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ExampleStatement1",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                 "arn:aws:s3:::examplebucket/*",
                 "arn:aws:s3:::examplebucket"
            ]
        },
        {
            "Sid": "ExampleStatement2",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        }
    ]
}

When should I use which access control method? For example, to grant bucket permissions, should I use a bucket policy or bucket ACL? I own a bucket and the objects in the bucket. Should I use a resource-based access policy or an IAM user policy? If I use a resource-based access policy, should I use a bucket policy or an object ACL to manage object permissions?

I own a bucket, but I don't own all of the objects in it. How are access permissions managed for the objects that somebody else owns?

If I grant access by using a combination of these access policy options, how does Amazon S3 determine if a user has permission to perform a requested operation?

Using Bucket Policies and User Policies

Managing Access with ACLs