前回記事に引き続き、 jnsato.com  でホストしている自己紹介ページについて。前回はデザイン面について書いた。

デザインを知らないエンジニアによるウェブデザインの工夫 - ユユユユユ (https://jnsato.hateblo.jp/entry/2020/05/31/210000)

 今回はホスティングについて書く。

構成

 はじめに構成図を示しておく。それはこんな形。

 各サービスの詳細については公式ドキュメントに譲るとして、やっていることを書き出してみると、

とまあ、粒度はまちまちだがこんなようにまとめられる。


 メリットも箇条書きすると、こんな感じ。

運用コスト

 コストというのを、保守に必要なリソースと、資金としてのリソースの2点で考えることにする。前者についてはいっさい手間はかからないし、後者についても100円/月程度とどんなレンタルサーバーよりも安価に運用できている。

保守

 「いっさい手間はかからない」と上に書いた時点で、もう話すことはほとんどないのだが、ひとつだけ補足する。

 サーバーを管理する、という意味での保守は存在しない(サーバーレスに栄光あれ!)わけだが、静的ファイルの更新はもちろん別タスクとしておこなっている。ただそれも、継続的デリバリーを定義してしまえば簡単に自動化できるので、手を煩わせられることはない。これについてはまた別の機会に書く。

料金

 以下に示す画像は、 Route 53 と S3 、そして CloudFront の利用料金を抜き出したもの。このウェブページ以外で利用しているリソースの料金も合算しているので多少のブレはあるが、おおむね $1/mo 未満で推移しているのがわかるだろう。

 もっともこれはアクセス数が少ないおかげともいえる。しかし万が一アクセス数が急増したとしても、 CloudFront が安定してリクエストを捌いてくれるはずなので、そう常軌を逸した請求額にはなりえないはず。

おわりに

 サーバーの管理もせずに安定してウェブサイトを運用できている。しかもコストはほとんどかからない。端的に言って最高である。

 ちなみにこの配信パターンは、以下の記事で 都元ダイスケ さんが最高ランクの格付けをしているパターンに結果的に則っている。自分で組み立てた構成にお墨付きをいただけたようで誇らしくも感じる。

[AWSにおける静的コンテンツ配信パターンカタログ(アンチパターン含む) Developers.IO (https://dev.classmethod.jp/articles/static-contents-delivery-patterns/)](https://dev.classmethod.jp/articles/static-contents-delivery-patterns/)

 それから、これらの構成を CloudFormation でテンプレート化して管理するやり方についても、以前書いたのだった。手を動かしながら試したいという方は、こちらも参照してみてほしい。

S3 + CloudFront + Route 53 の構成を CloudFormation にインポートする - ユユユユユ (https://jnsato.hateblo.jp/entry/2020/03/26/110255)