導入
SAPのドメイン3は「既存システムの継続的な改善」です。改善するには、まず「今の設計のどこが弱いか」を体系的に評価する必要があります。その共通のものさしが Well-Architected フレームワークです。
説明
AWS Well-Architected フレームワーク は、クラウド設計のベストプラクティスを 6つの柱（Pillars） に整理したものです。SAAでも登場しますが、SAPでは「新規設計の指針」だけでなく「既存システムを評価し、リスクを洗い出す道具」として使います。
| 柱 | プロレベルでの問い |
|---|---|
| 運用上の優秀性 | 変更・障害対応を自動化し、観測できているか |
| セキュリティ | 組織全体で最小権限・暗号化・監査を徹底できているか |
| 信頼性 | 目標のRTO/RPOを満たすDRを設計できているか |
| パフォーマンス効率 | 適切なサービスへ継続的に見直せているか |
| コスト最適化 | 使っていないリソース・過剰なサイズを削れているか |
| 持続可能性 | リソース効率を上げ環境負荷を下げられているか |
実務では AWS Well-Architected Tool（無料）でワークロードを6本柱の観点でレビューし、高／中リスクの項目を洗い出して改善計画に落とします。SAPの「既存改善」系の問題は、まさにこの「リスクを見つけて、最小の労力で直す」流れそのものです。
flowchart LR
W["既存ワークロード"] --> R["Well-Architected Review<br/>6本柱で評価"]
R --> H["高リスク項目を特定"]
H --> F["優先度をつけて改善"]
F --> W
読んでみよう
プロフェッショナルは「作って終わり」ではなく「回し続ける」役割です。Well-Architected Review を定期的に行い、リスクを見つけて直す 改善のループ を回すのがドメイン3の本質です。「一度に完璧を目指さず、リスクの高い順に、影響の小さい変更で直す」という感覚を覚えておいてください。