AWS Well-Architected Frameworkで構成をレビューする方法

AWS Well-Architected Frameworkで構成をレビューする方法｜6つの柱と改善の優先順位付け

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ AWS(Amazon Linux) ＞ AWS Well-Architected Frameworkで構成をレビューする方法｜6つの柱と改善の優先順位付け

「AWSにシステムを構築したが、本当にこの設計で問題ないのかを確認する方法がわからない」
クラウドへの移行を進めたチームが必ずぶつかる壁です。EC2が起動していて、RDSのデータも正常に取れている。しかし「セキュリティ上の穴はないか」「障害に耐えられる構成になっているか」「無駄なコストが出ていないか」を体系的に評価する手段が見当たらない、という状況です。

この記事では、AWSが公式に提供するアーキテクチャ評価フレームワーク「AWS Well-Architected Framework」を使って、自社の構成をレビューする方法を解説します。6つの柱の設計原則から、Well-Architected Toolを使ったレビューの実施手順、改善の優先順位付けの考え方まで体系的に説明します。
動作確認環境: AWSマネジメントコンソール（2026年6月時点）、AWS CLI v2。

この記事のポイント

・Well-Architected Frameworkは6つの柱でAWSアーキテクチャを総合評価する公式指針
・Well-Architected Toolで質問に答えるだけでHRIs（高リスク課題）を自動抽出できる
・改善の優先順位はリスクの大きさと対応コストのバランスで判断する
・フレームワークは一発チェックではなく四半期ごとのPDCAサイクルとして活用する

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

図解60P／登録10秒／解除も3秒／詳細はこちら

AWS Well-Architected Frameworkとは何か

AWS Well-Architected Frameworkは、AWSが長年のクラウド設計支援を通じて体系化したベストプラクティス集です。AWSのソリューションアーキテクトが顧客のシステムをレビューする際に使う評価基準が、誰でも利用できる形で公開されています。

一言で言えば、「クラウドアーキテクチャを自己評価するための公式な物差し」です。コンソールのダッシュボードを眺めているだけでは見えてこない、設計上の盲点を洗い出すことができます。

フレームワークは6つの柱（Pillar）で構成されており、各柱に設計原則（Design Principles）と一連の質問群が定義されています。質問に回答するだけで、自分のアーキテクチャがどの柱でどのようなリスクを抱えているかが可視化されます。

また、Well-Architected Frameworkには業種や用途に特化した拡張版「Lens（レンズ）」も存在します。サーバーレス・機械学習・SaaSなどのユースケース向けLensを適用することで、汎用的な6柱の評価に加えて分野固有のベストプラクティスもチェックできます。

AWSを使い始めて最初の構成レビューをするタイミング、または大きなアーキテクチャ変更の前後で活用するのが最も効果的です。

AWSの基本的な構成やサービス体系についてはじめて学ぶ方は、以下の入門コースも参照してください。
＞＞ AWSをはじめて学ぶ方はこちら（Amazon Linux入門）

6つの柱の概要

Well-Architected Frameworkを構成する6つの柱は、クラウドシステムの品質を多角的に評価するための視点です。それぞれの柱が互いに独立しているのではなく、「1つの柱を改善するとほかの柱にも影響する」という相互関係があります。

1. 運用上の優秀性（Operational Excellence）

システムを継続的に運用・改善していく能力を評価します。「ビジネスの変化に合わせてシステムを進化させられるか」が問われる柱です。

主な設計原則は「すべてのオペレーションをコードとして実装する」「小さく可逆的な変更を頻繁に行う」「運用上の問題を予測して備える」「障害から学んで継続的に改善する」の4つです。IaCによるインフラ管理（Terraform・CloudFormation）、ランブックの整備、デプロイパイプラインの自動化などが具体的な施策になります。

2. セキュリティ（Security）

情報・システム・資産を保護し、リスクを評価・軽減することで事業価値を提供する能力を評価します。

主な設計原則は「強力なアイデンティティ基盤を実装する」「トレーサビリティを確保する」「全レイヤーにセキュリティを適用する」「最小権限の原則を徹底する」「データを保護する」の5つです。IAMによる最小権限設計、CloudTrailによる操作ログの取得、VPCのセキュリティグループ設計などが評価対象です。

3. 信頼性（Reliability）

意図した機能を正しく実行し、障害から迅速に復旧する能力を評価します。「サービスが落ちたときにどれだけ早く元に戻せるか」という観点です。

主な設計原則は「障害から自動的に回復する」「復旧手順をテストする」「水平スケーリングで可用性を高める」「容量の推測をやめる」「自動化を活用する」の5つです。マルチAZ構成、Route 53フェイルオーバー、AWS Backupによる自動スナップショット取得などが具体策です。

4. パフォーマンス効率（Performance Efficiency）

コンピューティングリソースを効率的に使い、需要の変化やテクノロジーの進化に対応する能力を評価します。

主な設計原則は「高度なテクノロジーを使いこなす」「グローバルに展開する」「サーバーレスアーキテクチャを活用する」「実験をより頻繁に行う」「最新技術の動向を意識する」の5つです。ElastiCache・CloudFrontによるキャッシュ活用、Gravitonインスタンスへの移行などが評価ポイントです。

5. コスト最適化（Cost Optimization）

最低コストでシステムを実行して事業価値を生み出す能力を評価します。「使われていないリソースに無駄なコストを払っていないか」が問われます。

主な設計原則は「クラウド財務管理を実践する」「消費モデルを採用する」「全体的な効率を測定する」「差別化されていない重作業への支出をやめる」「支出を分析・帰属させる」の5つです。Savings Plans・リザーブドインスタンスの検討、Cost Explorerによるコスト追跡、不要リソースの自動削除などが具体的な改善策です。

6. 持続可能性（Sustainability）

環境への影響を最小限に抑えながらクラウドワークロードを実行する能力を評価します。2021年に6番目の柱として追加されました。

主な設計原則は「影響を把握する」「持続可能性の目標を設定する」「使用率を最大化する」「より効率的なハードウェアとソフトウェアを採用する」「マネージドサービスを活用する」の5つです。適切なインスタンスサイズへのダウンサイジング、Gravitonインスタンスの採用（電力効率向上）、不要なアイドルリソースの削除などが評価されます。

Well-Architected Toolを使ったレビューの実施手順

Well-Architected Toolは、AWSマネジメントコンソール上で利用できる無料のレビューツールです。コンソールの「Management & Governance」カテゴリから「AWS Well-Architected Tool」を開いて利用します。

1. ワークロードを作成する

レビュー単位となる「ワークロード」を作成します。ワークロードとは、ビジネス価値を提供するためのリソースとコードの集合体のことです。たとえば「受注管理システム」「ユーザー認証基盤」のように、ひとまとまりのシステムをワークロードとして定義します。

作成時に設定するのは以下の項目です。

・ワークロード名：例「受注管理システム v2.0」
・説明：システムの概要（設計者以外が見ても把握できる粒度で書く）
・環境：本番（Production）または本番以外（Pre-production）
・リージョン：このワークロードが使用するAWSリージョン
・レビューオーナー：レビュー担当者のメールアドレス

2. 各柱の質問に回答する

ワークロードを作成したら、6つの柱のそれぞれについて質問に回答していきます。各柱に20～30問程度の質問があり、合計で約70問になります。

1つの質問に対して、複数の「ベストプラクティスの実装状況」が選択肢として表示されます。現時点で実装できているものにチェックを入れ、最後の選択肢「これらのいずれにも該当しない（None of these）」は、何も実装できていない場合に選びます。

「None of these」を選択した質問は自動的にHRI（高リスク課題）としてマークされます。時間がかかる場合は、柱ごとに回答を途中保存しながら進めることができます。

AWS CLIを使って、既存のワークロード一覧とリスク件数を確認することもできます。


# ワークロードの一覧と各リスク件数を確認する
aws wellarchitected list-workloads \
  --region ap-northeast-1 \
  --query "WorkloadSummaries[*].{Name:WorkloadName,ID:WorkloadId,High:RiskCounts.HIGH,Medium:RiskCounts.MEDIUM}" \
  --output table

# 出力例
----------------------------------------------------------------
|                     ListWorkloads                            |
+------------------+-------------------+---------+-----------+
|       High       |        ID         | Medium  |   Name    |
+------------------+-------------------+---------+-----------+
|  8               |  wl-XXXXXXXXXXXX  |  12     | 受注管理  |
|  3               |  wl-YYYYYYYYYYYY  |  5      | 認証基盤  |
+------------------+-------------------+---------+-----------+

3. レビュー結果（HRIsとMRIs）を確認する

回答が完了すると、各柱のリスクサマリーが表示されます。

・HRI（High Risk Issue）：「None of these」を選択した質問。即座に対応が必要な高リスク課題
・MRI（Medium Risk Issue）：一部のベストプラクティスしか実装されていない質問。計画的に改善が必要な中リスク課題
・NONE：すべてのベストプラクティスを実装済み
・NOT_APPLICABLE：「該当なし」を選択した質問
・UNANSWERED：未回答の質問

レビュー結果はPDFとしてエクスポートできます。AWSのEnterpriseサポート契約があれば、AWSソリューションアーキテクトにレビューを依頼して共同で結果を分析することもできます。

4. マイルストーンを記録して改善を追跡する

レビュー後に「マイルストーン」を保存することで、改善前後の状態を比較できます。最初のレビューが完了したタイミングでマイルストーンを保存し、その後の改善施策を実施してから再レビューすると、HRI・MRIの削減を数値で確認できます。

改善の優先順位付けの考え方

レビューを実施すると、最初は多くのHRIとMRIが検出されることがほとんどです。「何から手をつけるか」の判断が、Well-Architected Frameworkを実践で活かすための最大のポイントです。

HRIとMRIの優先順位マトリクス

すべての課題を一度に解決しようとすると、リソースが分散して何も改善されないまま時間だけが経過します。以下の2軸で優先順位を判断してください。

・軸1　リスクの深刻度：HRI（高）＞MRI（中）の順で対応する
・軸2　対応コスト（工数・費用）：同じリスク深刻度なら、低コストで対応できるものを先に片付ける

この判断を整理すると、以下のような優先順位になります。

リスク	対応コスト	優先度	具体例
HRI（高）	低	最優先	MFAの有効化、パブリックS3バケットのアクセスブロック
HRI（高）	高	優先	マルチAZ構成の追加、DRサイトの構築
MRI（中）	低	次点	CloudTrailの有効化、Cost Explorerのタグ整備
MRI（中）	高	計画的に	IaCへの移行、マイクロサービスアーキテクチャへの段階的分割

特にセキュリティ柱のHRIは、「対応コストが低くても後回し」は絶対に避けてください。IAMのルートアカウントアクセスキー削除やMFAの強制など、数十分で実施できるのにHRIとして検出されるケースは実際に多くあります。

ビジネスインパクトを加味する

技術的なリスクだけでなく、ビジネスへの影響も優先順位の判断基準に加えてください。たとえば「コスト最適化柱のHRIが10件あるが、システム全体のAWS利用料は月3万円」という場合と、「信頼性柱のMRIが1件あるが、そのシステムがダウンすると1日100万円の機会損失が発生する」という場合では、後者を優先するほうが正しい判断です。

フレームワーク上のリスク分類はあくまでも「設計上の問題」の指標です。最終的な優先順位はビジネスへのインパクトとセットで判断してください。

各柱ごとの主要チェックポイントと改善例

Well-Architected Toolの質問数は多いですが、実際の現場で頻繁にHRIとして検出されやすいチェックポイントを柱ごとに整理します。

柱	よくあるHRI・MRIの原因	代表的な改善策
運用上の優秀性	手動デプロイが残っている、ランブックがない	CI/CDパイプラインの整備、IaC（Terraform・CloudFormation）の導入
セキュリティ	ルートアカウントの常用、MFA未設定、S3バケットの公開設定	IAM MFAの強制、SCPによる制御、GuardDutyの有効化
信頼性	シングルAZ構成、バックアップ未設定、復旧テスト未実施	マルチAZ化、AWS Backupによる定期スナップショット、障害シミュレーションの実施
パフォーマンス効率	インスタンスサイズの固定運用、キャッシュなし	Compute Optimizerによるサイジング最適化、ElastiCacheの導入
コスト最適化	使われていないElastic IPやEBS、オンデマンド一辺倒	Cost Anomaly Detectionの有効化、Savings Plansの検討
持続可能性	過剰なインスタンスサイズ、x86インスタンスのGraviton未移行	Gravitonインスタンスへの切り替え、マネージドサービスへの移行

特にセキュリティ柱は、初めてレビューすると5件以上のHRIが検出されることが珍しくありません。手が止まらないように、まずセキュリティ柱だけをターゲットにした「セキュリティ対応スプリント」を四半期単位で設定するアプローチが実務では有効です。

Well-Architected Frameworkを活用した継続的改善サイクル

Well-Architected Frameworkは「一度レビューすれば完了」ではありません。システムは変化し続けるため、定期的なレビューサイクルを設定することが重要です。

レビューを実施すべきタイミング

・アーキテクチャ変更の前後：新しいサービスの追加、マルチリージョン化、外部サービス連携の追加などを行う前後でレビューする
・定期レビュー（四半期または年次）：大きな変更がなくても、四半期ごとまたは年に1回、各柱の回答状況を見直す
・インシデント発生後：本番障害やセキュリティインシデントが発生した後は、関連柱の設計を再確認する

AWSとの共同レビューを活用する

EnterpriseサポートまたはEnterprise On-Rampサポートプランを契約しているAWSアカウントでは、AWSテクニカルアカウントマネージャー（TAM）を通じてAWSソリューションアーキテクトとの共同レビューを依頼できます。外部の視点を入れることで、内部だけでは気づかなかったリスクを発見しやすくなります。

共同レビューを依頼する際は、事前にWell-Architected Toolで自己評価を完了させ、HRIの内容を整理した上で臨むと議論が深まります。

PDCAサイクルで継続改善を回す

Well-Architected Frameworkを継続的に活かすためのPDCAは以下のように設計します。

・Plan（計画）：HRI・MRIの優先順位を決め、四半期のスプリントに改善タスクを組み込む
・Do（実行）：優先度の高い課題から順に改善施策を実施する
・Check（確認）：改善後にWell-Architected Toolで再レビューし、マイルストーンを保存してHRI数の変化を数値で確認する
・Act（改善）：残課題と新たに発生した課題を次のサイクルの計画に反映する

このサイクルを回し続けることで、ビジネスの成長に合わせてシステムを進化させながらアーキテクチャ品質を維持できます。

本記事のまとめ

AWS Well-Architected Frameworkは、AWSのクラウドアーキテクチャを6つの柱で体系的に評価・改善するための公式フレームワークです。Well-Architected Toolを使えば無料でレビューを実施でき、HRI・MRIという形で具体的な課題が可視化されます。

項目	内容
Well-Architected Framework	6つの柱でAWSアーキテクチャを評価するAWS公式ベストプラクティス集
6つの柱	運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性
Well-Architected Tool	AWSコンソールから無料でレビューを実施できるツール。HRI・MRIを自動抽出する
HRI（高リスク課題）	「None of these」選択時に自動マーク。セキュリティ柱のHRIは最優先で対応する
改善優先順位	リスク深刻度（HRI＞MRI）×対応コスト（低コスト優先）×ビジネスインパクトで判断
レビュー頻度	四半期ごと＋アーキテクチャ変更前後＋インシデント後

AWSの構成設計は「一度作れば終わり」ではありません。Well-Architected Frameworkを継続的なPDCAサイクルとして活用することで、ビジネスの成長に合わせてシステムを進化させ続けることができます。

AWSの設計をより深く実践したい方は、以下もご参照ください。
＞＞ AWSの構成設計・Well-Architectedを体系的に学ぶ（上級コース）

＞＞ AWSをはじめて学ぶ方はこちら（Amazon Linux入門）

AWSの設計品質を「自己評価できる力」は、Linuxサーバー構築の基礎から育ちます

Well-Architected FrameworkのHRIに答えられるエンジニアになるには、クラウドの設計原則を「自分で構築した経験」と結びつけることが必要です。マネジメントコンソールで設定するだけでは見えてこない、Linuxサーバー構築の「型」が判断力の土台になります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒）＞＞図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

次のページへ：AWSのDR設計入門｜バックアップ&リストア・パイロットライトなど4戦略とRTO/RPOの決め方
前のページへ：AWS GuardDutyとSecurity Hubで脅威検知を設計する方法｜有効化から通知・対応フローの構築まで
この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る