S3静的ウェブサイトホスティングをAWS CLIで設定｜403・404の原因

S3 の静的ウェブサイトホスティングは、「ブロックパブリックアクセスを緩める → 読み取りを許可するバケットポリシーを付ける → インデックスドキュメントを指定する → ファイルを置く」の4つがそろうと表示されます。 403 はたいてい前の2つ（公開の許可）、404 は後ろの2つ（ウェブサイト設定とファイルの場所）のどこかが欠けているときに返ります。

この記事では、バケット作成から公開までを AWS CLI のコマンドだけで通し、設定を確かめるコマンドとその出力を載せます。後半では 403 と 404 の原因を早見表にまとめ、リダイレクトの JSON 例、リージョンごとのエンドポイントの書式も一覧にします。

確認環境：Linux、AWS CLI 1.46.1。AWS の API をローカルで再現するツール（moto 5.2.3）で実行しています。掲載するコマンドは実際の AWS でそのまま使える形です。ウェブサイトエンドポイントが返す HTTP の応答（403・404・リダイレクト）は、AWS の公式ドキュメントの記載にもとづいています。

設定コマンドと 403・404 の早見表

設定の流れです。上から順に実行します。

エラーが出たときの最初の切り分けです（くわしい表は後半にあります）。

公開するファイルを用意する

次の構成のフォルダ site を作ります。

site/
├── index.html
├── error.html
├── assets/
│   └── style.css
└── blog/
    └── index.html

site/index.html:

<!doctype html>
<html lang="ja"><head><meta charset="utf-8"><title>Example Site</title>
<link rel="stylesheet" href="/assets/style.css"></head>
<body><h1>Hello from S3</h1><p><a href="/blog/">Blog</a></p></body></html>

site/error.html:

<!doctype html>
<html lang="ja"><head><meta charset="utf-8"><title>Not Found</title></head>
<body><h1>ページが見つかりません</h1><p><a href="/">トップへ戻る</a></p></body></html>

site/blog/index.html:

<!doctype html>
<html lang="ja"><head><meta charset="utf-8"><title>Blog</title></head>
<body><h1>Blog</h1></body></html>

site/assets/style.css:

body { font-family: sans-serif; }

手順1：バケットを作る

aws s3 mb s3://example-site-bucket --region ap-northeast-1

make_bucket: example-site-bucket

バケット名は全世界で重複できないので、実際には自分用の名前に置き換えます。リージョンはあとでエンドポイントの URL に使うので、確かめておきます。

aws s3api get-bucket-location --bucket example-site-bucket

{
    "LocationConstraint": "ap-northeast-1"
}

この時点では、ウェブサイト設定もバケットポリシーもありません。確認コマンドは次のように「設定がない」ことを知らせます。この2つのメッセージは、あとの切り分けでも目印になります。

aws s3api get-bucket-website --bucket example-site-bucket

An error occurred (NoSuchWebsiteConfiguration) when calling the GetBucketWebsite operation: The specified bucket does not have a website configuration

aws s3api get-bucket-policy --bucket example-site-bucket

An error occurred (NoSuchBucketPolicy) when calling the GetBucketPolicy operation: The bucket policy does not exist

手順2：ブロックパブリックアクセスを緩める（put-public-access-block）

ブロックパブリックアクセスは、バケットがうっかり公開されるのを防ぐ4つの設定です。公式ドキュメントのとおり、新しいバケットは既定で公開を許可しません。

バケットポリシーで公開する場合、緩めるのはポリシーに関する2つだけで足ります。ACL に関する2つは true のまま残します。

pab-off.json:

{
  "BlockPublicAcls": true,
  "IgnorePublicAcls": true,
  "BlockPublicPolicy": false,
  "RestrictPublicBuckets": false
}

aws s3api put-public-access-block --bucket example-site-bucket \
  --public-access-block-configuration file://pab-off.json

aws s3api get-public-access-block --bucket example-site-bucket

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": false,
        "RestrictPublicBuckets": false
    }
}

この手順を飛ばして先にバケットポリシーを付けようとすると、BlockPublicPolicy によって put-bucket-policy が拒否されます。 順番は「緩める → ポリシー」です。

ブロックパブリックアクセスはアカウント単位でも設定でき、バケットとアカウントで設定が違うときは厳しいほうが使われます。バケット側を false にしても 403 が続くときは、アカウント単位の設定も見ます。

手順3：読み取りを許可するバケットポリシーを付ける（put-bucket-policy）

だれでもオブジェクトを読めるようにするポリシーです。

public-read.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-site-bucket/*"
    }
  ]
}

aws s3api put-bucket-policy --bucket example-site-bucket --policy file://public-read.json

aws s3api get-bucket-policy --bucket example-site-bucket --query Policy --output text

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-site-bucket/*"
    }
  ]
}

見るところは2つです。

• Resource の末尾が /* になっているか。s3:GetObject はオブジェクトに対する操作なので、バケットの ARN（arn:aws:s3:::example-site-bucket）だけでは対象になりません
• バケット名が自分のものになっているか。ほかの記事から写したままだと、別のバケットを指してしまいます

get-bucket-policy は Policy を1つの文字列で返すので、--query Policy --output text を付けると JSON として読みやすくなります。

手順4：ウェブサイトホスティングを有効にする

aws s3 website で設定する

インデックスドキュメント（フォルダの URL を開いたときに返すファイル）とエラードキュメントを指定します。

aws s3 website s3://example-site-bucket/ \
  --index-document index.html --error-document error.html

aws s3api get-bucket-website --bucket example-site-bucket

{
    "IndexDocument": {
        "Suffix": "index.html"
    },
    "ErrorDocument": {
        "Key": "error.html"
    }
}

aws s3 website は成功しても何も表示しないので、get-bucket-website で設定が入ったことを確かめます。

put-bucket-website の JSON で設定する

同じ設定を JSON で書くと次のようになります。リダイレクトのルールを足すときはこちらを使います。

website.json:

{
  "IndexDocument": { "Suffix": "index.html" },
  "ErrorDocument": { "Key": "error.html" }
}

aws s3api put-bucket-website --bucket example-site-bucket \
  --website-configuration file://website.json

Suffix という名前のとおり、インデックスドキュメントはフォルダごとに探されます。/blog/ を開くと blog/index.html が返ります。公式ドキュメントによると、名前は大文字と小文字を区別し、index.html と設定したら Index.html は対象になりません。

手順5：ファイルをアップロードする（sync）

aws s3 sync site/ s3://example-site-bucket/ --delete

upload: site/blog/index.html to s3://example-site-bucket/blog/index.html
upload: site/error.html to s3://example-site-bucket/error.html
upload: site/assets/style.css to s3://example-site-bucket/assets/style.css
upload: site/index.html to s3://example-site-bucket/index.html

--delete は、手元にないファイルをバケットからも消すオプションです。置いた結果を確かめます。

aws s3 ls s3://example-site-bucket/ --recursive

2026-10-05 15:46:14         34 assets/style.css
2026-10-05 15:46:14        121 blog/index.html
2026-10-05 15:46:14        196 error.html
2026-10-05 15:46:14        219 index.html

index.html がバケットの直下にあることが大事です。ブラウザが HTML として表示するには Content-Type も必要で、aws s3 sync は拡張子から自動で付けます。

aws s3api head-object --bucket example-site-bucket --key index.html \
  --query '[ContentType,ContentLength]' --output text
aws s3api head-object --bucket example-site-bucket --key assets/style.css \
  --query ContentType

text/html   219
"text/css"

キーの階層がずれる例

コピー先にフォルダ名を付けると、キーが1階層深くなります。--dryrun で、どこに置かれるかを先に見られます。

aws s3 sync site s3://example-site-bucket/site --dryrun

(dryrun) upload: site/assets/style.css to s3://example-site-bucket/site/assets/style.css
(dryrun) upload: site/blog/index.html to s3://example-site-bucket/site/blog/index.html
(dryrun) upload: site/error.html to s3://example-site-bucket/site/error.html
(dryrun) upload: site/index.html to s3://example-site-bucket/site/index.html

この形で置くと、index.html のキーは site/index.html になり、サイトのトップ（/）にはインデックスドキュメントが見つからなくなります。フォルダそのものではなく、フォルダの中身をバケットの直下に置くのがポイントです。

ウェブサイトエンドポイントの URL を組み立てる

公開された URL は、REST API 用の URL とは別の「ウェブサイトエンドポイント」です。書式はリージョンによって2種類あります。

AWS の一般リファレンス（S3 のエンドポイント一覧）によると、ハイフン区切りは次の9リージョンで、それ以外はドット区切りです。

日本のリージョンで見ると、東京と大阪で書式が違います。

バケットのリージョンから URL を組み立てるスクリプトです。

website-url.sh:

#!/usr/bin/env bash
# 使い方: ./website-url.sh バケット名
set -euo pipefail
BUCKET="$1"
REGION=$(aws s3api get-bucket-location --bucket "$BUCKET" \
  --query LocationConstraint --output text)
# us-east-1 のバケットは LocationConstraint が空で返る
[ "$REGION" = "None" ] && REGION="us-east-1"
case "$REGION" in
  us-east-1|us-west-1|us-west-2|ap-southeast-1|ap-southeast-2|ap-northeast-1|eu-west-1|sa-east-1|us-gov-west-1)
    SEP="-" ;;
  *)
    SEP="." ;;
esac
echo "http://${BUCKET}.s3-website${SEP}${REGION}.amazonaws.com"

東京・大阪・バージニア北部に作ったバケットで実行した結果です。

chmod +x website-url.sh
./website-url.sh example-site-bucket
./website-url.sh example-site-osaka
./website-url.sh example-site-virginia

http://example-site-bucket.s3-website-ap-northeast-1.amazonaws.com
http://example-site-osaka.s3-website.ap-northeast-3.amazonaws.com
http://example-site-virginia.s3-website-us-east-1.amazonaws.com

出てきた URL をブラウザで開くと、index.html が表示されます。

REST エンドポイントとの違い

https://バケット名.s3.ap-northeast-1.amazonaws.com/ のような REST API 用の URL は、ウェブサイトとしての動きをしません。公式ドキュメントの比較表の要点です。

XML のエラーが表示されたら、開いているのは REST エンドポイントです。 URL のホスト名に s3-website が入っているかを見てください。HTTPS で配信したいときは、公式ドキュメントが案内しているとおり、CloudFront などを S3 の前に置きます。

403・404 の原因と直し方の早見表

403 Forbidden が返るとき

最後の2行は、AWS のナレッジセンターに載っている原因です。「ポリシーは合っているのに特定の URL だけ 403」というときは、ファイルが存在しない可能性を先に確かめると近道です。

404 Not Found が返るとき

そのほかの応答

公式ドキュメントに載っている、ウェブサイトエンドポイントの応答コードです。

エラードキュメントが返されるのは 4XX 系のエラーのときだけです。ブラウザによっては、独自のエラー画面が優先されることがあります。

リダイレクトとエラードキュメントの JSON 例

条件つきのリダイレクト（RoutingRules）

RoutingRules を使うと、キーの先頭やエラーコードを条件にしてリダイレクトできます。ルールは1つの設定に 50 個まで書けます。

website-rules.json:

{
  "IndexDocument": { "Suffix": "index.html" },
  "ErrorDocument": { "Key": "error.html" },
  "RoutingRules": [
    {
      "Condition": { "KeyPrefixEquals": "docs/" },
      "Redirect": { "ReplaceKeyPrefixWith": "blog/", "HttpRedirectCode": "301" }
    },
    {
      "Condition": { "HttpErrorCodeReturnedEquals": "404", "KeyPrefixEquals": "images/" },
      "Redirect": { "ReplaceKeyWith": "error.html" }
    }
  ]
}

1つ目は docs/ で始まる URL を blog/ に付け替えるルール、2つ目は images/ 以下で 404 になったときに error.html へ送るルールです。

aws s3api put-bucket-website --bucket example-site-bucket \
  --website-configuration file://website-rules.json

aws s3api get-bucket-website --bucket example-site-bucket

{
    "IndexDocument": {
        "Suffix": "index.html"
    },
    "ErrorDocument": {
        "Key": "error.html"
    },
    "RoutingRules": [
        {
            "Condition": {
                "KeyPrefixEquals": "docs/"
            },
            "Redirect": {
                "HttpRedirectCode": "301",
                "ReplaceKeyPrefixWith": "blog/"
            }
        },
        {
            "Condition": {
                "HttpErrorCodeReturnedEquals": "404",
                "KeyPrefixEquals": "images/"
            },
            "Redirect": {
                "ReplaceKeyWith": "error.html"
            }
        }
    ]
}

Condition と Redirect に書ける項目です。

put-bucket-website は設定全体を置き換えます。RoutingRules だけを書いた JSON を送ると、インデックスドキュメントの指定がなくなるので、毎回すべての項目を書きます。

すべてのリクエストを別のホストへ送る（RedirectAllRequestsTo）

バケットをまるごと別のドメインへの転送専用にする設定です。このときは IndexDocument などを書きません。

website-redirect-all.json:

{
  "RedirectAllRequestsTo": { "HostName": "www.example.com", "Protocol": "https" }
}

aws s3api put-bucket-website --bucket example-site-bucket \
  --website-configuration file://website-redirect-all.json

aws s3api get-bucket-website --bucket example-site-bucket

{
    "RedirectAllRequestsTo": {
        "HostName": "www.example.com",
        "Protocol": "https"
    }
}

オブジェクト単位のリダイレクト（--website-redirect）

1つのオブジェクトだけを転送したいときは、アップロード時に --website-redirect を付けます。オブジェクトのメタデータ（x-amz-website-redirect-location）に転送先が記録されます。

aws s3 cp site/index.html s3://example-site-bucket/old.html --website-redirect /blog/

aws s3api head-object --bucket example-site-bucket --key old.html \
  --query WebsiteRedirectLocation

"/blog/"

転送先には、同じバケット内のキー（/ で始める）か、外部の URL を書けます。この転送が働くのはウェブサイトエンドポイントだけです。

公開をやめるとき

ウェブサイト設定とポリシーを削除すれば、公開は止まります。削除後の確認コマンドは、手順1で見た「設定がない」メッセージに戻ります。

aws s3api delete-bucket-website --bucket example-site-bucket
aws s3api get-bucket-website --bucket example-site-bucket

An error occurred (NoSuchWebsiteConfiguration) when calling the GetBucketWebsite operation: The specified bucket does not have a website configuration

aws s3api delete-bucket-policy --bucket example-site-bucket
aws s3api get-bucket-policy --bucket example-site-bucket

An error occurred (NoSuchBucketPolicy) when calling the GetBucketPolicy operation: The bucket policy does not exist

バケットごと片付けるときは aws s3 rb --force で、中のオブジェクトと一緒に削除できます。

aws s3 rb s3://example-site-bucket --force

delete: s3://example-site-bucket/assets/style.css
delete: s3://example-site-bucket/error.html
delete: s3://example-site-bucket/blog/index.html
delete: s3://example-site-bucket/index.html
delete: s3://example-site-bucket/old.html
remove_bucket: example-site-bucket

よくある質問

Q. ブロックパブリックアクセスは4つとも false にする必要がありますか？

A. バケットポリシーで公開する場合は、BlockPublicPolicy と RestrictPublicBuckets の2つを false にすれば足ります。ACL に関する2つは true のままにしておけます。

Q. HTTPS で公開できますか？

A. ウェブサイトエンドポイントは HTTP のみです。HTTPS で配信するときは、CloudFront を S3 の前に置く構成が公式ドキュメントで案内されています。その構成ではブロックパブリックアクセスを緩めずに済みます。

Q. エラードキュメントを設定したのに、存在しない URL で 403 が出ます。

A. 公開側に s3:ListBucket がないと、存在しないオブジェクトへの応答が 403 になります。エラードキュメントは 4XX 系のエラーで返されるので、error.html がバケットに置かれていて、読み取りの対象になっているかを aws s3 ls と get-bucket-policy で確かめます。

Q. aws s3 website と put-bucket-website はどう使い分けますか？

A. インデックスドキュメントとエラードキュメントだけなら aws s3 website が手軽です。RoutingRules や RedirectAllRequestsTo を使うときは、JSON を渡す put-bucket-website にします。

まとめ

• 設定は ブロックパブリックアクセス → バケットポリシー → ウェブサイト設定 → sync の順に進める
• 確認は get-public-access-block・get-bucket-policy・get-bucket-website の3つ。設定がないときは NoSuchBucketPolicy、NoSuchWebsiteConfiguration で知らせてくれる
• 403 は公開の許可（ブロックパブリックアクセス、ポリシーの Resource の /*）を見る
• 404 はウェブサイト設定とファイルの場所（インデックスドキュメント、キーの階層）を見る
• URL は s3-website を含むウェブサイトエンドポイントを使う。東京はハイフン区切り、大阪はドット区切り
• リダイレクトは RoutingRules・RedirectAllRequestsTo・--website-redirect の3通り
• ウェブサイトエンドポイントは HTTP のみ。HTTPS には CloudFront を組み合わせる

参考・出典

• Website endpoints（Amazon S3 ユーザーガイド）
• Amazon S3 endpoints and quotas（AWS 全般のリファレンス）
• Setting permissions for website access
• Blocking public access to your Amazon S3 storage
• Configuring an index document
• Configuring a custom error document
• Configuring a webpage redirect
• AWS ナレッジセンター：403 Access Denied の原因

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。