はじめに
今回開発したアプリの一部機能ではS3のオリジンを参照する必要性があったためCloudFrontのディストリビューションを構築しました！
なので今回はCloudFrontとはそもそも何かと実装することでのセキュリティの向上について解説します！
さらに今回は、S3だけでなくECS（Fargate）上のサーバーへのアクセスも、すべて最初にCloudFrontを通るように設計しました。この「入り口を一本化」するメリットについても触れていきます。
1. CloudFrontとはそもそも何か？
一言でいうと、「世界中に配置されたサーバー（エッジロケーション）を利用して、コンテンツを高速に配信するサービス（CDN）」です。
通常、ユーザーはS3やECS（ALB）に直接アクセスしますが、CloudFrontを間に挟むことで、ユーザーに最も近い場所にあるサーバーがリクエストを肩代わりしてくれます。
これにより、「配信の高速化」と「強固なセキュリティ」を同時に実現できます。
2. 実装することでどうセキュリティが向上するのか？
S3とECS、それぞれのオリジンをCloudFront経由にすることで、以下の守りが手に入ります。
① S3オリジンの保護（OAC）
Origin Access Control (OAC) を使い、S3バケットを「非公開」のまま、CloudFrontからのリクエストだけを許可します。これにより、S3への直接アクセスを完全に遮断できます。
② ECS（ALB）オリジンの隠蔽（マネージドプレフィックスリスト）
ECSの前段にあるALBのセキュリティグループを「0.0.0.0/0（全解放）」ではなく、「CloudFrontのIP帯（マネージドプレフィックスリスト）のみ許可」に絞り込みます。
これで、悪意あるユーザーがALBのDNS名を直接叩いても、接続を拒否できるようになります。
③ WAFによる「入り口」での一括検疫
S3への画像リクエストも、ECSへのAPIリクエストも、すべてCloudFrontにアタッチしたAWS WAFを通るようになります。
「不正なリクエストはインフラの奥深くに届く前に、エッジで捨てる」という多層防御が完成します。
3. 【実践】S3とECSを共存させる構築のポイント
今回私が構築した際、1つのディストリビューションで複数のオリジンを捌くために以下の設定を行いました。
マルチオリジンの設定
- Origins（オリジン）: S3バケットと、ECS用のALBを両方登録します。
-
Behaviors（ビヘイビア）:
-
/static/*はS3へ -
/api/*はECS（ALB）へ
というように、パスパターンによって振り分け先を制御しました。
-
セキュリティグループの連動
ECS側のセキュリティグループ設定で、ソースにCloudFrontのプレフィックスリストを指定。
4. 構築中に感じたリアルなポイント
-
SSL証明書の一本化:
CloudFrontに証明書を置くだけで、背後のS3やECSの通信をHTTPS化できるため、証明書管理が非常にスッキリしました。
まとめ
実際にS3とECSの両方をCloudFrontの背後に置いてみて、「インフラの入り口が一つになる」ことの管理のしやすさを強く実感しました。
前回のセキュリティグループの記事の内容をさらに発展させ、CloudFrontを活用することで、安全なAWS構成を作ることができました。
以下前回記事のリンク
https://qiita.com/so_yanagi/items/9bbd5865d8f17a11db8f
アプリ開発でS3やECSを使っている方は、ぜひ「入り口をCloudFrontにする」設計を検討してみてください！