はじめに
AWSアーキテクチャの設計原則について学習したので、その内容をまとめたいと思う。Well-Architected Framework
まずAWSアーキテクチャの設計原則は上記のWell-Architected Frameworkに支えられている。 このフレームワークは以下の3つの内容で構成されている。 ・Well-Architected Framework ホワイトペーパー ・AWSのSAまたは認定パートナーによる支援制度 ・Well-Architected Toolこれらを順に詳細に見ていくことで、Well-Architected Framework、ひいてはAWSアーキテクチャの設計原則を理解していく。
Well-Architected Framework ホワイトペーパー
開発工程の流れから話すと、 要件定義→設計→構築→運用 という順で開発工程は存在する。この設計について5つの要素に分解して、（必ずではないが）準拠することを推奨しているというものだ。5つの分解要素とは以下のとおりである。 ・Reliability（信頼性） ・Performance Efficiency（パフォーマンス効率性） ・Security（安全性） ・Cost Optmization（コスト最適化） ・Operational Excellence（運用上の優秀性）である。
例えば、AZの選択時に信頼性（災害への対応）を上げたければ、1つのリージョンにつき2つのAZを利用（マルチAZという）すればよい。またRoute53を介してのマルチリージョン設計をすれば、同じシステム構成をフェイルオーバーすることでも信頼性は担保される。
ここで、設計時のみ着目するという言い方を上ではしているが、どのフェーズでもホワイトペーパーを確認してAWSを設計することで、5つの要素をより強固にしていく。
AWSのSAまたは認定パートナーによる支援制度
これとWell-Architected ToolはWell-Architected Frameworkdのような根本の設計原則ではない。 Well-Architected Frameworkにどれくらい準拠しているかの程度のチェックの話だ。 そして、題名の通り、Amazonのサポート社員やAmazonにパートナーだと認められた社員にチェックさせることによって、程度を調査される支援制度のことをいう。Well-Architected Tool
上記は人がやるのに対して、こちらはAWS自身で調べる、いわばセルフチェック機能だ。 構築・運用中のアプリケーションがベストプラクティスになってるかを検証してくれる機能である。 大きく4つの流れで検証してくれる。 ワークロードの定義→レンズ載せ一定→マイルストーン→レビューである。ワークロードの定義ではアプリケーションのビジネス価値を定義する。大それたことを言っているが、業種・業界の選択など、基本的な情報の入力である。
次に、レンズの設定では、アプリケーションの評価を行う。
次に、マイルストーンでは、アプリの変更内容を表示してくれる。(Gitのような機能がAWSにもついているというイメージ)
最後に、レビューでは、5つの構成要素に沿った質問を50～60問程度答えていけば、Well-Architected Frameworkに則るにはこうした方がよい、という改善案がでてくる
という流れでセルフチェックを行うのである。