AWS Expert Online『AWS SAW を使ったトラブルシューティング効率化のススメ』参加レポート
2024年3月13日 に JAWS-UG 金沢さんにお邪魔させてもらって AWS Expert Online #32『AWS SAW を使ったトラブルシューティング効率化のススメ』に参加しました。
イベントでは、AWS Support でクラウドサポートエンジニアをされている古野さんが、AWS SAW(AWS Support Automation Workflows)について解説してくださいましたが、テクニカルサポートエンジニアをしていながら、AWS SAW というサービスが初見だったので、以下簡単にまとめました。
イベント公開時の詳細ページはこちら
まとめ
- AWS SAW は「ソウ」と発音すれば良いっぽい。(古野さんはソウ/ソーと呼称されていた)
- SAW(AWS Support Automation Workflows) は、これまでに AWS サポートとして解決した課題で得たベストプラクティスをもとに AWS サポートによって作成されたセルフサービスな自動化のための仕組み
- 万が一、AWS SAW を利用しても自力解決できなかった場合でも、以下の情報を証跡として提出することで、SAW の実行結果を踏まえた詳細調査をしてもらえる
- 実行した SAW (ランブック名)
- AWS Systems Manger Automation 実行 ID
- 実行後の出力内容
- AWS SAW がサービスとして存在しているのではなく、Systems Manager の Automation を利用して SAW として提供している各種調査を享受できる仕組みとなっている
公式ドキュメント等
今回のセッションではが概要やメリット、使いどころを紹介することを主目的とするため、技術的な詳細については公式資料を確認してほしいとのこと。
以下は、セッション終了後に調査した内容
AWS Black Belt 資料
執筆時点で公開されている資料は以下。
- AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Container Service(Amazon ECS) 編
- AWS SAW - セルフサービスな診断と運用の効率化 入門編
- AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service(Amazon EKS) 編
- AWS SAW – セルフサービス自動化ランブックを使用したトラフィック監視の視覚化 Amazon Virtual Private Cloud (Amazon VPC) 編
- AWS SAW - 旧世代から最新世代 (AWS Nitro System 世代) への移行タスクの自動化 Amazon Elastic Compute Cloud (Amazon EC2) - Linux 編
- AWS SAW - セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud (Amazon EC2) - Windows 編
サービス紹介ページ
ページ中ほど以降に「ユースケース」セクションがあり、この部分を「ランディングページ」とおっしゃっていた。
AWS ドキュメント
以下の Systems Manager Automation の runbook reference 中で、名称のプレフィックスに「AWSSupport-」を持つものが、AWS SAW に相当する。
セッション中で紹介されていた事例
「AWS Systems Manager を利用しているが、EC2 インスタンスがマネージドノードとして登録されていない」という問題を考えた場合以下のようなハードルが考えられる。
- SSM やマネージドノードに対する理解(仕組み自体)が必要
- 問題被疑箇所をそれぞれ確認していく時間が必要
また、調査を行う場合にも以下のような- どこから調査をするのか?
- 権限?
- ネットワーク?
- インスタンスの設定?
また、別で用意されている AWSSupport-CheckXenToNitroMigrationRequirements の SAW を実行すれば、Xenから Nitro へのインスタンスタイプ変更するための前提条件を満たしているか確認できる、など現時点(2024-03-13)で約 80 のシナリオが用意されている。
AWS SAW のメリット
AWS SAWによるトラブルシューティングのメリットは大きく以下
-
簡単に実行が可能
-
自動チェックによる調査時間短縮
-
手動チェックミスの防止
また、発展した使い方として「問題の検知ができるもの」であれば、SAW を「自動的に実行」、さらに「問題時には通知」するというアーキテクチャを実装することも可能。
Slack などへの通知を行うことで、コンソールを確認せずに問題の把握と、対処方法の確認をするような仕組みを作ることもできる。
開催中に出ていた質問
- Automation AssumeRoleをつければ実行できるということは、参照のみのユーザーでも実行可能になるのでしょうか。その設定ができる権限だけはつけていないといけないのでしょうか。
- SSMドキュメント実行権限と各種ReadOnly権限程度があればSAWは実行できるでしょうか?それともかなり強い権限が必要ですか?
- 仕組みとしては SSMの Automation から各種 APIを実行しているため、SSM Automation として実行しようとしている SAW(ランブック)に依存する。
- 詳細は、それぞれの SAW の説明欄に要求される API アクションが明記されているので、それを確認してほしい。
- 目的に応じたSAWを探すのが難しいように思えたのですが、ランディングページから探すのが一番簡単なのでしょうか?
- 古野さん個人的には、ランディングページから探すのが最もやりやすいのではないかと感じている。
- AWS パートナー企業でテクニカルサポートエンジニアをしています。リセールでのアカウントをご利用いただいているエンドカスタマー様でも SAW をご利用いただいても良いでしょうか?今回ご説明いただいた内容を拝見した限り、SAW の利用で一気通貫でサポートケース起票までは進まない認識をしています。
- SAW では自動実行での各種調査は行うが、ケース起票まではしないため、問題なさそう。
- Organizations全体で集約して使うことはできますか?
- 質問の内容が抽象的なため即断ができないが、やってみないとわからない
- 特定のアカウントからのみ SAW を実行するようなことを想定しているのであれば、前述の通り内部的には Systems Manager の Automation を実行しているので、実行する SAW で動作する各種 AWS API の実行をクロスアカウントで許可するようなポリシーを持つ IAM エンティティで実行すれば実現可能なように思えるが、即答はできない。