デザインによって実現する強靭性：AWS 障害下でも確保された Cato の可視性とバックボーン性能
2025年10月 AWS 障害における事業継続性と可視性の確保
2025年10月20日、Amazon Web Services（AWS）の米国東部地区（US-East-1）で障害が発生しました。この事象は、世界中のビジネスコラボレーションツール、金融取引プラットフォーム、航空関連システム、そして数百万人が利用する消費者向けサービスに一時的なパフォーマンス低下を引き起こすと共に、世界中でも広く報道されました。この障害に対し、迅速かつ的確に対応された AWS の皆さまに、改めて敬意を表します。
今回の障害は、“基盤となるインフラを自社で保有する重要性”を改めて示すものとなりました。ハイパースケーラーのバックボーンが停止すれば、つい先日の Google Cloud 障害でも見られたように、影響はインターネット全体に波及します。これに対し Cato Networks のお客様は、ほとんど影響を受けることなくサービスを継続でき、当社独自のグローバル・プライベートバックボーンと分散 PoP アーキテクチャの高いレジリエンスが実証されました。これらの仕組みによって、大規模なクラウド障害下でも、安定した接続性と高い可視性が維持されたのです。
グローバル接続性が試されたクラウド障害
AWS Health Dashboard によれば、今回の障害は US-East-1 リージョン内の複数の AWS サービスに影響を与え、エラー率の上昇や接続障害を引き起こしました。クラウド上のアプリケーションに依存する多くの企業は、コラボレーション、ファイル共有、日常業務に一時的な支障が生じました。
Cato Networks は、これらの現象を自社インフラでの障害としてではなく、SaaS レイヤーで生じる性能低下として、Cloud Application Analytics を通じてグローバルに把握していました。
AWS 障害発生中に Cato が確認した状況
図１に示すとおり、障害発生期間中は 、AWS 上で稼働する複数の SaaS アプリケーションにおいてエラーレートが急上昇し、複数サービスの可用性が同時に低下していたことが明確に確認できました。さらに図２においては、実ユーザーのトラフィックに基づく Slack の HTTP エラー率が、AWS 障害の発生時刻とぴたりと一致して急増し、その後サービス回復とともに正常化する様子が示されています。
図1：AWS 上の主要 SaaS アプリケーションのエラーレート推移 — 10 月 20 日の AWS 障害に対応する鋭いスパイクが確認できる。
図2：Slack の HTTP エラー総数の推移 — スパイクが AWS 障害の発生タイミングと完全に一致。
こうしたインターネット全体の接続問題が見られた一方で、Cato のバックボーンおよび各PoPは100%の可用性を維持していました。そのため、Catoを利用するお客様は「ネットワークは健全だが、特定の SaaS にのみ障害が発生している」という状況をリアルタイムに把握でき、従来型アーキテクチャでは得にくい透明性を確保できたのです。
Cato のリアルタイム分析プラットフォームでは、以下の事象が明確に観測されました：
- AWS 上で提供される複数の SaaS アプリケーションで、障害時間帯に利用量が明確に低下
- Cato PoP 間の遅延・スループット・パケット配送は安定しており、バックボーンへの影響は一切なし
Cato Management Application を使うことで、お客様は、外部要因による SaaS 側の障害と、引き続き正常に稼働していた自社ネットワークの性能とを、明確に切り分けて把握することができました。
これにより、IT チームおよび NOC チームは、障害の原因を正確に認識しつつ、不要なアラートに惑わされることなく迅速に対処できました。結果として、障害発生中も自社インフラの健全性への信頼を維持することができました。
図３では、Cato Management Application 内で HTTPS／HTTP のエラーレートを時間軸で直接確認でき、SaaS レイヤーの性能劣化をリアルタイムで把握できることを示しています。
図3：Cato Management Application における HTTPS／HTTP エラーレートの推移 — AWS 障害に伴う SaaS レイヤーでの失敗増加を可視化。
さらに図４は、Site Application Experience Score を用いて、AWS を利用するアプリケーションのパフォーマンスが、障害期間中に他の SaaS と比較して顕著に低下したことを視覚的に示しており、ユーザー体験への影響が直感的に理解できます。
図4： Site Application Experience Score の比較 — 障害期間における Amazon AWS のパフォーマンス低下が、他の SaaS と比べても際立っていることを示す。
なぜ Cato は揺るがなかったのか：継続性を前提に構築されたアーキテクチャ
Cato のアーキテクチャは、外部障害にも動じない高いレジリエンス（耐障害性・自動復旧性）とクラウド依存からの独立性を備え、常に安定したサービス提供を可能にするよう設計されています。たとえハイパースケールクラウドのリージョンで障害が発生しても、Cato の SASE プラットフォームは途切れることなく稼働し続けます。しかし、Cato が 99.999% の稼働 SLA を実現できる理由は、クラウドへの非依存性だけではありません。
コントロールプレーンとデータプレーンの分離
コントロールプレーン（管理系）とデータプレーン（トラフィック処理系）は独立して動作します。そのため、データ転送経路に不安定さが生じても管理プレーンは影響を受けず、逆のケースでも同様にそれぞれが機能し続けるのです。
分散型 PoP アーキテクチャ
Cato の各 PoP（Point of Presence）は、Cato 自身が独立して運用・管理しています。そして、そのすべてで、完全に分散された当社独自のソフトウェアスタックが実行されています。世界 85 か所以上に PoP を展開しているため、特定のクラウドリージョンやクラウド事業者に依存することはありません。仮にある PoP に到達できなくなった場合でも、トラフィックは自動的に最寄りの利用可能なノードへ迂回され、プライベートバックボーン上でセッションは維持され、パフォーマンスも安定したまま保たれます。
自動 WAN Recovery
接続異常が発生した際には、WAN Recovery が自動的に即時起動し、手動操作なしに復旧を開始します。Cato Socket は利用可能な別回線へ自動で再接続し、サイト間接続やインターネットアクセスを維持。ローカルのファイアウォールポリシーもそのまま適用されるため、上流経路の一部が問題を抱えていても、拠点内部のオペレーションは通常どおり継続できます。
多層構造によるフェイルオーバー
Cato のスタックには、あらゆるレイヤーにレジリエンス（耐障害性・自動復旧性）が組み込まれています。
- Socket High Availability（HA）は、メインとセカンダリの Socket を自動で切り替え、機器側の障害が発生しても接続を維持します。
- WAN Recoveryは、回線障害が発生した際、セカンダリ ISP 回線や LTE バックアップなど、利用可能な別経路へシームレスにフェイルオーバー。手動操作なしでサイトの接続性を継続します。
- Internet Recoveryは、ある PoP が到達不能になった場合、トラフィックをローカル ISP 経由へ一時的に迂回させ、通信を継続します。
- バックオフアルゴリズムによって、再接続処理を賢く制御し、リカバリー中の不安定化を防ぎます。
マルチパス型クラウドレジリエンス：Cato の HA、BGP、BFD が発揮する強靭性
Cato は複数のクラウド接続手段を提供しており、大規模なクラウド障害が発生した場合でも、単一経路に依存することなく、企業が事業継続を図れるよう設計されています。これらの機能は、特定のクラウドに縛られない レジリエントかつクラウド非依存の接続性（cloud-agnostic connectivity） を実現するための Cato の戦略の中核を成すものです。この強みが評価され、Cato は Gartner の Market Guide for Private Connectivity to Public Cloud Services（購読者向け）でも高く認められています。
1.Cato vSocket によるネイティブ高可用性（HA）
AWS 上に Cato vSocket を導入する企業は、複数のアベイラビリティゾーン、さらにはリージョン間にまたがる HA 構成を組むことができます。どちらかの経路やゾーンで性能が低下した場合でも、トラフィックは自動的にスタンバイ側の vSocket へ切り替わり、セッションと業務処理は途切れることなく継続します。このフェイルオーバーは完全に自動化されており、運用側の手動介入は不要です。
2.BGP と BFD を活用した Software-Defined Cloud Interconnect（SDCI）
リージョンをまたぐ構成やハイブリッド環境では、Cato の Software-Defined Cloud Interconnect が
BGP（Border Gateway Protocol / 境界ゲートウェイプロトコル） と BFD（Bidirectional Forwarding Detection / 双方向フォワーディング検出） の両方をサポートします。
この組み合わせにより、障害を サブ秒レベルで検知 し、ルートの再収束も迅速に実行できます。
たとえば AWS US-East-1 に不安定が発生した場合、トラフィックは自動的に他リージョン（例：EMEA）へ迂回し、重要なクラウドサービスの接続性・稼働時間・パフォーマンスを維持できます。
成果：継続するオペレーションと確かな可視性
これらの機能により、各企業は以下を実現できます：
- 障害を迅速に検知し、健全なリージョンへ自動的にトラフィックを迂回
- ラウド障害が発生しても、サービス継続性を確保し、ユーザーへの影響を最小化
- Cato Management Application を通じ、SaaS 側の劣化と Cato バックボーン性能を正確に切り分けて可視化
詳しくはこちら。 Getting Started with Cloud Interconnect Sites 及び Configuring BFD for BGP Neighbors
リアルタイムの SaaS 可視性：本当に重要なものが見えるという強さ
AWS 障害の最中、決定的な違いを生んだのは「可視性」でした。多くの IT チームが障害の原因特定に苦戦する中、Cato のユーザーはアプリケーションレイヤーの状態を明確に把握できていました。
Cato の Application Analytics により、IT チームは次のようなことが可能になっていたのです：
- AWS 障害の影響を受けている SaaS を特定する
- Cato バックボーンが正常に稼働し続けていることを確認する
- 外部サービス側の劣化であることを、ユーザーに正確に説明する
この可視性によって、世界規模のクラウド障害は “制御不能な事象” ではなく、把握し、対処できるネットワークイベント へと変わりました。Cato のお客様は、つながり続け、状況を把握し、自社インフラの安定性に確信を持ち続ける事ができたのです。
最終的な教訓：鍵となるのはアーキテクチャの独立性
2025 年 10 月の AWS US-East-1 障害は、企業に重要な教訓を再認識させました。クラウドレジリエンスには アーキテクチャの独立性、可視性、自動化 が不可欠だということです。
IT リーダーにとっての重要ポイント：
- 単一リージョンや単一バックボーンへの依存を避け、独立性を確保する
- ネットワークに可視性を持たせ、内部問題と外部障害を切り分ける
- BFD、BGP、多層冗長化によってフェイルオーバーを自動化する
- ユーザーが影響を受ける前に、システムが自律的に適応できるようにする
Cato は、AWS のようなクラウドパートナーの高い信頼性を補完し、予期せぬ事態においてもサービス継続と透明性を確保する、独立性とインテリジェンスを備えたバックボーン を提供できることを誇りに思います。
AWS の迅速な障害対応と、Cato の分散型 SASE バックボーンによって、Cato のお客様は障害期間中も常につながり続け、状況を正確に把握し、SaaS のパフォーマンスを完全に可視化しながら、通常通りのサービスを提供し続けることが出来たのです。
レジリエンスとは、障害に“耐える”だけではないレジリエンスとは、障害を正しく理解し、賢く対応し、そしてサービス提供を継続すること。
急増するトラフィックに対応：日本のゴールデンウィーク後のトラフィック急増をどう乗り切ったか
クラウドが停止したとき：重要なサービスにおいてインフラを所有することがなぜ重要なのか
ネットワークの未来を拓く：SD-WANとMPLSの違い
