複数のDDoS対策CDN事業者に問い合わせると、ある会社は「Tbps級の防御性能」を強調し、別の会社は低価格を売りにし、さらに別の会社は導入の簡単さをアピールしているかもしれません。どの提案も魅力的に見えますが、実際に重要なのはもっと基本的な点です。ユーザーは快適にアクセスできるのか。そして攻撃を受けたときも、サービスを正常に提供し続けられるのかということです。

DDoS対策CDNを選ぶときは、まず対象のサービスやプロトコルに対応できるかを確認し、次にターゲットユーザーに対するネットワーク品質と防御範囲を比較し、最後にトライアル結果と総額の見積もりを基に判断することが重要です。 Webサイト、API、ゲームでは要件が異なります。ミティゲーション容量の数字が大きくても、重要なAPI、オリジンサーバー、すべてのポートが保護されるとは限りません。

まず用途を確認する：何を保護する必要があるのか？

DDoS対策CDNはコンテンツ配信と攻撃対策を組み合わせたサービスですが、導入方式、対応プロトコル、セキュリティ機能はサービスによって異なります。導入前に、「システム全体を保護する」という曖昧な要件を、具体的な入口ごとに整理してください。対象となるドメイン、API、接続、そしてそれぞれが実際に通過するネットワーク経路を明確にする必要があります。

この表は、最初の候補選定に利用できます。たとえばUDPによる対戦ゲームの通信を保護する必要があるにもかかわらず、候補となるプランがWebサイト向けのHTTP/HTTPSプロキシにしか対応していない場合、その時点で別の製品カテゴリを検討すべきです。月額料金を比較する段階ではありません。

Webサイト、API、ゲームに同じ受け入れ基準を適用しない

Webサイトのユーザーであればブラウザ上のチャレンジを完了できても、APIなどのマシンクライアントには同じ処理ができない場合があります。Webページへの不正アクセスを減らすルールでも、モバイルアプリ側ではHTMLのチャレンジページをJSONとして解析しようとしてAPIエラーになる可能性があります。

長時間接続についても、単に「WebSocketに対応しているか」だけを確認するのでは不十分です。Cloudflareのドキュメントでは、WebSocketの最初のHTTP UpgradeリクエストはWAFによる検査を受けますが、接続確立後の後続通信についてはWAFによる継続的な検査は行われないと説明されています。つまり、「WebSocketをサポートしていること」と「すべてのアプリケーションメッセージを継続的に検査すること」は別の機能です。具体的な実装は各事業者のドキュメントで確認する必要があります。CloudflareのWebSocket互換性に関するドキュメント

ゲームサービスでは、公式サイト、ログインAPI、リソース更新、実際の対戦接続も分けて考える必要があります。クライアント側への導入が必要な方式では、SDKの組み込み、バージョンリリース、ロールバックに必要なコストも評価対象です。ゲーム向けセキュリティSDKとDDoS対策IPサービスの選び方も参考にしながら、最初に導入方式を決め、その後でサービスプロバイダーを絞り込むとよいでしょう。

ネットワークはどう選ぶべきか：ターゲットユーザーの実測結果で候補を絞る

「世界各地に多数のPoPがある」「香港へのダイレクト接続」「インテリジェントルーティング」といった説明は、サービスを理解する入口にはなりますが、実測テストの代わりにはなりません。

確認すべきネットワーク経路は2つあります。ユーザーからCDNのエッジノードまでの経路と、エッジノードから実際のアプリケーションサーバーまでの経路です。後者はオリジンへの接続経路であり、実際のアプリケーションサーバーをオリジンサーバーと呼びます。キャッシュにヒットした画像などはエッジから直接返せますが、ログインや検索などリアルタイム処理が必要なリクエストは、オリジンへの通信品質やバックエンドの処理速度にも影響されます。

主要ユーザーがいる地域で比較する

中国本土のユーザーが中心であれば、主要地域におけるChina Telecom、China Unicom、China Mobileのネットワークを対象にし、夜間のピーク時間帯もテストに含める必要があります。海外ユーザーがいる場合も、実際のアクセス比率に合わせて対象地域を追加してください。「グローバルな速度測定結果」を作るためだけに、複数の国を均等に選ぶべきではありません。

ネットワークを比較するときは、候補となるサービスプロバイダーに次の点を確認してください。

• 提示されているエッジロケーションやネットワーク経路は、実際に購入予定のプランで利用できるものか、それともデモ専用なのか？
• テスト用ドメインでも、本番環境と同等のルーティング、セキュリティ、オリジン接続設定を使用できるか？
• ユーザー側ネットワークの輻輳やエッジノード障害が発生した場合、どのようにフェイルオーバーし、どのような基準で復旧を判断するのか？
• 「最適化されたネットワーク経路」は、ユーザーからエッジまで、エッジからオリジンまで、あるいはその両方のどの区間を対象としているのか？

ある地域で記録した最低レイテンシだけでは、ネットワーク品質の一部分しか判断できません。代表的なリクエストの応答時間、遅いリクエストの割合、失敗率も併せて確認してください。平均値では高速でも、重要なユーザー地域で頻繁にタイムアウトするのであれば、平均速度だけを理由に優位とは判断できません。

動的サービスはAPIを、コンテンツサイトはページ全体をテストする

実際のサービスから代表的なページと読み取り専用APIを選び、コンテンツのバージョン、オリジン、キャッシュ条件、セキュリティポリシーを可能な限り同じ条件に揃えます。一方のサービスですでにキャッシュされている画像と、もう一方で初回のオリジンフェッチが発生する動的ページを比較してはいけません。

以下はLinuxまたはmacOSのターミナルで実行できる単発の確認コマンドです。curlがインストールされている必要があります。サンプルのドメインを、自分がテストする権限を持つ公開ページまたは読み取り専用APIに置き換えてください。

curl -sS --connect-timeout 10 --max-time 30 \  -o /dev/null \  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \  'https://www.example.com/'

statusはHTTPレスポンスコード、ttfbはリクエスト開始から最初の1バイトを受信するまでの経過時間、totalは今回の転送全体にかかった時間です。接続待機時間を最大10秒、処理全体を最大30秒としているのは、このサンプルコマンドの制限にすぎず、性能の合格基準ではありません。curlの公式オプション説明

タイムアウトやその他のエラーが発生した場合は、その情報も記録し、失敗したサンプルを削除しないでください。200が返っても、アプリケーション処理が成功したとは限りません。チャレンジページでも同じステータスコードが返る場合があります。301または302の場合はリダイレクト先も確認してください。このコマンドはリダイレクトを自動的には追跡しません。

このようなチェックは、基本的な測定記録を収集するためのものです。Webページについてはブラウザでもリソースの読み込みや操作結果を確認し、ログインや注文処理はテスト環境でテストアカウントを使って検証してください。単発のリクエストだけでは長期的なパフォーマンスを証明できず、DDoS防御性能を証明することもできません。

防御範囲をどう確認するか：サービスプロバイダーに確認すべき4項目

防御範囲とは、どのトラフィックが保護され、どの入口が保護対象外であり、サービスの能力や契約上の上限を超えた場合に何が起こるのかを意味します。単独のミティゲーション容量の数字よりも、実際の調達判断に直結する要素です。

1. ドメインだけが保護されるのか、オリジンやその他のポートも対象になるのか？

WebサイトのドメインをCDN経由にしたからといって、そのサーバーへのすべてのトラフィックがCDNを通過するわけではありません。管理用ポート、CDNに接続していないサブドメイン、同一サーバー上のその他のサービスについても個別に確認する必要があります。

過去のDNSレコードからオリジンIPアドレスが判明する場合もあります。攻撃者がCDNを迂回してオリジンへ直接アクセスすれば、エッジノード上のセキュリティルールはその通信経路には適用されません。DNS設定を変更するだけではなく、オリジンへのアクセス元制限、オリジン認証、上流ネットワーク側の保護を組み合わせて対処する必要があります。Cloudflareのオリジンサーバー保護ドキュメントでは、過去のIPアドレス、アクセス制御、オリジン認証などの確認項目が示されています。実際の設定では、採用するサービスプロバイダーが提供する方式に従ってください。

導入前には、オリジンIPアドレスの露出確認と秘匿方法を参考に、外部から到達可能な入口を整理できます。サーバー上でリクエストを拒否するだけでは、上流回線の帯域がすでに攻撃トラフィックで飽和している状況には対応できません。その場合はネットワーク側またはサーバー側の保護も評価する必要があります。

2. 大規模トラフィック対策、リクエスト保護、アプリケーションリスク対策には何が含まれるのか？

Gbpsは帯域規模、ppsは1秒あたりのパケット数、QPSは1秒あたりのリクエスト数またはクエリ数を表します。それぞれ測定している対象が異なるため、非常に大きなGbpsの数字だけで、すべてのアプリケーション層テストを代替することはできません。

キャッシュ済み画像への1リクエストと複雑な検索処理への1リクエストでは、リクエスト数が同じでもオリジンに与える負荷が大きく異なることがあります。DDoS対策CDNが悪意のある検索リクエストを制限できるかどうかは、対象パス、ルール、実際のアプリケーション動作を踏まえて判断する必要があります。

また、DDoS対策は主にサービス停止を引き起こす大量のトラフィックやリクエスト消費に対応します。Web Application Firewall（WAF）は不審なWebリクエストを検査し、Bot管理は自動化されたアクセスを対象とします。これらは連携できますが、アカウント乗っ取り、決済不正、アプリケーションの脆弱性まで自動的に解決されるわけではありません。各機能の役割については、WAF、Bot管理、DDoS対策をどのように組み合わせるかも参考にできます。

3. 「無制限のDDoS防御」は、具体的に何が無制限なのか？

「無制限」「上限なし」といった表現を見た場合は、その適用範囲をサービスプロバイダーに確認してください。攻撃トラフィックに対する課金方法を指している場合もあれば、特定の防御容量についての説明である場合もあります。正規トラフィックの帯域、リクエスト数、同時接続数、ドメイン数、利用規約については、それぞれ個別に確認する必要があります。

直接、「この条件はどの製品の、どのトラフィックに適用されますか？レート制限、プロキシ停止、ブラックホールルーティングが適用されることはありますか？その場合、どのように通知され、どのように復旧しますか？」と確認するとよいでしょう。ブラックホールルーティングは通常、対象へのトラフィックを一時的に破棄する措置であり、正規ユーザーからのアクセスにも影響します。

回答が「心配ありません。絶対に落ちません」といった説明だけで、確認可能な適用条件が提示されない場合は、有料契約へ進む前に慎重に検討すべきです。

4. 誤遮断、障害、上限超過には誰が対応するのか？

正規ユーザーがブロックされたとき、顧客側で対応するセキュリティイベントを確認できるでしょうか。どの種類のルールに一致したかを把握できるでしょうか。誰がルールを変更する権限を持つのでしょうか。重要なサービスに影響が出た場合、実際に問題を処理できる担当者へどのように連絡できるのでしょうか。

トライアル期間中に、実際に想定されるポリシー調整を依頼してみる方法もあります。たとえば、ログインAPIを保護しながら、署名検証済みのパートナーからのコールバックは正常に通す、といった要件です。サービスプロバイダーがルールの適用範囲、検証方法、ロールバック方法を説明できるかを確認するほうが、「24時間対応していますか」とだけ質問するより実用的です。

CDN07、Cloudflare、AWSなどをどのように候補へ入れるべきか？

サービスプロバイダーを比較するときは、「ブランド名」だけではなく、「具体的な製品とプラン」まで落とし込んで評価してください。同じベンダーでも、製品によって導入方法、ルール機能、料金体系が異なる場合があります。

以下は候補リストを作成する際の検討例です。パフォーマンスランキングではなく、ここに掲載していないサービスプロバイダーが不適切であることを意味するものでもありません。

Cloudflareの公式ドキュメントでは、すべてのプランに標準のDDoS対策が含まれ、攻撃量に応じた従量課金は行われないと説明されています。一方、一部の高度な機能はプランによって異なります。そのため、「無料プランには有効なDDoS対策がない」という理由だけで他のサービスを推奨するのは適切ではありません。実際の要件と各プランで利用可能な機能を比較する必要があります。CloudflareのDDoS対策機能に関するドキュメント

AWS Shield Standardは自動的に提供され、追加料金は発生しません。Shield Advancedは、より高度な保護を提供する別途契約のサービスです。またCloudFrontにはAWS WAFを組み合わせることができます。これらは組み合わせた構成として評価すべきであり、CloudFront単体をすべての高度なセキュリティ機能の総称として扱うべきではありません。AWS Shieldの説明、CloudFrontとAWS WAFの設定方法

中国本土からのアクセス品質とセキュリティポリシーをまとめて検討したいWebサイトに対して、CDN07はパフォーマンス高速化とDDoS対策を組み合わせ、エッジロケーション、帯域、セキュリティポリシーについて要件に応じた構成を提供しています。CDN07 DDoS対策CDNサービスから具体的な要件を提示し、構成案と受け入れ条件を同じ評価プロセスで確認できます。

まず共有すべきなのは、サービスの実態です。ユーザーがどこからアクセスするのか、どの操作が失敗してはいけないのか、オリジンがどこにあるのか、これまでどのような攻撃を受けたのかを整理してください。そうすることで、調整すべき対象がネットワーク経路なのか、キャッシュなのか、アプリケーション層の保護なのか、オリジンへの入口なのかを判断し、具体的な構成要件を提示しやすくなります。

トライアルの合否をどう判断するか：速度測定のスクリーンショットだけで終わらせない

最初に必須条件を定義し、その条件を満たした候補同士でパフォーマンスとコストを比較してください。以下のいずれかが重要なサービスに関係し、未解決のままであれば、単に価格が安いという理由だけで採用すべきではありません。

• 必要なプロトコル、ポート、重要機能がサポートされていない。
• 重要なユーザーネットワークで、事前に合意したアクセス品質を継続的に満たせない。
• 正常なログイン、コールバック、長時間接続が誤ってブロックされ、検証可能な解決策もない。
• 防御範囲、上限超過時の処理、課金条件が明確に説明されない。
• 移行後に問題が発生した場合の実行可能なロールバック手順がない。

これらの条件を満たした後で、代表的なネットワークにおけるページ体験、APIレスポンス、エラー率、設定・運用コストを比較します。トライアル記録には、サンプル数、測定時間、キャッシュ状態、セキュリティ設定を残してください。これらの条件が記録されていないスクリーンショットだけでは、結果の再現や検証が困難です。

DDoS防御性能のテストは別途計画する必要があります。関連するCDN事業者、オリジン運用者、ネットワークサービスプロバイダーの許可を取得し、負荷強度、実施時間帯、停止条件について事前に合意した場合にのみ、攻撃シミュレーションや負荷テストを実施してください。通常のアクセス試験で検証できるのはアクセス性と機能であり、それだけを根拠に特定規模のDDoS防御性能が検証済みだと判断することはできません。

調達時には、一般にSLAと呼ばれる可用性に関する契約条件も項目ごとに確認してください。どのサービスが対象なのか、ダウンタイムをどのように算出するのか、どのようなケースが除外されるのか、サービスクレジットなどの補償をどのように申請するのかを確認します。SLAがあるからといって障害が発生しないわけではなく、補償条件もサービス復旧計画の代わりにはなりません。

月額料金をどう比較すれば、実際の導入コストが見えるのか？

候補サービスは、同じ利用条件を前提に比較して初めて意味があります。少なくとも、基本料金、正規トラフィックまたは帯域、リクエスト数、ドメインと証明書、追加のセキュリティ機能、オリジンからのアウトバウンド通信などに関連する費用を確認してください。請求期間、通貨、超過料金のルールについても同じ条件で整理する必要があります。

2社の見積もりで月額料金が同じでも、一方は必要なセキュリティポリシーやサポートが含まれ、もう一方では追加購入や自社チームによる運用が必要になる場合があります。その場合、実質的な総コストは異なります。料金構造をさらに詳しく確認する場合は、DDoS対策CDNの料金を構成する要素も参考にできます。

見積もりを依頼するときは、以下のテンプレートをコピーし、同じ要件を各候補事業者へ送ることができます。

业务类型及关键操作：主要用户地区、运营商与高峰时间：源站所在地区及接入方式：域名、协议、端口及长连接需求：正常带宽、流量、请求量与并发情况：已有攻击类型、时间及可提供的日志：必须保持正常的登录、回调、上传等功能：希望达到的访问、错误率及恢复目标：测试范围、迁移时间与回退要求：预算与期望计费周期：请说明：适配产品、包含能力、不覆盖范围、限制与超限动作、完整费用、技术支持方式，以及可执行的测试和验收安排。

まだ把握できていない利用量については「集計中」と明記し、見積もりを取得するためだけに適当な大きい数字や小さい数字を入力しないでください。ログを提供する場合は、アクセストークン、セッションCookie、個人情報や機密情報を削除してください。見積もりの段階でパスワードや秘密鍵を提出する必要はありません。

よくある質問

どのDDoS対策CDNがよいですか？すべてのWebサイトに適したサービスはありますか？

利用条件を無視して一律に適用できる答えはありません。コンテンツサイトでは配信とキャッシュが重視され、取引システムでは動的リクエストと誤遮断の制御が重要になります。ネイティブゲームではさらに異なるプロトコルへの対応が必要です。まず要件に合わない製品を除外し、その後で自社ユーザーのネットワークと実際のアプリケーションを使って候補を比較してください。

DDoSミティゲーション容量が大きいほど、選ぶ価値も高いのでしょうか？

必ずしもそうではありません。その数字がプラットフォーム全体の処理能力なのか、顧客単位の上限なのか、特定の試験条件における値なのかを確認する必要があります。さらに、アプリケーションリクエスト、正規トラフィックの処理容量、上限超過時の対応も個別に確認してください。非常に大きな帯域の数字が示されていても、注文APIが適切に保護されていることを証明するものではありません。

低価格のDDoS対策CDNを企業システムで利用できますか？

サービス要件を満たし、料金、制限、サービス範囲が明確であれば比較対象に含めることができます。価格が安いこと自体は、信頼性が低い証拠ではありません。同様に、価格が高いからといって必ず適しているわけでもありません。提供内容全体と実際のテスト結果を比較する必要があります。

API向けにDDoS対策CDNを選ぶ際、見落としやすいポイントは何ですか？

見落としやすいのは、セキュリティポリシーとマシンクライアントとの互換性、認証方式、アップロードサイズ、タイムアウト、リクエストレート制限です。テストではステータスコードだけを見るのではなく、レスポンスタイプ、アプリケーション上のフィールド、呼び出し元が結果を正しく処理できるかまで確認する必要があります。

DDoS対策CDNを導入した後も、オリジン保護は必要ですか？

オリジンへの入口は引き続き確認する必要があります。CDNを経由していないリクエストまで自動的に保護対象になると考えるべきではありません。過去に使用していたIPアドレス、その他のポート、同一サーバー上のサービスが別の攻撃経路になる可能性があります。追加のサーバー側保護が必要かどうかは、こうした露出面と上流ネットワークの保護能力を基に判断してください。

CDN07を検討する場合、最初にどのような情報を提供すればよいですか？

まず、サービスの種類、主要ユーザーのネットワーク、オリジンの所在地、使用プロトコル、重要な処理フローを共有し、その後に通常時の利用量と過去の攻撃記録を追加してください。これらの情報があれば、適切な構成の方向性を確認しやすくなり、その後のテストと見積もりについても共通の前提条件を作ることができます。

サービスプロバイダーを決める前に、検証可能な回答を得る

DDoS対策CDNを選定するときは、次の4点を確認してください。

• サービス要件とプロトコルによって候補範囲が決まります。重要機能が要件に合わない場合は、まず製品カテゴリを見直してください。
• ネットワーク品質は、ターゲットユーザーと実際のサービスを使って検証する必要があり、最低レイテンシだけで判断すべきではありません。
• 防御サービスでは、保護範囲、誤遮断への対応、上限超過時の処理を明確にする必要があります。
• 最終的な選定では、受け入れテストの結果、総コスト、障害対応能力を併せて評価してください。

要件リストを準備したら、まず候補となるサービスプロバイダーに構成案を説明してもらい、その後で範囲を明確にした検証を実施してください。CDN07を検討している場合は、DDoS対策CDNに関するお問い合わせから要件を送信し、ネットワーク経路、オリジンへの接続、防御範囲を中心に評価項目を整理したうえで、適切な構成を検討できます。