AWS Well-Architected Framework

AWS Well-Architected Framework は、クラウド上のシステムを安全で信頼性が高く、効率的で費用対効果の高いものにするための設計・運用の考え方です。アーキテクチャを6つの柱から確認し、改善点を継続的に見つけます。

CLF では、フレームワークの目的、6つの柱、との違いを理解することが重要です。

Point

Well-Architected は「適切に設計された」という意味です。
Framework は判断の枠組み、AWS Well-Architected Tool はそのレビューを支援するサービスです。
試験では、6つの柱と各柱が扱う課題を結び付けて覚えます。

概要

クラウドの設計では、セキュリティだけ、またはコストだけを考えるのではなく、複数の品質をバランスよく検討する必要があります。 AWS Well-Architected Framework は、共通の質問とベストプラクティスを使い、ワークロードの現在の状態を評価して改善点を特定するための一貫した方法を提供します。

レビューは一度で終わる作業ではありません。システムや事業要件の変化に合わせて繰り返し、継続的に改善します。

主要技術

①6つの柱

AWS Well-Architected Framework は、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、、持続可能性の6つの柱で構成されます。

柱	主な目的	問題文の判断ポイント
Operational Excellence	システムを効果的に運用・監視し、手順を継続的に改善します。	運用手順、自動化、監視、障害からの学習です。
Security	情報、システム、資産を保護します。	、追跡可能性、多層防御、データ保護です。
Reliability	障害から復旧し、期待どおりに機能し続けられるようにします。	自動復旧、需要への追随、障害対策、変更管理です。
Performance Efficiency	要件を満たすためにコンピューティング資源を効率よく使います。	適切な技術選択、性能測定、新技術の活用です。
Cost Optimization	無駄を減らし、事業成果に対する費用対効果を高めます。	支出の把握、適正なサイジング、需要と供給の調整です。
Sustainability	ワークロードが環境に与える影響を減らします。	資源使用量、エネルギー効率、不要な処理の削減です。

Point

Operational Excellence は「運用上の優秀性」です。
Reliability は「信頼性」、Performance Efficiency は「パフォーマンス効率」です。
Cost Optimization は「コスト最適化」、Sustainability は「持続可能性」です。
「運・セ・信・パ・コ・持」の順に並べて覚えると、6つを確認しやすくなります。

⚠️ 頻出: 「障害からの自動復旧」は Reliability、「最小権限」は Security、「未使用リソースの削除」は Cost Optimization が中心です。

②柱の判断軸

1つの改善が複数の柱に役立つこともあります。試験では、問題文が最も強く求めている成果を確認します。

状況	中心となる柱	理由
手作業を自動化し、運用ミスを減らす	Operational Excellence	運用プロセスの改善が中心です。
データを暗号化し、アクセスを最小限にする	Security	情報と資産の保護が中心です。
障害時に自動で正常な構成へ戻す	Reliability	障害への耐性と復旧が中心です。
要件に合う最適なコンピューティング方式を選ぶ	Performance Efficiency	資源を効率的に使って性能要件を満たします。
利用状況に合わせてリソースを縮小する	Cost Optimization	不要な支出を減らします。
不要なデータ処理や資源使用を減らす	Sustainability	環境への影響を減らします。

は単純な費用削減ではありません。必要な事業成果を維持しながら、無駄を減らして費用対効果を高めます。また、信頼性を高めるために冗長化を増やすとコストが上がることがあるため、事業要件に沿ってトレードオフを判断します。

各柱には、その目的を実現するための設計原則があります。試験では、具体的な取り組みがどの柱のどの原則に当たるかを、取り組みの目的から判断します。

柱	主な設計原則	取り組みの例
Operational Excellence	可能な場合は安全に自動化する、小規模かつ可逆的な変更を頻繁に行う、オペレーション手順を頻繁に改善する、障害を予測する、運用上のイベントとから学ぶ、を使用する	運用手順のコード化、小さく戻せるデプロイ、障害の振り返りの共有です。
Security	強力なアイデンティティ基盤を実装する、トレーサビリティの維持、すべての層にセキュリティを適用する、セキュリティのベストプラクティスの自動化、転送中および保管中のデータの保護、人をデータから遠ざける、セキュリティイベントの準備	、長期の認証情報の廃止、操作の記録、データへの直接操作の削減、インシデント対応の演習です。
Reliability	障害から自動的に復旧する、リカバリ手順をテストする、水平方向にスケールして総合的なワークロードの可用性を高める、容量を推測しない、自動化で変更を管理する	自動での置き換え、復元手順の試行、小さな複数台への分散、需要に合わせた自動増減です。
Performance Efficiency	高度なテクノロジーを誰でも使えるようにする、わずか数分でグローバル展開する、アーキテクチャを使用する、より頻繁に実験する、メカニカルシンパシーを重視する	複数のの比較テスト、データのアクセスパターンに合うデータベースの選択です。
Cost Optimization	クラウド財務管理の実装、消費モデルを導入する、全体的な効率を測定する、差別化につながらない手間のかかる作業にコストをかけるのをやめる、コストを分析し帰属関係を明らかにする	使わない時間帯の停止、部門やワークロードごとの費用の割り当てです。
Sustainability	影響を理解する、持続可能性の目標を設定する、使用率を最大化する、より効率的なハードウェアやソフトウェアの新製品を予測して採用する、マネージドサービスを使用する、クラウドワークロードのダウンストリームの影響を軽減する	使用率の低いサーバーの集約、アイドル状態の資源の削減です。

同じ取り組みでも、目的によって当たる原則が変わります。

需要の増加が容量を超える資源の飽和は、障害の主な原因の1つです。需要を監視して資源を自動で増減し、飽和による停止を防ぐのは信頼性の「容量を推測しない」です。
平日の業務時間しか使わない開発環境を使わない時間に止め、使った分だけ支払うのはコスト最適化の「消費モデルを導入する」です。
ホストには台数ごとに基礎的な電力がかかるため、使用率30%の2台より使用率60%の1台のほうがエネルギー効率は高くなります。台数を集約して使用率を高めるのは持続可能性の「使用率を最大化する」です。
マネージドサービスの利用は、運用の負担を減らす目的なら運用上の優秀性、多くの利用者で基盤を共有して必要なインフラを減らす目的なら持続可能性の原則に当たります。

③クラウドの一般的な設計原則

AWS Well-Architected Framework には、クラウドの特性を活用する一般的な設計原則があります。これらは特定のAWSサービスに依存せず、アーキテクチャ全体を考える基礎になります。

設計原則	意味	判断ポイント
必要な容量を推測しない	実際の需要に合わせて資源を増減します。	固定的な最大容量を先に購入する考え方を避けます。
本番規模でテストする	必要なときだけ本番相当の環境を作って検証します。	クラウドのと迅速な構築を活用します。
自動化によって実験しやすくする	同じ環境を繰り返し低コストで作れるようにします。	手作業ではなく、再現可能な変更を重視します。
発展的なアーキテクチャを可能にする	要件や技術の変化に合わせて設計を進化させます。	一度決めた構成を固定しません。
データに基づいて改善する	実際の指標や利用状況から設計を判断します。	推測ではなく測定結果を使います。
ゲームデーで改善する	障害を想定した演習から弱点を見つけます。	本番障害の前に対応手順を検証します。

④レビューとAWS Well-Architected Tool

Well-Architectedレビューでは、ワークロードを6つの柱の質問に照らして確認し、リスクと改善点を特定します。は、このレビュー内容の記録、リスクの把握、改善状況の追跡を支援するサービスです。

用語	役割	注意点
AWS Well-Architected Framework	設計と運用を評価する考え方・ベストプラクティス	フレームワーク自体はAWSサービスではありません。
AWS Well-Architected Tool	レビューを実施・記録するAWSサービス	フレームワークを利用する作業を支援します。
Lens	特定の技術領域や業界の観点を追加する質問とベストプラクティス	基本の6つの柱を特定領域向けに拡張します。

⚠️ 頻出: 「アーキテクチャを6つの柱で評価する考え方」は Framework、「レビュー結果や改善項目を記録・追跡するサービス」は Tool です。

⑤AWS CAFとの違い

AWS は組織全体のクラウド変革を扱い、AWS Well-Architected Framework はクラウド上のワークロードの設計・運用品質を扱います。

比較項目	AWS CAF	AWS Well-Architected Framework
対象	組織とクラウド変革	クラウド上のワークロード
主な構成	6つのパースペクティブ	6つの柱
主な問い	組織がクラウド導入の準備をできているか	ワークロードがベストプラクティスに沿っているか
成果	能力の差と変革計画	リスクとアーキテクチャ改善項目

試験対策

CLF では、6つの柱の名称と目的を対応させる問題が中心です。問題文に複数の利点が書かれていても、最も直接的な目的を示す柱を選びます。

問題文のキーワード	優先して考える柱	理由
運用手順、自動化、継続的改善	Operational Excellence	効果的な運用と改善を扱います。
、暗号化、監査	Security	情報とシステムを保護します。
障害復旧、冗長化、自動スケーリング	Reliability	正常に機能し続け、障害から回復できるようにします。
技術選定、性能要件、効率的な資源利用	Performance Efficiency	資源を効率よく使って要求性能を満たします。
支出の把握、適正サイジング、無駄の削減	Cost Optimization	費用対効果を継続的に高めます。
エネルギー効率、環境負荷、資源使用量	Sustainability	環境への影響を減らします。

よくある混同は、Reliability と Operational Excellence です。 Reliability はワークロードが障害に耐えて復旧する能力、Operational Excellence はワークロードを運用し、手順や組織を継続的に改善する能力です。

また、「6つ」という数だけで AWS と混同しないようにします。パースペクティブなら組織のクラウド変革、柱ならワークロードの設計・運用です。