AWSで使うCDN／エッジセキュリティ：CloudFront・Cloudflare・Akamai 比較 — 何ができて何ができないか

CDNはもはや「静的配信を速くする箱」ではなく、WAF・DDoS防御・ボット対策・エッジコンピュートを束ねたアプリケーションの最前線になった。AWSのオリジン（S3／ALB／API Gateway／EC2）を守り、速く届けるとき、選択肢は大きく三つ——AWSネイティブのAmazon CloudFront、そして前段に置く第三者としてのCloudflareとAkamai。本稿では機能・制限・料金モデルを、ポジショントーク抜きで「何ができて／何ができないか」の軸で整理する。

01前提：CDNは「配信」から「エッジの防御・実行環境」へ

いまCDNを選ぶことは、CDN単体を選ぶことではない。キャッシュ配信の下に、WAF（Webアプリケーションファイアウォール）、L3/L4のDDoS防御、ボット対策、そしてリクエスト経路上でコードを走らせるエッジコンピュートが積み重なっている。AWSのオリジンを守る文脈では、これらをAWSの中で完結させる（CloudFront）か、AWSの前段に第三者を置く（Cloudflare／Akamai）かという設計判断が最初に来る。本稿は「どれが優れているか」ではなく「あなたの要件でどれが噛み合うか」を判断できるよう、各社の得意・不得意を対比していく。

02リクエスト経路と3社の位置づけ

まず全体像を押さえる。エンドユーザーのリクエストは、必ずエッジ層（CDN＋WAF＋DDoS＋Bot＋エッジコンピュート）を通ってからAWSオリジンへ届く。CloudFrontはこのエッジ層をAWSアカウントの内側に持ち、Cloudflare／AkamaiはDNSやプロキシでAWSの手前に割り込ませる。どちらの構成でも肝は同じで、オリジンへの直アクセスを塞ぎ、必ずエッジを経由させることだ。

03CDN基礎：キャッシュ・オリジン対応・エッジ拠点

純粋な配信面では3社とも成熟しており、ここで大きな優劣はつきにくい。差が出るのは「AWSオリジンとどれだけ密に繋がるか」と「運用主体が誰になるか」だ。CloudFrontはS3のOrigin Access Control（OAC）やVPC origins、ALBへのカスタムヘッダ検証など、AWS側の認可と一体で「オリジン隠蔽」を組める点が最大の強み。Cloudflare／Akamaiはマルチクラウドや自社データセンターも含めた広い配信・大規模イベントに強いが、AWSの認可機構とは疎結合になる。

04WAFとDDoS防御：AWSの一体運用か、専業の厚みか

ここが最も判断が割れる領域だ。CloudFrontはAWS WAF（CloudFront／ALB／API Gateway／AppSyncで利用できるが、Web ACLはCloudFront用のグローバルスコープとALB等の地域リソース用のリージョナルスコープに分かれ、同一のWeb ACLをスコープを跨いで共有することはできない。ルール構成の使い回しは可能）と、AWS Shieldで守る。Shield Standardは全AWS利用者に無償で付き、L3/L4の一般的な攻撃を自動緩和。上位のShield Advancedは有償サブスクリプション（AWS公式の料金ページで月額3,000ドル・12か月コミット＋データ転送の従量課金と明記）で、24時間のShield Response Team（SRT）へのアクセス、DDoS起因の従量課金に対するコスト保護、L7の自動緩和（Shield Advanced付属のAWS WAFマネージドルールグループ）などが加わる。

一方Cloudflareは全プラン（無料含む）で「アンメータード（従量課金なし）」のDDoS防御をうたい、ネットワーク層全体を守るMagic Transit（BGP／Anycastで自社ネットワークやオンプレも保護）を提供する。Akamaiはネットワーク層のスクラビング専用サービスProlexicと、WAF・ボット・API保護を束ねたWAAP「App and API Protector」（挙動ベースのDDoSエンジンを内蔵）を組み合わせる構成が典型だ。

05ボット対策：厚みと運用のトレードオフ

ボット対策は「シグネチャで名乗るボットを弾く」段階と、「名乗らない高度なボットを挙動・フィンガープリントで見抜く」段階で難易度が段違いになる。CloudFront経由ではAWS WAF Bot Controlが使え、Common（自己申告するボット）に加えTargetedレベルで、ブラウザ挑戦・フィンガープリント・機械学習（TGT_ML_系ルール）による高度検知やCAPTCHAが可能。CloudFrontディストリビューションに紐づくWeb ACLでのみ使える動作もある。実用水準には達するが、専業ベンダーが持つ広範な脅威インテリジェンスと運用チューニングの厚みには一歩譲る場面がある——ここは正直に評価すべき点だ。

Cloudflareは巨大なトラフィックから得るシグナルを使ったスコアリング型のBot Management、Akamaiは1,700種を超える既知ボットの分類とアダプティブスコアリングを備えるBot Managerを持つ。高度なクレデンシャルスタッフィングやスクレイピング対策を最優先要件に置くなら、専業側が有利になりやすい。

06エッジコンピュート：4つの実行環境の使い分け

リクエスト経路上でコードを走らせる手段は、AWS側だけで2種類ある。軽量・超低遅延のCloudFront Functions（JavaScript、全エッジ拠点で実行、ヘッダ操作やURL書き換え・キャッシュキー正規化向け）と、より重い処理ができるLambda@Edge（Node.js／Python、リージョナルエッジキャッシュで実行、AWSサービスや外部への接続が可能）だ。前者はネットワークアクセス・リクエストボディ参照・ファイルI/Oができないという明確な制約がある。第三者側ではCloudflare Workers（V8アイソレート、fetchによる外部呼び出しやKV/D1/R2など豊富なストレージ、有料プランでCPU時間を最大5分まで拡張可能）とAkamai EdgeWorkers（JavaScript、階層化されたリソース上限、EdgeKV連携）が対応する。

軽量処理はCloudFront Functionsで足りるが、「外部API呼び出しやリクエストボディの検査が要る」と分かった時点でLambda@Edge、あるいはWorkers/EdgeWorkersに切り替える判断が要る。境界を最初に決めておくと後戻りが少ない。

// CloudFront Functions（JavaScript）：末尾スラッシュ補完など軽量処理向け
function handler(event) {
  var req = event.request;
  if (req.uri.endsWith('/')) req.uri += 'index.html';
  return req;
}
// ネットワークアクセス・リクエストボディ参照・ファイルI/Oは不可。
// 外部呼び出しやAWSサービス連携が要るなら Lambda@Edge を選ぶ。

07DNS・TLS・可観測性・AWS統合の深さ

周辺機能でも設計は変わる。DNSは、CloudFrontならRoute 53、TLS証明書はACMで無償発行・自動更新までAWS内で完結する。CloudflareはもともとAuthoritative DNSが中核事業で、DNS一体運用と広い無料枠が強み。AkamaiもEdge DNSでエンタープライズ向けに提供する。可観測性は、CloudFrontがCloudWatch・アクセスログ・AWS WAFログをS3/OpenSearch等に流し込み、既存のAWS監視基盤に載せられるのが利点。第三者側はそれぞれの管理コンソール・分析（ダッシュボードやログ連携）が中心となり、AWSのメトリクスとは別系統になる。

08料金モデルの考え方

数値は変動するため考え方を押さえる。CloudFrontは基本が従量課金で、データ転送量（GB）＋リクエスト数（1万件単位）＋有効化した機能ごとの積み上げ。常時無料枠（月1TBの転送、1,000万リクエスト、200万回のCloudFront Functions実行）があり、近年はCDN・セキュリティ・DNS・エッジ計算を月額固定に束ねるプランや大口向けの個別契約も選べる。Shield Advancedのように「月額サブスク＋従量」で別立てになる要素がある点は要注意だ。Cloudflareは無料からエンタープライズまでのプラン制（帯域は原則アンメータード）、Akamaiは基本的に営業経由のエンタープライズ契約が中心となる。

09使い分けの指針と、検証で先に潰す落とし穴

率直な指針はこうだ。ワークロードがAWS中心で、IAM・請求・IaC・監視を一元化したいなら、まずCloudFront＋AWS WAF／Shieldで組むのが素直で、運用の一貫性が最大化する。マルチクラウドや、名乗らない高度ボット・超大規模配信・ネットワーク全体のDDoS防御が主要件なら、Cloudflare／Akamaiを前段に置く価値が出る。ただし第三者を挟むとベンダーが増え、設計・課金・障害切り分けの責任分界が分かれる——この運用コストを織り込んで判断したい。両取り（前段＝Cloudflare/Akamai、オリジン保護＝CloudFront＋AWS WAF）も有効だが、役割分担を明文化しないと二重管理に陥る。

最後に、検証・PoC段階で先に踏み抜いておきたい落とし穴を挙げる。いずれも本番前に塞げば未然に防げるものだ。

その一、オリジンの直アクセス遮断漏れ。ALBやEC2が公開されたままだと、攻撃者はエッジを迂回してオリジンを直撃できる。検証時にオリジンへ直リクエストして「素通りしないか」を必ず確認し、S3はOAC、アプリ層はVPC originsとセキュリティグループ（あるいはCloudFront付与の秘密ヘッダ検証）で塞いでから本番へ上げる。

# オリジン隠蔽の確認例（検証環境で先に潰す）
# 1) S3: OACを設定し、バケットポリシーで当該ディストリビューション以外を拒否
# 2) ALB/EC2: プライベートサブネットへ置き VPC origins 経由に限定
#    （公開が避けられない場合は CloudFront 付与の秘密ヘッダを検証）
IF  http-header X-Origin-Verify != <秘密値>  THEN  return 403
# 3) 検証: オリジンのIP/DNSへ直接 curl して 403/到達不可 になることを確認

その二、WAFの二重管理による見落とし。前段CDNのWAFとAWS WAFの両方でルールを持つと、ブロックの発生源が追えず、リリース後に「誰も意図しない誤ブロック」が起きたときの切り分けが難航する。検証段階でどちらが何を担うかを1枚の表に落とし、ログの相関が取れる状態にしてから運用へ移す。こうした境界設計を先に決めておくことが、重大障害を出さないための最も安いコストだ。

関連記事：AWS・Azure・GCP・オンプレ サービス対応表