Well-Architected Framework

Well-Architected Framework とは

AWS Well-Architected Framework は、AWS のベストプラクティスに基づいてワークロードを評価 / 改善するための 6 本柱のフレームワークである。

中身は柱ごとの設計原則と、それを確かめるための質問の集まりである。準拠を証明する認証制度ではないし、質問に答え切ったからといって障害やコスト超過が起きないことが保証されるわけでもない。得られるのは「どの観点を検討し、どこを意図的に諦めたか」を言語化した記録であり、価値は判断の理由を後から読み返せる形で残す点にある。当初は 5 本柱で、持続可能性が 2021 年 12 月 2 日に追加されて 6 本になった (2026 年 8 月時点の構成)。

6 本柱

柱は互いに独立していない。信頼性を上げれば冗長化の費用が増え、検査を厚くすればパフォーマンスを削る。どの柱を優先するかを先に決めておかないと、出てきた指摘を全部つぶそうとして手が止まる。

Well-Architected レビュー

レビューはワークロードの登録から始まる。ワークロードは評価の単位で、通常は 1 つのシステムやサービスに対応させる。

# AWS Well-Architected Tool にワークロードを登録する
aws wellarchitected create-workload \
  --workload-name "My App" \
  --description "注文 API と管理画面" \
  --environment PRODUCTION \
  --aws-regions ap-northeast-1 \
  --review-owner "platform-team@example.com" \
  --lenses wellarchitected

--description と --lenses は省略できない。さらに API の仕様として、--aws-regions か --non-aws-regions のどちらかは必須であり、--review-owner も一覧上は任意に見えるが実際には指定が求められる。名前と環境とレンズだけを渡した形はコマンドとして通らないので、手元の例をそのまま流す前に必須項目を確認する。

登録したワークロードには質問の一覧が結び付き、回答を進めると未対応のベストプラクティスが改善計画として並ぶ。レビューの成果は並んだ一覧そのものではなく、対応しないと決めた項目にその理由を書き残せたかどうかで決まる。

柱ごとのチェックリスト

最初の一周で見る項目を、柱ごとに 1 つずつ挙げる。

この形の項目は、判断の基準を決めないまま並べると「はい」を埋める作業に化ける。最小権限は付与した時点の設計ではなく、使われていない権限の棚卸しで確かめる。メモリサイズの「適切」は実行時間と単価の積で比べて初めて言える (メモリを増やすと単価は上がるが実行時間が縮んで総額が下がる場合がある)。アラームは設定の有無ではなく、鳴ったときに誰が何をするかまで決まっているかで見る。

Well-Architected Tool

AWS コンソールの Well-Architected Tool で、質問に回答しながらワークロードを評価し、改善点を特定できる。ワークロードを定義すると Well-Architected Framework のレンズが自動で適用され、そこに別のレンズを重ねられる。レンズは評価の切り口で、それぞれが独自の質問 / ベストプラクティス / 改善計画を持つ。AWS が作成 / 維持する公式のレンズ (Lens Catalog) のほかに、自組織の柱と質問を定義したカスタムレンズも作れる。1 つのワークロードに適用できるレンズは 20 個までである。

レンズを増やせば質問は増えるが、埋めること自体が目的になると効果は薄れる。まず自動で適用されるレンズだけで一周し、指摘が集まった柱に関係するレンズを後から足す方が続けやすい。

Well-Architected Framework の理解を深めるには関連書籍が参考になる。