AWS Well Architectedについての概要を説明

最終更新日：2026年8月10日

Well-Architectedについて

項目	AWS	Microsoft Azure	Google Cloud
世界シェア	約33%（首位）	約22%	約11%
強み	サービス数・実績	Microsoft製品連携	データ分析・AI
無料枠	12ヶ月+常時無料	12ヶ月無料	常時無料枠あり
主な資格	CLF / SAA / SAP	AZ-900 / AZ-104	ACE / PCA

Well-Architectedの概要について記載します。

Well-Architectedとは

AWSの概念、設計原則や、ベストプラクティスが説明されたホワイトペーパーの事です。
公式の説明にはあくまでも設計の参考になる情報であって、必ずしも情報の通りに設計する必要はないという事が念入りに記載されているので、参考程度に確認すると良いでしょう。

Well-Architectedの6つの柱

Well-Architectedは以下の６本の柱を基本として記載してあります。

・運用上の優秀性の柱：運用の自動化や、障害対応、定期的な運用メンテナンスなどについての説明。

・セキュリティの柱：データの暗号化や権限設定、脅威の検出などによるセキュリティについての説明。

・信頼性の柱：障害復旧や可用性、変更管理設定などによる信頼性についての説明。

・パフォーマンス効率の柱：アーキテクチャやストレージの選択などによる効率化についての説明。

・コスト最適化の柱：AWSの使用状況や契約などによるコスト最適化についての説明。

・持続可能性の柱：リソース利用の最大化や環境負荷の低減などによるサステナビリティについての説明。

運用上の優秀性

運用上の優秀性の5つの設計原則と4つのベストプラクティス分野について簡単に要約して記載します。

設計原則

・運用をコードとして実行する:運用をコード化して環境に適用する事で、人為的なミスを抑制し、イベントへの一貫性のある対応を実現できる事。

・小規模かつ可逆的な変更を頻繁に行う: ワークロード（運用をコード化した物）を定期的に更新可能な設計で構築し運用する事で、不要な変更はすぐ戻せるため、有益な変更のみが蓄積されていく事。

・運用手順を定期的に改善する: 定期的な負荷テストやワークロード改良の際に運用手順を改善する余地を探す事で、チームが手順を熟知している事の確認、検証をする事。

・障害を予想する：事前に定期的な負荷テストを実施する事で、潜在的な障害の原因を特定し対策する事。

・運用上のすべての障害から学ぶ: 障害から学んだ教訓を通して、改善を推進していく事。

ベストプラクティス

・組織：業務の優先順位の決め方、組織内の役割や関係性の考え方、働き方による業務の効率化などについて記載されています。

・準備：運用の準備、つまり設計について「テレメトリの設計、フローの改善、デプロイのリスク緩和、運用準備の理解」の4項目で記載されています。

・運用：ワークロードの状態、運用の状態を確認する方法、イベントへの応答の仕方について記載されています。

・進化：障害などを学習、共有、改善していく事で運用を進化させていく為のAWSの活用方法が記載されています。

セキュリティ

セキュリティの7つの設計原則について簡単な要約を記載し、5つのベストプラクティス領域について概要を記載します。

設計原則

・強力なアイデンティティ基盤を実装する:職務分掌を徹底し、それに応じた最小限のセキュリティを設定する事で、適切な認証を用いたAWSリソースとの通信を実現する事。

・トレーサビリティを実現する: リアルタイムで監視を実施して、ログとメトリクスの収集をシステムに統合する事。

・すべてのレイヤーでセキュリティを適用する:セキュリティコントロール機能を全てのレイヤーに適用する事。深層防御(攻撃を遅らせる事)が狙い。

・セキュリティのベストプラクティスを自動化する:ソフトウェアベースのセキュリティを自動化する事で、迅速かつコスト効率の良い方法で安全にスケールできる事。

・転送中および保管中のデータを保護する: 機密度レベルでデータを分類して、必要に応じて暗号化、トークン分割、アクセスコントロールなどを実施する事。

・データに人を近づけない:ツールなどを使用して、データに対する直接的なアクセスや手動処理の必要性を低減する事。誤処理、改変、ヒューマンエラーを防ぐのが目的。

・セキュリティイベントに対して備える: 組織の要件に合わせたインシデント管理、監査を導入したり、検出、調査、復旧の自動化を実施、インデント対応シミュレーションを実行するなどして備える事。

ベストプラクティス

・アイデンティティ管理とアクセス管理：ユーザとマシンに対してのID管理、権限管理について記載されています。

・検出：潜在的なセキュリティ設定の誤り、脅威、予期しない動作を特定する手段として、AWSでの設定、調査という観点で記載されています。

・インフラストラクチャの保護：セキュリティについて、ネットワークの保護、コンピューティングの保護という観点で記載されています。

・データ保護：データの保護の仕方について、データ分類、保管中の保護、転送中の保護という観点で記載されています。

・インシデント対応：インシデントに対する対応として、クラウドレスポンスの設計目標を確認すること、対応の処理について、教育、準備、シミュレーションの観点で記載されています。

信頼性

信頼性の5つの設計原則について簡単な要約を記載し、4つのベストプラクティス領域について概要を記載します。

設計原則

・障害から自動的に復旧する:障害からの復旧プロセスを自動化する際は、重要業績評価指標 (KPI) に関わるワークロードをモニタリングする事。

・復旧手順をテストする:クラウドでは、システム障害の発生や復旧の手順が検証できるため実施する事。

・水平方向にスケールして集合的なワークロードの可用性を高める: リソースを分散させて処理する事で、ワークロードのシステム全体に及ぼす影響を軽減する事。

・キャパシティーを勘に頼らない:リソースの追加、削除を自動化する事で、リソースの飽和状態などによる障害を防ぐことができる。

・自動化で変更を管理する:変更の管理は自動化する事。

ベストプラクティス

・基盤：ネットワーク環境の信頼性について、サービスクォータの管理と制約、ネットワークトポロジのプロビジョニングという観点で記載されています。

・ワークロードのアーキテクチャ：高い信頼性を保つ為のワークロードのパターンについて、サービスアーキテクチャの実装、障害を防ぐ分散システムのソフトウェア設計、軽減する分散システムのソフトウェア設計という観点で記載されています。

・変更の管理：ワークロードを信頼できる形で実装する為の方法を、リソースをモニタリングする、需要の変化に適応するようにモニタリングする、変更の実装という観点で記載しています。

・障害の管理：障害を管理してワークロードに与える影響を防ぐ方法について、データのバックアップ方法、障害部分を切り離したワークロードの保護、コンポーネントの障害に耐えられるワークロード設計、弾力性テストする方法、被害対策(DR)の計画という観点で記載しています。

パフォーマンス効率

パフォーマンス効率の5つの設計原則について簡単な要約を記載し、4つのベストプラクティス領域について概要を記載します。

設計原則

・高度なテクノロジーを誰でも使えるようにする:複雑な運用はクラウドベンダーに委託する事。開発に集中する事が目的。

・数分でグローバルに展開する: 世界各地にAWSのリージョンはあるため、素早く情報の展開が可能である事。

・サーバーレスアーキテクチャを使用する: サーバレスアーキテクチャを利用する事で、物理サーバーの管理の負担を取り除く事。

・より頻繁に実験する:迅速な比較テストが実施できる環境なため、異なるタイプのインスタンス、ストレージ、および設定などで比較テストを頻繁に実施する事。

・メカニカルシンパシーを考慮する:データベースを作成するときはデータアクセスパターン考慮するなどの事。

ベストプラクティス

・選択：パフォーマンス、コンピューティング、ストレージ、データベース、ネットワークという観点で最適なアーキテクチャを選択する方法を記載しています。

・レビュー：ワークロードのパフォーマンス向上に関わるAWSのサービスの活用方法について記載されています。

・モニタリング：AWSのサービスを活用した監視について記載されています。

・トレードオフ：整合性、耐久性、および時間とレイテンシーの余裕と引き換えに、パフォーマンスが向上するトレードオフを積極的に考慮していき効率化する方法を記載しています。

コスト最適化

コスト最適化の5つの設計原則について簡単な要約を記載し、5つのベストプラクティス分野について概要を記載します。

設計原則

・クラウドの財務管理の運用:リソースの使用量管理など財務管理の運用に力をいれる事。

・消費モデルを導入する:リソースを使用しない時に停止して、コストを削減する事。

・全体的な効率を測定する:ビジネスの成果とデリバリー関連コストを測定する事。生産性や機能性の向上、コスト削減によるメリットを理解するため。

・付加価値を生まない作業への資金投入をやめる:AWSを使用する事で手間のかかる運用作業への負担が解消される事。

・費用を分析し、帰結させる:システムの使用状況やコストを把握できる機能があるため、コストを最適化できる事。

ベストプラクティス

・クラウドの財務管理の実践：AWSでのコストの使用状況を最適化するための方法を、機能オーナーシップ、財務とテクノロジーのパートナーシップ、クラウドの予算と予測、コストを意識したプロセス、コストを意識した文化、コスト最適化によるビジネス価値の最適化という観点で説明しています。

・支出と使用量の認識：組織内のリソース配分を決定し、無駄を削減する方法を、ガバナンス、コストと使用量のモニタリング、廃棄という観点で説明しています。

・費用対効果の高いリソース：費用対効果の高いリソース作成するために考慮すべき事を、サービスを選択する際のコスト評価、正しいリソースタイプ、リソースサイズ、リソース数の選択、最適な料金モデルの選択、データ転送の計画という観点で説明しています。

・需要と供給を一致させる：AWSでの需要管理とリソース供給の方法を、ワークロードの分析、需要管理、需要ベースの供給、時間ベースの供給という観点で説明しています。

・継続的最適化：AWSの新機能を使用してワークロードを最適化していく方法について、ワークロードのレビュープロセスの開発、サービスのレビューと運用という観点で説明しています。

持続可能性

2021年12月に追加された持続可能性の柱について、6つの設計原則と6つのベストプラクティス分野を簡単に要約して記載します。クラウドワークロードが環境に与える影響を理解し、削減していくことを目的とした柱です。

設計原則

・影響を把握する:ワークロードが環境に与える影響を、コスト等の指標と同様に継続的に計測・把握する事。

・持続可能性の目標を設定する:ワークロードごとに長期的な目標を設定し、投資対効果を計画する事。

・使用率を最大化する:サイジングやワークロードの適切な配置によって、リソースに投入したエネルギーを無駄なく活用する事。

・新しくより効率的なハードウェアやソフトウェアの提供を予測して採用する:継続的に登場する効率性の高い新しいオファリングを早期に取り入れる事。

・マネージド型サービスを使用する:リソースの利用率を高めやすいマネージド型サービスを活用し、共有インフラのスケールメリットを活かす事。

・クラウドワークロードによる下流への影響を減らす:エンドユーザー側で必要とするデバイスやネットワークの負荷を削減する事。

ベストプラクティス

・リージョンの選択：再生可能エネルギー比率などを考慮したリージョン選択について記載されています。

・需要に対する認識：需要と供給の連動、不要になったリソースの削除など、需要側の管理について記載されています。

・ソフトウェアとアーキテクチャのパターン：効率的なソフトウェア設計やアーキテクチャパターンの採用について記載されています。

・データパターン：データのライフサイクル管理や、不要なデータの削減・圧縮・階層化について記載されています。

・ハードウェアとサービスのパターン：ワークロードの要件に合わせた最小限のハードウェア選択について記載されています。

・プロセスと文化：組織内で持続可能性を意識した開発・運用プロセスや文化を根付かせる方法について記載されています。

押さえておきたいポイント

• Well-Architected Frameworkは、運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6つの柱で構成される設計指針であり、絶対的なルールではなく設計判断のためのベストプラクティス集として活用するものです。
• 各柱には設計原則とベストプラクティス領域が定義されており、新規設計時のチェックリストや、既存環境を見直す際の観点として活用できます。
• AWSマネジメントコンソールから無料で利用できる「AWS Well-Architected Tool」を使うと、各柱の質問に回答する形でワークロードを評価し、改善余地を可視化できます。

よくある質問

Well-Architected Frameworkは何本の柱で構成されていますか？

2021年12月に追加された「持続可能性」の柱を含め、現在は運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6本の柱で構成されています。

Well-Architectedの内容通りに設計しないといけませんか？

必須ではありません。AWS公式もあくまで設計の参考情報と位置付けており、必ずしも記載の通りに設計する必要はないとされています。自社の要件やコストバランスに応じて取捨選択して活用するのが前提です。

Well-Architectedのレビューはどのように行えますか？

AWSマネジメントコンソールから無料で利用できる「AWS Well-Architected Tool」を使うと、各柱の質問に回答する形でワークロードを評価し、リスクの高い箇所や改善余地を可視化できます。

最後に

設計原則を意識するだけでもかなり参考になる内容だと感じました。ベストプラクティスの詳細な内容については、AWSを具体的にどう活用すれば良いのかわからない時、既存の環境を見直して効率化したい時などに活用すると良いかと思います。また、レビュー用にAWS Well-Architected Tool というサービスもあるのでそういったサービスを利用するのも良いかもしれません。