ちょっと話題の記事

[新サービス]インシデントからの復旧を有人でサポートしてくれるAWS Incident Detection and Responseがリリースされました

新サービスのAWS Incident Detection and Responseの紹介です。一言でいうと、大規模でビジネスクリティカルなシステムのレジリエンスを確保するAWSの有人サポートといった感じだと思います。
2022.09.23

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、インシデント対応の準備してますか?(挨拶

今回は新しくリリースされたAWS Incident Detection and Responseについて紹介します。

AWS Enterprise Support launches AWS Incident Detection and Response

概要

AWS Incident Detection and ResponseはAWSエンタープライズサポートを利用しているユーザーが利用できる追加のサポートサービスです。リリース文章では以下のに説明されています。

クラウドでワークロードを安全に運用するための強力な基盤を確立するには、適切なワークロード メトリックを追跡する監視可能な環境を用意することが重要です。AWS Incident Detection and Response は、ワークロードの信頼性と優れた運用性を確認することから始まります。AWS の専門家がお客様と協力して、重要なメトリクスとアラームを定義します。これにより、ワークロードのアプリケーションとインフラストラクチャ レイヤーの可視性が向上し、インシデント発生時に問題を簡単に見つけて優先順位を付けることができます。AWS インシデント管理エンジニア(AWS Incident Management Engineers / IME)は、お客様のワークロードを継続的に監視し、重大なインシデントを検出し、適切な AWS エキスパートとのコール ブリッジでお客様を関与させて、ワークロードの復旧を加速します。すべてのインシデントは最高レベルの重大度とエスカレーションで管理され、AWS はインシデントが解決されるまで関与し続けます。

残念ながらすぐにこのサービスを受けることは簡単ではなさそうなので、実際に利用することはできていませんが、イメージとしてはAWS Shield Advanceに近いものである印象を受けました。

AWS Shield Advanceは高度なDDoS保護とともに、AWSのShieldレスポンスチーム(SRT)という組織が24時間年中無休でこれを支援してくれます。高度なDDoSの対応は一筋縄では行かないため、有人で知見のあるメンバーがサポートに入ってくれることは大変心強いです。

AWS Incident Detection and ResponseではAWS Incident Management Engineers(IME)が重大なインシデントの対応に入ってくれるということで、こちらも頼もしいですね。

現状ではAWSマネジメントコンソール上にサービスの画面は見受けられませんでした。

料金は現状英語版のAWSサポートのよくある質問で確認することができます。以下のような体型になっています。

  • 月額最低7,000USD + サブスクライブしたAWSアカウントの月間使用量の2.0%
  • 最低期間90日

AWS Incident Detection and ResponseはAWSサポートケースでbilling caseを作成することでサブスクライブできます。

対応リージョンは下記の通り。

  • 米国東部 (オハイオ)
  • 米国東部 (バージニア北部)
  • 米国西部 (オレゴン)
  • 米国西部 (北カリフォルニア)
  • カナダ (中部)
  • ヨーロッパ (フランクフルト)
  • ヨーロッパ (アイルランド)
  • ヨーロッパ (ロンドン)
  • ヨーロッパ (パリ)
  • ヨーロッパ (ストックホルム)
  • アジア パシフィック (ムンバイ)
  • アジア パシフィック (東京)
  • アジア パシフィック (シンガポール)
  • アジア パシフィック (ソウル)
  • アジアパシフィック (シドニー)
  • 南米 (サンパウロ)

できることを読み取る

利用できるものがないのでドキュメントから色々読み取ってみます。全般としてはサービス紹介ページの以下の図がわかりやすいです。

まずはサービス利用開始時とインシデント発生時に分けてみていきます。

サービス利用開始時

よくある質問には下記のように書かれています。

Q.個々のワークロードをサービスにオンボードするにはどうすればよいですか?

ワークロードのオンボーディングは、ワークロードを構成する構成アカウントが AWS Incident Detection and Response にサブスクライブされた後に開始されます。ワークロードのオンボーディング プロセスの焦点は、共有したいワークロードに関するコンテキストを AWS ができるだけ多く収集することです。これには、ワークロードで使用されるサービスの ARN と機能、およびワークロードの結果を示す重要なアラームが含まれる場合があります。また、オンボーディング プロセス中のインシデント管理のランブックと対応計画も作成します。

要点を解釈して書き出すと以下のようになります。

  • 対象となるワークロード(自分たちのサービスやシステム)のAWS環境のリソースやどのようなワークロードかをAWSに共有する
  • ワークロードの重要なアラームを共有する
  • AWSはインシデント管理のランブックや対応計画を作成する

重大なインシデントに対する対応をすぐできるようにすることが目的のサービスであるため、AWSがワークロードについて詳細に理解する必要があることが読み取れますね。特に重要な点はアラームの設定で、この重要なアラームのトリガーから15分以内に対応が行われます。

インシデント発生時

よくある質問には下記のように書かれています。

Q. インシデント発生時にどのように関与しますか?

ワークロードでトリガーされた重大なアラームは、イベント ブリッジ経由で AWS インシデント管理ツールに送信され、オンコールのインシデント管理エンジニア (IME) に通知されます。IME はアラームのトリアージを行い、会議ブリッジにあなたを参加させ、事前に確立されたインシデント管理対応計画に従って復旧に導きます。通話中に実行されるアクションには、たとえば、AWS サービスの状態に関する最新の洞察を提供する、AWS 内でエスカレーションをトリガーする、解決を促進する方法についてアドバイスするなどがあります。IME はインシデントを管理し、インシデントが解決または軽減されるまで、適切な AWS リソースに関与し続けるようにします。インシデントが終結すると、IME は、インシデントを要約し、アプリケーション アーキテクチャ、メトリック、および対応手順の改善を通知するインシデント解決レポートを提供する場合があります。AMS のお客様の場合、オペレーション エンジニアはインシデント管理プロセスにも関与して、インシデントの解決を支援します。

読み取って解釈すると下記のようになります。

  • 重大なアラームがトリガーされるとIMEがこれを検知する
  • IMEがアラームのトリアージを行う
  • 利用者がオンライン会議に呼ばれる
  • 事前に用意した対応計画に従って復旧する
  • 必要に応じAWS内部のエスカレーションを実施する
  • IMEはインシデントを管理し解決や軽減まで関与する
  • インシデントのクローズ後レポートを提供する場合がある

また、AWSサービスに発生しているイベントについても下記のように言及があります。

Q.AWS のサービスイベント中に、AWS Incident Detection and Response はどのように役立ちますか?

サービス イベント中、AWS は、ワークロードが影響を受けるかどうかに関係なく、進行中のサービス イベントについて通知します。ワークロードがサービス イベントの影響を受ける場合、AWS はサポート ケースを作成して関与させ、影響と感情に関するフィードバックを受け取り、イベント中に災害復旧計画を呼び出すための事前に決定されたガイダンスを提供します。また、AWS Health を介して、作成されたサポートケースの詳細を含む通知を受け取ります。AWS が所有するサービス イベントの影響を受けていないお客様 (たとえば、別の地域で運用している、障害のある AWS サービスを使用していないなど) は、引き続き標準的な契約でサポートされます。

  • AWSサービスに発生しているイベントがワークロードに影響があるかに関係なく進行中のイベントを通知する
  • 影響がある場合はAWSがサポートケースを作成し、
    • そのインパクトや温度感のフィードバックを受け取る
    • 利用者のディザスタリカバリ計画を実行するための事前に定めたガイダンスを提供する

この文面から推測すると、インシデントの要因にAWSサービス自体の障害が絡んでいる可能性がある場合にも、通常のAWS Healthを介した情報提供より早く情報を受け取れ、またこれと紐付けて対応してくれそうに見えます。

特にビジネスクリティカルなワークロードを持っている場合には利用価値が高そうです。

その他

他にもいくつか気になるよくある質問を抜粋します。

Q.AppDynamics/New Relic/Dynatrace/Signal FX/Data Dog を使用して、すべてのワークロードのワークロード監視を計測しました。AWS Incident Detection and Response を既存のモニタリングツールで使用できますか?

現在、AWS Incident Detection and Response は AWS CloudWatch アラームのみをサポートしています。

現状では重大なアラームはCloudWatchベースのみのようです。

Q.AWS Incident Detection and Response を使用して、ワークロードの重大なケースを自分で提起することはできますか?

はい、自分で重大なケースを提起することはできます。重大なケースは、既存のプロセスを使用して管理され、AWS エンタープライズ サポートの標準的な応答時間目標の対象となります。

基本は重大なアラームをトリガーとしていますが、利用者から既存のエンタープライズサポート経由でトリガーできる、とも読み取れます。(一般的なサポート経路の案内のみ、かもしれませんが)

Q.AWS Incident Detection and Response を使用して、引き続き独自のモニタリングチームを維持する必要がありますか?

AWS Incident Detection and Response は、モニタリング チームに取って代わるものではありません。AWS Incident Detection and Response は、モニタリング チームと協力して機能し、重要なインシデントの管理に重点を置いています。

既存のモニタリングを置き換えるものではないという点は重要ですね。

言語について

特に対応言語について記述がありませんでした。

AWS Shield Advancedも英語のみであることから、AWS Incident Detection and Responseでも英語のみと考えるのが自然だと思います。

まとめ

新しくリリースされたAWS Incident Detection and Responseについて調査してみました。

一言でいうと、大規模でビジネスクリティカルなシステムのレジリエンスを確保するAWSの有人サポート、といった感じでしょうか。高価なサービスではありますが、その分AWS自体に起きている問題まで含めて迅速に把握や対応が可能になります。

ちなみに私は最初にこのサービス名を見たときに、セキュリティ領域におけるインシデントレスポンスを支援するサービスなのかと思いましたが、そういうわけではなさそうですね。

ここぞという環境で利用を検討してみてはいかがでしょうか?