【2023最新】AWS WellArchitectedとは?SAA保持者解説

AWSの勉強したいけど、Well-Architected Frameworkってなに？勉強したほうが良い？

という方向けの記事になります！

記事執筆者：オザック

10年以上、Web開発でバックエンド兼インフラエンジニアをしているrevenue-hackです！

AWS SAAの資格も持っており、AWSやTerraform、クラス設計の技術サポートをMENTAで行っている。

AWS Well-Architected FrameworkとはAWSのアーキテクチャを設計する上で基本設計となる、AWS公式が出している設計方針となります。

今回はAWSの基本設計であるAWS Well-Architected Frameworkについて、SAAを持っているエンジニアが解説していきます！

この記事で学べることは

AWS Well-Architected Frameworkの6つの柱(設計原則)
AWS Well-Architected Frameworkのメリット
AWS Well-Architected Frameworkのアーキテクチャについて
AWS Well-Architected Frameworkの設計方法

となります。

2分程度で読み終わるので、少しでもAWSを学びたいと思っている方は読んでみるのをおすすめします！

1 AWS Well-Architected Frameworkとは？6つの柱と設計原則
- 1.1 AWS Well-Architected Frameworkが必要な理由
- 1.2 Well-Architected Frameworkの一般的な設計原則と6つの柱
2 AWS Well-Architected Frameworkの使用方法
3 AWS Well-Architected Frameworkの勉強方法
4 AWS Well-Architected Frameworkとは？まとめ

AWS Well-Architected Frameworkとは？6つの柱と設計原則

AWS Well-Architected FrameworkとはAWSを構築・運用する際のベストプラクティスをまとめたフレームワークになります！

このフレームワークは、AWSアーキテクチャにおける6つの柱に基づいて設計されていて、

AWSアーキテクトがクラウドアプリケーションを設計する際に、問題を特定し、問題を解決するための具体的な手順を提供してくれます。

ただ正直勉強していくには、ドキュメントも読みづらいし、完全に全てを覚えるというのは難しいかな−とは思いますが、

頭の片隅に入れておいて、なにか困った時はドキュメントを見に行くと良いと思います！

オザック

そのためこの記事をブックマークしておくのがおすすめです！

AWS Well-Architected Frameworkが必要な理由

AWS Well-Architected Frameworkが必要な理由は、クラウドソリューションの昨今の複雑性に対応するためです！

AWSでアーキテクチャを構築するためは、多くの提供されているサービスの特性を理解し、正しく組み合わせることが重要です。

また、AWSはリソースの更新や追加が継続的に行われるため、アプリケーションの最適化を継続的に行う必要があり、

常にそれに対応しているかをチェックするためにもWell-Architected Frameworkというベストプラクティスとなる指針は必要となります。

Well-Architected Frameworkの一般的な設計原則と6つの柱

まずWell-Architectedフレームワークでは一般的な設計原則を提供しています

一般的な設計原則

キャパシティーニーズの推測が不要
本稼働スケールでシステムをテストする
⾃動化によってアーキテクチャでの実験が容易に
発展するアーキテクチャが可能に
データに基づいてアーキテクチャを駆動
ゲームデーを利用して改善する

※AWS Well-Architectedフレームワークの一般的な設計原則参照

この設計原則はAWSを構築する上では意識しておくと良いです！

特に上記の太文字になっている部分は、構築で必ず意識しておかなければいけません！

またWell-Architectedフレームワークには6つの柱というものを掲げています。

6つの柱

優れた運用効率
セキュリティ向上
信頼性向上
パフォーマンス効率アップ
コストの最適化
持続可能性

オザック

一つ一つポイントを説明していきます！

優れた運用効率

運用をコードとして実行する
小規模かつ可逆的な変更を頻繁に行う
運用手順を定期的に改善する
障害を予想する
運用上のすべての障害から学ぶ

という点がポイントになってきます！

また優れた運用効率のベストプラクティスとして以下の質問に答えられると良いです！

OPS 1: 優先順位はどのように決定すればよいでしょうか?
OPS 2: ビジネスの成果をサポートするために、組織をどのように構築しますか?
OPS 3: 組織の文化はビジネスの成果をどのようにサポートしますか?
OPS 4: どのようにワークロードを設計して、その状態を理解できるようにするのですか?
OPS 5: どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか?
OPS 6: どのようにデプロイのリスクを軽減しますか?
OPS 7: ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか?
OPS 8: ワークロードの正常性をどのように把握しますか?
OPS 9: オペレーションの正常性をどのように把握しますか?
OPS 10: ワークロードと運用イベントはどのように管理しますか?
OPS 11: オペレーションを進化させる方法

これらの質問に答えられると、運用上の効率について考慮されていると言えます。

セキュリティ向上

セキュリティは、AWSアプリケーションを設計する際に重要な柱の一つです。

強力なアイデンティティ基盤の実装
トレーサビリティの実現
全レイヤーでセキュリティを適用する
セキュリティのベストプラクティスを自動化する
伝送中および保管中のデータの保護
データに人の手を入れない
セキュリティイベントに備える

という点がポイントになってきます！

またセキュリティ向上のベストプラクティスとして以下の質問に答えられると良いです！

SEC 1: ワークロードを安全に運用するには、どうすればよいですか?
SEC 2: ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
SEC 3: 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
SEC 4: セキュリティイベントをどのように検出し、調査していますか？
SEC 5: ネットワークリソースをどのように保護しますか?
SEC 6: コンピューティングリソースをどのように保護していますか?
SEC 7: どのようにデータを分類していますか?
SEC 8: 保管時のデータをどのように保護していますか?
SEC 9: 転送時のデータをどのように保護していますか?
SEC 10: インシデントの予測、対応、復旧はどのように行いますか?

信頼性向上

アプリケーションでは常に障害がつきものです。

その障害など予期せぬときに、ちゃんと迅速に回復する事はアプリケーションの信頼性を担保する上では重要なことになります。

例えば

フェイルオーバー設計
キャパシティ推測をやめる
障害時の復旧計画

などを設計時に考慮しなければいけません。

信頼性でのポイントは

障害から自動的に復旧する
復旧手順をテストする
水平方向にスケールしてワークロード全体の可用性を高める
キャパシティーを推測することをやめる
オートメーションで変更を管理する

となります。

また信頼性のベストプラクティスとして以下の質問に答えられると良いです！

REL 1: サービスクォータと制約はどのように管理しますか?
REL 2: ネットワークトポロジをどのように計画しますか?
REL 3: どのようにワークロードサービスアーキテクチャを設計すればよいですか?
REL 4: 障害を防ぐために、分散システムの操作をどのように設計しますか?
REL 5: 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか?
REL 6: ワークロードリソースをモニタリングするにはどうすればよいですか?
REL 7: 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか?
REL 8: 変更はどのように実装するのですか?
REL 9: データはどのようにバックアップするのですか?
REL 10: ワークロードを保護するために障害分離をどのように使用しますか?
REL 11: コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか?
REL 12: どのように信頼性をテストしますか?
REL 13: 災害対策 (DR) はどのように計画するのですか?

パフォーマンス効率アップ

パフォーマンス効率化アップは、要件に対して、柔軟に最適化されたリソースを割り当てられることを重点においています。

例えば

サーバレスで対応出来るところはする
何度もデプロイなどを行い効率性をテストする

ことが重要です！

パフォーマンス効率のポイントは

最新テクノロジーの標準化
わずか数分でグローバル展開する
サーバーレスアーキテクチャを使用する
より頻繁に実験する
システムに対する精通の程度を考慮する

になります。

またパフォーマンス効率のベストプラクティスとして以下の質問に答えられると良いです！

PERF 1: どのように最良パフォーマンスのアーキテクチャを選択するのですか?
PERF 2: コンピューティングソリューションはどのように選択するのですか?
PERF 3: ストレージソリューションをどのように選択していますか?
PERF 4: データベースソリューションをどのように選択していますか。
PERF 5: どのようにネットワーキングソリューションを選択するのですか?
PERF 6: ワークロードを進化させるためにどのように新機能を取り込んでいますか？
PERF 7: リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか?
PERF 8: トレードオフをどのように使用するとパフォーマンスが向上するのですか?

コスト最適化

コスト最適化は、費用の高いクラウドのコスト回避に重点を置いています。

時間の経過と共に、

支出の把握
資金配分の管理
適切なリソースのサイズやタイプの選択

など過剰にビジネスニーズを満たすためのスケーリングを考慮していく必要があります。

ポイントとしては

クラウド財務管理の実装
消費モデルを導入
全体的な効率を測定する
差別化につながらない高負荷の作業に費用をかけるのをやめる
費用を分析および属性化する

になります！

またコスト最適化のベストプラクティスとして以下の質問に答えられると良いです！

COST 1: クラウド財務管理はどのように実装しますか?
COST 2: 使用状況をどのように管理しますか?
COST 3: 使用状況とコストをどのようにモニタリングしますか?
COST 4: 不要なリソースをどのように削除しますか？
COST 5: サービスを選択するとき、どのようにコストを評価しますか?
COST 6: コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか?
COST 7: コストを削減するには、料金モデルをどのように使用したらよいでしょうか?
COST 8: データ転送料金についてどのように計画していますか？
COST 9: どのように需要を管理し、リソースを供給しますか?
COST 10: 新しいサービスをどのように評価していますか？

持続可能性

持続可能性の柱は実行中のワークロードを常に維持して運用できる事に重点を置いています。

主にポイントは

影響を理解する
持続可能性の目標を設定する
使用率を最大化する
より効率的なハードウェアやソフトウェアの新製品を予測して採用する
マネージドサービスを使用する
クラウドワークロードのダウンストリームの影響を軽減する

です！

また持続可能性のベストプラクティスとして以下の質問に答えられると良いです！

SUS 1: リージョンをどのように選択して、持続可能性目標を目指しますか?
SUS 2: ユーザーの行動パターンをどのように利用して、持続可能性目標を目指しますか?
SUS 3: ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか?
SUS 4: データのアクセスパターンおよび使用パターンをどのように利用して、持続可能性目標を目指しますか?
SUS 5: ハードウェアの管理および使用のプラクティスは、持続可能性目標を目指すうえでどのように役立ちますか?
SUS 6: 開発およびデプロイのプロセスは、持続可能性目標を目指すうえでどのように役立ちますか?

これらの6つの柱のポイントを抑えて設計することがAWSでアーキテクチャを構築する上では重要であり、

それを実現するベストプラクティスがWell-Architected Frameworkということです！

AWS Well-Architected Frameworkの使用方法

AWS Well-Architected Frameworkはベストプラクティスを達成するためのツールです。

注意ポイント

ただ必ずしも準拠しなければならないものではなく、ケースバイケースでは準拠しないケースもあります

オザック

それを踏まえて使い方を見ていきましょう！

以下Well-Architected Frameworkを適用するための方法

ホワイトペーパーを使う方法
Well-Architected Framework Toolを使う方法
パートナーを利用する

ホワイトペーパーを使用する

AWS Well-Arhitected Frameworkを使うためのフロー
要件定義	ホワイトペーパーを使って、システム要件的に問題ないかをチェックしながら要件検討していく
設計	ホワイトペーパーを使いながら、リソースごとの要件を適切に設計していく
構築	リソースごとに構築した後、リリース前にインフフラ構成にセキュリティホールやその他問題点がないかを、ホワイトペーパーを使いながら確認していく
運用	ホワイトペーパーで定期的にレビューを実施する