AWS Well-Architected フレームワークとは？6つの柱などを解説
公開日
2023年5月23日
AWS Well-Architected フレームワークは、アマゾン ウェブ サービス（以下、AWS）を活用する際に参考となるベストプラクティス集です。AWSは世界1位のシェアを誇るクラウドサービスで、AWSやAWSユーザのこれまでの取り組みから導き出されたベストプラクティスがAWS Well-Architected フレームワークにまとめられています。AWS Well-Architected フレームワークを活用することで、現況とベストプラクティスを比較しながら、AWSのシステムを構築できます。
この記事では、AWS Well-Architected フレームワークの構成や内容をテーマごとに分けた「6つの柱」の内容について解説します。
AWS Well-Architected フレームワークはAWS活用のためのベストプラクティス集
AWS Well-Architected フレームワークは、企業がAWSを活用する際に参考となるベストプラクティス集です。AWSは、Amazonが2006年に提供を開始したサービスで、利便性の高さやコストの安さ、セキュリティレベルの高さから、クラウドサービス市場で世界1位のシェアを維持しています。AWS Well-Architected フレームワークには、膨大な数の事例から得た知見をもとに、構築プロセスのベストプラクティスがまとめられています。
AWS Well-Architectedの構成
WS Well-Architectedは、内容をテーマごとに分けた「6つの柱」で構成されています。具体的には、オペレーショナルエクセレンス、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6つです。また、6つの柱には、それぞれの設計原則とベストプラクティスを考えるうえで必要な観点に関する「定義」があり、それぞれの「定義」、を実現するための質問と回答となるベストプラクティスが用意されています。これらを参照することで、企業は適切にAWSを活用できるようになります。
6つの柱の具体的な内容は？
AWS Well-Architected フレームワークを参照する際には、テーマごとに分けられた「6つの柱」を確認します。6つの柱を意識すれば安定的・効率的なシステム構築が可能です。ここからは、6つの柱が対象とする領域や設計原則、どういった観点が必要なのかを説明する「定義」について解説します。
オペレーショナルエクセレンス
1つ目の柱はオペレーショナルエクセレンスです。ワークロードを効率的に実行し、ビジネス価値をもたらすために、ここではシステムの実行とモニタリング、継続的な改善に焦点を当てています。変更への対応や日常業務を管理するための標準化なども対象です。以下の5つの設計原則と4つの定義で構成されています。
■5つの設計原則
| 設計原則 | 内容 |
|---|---|
| 運用をコードとして実行する | 運用の手順をコードとして実装し、イベントに対して、対応するコードを自動的に実行する |
| 小規模かつ可逆的な変更を頻繁に行う | 失敗した場合にもすぐ回復できるように、変更は小規模に行う |
| 運用手順を頻繁に改善する | 定期的に運用手順を改善し、最適化する |
| 障害を予想する | 予測される障害に対してシナリオを立て、定期的な負荷テストを実施して対策する |
| 運用上のすべての障害から学ぶ | すべての障害から教訓を得て、改善を推進する |
■4つの定義
| 定義 | 内容 |
|---|---|
| 組織 | チームはビジネス目標やワークロード全体と役割や自分たちの責任を理解したうえで、優先順位を設定する また、優先順位を定義し、対応するために必要なサポートや学習機会を提供する |
| 準備 | ワークロードと期待される動作を理解する |
| 運用 | ビジネスの成果と顧客の成果の達成度をもとに、ワークロードの運用に関する成果を定義し、成功を評価する方法を決定する |
| 進化 | 継続的かつ段階的な改善を行うために作業サイクルを作成する |
セキュリティ
2つ目の柱はセキュリティです。クラウドのセキュリティ環境を構築するための、データとシステムを保護する方法、データの機密性、ユーザの管理、インシデント検出などが対象です。以下の7つの設計原則と6つの定義で構成されています。
■7つの設計原則
| 設計原則 | 内容 |
|---|---|
| 強力なアイデンティティ基盤を実装する | 最小権限の原則を実装し、役割分担を徹底し、適切な認証による通信を行う |
| トレーサビリティを実現する | 環境をリアルタイムで監視・アラートし、監査のアクション、変更を行う |
| セキュリティのベストプラクティスを自動化する | ソフトウェアベースの自動化されたセキュリティメカニズムを利用して、スケール機能の速度や費用対効果を改善する |
| 伝送中および保管中のデータを保護する | 機密性レベルでデータを分類し、必要なメカニズムを使用してデータを保護する |
| データに人の手を入れない | データへの直接的なアクセスや手動処理を減らす |
| セキュリティイベントに備える | 組織の要件に合ったインシデント管理や調査のポリシー、プロセスを導入し、インシデントに備える |
■6つの定義
| 定義 | 内容 |
|---|---|
| セキュリティ | オペレーショナルエクセレンスで定義した要件とプロセスを抽出し、それらをすべての領域に適用する |
| アイデンティティとアクセスの管理 | 意図した方法で承認、認証されたユーザおよびコンポーネントのみがリソースにアクセスできるようにする ユーザアクセス権はベストプラクティスを実践したうえで、最小権限で与える |
| 検出 | 発見的統制により、セキュリティの潜在的な脅威やインシデントを特定する |
| インフラストラクチャの保護 | 組織の義務または規制上の義務に準拠するために必要な、多層防御などの制御手段を用いて、クラウドやオンプレミス環境を滞りなく運用する |
| データの保護 | システム設計前にセキュリティに影響を与える基本的なプラクティスを実施する |
| インシデント対応 | セキュリティインシデントの潜在的な影響に対応し、影響を緩和する手段を講じる |
信頼性
3つ目の柱は信頼性です。期待通りの機能を実行するワークロードや、要求に応えられない場合の迅速な回復方法に焦点を当てています。以下の5つの設計原則と4つの定義で構成されています。
■5つの設計原則
| 設計原則 | 内容 |
|---|---|
| 障害から自動的に復旧する | KPIをモニタリングし、一定の値を超えた場合は、障害の通知・追跡、回避・修正を自動的に行う |
| 復旧手順をテストする | さまざまな障害のシミュレーションや過去の障害シナリオの再現し、復旧手順を検証する |
| 水平方向にスケールしてワークロード全体の可用性を高める | リソースを分散させ、1つの障害がワークロード全体に与える影響を軽減する |
| キャパシティーを推測することをやめる | ワークロードの使用率をモニタリングし、リソースの追加・削除を自動化する |
| オートメーションで変更を管理する | 変更の管理を自動化する |
■4つの定義
| 定義 | 内容 |
|---|---|
| 基盤 | システムを設計する前に、信頼性に影響を与える基本的な要件を満たしておく |
| ワークロードアーキテクチャ | ソフトウェアとインフラストラクチャの両方について事前に設計を決定する |
| 変更管理 | ワークロードやその環境に対する変化を予測してそれに対応する |
| 障害の管理 | 障害の発生時点で障害を認識し、可用性への影響を回避するための措置を講じる |
パフォーマンス効率
4つ目の柱はパフォーマンス効率です。長期的・持続的にパフォーマンスを発揮するためのコンピューティングリソースの効率化に重点をおいています。以下の5つの原則と4つの定義で構成されています。
■5つの設計原則
| 設計原則 | 内容 |
|---|---|
| 最新テクノロジーの標準化 | 専門知識を必要とするテクノロジーをサービスとして利用して、開発にリソースを集中させる |
| わずか数分でのグローバル展開 | 世界各地のリージョンを活かして、最小限のコストと低いレイテンシーでワークロードをデプロイできる |
| サーバーレスアーキテクチャの使用 | 物理的なサーバの維持・管理にかかる負担を軽減できる |
| 頻繁な実験 | 異なる対応のインスタンス、ストレージ、設定を使用した比較テストを簡単に実施できる |
| メカニカルシンパシーの重視 | クラウドサービスの使用方法を理解し、常にワークロードの目標に最適なテクノロジーアプローチを使用する |
■4つの定義
| 定義 | 内容 |
|---|---|
| 選択 | パフォーマンスを向上させるために複数のソリューションを使用し、異なる機能を有効化する |
| レビュー | ワークロードコンポーネントに対する変更を継続的に評価して検討し、パフォーマンスとコストの目標を確実に満たす |
| モニタリング | パフォーマンスをモニタリングし、問題が顧客に影響を及ぼす前に修正できるようにする |
| トレードオフ | 状況に応じて整合性や耐久性、時間やレイテンシーと引き換えに、より優れたパフォーマンスを実現することができるように考慮する |
コスト最適化
5つ目の柱はコスト最適化です。継続的にコストを抑えながら最新のアーキテクチャを構築する方法が説明されています。以下の5つの設計原則と5つの定義で構成されています。
■5つの設計原則
| 設計原則 | 内容 |
|---|---|
| 消費モデルの導入 | ビジネス要件に応じて必要なコンピューティングリソースの費用のみを支払う消費モデルを活用する |
| 全体的な効率の測定 | ワークロードのビジネス成果とその実現にかかったコストを測定し、生産性の向上によって削減したコストによって得られるメリットを把握する |
| 差別化につながらない高負荷の作業に対する投資の停止 | 責任共有モデルに従い、さらにマネージドサービスによってオペレーションの負担を軽減することで、ITインフラストラクチャの管理・運用ではなく顧客やビジネスに集中できる |
| 費用の分析と帰属関係の明確化 | システムの利用状況とコストを正確に把握することで、リソースを最適化してコストを削減する機会が得られる |
■5つの定義
| 定義 | 内容 |
|---|---|
| クラウド財務管理の実践 | 組織全体での知識の蓄積、プログラム、リソース、プロセスを実装することで、事前に合意された一連の財務目標に整合するように組織を調整し、それらを満たすメカニズムを組織に提供する |
| 経費支出と使用量の認識 | リソースのコストをそれぞれの組織や製品オーナーに帰属させ、リソースを効率的に使用し、無駄を削減する |
| 費用対効果の高いリソース | 適切なインスタンスとリソースを使用することで、コストを削減する |
| 需要を管理しリソースを供給する | ワークロードの需要に合わせたリソースを供給し、必要な分のみ利用料を支払うことでコストを削減する |
| 継続的最適化 | 既存のアーキテクチャをレビューし、要件の変化に応じて、不要になったリソース、サービス全体、システムを積極的に廃止することで、コスト効率の最適化を図る |
持続可能性
最後の柱は持続可能性です。環境への影響や、エネルギーの消費・効率性に注目して、リソースの使用量を低減するアーキテクトを提示しています。以下の6つの設計原則と6つの定義で構成されています。
■6つの設計原則
| 設計原則 | 内容 |
|---|---|
| 影響の理解 | 作業単位ごとに必要なリソースと排出量を確認し、影響を抑えながら生産性を向上させる方法を評価することで、提案された変更による影響を経時的に見積もる |
| 持続可能性の目標設定 | クラウドワークロードごとに持続可能性や長期目標を設定する |
| 使用率の最大化 | 効率的な設計で使用率を高く保ち、エネルギー効率を最大化する |
| より効率的なハードウェアやソフトウェアの新製品を予測した採用 | 新しい効率的な技術を迅速に導入できるよう、新製品を継続的にモニタリングし、設計に柔軟性を持たせる |
| マネージドサービスの使用 | マネージドサービスの活用で、リソースの使用率を最大化する |
| クラウドワークロードごとに持続可能性や長期目標を設定する | サービスを使用するために必要なエネルギーやリソースの量を削減する |
■6つの定義
| 定義 | 内容 |
|---|---|
| リージョンの選択 | ビジネス要件と持続可能性目標の両方にもとづいて、ワークロードを実装するリージョンを選択する |
| 需要に合わせた調整 | 継続的に需要に合うようにインフラストラクチャをスケールし、ユーザーサポートのために必要な最小リソースのみを使用しているか検証する |
| ソフトウェアとアーキテクチャ | パターンとアーキテクチャを改定して、使用率の低いコンポーネントを統合し、全体の使用率を上げる |
| データ | データ管理プラクティスを実装して、ワークロードのサポートに必要なプロビジョンされたストレージと、それを使用するために必要なリソースを削減する |
| ハードウェアとサービス | プロビジョンおよびデプロイする必要があるハードウェア数を最小化し、ワークロードにおいて最も効率のいいハードウェアとサービスを選択する |
| プロセスと文化 | 開発、テスト、デプロイのプラクティスを変更することで、持続可能性に対する影響を減らす機会を探す |
AWSの理解や活用に役立つAWS Well-Architected フレームワーク
AWS Well-Architected フレームワークはAWSを活用する際に参考となるベストプラクティス集です。定期的に確認し、自社の状態と照らし合わせて課題を見つけることで、システムを最適化できます。
トレンドマイクロでは、AWS Well-Architected フレームワークの中でもセキュリティの柱への対応をご支援するTrend Cloud Oneを提供しています。ぜひ、Trend Cloud Oneをご活用ください。
監修
福田 俊介
トレンドマイクロ株式会社 ビジネスマーケティング本部
ストラテジックマーケティンググループ
グループ長 シニアマネージャー
IPA 情報処理安全確保支援士（第000893号）、AWS Certified Solutions Architect – Professional保有。
約10年間クラウドセキュリティ領域およびエンドポイントセキュリティ領域に従事、クラウドの最新アーキテクチャに対応するセキュリティ戦略を立案、市場啓蒙を実施。これまでのセミナー登壇は100回を超える。専門領域は「クラウド」「サーバ」「仮想化」「コンテナ」「脆弱性」「EDR」「XDR」。
電子公告 | ご利用条件 | 個人情報保護方針 | Privacy and Legal |利用者情報の外部送信について | 製品使用許諾契約 |プレスリリース | サポート | サイトマップ | RSS
Copyright ©2024 Trend Micro Incorporated. All rights reserved