# AWS Well-Architected フレームワーク
<a name="welcome"></a>

発行日: **2024 年 11 月 6 日** ([ドキュメントの改訂](document-revisions.md))

AWS Well-Architected フレームワークは、AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを使用することによって、信頼性が高く、安全で、効率的で、費用対効果が高く、持続可能なシステムを設計して運用するための、アーキテクチャに関するベストプラクティスを学ぶことができます。

## 序章
<a name="introduction"></a>

 AWS Well-Architected フレームワークは、AWS でシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。このフレームワークを利用すると、安全で信頼性および有効性が高く、コスト効率に優れた持続可能なワークロードを AWS クラウドで設計し、運用するためのアーキテクチャに関するベストプラクティスを学ぶことができます。また、このフレームワークは、ベストプラクティスに照らしてアーキテクチャを評価し、改善すべき分野を特定する一貫した方法を提供します。アーキテクチャをレビューするプロセスは、アーキテクチャの決定に関する建設的な話し合いであり、監査メカニズムではありません。当社は、Well-Architected システムによってビジネスの成功の可能性が大いに高まると確信しています。

 AWS ソリューションアーキテクトは、さまざまな業種やユースケースに対応するソリューションのアーキテクトとして長年の経験を持っています。これまで、何千ものお客様の AWS でのアーキテクチャの設計とレビューをお手伝いしてきました。その経験に基づいて、クラウド対応システムを設計するための核となる、戦略とベストプラクティスを確立しました。

 AWS Well-Architected フレームワークは、特定のアーキテクチャがクラウドのベストプラクティスと整合しているかどうかを理解するための、一連の基本的な質問を文書化したものです。このフレームワークは、最新のクラウドベースのシステムに期待する品質を評価するための一貫したアプローチと、その品質を達成するために必要な修正を提供します。AWS が進化を続けるのにつれて、当社はお客様との共同作業から多くのことを学び、Well-Architected (よくできたアーキテクチャ) の定義に磨きをかけています。

 このフレームワークは、最高技術責任者 (CTO)、設計者、開発者、オペレーションチームメンバーなどの技術担当者を対象としています。本ドキュメントは、クラウドワークロードを設計、運用する際に使用する AWS のベストプラクティスや戦略について説明し、さらなる実装の詳細やアーキテクチャパターンへのリンクも提供しています。詳細については、「[AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp)」を参照してください。

 AWS では、ワークロードをレビューする無料サービスも提供しています。[AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/?ref=wellarchitected-wp) (AWS WA ツール) は、AWS Well-Architected フレームワークを使用してアーキテクチャをレビューおよび測定するための一貫したプロセスを提供する、クラウド上のサービスです。AWS WA ツールでは、より信頼性が高く、安全で、効率やコスト効果に優れたワークロード処理を実行するための推奨事項を提供します。

 当社は、ベストプラクティスの適用をサポートするために、[AWS Well-Architected ラボ](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp)を作成しました。このラボでは、コードとドキュメントのリポジトリを使用して、ベストプラクティスの実装を実践的に体験できます。当社は、[AWS Well-Architected パートナープログラム](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp)のメンバーである、厳選された AWS パートナーネットワーク (APN) パートナーと提携しています。これらの AWS パートナーは AWS に関する深い知識を有しており、ワークロードのレビューと改善をサポートします。

# 定義
<a name="definitions"></a>

 AWS のエキスパートは、クラウドのベストプラクティスを活用したシステムの構築において、日々、お客様を支援しています。当社は、設計が進化するにつれて発生するアーキテクチャとのトレードオフをお客様とともに考えてきました。お客様が実際の環境にシステムをデプロイするたびに、当社はそのシステムのパフォーマンスやトレードオフの結果について学んでいます。

 当社はその学びに基づいて、AWS Well-Architected フレームワークを確立しました。このフレームワークでは、お客様とパートナーがアーキテクチャを評価するための一貫したベストプラクティスや、アーキテクチャが AWS のベストプラクティスにどれだけ準拠しているのかを評価するための質問を提供しています。

 AWS Well-Architected フレームワークは、オペレーショナルエクセレンス、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性という 6 つの柱に基づいています。

 **表 1 AWS Well-Architected フレームワークの柱** 


|  **\$1.Name**  |  **説明**  | 
| --- | --- | 
|  オペレーショナルエクセレンス  |  開発をサポートし、ワークロードを効率的に実行し、運用に関するインサイトを得て、ビジネス価値をもたらすサポートプロセスと手順を継続的に改善する能力。 | 
|  セキュリティ  | セキュリティの柱では、クラウドテクノロジーを活用して、ユーザーのセキュリティ体制を向上させる方法でデータ、システム、アセットを保護する方法について説明します。 | 
|  信頼性  |  信頼性の柱には、意図した機能を期待どおりに、正しく、一貫して実行するワークロードの能力が含まれます。これには、ワークロードのライフサイクル全体を通じてワークロードを運用およびテストする能力が含まれます。このホワイトペーパーでは、AWS に信頼性の高いワークロードを実装するための、詳細なベストプラクティスのガイダンスを提供します。 | 
|  パフォーマンス効率  |  コンピューティングリソースを効率的に使用してシステム要件を満たし、需要の変化や技術の進歩に合わせてこの効率性を維持する能力。 | 
|  コスト最適化。 |  最も安価にシステムを実行して、ビジネス価値を実現する能力。 | 
|  持続可能性  |  プロビジョニングされたリソースのメリットを最大化し、必要な合計リソースを最小化することにより、エネルギー消費を削減し、ワークロードのすべてのコンポーネントにおいて効率を向上させ、持続可能性への影響を継続的に改善する能力。 | 

 AWS Well-Architected フレームワークでは、以下の用語を使用します。
+  **コンポーネント**とは、要件に合わせて提供されるコード、構成、および AWS リソースです。コンポーネントは多くの場合、技術的所有権の単位であり、他のコンポーネントとは切り離されています。
+  **ワークロード**は、ビジネス価値を実現する一連のコンポーネントを特定するために使用します。ワークロードの詳細レベルは通常、ビジネスリーダーとテクノロジーリーダーが話し合いで決定します。
+  **アーキテクチャ**は、ワークロード内でコンポーネントが連携する方法であると考えられます。多くの場合、コンポーネントが通信や対話をする方法が、アーキテクチャ図の焦点となります。
+  **マイルストーン**は、アーキテクチャにおける設計、実装、テスト、稼働、本番という製品のライフサイクル全体を通した進化において、重要な変更を記録します。
+  組織内の**テクノロジーポートフォリオ**は、ビジネスの運営に必要なワークロードの集合です。
+ **工数レベル**は、タスクの実行に必要な時間、労力、複雑さの度合いを分類したものです。各組織は、組織の工数レベルを適切に分類するために、チームの規模や専門性、ワークロードの複雑性など、追加のコンテキストを考慮する必要があります。
  + **高:** 作業には数週間または数か月かかる可能性があります。これは複数のストーリー、リリース、タスクに分割することができます。
  + **中:** 作業には数日または数週間かかる可能性があります。これは複数のリリースおよびタスクに分割することができます。
  + **低:** 作業には数時間または数日かかる可能性があります。これは複数のタスクに分割することができます。

 ワークロードを設計するときは、ビジネスのコンテキストに応じて、各柱の間でトレードオフを行います。これらのビジネス上の意思決定がエンジニアリングの優先度を左右する可能性があります。開発環境では、信頼性を犠牲にして持続可能性への影響を改善し、コストを削減するために最適化するかもしれませんし、ミッションクリティカルなソリューションでは、コストと持続可能性への影響を増加させて信頼性を最適化するかもしれません。e コマースソリューションでは、パフォーマンスが収益と顧客の購買傾向に影響することがあります。セキュリティおよび運用上の優秀性は、通常、他の柱に対してトレードオフされることはありません。

# アーキテクチャについて
<a name="on-architecture"></a>

 オンプレミス環境では、多くの場合、テクノロジーアーキテクチャの中心チームがあり、製品や機能を担当する他のチームがベストプラクティスに従うように、まとめ役として機能します。テクノロジーアーキテクチャチームには、通常、テクニカルアーキテクト (インフラストラクチャ)、ソリューションアーキテクト (ソフトウェア)、データアーキテクト、ネットワーキングアーキテクト、セキュリティアーキテクトなどの担当者が含まれます。多くの場合、これらのチームはエンタープライズアーキテクチャ機能の一部として、[TOGAF](https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework) または [Zachman Framework](https://zachman-feac.com/zachman/about-the-zachman-framework) を使用します。

 AWS では、能力を持つチームを一元化するのではなく、各チームに能力を分散させることを好みます。決定権限を分散することは、複数のチームを内部標準に準拠させるという点でリスクがあります。当社はそのようなリスクを 2 つの方法で軽減します。まず、各チームがその能力を持てるようにすることに重点を置いたプラクティス (物事のやり方、プロセス、基準、受け入れた規範) を用意し、チームが満たすべき基準の水準を引き上げているかどうかを検証する専門家を配置します。次に、基準が満たされていることを確認するための、自動チェックを実行するメカニズムを実装します。

****  
 「善意だけでは十分ではない。仕組みづくりが重要だ」- ジェフ ベゾス。

つまり、人間の最善の努力を、ルールやプロセスへの準拠をチェックするメカニズム (多くは自動化) に置き換えるということです。この分散型アプローチは、[Amazon のリーダーシップ原則](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp)によってサポートされており、お客様を起点にして逆算した、すべての役割にわたる文化を確立します。逆算は、当社のイノベーションプロセスの基本です。当社はお客様とその要望を出発点として、取り組みを定義し、推進します。お客様のことを真剣に考えているチームが、お客様のニーズに応じて製品を開発します。

 アーキテクチャについては、すべてのチームがアーキテクチャを作成し、ベストプラクティスに従う能力があることを想定しています。新しいチームがこれらの能力を獲得するために、または既存のチームがそのレベルを上げるために、チームの設計をレビューし、チームが AWS のベストプラクティスを理解するのに役立つ、プリンシパルエンジニアの仮想コミュニティへのアクセスを有効にします。プリンシパルエンジニアリングコミュニティの仕事は、ベストプラクティスを周知させ、わかりやすくすることです。例えば、これを実現する 1 つの方法として、ベストプラクティスを実例に適用することに焦点を当てた、ランチタイムトークが挙げられます。彼らの会話を録音して、新しいチームメンバー向けのオンボーディング教材として使用できます。

 AWS のベストプラクティスは、インターネット規模で数千のシステムを運用してきた当社の経験から生まれました。ベストプラクティスの定義には主にデータを活用しますが、プリンシパルエンジニアなどの専門分野に精通した人がベストプラクティスを設定することもあります。プリンシパルエンジニアは、新しいベストプラクティスが形成されるにつれて、コミュニティとして協力しながら、チームにそれを徹底させます。やがてそれらのベストプラクティスは、当社の内部評価プロセスやコンプライアンス遵守メカニズムに取り込まれて、正式なものになります。Well-Architected フレームワークは、当社の内部評価プロセスをお客様向けに実装したものであり、フィールドの役割全体で、ソリューションアーキテクチャや内部エンジニアリングチームなどのプリンシパルエンジニアリングの考えを体系化しています。Well-Architected フレームワークは、学んだことを活用できるスケーラブルなメカニズムです。

 プリンシパルエンジニアリングコミュニティが取り組んでいるアーキテクチャの分散所有に従うことにより、お客様のニーズに基づいて Well-Architected のエンタープライズアーキテクチャが生まれると当社は確信しています。テクノロジーリーダー (CTO や開発マネージャーなど) がお客様のワークロードのすべてに対して Well-Architected のレビューを実施することで、お客様のテクノロジーポートフォリオのリスクがよくわかるようになります。このアプローチを使用して、チーム全体に関わる課題を特定し、その課題に取り組むことができます。プリンシパルエンジニアは、メカニズム、トレーニング、ランチタイムトークを活用して、特定の領域についての考えを複数のチーム間で共有することができます。

# 一般的な設計原則
<a name="general-design-principles"></a>

 Well-Architected フレームワークは、クラウドでの適切な設計を可能にするための一般的な設計原則を提供します。
+  **容量ニーズの推測が不要**: ワークロードのデプロイ時に容量の決定を誤ると、費用のかかるアイドル状態のリソースが発生したり、容量の制約によるパフォーマンスへの影響に対処する必要が生じたりする可能性があります。クラウドコンピューティングにはこのような問題はありません。必要な分のみ容量を使用し、自動的にスケールインまたはスケールアウトできます。
+  **本稼働スケールでシステムをテストする**: クラウドでは、オンデマンドで本稼働規模のテスト環境を作成し、テストが完了したらリソースを削除することができます。テスト環境の支払いは実行時にのみ発生するため、オンプレミスでテストを実行する場合と比べて、わずかなコストで本番環境をシミュレートできます。
+  **アーキテクチャの実験を念頭に置いた自動化**: 自動化により、低コストでワークロードを作成およびレプリケートすることが可能になり、手作業による負担を回避できます。自動化に対する変更を追跡し、影響を監査して、必要に応じて以前のパラメータに戻すことができます。
+  **発展するアーキテクチャを検討する**: 従来の環境では、アーキテクチャに関する決定は 1 回限りの静的イベントとして実装されることが多く、システムの存続期間中に主要なバーションがいくつか発生していました。ビジネスとその状況が進化し続けるにしたがって、当初の決定では変化するビジネス要件にシステムが対応できなくなる可能性があります。クラウド上では、自動化し、オンデマンドでテストできるため、設計変更によって生じる影響のリスクを軽減できます。これにより、イノベーションを標準プラクティスとしてビジネスで活用できるよう、システムを経時的に進化させることができます。
+  **データに基づいてアーキテクチャを駆動する**: クラウドでは、アーキテクチャの選択がワークロードの動作に与える影響に関するデータを収集できます。これにより、ワークロードの改善について、事実に基づいた意思決定を行うことができます。クラウドのインフラストラクチャはコードのため、そのデータに基づいて、アーキテクチャに関する選択と改善を徐々に進めることができます。
+  **ゲームデーを利用して改善する**: ゲームデーを定期的にスケジュールし、本番環境のイベントをシミュレートすることで、アーキテクチャとプロセスのパフォーマンスをテストします。これは、改善できる箇所を把握し、組織がイベントに対応することを経験するのに役立ちます。