はじめに
前回の「AWS ALB + S3 + Cognito マネージドログインで実現する SPA での公開構成！」の続きです！
今回は、前回の「Cognito + ALB + S3」と、王道の「CloudFront + S3」の比較をAIに聞いてみました。
※実際に構築して比較している訳ではありませんので、ご注意ください。
構成の違い（ざっくり）
ALB 版（前回の構成）
Browser
↓
ALB（HTTPS + Cognito 認証）
↓
S3（非公開）
CloudFront 版（王道）
Browser
↓
CloudFront（キャッシュ）
↓
S3（非公開 / OAC）
機能比較表（重要ポイントだけ厳選）
| 観点 | ALB + S3 | CloudFront + S3 |
|---|---|---|
| 配信速度 | △（リージョン依存） | ◎（エッジ配信） |
| キャッシュ | ✕（ほぼ不可） | ◎（強力） |
| SPA 対応 | ◯（index.html 変換） | ◯（エラーページ制御） |
| HTTPS | ◯（ACM） | ◯（ACM） |
| 独自ドメイン | ◯ | ◯ |
| 認証連携 | ◎（Cognito ネイティブ） | △（Lambda@Edge 等） |
| WAF 連携 | ◯ | ◎ |
| 構成の単純さ | ◎ | △ |
| コスト（小規模） | ◯ | △ |
| グローバル配信 | ✕ | ◎ |
認証まわりの違い（ここが最大の分岐点）
ALB 版の強み
- Cognito マネージドログインをそのまま使える
- ALB の「認証アクション」だけで完結
- Lambda 不要、コードゼロ
未ログイン
↓
ALB が Cognito にリダイレクト
↓
ログイン成功 → 自動で SPA 表示
「SPA にログイン必須を付けたい」なら ALB は最短ルート
CloudFront 版の認証の現実
CloudFront 単体では、Cognito を直接は使えない
そのため、下記が代替例。設計・実装・運用コストが上がる
- Lambda@Edge + Cognito
- CloudFront Functions + JWT 検証
- API Gateway + 認証プロキシ
SPA ルーティング対応の違い
ALB 版
- / → /index.html に書き換え
- それ以外は S3 にそのまま転送
Good: シンプル
Bad: /users/123 のような SPA ルーティングは工夫が必要
CloudFront 版
- 404 / 403 を /index.html にリダイレクト
- SPA との相性が非常に良い
Vue / React / Angular では ほぼ標準構成
パフォーマンス・コスト感
ALB 版が向いているケース
- 日本国内ユーザーのみ
- アクセス数は少〜中
- 社内ツール / 管理画面 / PoC
- 認証必須
ALB + 転送量のみで安い
CloudFront 版が向いているケース
- 不特定多数・海外ユーザー
- アクセスが多い
- 表示速度が重要
- 静的配信がメイン
初期はやや高いが、スケールするとむしろ安定
結論：どう使い分ける？
ALB + S3 を選ぶべき人
- まずは動くものを早く出したい
- Cognito のマネージドログインを使いたい
- SPA にログイン必須
- 構成はシンプルが正義
CloudFront + S3 を選ぶべき人
- グローバル配信したい
- とにかく速さが最優先
- 認証は SPA 側 or API 側で制御
- 将来の拡張を重視
おわりに
AIに教えてもらいながらですが、私が携わるシステムはログインを行うシステムが多数です。
そのため、「Cognito + ALB + S3」は、とてもメリットがあるように思えました。
ただ、やはり”速さ”などを比較すると「CloudFront + S3」が良いみたいですね。
規模や要件などによって変わると思うので、非機能要件の１つの引き出しとして、覚えておくようにします！
参考（感謝）
- AIに聞きながら