JAWS Festa 2025 in 金沢にて、CloudFront を利用した Infrastructure as a Service ( IaaS )を開発・運用する方法について紹介いたしました。当日は Shifter の立ち上げや運用の中で経験したことや、2025年の製品機能や知識に基づいての振り返りを紹介するセッションとしてお話ししました。
Shifter のアーキテクチャ
Shifter は WordPress サイトを静的化してビルド・公開する SaaS として2017年にリリースしました。WordPress サイトの提供方法やビルドプロセスについては、 AWS の様々なサービスを組み合わせておりますが、公開サイトの配信方法はとてもシンプルです。
CloudFront が HTTPS リクエストを受け取り、CloudFront Functions と Lambda@Edge でリクエストを処理し、S3 オリジンからコンテンツを配信します。CloudFront Functions や Lambda@Edge は、WordPress ライクなパスでのルーティング処理や Basic 認証への対応、そしてサブスクリプションの未払いなどが発生した時の利用制限等のカスタマイズを実装しています。
CloudFront の「在庫管理システム」
CloudFront は利用開始まで20分程度かかるため、顧客が迅速にアクセスできるよう事前に Distribution を作成する在庫管理方式を採用しました。ディストリビューション数をカウントするバッチが動作し、必要在庫数の閾値を下回ると自動的に追加作成する仕組みです。
事前に自動で Distribution を作成し、ユーザーの申し込みに連動してサイトを割り当てる仕組みを実装するため、CloudFront Distribution は terraform / CloudFormation などの Infrastructure as Code ( IaC )ツールで管理せずに展開しています。現在であれば AWS CDK の中にある SaaS Builder Toolkit ( SBT ) などが利用できるかもしれませんが、2017 年時点では AWS CDK もSBT が利用する EventBridge などもリリースされていませんでした。
運用で発生した問題と部分的な解決
IaC ツールで構成管理をしていない CloudFront Distribution が増加したことで、構成変更などの保守運用作業への負荷が増加しました。特に Lambda@Edge のランタイムバージョンの変更のような全 Distribution への展開が必要なケースにおいては、AWS SDK を利用したバッチ処理で設定を更新するしかありません。Config を取得して差分を更新し、Tag ベースで対象を特定して更新を実施する。こんなスクリプトを実装し、AWS API のスロットリングを回避するように逐次実行で時間をかけて更新作業を実施しています。
CloudFront Functions による負荷軽減
2021年に登場した CloudFront Functions は状況を改善しました。Lambda@Edge では各 Distribution の更新が必要でしたが、Functions は関数更新で一括反映できます。全サイト適用系と軽量なカスタマイズを Functions に集約することで、運用負荷を大幅に軽減できました。
[ 進行中 ] Cache Policy への設定移行
現在進行しているもう1つの改善が、CloudFront のキャッシュ設定を Cache Policy へ移行する取り組みです。これは2020年ごろに登場した機能で、キャッシュ設定をポリシーとして Distribution と分離した形で管理できるようになります。
Cache Policy を利用して、Shifter で提供する CDN のキャッシュ設定を集約管理できるようになります。これによってオブジェクトの圧縮方法など、 CDN 技術の変化やユースケースの変化への対応速度を高めることを目指します。
2025年に CDN IaaS を作るならどうする？
セッションでは、現在の AWS 機能やベストプラクティスで同様の構成を作るならばどうするかについても紹介しました。今、自分が持つ知識をベースにすれば、おそらく以下の機能を利用すると考えています。
- CloudFront Multi-tenant distribution
- CloudFront Functions
- CloudFront KeyValue Store
- SaaS Builder Toolkit
CloudFront Multi-tenant distribution
2025年5月に一般提供（GA）となった CloudFront Multi-tenant distribution は、IaaS を提供する場合に非常に有効です。1つの Distribution に複数のサイトを配置でき、キャッシュやセキュリティ設定を共有設定として定義しながら、各テナントで WAF、TLS 証明書、地理的制限を個別にカスタマイズできます。
Distribution の設定を1つに集約できるため、設定を変更する必要が生じた場合にも迅速な対応が期待できます。また、キャッシュやセキュリティ設定の異なる Multi-tenant distribution をいくつか用意し、顧客が契約するプランによってテナントの割当先を変更するような、Tiering も実現できます。
CloudFront Functions & CloudFront KeyValue Store ( KVS )
Basic 認証や閲覧制限など、サイトごとに実施するカスタマイズや対応については、この2つを利用することになるでしょう。サイトを管理する API やバッチ処理が KVS API を利用して設定情報を KVS に登録します。あとは CloudFront Functions が KVS にあるテナントごとの設定情報を読み取って振る舞いを変えてくれます。
SaaS Builder Toolkit ( SBT )
Multi-tenant distribution の設定やサイト管理に関するリソースは、AWS の SaaS アーキテクチャの基礎 が定義する「コントロールプレーン」として管理します。コントロールプレーンはテナント管理、認証、運用を担う層であり、CloudFront のテナントや静的な HTML をホストする S3 バケットなどはアプリケーションプレーン層として分割統治します。
この際、コントロールプレーン側のセットアップやリソース管理を効率化できるツールとして、 SaaS Builder Toolkit ( SBT ) を活用します。イベント駆動アーキテクチャでの設計やイベントバス・ルールの設計にユーザー認証など、コントロールプレーン側の設計や実装について、AWS が提供するリファレンスアーキテクチャに従って効率的な実装ができることを期待するでしょう。
まとめ
今回の登壇に向けて、 CloudFront やマルチテナント SaaS についての情報を調べ直しました。やはり2017年当時と比較すると、ナレッジやリソースといった環境の変化は大きく、「あの時これがあれば…」と思った瞬間は片手で数えきれないほどありました。同時に手探りな環境での試行錯誤や、「当時のベストプラクティス」が5年後10年後でもベストであるとは限らないことの難しさも実感しています。
AWS Well-Architected SaaS Lens が警告するように、「ビジネスのニーズ、ドメインの性質、コンプライアンス要件」などすべての要因がアーキテクチャに影響を与えます。万能かつ不変の SaaS アーキテクチャは存在しないと言えるでしょう。
重要なのは技術の進化を追い続け、適切なタイミングでアーキテクチャを見直すことです。
とはいえ、昨今の AWS アップデート情報を一人で追いかけるのは非常に大変です。情報洪水に溺れないために、JAWS-UG のようなコミュニティを活用しましょう。セッション終了後、会場内で AWS のソリューションアーキテクトも交えて既存の Distribution をマルチテナントディストリビューションへ移行する方法などについて議論しました。このような会話、特に AWS のアーキテクトも交えて会話や質問をするということは、コミュニティ以外では年に一度の AWS Summit に参加するくらいしかないのではないでしょうか。
ぜひあなたの試行錯誤や悩み・成功と失敗経験を片手に、お近くのユーザーコミュニティに足を運んでみてください。思いもよらない場所からアドバイスを貰えたり、新しい機会が手に入るかもしれません。
