「設計のレビューで『この構成は Well-Architected になっていますか』と聞かれました。何を、どう答えればよいのでしょうか」
「本番の RDS をマルチ AZ にしたら費用がほぼ倍になると言われました。6つの柱を全部満たすのが正しい設計ではないのですか」
第11回と第12回では、運用・監視・コストのサービスを見ました。ここまでで、AWS の主要なサービスはひととおり出そろいました。最後に必要なのは、サービスを「どう組み合わせるか」を判断する軸 です。オンプレでは、経験の長い人の勘や社内の慣習で決めていたことも多いでしょう。AWS はその判断の物差しを Well-Architected フレームワーク としてまとめ、公開しています。
第13回では、Well-Architected フレームワークの成り立ちと一般的な設計原則、6つの柱それぞれの設計原則、柱どうしのトレードオフ、Well-Architected Tool とレビューの進め方、Azure・Google の同種のフレームワークとの比較を扱います。
Well-Architected フレームワークとは
AWS Well-Architected フレームワークは、AWS のソリューションアーキテクトが多数の顧客のシステムを支援する中で得た知見を体系化した「クラウド上の設計・運用のベストプラクティス集」です。2015年に公開され、2016年に5つの柱、2021年12月に「持続可能性」が加わって 6つの柱 になりました。各柱は「設計原則」「ベストプラクティス」「質問と確認項目」で構成され、特定のサービスの使い方ではなく、「この設計は何を優先し、何を犠牲にしているか」を言葉にするための共通の物差しを与えます。
重要なのは、6つの柱は同時に最大化できない ことです。信頼性を上げれば冗長の分だけコストが増え、コストを削ればパフォーマンスや可用性が落ちます。フレームワークは「正解」ではなく、「トレードオフを意識的に判断し、記録する」ための道具です。
AWS は無料の Well-Architected Tool で自己評価できるようにしており、パートナー（SIer など）がレビューを行う Well-Architected Partner Program もあります。Microsoft も同じ名前の Azure Well-Architected Framework（5つの柱）、Google も Google Cloud Well-Architected Framework を持ち、考え方は共通しています（後の節「Azure・Google との比較」）。
- 2015年に公開、今は 6つの柱。設計原則・ベストプラクティス・質問で構成
- 柱どうしは トレードオフ。「意識的に判断して記録する」ための共通の物差し
- Well-Architected Tool（無料） で自己評価。Azure・Google にも同種のものがある
一般的な設計原則
柱ごとの原則の前に、フレームワーク全体に共通する6つの設計原則があります。
- 必要なキャパシティを推測しない：オンプレのように事前に見積もって買うのではなく、計測して自動でスケールさせる（Auto Scaling、サーバーレス）
- 本番の規模でテストする：クラウドなら本番と同等の環境を一時的に作り、終わったら捨てられる。テスト環境の費用は使った時間の分だけ
- 自動化によりアーキテクチャの実験を容易にする：IaC で環境を再現できるようにし、変更をコードとして追跡・ロールバックできるようにする
- 進化的なアーキテクチャを許容する：一度決めた設計を固定せず、要件と技術の変化に合わせて変えられるように作る
- データに基づいてアーキテクチャを決める：勘や慣習ではなく、メトリクス・ログ・コストのデータを根拠に改善する
- ゲームデーで改善する：本番を模した環境で障害を意図的に起こし（AWS Fault Injection Service）、手順と体制を検証する
- これら6つの原則は、オンプレの「事前に見積もり、慎重に変更し、障害は起こさない」という文化からの転換を求めている
6つの柱の概観
6つの柱がそれぞれ何を問い、この連載のどのサービスと関係するかをまとめます。
| 柱 | 問い | 主な関連サービス（この連載の回） |
|---|---|---|
| 運用上の優秀性 | 運用を改善し続けられるか | IaC（第12回）、CloudWatch（第11回）、Systems Manager（第11回） |
| セキュリティ | データ・システムを守れているか | IAM（第8回）、KMS（第9回）、GuardDuty（第9回）、Organizations（第8回） |
| 信頼性 | 障害から回復し、需要に応じられるか | マルチ AZ（第2回、第10回）、Auto Scaling（第4回）、AWS Backup（第5回）、Route 53（第7回） |
| パフォーマンス効率 | リソースを効率よく使えているか | インスタンスタイプ（第3回）、EBS（第5回）、CloudFront（第7回）、Lambda（第4回） |
| コスト最適化 | 無駄なく価値を出せているか | 購入オプション（第4回）、タグ（第12回）、Cost Explorer（第12回） |
| 持続可能性 | 環境負荷を減らせているか | 適正サイジング、Graviton（第3回）、S3 のライフサイクル（第5回） |
以降の節では、各柱について AWS 公式の「設計原則」を挙げます。これはレビューの質問項目の根拠にもなっているので、原則の言葉をそのまま覚えておくとよいでしょう（設計原則の言葉は改訂されることがあります。ここでは2026年9月時点の版で書いています）。
柱①：運用上の優秀性（Operational Excellence）
システムを実行・監視し、プロセスと手順を改善し続けるための柱です。
- 設計原則（AWS 公式、2023年の改訂版）
- チームをビジネスの成果を中心に編成する
- 実用的な洞察を得るためのオブザーバビリティを実装する（メトリクス・ログ・トレース）
- 可能な限り安全に自動化する（手順書ではなくコードで）
- 小規模で可逆的な変更を頻繁に行う（大きな一発のリリースをしない）
- 運用の手順を頻繁に改善する
- 障害を予測する（プレモータム、ゲームデー）
- 運用上のあらゆるイベントとメトリクスから学ぶ（事後分析を責任追及にしない）
- マネージドサービスを使用する
- 確認項目の例：デプロイは自動化されているか／ロールバックできるか／ランブックとプレイブックがあるか／KPI は定義されているか
- オンプレとの違い：「変更を減らす」のではなく「変更を小さく速く安全に」行う。ITIL の変更管理をそのまま持ち込むと衝突する部分
柱②：セキュリティ（Security）
データ・システム・資産を保護し、リスクを評価・軽減し続けるための柱です。
- 設計原則
- 強力なアイデンティティ基盤を実装する（最小権限、一元的な ID の管理、恒久的な認証情報の排除。第8回）
- トレーサビリティを維持する（CloudTrail・Config・ログの集約と監視。第11回）
- すべてのレイヤーにセキュリティを適用する（エッジ・VPC・ELB・インスタンス・OS・アプリ・コードの多層防御。第9回）
- セキュリティのベストプラクティスを自動化する（Config ルール、Security Hub、IaC に組み込む）
- 転送中および保管中のデータを保護する（KMS、TLS、データの分類。第9回）
- データに人の手を入れない（直接のアクセスの排除、ツール経由の自動処理）
- セキュリティイベントに備える（インシデント対応のランブック、ゲームデー、GuardDuty の検出への対応手順）
- 確認項目の例：ルートユーザーは保護されているか／人の恒久的なキーは無いか／ログは組織で集約されているか／暗号化されていないデータは無いか／インシデントのときの隔離の手順はあるか
- 責任共有モデル（第1回）で「利用者側」に残る部分を、この柱が網羅している
最初の一手は、CloudTrail・GuardDuty・Security Hub・Config の4つを Organizations の全体で有効にする ことです（第9回）。
柱③：信頼性（Reliability）
期待どおりに一貫して機能し続けるための柱です。障害を前提に設計し、自動で回復させます。
- 設計原則
- 障害から自動的に復旧する（ヘルスチェック → 自動で置き換え。人を待たない）
- 復旧の手順をテストする（復元のテスト、フェイルオーバーの訓練、ゲームデー）
- 水平方向にスケールしてワークロード全体の可用性を高める（大きな1台より小さな多数）
- キャパシティを推測しない（Auto Scaling、Service Quotas の管理）
- オートメーションで変更を管理する（IaC）
- 4つの領域：基盤（Quotas、ネットワークの設計）／ワークロードのアーキテクチャ（疎結合、SQS によるバッファー、タイムアウトとリトライ、サーキットブレーカー）／変更管理（監視、デプロイ）／障害管理（バックアップ、DR、AZ・リージョンの障害への耐性）
- 可用性の設計目標：99.9%（年 8.7時間の停止）＝マルチ AZ、99.99%（52分）＝マルチ AZ＋自動復旧＋変更の自動化、99.999%（5分）＝マルチリージョン。数字を決めてから構成を選ぶ。RPO・RTO と一緒に定義する（連載「バックアップ入門」第2回「RPO・RTO と SLA の決め方」で扱います）
- 静的安定性：障害のときに「スケールアップして耐える」のではなく、あらかじめ AZ の障害の分の余力を持っておく
柱④：パフォーマンス効率（Performance Efficiency）
限られたリソースを、需要の変化に応じて効率よく使うための柱です。
- 設計原則
- 高度なテクノロジーを民主化する（機械学習・分散 DB を自前で作らず、マネージドサービスとして使う）
- 数分でグローバルに展開する（複数のリージョン、CloudFront）
- サーバーレスアーキテクチャを使用する（サーバーの管理そのものを無くす）
- より頻繁に実験する（インスタンスタイプ・ストレージ・構成の比較が安くできる）
- メカニカルシンパシーを考慮する（技術の特性に合った使い方。RDB に時系列を詰め込まない、S3 に小さなファイルを大量に置かない、といった配慮）
- 5つの重点領域：アーキテクチャの選択／コンピューティングとハードウェア（EC2・コンテナ・Lambda。第3・4回）／データ管理（ストレージと DB。第5・10回）／ネットワークとコンテンツ配信（配置、エンドポイント、CDN。第6・7回）／プロセスと文化
- 監視して見直す：Compute Optimizer、CloudWatch Database Insights、CloudWatch のメトリクスで「選択」を定期的に検証する。オンプレの「5年間同じサーバー」は前提にならない
- 「速い＝良い」ではなく、要件を満たす最小のリソースで。コスト最適化との接点を意識する
柱⑤：コスト最適化（Cost Optimization）
不要な支出を避け、最も低いコストでビジネスの価値を実現するための柱です。
- 設計原則
- クラウド財務管理を実装する（コストの責任者・プロセスを決める。FinOps）
- 消費モデルを導入する（使った分だけ。使わないときは止める。開発環境の夜間停止）
- 全体的な効率を測定する（費用あたりのビジネスの成果。1トランザクションあたりの費用）
- 差別化につながらない重労働に費用をかけるのをやめる（データセンターの運用・OS のパッチ・DB の運用をマネージドへ）
- 費用を分析し、帰属させる（タグ、Cost Explorer、部門への配賦。第12回）
- 実践の5つの領域：クラウド財務管理／費用と使用状況の認識（可視化）／費用対効果の高いリソース（適正なサイズ、購入オプション、Graviton）／需要の管理とリソースの供給（Auto Scaling、スケジュールによる停止）／継続的な最適化（新しいサービス・新しい世代への追従）。使った分だけ払う「消費に応じた支出」は、設計原則の「消費モデルを導入する」にあたる
- 代表的な打ち手の順序：①消し忘れ・アイドルの削除 → ②適正なサイズへの変更 → ③スケジュールによる停止 → ④Savings Plans・RI → ⑤アーキテクチャの変更（サーバーレス化、ストレージクラス）の順で進める
- コストは「後で見直す」のではなく、設計の時点で試算し（Pricing Calculator）、運用の開始と同時に Budgets を入れる
柱⑥：持続可能性（Sustainability）
2021年に追加された柱で、クラウドの利用による環境負荷（主に電力の消費と、それに伴う炭素の排出）を最小にすることを目的としています。ここにも 責任共有モデル の考え方が当てはまり、データセンターの電力の調達や冷却の効率は AWS の責任です（Amazon は、全事業で使う電力に相当する量を再生可能エネルギーで調達する目標を2023年に達成し、2024年も続けたと報告しています。2040年のネットゼロを目標にしています。2026年9月時点）。その上で「どれだけのリソースを使うか」は利用者の責任です。
設計原則は次の6つです。
- 影響を理解する：使用量とその環境への影響を計測する（Customer Carbon Footprint Tool）
- 持続可能性の目標を設定する
- 使用率を最大化する：アイドルを減らす。使用率 10% のサーバー10台より、50% の2台のほうが望ましい
- より効率的な新しいハードウェアとソフトウェアを予測して採用する：Graviton、新しい世代のインスタンス、効率のよい言語・アルゴリズム
- マネージドサービスを使用する：共用の基盤のほうが使用率が高いため
- クラウドのワークロードのダウンストリームの影響を軽減する：利用者側の端末・ネットワークの負荷も考える
実践の内容はコスト最適化と大部分が重なり、「不要なものを動かさない、必要以上に大きくしない、古いものを持ち続けない」が両方に効きます。データの保持期間を決めてライフサイクルで削除することも、ストレージの料金と環境負荷の両方を下げます。
- 2021年に追加。電力・炭素排出の最小化。責任共有モデルが当てはまる
- 原則は、影響の計測／目標設定／使用率の最大化／新しい世代の採用／マネージド／下流への配慮
- 実践はコスト最適化とほぼ重なる。「動かさない・大きくしない・持ち続けない」
柱のトレードオフ：具体例
柱どうしは、片方を上げるともう片方が下がることがよくあります。代表的な判断と落としどころの例です（料金は東京リージョンの例、2026年9月時点）。
| 判断 | 上がる柱 | 下がる柱 | 落としどころ |
|---|---|---|---|
| RDS をマルチ AZ にする | 信頼性 | コスト（約2倍） | 本番は必須、開発はシングル AZ＋夜間停止 |
| AZ ごとに NAT ゲートウェイ | 信頼性 | コスト（月 45 USD × AZ の数） | 本番は3 AZ、検証は1つ |
| すべてのログを無期限に保存 | セキュリティ（追跡性） | コスト、持続可能性 | CloudWatch Logs は 90日、S3 Glacier で1〜7年 |
| すべての通信を Network Firewall 経由に | セキュリティ | パフォーマンス、コスト | 境界だけ FW、内部は SG |
| スポットインスタンスでバッチ | コスト | 信頼性（中断） | チェックポイントとリトライを実装 |
| Lambda ですべてを処理 | 運用性、コスト（低負荷のとき） | パフォーマンス（コールドスタート）、コスト（高負荷のとき） | 定常的な高負荷は ECS、変動するものは Lambda |
| Graviton に移行 | コスト、持続可能性 | 運用性（互換性の検証） | 新規は Graviton、既存は検証してから |
| マルチリージョン | 信頼性 | コスト、運用性、セキュリティ（守る面が増える） | RTO・RPO の要件で本当に必要な場合だけ |
冒頭の2つ目の相談がこれです。レビューで問われるのは「なぜその選択をしたか」であり、「全部の柱を満たしているか」ではありません。本番の RDS をマルチ AZ にして費用が倍になるのは、信頼性のためにコストを払うという判断で、開発環境まで同じにする必要はありません。リスクを認識したうえで受け入れる ことは正当な判断であり、それを記録に残しましょう。
Well-Architected Tool とレビューの進め方
レビューは、無料の Well-Architected Tool を使って進めます。
- AWS Well-Architected Tool（コンソール、無料）：ワークロードを登録し、柱ごとの質問（合計 60問前後）に答えると、高リスク（HRI）・中リスク（MRI）の項目と改善の計画 が出る。マイルストーンで改善の推移を記録できる
- レンズ：業種・技術ごとの追加の質問集。Serverless、SaaS、機械学習、金融、ゲーム、IoT、生成 AI など。カスタムレンズも作れる
- レビューの進め方：①対象のワークロードと責任者を決める → ②アーキテクチャ図・運用の手順を揃える → ③関係者（開発・運用・セキュリティ）で質問に答える（半日〜1日） → ④HRI に優先度を付ける → ⑤改善の計画を実行する → ⑥定期的に（半年〜1年ごと、大きな変更のとき）再レビューする
- 考え方：監査ではなく「会話」。「できていない」を責めるのではなく、リスクを見える化して意思決定者に判断してもらう
- AWS のパートナーが行う場合は Well-Architected Partner Program の枠組みがあり、HRI の 45% 以上を改善するとクレジットが出る制度もある（時期により変わる）
- Trusted Advisor の結果は、ワークロードごとに有効にすると WA Tool の質問に関連付けて表示される（Business Support+ 以上が必要）。Security Hub・Compute Optimizer の結果も事前に見て、機械的に検出できる項目は潰しておく
冒頭の1つ目の相談への答えがこれです。「Well-Architected になっているか」は、合否ではなく、Well-Architected Tool の質問に関係者で答え、HRI とその扱い（直す・受け入れる）を説明できるか という意味で答えます。まだレビューをしていなければ、上の①〜③から始めましょう。
Azure・Google との比較
Azure にも同じ名前のフレームワークがあります。AWS と比べます。
| 項目 | AWS Well-Architected | Azure Well-Architected |
|---|---|---|
| 柱の数 | 6（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性） | 5（信頼性、セキュリティ、コスト最適化、オペレーショナル エクセレンス、パフォーマンス効率） |
| 持続可能性 | 柱として独立 | 柱ではなく「サステナブルなワークロード」のガイダンスとして別立て |
| 自己評価のツール | Well-Architected Tool（コンソールの中） | Azure Well-Architected Review（Microsoft Assessments のサイト） |
| 業種・技術別の拡張 | レンズ | ワークロード別のガイド（SaaS、AI、ミッションクリティカルなど） |
| 導入全体の枠組み | AWS Cloud Adoption Framework（CAF） | Microsoft Cloud Adoption Framework（CAF）＋ Landing Zone |
| 推奨事項の自動検出 | Trusted Advisor | Azure Advisor（5つの柱に対応した推奨） |
| 位置づけ | パートナーのレビュー制度が整備されている | ドキュメントが中心、Advisor と統合 |
柱の中身はほぼ共通で、AWS で学んだ設計原則は Azure でもそのまま通用します。Google Cloud にも Google Cloud Well-Architected Framework（以前の名前は Architecture Framework）があり、運用の優秀性、セキュリティ・プライバシー・コンプライアンス、信頼性、コスト最適化、パフォーマンス最適化、持続可能性の6つの柱で構成され、AI・ML は柱をまたぐ「視点（perspective）」として扱われています（2026年9月時点）。「クラウド設計の共通言語」として一度身につければ、事業者をまたいで使えます。
考えてみよう
- 担当しているシステム（オンプレでもかまいません）の可用性の目標は、99.9%・99.99%・99.999% のどれですか。その目標に対して、今の構成はマルチ AZ・自動復旧・マルチリージョンのどこまで備えていますか
- 「柱のトレードオフ：具体例」の表から、自分の環境で「あえて受け入れている」リスクを1つ選び、なぜ受け入れたのかを一文で記録してみてください
- コスト最適化の打ち手の順序（①〜⑤）で、いきなり ④ Savings Plans・RI から始めると、どんな無駄が起こりえますか
- Well-Architected Tool でレビューするとしたら、①責任者、②揃える資料、③参加する人を、それぞれ誰（何）にしますか
ヒント：1は「柱③：信頼性」、2は「柱のトレードオフ：具体例」、3は「柱⑤：コスト最適化」、4は「Well-Architected Tool とレビューの進め方」の節を見直してください。
まとめ
- Well-Architected フレームワークは、AWS の知見をまとめた 設計・運用の共通の物差し。今は 6つの柱
- 一般的な設計原則は「推測しない・本番規模でテスト・自動化・進化・データ・ゲームデー」。オンプレの文化からの転換
- 各柱の 設計原則の言葉 は、レビューの質問の根拠になる
- 信頼性は 可用性の数字を決めてから構成を選ぶ。RPO・RTO と一緒に定義する
- コスト最適化は 消し忘れの削除 → 適正なサイズ → 停止 → Savings Plans・RI → アーキテクチャ の順
- 柱どうしは トレードオフ。全部を満たすのではなく、何を優先し何を受け入れたかを記録 する
- Well-Architected Tool は無料。レビューは監査ではなく「会話」。Azure・Google にも同じ考え方がある
次回は最終回です。オンプレのテーマ（DNS・証明書・NTP・認証など）が AWS で何に当たるかの対応表と、連載全体の振り返り・学習の進め方を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク（この記事）
- これまでのテーマとAWSの対応・まとめ
コメント