🎏
[AWS CloudFront] 複数のSPAアプリケーションをマルチオリジンで配信する際の注意点
はじめに
AWSのS3とCloudFrontを使用して複数のシングルページアプリケーション（SPA）を配信する際、効率的な構成とキャッシュの適切な管理が重要です。本記事では、複数SPAの配信における問題点とその解決策、さらにLambda@Edgeを使用した配信方法について解説します。
基本的な構成と問題点
構成概要
- 複数のS3バケット（例：
bucket-1、bucket-2）にSPAをホスティング - 1つのCloudFrontディストリビューションで複数のバケットを配信
- CloudFrontのビヘイビア設定で各バケットへのルーティングを定義
- CloudFront Functionを使用して、拡張子なしのリクエストを
/index.htmlに変更
発生しうる問題
この基本的な構成では、以下のような問題が発生する可能性があります：
- 異なるパス（例：
/bucket-1/pageと/page）へのアクセスが同じindex.htmlを返す - キャッシュの不適切な管理による意図しないコンテンツの配信
問題の原因：キャッシュキーの理解
CloudFrontのキャッシュキーは通常、以下の要素で構成されます：
- リクエストのホスト名
- リクエストのパス
- クエリ文字列（設定による）
- ヘッダー（設定による）
CloudFront Functionで全てのリクエストを/index.htmlに変更すると、異なるオリジンへのリクエストでも同じキャッシュキーが生成され、意図しないコンテンツが返される可能性があります。
解決策：Lambda@Edgeの活用
Lambda@Edge関数の実装例
exports.handler = async (event) => {
const { request } = event.Records[0].cf;
const uri = request.uri;
if (!uri.includes('.')) {
request.uri = '/index.html';
} else if (uri.startsWith('/bucket-1')) {
request.uri = request.uri.replace(/^\/bucket-1/, '');
}
return request;
};
この実装により、拡張子なしのリクエストの適切な処理と、特定のパスの正確なルーティングが可能になります。
まとめ
- CloudFrontで複数のSPAを配信する際は、キャッシュの挙動に注意が必要
- Lambda@Edgeを活用することで、シンプルなケースにおけるルーティングとキャッシュ問題を解決可能
Discussion