なぜEC2を直接公開しないのか
EC2にWebサーバーを立てて、セキュリティグループで80/443を開ければ、ひとまず公開はできます。ですが、グローバル向けのサービスになるほど「公開のしかた」がボトルネックになります。SAA-C03の学習でも、ここを“機能の暗記”ではなく“設計の理由”として押さえておくと、問題文の条件から自然に選べるようになります。
まず、EC2直公開がつらくなる代表例は次の3つです。
- 世界中からのアクセスで遅くなる
ユーザーが遠いと往復遅延が増えます。アプリが重くなくても体感は落ちます。 - 攻撃トラフィックの受け皿が小さい
レイヤ3/4の大量トラフィックや、レイヤ7のHTTPフラッドが来ると、EC2やALBが先に疲弊します。 - 入口がバラけて運用が難しくなる
TLS設定、ヘッダー付与、アクセス制御、ログ、制限、緩和策が各所に散ると、変更が怖くなります。
ここで登場するのが CloudFrontを入口に集約し、WAFとShieldを“入口側”で効かせる考え方です。CloudFrontはCDNとしてだけでなく、エッジの分散基盤として「近い場所から配信」「キャッシュでオリジン負荷を下げる」「入口を一本化する」をまとめて実現します。さらに、CloudFrontはAWS WAFを関連付けてリクエストを事前に弾けます。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
CloudFrontを前段に置く基本アーキテクチャ
ここでは、SAA-C03でよく出てくる“定番の置き方”を、実務でもそのまま使える形で整理します。
代表的な構成はこうです。
- ユーザー → CloudFront → ALB → EC2
いちばん汎用的。ALBでパス分岐やターゲット管理ができ、EC2の増減にも強いです。 - ユーザー → CloudFront → EC2
小規模や単一ホスト構成。あとでALBに差し替えやすいように、最初からCloudFrontを入口にしておくのがコツです。 - ユーザー → CloudFront → オリジンをプライベート化
最近は、オリジンをVPC内のリソースとして扱い、外部から直接叩かれないように寄せる選択肢もあります。
重要ポイントは「オリジン直叩きを減らす」
CloudFrontを置いても、オリジンがインターネットから直接叩けるままだと、攻撃者はCloudFrontを迂回できます。つまり「入口はCloudFrontに集約したいのに、裏口が開いている」状態です。
AWS公式ドキュメントでは、ALBをオリジンにする場合の対策として、次の組み合わせが案内されています。
- CloudFrontからALBへのリクエストに カスタムヘッダー を付ける
- ALB側は、そのヘッダーを満たすものだけを転送し、それ以外は403で返す
- 可能ならCloudFront→ALB間もHTTPSにして、ヘッダー漏えいリスクを下げる
さらにネットワーク層でも絞るなら、CloudFrontのマネージドプレフィックスリストをセキュリティグループに使って、CloudFrontのオリジン向けIP帯だけを許可する方法があります。CloudFrontのオリジン向けプレフィックスリストは名前も明示されています。
この「ヘッダーでのアプリ層ガード」と「プレフィックスリストでのネットワーク層ガード」を合わせると、裏口をかなり塞ぎやすくなります。
AWS WAFでアプリ層の攻撃を止める考え方
AWS WAFは、HTTP(S)リクエストを見て“通す・止める”を決める仕組みです。重要なのは、WAFを「とりあえず付ける防具」ではなく、アプリの入口に置くルールエンジンとして設計することです。
CloudFrontと組み合わせると、リクエストがオリジンへ届く前にエッジ側で弾けます。これはオリジン保護の観点で効きます。
WAFの設計で迷いがちなポイント
どこに関連付けるか
SAA-C03では「CloudFrontに関連付けるのか、ALBなどリージョナルに関連付けるのか」で混乱しやすいです。CloudFrontを入口にするなら、まず CloudFrontにWeb ACLを関連付けるのが基本です。CloudFrontは関連付けの手順や、CloudFrontの場合の扱いも明確に区別されています。
何を守りたいかを先に決める
WAFのルールは「SQLiを止めたい」「不要な国からのアクセスを抑えたい」「ログイン試行を抑制したい」など、目的とセットで強くなります。たとえばECサイトなら、次のような“狙われ方”を想定すると設計が進みます。
- ログイン画面に対する総当たり
- 検索窓やパラメータに対するインジェクション系
- 注文APIに対する高頻度リクエスト
- ボットによる在庫監視や価格スクレイピング
レート制限と段階導入
WAFではレートベースの制御などで、短時間の大量リクエストを抑えられます。とはいえ、いきなり厳しくすると正規ユーザーまで巻き込みます。AWS公式のベストプラクティスでも、通常時のトラフィックを前提にした調整や、段階的な導入の考え方が示されています。
SAA-C03目線のコツ
試験対策としては「WAF＝L7の入口制御」「CloudFrontに付けるとオリジンに届く前に弾ける」という因果を押さえるのが近道です。問題文で「世界中から」「急なアクセス増」「EC2の負荷を下げたい」「攻撃対策」などが混ざっているとき、CloudFront＋WAFが自然に浮かびます。
AWS ShieldでDDoSに備える基本とAdvancedの位置づけ
ShieldはDDoS対策のサービスで、StandardとAdvancedがあります。ここも暗記で分けるより、まず「どの層の攻撃に何が効くか」で整理すると混乱しません。
AWS公式では、Shieldがレイヤ3/4だけでなくレイヤ7も含むDDoSに対応すること、Standardが自動で提供されること、より高い保護としてAdvancedがあることが説明されています。
Shield Standardは前提として“付いている”
Standardは追加料金なしで自動的に提供され、特にCloudFrontやRoute 53、Global Acceleratorでメリットが大きいとされています。つまり、CloudFrontを入口にするだけで「DDoS緩和の土台」に乗りやすくなります。
Shield Advancedは何が違うのか
Advancedは、より高いレベルの保護を必要とするケースの選択肢です。保護対象リソースの種類や、どの層まで保護が及ぶかが整理されています。
設計の感覚としては、こんな線引きが実務ではよくあります。
- Standardでまず土台を作る
CloudFrontを前段に置く。裏口を塞ぐ。キャッシュ戦略でオリジン負荷を落とす。 - Advancedを検討するのは“事業影響”が大きいとき
たとえば売上直結のECで、攻撃時の運用体制や復旧コスト、機会損失まで含めて考える段階。
また、AWS公式ではShield Advancedを他サービスと組み合わせるユースケースも整理されています。CloudFrontやALBとセットで守る考え方は、試験でも実務でも筋が通ります。
組み合わせ設計のチェックリストとよくある落とし穴
最後に「CloudFront＋WAF＋Shield」でEC2を守るときの、設計チェックポイントをまとめます。SAA-C03の設問でも、ここが抜けると選択肢で迷いやすいところです。
入口をCloudFrontに集約できているか
- 可能なら CloudFront→ALB→EC2 の一本化
- どうしても直アクセスが必要なAPIは、用途ごとに入口を分ける判断もあり得ます（全部を無理に一つにしない）
オリジン直叩き対策ができているか
- カスタムヘッダー＋ALBのルールで403返し
- CloudFrontマネージドプレフィックスリストでネットワーク層も絞る
- さらに踏み込むなら、VPC内オリジンとして“直接届かない”構成も検討
WAFの運用設計があるか
- 最初はログ中心、段階的にブロックへ
- 何を守るか（ログイン、注文API、検索）を先に決める
- 通常時トラフィックの把握と調整の前提を作る
Shieldは“CloudFrontを前に置くこと”がまず効く
- Standardが前提として効く場所を理解しておく
- Advancedは事業要件と運用体制まで含めて検討
よくある落とし穴
- CloudFrontを置いたのに、ALBやEC2がインターネットから誰でも叩けるまま
- WAFを強くしすぎて、正規ユーザーまで落とす
- キャッシュ設計が弱く、CloudFrontを置いたのにオリジン負荷が下がらない
- 証明書やHTTPS区間の整理が曖昧で、通信の前提が崩れる
まとめ
EC2をグローバルに公開するときは、サーバーそのものを強化する前に「入口をどう設計するか」で難易度が大きく変わります。CloudFrontを前段に置くと、世界中に近い場所から配信でき、キャッシュでオリジン負荷を下げられます。その上でAWS WAFを関連付ければ、悪意あるHTTPリクエストをオリジンに届く前に止めやすくなります。
DDoS対策はShieldが土台です。Shield Standardは自動的に提供され、CloudFrontを入口にするだけでもメリットが得られます。より強い保護や体制が必要な場合にShield Advancedを検討する、という順番で考えると整理しやすいです。
そして忘れがちなのが、オリジン直叩き対策です。CloudFrontからのカスタムヘッダーを使った制御や、CloudFrontマネージドプレフィックスリストでのセキュリティグループ制限など、入口を一本化するための“裏口対策”まで含めて完成形になります。
SAA-C03の学習では、WAFとShieldを別々の暗記事項にせず、CloudFrontを入口に置いたときに「どの層のリスクを、どこで落とすか」という設計ストーリーとしてつなげておくのが効果的です。もし体系的に復習したいなら、SAA-C03対策のUdemy講座で、CloudFrontとWAFとShieldを“構成として”扱っている教材を一つ決めて、図を描きながら追いかけるのがおすすめです。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
