# AWS Well-Architected Framework
<a name="welcome"></a>

発行日: **2023 年 4 月 10 日** ([改訂履歴](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 Tool) は、AWS Well-Architected フレームワークを使ってアーキテクチャをレビューし、測定するための一貫したプロセスを提供する、クラウド内のサービスです。AWS WA ツールは、ワークロードの信頼性、安全性、効率性、コスト効率を高めるための推奨事項を提供します。

 ベストプラクティスの適用をサポートするため、[AWS Well-Architected Labs](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 フレームワーク**の柱 


|  **名前**  |  **説明**  | 
| --- | --- | 
|  運用上の優秀性  |  The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value.  | 
|  セキュリティ  | The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture. | 
|  信頼性  |  The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS.  | 
|  パフォーマンス効率  |  The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve.  | 
|  コスト最適化  |  The ability to run systems to deliver business value at the lowest price point.  | 
|  持続可能性  |  The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required.  | 

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

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

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

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

 AWS では、能力を持つチームを一元化するのではなく、各チームに能力を分散させることを好んでいます。決定権限を分散することには、複数のチームを内部標準に準拠させるといった点でリスクがあります。当社はそのようなリスクを 2 つの方法で軽減します。第 1 に、AWS には各チームにその機能を持たせることに焦点を当てた*プラクティス* (方法、プロセス、標準、受け入れられている基準) があり、エキスパートを配置して、チームが満たすべき基準を引き上げます。2 番目は、*メカニズム*を実装し、自動チェックを実行して、基準が確満たされるようにします。

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

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

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

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

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

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

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