[アップデート] AWS Well-Architected フレームワークおよび AWS Well-Architected ツールが更新されたので、どこが変わったのかを調べてみた

本日のアップデートにて Well-Architected フレームワークおよび、Well-Architected ツールの内容が更新されました。

• Updates to the AWS Well-Architected Framework and the AWS Well-Architected Tool

Well-Architected ツールの設問数を見てみると、46 → 52 に変わっているのが判ります。

既に Well-Architected フレームワークの最新版を日本語で利用できますので、こちらよりご確認ください。

• AWS Well-Architected フレームワーク（2020年7⽉版）

本記事では AWS Well-Architected フレームワーク（2019年7月版）と見比べつつ、どのようなところに追加、変更があった箇所をまとめてみました。（細かい文言までは比較できてませんので、あしからず）

柱の定義

Well-Architected には 5 つの柱がありますが、まずは柱についての説明の差分を確認してみます。

名前	2019年7月版	2020年月版
運用上の優秀性	ビジネス価値を提供し、サポートのプロセスと⼿順を継続的に向上させるためにシステムを稼働およびモニタリングする能⼒	開発をサポートし、ワークロードを効率的に実⾏し、運⽤に関する洞察を得て、ビジネス価値をもたらすためのサポートプロセスと⼿順を継続的に改善する能⼒
セキュリティ	リスク評価とリスク軽減の戦略を通してビジネスに価値をもたらす、情報、システム、アセットのセキュリティ保護機能	このセキュリティの柱では、データ、システム、資産を保護して、クラウドテクノロジーを活⽤し、セキュリティを向上させる機能について説明します
信頼性	インフラストラクチャやサービスの中断から復旧し、需要に適したコンピューティングリソースを動的に獲得し、誤設定や⼀時的なネットワークの問題といった中断の影響を緩和する能⼒	期待されるタイミングで、意図した機能を正確かつ⼀貫して実⾏するワークロードの能⼒。これには、そのライフサイクル全体を通じてワークロードを運⽤およびテストする機能が含まれます
パフォーマンス効率	システムの要件を満たすためにコンピューティングリソースを効率的に使⽤し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能⼒です	同文
コスト最適化	最も低い価格でシステムを運⽤してビジネス価値を実現する能⼒	同文

「信頼性」においては以前までは「中断の影響を緩和する能力」という内容でしたが、最新版では「一貫して実行するワークロード能力」「テストする機能が含まれる」といったように、そもそもシステムが停止しないためにどうするか、ということを強く意識した内容に変更されているように見えました。

それでは、それぞれの柱の設問項目を見てみましょう。

細かい文言の変更などは拾っていませんが、設問が追加されたもの、設問文が大きく変更されているものには私の判断で (NEW!) とつけました。

運用上の優秀性（9項目→11項目）

設計原則

設計原則は 6 つから、5つに変更されていました。

2019年7月版	2020年7月版
・運⽤をコードとして実⾏する ・ドキュメントに注釈を付ける ・定期的に、⼩規模な、元に戻すことができる変更を適⽤する ・運⽤⼿順を定期的に改善する ・障害を予想する ・運用上のすべての障害から学ぶ	・運用をコードとして実行する ・⼩規模かつ可逆的な変更を頻繁に⾏う ・運⽤⼿順を定期的に改善する ・障害を予想する ・運用上のすべての障害から学ぶ

設問項目としては組織としてクラウドの活用を引っ張るサポートチーム（CCoE 的なものでしょうか）を意識した設問が増えているように思います。

これは運用上の優秀性のベストプラクティスは従来、「準備」「運用」「進化」の 3 つでしたが、今回より「組織」が追加されて 4 つのベストプラクティスに変わっていることからも伺えます。

「組織」

OPS 1. 優先順位はどのように決定すればよいでしょうか?

だれもが、ビジネスを成功させるうえで自分が果たす役割を理解する必要があります。リソースの優先順位を設定するため、共通の目標を設定してください。これにより、取り組みから得られるメリットが最大化されます。

(NEW!) OPS 2. ビジネスの成果をサポートするために、組織をどのように構築しますか?

チームはビジネスの成果を達成するうえでの役割を理解する必要があります。チームは他のチームが成功するためのそれぞれの役割を理解し、自分たちのチームが成功するための他のチームの役割を理解し、目標を共有する必要があります。責任、所有権、意思決定方法、意思決定を行う権限を持つユーザーを理解することは、労力を集中的に投入し、チームの利点を最大化するのに役立ちます。

(NEW!) OPS 3. 組織の文化はビジネスの成果をどのようにサポートしますか?

チームメンバーにサポートを提供することで、チームメンバーがより効果的に行動し、ビジネスの成果をサポートできるようにします。

「準備」

OPS 4. どのようにワークロードを設計して、その状態を理解できるようにするのですか?

ワークロードを設計する際には、すべてのコンポーネント (メトリクス、ログ、トレースなど) にわたって内部状態を理解するために必要な情報が送出されるようにします。そうすることによって、適時に有用な返答を提供できるようになります。

OPS 5. どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか?

リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。

OPS 6. どのようにデプロイのリスクを軽減しますか?

品質に関する迅速なフィードバックを提供し、望ましい結果をもたらさない変更から迅速に復旧できるようにするアプローチを採用します。このような手法を使用すると、変更のデプロイによって生じる問題の影響を軽減できます。

OPS 7. ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか?

ワークロード、プロセス、手順、従業員の運用準備状況を評価し、ワークロードに関連する運用上のリスクを理解するようにします。

「運用」

OPS 8. ワークロードの正常性をどのように把握しますか?

ワークロードメトリクスの定義、キャプチャ、分析をすると、適切なアクションを取れるようにワークロードイベントの可視性を高めることができます。

OPS 9. オペレーションの正常性をどのように把握しますか?

オペレーションメトリクスを定義し、キャプチャし、分析することで、オーペレーションイベントの可視性を高め、適切なアクションがとれるようになります。

OPS 10. ワークロードと運用イベントはどのように管理しますか?

イベントに対応するための手順を準備、検証してワークロードの中断を最小限にします。

「進化」

OPS 11. オペレーションを進化させる方法

漸進的な継続的改善に時間とリソースを費やすことで、オペレーションを効果的かつ効率的に進化させることができます。

セキュリティ（11項目→10項目）

設計原則

セキュリティの柱においては設計原則に変更はなく、以下の 7 つです。

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

設問項目数としては減っていますが、旧バージョンのいくつかの設問が統合されたという感じで、大きく変わりは無いように思います。

ベストプラクティスは 5 つから 6 つに変更されていますので、その対応によって設問が更新されたのかもしれませんね。

2019年7月版	2020年7月版
・アイデンティティ管理とアクセス管理 ・発見的統制 ・インフラストラクチャ保護 ・データ保護 ・インシデント対応	・セキュリティ ・Identity and Access Management ・検出 ・インフラストラクチャ保護 ・データ保護 ・インシデント対応

「セキュリティ」

(NEW!) SEC 1. ワークロードを安全に運用するには、どうすればよいですか?

ワークロードを安全に運用するには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。組織レベルおよびワークロードレベルにおいて、運用上の優秀性で定義した要件とプロセスを抽出し、それらをすべての領域に適用します。AWS や業界のレコメンデーションおよび脅威インテリジェンスを最新に保つことで、脅威モデルと管理の目標を進化させることができます。セキュリティプロセス、テスト、検証を自動化することで、セキュリティオペレーションをスケールできます。

「Identity and Access Management」

(NEW!) SEC 2. ユーザー ID とマシン ID はどのように管理したらよいでしょうか?

安全に AWS ワークロードを運用するアプローチには、管理する必要があるアイデンティティが 2 種類あります。管理およびアクセス権を付与する必要があるアイデンティティのタイプを理解することで、適切な ID が適切な条件下で適切なリソースにアクセスできるようになります。ユーザー ID: 管理者、開発者、オペレーター、エンドユーザーは、AWS 環境とアプリケーションにアクセスするために ID を必要とします。これらの者は、あなたの組織のメンバー、または共同作業を行う外部ユーザーで、ウェブブラウザ、クライアントアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースを操作する人たちです。マシン ID: サービスアプリケーション、運用ツール、およびワークロードには、たとえばデータの読み取りを行うために、AWS のサービスにリクエストを送るための ID が必要です。このような ID には、Amazon EC2 インスタンスや AWS Lambda 関数など、AWS 環境で実行されているマシンが含まれます。また、アクセスを必要とする外部関係者のマシン ID を管理することもできます。さらに、AWS 環境にアクセスする必要があるマシンが AWS 外にある場合もあります。

(NEW!) SEC 3. 人とマシンのアクセス許可はどのように管理すればよいでしょうか?

アクセス許可を管理して、AWS とワークロードへのアクセスを必要とするユーザー ID やマシン ID へのアクセスを制御します。アクセス許可は、どの条件で誰が何にアクセスできるかを制御します。

「検出」

SEC 4. セキュリティイベントをどのように検出し、調査していますか？

ログやメトリクスからイベントを可視化して把握し、分析します。セキュリティイベントや潜在的な脅威に対して措置をとることで、ワークロードを保護します。

「インフラストラクチャ保護」

SEC 5. ネットワークリソースをどのように保護しますか?

何らかの形式のネットワーク接続があるワークロードは、インターネットでもプライベートネットワークでも、外部および内部ネットワークベースの脅威から保護するために、複数の防御レイヤーが必要です。

SEC 6. コンピューティングリソースをどのように保護していますか?

ワークロード内のコンピューティングリソースを内外の脅威から守るには、複数の防御レイヤーを設ける必要があります。コンピューティングリソースには、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベースサービス、IoT デバイスなどがあります。

「データ保護」

SEC 7. どのようにデータを分類していますか?

分類方法を確立すると、重要度と機密性に基づいてデータをカテゴリ別に分類して、各カテゴリに適した保護と保持方法でデータを管理できるようになります。

SEC 8. 保管時のデータをどのように保護していますか?

複数のコントロールを実装して保管中のデータを保護し、不正アクセスや不正処理のリスクを低減します。

SEC 9. 転送時のデータをどのように保護していますか?

複数のコントロールを実装して、転送中のデータを保護し、不正アクセスや損失のリスクを軽減します。

「インシデント対応」

SEC 10. インシデントの予測、対応、復旧はどのように行いますか?

組織に支障をきたすことを最小限に抑えるために、セキュリティインシデントのタイムリーで効果的な調査、対応、復旧に備えることが重要です。

信頼性（9項目→13項目）

設計原則

信頼の柱においては設計原則に変更はなく、以下の 5 つです。

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

ベストプラクティスは従来の 3 つ「基盤」「変更管理」「障害の管理」に加えて、「ワークロードアーキテクチャ」が追加されています。この追加により障害分離などの観点で、マイクロサービスアーキテクチャ、分散システムを強く意識した設問項目が増えているように思います。

「基盤」

REL 1. サービスクォータと制約はどのように管理しますか?

クラウドベースのワークロードアーキテクチャには、サービスクォータ (サービスの制限とも呼ばれます) というものがあります。このようなクォータは、誤って必要以上のリソースをプロビジョニングするのを防ぎ、サービスを不正使用から保護することを目的として API 操作のリクエスト頻度を制限するために存在します。リソースにも制約があります。たとえば、光ファイバーケーブルのビットレートや、物理ディスクの記憶容量などです。

REL 2. ネットワークトポロジをどのように計画しますか?

多くの場合、ワークロードは複数の環境に存在します。このような環境には、複数のクラウド環境 (パブリックにアクセス可能なクラウド環境とプライベートの両方) と既存のデータセンターインフラストラクチャなどがあります。計画する際は、システム内およびシステム間の接続、パブリック IP アドレスの管理、プライベート IP アドレスの管理、ドメイン名解決といったネットワークに関する諸点も考慮する必要があります。

ワークロードアーキテクチャ

(NEW!) REL 3. どのようにワークロードサービスアーキテクチャを設計すればよいですか?

サービス指向アーキテクチャ (SOA) またはマイクロサービスアーキテクチャを使用して、拡張性と信頼性の高いワークロードを構築します。サービス指向アーキテクチャ (SOA) は、サービスインターフェイスを介してソフトウェアコンポーネントを再利用できるようにする方法です。マイクロサービスアーキテクチャは、その一歩先を行き、コンポーネントをさらに小さくシンプルにしています。

(NEW!) REL 4. 障害を防ぐために、分散システムの操作をどのように設計しますか?

分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。これらのベストプラクティスは、故障を防ぎ、平均故障間隔 (MTBF) を改善します。

(NEW!) REL 5. 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか?

分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。これらのベストプラクティスに従うことで、ワークロードはストレスや障害に耐え、より迅速に復旧し、そのような障害の影響を軽減できます。その結果、平均復旧時間 (MTTR) が向上します。

REL 6. ワークロードリソースをモニタリングするにはどうすればよいですか?

ログとメトリクスは、ワークロードの状態についての洞察を得るための強力なツールです。ワークロードは、しきい値を超えたり重大なイベントが発生したりしたときに、ログとメトリクスがモニタリングされて通知が送信されるように構成できます。モニタリングにより、ワークロードは、低パフォーマンスのしきい値を超えたときや障害が発生したときにそれを認識できるため、それに応じて自動的に復旧できます。

REL 7. 需要の変化に適応するようにワークロードを設計するには、どうすればよいですか?

スケーラブルなワークロードには、リソースを自動で追加または削除する伸縮性があるので、リソースは常に、現行の需要に厳密に適合します。

REL 8. 変更はどのように実装するのですか?

変更制御は、新しい機能をデプロイしたり、アプリケーションと運用環境で既知のソフトウェアが実行されており、予測できる方法でパッチを適用または置換できることを確認したりするために必要です。変更が制御されていないと、変更の影響を予測したり、変更によって発生した問題に対処したりすることが困難になります。

「障害の管理」

REL 9. データはどのようにバックアップするのですか?

目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を満たすように、データ、アプリケーション、設定をバックアップします。

(NEW!) REL 10. ワークロードを保護するために障害分離をどのように使用しますか?

障害部分を分離した境界は、ワークロード内の障害の影響を限られた数のコンポーネントに限定します。境界外のコンポーネントは、障害の影響を受けません。障害部分を切り離した境界を複数使用すると、ワークロードへの影響を制限できます。

REL 11. コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか?

高い可用性と低い平均復旧時間 (MTTR) の要件を持つワークロードは、高い弾力性があるように設計する必要があります。

REL 12. どのように信頼性をテストしますか?

本番環境のストレスに耐えられるようにワークロードを設計した後、ワークロードが意図したとおりに動作し、期待する弾力性を実現することを確認する唯一の方法が、テストを行うことです。

REL 13. 災害対策 (DR) はどのように計画するのですか?

バックアップと冗長ワークロードコンポーネントを配置することは、DR 戦略の出発点です。RTO と RPO は、可用性を回復するための目標です。これらは、ビジネスニーズに基づいて設定します。ワークロードのリソースとデータのロケーションと機能を考慮して、目標を達成するための戦略を実装します。

パフォーマンス（追加なし）

設計原則

パフォーマンスの柱においては設計原則に変わりはなく、以下の 5 つです。

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

またベストプラティスも変更はなく、以下の 4 つです。

• 選択
• レビュー
• モニタリング
• トレードオフ

設計原則、ベストプラクティスともに変更がないことから、設問も特に追加はありませんでした。

選択

PERF 1. どのように最良パフォーマンスのアーキテクチャを選択するのですか?

多くの場合、ワークロード全体での最適なパフォーマンスのためには、複数のアプローチが必要になります。Well-Architected なシステムでは、パフォーマンスを向上させるために複数のソリューションと機能が使用されています。

コンピューティング

PERF 2. コンピューティングソリューションはどのように選択するのですか?

ワークロードにとって最適なコンピューティングソリューションは、アプリケーションの設計、使用パターン、設定に応じて異なります。各アーキテクチャでは、コンポーネントごとに異なるコンピューティングソリューションが使用される可能性があるため、パフォーマンスを向上させるための機能も異なります。アーキテクチャに不適切なコンピューティングソリューションを選択すると、パフォーマンス効率が低下する可能性があります。

ストレージ

PERF 3. ストレージソリューションをどのように選択していますか?

システムにとって最適なストレージソリューションは、アクセス方法 (ブロック、ファイル、オブジェクト)、アクセスパターン (ランダム、シーケンシャル)、必要なスループットやアクセス頻度 (オンライン、オフライン、アーカイブ)、更新頻度 (WORM、動的)、可用性と耐久性に関する制約によって異なります。優れた設計のシステムでは、複数のストレージソリューションを使用し、さまざまな機能を有効にしてパフォーマンスとリソースの使用効率を高めています。

データベース

PERF 4. データベースソリューションをどのように選択していますか。

システムにとって最適なデータベースソリューションは、可用性、整合性、分断耐性、レイテンシー、耐久性、スケーラビリティ、クエリ機能などの要件に応じて異なります。多くのシステムでは、サブシステムごとに異なるデータベースソリューションを使用しているため、パフォーマンスを向上させるための機能も異なります。システムに対して適切でないデータベースソリューションや機能を選択すると、パフォーマンス効率が低下する場合があります。

ネットワーク

PERF 5. どのようにネットワーキングソリューションを選択するのですか?

ワークロードに最適なネットワークソリューションは、レイテンシー、スループット要件、ジッター、および帯域幅に応じて異なります。ロケーションのオプションは、ユーザーまたはオンプレミスのリソースなどの物理的な制約に左右されます。これらの制約は、エッジロケーションまたはリソースの配置で相殺することができます。

レビュー

PERF 6. ワークロードを進化させるためにどのように新機能を取り込んでいますか？

ワークロードを設計する際に選択できるオプションには限りがありますが、時間と共に、ワークロードのパフォーマンスを向上させることができる新しいテクノロジーとアプローチが利用できるようになります。

モニタリング

PERF 7. リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか?

システムのパフォーマンスは徐々に低下することがあります。劣化を特定し、オペレーティングシステムまたはアプリケーション負荷などの内部および外部の要因を修正するために、システムのパフォーマンスをモニタリングします。

トレードオフ

PERF 8. トレードオフをどのように使用するとパフォーマンスが向上するのですか?

アーキテクチャの設計にあたって、最適なアプローチとなるトレードオフを特定します。多くの場合、整合性、耐久性、および時間とレイテンシーの余裕と引き換えに、パフォーマンスを向上させることができます。

コスト最適化（９項目→10項目）

設計原則

コスト最適化の柱においては、設計原則は 5 つで変わりないのですが、内容に変更がありました。

2019年7月版	2020年7月版
・消費モデルを導⼊する ・全体的な効率を測定する ・データセンター運⽤のための費⽤を排除する ・費⽤を分析し、帰結させる ・アプリケーションレベルのマネージドサービスを使⽤して所有コストを削減する	・クラウド財務管理の実装 ・消費モデルを導⼊する ・全体的な効率を測定する ・差別化につながらない⾼負荷の作業に費⽤をかけるのをやめる ・費⽤を分析および属性化する

また、ベストプラクティスについても 4 つから 5 つに変更となっています。

2019年7月版	2020年7月版
・費用認識 ・費用対効果の高いリソース ・需要と供給を一致させる ・長期的な最適化	・クラウド財務管理を実践する ・経費支出と使用量の認識 ・費用対効果の高いリソース ・需要を管理し、リソースを供給する ・経時的な最適化

単なる使用状況のモニタリングだけでなく、組織全体にコスト意識を持たせるための財務管理についての設問が追加されています。

「クラウド財務管理を実践する」

(NEW!) COST 1. クラウド財務管理はどのように実装しますか?

組織はクラウド財務管理の実装により、AWS によってコストと使用状況の最適化とスケーリングをすることで、ビジネス価値と財務上の成功を実現できます。

経費支出と使用量の認識

COST 2. 使用状況をどのように管理しますか?

発生コストを適正な範囲内に抑えつつ、目的を確実に達成するためのポリシーとメカニズムを設定します。チェックアンドバランスのアプローチを採用することで、無駄なコストを費やすことなくイノベーションが可能です。

COST 3. 使用状況とコストをどのようにモニタリングしますか?

コストをモニタリングし、適切に配分するためのポリシー手順を定めます。これにより、ワークロードのコスト効率を測定し、向上させることができます。

COST 4. 不要なリソースをどのように削除しますか？

プロジェクトの開始から終了まで変更管理とリソース管理を実装します。これにより、使用されていないリソースをシャットダウンまたは終了して、無駄を減らします。

費用対効果の高いリソース

COST 5. サービスを選択するとき、どのようにコストを評価しますか?

Amazon EC2、Amazon EBS、Amazon S3 は、基盤となる AWS のサービスです。Amazon RDS や Amazon DynamoDB などのマネージドサービスは、高レベルまたはアプリケーションレベルの AWS のサービスです。基盤となるサービスやマネージドサービスを適切に選択することで、このワークロードのコストを最適化できます。例えば、マネージドサービスを使用することで、管理や運用によって発生するオーバーヘッドを削減またはゼロにでき、アプリケーション開発やビジネス上の他の活動に注力できるようになります。

COST 6. コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか?

対象タスクについて適切なリソースサイズおよびリソース数を選択していることを確認します。最もコスト効率の高いタイプ、サイズ、数を選択することで、無駄を最小限に抑えます。

COST 7. コストを削減するには、料金モデルをどのように使用したらよいでしょうか?

リソースのコストを最小限に抑えるのに最も適した料金モデルを使用します。

COST 8. データ転送料金についてどのように計画していますか？

データ転送料金を計画し、モニタリングすることで、これらのコストを最小化するためのアーキテクチャ上の決定を下すことができます。小規模でも効果的なアーキテクチャ変更により、長期的な運用コストを大幅に削減できる場合があります。

需要を管理し、リソースを供給する

COST 9. どのように需要を管理し、リソースを供給しますか?

費用とパフォーマンスのバランスが取れたワークロードを作成するには、費用を掛けたすべてのものが活用されるようにし、使用率が著しく低いインスタンスが生じるのを回避します。利用が過剰でも過少でも偏りが生じると、運用コスト (利用過剰によるパフォーマンスの低下) または無駄な AWS 費用 (過剰なプロビジョニング) のいずれかで、組織に悪影響が及びます。

「経時的な最適化」

COST 10. 新しいサービスをどのように評価していますか？

AWS では新しいサービスと機能がリリースされるため、既存のアーキテクチャの選択をレビューし、現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです。

さいごに

Well-Architected はクラウドを導入、運用するにあたっての設計原則、ベストプラクティスに則っているかをチェックするのに優れたツールです。

これから本格的にクラウドを展開されるのであれば、是非、ご活用ください。

以上！大阪オフィスの丸毛（@marumo1981）でした！