はじめに
CLF-C02の問題集を解いていて、「6つの〇〇」と聞かれた瞬間にAWS CAFの6つのパースペクティブを答えてしまい、正解はWell-Architected Frameworkの6つの柱だった、ということが立て続けに2回ありました。どちらも「6つ」で始まるので、名前だけで覚えていると区別がつかないんです。それがきっかけで、公式ドキュメントの現行版（2024年11月6日発行）を頭から読み直し、柱・設計原則・ベストプラクティス領域の数を自分で数えました。この記事はその整理です。
忙しい人向けに結論を先に置きます。
| 問い | 答え |
|---|---|
| 何を評価するのか | 個々のワークロード（組織ではない） |
| 柱はいくつか | 6つ。運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性 |
| AWS CAFとの違い | CAFは組織の準備状況、Well-Architectedはワークロードの設計。階層が違う |
| レビューとは何か | 監査ではなく、設計判断について建設的に話し合う場 |
| 試験で問われる道具 | AWS Well-Architected Tool（Trusted Advisorとは別物） |
対象読者: CLF-C02 / SAA-C03 の受験を控えている人、AWSを触り始めて設計レビューの共通語彙が欲しい人。実際のワークロード改善事例ではなく、フレームワークの構造を正確に押さえることを目的にしています。
参考文献
この記事は次の公式ドキュメントの整理です。先に一次情報を置いておくので、正確な文言が必要な人はこちらへ。いずれも2024年11月6日発行版を参照しました。
Well-Architected Frameworkは何を評価するのか
AWS Well-Architected Frameworkは、AWS上に構築したワークロードの設計を評価するための共通の物差しです。ここで言うワークロードとは、ビジネス価値を生む一連のコンポーネント（アプリケーション・データ・インフラ）のまとまりを指します。
なぜ物差しを固定する必要があるのか。「動いているから良い構成だ」という判断は、動かなくなるまで問題を見せません。加えて、構成の良し悪しを個人の経験則で語ると、レビューのたびに論点がズレます。ある人はコストを、別の人は障害耐性を、また別の人は運用の手間を見ていて、同じ構成図から別の結論を出す。心当たりはありませんか？
このズレを防ぐために、AWSは評価軸を6つの柱に固定しました。AWSのソリューションアーキテクトが多数の顧客アーキテクチャを設計・レビューしてきた経験から抽出したベストプラクティスを、一貫した手順で自分のアーキテクチャに当てられる形にまとめたものです。
公式ドキュメントのIntroductionには、次の一文があります。
The process for reviewing an architecture is a constructive conversation about architectural decisions, and is not an audit mechanism.
（アーキテクチャをレビューするプロセスは、アーキテクチャ上の決定について建設的に話し合うものであり、監査の仕組みではありません）
この一文が、後で触れる「柱同士の綱引き」と「WA Toolの使い方」の前提になります。
AWS CAFとどう違うのか
| 観点 | AWS CAF | Well-Architected Framework |
|---|---|---|
| 対象 | 組織全体のクラウドを活用した変革（導入の準備状況と変革ロードマップ） | 個々のワークロード |
| 中心の問い | クラウドをやれる組織になっているか | この設計は要件に対して適切か |
| 構造 | 6パースペクティブ / 47ケイパビリティ | 6つの柱 / 設計原則 / ベストプラクティス領域 / 質問 |
| 主な使い手 | 経営層から各パースペクティブの責任者・アーキテクト・エンジニア・運用リーダーまで組織横断 | CTO・アーキテクト・開発者・運用チーム |
CAFが会社や部門の健康診断だとすれば、Well-Architected Frameworkは個々のワークロードの設計レビューです。CAFの使い手を経営層だけと思っていたのも誤解で、公式のステークホルダーにはアーキテクトやSRE、ITサービス管理者も含まれています。違いは「誰が使うか」ではなく「何を見るか」でした。片方がもう片方を包含するのではなく、扱う階層が違う道具です。
この図を描いてから、問題文に「組織」「導入」「準備状況」があればCAF、「ワークロード」「設計」「レビュー」があればWell-Architected、と読み分けるようになりました。数字ではなく対象で覚える、というだけの話なんですが、これで取り違えは止まりました。
6つの柱
柱の名前と公式定義の要点です。英語名を併記しているのは、AWS WA Toolや試験問題では英語の見出しがそのまま出ることが多いためです。
| 柱 | 英語名 | 公式定義の要点 |
|---|---|---|
| 運用上の優秀性 | Operational Excellence | ソフトウェアを正しく構築し、優れた顧客体験を一貫して届けることへの取り組み。チームの組織化、ワークロードの設計、大規模な運用、継続的な進化を扱う |
| セキュリティ | Security | クラウド技術を活かしてセキュリティを高めるために、データ・システム・資産を保護する能力 |
| 信頼性 | Reliability | ワークロードが期待されるときに意図した機能を正しく一貫して果たす能力。ライフサイクル全体を通じた運用とテストを含む |
| パフォーマンス効率 | Performance Efficiency | クラウドリソースを効率的に使って性能要件を満たし、需要や技術が変化してもその効率を維持する能力 |
| コスト最適化 | Cost Optimization | 最も低い価格でビジネス価値を届けるようにシステムを実行する能力 |
| 持続可能性 | Sustainability | 環境への影響、特にエネルギー消費と効率に焦点を当てる。リソース使用量を直接減らすための手がかりとなる |
公式ドキュメントは、ソフトウェアシステムの構築を建物の建設にたとえています。基礎が固まっていなければ構造上の問題が建物全体を損なうように、6つの柱を無視すると期待どおりに動くシステムを作ることが難しくなる、という位置づけです。
持続可能性（Sustainability）は2021年に追加された6本目の柱です。古い教材や記憶で「5つの柱」と覚えていると、柱の数を問う設問や「次のうち柱でないものはどれか」形式の設問で落とします。
フレームワークの階層構造
6つの柱はそれぞれ同じ構造で書かれています。柱の下には「設計原則」と「ベストプラクティス」が並んでいて、ベストプラクティスの側がさらに「領域」→「質問」→「個別のベストプラクティス」と枝分かれします。設計原則は考え方を示す短いリストで、質問の親ではありません。ここは最初、原則の下に領域があると思い込んで図を描き、レビューで指摘されて直しました。レビューで実際に答えるのは質問の側で、自分のワークロードがベストプラクティスからどれだけ離れているかをそこで測ります。
数を数えてみると、柱ごとの設計原則は合計36、ベストプラクティス領域は合計31でした。これに加えて、柱に属さない全体共通の設計原則が6つあります。数そのものを覚える必要はありませんが、「柱6つの下にこれだけの構造がある」と知っておくと、WA Toolで質問が大量に出てきても迷子になりません。
質問IDは柱の略号で始まります。たとえばセキュリティの柱の質問「SEC 2. How do you manage authentication for people and machines?」のように、OPS / SEC / REL / PERF / COST / SUS の接頭辞で、どの柱の質問かが分かるようになっています。
全体に共通する6つの設計原則
柱ごとの原則の前に、フレームワークは「クラウドで良い設計をするための一般的な設計原則」を6つ置いています。読んでみると、どれも「オンプレミスの制約を前提にした習慣を捨てる」という一点で共通していました。
| 原則 | 英語名 | 要点 |
|---|---|---|
| キャパシティを推測しない | Stop guessing your capacity needs | 必要な分だけ使い、自動でスケールする。過剰な遊休リソースも、容量不足による性能劣化も避ける |
| 本番規模でテストする | Test systems at production scale | 本番と同じ規模のテスト環境をオンデマンドで作り、終わったら破棄する |
| 実験を前提に自動化する | Automate with architectural experimentation in mind | 自動化によりワークロードを低コストで複製でき、変更の追跡・影響の監査・以前の状態への復帰ができる |
| 進化するアーキテクチャを考える | Consider evolutionary architectures | 設計を一度きりの決定にせず、自動化とオンデマンドのテストで設計変更のリスクを下げ、時間とともに進化させる |
| データに基づいて設計を導く | Drive architectures using data | 設計上の選択がワークロードの挙動にどう影響したかをデータで集め、事実に基づいて改善する |
| ゲームデーで改善する | Improve through game days | 本番のイベントを模擬する日を定期的に設け、アーキテクチャと手順がどう振る舞うかを確かめる |
「本番規模でテストする」は、オンプレミスだと予算的に不可能だったことを、使った時間分だけの課金で可能にする、という発想の転換です。6つの中では一番クラウドらしい原則だと感じました。
柱ごとの設計原則とベストプラクティス領域
ここから柱ごとに、公式ドキュメントの設計原則とベストプラクティス領域を並べます。ベストプラクティス領域は、その柱の質問がどの区分に属するかを示す見出しで、領域名そのものが「見るべき場所」の一覧になっています。
運用上の優秀性（Operational Excellence）
設計原則は8つ。6つの柱の中で最も多く、「チームの組織」から「マネージドサービスの利用」まで幅があります。
| 設計原則 | 英語名 |
|---|---|
| ビジネス成果を軸にチームを組織する | Organize teams around business outcomes |
| 行動につながる洞察のためにオブザーバビリティを実装する | Implement observability for actionable insights |
| 可能な限り安全に自動化する | Safely automate where possible |
| 小さく可逆的な変更を頻繁に行う | Make frequent, small, reversible changes |
| 運用手順を頻繁に改善する | Refine operations procedures frequently |
| 障害を予測する | Anticipate failure |
| すべての運用イベントとメトリクスから学ぶ | Learn from all operational events and metrics |
| マネージドサービスを使う | Use managed services |
ベストプラクティス領域（4）: Organization / Prepare / Operate / Evolve
セキュリティ（Security）
設計原則は7つ。多層防御・最小権限・自動化という守りの基本に加え、「人をデータから遠ざける」という運用上の原則が含まれている点が特徴です。
| 設計原則 | 英語名 |
|---|---|
| 強力なID基盤を実装する | Implement a strong identity foundation |
| トレーサビリティを維持する | Maintain traceability |
| すべてのレイヤーにセキュリティを適用する | Apply security at all layers |
| セキュリティのベストプラクティスを自動化する | Automate security best practices |
| 転送中および保管中のデータを保護する | Protect data in transit and at rest |
| 人をデータから遠ざける | Keep people away from data |
| セキュリティイベントに備える | Prepare for security events |
ベストプラクティス領域（7）: Security foundations / Identity and access management / Detection / Infrastructure protection / Data protection / Incident response / Application security
この柱の前提にはAWSの責任共有モデルがあります。AWSがクラウドを支える物理インフラを守るため、利用者はその上でサービスを使って目標を達成することに集中できる、という分担です。
信頼性（Reliability）
設計原則は5つ。「障害からの自動復旧」と「復旧手順のテスト」が並んでいるのは、オンプレミスでは特定シナリオで動くことの証明に使われることが多く復旧戦略の検証には回りにくかったテストを、クラウドでは失敗のさせ方の検証にも使える、という発想の転換を表しています。
| 設計原則 | 英語名 |
|---|---|
| 障害から自動的に復旧する | Automatically recover from failure |
| 復旧手順をテストする | Test recovery procedures |
| 水平にスケールしてワークロード全体の可用性を高める | Scale horizontally to increase aggregate workload availability |
| キャパシティを推測しない | Stop guessing capacity |
| 変更を自動化で管理する | Manage change through automation |
ベストプラクティス領域（4）: Foundations / Workload architecture / Change management / Failure management
「キャパシティを推測しない」は全体の設計原則にもありました。信頼性の柱では、需要がキャパシティを超えるリソース飽和がオンプレミスの典型的な障害原因である、という文脈で再登場します。
パフォーマンス効率（Performance Efficiency）
設計原則は5つ。高度な技術をサービスとして消費する、サーバーレスを使う、といった原則が並び、「自分で運用しないことで性能を得る」方向を向いています。
| 設計原則 | 英語名 |
|---|---|
| 高度な技術を民主化する | Democratize advanced technologies |
| 数分でグローバルに展開する | Go global in minutes |
| サーバーレスアーキテクチャを使う | Use serverless architectures |
| より頻繁に実験する | Experiment more often |
| メカニカルシンパシーを考慮する | Consider mechanical sympathy |
ベストプラクティス領域（5）: Architecture selection / Compute and hardware / Data management / Networking and content delivery / Process and culture
メカニカルシンパシーとは、クラウドサービスがどう消費されるかを理解し、ワークロードの目的に合った技術を選ぶことです。公式ドキュメントが挙げる例は、データベースやストレージを選ぶときにデータのアクセスパターンを考慮すること。名前だけ見ると何のことか分からない原則ですが、中身は「用途に合わない道具を選ばない」という当たり前の話でした。
コスト最適化（Cost Optimization）
設計原則は5つ。最初の原則が「Cloud Financial Managementを実装する」であることが示すように、この柱は安いインスタンスを選ぶ技術ではなく、コスト効率の良い組織になるための能力構築を扱います。
| 設計原則 | 英語名 |
|---|---|
| クラウド財務管理を実装する | Implement Cloud Financial Management |
| 消費モデルを採用する | Adopt a consumption model |
| 全体的な効率を測定する | Measure overall efficiency |
| 差別化につながらない重労働にお金を使わない | Stop spending money on undifferentiated heavy lifting |
| 支出を分析し帰属させる | Analyze and attribute expenditure |
ベストプラクティス領域（5）: Practice Cloud Financial Management / Expenditure and usage awareness / Cost-effective resources / Manage demand and supply resources / Optimize over time
公式ドキュメントは、この柱の中で明確にトレードオフを認めています。市場投入の速さを優先して先にリフト＆シフトし、後から最適化するのは妥当な選択であり、問題になるのはデータではなく焦りで判断して「念のため」に過剰なリソースを積むことだ、という整理です。
持続可能性（Sustainability）
設計原則は6つ。2021年に追加された6本目の柱で、エネルギー消費と効率を主なてこにして環境への影響を減らすことを扱います。
| 設計原則 | 英語名 |
|---|---|
| 自分の影響を理解する | Understand your impact |
| 持続可能性の目標を設定する | Establish sustainability goals |
| 使用率を最大化する | Maximize utilization |
| より効率的な新しいハードウェア・ソフトウェアを予測し採用する | Anticipate and adopt new, more efficient hardware and software offerings |
| マネージドサービスを使う | Use managed services |
| ワークロードの下流への影響を減らす | Reduce the downstream impact of your cloud workloads |
ベストプラクティス領域（6）: Region selection / Alignment to demand / Software and architecture / Data management / Hardware and services / Process and culture
「使用率を最大化する」の説明にある例は覚えやすいものでした。使用率30%のホスト2台は、ホストごとの基礎消費電力があるため、使用率60%のホスト1台より効率が悪い。適正サイズ化は、コスト最適化だけでなく持続可能性の原則でもあるわけです。
柱同士は綱引きをする
6つの柱を全部満点にすればよい、という話ではありません。柱同士は綱引きをします。信頼性を上げるためにマルチAZにすればコストは増える。コストを下げるために夜間インスタンスを止めれば、起動失敗という新しい障害モードが増える。パフォーマンスのために最新世代のインスタンスへ揃えれば、持続可能性の「新しい効率的なハードウェアを採用する」とは一致しますが、コスト最適化の「消費モデル」とは別の議論が要ります。
レビューの道具 AWS Well-Architected Tool
フレームワークを実際に当てるための道具として、AWSはAWS Well-Architected Tool（AWS WA Tool）を提供しています。マネジメントコンソール上でワークロードを定義し、柱ごとの質問に答えると、ベストプラクティスからの乖離と改善の推奨が一覧されます。マイルストーンを保存しておけば、改善後に再レビューしてリスク件数の変化を追えます。
WA Toolに点数という概念はありません。質問ごとに「実施しているベストプラクティス」をチェックしていくと、選ばれなかったベストプラクティスから高リスク（HRI: High Risk Issue）と中リスク（MRI: Medium Risk Issue）が特定され、改善プランとして一覧されます。該当しない質問やベストプラクティスは「このワークロードには該当しない」として理由をメモに残せます。ただしメモを残せばリスクが消えるわけではなく、HRI／MRIの影響を理解して、優先順位を付けて改善するか、受容すると決めて記録するかを判断するのがレビューの中身です。
フレームワークには、特定領域（サーバーレスや機械学習など）向けに観点を追加する「レンズ」があり、汎用の6つの柱に加えて領域固有の質問を重ねられます。WA Toolは自組織のベストプラクティスを組み込むカスタムレンズにも対応しています。補助教材として、ベストプラクティスを手を動かして実装するAWS Well-Architected Labsと、レビューを支援するパートナープログラムも用意されています。
AWS Trusted Advisorと混同しやすいので分けておきます。Trusted Advisorはアカウント全体のリソースを自動でチェックして推奨を出すサービスで、WA Toolはワークロード単位で人が質問に答える設計レビューのサービスです。「自動チェック」ならTrusted Advisor、「設計レビュー」「6つの柱」ならWA Toolです。
CLF-C02で問われる見分け方
ここまでの内容を、試験の選択肢で迷ったときの判断基準に圧縮します。
- 「6つの柱」「ワークロードの設計」「アーキテクチャのレビュー」が出たらWell-Architected Framework。「6つのパースペクティブ」「クラウド導入」「組織の準備状況」ならAWS CAF
- 柱の数を問われたら6。持続可能性（Sustainability）は2021年追加の6本目
- コスト最適化は「安いインスタンスを選ぶこと」ではない。定義は最も低い価格でビジネス価値を届けること、設計原則の筆頭はCloud Financial Managementの実装
- 信頼性とパフォーマンス効率の混同に注意。障害からの復旧・需要への追従は信頼性、リソースを効率よく使って性能要件を満たすのがパフォーマンス効率
- 設計レビューを行うサービスはAWS Well-Architected Tool。Trusted Advisorはアカウント全体の自動チェックを行う別サービス
まとめ
Well-Architected Frameworkが与えるのは、設計を評価するための共通語彙と質問であって、答えではありません。柱同士の綱引きはフレームワークの側では決着せず、ビジネス要件を置いたうえで自分で判断する必要があります。その代わり、判断の根拠を6つの軸で説明できるようになるため、レビューの場で論点がズレにくくなる。個人的には、試験対策で読み始めたはずが、「動いているから良い構成」という自分の口癖を疑うための語彙を手に入れた感覚のほうが強く残りました。
なお、この記事が参照したのは2024年11月6日発行版です。柱ごとの詳細ガイダンスは、それぞれ独立したホワイトペーパー（各柱のPillar whitepaper）として別途公開されており、実際にレビューを行う段階ではそちらを併読するのが実務的です。自分はSAA-C03に向けて、次は信頼性とパフォーマンス効率のホワイトペーパーを読む予定です。読んだらまた整理して追記します。