アクセス制限付き静的ウェブサイトを楽にホスティングしたい – GCPとAWS S3とGitHubを調査

こんにちは。てぃろです。

最近、アクセス制限を入れた静的サイトを作りたいという話があって少し調べていました。

今回は静的サイトはDocusaurusを使ったのですが、それ自体はなんでもいいです。重要なのは静的サイトをできるだけ簡単かつ安くアクセス制限も入れてやりたいというところです。

そこでいろいろ考えたり調べたり作ったりしたので、ご紹介です。

アクセス制限付きの静的サイトを作りたい

まずは要件です。以下の通りで考えていました。

  • 設計書をレビュー付きで作れるようにしたい
  • 閲覧者は非エンジニアも含むので、ブラウザで見れるようにしたい
  • 関係者のみがアクセスできるようにしたい
  • コスト(運用、支払いなど)を最小化したい
  • クラウドを使う場合にはGCPを使いたい

これをまとめると、GitHubでドキュメントを管理して静的サイトとしてデプロイする、とすれば良さそうに思いました。残りはどこにデプロイするか?です。それには次の選択肢がありました。

  • GitHub Pages
  • AWS S3
  • GCP Cloud Storage
  • GCP Firebase Hosting
  • GCP Cloud Run

一つ一つの検討内容を書いてみます。

GitHub Pages

これはGitHubのリポジトリにあるソースをそのままホストできるという非常に便利なものです。静的サイトのHTMLページをリポジトリに含めてしまって、それを公開するように設定すればOKで、非常に運用が簡単になります。

運用の簡単さから自分の中では一番の選択肢でしたが、アクセス制限という点で一番コストがかかることがわかりました。

GitHub Pagesのアクセス制限はこちらのリンクにあるように「可視性」として表現されています。この可視性を関係者に限定しようとすると機能的にはできますが、以下のようにEnterpriseプランに入らないとできないと注釈がありました。

注: GitHub Pages サイトをプライベートで公開するには、組織で GitHub Enterprise Cloud を使用する必要があります。 GitHub Enterprise Cloud を無料で試す方法の詳細については、「GitHub Enterprise Cloud の試用版を設定する」を参照してください。

https://docs.github.com/ja/enterprise-cloud@latest/pages/getting-started-with-github-pages/changing-the-visibility-of-your-github-pages-site

そんなお金をいまGitHubでかけても無駄なので、この支払うコストという観点で選択肢から外れました。

AWS S3

S3はHTMLファイルを配置してPublicに公開する設定をするとWebサイトとして公開することができます。

ACLなど(ややこしいくらい)多くのアクセス制御方法があるので、十二分にアクセス制限することもできます。運用としてもS3へファイルを配置するだけなのでその点のコストも低いです。

正直なところ、私もAWSが得意で好きなので最有力候補でした。

しかし、今回プロダクトの基盤としてGCPを使用するので、それに合わせて置くのがよかろうということで一旦保留にしました。

GCP Cloud Storage

GCPもS3と同じようにブロックストレージであるCloud Storageで静的コンテンツを公開することは可能です。

私の感覚では、使用感はS3とそんなに変わらないので非常に魅力的な選択肢です。Cloud Load BalancingやIAPと組み合わせることでGoogleアカウントによるアクセス制限もできます。

しかし、唯一にして残念な点が、Cloud Load Balancingを前面に設置していてもCloud Storageの Public IPアドレスに直接アクセスすることができてしまうということです。IPアドレスが漏れるというのはほとんどありませんが、関係者以外には見えてほしくないものが見える経路があるというのはいただけません。

そこさえ直れば採用したいですが、今回は不採用としました。

Firebase Hosting

Firebase HostingもWebサイトをホスティングできるサービスです。これも静的コンテンツを指定しアップロードするだけですし、履歴も残るのでロールバックしたり、一時的にWebサイトのアクセスを遮断するなど、サイト公開においてできることは多いです。

しかし、アクセス制限しようとすると少し工夫が必要になってしまいます。こちらのサイトで紹介されているようにCloud Functionsを使い多少コーディングすると制限は実装できるようです。

しかし、そこでできるアクセス制限についてはIP制限がメインで、Googleアカウントなどでやるにはもう少し工夫が必要そうです。フルマネージドではないあたり、今後の運用コストがかかりそうなのが懸念となり、今回は不採用としました。

GCP Cloud Run

Cloud Runは他の選択肢に比較すると比較的構築するものが多いものですし、これについてはWebサイトのホスティングサービスではないですし、Webサーバを立てている点はVMを立てているのと似ているくらいです。

ただ、今回はこちらを採用することにしました。理由は次のとおりです。

  • 静的サイトをWebサーバとして立てるのはDockerfileをちょっと書くだけでよいので、そこまで構築コストがかからない
  • Cloud Load Balancing + IAPで理想的なアクセス制御ができる(Cloud Storageと違ってCloud Runへの直接アクセスは切ることができる)

デメリットは、アクセス制御のために多少の構築が必要ということなのですが、今回はこの点に目をつむることにしました。これはマネージドサービスで構築する部分なので、一度構築してしまえばおそらくほとんどメンテは不要だからです。

最後に

今回は静的サイトを構築するに当たっての選択肢と検討の軌跡をご紹介しました。

GCPを使うという制約がなければ、AWS S3で良かったと思っています。個人的に何度も構築経験がありますし、Terraformでいつでも構築できるようにもしていましたので。

GCPを使うという点でもほんとはCloud Storage案が理想的なのですが、なぜCloud Storageへの直接アクセスを無効にできないんでしょうね…。あれさえなければ…。

私が一番やりたかったのは構築いらずのGitHub Pagesだったんですけど、プランの壁は高いですねぇ…。