Why do I receive 403 Access Denied when I use an S3 REST API origin in my CloudFront distribution?
Summary
TLDRこのビデオでは、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
😀 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キーポリシーの更新方法も紹介されています。
🔒 S3バケットの暗号化とオブジェクト所有権の確認
この段落では、S3バケットがKMSで暗号化されている場合のCloudFrontのアクセス制御について解説しています。オリジンアクセスアイデンティティ(OAI)を使用している場合、OACを使用してCloudFrontがS3にアクセスできるようにKMSキーポリシーを更新する必要がある点に焦点を当てています。また、S3 CLIを使用してオブジェクトがKMSで暗号化されているかを確認する方法や、S3バケットのデフォルト暗号化設定を確認する方法も説明されています。
📝 S3バケットポリシーの確認とオブジェクト所有権の不一致の解決
この段落では、OACまたはOAIを使用する際に必要なS3バケットポリシーの確認方法と、オブジェクト所有権の不一致を解決する手順について説明しています。S3バケットの所有者が異なる場合に発生する403エラーとその解決方法、オブジェクトが存在しない場合のCloudFrontの動作、そしてオブジェクトの存在を確認し、キャッシュされた403エラーを無効にする方法について学びます。
🌐 CloudFrontのルートオブジェクトとアクセスログの活用
最後の段落では、CloudFrontのルートオブジェクトを設定し、403エラーを回避する方法について解説しています。また、CloudFrontとS3のアクセスログを活用して403エラーをテストまたは調査する際のベストプラクティスについても触れています。ログからリクエストIDを取得し、AWSプレミアムサポートに連絡する際にそれらを共有することで、より迅速なサポートを得る方法も紹介されています。
Mindmap
Keywords
💡Amazon CloudFront
💡Amazon S3
💡403アクセス拒否エラー
💡Origin Access Control (OAC)
💡Origin Access Identity (OAI)
💡AWS Signature Version 4
💡AWS Key Management Service (KMS)
💡Lambda@Edge
💡Bucket Policy
💡Invalidation
💡Default Root Object
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]
Browse More Related Video
How do I troubleshoot health check failures for Amazon ECS tasks on Fargate?
【13分で解説】ビジネスフレームワーク図鑑 すぐ使える問題解決・アイデア発想ツール
Elasticsearch バージョンアップでのパフォーマンス低下の原因がベトナム語プラグインだった件 - AWS サポート Technical Deep Dive 事例紹介
Set up permissions for creating private offers on Marketplace | Amazon Web Services
E-BIKE Conversion SW 900 ERROR Code 09 Troubleshooting | DIY Petz
【必見】Snap Cameraに代わるパソコンカメラで使えるビューティーエフェクト見つけたよ!
5.0 / 5 (0 votes)