【はじめに】
今回はS3での静的ウェブホスティングを試したいと思います。
あるプロジェクトの一環で、オンプレミス環境のレンタルサーバで運用している自社ホームページを、AWS上に移行して実現したいとのことで、私自身がS3の静的ウェブホスティングをやったことがなかったので自宅で予習という感じです。
【私について】
2026年1月からITエンジニア完全未経験でSESに転職しました。
前職は自動車業界に10年程度在籍していました。
保有資格は下記3つ
- AWS CLF
- AWS SAA
- Linuc レベル1
前職在籍中に時間を作って独学で学習し、1年ほどかけて取得しました。
いずれも試験問題を解くだけの知識としては保有しておりますが、実際にAWSマネジメントコンソールやターミナル上での操作をほとんどやったことがない所謂エアプ状態です。
【流れの確認】
- バケット作成
- オブジェクト（今回はHTMLファイル）アップロード
- 静的ウェブホスティング設定有効化
- バケットポリシー作成
【いざ実践】
まずはS3のマネジメントコンソール上でバケット作成へ
バケットタイプ：汎用
バケット名：任意の名前
Amazon S3 の 3 種類のバケットタイプを比較してみた（DevelopersIO）
上記リンクは非常にわかりやすくユースケースが書かれています。
上から下まで読むことをおすすめします。
～Amazon S3の仕組み～
■バケット
汎用バケット は、ほとんどのユースケースやアクセスパターンに推奨される、オリジナルの S3 バケットタイプです。汎用バケットは、Amazon S3 に保存されているオブジェクトのコンテナであり、バケット内およびすべてのストレージクラス (S3 Express One Zone を除く) に任意の数のオブジェクトを保存できるため、複数のアベイラビリティーゾーンにオブジェクトを冗長的に保存できます。
ディレクトリバケット は、低レイテンシーのユースケースとデータレジデンシーのユースケースに推奨されます。デフォルトでは、最大 100 個のディレクトリバケットを AWS アカウントに作成できます。ディレクトリバケット内に保存できるオブジェクトの数に制限はありません。ディレクトリバケットは、汎用バケットのフラットなストレージ構造の代わりに、オブジェクトを階層ディレクトリ (プレフィックス) に整理します。このバケットタイプにはプレフィックス制限がなく、個々のディレクトリを水平にスケールできます。
私も失敗しましたが、バケット名は世界中のバケット名のどれとも被っていけないようです。
オブジェクト所有者：ACL無効
AWSドキュメントを確認しましたが、関連引用部分が多かったので私の要約で…
- ACLとは「そのオブジェクトが誰が読み書きできるか」を個別に設定する仕組み
- AWS的には現在は基本的に無効化することを推奨している
- したがって、バケットポリシーでのアクセス管理が主流になっている
無効にするとバケット所有者が必ずオブジェクト所有者になって、アクセス管理は全部バケットポリシーでOKになるので管理がシンプルになるようですね。
また、ほとんどのユースケースではACLは不要とも記載ありました。
全容が気になる方は下記リンク参照
アクセスコントロールリスト (ACL) の概要（AWSドキュメント）
オブジェクトの所有権の制御とバケットの ACL の無効化（AWSドキュメント）
デフォルトでチェックされている項目を外し、「現在の設定により、このバケットとバケット内のオブジェクトが公開される可能性があることを承認します。」にチェックします。
自社ホームページの用途としては、デフォルトの設定は外さなきゃなんだろうな～という感じがしますが、念のためAWSドキュメントを参照
ウェブサイトアクセスのアクセス許可の設定（AWSドキュメント）
バケットを静的ウェブサイトとして設定する場合、このウェブサイトを公開するときは、パブリック読み取りアクセスを許可できます。バケットをパブリックに読み取り可能にするには、バケットのパブリックアクセスブロック設定を無効にし、パブリック読み取りアクセスを許可するバケットポリシーを記述する必要があります。
今回はテストなので以下の設定はデフォルトでいきます。
右下のバケットを作成へ
正直、私みたいにIT用語に慣れていないとこれらの言葉程度(?)で身構えてしまうので念のためにAWSドキュメントを確認しましょう。
S3 バージョニングを使用すると、オブジェクトの複数のバージョンを 1 つのバケットに保持し、誤って削除または上書きされたオブジェクトを復元できます。例えば、S3 バージョニングをバケットに適用すると、次の変更が行われます。
オブジェクトを削除した場合、Amazon S3 では、オブジェクトを完全に削除する代わりに削除マーカーを挿入し、それが最新のオブジェクトバージョンになります。これにより、以前のバージョンを復元できます。詳細については、「バージョニングが有効なバケットからのオブジェクトバージョンの削除」を参照してください。
オブジェクトを上書きすると、Amazon S3 のバケットに新しいオブジェクトバージョンが追加されます。以前のバージョンはバケットに残りますが、最新のバージョンではなくなります。以前のバージョンは復元することができます。
Amazon S3 バケットにはデフォルトで暗号化が有効化されており、新しいオブジェクトは Amazon S3 マネージドキー (SSE-S3) を使用してサーバー側の暗号化により自動的に暗号化されます。この暗号化は Amazon S3 バケット内のすべての新しいオブジェクトに適用され、費用はかかりません。
暗号化無効のバケットを有効化したところで既存のオブジェクトは暗号化されないとかそんなのが試験にも出たような気がします。
バケットが作成されたら、次にオブジェクト（今回はHTMLファイル）をアップロードする手順です。
HTMLの知識がなかったので今回はAIにお願いして作ってもらいました。
続いて、静的ウェブホスティングの設定です。
静的ウェブホスティング：有効にする
ホスティングタイプ：静的ウェブサイトをホストする
インデックスドキュメント：HTMLファイル名
画像には映っていませんが、ページ下部の変更の保存をクリック！
インデックスドキュメントはサイトのトップページみたいなもののようです。
また、画像には映っていませんがエラードキュメントはエラー時に飛ぶページのようです。
ウェブサイトホスティングを有効にする場合は、インデックスドキュメントの設定とアップロードも必要です。インデックスドキュメントは、リクエストがウェブサイトのルートまたはサブフォルダに対して行われた場合に Amazon S3 によって返されるウェブページです。
バケットを静的ウェブサイトとして設定した後、エラーが発生すると、Amazon S3 から HTML エラードキュメントが返されます。オプションで、エラーが発生したときに Amazon S3 からそのドキュメントが返されるように、カスタムエラードキュメントを含むバケットを設定できます。
ちなみにこの状態でアクセスを試みたら、エラーでした。
バケットポリシーが足りないからですね。
続いて、バケットポリシーを設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::★/*" #★はS3バケットのARN
}
]
}
ここまで完了したら、アクセスしてみると…
無事成功です。
【おわりに】
とりあえず、予習完了です。
実務ではどんな感じになるかわかりませんが、引き続きがんばります。