静的ウェブサイトのホスティング

テックポエム

techpoem_nakano_part3

静的ウェブサイトのホスティング

自社ウェブコンテンツを公開したい場合、当然ながらウェブサーバを用意する必要があります。

が、マーケティング等の事由により準備するコンテンツが静的コンテンツである場合は、各クラウドベンダーが提供している静的ウェブサイトホスティングの仕組みを使うと サーバー構築が不要で低コストにコンテンツが公開でき大変便利です。

今回は、当社のランディングページ公開にAmazon S3を利用する機会がありましたのでご紹介したいと思います。

静的ウェブサイトホスティングのメリット・デメリット

を軽くまとめてみますと、

  • pros
    • サーバ構築不要
    • 高速
    • 仮想マシンを構築するよりは割と安価
    • 高負荷に対するスケール等の考慮も不要
  • cons
    • サーバ側でやっていた処理(メールフォームの処理など)をフロント側で吸収する必要がある

上記のようなポイントが挙げられます。

サーバ側の処理は、サーバレス API などで実装してしまってフロントエンドから叩けば済む話なので、もはや大した障壁では無いように思います。

主要ベンダーの静的ウェブサイトホスティング

静的ウェブサイトホスティングを構築できる主要サービスは以下のようなものがあります。

今回は Amazon S3 を利用して構築しました。

step-by-step

以下の手順で作業を進めていきます。

  1. Amazon S3 Bucket の作成と設定
  2. ACM (AWS Certificate Manager) への証明書の設置と Amazon CloudFront の設定
  3. DNS CNAME レコードの設定
  4. 特定の Amazon S3 Bucket へアクセス可能なアカウントの開設

Amazon S3 Bucket の作成と設定

Amazon S3 コンソールで S3 Bucket を作成していきます。とりあえずデフォルト設定のまま作成してしまってかまいません。

s3-01-01.png

Bucket のプロパティ設定画面で Static website hostingを有効にします。インデックスドキュメントとエラードキュメントは必須項目です。

s3-01-02.png

カスタムバケットポリシーを設定するために、アクセス制限のパブリックアクセス設定で 新規のパブリックバケットポリシーをブロックするバケットにパブリックポリシーがある場合、パブリックアクセスとクロスアカウントアクセスをブロックするを OFF にします。

s3-01-03.png

パブリックアクセスを許容するためにバケットポリシーエディタで下記の JSON を設定します。Resource の ARN は作成した Bucket Name に合致するようにしましょう。

s3-01-04.png

この時点で、Bucket にコンテンツをアップロードすることによりStatic website hostingプロパティに表示されているエンドポイントの URL でアクセスが可能な静的ウェブサイトホスティングを確認することができます。

(本例では http://uni.foobar.s3-website-ap-northeast-1.amazonaws.com/)

上記ページを例えば http://foobar.unifinity.co.jp でアクセス可能としたい場合は、unifinity.co.jp の DNS 設定にて、foobar.unifinity.co.jpの CNAME を uni.foobar.s3-website-ap-northeast-1.amazonaws.comと設定してあげることにより実現することができます。

ウェブサイトの SSL 化が不要であれば、このステップでコンテンツの公開に関する対応は完了です。

しかしながら、常時 SSL 化 の流れを無視するわけにもいかず、 サーバー証明書を配置するためには次ステップ以降の手順を踏む必要があります。

ACM(AWS Certificate Manager)への証明書の設置と Amazon CloudFront の設定

S3 Bucket へ配置した静的コンテンツやAPI Gatewayで公開する API を HTTPS で運用する場合、

  1. ACMで証明書を設置
  2. Amazon CloudFrontで S3 Bucket を配布する設定を行い、SSL の設定を行う

上記の手順を踏む必要があります。

また、サポートされるリージョンに示されているとおり、 CloudFront で ACM 証明書を利用するためには、us-east-1 region で ACM の設定を行わなくてはならず、注意が必要です。

ACM では無料で証明書を発行することができますが、当社はワイルドカード証明書を既に運用しているため、 運用中のワイルドカード証明書を ACM へインポートする方針としました。

ACM のコンソール(us-east-1 region)で証明書をインポートします。 PEM 形式の証明書、プライベートキー、証明書チェーンを貼り付けます。

s3-02-01.png

確認画面後、インポート完了です。

s3-02-02.png

Amazon CloudFront のコンソールCreate Distributionを押し CloudFront の設定を進めます。

Origin Domain Nameに、設置済みの S3 Bucket や ELB のリストが表示されますので、今回 CloudFront 経由で公開したい S3 Bucket を選択します。

s3-03-01.png

下にスクロールし、Distribution Settings の項目でCustom SSL Certificateを選択し ACM で作成した証明書を選択します。

s3-03-02.png

これで AWS 側の静的コンテンツ配信に関する基本的な設定は完了となります。

CloudFront では他にも CDN 的な設定項目や ACL での制限など多岐にわたる設定項目があります。特記事項があるとするとキャッシュの設定でしょうか。

サイト構築中は頻繁にウェブコンテンツを編集することになるかと思いますが、デフォルトの設定では CloudFront が CDN としてコンテンツをキャッシュするため、構築中はキャッシュ時間を短くするか無効化するのをお勧めします。Behavior の編集画面から、Minimum TTLMaximum TTLDefault TTLを 0 に設定することにより CloudFront 側でのコンテンツキャッシュが無効となります。

DNS CNAME レコードの設定

Amazon CloudFront 経由で公開するコンテンツを自社ドメイン FQDN で公開したい場合、Amazon CloudFront で割り当てられたDomain Nameを CNAME として設定することになります。

作成した Distribution のプロパティを表示し、Domain Name(本例では d40k96yonn1kw.cloudfront.net)を DNS の設定にて foobar.unifinity.co.jpの CNAME に割当てて下さい。

s3-04-01.png

ここまでで、ようやく https://foobar.unifinity.co.jp への HTTPS でのアクセスが可能となります。

特定の Amazon S3 Bucket へアクセス可能なアカウントの開設

Web コンテンツの制作者が AWS コンソールにアクセスする権限を持っていれば AWS コンソールへアクセスしてもらいファイルの上げ下げができるのですが、 往々にしてそんなことはありません。

そもそも Web コンテンツ制作者に AWS コンソールアクセス権限を渡せるシーンは少なそうです。即ち、Web コンテンツ製作者が S3 Bucket へアップロードできるよう 何らかの手法を提供してあげる必要があります。

2018 年 11 月に AWS Transfer for SFTP がリリースされました。 これは over SFTP で S3 Bucket のファイル転送が行えるサービスで、今回のような要件にうってつけです。

・・・と思い検証を行ったのですが、残念ながら今回は利用を断念しました。

機能的には全く問題無かったものの、コストがあまりにも高額すぎました。ファイルの上げ下げのコストは軽微(upload 0.04USD/GB, download 0.05USD/GB)ですが、 SFTP エンドポイントの料金は 0.30USD/h です。

月に換算すると 0.30*24*30=216USD/month となります。 SFTP サーバを停止しても課金は続き、課金対象から外すには SFTP サーバを削除するしかありません。なんでしょうねこの攻めの価格設定は。

コスト面から AWS Transfer for SFTP は見送りましたが、せっかく検証を行ったので記録を残しておきます。

AWS Transfer for SFTP を利用したアカウントの作成

AWS Transfer for SFTP を利用して S3 にファイルをアップロードする手順としては以下の通りになります。

  1. SFTP サーバの作成
  2. SFTP アカウントへ付与する IAM ロールの作成
  3. SFTP アカウントの作成
  4. SFTP クライアントを利用し S3 へ接続

AWS Transfer for SFTP のコンソール で Create Server でサーバーを作成していきます。

s3-05-01.png

サーバを作成すると State が Starting となり、その後 Online になるとサーバが利用可能となります。(数分を要するようです)

s3-05-02.png

対象となる S3 Bucket にアクセスを可能とする IAM のロールを作成していきます。今回はこちらの公式ドキュメントを参考に以下のような IAM ポリシーを作成しロールを作成しました。

作成した IAM ロールを持つ SFTP ユーザーを作成していきます。作成済みのサーバを選択するとサーバの詳細画面が表示されます。

s3-05-03.png

さきほど作成したロールを紐づけ、Home directory には対象となる S3 Bucket を選択します。 SSH のキーペアを作成し公開鍵を設定してください。

s3-05-04.png

これで、SFTP サーバに割り当てられているエンドポイントに対して SFTP クライアントからアクセスが可能となりファイルの管理が可能となります。

S3 に対応したデスクトップクライアントに開放する IAM アカウントの作成

WinSCPCyberDuckなどの FTP クライアントは S3 への直接接続が可能です。

これらのクライアントを利用して S3 にファイルをアップロードする手順としては以下の通りになります。

  1. 対象の S3 へアクセス権限を持つ IAM ユーザーの作成
  2. IAM ユーザー

IAM ユーザーに関しては、社外ユーザーへの公開を想定して、対象となる S3 Bucket のみアクセス可能となるよう権限設定を行います。 ポリシーは上記の SFTP 手順で作成したポリシーを流用できます。

IAM コンソール からユーザーを作成していきます。

WinSCP 等のクライアントでは AWS API を使用するため IAM ユーザーのアクセスキーIDシークレットアクセスキーが必要となります。

s3-05-05.png

IAM ユーザーへポリシーを割り当てます。

s3-05-06.png

シークレットアクセスキーはこの画面で表示し控えておきましょう。

s3-05-07.png

WinSCP では、アクセスキーIDシークレットアクセスキーを指定することによりアクセスが可能となりファイルの管理が可能となります。

s3-05-08.png

まとめ

IAM ユーザーのロール割当の煩雑さなどを鑑みると AWS Transfer for SFTP がベストプラクティスなように思えます。ぜひ価格設定の見直しをお願いしたいですね。

当社の下記の LP はご紹介した方式で Amazon S3 + Amazon CloudFront で作成されています。ぜひご覧いただきお問い合わせください!