アラフィフ未経験転職者6年生の…「いとあたらし」です。
当初は慣れない操作等に苦労しましたが、周りの方には面倒見のいい方が多く、いろいろな経験を積むことができ、かなり慣れる事ができました。
業務中の空き時間には自己学習も可能な環境ですので、パソコンの操作や、処理の待ち時間が苦にならない人には、非常にいい職場だと思います。
はじめに
前回では、無料の生成AIだけで、マウス操作で遊べるインベーダーゲームもどき…などを作ってみました！という内容をブログ化してみましたが、今回のブログは、最近有ったAWSの大規模障害を踏まえまして…AWS障害発生時の具体的な確認方法と対応方法についてです。(*’ω’*)
ちなみに、以下のリンク先に過去私の作成したブログのリンクを記載しておきます。
まだ見ていない方はこちら(特にハンズオン)↓も是非見てみてもらえますと嬉しいです。
尚、本ブログは以下のサイトのAWS初心者向けハンズオン資料の該当項目を、本当に初心者(;^ω^)が実践した経過の記録となっています。
なんといっても、講義の視聴だけなら現在は無料で利用できる素晴らしい動画になっています。
※ハンズオンでAWSを実際に使用する費用は、必要です。
AWS Hands-on for Beginners とは
・実際に手を動かしながらAWSの各サービスを学んでいただきます。
・初めてそのサービスを利用される方がメインターゲットです。
・お好きな時間、お好きな場所でご視聴いただけるオンデマンド形式。
・学習テーマごとに合計1～2時間の内容＆細かい動画に分けて公開されておりますので、スキマ時間の学習や、興味のある部分だけの視聴も可能。
では、いよいよこれよりAWS障害発生時の具体的な確認方法と対応方法についてを進めて参ります。
割と最近の事となりますが…2025年10月20日にAWSにて大規模障害が発生する事態が発生しました。今後何らかの事態の発生は避けられない事でもありますので、そういった事態が発生しても慌てず冷静に対応できるよう事前に確認方法を調べてみました。
クラウドインフラとして広く利用されているAmazon Web Services（AWS）ですが、万が一障害が発生した場合、迅速かつ適切な対応が求められます。本記事では、AWS障害が疑われる際に現場で実施すべき具体的な確認手順と、その対応方法をステップ形式で紹介します。
尚、2025年12月3日のAWSのイベントで、以下のリンクの［速報］AWS、障害が発生すると人間より先にAIが調査分析、対処法まで報告「AWS DevOps Agent」プレビュー公開という発表が有りましたので、今回のブログ内容はいずれ必要無くなってゆくのかも知れません。
障害の有無を確認する
まずは、障害が本当にAWS側で発生しているのか、それとも自社システムの問題なのかを切り分けます。
2.1 AWS Service Health Dashboardの確認
AWS公式のService Health Dashboard（SHD）を確認しましょう。ここでは、各リージョンごとのサービスのステータス（正常・注意・障害）がリアルタイムで表示されます。
2.2 Third-party監視ツールの活用
Datadog、PagerDuty、Statuspageなどの外部監視サービスも、AWSの障害情報を即座に通知してくれる場合があります。特に、複数のリージョン・サービスをまたいで運用している場合に有用です。
サードパーティ監視ツールについて
・DataDog
Datadogとは、クラウドアプリケーション向けの監視・セキュリティプラットフォームです。インフラストラクチャ監視、アプリケーションパフォーマンス監視（APM）、ログ管理などの機能を統合し、システムのパフォーマンスやセキュリティの問題をリアルタイムで一元的に監視します。SaaS（Software as a Service）形式で提供され、AWSやAzureなどのクラウド環境と連携できます。
・PagerDuty
PagerDutyとは、システム障害発生時などに、関連アラートを自動的に検知・分類し、担当者への通知、対応フローの自動化までを一元管理するインシデント管理プラットフォームです。システム監視ツールなど多くの外部サービスと連携し、迅速なインシデント対応を実現することで、システム障害時のダウンタイムを最小限に抑え、運用を効率化します。
・Statuspage
Statuspageとは、サービス提供企業が障害やメンテナンスなどのインシデント発生時に、ユーザーへリアルタイムで状況を通知するためのコミュニケーションツールです。システムの稼働状況を一元管理し、メールやSMS、Webサイトへの埋め込みなど、様々な方法でユーザーに共有できます。これにより、顧客の信頼性を高め、問い合わせを削減する効果が期待できます。
自社システムの影響範囲を把握する
AWS障害が確認されたら、自社システムへの影響をすばやく特定します。
- どのAWSサービスが影響を受けているか？（例：EC2、RDS、S3、Lambdaなど）
- どのリージョンで障害が発生しているか？
- どのアプリケーション・ユーザーが影響を受けているか？
この段階では、CloudWatchのアラームやログ、トレーシング（X-Ray）などの監視情報を活用すると効率的です。
代替措置（Workaround）の検討と実施
障害が長引く可能性がある場合は、代替措置を講じる必要があります。
4.1 マルチリージョン構成の活用
マルチリージョンでアプリケーションを構成している場合、トラフィックを正常なリージョンに切り替えることでサービスを継続できます。Route 53のフェールオーバールーティングポリシーなどが有効です。
4.2 キャッシュやローカル処理の活用
一時的にS3やDynamoDBにアクセスできない場合、CloudFrontやアプリケーション側のキャッシュを活用して、一部の機能を維持することも検討しましょう。
4.3 オートメーションによる障害対応
事前にAWS Systems Manager AutomationやLambdaによる障害対応スクリプトを準備しておくと、手動操作なしで復旧を促進できます。
💡 ポイント： 実際に障害が発生してから代替措置を考えるのは遅すぎます。平常時から「障害発生時の対応フロー」や「復旧手順書」を整備しておきましょう。
AWSサポートへの連絡
Developer(平日9:00～18:00:12時間)或いは、Business(24H年中無休:最短1時間以内)またはEnterprise(24H年中無休:最短15分以内)のサポート契約を結んでいる場合、AWSサポートに障害情報を報告し、状況の共有・エスカレーションが可能です。
連絡時には以下の情報を準備しておくとスムーズです：
- アカウントID
- 影響を受けているサービス名とリージョン
- 発生時刻と影響内容
- これまでに実施した調査・対応内容
障害復旧後のフォローアップ
障害が解消された後も、以下のアクションを忘れずに行いましょう。
- 障害報告書の作成（Postmortem:振り返り）： 原因、影響、対応内容、今後の改善策を文書化。
- アラートの見直し： 早期検知できなかった要因があれば、CloudWatchアラームやSNS通知を強化。
- 自動フェイルオーバーのテスト実施： 実際に障害時に機能するか定期的に検証。
まとめ
AWS障害への対応は、「確認 → 切り分け → 対応 → 改善」のサイクルで進めることが重要です。技術的な対応だけでなく、組織としての備え（ドキュメント・訓練・監視体制）が、ダウンタイムを最小限に抑える鍵となります。
日頃から「障害は起きるもの」という前提でシステム設計・運用体制を整えておけば、いざという時も冷静かつ迅速に対応できるでしょう。
今回は、いつか必ず起こる事について、最低限どういう準備や対応が必要になってくるのかを調べてみました。いざという時余裕を持って対応できるようにしておきたいと思います。
余談ですが、3月に無事AIプラクティショナーに合格できました。いろいろな説が有りますが、個人的にはクラウドプラクティショナーを学習した時より難易度が高かったような気がします。何はともあれ、無事合格できて良かったです。
コメント