Troubleshoot access denied (403 Forbidden) errors in Amazon S3
Access denied (HTTP 403 Forbidden
) errors appear when AWS explicitly or
implicitly denies an authorization request.
-
An explicit denial occurs when a policy contains a
Deny
statement for the specific AWS action. -
An implicit denial occurs when there is no applicable
Deny
statement and also no applicableAllow
statement.
Because an AWS Identity and Access Management (IAM) policy implicitly denies an IAM principal by default, the policy must explicitly allow the principal to perform an action. Otherwise, the policy implicitly denies access. For more information, see The difference between explicit and implicit denies in the IAM User Guide. For information about the policy evaluation logic that determines whether an access request is allowed or denied, see Policy evaluation logic in the IAM User Guide.
The following topics cover the most common causes of access denied errors in Amazon S3.
Note
For access denied (HTTP 403 Forbidden
) errors, Amazon S3 doesn't charge the
bucket owner when the request is initiated outside of the bucket owner's individual
AWS account or the bucket owner's AWS organization.
Topics
Note
If you're trying to troubleshoot a permissions issue, start with the Access denied message examples and how to troubleshoot them section, then go to the Bucket policies and IAM policies section. Also be sure to follow the guidance in Tips for checking permissions.
Access denied message examples and how to troubleshoot them
Important
Starting on August 21, 2024, enhanced access denied error messages for same-account requests will become available in the coming weeks. These messages will be available in all AWS Regions, including the AWS GovCloud (US) Regions and the China Regions.
Most access denied error messages appear in the format User
. In this example,
user-arn
is not authorized to perform
action
on "resource-arn
"
because context
is the Amazon Resource Name
(ARN) of the user that doesn't receive access,
user-arn
is the service action that the
policy denies, and action
is the ARN of
the resource on which the policy acts. The
resource-arn
field represents additional context
about the policy type that explains why the policy denied access.context
When a policy explicitly denies access because the policy contains a Deny
statement, then the access denied error message includes the phrase with an
explicit deny in a
. When the policy
implicitly denies access, then the access denied error message includes the phrase
type
policybecause no
.type
policy allows the
action
action
Important
-
Enhanced access denied messages are returned only for same-account requests. Cross-account requests return a generic
Access Denied
message.For information about the policy evaluation logic that determines whether a cross-account access request is allowed or denied, see Cross-account policy evaluation logic in the IAM User Guide. For a walkthrough that shows how to grant cross-account access, see Example 2: Bucket owner granting cross-account bucket permissions.
-
Enhanced access denied error messages aren't returned for requests made to directory buckets. Directory bucket requests return a generic
Access Denied
message. -
If multiple policies of the same policy type deny an authorization request, the access denied error message doesn't specify the number of policies.
-
If multiple policy types deny an authorization request, the error message includes only one of those policy types.
-
If an access request is denied due to multiple reasons, the error message includes only one of the reasons for denial.
The following examples show the format for different types of access denied error messages and how to troubleshoot each type of message.
Access denied due to a Service Control Policy – implicit denial
-
Check for a missing
Allow
statement for the action in your Service Control Policies (SCPs). For the following example, the action iss3:GetObject
. -
Update your SCP by adding the
Allow
statement. For more information, see Updating an SCP in the AWS Organizations User Guide.
User: arn:aws:iam::
777788889999
:user/MaryMajor
is not authorized to perform: s3:GetObject because no service control policy allows the s3:GetObject action
Access denied due to a Service Control Policy – explicit denial
-
Check for a
Deny
statement for the action in your Service Control Policies (SCPs). For the following example, the action iss3:GetObject
. -
Update your SCP by removing the
Deny
statement. For more information, see Updating an SCP in the AWS Organizations User Guide.
User: arn:aws:iam::
777788889999
:user/MaryMajor
is not authorized to perform: s3:GetObject with an explicit deny in a service control policy
Access denied due to a VPC endpoint policy – implicit denial
-
Check for a missing
Allow
statement for the action in your virtual private cloud (VPC) endpoint policies. For the following example, the action iss3:GetObject
. -
Update your VPC endpoint policy by adding the
Allow
statement. For more information, see Update a VPC endpoint policy in the AWS PrivateLink Guide.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject because no VPC endpoint policy allows the s3:GetObject action
Access denied due to a VPC endpoint policy – explicit denial
-
Check for an explicit
Deny
statement for the action in your virtual private cloud (VPC) endpoint policies. For the following example, the action iss3:GetObject
. -
Update your VPC endpoint policy by removing the
Deny
statement. For more information, see Update a VPC endpoint policy in the AWS PrivateLink Guide.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" with an explicit deny in a VPC endpoint policy
Access denied due to a permissions boundary – implicit denial
-
Check for a missing
Allow
statement for the action in your permissions boundary. For the following example, the action iss3:GetObject
. -
Update your permissions boundary by adding the
Allow
statement to your IAM policy. For more information, see Permissions boundaries for IAM entities and Editing IAM policies in the IAM User Guide.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" because no permissions boundary allows the s3:GetObject action
Access denied due to a permissions boundary – explicit denial
-
Check for an explicit
Deny
statement for the action in your permissions boundary. For the following example, the action iss3:GetObject
. -
Update your permissions boundary by removing the
Deny
statement from your IAM policy. For more information, see Permissions boundaries for IAM entities and Editing IAM policies in the IAM User Guide.
User: arn:aws:iam::
777788889999
:user/MaryMajor
is not authorized to perform: s3:GetObject with an explicit deny in a permissions boundary
Access denied due to session policies – implicit denial
-
Check for a missing
Allow
statement for the action in your session policies. For the following example, the action iss3:GetObject
. -
Update your session policy by adding the
Allow
statement. For more information, see Session policies and Editing IAM policies in the IAM User Guide.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject because no session policy allows the s3:GetObject action
Access denied due to session policies – explicit denial
-
Check for an explicit
Deny
statement for the action in your session policies. For the following example, the action iss3:GetObject
. -
Update your session policy by removing the
Deny
statement. For more information, see Session policies and Editing IAM policies in the IAM User Guide.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" with an explicit deny in a session policy
Access denied due to resource-based policies – implicit denial
Note
Resource-based policies means policies such as bucket policies and access point policies.
-
Check for a missing
Allow
statement for the action in your resource-based policy. Also check whether theIgnorePublicAcls
S3 Block Public Access setting is applied on the bucket, access point, or account level. For the following example, the action iss3:GetObject
. -
Update your policy by adding the
Allow
statement. For more information, see Resource-based policies and Editing IAM policies in the IAM User Guide.You might also need to adjust your
IgnorePublicAcls
block public access setting for the bucket, access point, or account. For more information, see Access denied due to Block Public Access settings and Configuring block public access settings for your S3 buckets.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject because no resource-based policy allows the s3:GetObject action
Access denied due to resource-based policies – explicit denial
Note
Resource-based policies means policies such as bucket policies and access point policies.
-
Check for an explicit
Deny
statement for the action in your resource-based policy. Also check whether theRestrictPublicBuckets
S3 Block Public Access setting is applied on the bucket, access point, or account level. For the following example, the action iss3:GetObject
. -
Update your policy by removing the
Deny
statement. For more information, see Resource-based policies and Editing IAM policies in the IAM User Guide.You might also need to adjust your
RestrictPublicBuckets
block public access setting for the bucket, access point, or account. For more information, see Access denied due to Block Public Access settings and Configuring block public access settings for your S3 buckets.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" with an explicit deny in a resource-based policy
Access denied due to identity-based policies – implicit denial
-
Check for a missing
Allow
statement for the action in identity-based policies attached to the identity. For the following example, the action iss3:GetObject
attached to the userMaryMajor
. -
Update your policy by adding the
Allow
statement. For more information, see Identity-based policies and Editing IAM policies in the IAM User Guide.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject because no identity-based policy allows the s3:GetObject action
Access denied due to identity-based policies – explicit denial
-
Check for an explicit
Deny
statement for the action in identity-based policies attached to the identity. For the following example, the action iss3:GetObject
attached to the userMaryMajor
. -
Update your policy by removing the
Deny
statement. For more information, see Identity-based policies and Editing IAM policies in the IAM User Guide.
User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" with an explicit deny in an identity-based policy
Access denied due to Block Public Access settings
The Amazon S3 Block Public Access feature provides settings for access points, buckets, and accounts to help you manage public access to Amazon S3 resources. For more information about how Amazon S3 defines "public," see The meaning of "public".
By default, new buckets, access points, and objects don't allow public access. However, users can modify bucket policies, access point policies, IAM user policies, object permissions, or access control lists (ACLs) to allow public access. S3 Block Public Access settings override these policies, permissions, and ACLs. Since April 2023, all Block Public Access settings are enabled by default for new buckets.
When Amazon S3 receives a request to access a bucket or an object, it determines whether the bucket or the bucket owner's account has a block public access setting applied. If the request was made through an access point, Amazon S3 also checks for block public access settings for the access point. If there is an existing block public access setting that prohibits the requested access, Amazon S3 rejects the request.
Amazon S3 Block Public Access provides four settings. These settings are independent and can be used in any combination. Each setting can be applied to an access point, a bucket, or an entire AWS account. If the block public access settings for the access point, bucket, or account differ, then Amazon S3 applies the most restrictive combination of the access point, bucket, and account settings.
When Amazon S3 evaluates whether an operation is prohibited by a block public access setting, it rejects any request that violates an access point, bucket, or account setting.
The four settings provided by Amazon S3 Block Public Access are as follows:
-
BlockPublicAcls
– This setting applies toPutBucketAcl
,PutObjectAcl
,PutObject
,CreateBucket
,CopyObject
, andPOST Object
requests. TheBlockPublicAcls
setting causes the following behavior:-
PutBucketAcl
andPutObjectAcl
calls fail if the specified access control list (ACL) is public. -
PutObject
calls fail if the request includes a public ACL. -
If this setting is applied to an account, then
CreateBucket
calls fail with an HTTP400
(Bad Request
) response if the request includes a public ACL.
For example, when access is denied for a
CopyObject
request because of theBlockPublicAcls
setting, you receive the following message:An error occurred (AccessDenied) when calling the CopyObject operation: User: arn:aws:sts::
123456789012
:user/MaryMajor
is not authorized to perform: s3:CopyObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" because public access control lists (ACLs) are blocked by the BlockPublicAcls block public access setting. -
-
IgnorePublicAcls
– TheIgnorePublicAcls
setting causes Amazon S3 to ignore all public ACLs on a bucket and any objects that it contains. If your request's permission is granted only by a public ACL, then theIgnorePublicAcls
setting rejects the request.Any denial resulting from the
IgnorePublicAcls
setting is implicit. For example, ifIgnorePublicAcls
denies aGetObject
request because of a public ACL, you receive the following message:User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject because no resource-based policy allows the s3:GetObject action -
BlockPublicPolicy
– This setting applies toPutBucketPolicy
andPutAccessPointPolicy
requests.Setting
BlockPublicPolicy
for a bucket causes Amazon S3 to reject calls toPutBucketPolicy
if the specified bucket policy allows public access. This setting also causes Amazon S3 to reject calls toPutAccessPointPolicy
for all of the bucket's same-account access points if the specified policy allows public access.Setting
BlockPublicPolicy
for an access point causes Amazon S3 to reject calls toPutAccessPointPolicy
andPutBucketPolicy
that are made through the access point if the specified policy (for either the access point or the underlying bucket) allows public access.For example, when access is denied on a
PutBucketPolicy
request because of theBlockPublicPolicy
setting, you receive the following message:An error occurred (AccessDenied) when calling the PutBucketPolicy operation: User: arn:aws:sts::
123456789012
:user/MaryMajor
is not authorized to perform: s3:PutBucketPolicy on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" because public policies are blocked by the BlockPublicPolicy block public access setting. -
RestrictPublicBuckets
– TheRestrictPublicBuckets
setting restricts access to an access point or bucket with a public policy to only AWS service principals and authorized users within the bucket owner's account and the access point owner's account. This setting blocks all cross-account access to the access point or bucket (except by AWS service principals), while still allowing users within the account to manage the access point or bucket. This setting also rejects all anonymous (or unsigned) calls.Any denial resulting from the
RestrictPublicBuckets
setting is explicit. For example, ifRestrictPublicBuckets
denies aGetObject
request because of a public bucket or access point policy, you receive the following message:User: arn:aws:iam::
123456789012
:user/MaryMajor
is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1
/object-name
" with an explicit deny in a resource-based policy
For more information about these settings, see Block public access settings. To review and update these settings, see Configuring block public access.
Bucket policies and IAM policies
Bucket-level operations
If there is no bucket policy in place, then the bucket implicitly allows requests from any AWS Identity and Access Management (IAM) identity in the bucket-owner's account. The bucket also implicitly denies requests from any other IAM identities from any other accounts, and anonymous (unsigned) requests. However, if there is no IAM user policy in place, the requester (unless they're the AWS account root user) is implicitly denied from making any requests. For more information about this evaluation logic, see Determining whether a request is denied or allowed within an account in the IAM User Guide.
Object-level operations
If the object is owned by the bucket-owning account, the bucket policy and IAM user policy will function in the same way for object-level operations as they do for bucket-level operations. For example, if there is no bucket policy in place, then the bucket implicitly allows object requests from any IAM identity in the bucket-owner's account. The bucket also implicitly denies object requests from any other IAM identities from any other accounts, and anonymous (unsigned) requests. However, if there is no IAM user policy in place, the requester (unless they're the AWS account root user) is implicitly denied from making any object requests.
If the object is owned by an external account, then access to the object can be granted only through object access control lists (ACLs). The bucket policy and IAM user policy can still be used to deny object requests.
Therefore, to ensure that your bucket policy or IAM user policy isn't causing an Access Denied (403 Forbidden) error, make sure that the following requirements are met:
-
For same-account access, there must not be an explicit
Deny
statement against the requester you are trying to grant permissions to, in either the bucket policy or the IAM user policy. If you want to grant permissions by using only the bucket policy and the IAM user policy, there must be at least one explicitAllow
statement in one of these policies. -
For cross-account access, there must not be an explicit
Deny
statement against the requester that you're trying to grant permissions to, in either the bucket policy or the IAM user policy. To grant cross-account permissions by using only the bucket policy and IAM user policy, make sure that both the bucket policy and the IAM user policy of the requester include an explicitAllow
statement.
Note
Allow
statements in a bucket policy apply only to objects that
are owned by the
same bucket-owning account. However, Deny
statements in
a bucket policy apply to all objects regardless of object ownership.
To review or edit your bucket policy
Note
To view or edit a bucket policy, you must have the
s3:GetBucketPolicy
permission.
Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/
. -
In the left navigation pane, choose Buckets.
-
From the Buckets list, choose the name of the bucket that you want to view or edit a bucket policy for.
-
Choose the Permissions tab.
-
Under Bucket policy, choose Edit. The Edit bucket policy page appears.
To review or edit your bucket policy by using the AWS Command Line Interface (AWS CLI), use the get-bucket-policy
Note
If you get locked out of a bucket because of an incorrect bucket policy, sign in to the AWS Management Console by using your AWS account root user credentials. To regain access to your bucket, make sure to delete the incorrect bucket policy by using your AWS account root user credentials.
Tips for checking permissions
To check whether the requester has proper permissions to perform an Amazon S3 operation, try the following:
-
Identify the requester. If it’s an unsigned request, then it's an anonymous request without an IAM user policy. If it’s a request that uses a presigned URL, then the user policy is the same as the one for the IAM user or role that signed the request.
-
Verify that you're using the correct IAM user or role. You can verify your IAM user or role by checking the upper-right corner of the AWS Management Console or by using the aws sts get-caller-identity command.
-
Check the IAM policies that are related to the IAM user or role. You can use one of the following methods:
-
Review the different IAM policy types.
-
If needed, edit your IAM user policy.
-
Review the following examples of policies that explicitly deny or allow access:
-
Explicit allow IAM user policy: IAM: Allows and denies access to multiple services programmatically and in the console
-
Explicit allow bucket policy: Granting permissions to multiple accounts to upload objects or set object ACLs for public access
-
Explicit deny IAM user policy: AWS: Denies access to AWS based on the requested AWS Region
-
Explicit deny bucket policy: Require SSE-KMS for all objects written to a bucket
-
Amazon S3 ACL settings
When checking your ACL settings, first review your Object Ownership setting to check whether ACLs are enabled on the bucket. Be aware that ACL permissions can be used only to grant permissions and can't be used to reject requests. ACLs also can't be used to grant access to requesters that are rejected by explicit denials in bucket policies or IAM user policies.
The Object Ownership setting is set to bucket owner enforced
If the bucket owner enforced setting is enabled, then ACL settings are unlikely to cause an Access Denied (403 Forbidden) error because this setting disables all ACLs that apply to bucket and objects. Bucket owner enforced is the default (and recommended) setting for Amazon S3 buckets.
The Object Ownership setting is set to bucket owner preferred or object writer
ACL permissions are still valid with the bucket owner preferred setting or the object writer setting. There are two kinds of ACLs: bucket ACLs and object ACLs. For the differences between these two types of ACLs, see Mapping of ACL permissions and access policy permissions.
Depending on the action of the rejected request, check the ACL permissions for your bucket or the object:
-
If Amazon S3 rejected a
LIST
,PUT
object,GetBucketAcl
, orPutBucketAcl
request, then review the ACL permissions for your bucket.Note
You can't grant
GET
object permissions with bucket ACL settings. -
If Amazon S3 rejected a
GET
request on an S3 object, or a PutObjectAcl request, then review the ACL permissions for the object.Important
If the account that owns the object is different from the account that owns the bucket, then access to the object isn't controlled by the bucket policy.
Troubleshooting an Access
Denied (403 Forbidden) error from a GET
object request during
cross-account object ownership
Review the bucket's Object Ownership settings to determine the object owner. If you have
access to the object ACLs, then you
can also check the object owner's account. (To view the object owner's account,
review the object ACL setting in the Amazon S3 console.) Alternatively, you can also make
a GetObjectAcl
request to find the object owner’s canonical
ID to verify the object owner account. By default, ACLs grant explicit
allow permissions for GET
requests to the object owner’s
account.
After you've confirmed that the object owner is different from the bucket owner, then depending on your use case and access level, choose one of the following methods to help address the Access Denied (403 Forbidden) error:
-
Disable ACLs (recommended) – This method will apply to all objects and can be performed by the bucket owner. This method automatically gives the bucket owner ownership and full control over every object in the bucket. Before you implement this method, check the prerequisites for disabling ACLs. For information about how to set your bucket to bucket owner enforced (recommended) mode, see Setting Object Ownership on an existing bucket.
Important
To prevent an Access Denied (403 Forbidden) error, be sure to migrate the ACL permissions to a bucket policy before you disable ACLs. For more information, see Bucket policy examples for migrating from ACL permissions.
-
Change the object owner to the bucket owner – This method can be applied to individual objects, but only the object owner (or a user with the appropriate permissions) can change an object's ownership. Additional
PUT
costs might apply. (For more information, see Amazon S3 pricing.) This method grants the bucket owner full ownership of the object, allowing the bucket owner to control access to the object through a bucket policy. To change the object's ownership, do one of the following:
-
You (the bucket owner) can copy the object back to the bucket.
-
You can change the Object Ownership setting of the bucket to bucket owner preferred. If versioning is disabled, the objects in the bucket are overwritten. If versioning is enabled, duplicate versions of the same object will appear in the bucket, which the bucket owner can set a lifecycle rule to expire. For instructions on how to change your Object Ownership setting, see Setting Object Ownership on an existing bucket.
Note
When you update your Object Ownership setting to bucket owner preferred, the setting is only applied to new objects that are uploaded to the bucket.
-
You can have the object owner upload the object again with the
bucket-owner-full-control
canned object ACL.
Note
For cross-account uploads, you can also require the
bucket-owner-full-control
canned object ACL in your bucket policy. For an example bucket policy, see Grant cross-account permissions to upload objects while ensuring that the bucket owner has full control. -
-
Keep the object writer as the object owner – This method doesn't change the object owner, but it does allow you to grant access to objects individually. To grant access to an object, you must have the
PutObjectAcl
permission for the object. Then, to fix the Access Denied (403 Forbidden) error, add the requester as a grantee to access the object in the object's ACLs. For more information, see Configuring ACLs.
S3 Block Public Access settings
If the failed request involves public access or public policies, then check the S3 Block Public Access settings on your account, bucket, or access point. For more information about troubleshooting access denied errors related to S3 Block Public Access settings, see Access denied due to Block Public Access settings.
Amazon S3 encryption settings
Amazon S3 supports server-side encryption on your bucket. Server-side encryption is the encryption of data at its destination by the application or service that receives it. Amazon S3 encrypts your data at the object level as it writes it to disks in AWS data centers and decrypts it for you when you access it.
By default, Amazon S3 now applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption for every bucket in Amazon S3. Amazon S3 also allows you to specify the server-side encryption method when uploading objects.
To review your bucket's server-side encryption status and encryption settings
Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/
. -
In the left navigation pane, choose Buckets.
-
From the Buckets list, choose the bucket that you want to check the encryption settings for.
-
Choose the Properties tab.
-
Scroll down to the Default encryption section and view the Encryption type settings.
To check your encryption settings by using the AWS CLI, use the get-bucket-encryption command.
To check the encryption status of an object
Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/
. -
In the left navigation pane, choose Buckets.
-
From the Buckets list, choose the name of the bucket that contains the object.
-
From the Objects list, choose the name of the object that you want to add or change encryption for.
The object's details page appears.
-
Scroll down to the Server-side encryption settings section to view the object's server-side encryption settings.
To check your object encryption status by using the AWS CLI, use the head-object command.
Encryption and permissions requirements
Amazon S3 supports three types of server-side encryption:
-
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)
Based on your encryption settings, make sure that the following permissions requirements are met:
-
SSE-S3 – No extra permissions are required.
-
SSE-KMS (with a customer managed key) – To upload objects, the
kms:GenerateDataKey
permission on the AWS KMS key is required. To download objects and perform multipart uploads of objects, thekms:Decrypt
permission on the KMS key is required. -
SSE-KMS (with an AWS managed key) – The requester must be from the same account that owns the
aws/s3
KMS key. The requester must also have the correct Amazon S3 permissions to access the object. -
SSE-C (with a customer provided key) – No additional permissions are required. You can configure the bucket policy to require and restrict server-side encryption with customer-provided encryption keys for objects in your bucket.
If the object is encrypted with a customer managed key, make sure that the KMS key policy
allows you to perform the kms:GenerateDataKey
or
kms:Decrypt
actions. For instructions on checking your KMS key
policy, see Viewing a key
policy in the AWS Key Management Service Developer Guide.
S3 Object Lock settings
If your bucket has S3 Object Lock enabled and the object is protected by a retention period or legal hold, Amazon S3 returns an Access Denied (403 Forbidden) error when you try to delete the object.
To check whether the bucket has Object Lock enabled
Sign in to the AWS Management Console and open the Amazon S3 console at https://console.aws.amazon.com/s3/
. -
In the left navigation pane, choose Buckets.
-
From the Buckets list, choose the name of the bucket that you want to review.
-
Choose the Properties tab.
-
Scroll down to the Object Lock section. Verify whether the Object Lock setting is Enabled or Disabled.
To determine whether the object is protected by a retention period or legal hold, view the lock information for your object.
If the object is protected by a retention period or legal hold, check the following:
-
If the object version is protected by the compliance retention mode, there is no way to permanently delete it. A permanent
DELETE
request from any requester, including the AWS account root user, will result in an Access Denied (403 Forbidden) error. Also, be aware that when you submit aDELETE
request for an object that's protected by the compliance retention mode, Amazon S3 creates a delete marker for the object. -
If the object version is protected with governance retention mode and you have the
s3:BypassGovernanceRetention
permission, you can bypass the protection and permanently delete the version. For more information, see Bypassing governance mode. -
If the object version is protected by a legal hold, then a permanent
DELETE
request can result in an Access Denied (403 Forbidden) error. To permanently delete the object version, you must remove the legal hold on the object version. To remove a legal hold, you must have thes3:PutObjectLegalHold
permission. For more information about removing a legal hold, see Configuring S3 Object Lock.
VPC endpoint policy
If you're accessing Amazon S3 by using a virtual private cloud (VPC) endpoint, make sure that the VPC endpoint policy isn't blocking you from accessing your Amazon S3 resources. By default, the VPC endpoint policy allows all requests to Amazon S3. You can also configure the VPC endpoint policy to restrict certain requests. For information about how to check your VPC endpoint policy, see Control access to VPC endpoints by using endpoint policies in the AWS PrivateLink Guide.
AWS Organizations policies
If your AWS account belongs to an organization, AWS Organizations policies can block you from accessing Amazon S3 resources. By default, AWS Organizations policies don't block any requests to Amazon S3. However, make sure that your AWS Organizations policies haven’t been configured to block access to S3 buckets. For instructions on how to check your AWS Organizations policies, see Listing all policies in the AWS Organizations User Guide.
Access point settings
If you receive an Access Denied (403 Forbidden) error while making requests through Amazon S3 access points, you might need to check the following:
-
The configurations for your access points
-
The IAM user policy that's used for your access points
-
The bucket policy that's used to manage or configure your cross-account access points
Access point configurations and policies
-
When you create an access point, you can choose to designate Internet or VPC as the network origin. If the network origin is set to VPC only, Amazon S3 will reject any requests made to the access point that don't originate from the specified VPC. To check the network origin of your access point, see Creating access points restricted to a virtual private cloud.
-
With access points, you can also configure custom Block Public Access settings, which work similarly to the Block Public Access settings at the bucket or account level. To check your custom Block Public Access settings, see Managing public access to access points.
-
To make successful requests to Amazon S3 by using access points, make sure that the requester has the necessary IAM permissions. For more information, see Configuring IAM policies for using access points.
-
If the request involves cross-account access points, make sure that the bucket owner has updated the bucket policy to authorize requests from the access point. For more information, see Granting permissions for cross-account access points.
If the Access Denied (403 Forbidden) error still persists after checking all the items in this topic, retrieve your Amazon S3 request ID and contact AWS Support for additional guidance.