導入
「良い設計」とは何かを、感覚ではなく共通のものさしで語るために、AWSは Well-Architected フレームワーク を用意しています。SAAの4ドメインは、実はこのフレームワークの考え方が土台になっています。
説明
AWS Well-Architected フレームワーク は、AWSが長年の経験から体系化した「クラウドで良いシステムを設計・運用するためのベストプラクティス集」です。設計を評価・改善するための 6つの柱（Pillars） で構成されます。
| 柱 | 問いかけ |
|---|---|
| 運用上の優秀性（Operational Excellence） | 運用を自動化し、継続的に改善できているか |
| セキュリティ（Security） | データとシステムを守れているか |
| 信頼性（Reliability） | 障害から復旧し、需要に応え続けられるか |
| パフォーマンス効率（Performance Efficiency） | リソースを効率よく使えているか |
| コスト最適化（Cost Optimization） | 不要な出費をなくせているか |
| 持続可能性（Sustainability） | 環境負荷を減らせているか |
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は「どの柱を優先するか」を意識的に選ぶための道具です。SAAの問題も、たいてい「何を優先する要件か」を読み取れば答えが絞れます。