AWS Well-Architected Framework 入門:全体像と公式ドキュメントを整理してみた

AWS Well-Architected Framework 入門:全体像と公式ドキュメントを整理してみた

AWS認定試験の学習で頻繁に登場する「Well-Architected Framework」について、全容を把握しきれていないという課題を解決するため、6つの柱をハンズオンで実践しながら学ぶシリーズを始めます。まず今回は、Framework の概要と情報の探し方を整理しました。
2026.07.08

はじめに

こんにちは。クラスメソッドオペレーションズの藤瀨です。

AWS Certified Solutions Architect – Associate(SAA)の学習を始めたのですが、勉強を進めるうちに「AWS Well-Architected Framework」という言葉が頻繁に出てくるものの、なかなか全体像をつかみにくいと感じました。

そこで、Well-Architected Framework の理解を兼ねて、6 つの柱を 1 つずつハンズオンで触っていくシリーズを始めることにしました。実際に手を動かしながら学ぶことで、単語を暗記するだけでは得られない、より深い理解につながるのではないかと考えています。

この記事はシリーズの第 1 回として、実際の AWS 環境を操作する前に「そもそも Well-Architected Framework とは何か」「情報がどこにまとまっているか」を整理します。同じように AWS の学習を始めたばかりの方の参考になれば嬉しいです。

AWS Well-Architected Framework とは

AWS Well-Architected Framework は、AWS 上でワークロードを設計・運用する際のベストプラクティスを整理し、アーキテクチャを一貫した観点で評価するためのフレームワークで、一般的な設計原則を基にした 6 つの柱から構成されています。「良い設計とは何か」を判断するための一貫した視点を AWS と顧客・パートナーで共有できるようにすることを目的としています。
well_architected_pillars

【参考】AWS Well-Architected(製品ページ)

一般的な設計原則

6 つの柱それぞれに個別の設計原則がありますが、そのベースとして全体に共通する「一般的な設計原則」が定義されています。

  • キャパシティー需要の予測をやめる:オンプレミスのように長期的なキャパシティを過剰に見積もるのではなく、必要に応じてリソースをプロビジョニングし、需要に合わせて拡張・縮小できる
  • 本番環境と同じ規模でテストする:クラウドならオンデマンドで本番規模のテスト環境を作り、使い終わったら削除できる
  • アーキテクチャの試行錯誤を前提に自動化する:自動化しておけば低コストで環境を複製・追跡・ロールバックできる
  • 進化し続けるアーキテクチャを前提にする:一度きりの設計で終わらせず、ビジネスの変化に合わせて継続的に更新する
  • データに基づいてアーキテクチャを決定する:設計判断がワークロードにどう影響したかをデータで確認し、改善につなげる
  • ゲームデーを通じて改善する:本番相当のイベントを意図的にシミュレーションし、組織としての対応力を高める

【参考】General design principles(一般的な設計原則)

6 つの柱

上記の一般原則を土台に、6 つの柱それぞれが個別の視点と設計原則を持っています。公式ドキュメントの定義をベースに、各柱の設計原則も整理してみました。

オペレーショナルエクセレンス(Operational Excellence)
ソフトウェアを正しく構築し、優れた顧客体験を一貫して提供するための取り組みです。チームの組織づくり、ワークロードの設計、大規模運用、そして時間をかけた改善に関するベストプラクティスを含みます。

  • ビジネスの成果を中心にチームを組織する
  • 可観測性を実装し、実用的な洞察を得る
  • 安全に自動化できる部分は自動化する
  • 小さく・頻繁で・戻しやすい変更を行う
  • 運用手順を頻繁に見直す
  • 失敗を想定しておく
  • すべての運用イベント・メトリクスから学ぶ
  • マネージドサービスを活用する

【参考】オペレーショナルエクセレンスの設計原則

セキュリティ(Security)
クラウド技術を活用してセキュリティを高めながら、データ・システム・資産を保護する能力です。

  • 強固な ID 基盤を実装する(最小権限の原則、職務の分離)
  • 追跡可能性を維持する(監視・アラート・監査)
  • すべてのレイヤーにセキュリティを適用する(多層防御)
  • セキュリティのベストプラクティスを自動化する
  • 転送中・保管中のデータを保護する
  • 人をデータから遠ざける
  • セキュリティイベントに備える

【参考】セキュリティの設計原則

信頼性(Reliability)
ワークロードが意図した機能を正確かつ一貫して実行し続ける能力です。ライフサイクル全体を通じて運用・テストする能力も含みます。5 つの設計原則があります。

  • 障害から自動的に復旧する
  • 復旧手順をテストする
  • 水平方向にスケールしてワークロード全体の可用性を高める
  • キャパシティを勘に頼らない
  • 自動化を通じて変更を管理する

【参考】信頼性の設計原則

パフォーマンス効率(Performance Efficiency)
パフォーマンス要件を満たすためにクラウドリソースを効率的に使用し、需要や技術の変化に応じてその効率を維持する能力です。5 つの設計原則があります。

  • 高度な技術を誰でも使えるようにする(マネージドサービスとして消費する)
  • 数分でグローバル展開する
  • サーバーレスアーキテクチャを使う
  • 実験を頻繁に行う
  • メカニカルシンパシーを持つ(データアクセスパターンに適した技術を選ぶ)

【参考】パフォーマンス効率の設計原則

コスト最適化(Cost Optimization)
最も低い価格でビジネス価値を提供するシステムを運用する能力です。5 つの設計原則があります。

  • クラウド財務管理を実践する
  • 消費モデルを採用する(使った分だけ支払う)
  • 全体の効率を測定する
  • 差別化につながらない重労働への支出をやめる
  • 支出を分析し、帰属を明確にする

【参考】コスト最適化の設計原則

持続可能性(Sustainability)
エネルギー消費と効率など環境への影響に着目し、リソース使用量を削減するための直接的な行動を導き出す視点です。2021 年 12 月に追加された柱で、6 つの設計原則があります。

  • 自分たちの影響を理解する
  • 持続可能性の目標を設定する
  • 使用率を最大化する
  • より効率的なハードウェア・ソフトウェアを取り入れる
  • マネージドサービスを使う
  • 下流(顧客側)への影響を減らす

【参考】 持続可能性の設計原則

柱同士のトレードオフという考え方

6 つの柱は、常にすべてを 100 点にできるわけではなく、場面によっては柱同士がトレードオフの関係になります。

たとえば「コストを抑えたい」と「パフォーマンスを最大化したい」は常に両立するわけではなく、ビジネス上の優先順位に応じてどちらを取るかを意識的に選択することが求められます。
ただし、セキュリティはあらゆる領域に適用すべきベースラインであり、オペレーショナルエクセレンスも継続的な改善を支える重要な柱です。そのため、単純に「コストのためにセキュリティを下げる」といった判断ではなく、ビジネス要件・リスク・影響を踏まえてトレードオフを評価することが重要です。

AWS Well-Architected Tool を覗いてみる

マネジメントコンソールから追加料金なしで利用できる AWS Well-Architected Tool も軽く紹介します。シリーズ最終回で詳しく扱う予定ですが、このようなツールが存在するということだけでも知っておくと後の理解がスムーズになります。

AWS Well-Architected Tool は、ワークロードに対して質問に回答することで、現在の設計が AWS のベストプラクティスにどの程度沿っているかを確認し、改善計画を整理できるセルフレビュー用のツールです。

マネジメントコンソールの検索バーで「Well-Architected Tool」と入力するとアクセスできます。「ワークロードを定義」から自分が運用しているシステムを登録すると、6 つの柱ごとに質問が用意されており、回答すると改善提案が表示される仕組みです。レビュー対象の AWS リソースを新たに作成しなくても利用できるため、AWS Well-Architected Tool 自体に追加料金はかかりません(ただし、レビュー対象のワークロードで利用している AWS リソースの料金は別途発生します)。
AWS Well-Architected Tool

【参考】 AWS Well-Architected Tool の開始方法

情報の探し方

Well-Architected 関連の情報は複数箇所に分散しているため、このセクションにまとめます。

  • Framework 本体(ホワイトペーパー):6 つの柱それぞれの設計原則とベストプラクティスがまとまった公式ドキュメント
  • レンズ(Lens):特定のユースケース(サーバーレス・SaaS・機械学習など)に特化した追加ガイドラインで、Framework 本体を補完するもの
  • AWS Well-Architected Labs:AWS が公開しているハンズオン・ワークショップ集
  • AWS Well-Architected Tool:上記を実際に自分のワークロードに当てはめてセルフチェックできるツール

参考リンク

既に掲載したものも含まれますが、改めて参考リンクの一覧を示します。

AWS Well-Architected の基本概念

各柱の導入ドキュメント
ここからそれぞれの設計原則や関連する内容のドキュメントを見つけることができます。

ハンズオン・実践

このシリーズの進め方

次回以降、以下の順でハンズオンを行いながら各柱を理解していく予定です。

  1. オペレーショナルエクセレンス(Amazon CloudWatch + AWS CloudTrail + AWS Systems Manager)
  2. セキュリティ(AWS Identity and Access Management + MFA + Amazon GuardDuty)
  3. 信頼性(マルチ AZ の Amazon RDS + Amazon EC2 Auto Scaling)
  4. パフォーマンス効率(Amazon S3 + Amazon CloudFront)
  5. コスト最適化(AWS Cost Explorer + AWS Budgets)
  6. 持続可能性(AWS Compute Optimizer での棚卸し)
  7. まとめ:AWS Well-Architected Tool でのセルフレビュー

おわりに

このブログでは、Well-Architected Framework の全体像とドキュメントの地図を整理しました。次回は「オペレーショナルエクセレンス」の柱から、実際に手を動かしていきます。

まだ学習を始めたばかりで至らない点もあるかと思いますが、同じように AWS の学習を進めている方の参考になれば幸いです。最後までお読みいただきありがとうございました!

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。

当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。

※2026年1月 アノテーション㈱から社名変更しました。


コスト最適化、打ちっぱなしで元通りになっていませんか

タグ付けも不要リソースの棚卸しも、施策は打てる。でも続ける仕組みがなければ、コストは数か月でじわじわ戻る。一度きりで終わらせず、FinOpsを組織に定着させる=CCoEの役割。最適化を回し続ける進め方を、無料資料にまとめました。

CCoE総合支援

FinOpsを定着させる資料をもらう

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事