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

公開日: **2023 年 10 月 3 日** ([改訂履歴](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 ツール](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 パートナーネットワーク (APN) パートナーと提携しています : [AWS Well-Architected パートナープログラム](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp).これらの AWS パートナーは AWS に関する深い知識を持っており、ワークロードのレビューと改善をサポートします。

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

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

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

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

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


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

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

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

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

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

 AWS では、能力を持つチームを一元化するのではなく、各チームに能力を分散させることを好んでいます。決定権限を分散することには、複数のチームを内部標準に準拠させるといった点でリスクがあります。当社はそのようなリスクを 2 つの方法で軽減します。第 1 の方法は、各チームがその職能を持てるようにするための *プラクティス* (物事の進め方、プロセス、基準、通念) であり、チームが満たすべき基準の水準を確実に引き上げるために専門家が配置されています。次に、仕組みを *導入して、* 標準への準拠を徹底させるための自動チェックを実施します。

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

つまり、人間の善意による努力を、ルールやプロセスへの準拠をチェックするメカニズム (多くは自動化) に置き換えるということです。この分散のアプローチは [Amazon のリーダーシッププリンシプル](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp)に支えられており、すべての職務においてお客様を起点に逆算して考える文化を確立しています。お客様を起点に逆算して考える (Working backward) アプローチは、当社のイノベーションプロセスの基本的な部分です。お客様、そしてお客様の要望を起点に、当社の取り組みを定義して進めます。お客様を重視するチームは、お客様のニーズに応えて製品を開発します。

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

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

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

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

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