ナビゲーション全体を読み込み中です。

Elevate 2026へのカウントダウンが始まりました。 今すぐ登録 シカゴ、ロンドン、またはシドニーで私たちと一緒に過ごしませんか。

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

ロジックモニターブログ

障害発生の振り返り：AWSの局所的な障害がステータスページを回避した経緯

AWSの小規模な障害は、ユーザーがその影響を感じていたにもかかわらず、ステータスページには表示されませんでした。外部からのインターネット可視化によって、内部ツールでは捉えられない事態がどのように発生するのかをご覧ください。

6〜9分
デントン千倉

ニュースレター

最新情報のメール配信を登録

最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

シェア

クイックダウンロード

プロバイダーが「正常」と表示していても、ユーザーが「故障している」と訴えている場合は、ユーザーの意見を信じましょう。

  • AWSの25分間の小規模な障害により、LumenおよびCenturyLinkネットワークを通過するトラフィックに関して、S3、EC2、CloudFront、およびLambdaが影響を受けたが、AWSのステータスページには異常は表示されなかった。

  • 内部テレメトリやプロバイダーダッシュボードでは、ユーザーとサービスの間にあるISP、中継経路、ピアリングポイントにおける障害を検出することはできません。

  • わずか25分のダウンタイムでも、SLA（サービスレベル契約）の0.06%が損なわれるだけでなく、クラウドプロバイダーではなく、ユーザーから自社の評判を貶められるという損害にもつながります。

  • 外部からのインターネット可視性とインフラストラクチャの可視性を組み合わせることで、ユーザー視点での障害を検知し、証拠に基づいて対応できるようになります。

クラウドプロバイダー、ステータスページ、社内監視システムがすべて正常と表示していても、ユーザーには影響が出る可能性があります。この認識のずれこそが、いわゆるマイクロ障害の真のリスクです。マイクロ障害とは、プロバイダーが対応を通知するほどではないほど小規模または局所的なインシデントでありながら、実際のユーザーエクスペリエンスを低下させ、SLAに違反し、信頼を損なうほど深刻な影響を与えるものです。

大規模な停電が発生すると、 CrowdStrikeインシデント 大きなニュースになるような障害も、実際には様々な形で発生する。地理的な要因、自律システム、あるいは輸送経路によって局地的に限定される。ニュースにはならないし、ステータスページにも表示されない。しかし、それでもコストがかかり、評判が傷つき、対応に追われることになる。

あらゆる企業は、クラウドプロバイダー、ISP、DNS、CDN、ピアリングポイント、ルーティングインフラストラクチャなど、自社が直接制御できないレイヤーに依存しています。これらのレイヤーのいずれかに障害が発生すると、たとえ社内テレメトリがすべて正常値を示していても、ユーザーはその影響を感じます。課題は、ユーザーから苦情が出る前に、自社環境外で何が起こっているかを把握することです。

AWSの小規模な障害は、この問題を明確に示している。 キャッチポイントLogicMonitor傘下の企業がこの障害を検知したが、AWS自身のステータスページには、この事象全体を通して問題は一切表示されていなかった。

AWSの小規模障害中に何が起こったのか

2025年8月14日、UTC午前8時00分から午前8時25分の間に、 インターネットソナー複数のリージョンにわたる複数のAWSサービス（S3、EC2、CloudFront、Lambda）に影響を与える接続タイムアウトを検出しました。タイムアウトは、CenturyLink AS209およびLumen（Level 3）AS3356のロケーションで観測されました。

この事象は完全なサービス停止には至らなかったものの、これらのネットワークからのトラフィックがAWSサービスに到達する能力に測定可能な影響を与えた。

AWSの小規模な障害の影響を示すダッシュボード。複数のサービスにおいて、異なるAWSリージョンで接続問題が検出されています。

接続時間によるテスト失敗を示すウォーターフォール記録と、AWSインシデントを示すインターネットソナーの根本原因

複数の地域における様々なサービスでのダウンタイム率

さらなる調査の結果、接続タイムアウトは主にLevel 3 AS3356およびCenturyLink AS209を起点または経由するトラフィックで発生していることが判明した。このパターンは、これらのトランジットプロバイダーとAWS間のピアリングに潜在的な問題があることを示唆している。

ピアリング問題の根本原因は依然として不明である。ただし、これらの2つのLumen ASの影響を受けたのはAWSのみであった。

内部からマイクロ障害を検知するのが難しい理由

今回の事件は、クラウドインフラストラクチャ上で運用されているすべての組織に影響を与える脆弱性を露呈しました。内部テレメトリではアプリケーションが正常に動作していると表示されていても、そのアプリケーションへの外部パスが障害を起こしている可能性があるのです。

アプリが稼働しているクラウド環境内で監視を行っている場合、トランジットプロバイダーとクラウドプラットフォーム間のピアリングの問題は検出されません。サーバーは正常に動作し、ヘルスチェックもパスします。しかし、一部のユーザーはサービスにアクセスできません。内部ツールでは問題箇所を特定できないのは、問題が自社環境の外、つまりユーザーとサービスを接続するISP、トランジットプロバイダー、ピアリングポイントの連鎖のどこかで発生しているためです。

これは、外部からのインターネット可視化と内部からの監視を組み合わせることの核心的な論拠です。正確な診断には、インフラストラクチャが何を見ているか、そしてユーザーが実際に何を体験しているかという、両方の視点が必要です。

ステータスページでは、ユーザーがどのような状況に陥っているかはわかりません。

このインシデント発生時、AWSの公式ステータスページには問題は表示されていませんでした。影響を受けたユーザーを抱えるチームにとっては、これは大きな矛盾を生み出しました。「顧客からは苦情が出ているのに、プロバイダー側​​はすべて正常だと言っている」という状況でした。

スクリーンショット：小規模な障害発生時のAWSのステータスページ

これは珍しいことではなく、プロバイダーが問題を隠しているわけでもありません。クラウドプロバイダーはそれぞれ、問題がステータスページを更新するに値するかどうかを判断するための独自の基準とプロセスを持っています。多くの場合、プロバイダーは顧客から報告されるまで、ローカルな問題に気づかないことがあります。中には、そもそも問題として認識される基準を下回るものもあります。

パフォーマンスの低下や遅延はステータスページに表示される可能性はさらに低いが、ユーザーエクスペリエンスに大きな影響を与える可能性がある。 インターネット障害の高額なコストプロバイダーから何らかの問題が発生したとの連絡を待つことは、あなたにとって許容できない遅延を引き起こします。

要点は単純明快だ。チームはサービスの状態を独自に検証する必要がある。プロバイダーのステータスページだけが唯一の情報源であれば、最も重要な局面で不完全な情報に基づいて業務を行うことになる。

第三者依存事象に関する実務者向けフレームワーク

今回の事例は、AWSに限らず、あらゆるサードパーティ依存関係に当てはまるパターンを改めて示すものです。問題がクラウドプロバイダー、ISP、DNSプロバイダー、CDN、ピアリングポイントのいずれに起因する場合でも、同じ枠組みが適用されます。

外部から内部へ検出する

さまざまな地域、ISP、通信経路にわたって、ユーザーの視点からサービスを監視しましょう。内部の健全性チェックでは、自社環境外に起因する問題は検出できません。外部からの監視によって、内部ツールでは見逃してしまう問題を捉えることができます。

プロバイダーのステータスを独自に検証する

プロバイダーのステータスページを信頼できる情報源として鵜呑みにしないでください。プロバイダーのダッシュボードに表示される内容とは関係なく、ユーザーからの報告と自社の監視結果を比較検討してください。

経路とプロバイダーの影響を分離する

問題がすべてのユーザーに影響しているのか、それとも地域、ISP、または通信経路に基づいて特定のユーザーグループに影響しているのかを判断します。今回のAWSインシデントでは、影響は2つの特定の自律システムを通過するトラフィックに集中していました。このような分離によって、影響範囲を把握し、対応の優先順位付けを行うことができます。

証拠に基づいてコミュニケーションをとる

ユーザーから問題が報告され、プロバイダー側​​が問題ないと言う場合、何が起こっているのかを説明するために独立したデータが必要になります。証拠に基づいたコミュニケーションは、たとえ自社に責任のない障害が発生した場合でも、顧客との信頼関係を維持するのに役立ちます。

代替案と緊急時対応計画をテストしてください。

すべての組織が、すべてのサービスに対してマルチクラウドまたはハイブリッドフェイルオーバーを導入できるわけではありません。フェイルオーバーが実現不可能な場合は、ユーザーとの積極的かつ透明性の高いコミュニケーションが次善の策となります。こうした事態が発生する前に準備しておくこと（誰が連絡を取るのか、どのような証拠を共有すべきか、どのような回避策が存在するのかを把握しておくこと）で、インシデント発生時の混乱を軽減できます。

クラウドプロバイダーからクラウドプロバイダーを監視しないでください

今回の事例は、検討に値するアーキテクチャ上のリスクも浮き彫りにしています。監視インフラストラクチャが、監視対象であるクラウドプラットフォームと同じプラットフォーム上で稼働している場合、単一障害点が発生していることになります。

クラウドプロバイダーに問題が発生すると、監視システムもダウンするか、さらに悪いことに、同じ障害の影響を受けるため、誤った情報（偽陰性）が報告されることになります。可視性が最も重要な場面で、まさに盲点が生じてしまうのです。

これは合成監視にも当てはまります。合成テストが同じクラウドインフラストラクチャ上でホストされているノードから実行される場合、そのプロバイダーに影響を与える障害が発生すると、テストで問題を検出できなくなる可能性があります。つまり、プラットフォームの内部からプラットフォームの状態を測定していることになります。

監視を実行する場所を多様化し、主要なクラウドプロバイダーとは別の独立した監視ポイントを確保することは、単なるツール選択ではなく、回復力アーキテクチャに関する重要な決定事項です。

外部からの可視性とインフラストラクチャの可視性を連携させる

今回のような小規模な障害は、内部ツールが把握できる情報とユーザーが実際に体験する情報の間のギャップに存在します。このギャップを埋めるには、互いに補完し合う2つの視点が必要です。

LogicMonitorは、外部からのインターネット可視性を提供します。つまり、ISP、トランジットプロバイダー、ピアリングポイント、CDN、DNS、クラウドエッジ全体にわたって、ユーザーの視点から問題を検出する機能です。このプラットフォームはまた、 インフラストラクチャの可観測性 (NAIST) と 運用情報 ハイブリッド環境、クラウドサービス、アプリケーション、ログなど、あらゆる要素を網羅しています。これらを組み合わせることで、ユーザーが直面する問題とバックエンドの健全性や外部依存関係の問題を関連付けることができ、ユーザーエクスペリエンス、ネットワークパス、クラウドサービス、バックエンドシステム間の盲点を減らすことができます。

外部からの視点と内部からの視点の両方を可視化できるこの組み合わせこそが、チームが必要とする独立した証拠を提供するのです。プロバイダーが問題はないと言い、社内ダッシュボードが正常を示していても、ユーザーから苦情が寄せられる場合、ユーザーからインフラストラクチャに至るまでの全経路を把握できる機能があれば、混乱を明確な状況へと変えることができます。

目に見えない出来事の代償

ユーザーはクラウドプロバイダーを責めるのではなく、あなたを責めるでしょう。

顧客が企業で、SLA（サービスレベル契約）を締結している場合、このような事態は契約違反につながる可能性があります。わずか25分のダウンタイムでも、SLAの0.06%が影響を受ける可能性があります。プロバイダーが問題を認めていない場合、ユーザーは不満を抱えたまま、何の理由も説明されないまま放置されます。たとえ後から説明があったとしても、企業の評判（そして場合によっては収益）へのダメージは既に発生しています。

目標は、問題を早期に発見し、影響を軽減し、問題が拡大する前に証拠に基づいて対応することです。ユーザーからインフラストラクチャに至るまで、デジタルプロセス全体で何が起こっているかを独自に検証できるチームは、より高い自信を持って業務を遂行し、顧客体験とビジネス成果の両方を保護することができます。

ユーザーよりも先に、障害を察知しましょう。

LogicMonitorは、プロバイダからの応答が途絶えた瞬間に、独立した証拠を提供します。後から原因究明に追われるのではなく、次の小規模な障害を未然に防ぎましょう。

よくあるご質問

マイクロアウトとは何ですか？

回答1：マイクロ障害とは、規模が小さすぎたり、局所的すぎたりしてプロバイダ側が対応を通知するほどではないものの、実際のユーザー体験を低下させ、SLA（サービスレベル契約）に違反し、信頼を損なうほど深刻な障害のことです。これらの障害は、地理的な要因、自律システム、または通信経路によって隔離されていることが多く、ユーザーが影響を感じていても、ステータスページに表示されることはほとんどありません。

AWSのステータスページに2025年8月14日の問題が表示されなかったのはなぜですか？

クラウドプロバイダーごとにステータス更新のしきい値が異なり、局所的な問題やしきい値以下の問題は、顧客から報告されるまで認識されないことがよくあります。今回の事象では、Lumen（レベル3）AS3356とCenturyLink AS209を経由するトラフィックが接続タイムアウトの影響を受けましたが、これはピアリングレベルの問題であり、AWSのダッシュボードでは検出されませんでした。

チームは、社内ツールでは見逃してしまうような小規模な障害をどのように検知できるのでしょうか？

さまざまな地域、ISP、および伝送経路にわたって、ユーザー視点からサービスを監視し、プロバイダーの状態を独自に検証します。Internet Sonarのような外部からの視点に基づくツールとインフラストラクチャの可観測性を組み合わせることで、チームはどのレイヤーで障害が発生したかを特定し、証拠に基づいてコミュニケーションを取ることができます。

デントン千倉著

テクニカルライター

デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

デントン千倉著

テクニカルライター

デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。

関連ブログ

AWS Kinesis 上で OpenTelemetry トレースヘッダーを伝播する方法: パート 3
Blog 可観測性

AWS Kinesis 上で OpenTelemetry トレースヘッダーを伝播する方法: パート 3

Kinesis PartitionKey と ExplicitHashKey を組み合わせることで、OpenTelemetry トレース コンテキストを伝播させつつ、レコードを元のシャードに保持し、順序を維持することができます。
2026 年 10 月 5 日
さらに詳しく
統合クラウド監視がハイブリッドITの盲点を解消する方法
Blog クラウド

統合クラウド監視がハイブリッドITの盲点を解消する方法

現代のITは、パブリッククラウド、データセンター、コンテナ、SaaS、ネットワーク、AIサービスなど、複数の環境にまたがって運用されています。これらの環境が同じ可観測性コンテキストを共有することで、クラウド監視はより大きな価値を発揮します。これにより、チームはサービスの問題をより明確にトラブルシューティングし、クラウド支出を管理し、AIを活用した運用をサポートできるようになります。
2026 年 9 月 30 日
さらに詳しく
WebMCP監視：AIエージェントにとってウェブサイトの稼働時間だけでは不十分な理由
Blog WebMCPモニタリング

WebMCP監視：AIエージェントにとってウェブサイトの稼働時間だけでは不十分な理由

ウェブサイトが正常に見えていても、AIエージェントが誤動作する可能性があります。WebMCPのモニタリングでは、ツール検出からバックエンド応答まで、エージェントの動作全体を検証するために合成テストがどのように使用されるかをご覧ください。
2026 年 9 月 18 日
さらに詳しく