AWS Well-Architected Tool 使ってAWS環境のアセスメントしてみた
製造ビジネステクノロジー部の小林です。
最近、お客様の AWS 環境をアセスメント（評価・分析）する機会がありました。
そのときは使う場面がなかったものの、以前からずっと気になっていた AWS Well-Architected Tool。今回、手元のワークロードを題材にひととおり点検してみました！
AWS Well-Architected Tool とは
AWS Well-Architected Tool（以下 WA Tool）は、AWS Well-Architected Framework のベストプラクティスに沿って、自分のワークロードを点検できるマネージドサービスです。
用意された質問に答えていくと、リスクの高い箇所を洗い出してくれて、そこに対する改善のヒントまで提示してくれます。
点検の軸になるのが、フレームワークの 6 つの柱です。
- 運用上の優秀性（Operational Excellence）
- セキュリティ（Security）
- 信頼性（Reliability）
- パフォーマンス効率（Performance Efficiency）
- コスト最適化（Cost Optimization）
- 持続可能性（Sustainability）
標準の AWS レンズに加えて、自分たちの基準を質問として組み込んだカスタムレンズも使えます。ここでは初回ということもあり、標準の AWS Well-Architected Framework レンズだけを使います。
WA Tool 自体は追加料金なしで使えます。
ワークロードを定義する
コンソールで WA Tool を開いて、ワークロードの定義に進みます。
「プロパティを指定」画面で、まずは必須項目を埋めていきます。
続いて所有者・環境・リージョンを指定します。
- レビューの所有者: レビュープロセスを取りまとめる個人やグループ。名前でもメールアドレスでも識別子でも大丈夫です。
- 環境: 「本番稼働」か「本番稼働前」かを選びます。今回は検証なので本番稼働前にしました。
- リージョン: ワークロードが動いている AWS リージョンを選びます。今回は東京（ap-northeast-1）を指定しました。AWS 外で動いている場合は「AWS 以外の領域」にその名前を入れられます（最大 5 つ、各 25 文字まで）。
ここから下は任意項目です。アカウント ID（最大 100 個）やアプリケーション ARN、アーキテクチャ設計の URL などが並びます。初回はいったん空のまま進めて問題ありません。
さらに下には Trusted Advisor 連携や Jira 連携、タグの設定もあります。Trusted Advisor をアクティブ化すると、入力した AWS リージョンとアカウント ID をもとに、質問の判断材料になる情報を自動で集めてくれます。今回はどちらもオフのままにしました。
次のプロファイル適用のステップも今回は使わないので、そのまま「次へ」で進みます。最後にレンズの選択画面で、標準の AWS Well-Architected Framework レンズが選ばれた状態になっているのを確認して、「ワークロードを定義」で保存します。
保存できたら「レビューの開始」でレビューを始められます。
質問に答えて状態を記録する
レビューを始めると、選んだレンズの質問がずらっと出てきます。質問は先ほどの 6 つの柱にまたがっていて、それぞれについて「今どのベストプラクティスを実践できているか」をチェックしていく形です。
進め方のコツというか、迷ったときの判断材料を書いておきます。
- 各項目の「情報」を押すと、右側にそのベストプラクティスの説明と参考リソースが出ます。用語がピンとこないときはここを読むと早いです。
- 「エキスパートに質問」からは AWS re:Post の Well-Architected コミュニティに飛べます。設計や運用で疑問が出たときの相談先として覚えておくと便利です。
- 「この質問はワークロードに適用されない」や「該当なし」を選ぶときは、メモ欄に理由を書いておくのがおすすめです。あとで自分が見返したときに助かりますし、レポートにも残ります。
途中でやめたくなったら「保存して終了」でいつでも中断できます。再開するときは「ワークロード」から対象を開いて「レビューを続行」で続きに戻れる、という流れです。全部答え終えると、ワークロードの概要ページが表示されます。
マイルストーンを保存してレポートを出す
初回のレビューが終わったら、その時点の状態を「マイルストーン」として保存しておきます。マイルストーンは今の状態のスナップショットで、あとで改善したときに「どれくらい良くなったか」を比べる基準になります。同じワークロードに複数のマイルストーンを残して、あとから比較することもできます。
「ベータ版」という名前で保存してみました。
あわせて、レンズを選んで「レポートの生成」を押すと、点検結果をまとめた PDF を出力できます。ワークロードの状態、見つかったリスクの数、改善の候補が一枚にまとまるので、チームに共有するときに便利です。
改善計画でリスクを見る
チェックした内容をもとに、WA Tool が高リスク・中リスクの箇所を洗い出してくれます。概要ページの「レンズ」から AWS Well-Architected Framework レンズを開いて、「改善計画」を見にいきます。
まずダッシュボードの上部に、全体のサマリーが並びます。今回の私のワークロードでは、回答した時点で高リスクの問題が 11 件、中リスクの問題が 13 件という結果でした。まだ 57 問中 27 問しか答えていない状態なので、埋めていけばもう少し増えそうです。
その下には、6 つの柱ごとにリスクの内訳を示す棒グラフが出ます。今回は運用上の優秀性が高リスク 5・中リスク 5 と飛び抜けていて、逆にセキュリティは 0 件でした。どの柱が弱いのか一目でわかるので、どこから手を付けるか考える材料になります。
改善項目には、リスクが見つかった質問が並びます。柱の絞り込みやリスクレベルでの絞り込みができるので、たとえば「高リスクの問題」だけに絞って上から潰していく、という進め方ができます。各項目のリンクを開くと、その質問に対する具体的なベストプラクティスと、詳しいガイドが出てきます。
改善のステータスは、ワークロードの「プロパティ」タブにある「ワークロードのステータス」から変えられます。まだ手を付けていないうちは「未開始」にしておくと、あとで進み具合を追いやすくなります。
改善を反映して測り直す
あとは、洗い出されたリスクに対して実際に手を入れて、その結果をツールに反映していきます。たとえば監視が足りていない、という指摘に対して Amazon CloudWatch や Auto Scaling を足す、といった具合です。
対応できたら、改善項目から該当の質問を開いて、実践できるようになったベストプラクティスにチェックを付け直します。メモ欄に何をやったか書いておくと、あとで経緯がわかって助かります。
「保存して終了」で状態を更新したら、もう一度改善計画に戻ってみます。実践したベストプラクティスが増えていれば、その分だけ高リスク・中リスクの件数が減っていきます。
ここで再びマイルストーンを保存しておくと、「マイルストーン」から初回との差を並べて見られます。数字として改善が見えると、ちょっとうれしくなります。
触ってみて感じたこと
一回で完璧に埋めようとしないほうがいいです。わからない質問は Info を読みつつ、判断がつかなければ Notes に「保留」とだけ書いて先に進めるくらいがちょうどいいと思います。
マイルストーンは面倒でもこまめに残しておくと、あとで「ここで良くなった」が見えて振り返りが楽になります。
まとめ
AWS Well-Architected Tool を使って、ワークロードの定義からレビュー、改善計画の確認まで触ってみました。追加料金もなく、質問に答えていくだけで自分のシステムの弱いところが見えてくるので、設計を見直すきっかけとしてかなり手軽です。
ただ、6 つの柱を全部いっぺんに直そうとすると息切れするので、高リスクから 1 つずつ潰していくほうが続けやすいです。
この記事がどなたかの参考になれば幸いです。
