aws上で静的なwebサイトを公開してみる
今回もawsの初心者ハンズオンを行ってみました
aws上で静的なwebサイトを公開しよう
構成図はこちら
概要
s3の静的webホスティング機能を使えば簡単に静的サイトを公開することができます。
cloudfrnot等のCDNを経由させることでキャッシュして配信することもできます。
独自ドメインを取得し、SSL証明書をcdnにインポートすることで独自ドメインのままSSL通信が可能になります。
awsではs3とcloudfrontを使って独自ドメインのままSSL通信を可能にする方法として大きく２パターンあります。
パターン①: S3の静的webホスティング機能を使った方法
パターン②: S3の静的webホスティング機能を使わずに行う方法
ではテキストベースで設定の流れを説明します。
パターン①: S3の静的webホスティング機能を使った方法
-
ドメイン名を取得する
自分はfreenomで無料で取得しました。 -
s3バケットを作成する
- バケット名はドメイン名と同じ名前にする
- パブリックアクセスを許可
- webホスティングを有効化(デフォルトドキュメントはindex.html
- index.htmlをアップロードする
- バケットポリシーを設定(s3バケットに対してオブジェクトの匿名アクセス許可)
※xxxxxxxxxにはバケット名が入ります
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::xxxxxxxxx/*"
]
}
]
}
※この状態になると静的webホスティングのエンドポイントでindex.htmlが閲覧できます。
- route 53で先程のドメインに対してホストゾーンを作成する
-
ドメインの管理をRoute53に委任(freenomのcustom nameserverにNSレコードを設定)
こちらのサイトが参考になります。 -
Aレコードを作成し、エイリアスにS3バケットを指定する
-
※この状態になると取得した独自ドメインでindex.htmlが閲覧できます。
- cloudfrontのディストリビューションを作成
- origin domain nameにs3のwebホスティングURLを指定
※この状態になるとcloudfrontのDNS名でindex.htmlが閲覧できます。
-
acmを作成する
- リージョンはバージニア北部で作成する
- DNSで検証するを選択
- route 53にcnameレコードを追加して検証する
-
SSLの独自ドメインでアクセスできるように設定する
- CloudFrontのbehaviorでhttpをhttpsに強制リダイレクトする設定に変更する
- CloudFrontのcnameにドメイン名を追加し、acmをインポートする
- route 53のAレコードのエイリアスをCloudFrontに変更する
※この状態になるとSSL化された独自ドメインでindex.htmlが閲覧できます。
しかし、この状態だとs3webホスティングURLに直接アクセスができてしまう。
s3のホスティングURLに直接アクセスさせないためにはwebホスティング機能は使えません。その場合パターン②に変更する必要があります。
パターン②:必ずCloudFrontを経由してs3にアクセスさせる方法
-
s3バケットの設定を変更する①
- パブリックアクセスを拒否
- バケットポリシーを削除
- webホスティングを無効化
-
CloudFrontの設定を変更する
- origin domain nameにs3のバケットを指定
- Restrict Bucket Accessをyesに設定
- OAC(Origin Access Control)を設定（そのときバケットポリシーをコピーしておく）
- デフォルトルートオブジェクトにindex.htmlを設定する
-
s3バケットの設定を変更する②
- OACでコピーしたバケットポリシーを設定する(cloudfrontの特定のディストリビューションのみs3へのアクセスを許可するという内容)
以上で設定完了。
まとめ
今回はバケットポリシーとパブリックアクセスブロックの設定でアクセス制御を行ったが、その他にも方法はある(aclやIAMポリシーを使う方法等)。どうやらアクセス制御には優先度があるみたいだがその辺は次回以降調べてみる。
cloudfront経由にs3のアクセス制御をする方法は従来はOAI(Origin Access Identity)だった。
しかしセキュリティの懸念事項があったために新しくOACという方法ができた。
実はCloudFrontのデフォルトルートオブジェクトとS3の静的ウェブサイトホスティングのインデックスドキュメントの動作は違う。
具体的にはs3のフォルダ配下のindex.htmlにアクセスする際に違いが生じる。
それを解決するためにはlambda@edgeをs3とcloudfrontの間にかませる方法があるらしい。
Discussion