お久しぶりです、きおかです。
今回はAWSサービスそのものの障害検知方法をご紹介します。
AWS責任共有モデルと障害検知
AWS責任共有モデルに従って、障害検知は大きく２つに分けられます。
（AWS『責任共有モデル』より）
１つはAWS利用者側が自分たちで行う障害検知。
もう一つはAWS の “クラウドのセキュリティ” 責任部分の障害検知。
前者は自分たちで監視サービスなどを用いて設定します。が、後者は利用者側で設定はしません。例えばですが、Code Buildがドキュメント通りの動作をしない場合に、何が起こっているかわかりません。
そこで、AWS Health DashboardのOpen and Recent Issues又はService Historyの出番です。
AWS Health Dashboard
AWS Health DashboardのOpen and Recent IssuesとService HistoryはAWSアカウントを持っていなくてもアクセスして閲覧できます。
(URL: https://health.aws.amazon.com/health/status)
ちなみに2023年9月5日時点では日本語ページは存在しません。即時アラートのためか、対応が難しい部分があるんですかね。https://...on.com/jp/health/statusでも確認できませんでした。
Open and Recent Issues
現在障害発生中・対応中のものが表示されます。
PDT(Pacific Daylight Time)で表示されるので、日本時間(JST: Japan Standard Time)だとこれに16時間を足します。
直近は発生していないので画面キャプチャを載せられないのが残念ですが、障害が発生しないことは素晴らしいことなので一旦割愛させてください。キャプチャ取れたら更新しますね。
Service History
Service Historyでは、直近１年間分のステータス・検知内容を閲覧することができます。
試しに2023年9月3日(PDT)にあった、Route53リゾルバのアラート（実際はAWSからの対応報告ですが、便宜上アラートや通知と呼びます）を見てみます。
アラート例： Route 53 Resolver VPC Query Logs delayed/duplicated
通知時間が古い順（通知が届いた順、AWS側の対応順と同じ）で見ていきます。
アラートレベルがInformationalなので、大きなエラーではないようです。
8:41 AM PDT Route 53 Resolver VPC Query Logs for instances in the usw2-az1 Availability Zone in the US-WEST-2 Region from 5:30 AM PDT are not being delivered to customers. This is due to an impairment in the system that de-duplicates these logs. To mitigate this issue, we are disabling this de-duplication system, and all delayed log messages will be delivered to customers, however these will potentially include duplicate log entries. We are actively working on mitigating the impairment to the de-duplication system, and will provide an update within the next 30 minutes. This issue is only affecting query logs. All DNS queries are being answered normally, and are not impacted by this issue.
「PDT 09/04 8:41 AM、日本時間で09/05 0:41 AMに通達。
US-WEST-2リージョン（オレゴン州）のusw2-az1アベイラビリティゾーンにて、5:30 AM PDT(以下、JST変換は省略)以降、Route53リゾルバでのVPCクエリログ（詳しくはAWS公式ブログ参照）がユーザーに届かなくなった。原因はVPCクエリログの重複を削除するシステムの損傷で、影響緩和のために当該システムを停止しており、それにより遅延したログがユーザーに届くが、同時に重複したログも届く可能性がある。当障害の影響を緩和すべく現在奮闘しており、次の進捗状況を30分以内に送る。当案件の影響はクエリログのみ。DNSクエリの応答は全て平時通り動いており、当案件による影響はない。」
という感じです。他の通知もそうですが、トリガーや原因、影響や対応状況などコンパクトにまとめられて読みやすいです。clearでsimpleで故にconciseな文章で読んでいて心地よい、お手本のような文章構成で参考になります。
…
（。。結構長いので間のものは割愛させてください。。）
…
6:12 PM PDT All Route 53 Resolver VPC Query Log messages that had been delayed have now been delivered. We have also addressed the issue with our system that prevents duplicate messages. Only a single log entry is being delivered now for every logged DNS query.
「PDT 09/04 8:41 AM、日本時間で09/05 0:41 AMに通達。
遅延していたRoute53リゾルバVPCクエリログは、現在全て配信済み。重複排除システムの損傷も解決し、現在はDNSクエリ一つに対して単一の（重複のない）ログエントリが配信されている。」
同じく簡潔で綺麗な論理でつながり、読みやすいです。
このような感じで、AWSサービス自体に障害が起きた場合、より正確にはAWS側の責任範囲の障害の場合、AWS Health Dashboardを利用することで障害の詳細や対応状況を確認することができます。
ちなみにリージョン毎の各サービスの通知をRSS配信で確認できます。
例えば東京リージョンのAPI Gatewayの状況を確認するには、こちらにアクセスすることで、XML形式のままですがよりすばやく確認できます。
余談：RSS配信について
僕も軽く調べた程度ですが、記事のサマリなどメイン情報をサイトにアクセスすることなく低コストで得る通信方法の一つみたいです。基本的にサイトURLに/rssや/feedを付加して実装することが多いみたいです。
もしAWSアカウントを作るまではいかないが特定のAWSサービスのステータスを認知したい、という場合があれば、適当なRSSフィードのURLを指定して、定期的に情報を取得しにいくようなものを作れば実現できそうです。
さいごに
AWSサービスの障害検知（認知？）方法のご紹介でした。
AWS Health DashboardはAWSアカウントでログインすれば、自身が利用しているサービスに影響があるもので絞り込んで確認することもできます。
常時稼働しているものに関しては特に注意を払って確認したいですね。
私事ですが、７月からプロジェクトに配属されたのでしばらく現場の文化や体制のキャッチアップにリソースを割いてましたが、これからまた少しずつ投稿していければと思います。