Why do I receive 403 Access Denied when I use an S3 REST API origin in my CloudFront distribution?

Summary

このビデオでは、AWSのクラウドサポートエンジニアであるAaronが、Amazon CloudFrontの403アクセス拒否エラーを特定し解決する方法を紹介しています。特に、Amazon S3のREST APIオリジンを使用する場合のエラー対応について、Origin Access Control（OAC）の設定や、AWS KMSで暗号化されたオブジェクトへのアクセス権限の付与、そしてオブジェクト所有者の不一致を解決する手順を解説しています。また、CloudFrontの標準ログとS3のサーバーアクセスログを活用して問題を調査し、403エラーを解決するためのベストプラクティスを紹介しています。

Takeaways

• 🌐 AWSのCloudFrontの403アクセス拒否エラーを特定し解決する方法について説明しています。
• 📁 S3バケットをCloudFrontのオリジンとして設定する方法は、REST APIエンドポイントまたはウェブサイトエンドポイントのいずれかです。
• 🔍 CloudFrontコンソールでS3オリジンタイプを確認する方法が紹介されています。
• 🛡️ S3 REST APIオリジンを使用するCloudFrontディストリビューションには、オリジンアクセス制御（OAC）またはオリジンアクセスアイデンティティ（OAI）を使用して十分なアクセス権を設定する必要があります。
• 🔑 S3オブジェクトがAWS KMSで暗号化されている場合、OACを使用してCloudFrontがS3に署名付きリクエストを送信できるようにすることが推奨されています。
• 📝 KMSキーポリシーを更新して、OACにキーを使用する権限を付与する必要があります。
• 🔍 S3バケットのオブジェクトがKMSで暗号化されているか確認する方法が示されています。
• 📜 CloudFrontとS3 REST APIオリジンでOACまたはOAIを使用する場合のバケットポリシーの確認方法が説明されています。
• 🤖 オブジェクト所有者が異なるAWSアカウントに属する場合、403エラーが発生する可能性があるため、所有権の不一致を解決する手順が提供されています。
• 🚫 CloudFrontがS3 REST APIオリジンにリクエストを転送する際にオブジェクトが存在しない場合、S3は403エラーを返すことに注意してください。
• 🗑️ CloudFrontのキャッシュから403エラーをクリアするために、無効化（Invalidation）を作成する方法が紹介されています。
• 📄 CloudFrontのルートにアクセスする際には、デフォルトのルートオブジェクトを指定する必要があります。
• 📊 CloudFrontの標準ログとS3のサーバーアクセスログを実装して、403エラーのテストや調査を行うことが推奨されています。

Q & A

Amazon CloudFrontの403アクセス拒否エラーはどのように識別しますか？

CloudFrontコンソールで対象のディストリビューションを選択し、オリジンタブでS3オリジンのドメイン値を確認します。値がexamplebucket.s3.region.amazonaws.comの形式であればREST APIエンドポイントを示し、examplebucket.s3-website-region.amazonaws.comの形式であればウェブサイトエンドポイントを示します。

S3バケットをCloudFrontオリジンとして構成する方法は？

S3バケットをCloudFrontオリジンとして構成するには、バケットのREST APIエンドポイントまたはウェブサイトエンドポイントとして設定します。AWSマネジメントコンソールを使用して、CloudFrontディストリビューションのオリジンタブでオリジンタイプを確認します。

オリジンアクセスコントロール(OAC)を使用する場合の設定手順は？

CloudFrontコンソールで、セキュリティの下にあるオリジンアクセスを選択し、デフォルトのコントロール設定タブでコントロール設定を作成します。名前を入力し、署名の動作として「リクエストに署名」を選択します。OACの署名動作が「リクエストに署名しない」に設定されていると403エラーが発生します。

AWS KMSで暗号化されたオブジェクトに対する設定手順は？

KMSキーのポリシーを更新してOACにキー使用権限を付与します。KMSコンソールでキーを選択し、キーのポリシーを編集して必要なポリシーを適用します。

バケットポリシーを確認する方法は？

OACをCloudFrontディストリビューションに関連付けると、必要なバケットポリシーが生成されます。生成されたポリシーをコピーして、S3バケットのパーミッションセクションに貼り付けて保存します。

オブジェクトの所有者が異なる場合の対処方法は？

S3バケットのオーナーアカウントとオブジェクトのオーナーアカウントが異なる場合、403エラーが発生します。オブジェクトの所有権を変更するか、必要なACL権限を設定します。

403エラーのキャッシュをクリアする方法は？

CloudFrontディストリビューションの無効化タブで無効化を作成し、オブジェクトのURIパスを入力して無効化を作成します。これにより、CloudFrontのキャッシュがクリアされ、新しいオリジンリクエストが行われます。

ディストリビューションのルートへのアクセス時に403エラーが発生する場合の対処法は？

デフォルトルートオブジェクトを指定する必要があります。CloudFrontコンソールでディストリビューションを編集し、デフォルトルートオブジェクトにS3の対象オブジェクトを設定します。

S3オブジェクト名の大文字小文字の区別に関する注意点は？

S3オブジェクト名は大文字小文字を区別します。CloudFrontへのリクエストURIがS3オブジェクト名と完全に一致することを確認してください。

CloudFrontとS3のログを活用して403エラーを調査する方法は？

CloudFront標準ログとS3サーバアクセスログを有効にします。CloudFrontログにはリクエスト結果、URI、HTTP応答コードが記録され、S3ログにはオブジェクトキー、操作、HTTPステータスが記録されます。

Outlines

00:00

😀 Amazon CloudFront 403 エラーの特定と解決

この段落では、AWSのCloud SupportエンジニアであるAaronが、Amazon Simple Storage Service (S3) REST APIオリジンを使用する際に発生するCloudFrontの403アクセス拒否エラーを特定し解決する方法を説明しています。S3バケットのオリジンタイプを特定する方法、Origin Access Control (OAC)の設定、AWS Signature V4でのリクエスト認証、またはオブジェクトの公開アクセスの設定について学びます。さらに、S3オリジンにAWS Key Management Service (KMS)で暗号化されたオブジェクトを使用している場合のKMSキーポリシーの更新方法も紹介されています。

05:00

🔒 S3バケットの暗号化とオブジェクト所有権の確認

この段落では、S3バケットがKMSで暗号化されている場合のCloudFrontのアクセス制御について解説しています。オリジンアクセスアイデンティティ(OAI)を使用している場合、OACを使用してCloudFrontがS3にアクセスできるようにKMSキーポリシーを更新する必要がある点に焦点を当てています。また、S3 CLIを使用してオブジェクトがKMSで暗号化されているかを確認する方法や、S3バケットのデフォルト暗号化設定を確認する方法も説明されています。

10:01

📝 S3バケットポリシーの確認とオブジェクト所有権の不一致の解決

この段落では、OACまたはOAIを使用する際に必要なS3バケットポリシーの確認方法と、オブジェクト所有権の不一致を解決する手順について説明しています。S3バケットの所有者が異なる場合に発生する403エラーとその解決方法、オブジェクトが存在しない場合のCloudFrontの動作、そしてオブジェクトの存在を確認し、キャッシュされた403エラーを無効にする方法について学びます。

15:04

🌐 CloudFrontのルートオブジェクトとアクセスログの活用

最後の段落では、CloudFrontのルートオブジェクトを設定し、403エラーを回避する方法について解説しています。また、CloudFrontとS3のアクセスログを活用して403エラーをテストまたは調査する際のベストプラクティスについても触れています。ログからリクエストIDを取得し、AWSプレミアムサポートに連絡する際にそれらを共有することで、より迅速なサポートを得る方法も紹介されています。

Keywords

💡Amazon CloudFront

Amazon CloudFrontはAWSが提供するコンテンツデリバリーネットワークサービスであり、静的ウェブサイトや動的なウェブアプリケーションのコンテンツを高速で効率的に配信することができます。このビデオでは、CloudFrontの403アクセス拒否エラーを特定し、解決する方法について学びます。

💡Amazon S3

Amazon S3はAWSのオブジェクトストレージサービスで、ウェブサイト、アプリケーション、データをスケーラブルかつセキュアに保存することができます。ビデオでは、S3バケットをCloudFrontのオリジンとして設定する方法と、それに関する403エラーの解決策について説明しています。

💡403アクセス拒否エラー

403アクセス拒否エラーは、ウェブサーバーがリクエストを理解しているが、リクエストを許可しない場合に発生するHTTPエラーです。ビデオでは、このエラーがS3とCloudFrontの間で発生する状況と、その解決方法について詳しく説明しています。

💡Origin Access Control (OAC)

Origin Access ControlはCloudFrontで使用される機能で、S3バケットへのアクセスを制御します。ビデオでは、OACを使用してCloudFrontがS3バケットのオブジェクトにアクセスできるように設定する方法について説明しています。

💡Origin Access Identity (OAI)

Origin Access IdentityはCloudFrontで使用される機能で、S3オリジンへのリクエストを認証するために使用されます。ビデオでは、OAIを使用する際のアクセス設定と、それが403エラー解決にどのように役するかについて触れています。

💡AWS Signature Version 4

AWS Signature Version 4は、AWSサービスへのリクエストを認証するための署名プロトコルです。ビデオでは、この署名バージョンを使用してリクエストを認証し、S3バケットへのアクセスを許可する方法について学びます。

💡AWS Key Management Service (KMS)

AWS Key Management Serviceは、AWS上のデータを暗号化するためのキー管理サービスです。ビデオでは、S3バケット内の暗号化されたオブジェクトにアクセスする際にKMSとOACを組み合わせて使用する必要性について説明しています。

💡Lambda@Edge

Lambda@Edgeは、Lambda関数をエッジロケーションで実行できるAWSサービスで、CloudFrontのキャッシュやリクエスト/レスポンスをカスタマイズするために使用されます。ビデオでは、Lambda@Edgeを使用してKMSで暗号化されたS3オブジェクトを提供する方法について言及しています。

💡Bucket Policy

Bucket PolicyはS3バケットに関連付けられたアクセスポリシーで、どのユーザーやサービスがバケット内のオブジェクトにアクセスできるかを制御します。ビデオでは、OACやOAIを使用する際に必要なバケットポリシーの設定方法について詳しく説明しています。

💡Invalidation

InvalidationはCloudFrontで使用される機能で、キャッシュから特定のオブジェクトやパスを削除することができます。ビデオでは、403エラーがキャッシュにある場合に、Invalidationを使用してキャッシュをクリアし、新しいオリジンリクエストを可能にする方法について学びます。

💡Default Root Object

Default Root Objectは、CloudFrontのディストリビューションのルートパスにアクセスしたときに提供されるオブジェクトです。ビデオでは、S3バケットに指定されたデフォルトルートオブジェクトがない場合に403エラーが発生する理由と、その設定方法について説明しています。

Highlights

Aaron, a cloud support engineer at AWS, demonstrates resolving Amazon CloudFront 403 access denied errors with S3 REST API origin.

Two ways to configure an Amazon S3 bucket as a CloudFront origin: REST API endpoint or website endpoint.

Guide on confirming S3 origin type via AWS Management Console by checking the origin domain value.

Differences between accessing S3 website endpoints and REST API endpoints are discussed.

Explanation of using Origin Access Control (OAC) or Origin Access Identity (OAI) for access configuration.

Best practice for accessing S3 REST API origin through CloudFront distribution is using an OAC.

Step-by-step guide to creating a new OAC in the AWS Management Console.

Importance of setting signing behavior to 'always sign requests' in OAC to avoid 403 errors.

How to handle S3 origins with objects encrypted with AWS Key Management Service (KMS) using OAC.

Updating KMS key policy to grant OAC permission to use the key for encrypted objects.

Use of Origin Request Lambda Edge function to serve objects from KMS encrypted S3 origins.

Verification of object encryption status through bucket properties or AWS CLI.

Confirmation of bucket policy when using OAC or OAI and the automatic generation of necessary bucket policy.

Procedure to update the S3 bucket policy after creating an OAC distribution.

Handling cases where S3 objects are owned by a different AWS account and resolving object owner mismatch.

Using AWS CLI to confirm the owner of an object in S3 and the steps to resolve ownership issues.

Explanation of why S3 returns a 403 error when the requested object does not exist at the time of the request.

Process of creating an invalidation in CloudFront to clear cache and allow fresh origin requests.

Importance of specifying a default root object to avoid 403 errors when accessing the root of a distribution.

Details on suppressing 404 responses from S3 due to lack of list bucket access in bucket policy.

Recommendation to use CloudFront standard logs and S3 server access logs for troubleshooting 403 errors.

AWS premium support's role in resolving 403 errors with request IDs from logs.

Transcripts

[Music]

[Applause]

[Music]

hello I'm Aaron the cloud support

engineer here at AWS today I'm going to

show you how to identify and resolve

Amazon cloudfront 403 access denied

errors when you use an Amazon simple

storage service S3 rest API origin let's

get

started how do I identify my S3 bucket

Origins endpoint type there are two ways

that you can configure an Amazon S3

bucket as a cloudfront origin either as

the bucket's rest API endpoint or the

bucket's website endpoint follow along

with me in the AWS Management console to

confirm your S3 origin

type open the cloudfront

console select the cloudfront

distribution whose origin you want to

check choose the origins tab

note the origin domain value for the S3

origin if the value is similar to

example bucket. s3. region.

amazonaws.com or example bucket. s3.

Amazon aws.com then this indicates that

the origin is an S3 buckets rest API

endpoint if the value is instead similar

to example bucket. s3- website -

us-- one. Amazon aws.com then this

indicates that the origin is an S3

buckets website end

point if you're experiencing 403 access

denied errors with an S3 website origin

visit our repost discussion on the topic

to understand the differences between

accessing S3 website endpoints and

accessing rest API

endpoints what if I'm using an origin

access ACC control when you use an S3

rest API origin within a cloudfront

distribution the distribution must have

sufficient access to the buckets objects

to configure access you can use either

An Origin Access Control OAC or in

origin access identity oi you can also

authenticate requests using AWS

signature V4 or make the objects

publicly accessible for most use cases

where a cloudfront distribution must

access an S3 rest API origin it's a best

practice to use an

OAC here's how to create a new OAC in

the AWS Management console open the

cloudfront

console under security choose origin

access under the default control

settings tab choose create control

setting enter a name for your OAC

optionally you can enter a

description under settings make sure

that sign requests recommended is

selected for the signing Behavior if

your OAC is set to do not sign requests

then cloudfront can't access the S3

bucket which causes a 403 error if your

client applications can sign requests

and your use case involves toggling

between client signed and cloudfront

signed authorization headers

then you can also select do not override

authorization header for most use cases

you don't need to turn on this feature

I'll keep it

unselected make sure that your origin

type is set to S3 choose

create remember that for an OAC

configuration you must always set

signing Behavior to always sign requests

otherwise cloudfront can't sign requests

that are made against your S3 rest API

origin and you will receive a 403 access

denied

error what if my bucket contains objects

that are encrypted with AWS KMS if your

S3 rest API origin has objects that are

encrypted with AWS Key Management

Service and you're using an oai for your

distribution then you must instead use

an OAC so that cloudfront can properly

sign requests to S3 for en crypted

objects you must also update the KMS key

policy to Grant the OAC permission to

use the key such as in the following

policy from my own

key let's go to KMS together make sure

customer manage keys are selected for

this scenario and then select the key in

question once the key in question is

selected edit its key

policy and ensure that the policy shown

on the screen is implemented using your

account

information you can also use an origin

request Lambda Edge function to serve

objects from KMS encrypted S3 rest API

Origins more information about how to

use this function including sample code

see our Solutions architect blog post

for more information to confirm whether

your objects are encrypted you can

either check your buckets properties to

see if AWS KMS is selected for

encryption or use the AWS command line

interface to run a head object command

against an object in your

bucket let's navigate the S3 to check

our

bucket select the KMS encrypted

bucket navigate to

properties scroll down to its default

encryption

setting if the encryption types as

server side encryption with Amazon S3

manage Keys then your bucket is

encrypted by default if you would

instead like to verify using the AWS CLI

let's navigate to

cloudshell if the output from the

following AWS CLI command shows AWS KMS

for serers side encryption then your

object is encrypted as you can see in my

output the server side encryption output

field is set to awmf

showing that my buckets index.html file

was

encrypted how do I confirm my bucket

policy when I use an OAC or oai when you

create and Associate an OAC with your

cloudfront distribution the necessary

bucket policy is generated for you if

you didn't copy the policy when you

created your distribution or you want to

confirm your current policy then use the

example policy shown

below I will also walk with you in

creating an OAC distribution let's start

by navigating the cloud front next let's

click on create

distribution under origin domain select

a S3 rest API bucket under origin access

select origin access control settings

recommended under origin Access Control

select your origin access

control the rest of your distribution

settings are at your own discretion I

will go through with some defaults I

find helpful for troubleshooting

once the distribution is created you

will see a popup saying that the S3

bucket policy needs to be updated you

may click on copy policy so the policy

statement is copied to your clipboard

and then you may click the goto S3

bucket permissions

hyperlink once here you may scroll down

to the bucket policy section click edit

and paste the statement that you copied

from

cloudfront Once pasted you may save the

policy when you use an oai go to the

bucket in the Amazon S3 console and then

manually attach the bucket policy I will

show you one of my oi enabled buckets

let's navigate to

S3 I will now select my oi specific

bucket under my buckets permissions tab

will be a policy that you may use with

your own account information to

configure oi permission

this bucket policy is specific to my

distribution and AWS

account what if my buckets objects are

owned by a different AWS account for a

bucket policy to apply to external

accounts or Services the AWS account

that owns the bucket must also own the

objects if your S3 rest API Origins

objects are owned by another account

then Amazon S3 responds with a 403 error

because because of an object owner

mismatch for more information on this

topic let's navigate the cloud shell to

get your account's S3 canonical ID run

the following AWS CLI command to confirm

the owner of an object in S3 run the

following AWS CLI command note how in my

example the first command's owner ID

matches the second commands owner ID if

the canonical IDs don't match then the

bucket and object have different owners

in this case complete the following

steps to resolve the object owner

mismatch from the object owner's account

run the following command to get the

access control list permissions that are

assigned to the object if the object has

bucket owner full control ACL

permissions then skip this step if the

object doesn't have bucket owner full

control ACL permissions then run the

following command from the object

owner's account from the bucket owner's

account run the following command to

change the owner of the object by

copying the object over

itself if cloudfront still returns a 403

error then confirm that the requested

object existed in S3 at the time of the

request when cloudfront forwards a

request to your S3 rest API origin and

the object doesn't exist S3 returns a

403

error let's use one of my distributions

as an

example this null. txt object does not

currently exist in this distribution's

bucket so I will receive a 403 error

when attempting to access it however if

I navigate back to my Management console

go to

S3 select my bucket where the object

doesn't exist and upload the object in

question

I can then resend the request through

cloudfront and be presented with the

content if you find a non-existent

object upload it and still receive a 403

error then the 403 response might be

cached to reconfirm access create an

invalidation for the objects URI I will

show you how to create an invalidation

for this object in the Management

console let's navigate the cloud front

select the distribution in question

click on the invalidations tab click on

create invalidation enter the URI path

of the object and question finally click

on create

invalidation once this invalidation is

complete cloudfront will clear its cache

of this 403 for this object to allow for

a fresh origin request to take place if

further 403s are still occurring then

you may roll this root cause out because

S3 object names are case sensitive also

confirm that the request Uris that you

send to cloudfront exactly match the S3

object name for instance in my

cloudfront tab if I tried accessing

capital N null. txt I would also receive

a

403 what if clients receive 403s when

making requests against the root of my

distribution for viewers to access your

distribution at its root you must

specify a default root object otherwise

S3 returns a 403

error let's navigate to my environment

in the AWS web console let's go to Cloud

front let's select one of the

distributions where I do not yet have a

default root object

specified for this distribution I do

have an

index.html in the corresponding buckets

directory however when I navigate to it

I will receive a

403 to rectify this issue let's go back

to our distribution and click edit under

settings once within your distribution

settings under default root object

specify the object in S3 of your default

root object once entered let's scroll

all the way to the bottom and save our

changes once your last modified time

changes from deploying to a timestamp

you will be able to verify the changes

you just made to your

distribution now that my distribution

has been updated now let's attempt to go

to the root of

it and we will now see that because an

default root object is specified we will

not receive a 403

error 403 errors suppress a 404 response

from S3 because the bucket policy isn't

granting S3 list bucket access which is

required for S3 requests that don't

specify a specific object note that it's

not a security best practice to allow S3

list bucket Public Access S3 list bucket

Public Access allows users to see and

list all objects in a bucket this

exposes object metadata details such as

key and size to users even if the users

don't have permissions to to download

the

object to better understand what happens

during requests in cloudfront and your

S3 rest API origin when you test or

investigate 403 errors it's a best

practice to implement cloudfront

standard logs and S3 server access logs

the cloudfront logs provide you with

relevant request results such as URI

HTTP verb HTTP Response Code and result

type the S3 logs provide you with the

object key operation HTTP status and

signature version if you need additional

support to resolve the 403 errors then

you can find request IDs for each

service in these logs when you contact

AWS premium support share these request

IDs so that we can better help

you thanks for watching and happy cloud

computing from all of us here at AWS

[Applause]

[Music]

[Music]