Well-Architected フレームワークとは

導入

「良い設計」とは何かを、感覚ではなく共通のものさしで語るために、AWSは Well-Architected フレームワーク を用意しています。SAAの4ドメインは、実はこのフレームワークの考え方が土台になっています。

説明

AWS Well-Architected フレームワーク は、AWSが長年の経験から体系化した「クラウドで良いシステムを設計・運用するためのベストプラクティス集」です。設計を評価・改善するための 6つの柱（Pillars） で構成されます。

SAAの4ドメイン（セキュリティ・回復性・性能・コスト）は、この6本柱のうち中心的な4つにほぼ対応します。Well-Architectedの考え方を身につければ、そのままSAAの解答基準になると考えてください。

flowchart TD
    WA["Well-Architected<br/>6本柱"] --> S["セキュリティ"]
    WA --> R["信頼性"]
    WA --> P["パフォーマンス効率"]
    WA --> C["コスト最適化"]
    WA --> O["運用上の優秀性"]
    WA --> SU["持続可能性"]
    S -.-> D1["SAAドメイン1: セキュア設計"]
    R -.-> D2["SAAドメイン2: 回復性"]
    P -.-> D3["SAAドメイン3: 高性能"]
    C -.-> D4["SAAドメイン4: コスト最適化"]

実務では AWS Well-Architected Tool（無料）を使って、既存システムを6本柱の観点で自己診断し、リスクを洗い出せます。

具体例

Well-Architectedの核心は「柱どうしのトレードオフを意識的に選ぶ」ことです。あるスタートアップの設計会議を覗いてみましょう。

決済API（お金を扱う）とキャンペーンの画像配信、2つを設計します。同じ会社でも、優先する柱が真逆です。

• 決済API … 止まると売上に直結し、二重決済も許されない。→ 信頼性を最優先。多少コストが上がっても、マルチAZ構成でDBを冗長化し、確実性を取る。
• キャンペーン画像の配信 … 一時的に大量アクセスされるが、失敗しても致命的でない。→ コスト最適化を優先。S3＋CloudFrontで安く配り、スポット活用も検討。信頼性は「そこそこ」で割り切る。

もし両方を「とにかく最高の可用性で」と作れば、画像配信に過剰なコストをかけることになります。逆に決済まで「とにかく安く」で作れば、障害時に大損害。どのシステムで、どの柱を優先するかを要件から決める——これがWell-Architectedの使い方であり、そのままSAAの解答の指針になります。

読んでみよう

「トレードオフ」という言葉を覚えておいてください。可用性を上げればコストは上がり、コストを削れば信頼性が下がることもあります。Well-Architectedは「どの柱を優先するか」を意識的に選ぶための道具です。SAAの問題も、たいてい「何を優先する要件か」を読み取れば答えが絞れます。