S3とは

基本的にAWSのストレージサービスです。

AWSの他サービスとも連携しやすく、クラウドストレージとして以外にも活用できます。

今回は静的サイトをホスティング（一般公開）してみたいと思います。

バケット

バケット名は一意

バケット名は世界的に一意にする必要があります。

平たくいえばバケット名は早い者勝ちなので、取得したいバケット名をすでに誰かが使っていたら新しく指定することはできません。

これは、サイトのURLとして利用することがあるためそれが考慮されています。

ファイルを置く

S3にバケットを作ってファイルを置きます。今回は、バケット直下にひとつtestフォルダを作って構成しています。

これによりhtmlファイルにアクセスすればページが閲覧できるようになります。

f:id:bonoponz:20210806152547p:plain

アクセス拒否エラー？

ところが、アクセスの仕方によって問題なく閲覧できたりアクセス拒否されたりします。

下の画像のとおり、AとBの2通りからアクセスできます。

f:id:bonoponz:20210806151312p:plain

「開く」(A)からリンク先へ飛んだ場合

indexファイルには簡単にh1のみを記述しています。

<body>
    <h1>あああ</h1>
</body>

f:id:bonoponz:20210806151437p:plain

「オブジェクトURL」(B)からリンク先へ飛んだ場合

https://バケット名.s3.リージョン名.amazonaws.com/test/index.html

f:id:bonoponz:20210806151512p:plain

原因

Aの「開く」からアクセスした場合、URLには文字数多めなクエリパラメータが連なっているのが確認できると思います。
そのパラメータに含まれるのがユーザ認証情報です。AWSのコンソールログイン情報ですね。

Bの「オブジェクトURL」からアクセスするとこのクエリパラメータがありません。つまりユーザ認証情報がないのです。

ゆえにアクセス権がないとしてアクセス拒否の画面になります。

解決策

AWSのオブジェクトURLはデフォルトではすべてプライベートで設定されています。

署名付きURLを作成することで、AWSにログインしていなくてもそのURLを知る人は誰でもアクセスできるようになります。

そのため、アクセス拒否を解決するためには事前に署名されたURLを設定することが必要になります。

バケットポリシーを設定でも解決できました。次項で解説します。

バケットポリシーを設定

アクセス拒否を回避するため、バケットポリシーを設定します。

バケット＞アクセス許可＞バケットポリシー＞編集

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"1",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::バケット名/*"]
    }
  ]
}

このままバケットポリシー欄にまるっとコピペします。（バケット名には自身のバケット名にしてください。）

すると先程はアクセス拒否されていたオブジェクトURLにアクセスしても、ページが閲覧できます。

AWSコンソール上でも、公開になっていることがわかります。

f:id:bonoponz:20210806170919p:plain

すばらしい〜！

これにて、ホスティング完了です。あとはindex.htmlを置いている階層にファイルを追加していけばサイトに肉付けでき立派なサイトもなりますね。

参考URL

S3 オブジェクトへのリンクを開くことから発生する 403 エラーのトラブルシューティング

Sharing an object with a presigned URL - Amazon Simple Storage Service

AWS S3で静的サイトを構築 - Qiita

IAM JSON ポリシーの要素のリファレンス - AWS Identity and Access Management

【基本おさらい】Amazon S3バケットに読み取り専用のポリシーをつけたAWS IAMポリシーをサクッと作る方法 | DevelopersIO

小さなことからこつこつと。

【AWS/S3】静的サイト構築