マルチアカウント環境のリソースを可視化。

「Workload Discovery on AWS」を試してみる

2022-09-02
AWS ソリューション紹介

佐藤 裕介, 山澤 良介

皆さん、こんにちは ! ソリューションアーキテクトの佐藤裕介です。

皆さんは「AWS ソリューションライブラリ」をご存知でしょうか ? 業界ごと、テクノロジーごとにお客様の課題解決に役立つ、AWS サービス、リファレンスアーキテクチャ、そして今回ご紹介する「Workload Discovery on AWS」を含む AWS ソリューションズが AWS ソリューションライブラリで紹介されています。

AWS ソリューションズでは、世界中のユーザーが直面する一般的な問題の解決策を提供しています。AWS ソリューションズは AWS CloudFormation のテンプレートを提供しており、お客様の環境で CloudFormation テンプレートを展開することで、実装にかかる時間と労力を節約することができます。構築後の運用はお客様にて実施していただく必要はありますが、CloudFormation テンプレートは無料で入手することができ、お客様は実際に利用したサービスの利用料を負担いただくのみで利用できます。

AWS ソリューションのページ  から、Filter の Content Type - AWS Solutions を選択すると、2022 年 7 月時点で 53 個の AWS ソリューションズが公開されています。

AWS ソリューションは CloudFormation テンプレートを展開するだけで、課題の解決を支援できるため、非常に便利なものではあるのですが、AWS ソリューションの存在を知っていた方であっても、「どんなソリューションがあるのかわからない」「ソリューションの概要や使い方がわからない」といった理由で実際に活用したことがある方は少ないのではないでしょうか ?

クリックすると拡大します

そのような背景から、今回の記事では、皆さんに活用頂けそうな AWSソリューションズを 1 つ、使いどころ、使い方、参考コストを紹介していこうと思います!

今回紹介するソリューションは、「Workload Discovery on AWS」というワークロードの可視化のためのソリューションです。以前は AWS Perspective と呼ばれていたソリューションです。

例えば、「AWS でシステムを構築したけれど、アーキテクチャ図を手動で更新するのは大変・・・自動で更新したい !」ときにご活用いただけます。Workload Discovery on AWS を利用することで、AWS アカウントの複数のリージョンのリソースから自動的にアーキテクチャ図を作成し、WebUI により表示できます。

それではここから本ソリューションの概要や使い方を紹介します。

ご注意

本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。

*ハンズオン記事およびソースコードにおける免責事項 »

この記事のデモを無料でお試しいただけます »

毎月提供されるデベロッパー向けアップデート情報とともに、クレジットコードを受け取ることができます。 


1. Workload Discovery on AWSとは ?

Workload Discovery on AWS は、 AWS アカウントおよびリージョン全体の AWS のリソースをマッピングし、それらを Web サイトで提供されている UI に可視化できます。可視化したリソースはタグなどによる検索が可能です。さらに、AWS リソースの予想コストをアーキテクチャ図にマッピングして表示することも可能です。そのため、AWS で利用しているワークロードのアーキテクチャ図の自動作成や、ワークロードごとのコストの可視化に役立ちます。

AWS のアーキテクチャ図は、手動で更新しているお客様も多いのではないのでしょうか。また、IaC のコードと一緒に Git で管理しているお客様もいらっしゃるかと思います。また、今までアーキテクチャ図を書いたことがないお客様は、ぜひこちらの記事もご覧ください。

AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? »

手動でのアーキテクチャ図作成は手軽に書け、伝えたい内容に合わせて柔軟に粒度や表現を変えることができる点がメリットです。私達ソリューションアーキテクトも、ホワイトボードや drao.io、Microsoft PowerPoint など個人が好きなツールを利用し、お客様とアーキテクチャ図を基にディスカッションすることも多いです。

Workload Discovery on AWS は手動でのアーキテクチャ図作成を完全に置き換えるものではありません。チームメイトやお客様とディスカッションしながらアーキテクチャ図を書いたり、プレゼンテーションなどで伝えたい内容に合わせてアーキテクチャ図を書くときは手動での作成が優れていると言えます。

一方で、対象の AWS アカウントに既にプロビジョニング済みのリソースを可視化したいときはどのように行うでしょうか。対象の AWS アカウントが複数リージョンを利用している場合や対象の AWS アカウントが複数ある場合、手動で図に書き起こすのはかなり工数がかかりますし、網羅性にも不安が残ると思います。

Workload Discovery on AWS は、リンクした AWS アカウントの複数のリージョンのリソースから自動的にアーキテクチャ図を作成します。そのため、複数アカウントや複数リージョンを利用している場合でも、リソースを効率的に可視化できます。さらに、作成したアーキテクチャ図を PNG, JSON, CSV, draw.io にエクスポートが可能です。そのため、自動的に作成されたアーキテクチャ図を基に修正したり、プレゼンテーションに貼り付けることも出来ます。

このように Workload Discovery on AWS には以下の利点があります。

  • CloudFormation テンプレートが提供されているため、簡単にデプロイできる
  • AWS アカウントやリージョンを跨いでリソースを効率的に可視化できる
  • AWS 上のリソースを機械的に抽出するため、正確である
  • コストとアーキテクチャ図を合わせて可視化できる

2. まずは出来上がったアーキテクチャ図を見てみよう

百聞は一見にしかず。まずは Workload Discovery on AWS で作成したアーキテクチャ図を見てみましょう !

今回は AWS が公開しているハンズオンをいくつかピックアップし、出来上がった環境のアーキテクチャ図を Workload Discovery on AWS で作成してみました。

現状、Workload Discovery on AWS は AWS の全てのサービスに対応しているわけではありませんが、Workload Discovery on AWS がサポートしているサービスはデプロイガイドの「Supported resources」をご参照ください。

クリックすると拡大します

クリックすると拡大します

クリックすると拡大します

いかがでしょうか。ハンズオンのアーキテクチャはシンプルなものが多いため、手動で書いたほうが早いと思われるかもしれません。しかし、前述したように、複数のアカウントや複数のリージョンを利用している場合や、さらに多数のサービスを利用しているアーキテクチャを可視化する場合は、Workload Discovery on AWS で可視化することで、効率的に可視化することが可能です。


3. マルチアカウントで Workload Discovery on AWS を利用するには

単独のアカウントで Workload Discovery on AWS をデプロイし、同一アカウント内のリソースを可視化することも可能ですが、Workload Discovery on AWS をデプロイするアカウントは可視化対象のアカウントと分離し、専用のアカウントを利用することがデプロイガイド「Design considerations - Workload Discovery on AWS」で推奨されています。これは、既存の環境との分離や発生したコストの追跡が容易になるためです。

そのため推奨構成に従うと、利用するアカウントは Workload Discovery on AWS をデプロイするアカウント (アドミンアカウント) と可視化対象のアカウント (ターゲットアカウント) の 2 種類となります。

クリックすると拡大します

では、複数アカウントで Workload Discovery on AWS を利用するにはどのような方法があるでしょうか。Workload Discovery on AWS は大きく 2 種類の CloudFormation テンプレートを利用することで可視化を実現します。1 つ目は Workload Discovery on AWS をデプロイするための CloudFormation テンプレート (workload-discovery-on-aws.template)、2 つ目は可視化する対象のアカウント (ターゲットアカウント) にデプロイする CloudFormation テンプレートです。

2 つ目の可視化する対象のアカウント (ターゲットアカウント) にデプロイする CloudFormation テンプレートは 2 種類あり、1 つのアカウントに 1 つデプロイするグローバルリソーステンプレート (global-resources.template) と 1 つのアカウントのリージョンごとにデプロイするリージョナルリソーステンプレート (regional-resources.template) があります。

クリックすると拡大します

CloudFormation テンプレートを、可視化対象のアカウント (ターゲットアカウント) に個別に展開しても良いですが、複数のアカウントに CloudFormation テンプレートを効率的に展開する方法として、AWS CloudFormation StackSets があります。

StackSets はアドミンアカウントで定義した CloudFormation テンプレートを単独もしくは複数のターゲットアカウントに展開する仕組みです。

クリックすると拡大します

アドミンアカウントからターゲットアカウントに CloudFormation テンプレートを展開しリソースを作成するため、アドミンアカウントからターゲットアカウントへのアクセス許可が必要になります。アクセス許可の方法は 2 種類あります。

1 つ目はアドミンアカウントとターゲットアカウントで CloudFormation テンプレートの展開に必要な IAM ロールを作成する方法 (セルフマネージド型アクセス許可)、2 つ目は AWS Organizations を利用して、AWS Organizations の管理下のアカウントにアクセス許可を与える方法 (サービスマネージド型アクセス許可) です。詳細は CloudFormation のドキュメント をご参照ください。

ここでは、セルフマネージド型アクセス許可により、Workload Discovery on AWS をデプロイするアカウントを StackSets のアドミンアカウント、Workload Discovery on AWS で可視化するアカウントを StackSets のターゲットアカウントとして手順を確認していきます。セルフマネージド型アクセス許可を用いるため、2 つのアカウントは同一の AWS Organizations に属していなくても構いません。

セルフマネージド型アクセス許可では、アドミンアカウントに StackSet の管理者用 IAM ロール (AWSCloudFormationStackSetAdministrationRole)、ターゲットアカウントに StackSet の展開用の IAM ロール (AWSCloudFormationStackSetExecutionRole) をデプロイします。

クリックすると拡大します


4. Workload Discovery on AWS をデプロイしてみよう

4-1. 前提

AWS アカウントが 2 つ用意されていること

  • Workload Discovery on AWS をデプロイするアカウント (アドミンアカウント)
  • Workload Discovery on AWS で可視化するアカウント (ターゲットアカウント)

4-2. StackSets のセルフマネージド型アクセス許可の設定

Workload Discovery on AWS で用いる CloudFormation テンプレートを、アドミンアカウントからターゲットアカウントに展開するために、StackSets のセルフマネージド型アクセス許可を 2 つのアカウント間で設定します。

アドミンアカウント用の IAM ロール (AWSCloudFormationStackSetAdministrationRole) とターゲットアカウント用の IAM ロール (AWSCloudFormationStackSetExecutionRole) を作成します。

設定手順は「Grant self-managed permissions - AWS CloudFormation」をご参照ください。

設定が完了すると、2 つの IAM ロールがそれぞれのアカウントに作成されます。

クリックすると拡大します

4-3. Workload Discovery on AWS のデプロイ

それでは、Workload Discovery on AWSをデプロイしましょう!

まずは、アドミンアカウントの CloudFormation で Workload Discovery on AWS の CloudFormation テンプレートを展開します。

Workload Discovery on AWSのランディングページ にアクセスし、「AWS コンソールで起動する」を選択します。

デフォルトではバージニア北部リージョンで CloudFormation が起動し、ソリューションが展開されます。なお、Workload Discovery on AWS で可視化するターゲットアカウントのリージョンは別途指定するため、アドミンアカウントで Workload Discovery on AWS を展開するリージョンはどこでも構いません。

普段使っているリージョンと同じリージョンで Workload Discovery on AWS のリソースを管理する必要があれば、マネジメントコンソールの左上より普段お使いのリージョンを指定します。今回はバージニア北部リージョンのまま進みます。

クリックすると拡大します

前提条件 - テンプレートの準備」、「テンプレートの指定」は変更せずに「次へ」を選択します。

クリックすると拡大します

スタックの名前」に名前 (例:aws-perspective) が入力されています。

クリックすると拡大します

4-4. CloudFormation パラメータの設定

次に、CloudFormation のパラメータを設定します。

Workload Discovery on AWS は Web の UI が提供され、Web ページにログインすることでアーキテクチャ図の閲覧などが可能になります。「AdminUserEmailAddress」に Web ページにログインする際に利用するユーザー名、パスワードが記載されたメールを受け取るメールアドレスを入力します。

すでにアドミンアカウントのデプロイ先リージョンで AWS Config をセットアップしている場合は「AlreadyHaveConfigSetup」を「Yes」にします。

その他、可用性やコストに関わるパラメータとして、リソースのインベントリ情報を保持する Amazon Neptune のリードレプリカを持つか (CreateNeptuneReplica)、Amazon Neptune のインスタンスタイプ (NeptuneInstanceClass)、Amazon OpenSearch Service のインスタンスタイプ (OpensearchInstanceType)、Amazon OpenSearch Service のマルチ AZ 化 (OpensearchMultiAz) があります。

ここではデフォルトの設定で進めますが、本番利用の際は必要な可用性やパフォーマンスに応じてご選択ください。パラメータについての詳細はデプロイガイドの「Automated deployment - Workload Discovery on AWS」をご参照ください。

クリックすると拡大します

スタックオプションの設定」、「詳細オプション」は変更せずに、「次へ」を選択します。

レビュー aws-perspective」で、CloudFormation のパラメータが指定した値で設定されていることを確認します。

クリックすると拡大します

レビューを下へスクロールし、チェックボックスにチェックを入れ、「スタックの作成」 を選択します。

クリックすると拡大します

スタックの作成が成功したことを確認します。作成完了までに 30 分程度かかります。

ネスト表示が On になっている場合は、入れ子になっている Workload Discovery on AWS 関連の CloudFormation テンプレートが複数表示されます。

クリックすると拡大します

作成に失敗してしまった場合、イベントタブから「CREATE_FAILED」となっているイベントを探し、エラーメッセージを読み解決していきます。また、Workload Discovery on AWS の GitHub の Issues ページ  などに同様のエラーに関する Issue が無いか探してみましょう。


5. Workload Discovery on AWS にログインしてみよう

5-1. Workload Discovery on AWS の WebUI へのログイン

Workload Discovery on AWS をデプロイすると、Web の UI が提供されます。Web サイトの URL は aws-perspective-<deployment-accountID>-<deployment-region> のスタック名から確認できます。

スタック名がリンクになっているため、クリックします。

クリックすると拡大します

出力」タブを表示すると、WebUiUrl として URL が記載されています。

クリックすると拡大します

記載されている URL に遷移すると、Workload Discovery on AWS のログイン画面が表示されるため、ユーザー名及びパスワードを入力してログインします。

ユーザー名とパスワードは CloudFormation テンプレートの「AdminUserEmailAddress」に入力したメールアドレスにユーザー名と初期パスワードが記載されたメールが送付されています。

クリックすると拡大します

以下の図のように、Web サイトのユーザー名とパスワードは Amazon Cognito で管理されています。例えば、社外のパートナー向けにアーキテクチャ図を共有するために、新規に Amazon Cognito でユーザーを作成することも可能です。

クリックすると拡大します

Web サイトは大まかに 3 つの領域で構成されており、メニュー、検索 Box、アーキテクチャ図が書かれるスペースが確認できます。まだ、ターゲットアカウントのリソースを読み取りしていないため、アーキテクチャ図も書かれていません。

クリックすると拡大します

5-2. TargetAccount のリージョンを Workload Discovery on AWS にインポート

初回に Workload Discovery on AWS の Web サイトにログインすると、リソースのインポートチュートリアルが開始します。

閉じてしまった方は、メニューの「Settings-Imported Regions」から再開することができます。

クリックすると拡大します

前述したとおり、可視化する対象のアカウントにデプロイする CloudFormation テンプレートは 2 種類あり、1 つのアカウントに 1 つデプロイするグローバルリソーステンプレート (global-resources.template) と、1 つのアカウントのリージョンごとにデプロイするリージョナルリソーステンプレート (regional-resources.template) があります。

チュートリアルには、可視化する対象のアカウントに CloudFormation テンプレートをデプロイする方法として、2 種類の方法が用意されています。AWS CloudFormation StackSetsを利用する方法と、ターゲットアカウントで AWS CloudFormation を実行する方法です。今回は前者の StackSets を利用する方法で進めていきます。

AWS CloudFormation StackSets が選択されていることを確認し、リソースの可視化対象であるターゲットアカウントの AWS アカウント ID、任意のアカウント名、ターゲットアカウントの可視化するリージョンを入力し、「Add」をクリックします。

クリックすると拡大します

下部の Regions に対象の AWS アカウント及びリージョンが追加されたことを確認し、「Next」をクリックします。

クリックすると拡大します

ターゲットアカウントに展開する CloudFormation テンプレートのダウンロード画面が表示されるため、2種類のテンプレートをダウンロードし、「Next」をクリックします。実際のファイル名は「global-resources-1655969430556.template」と「aws-perspective-region-import-1655969435310.template」のように、ランダムな文字列が含まれます。

クリックすると拡大します

Deploy」をクリックすると、ターゲットアカウントへの IAM ユーザーでのログイン画面が表示されますが、StackSets の設定はアドミンアカウント側で行うため、ログイン画面を閉じ、「Next」をクリックします。

クリックすると拡大します

入力した AWS アカウント ID、リージョンが正しいことを確認して、「Import」をクリックします。

クリックすると拡大します

Import 済みの Region を表示する画面に、入力したターゲットアカウントが表示されます。

まだ、ターゲットアカウントに必要な CloudFormation テンプレートを展開していないため、直近のリソースのスキャン状況を表す「Last Scanned」には N/A が表示されています。

クリックすると拡大します

5-3. StackSets による CloudFormation テンプレートの展開

先程ダウンロードした 2 種類の CloudFormation テンプレート (global-resources-XXXX.templateaws-perspective-region-import-XXXX.template) をターゲットアカウントに展開します。

Workload Discovery on AWS を デプロイしたアドミンアカウントで CloudFormation の StackSets のコンソール画面 を開き、「StackSet の作成」をクリックします。

クリックすると拡大します

テンプレートファイルのアップロード」を選択、先程ダウンロードした CloudFormation テンプレートの「global-resources-XXXX.template」をアップロードし、「次へ」をクリックします。

クリックすると拡大します

StackSet 名」に任意の名前 (global-resources-template) を入力、パラメータの「AccountIdにアドミンアカウントの AWS アカウント ID が入力されていることを確認し「次へ」をクリックします。

クリックすると拡大します

StackSet オプションの設定」はデフォルトのまま「次へ」をクリックします。

展開先のアカウントが多数ある場合は、「アクティブ」を選択することで並行して CloudFormation テンプレートを展開できるため、より短時間で完了します。

クリックすると拡大します

デプロイオプションの設定」にて、デプロイ先のアカウント番号にターゲットアカウントの AWS アカウント ID を入力します。

リージョン」も同様にターゲットアカウントで可視化したいリージョンを選択します。(global-resources-XXXX.template は IAM ロールの展開であるため、リージョンは関係ありませんが、StackSet の設定時には少なくとも 1 つのリージョンを選択する必要があります。)

クリックすると拡大します

デプロイオプションにて、展開先のアカウント数、リージョン数に応じて同時実行数を調整します。

今回は単一アカウント、単一リージョンであるため、デフォルトのまま「次へ」をクリックします。

クリックすると拡大します

チェックボックスにチェックを入れ、「送信」をクリックします。

クリックすると拡大します

同様の StackSet の作成手順を aws-perspective-region-import-XXXX.template に対しても行い、合計 2 つの StackSet を作成します。

手順を終えると、こちらの図のように 2 つの StackSet が作成されたことが確認できます。

クリックすると拡大します


6. Workload Discovery on AWS でリソースを可視化してみよう

StackSet の展開が完了すると、Workload Discovery on AWS の Web サイトでターゲットアカウントのリソースを可視化する準備が整います。

ターゲットアカウントのリソースのインポートは、リソースの検出を担う Amazon ECS のタスクが 15 分ごとに実行されることで行われます。実行履歴は、Amazon ECS のマネジメントコンソールAmazon EventBridge のマネジメントコンソール から確認できます。

クリックすると拡大します

クリックすると拡大します

6-1. Workload Discovery on AWS での可視化

Workload Discovery on AWS の Web サイトにログインし、リソースを可視化してみましょう。StackSets の展開が完了した後、15 分程待つと初回のスキャンが完了し、Web サイトでの表示が可能になります。

6-2. リソースの個別選択による可視化

例えば、Amazon EC2 であれば、メニューの「Resources-EC2-Instance-インスタンス IDをクリックすることでアーキテクチャ図が表示されます。

クリックすると拡大します

Elastic Network Interface や Security Group が余分であれば、メニューの「Actions」-「Filters」から表示、非表示を切り替えることが可能です。

クリックすると拡大します

EC2 インスタンスや Amazon EBS のみを表示したかったので、タグ (AWS::TAGS::TAG)、Elastic Network Interface (AWS::EC2::NetworkInterface)、Security Group (AWS::EC2::SecurityGroup) を非表示にしました。

クリックすると拡大します

すっきりしましたね !

リソースのアイコンは個別に選択して、移動することができます。他のアイコンも一緒に動いてしまう場合、複数のアイコンを選択してしまっている状態のため、一度、空白部分でクリックしてから移動させたいアイコンを再度クリックして移動してみてください。

リソースをクリックすることで、詳細情報を確認することができます。また、右クリックで個別にリソースをアーキテクチャ図から削除 (Remove) することもできます。

クリックすると拡大します

リソースの詳細情報 (Show resource details) は例えば、Amazon EC2 であれば現在のステータスや、IP アドレスなどの基本情報が表示されます。

現在のステータスは手書きのアーキテクチャ図では表示できない情報であるため、Workload Discovery on AWS ならではのメリットです。

クリックすると拡大します

作成したアーキテクチャ図はメニューの「Architecture diagrams」-「Manage」から名前を付けて保存することができます。

クリックすると拡大します

クリックすると拡大します

また、「All-users」のタブを選択して保存することで、保存したアーキテクチャ図を他のユーザーが開くことができます。

クリックすると拡大します

アーキテクチャ図はメニューの「Actions」-「Clear graph」から削除することができます。

クリックすると拡大します

6-3. タグを用いた可視化

AWS のサービスを多数利用している場合、個別のリソースを一つ一つ選択するのは手間がかかります。AWSではタグを利用して、リソースをグループ化することができます。

先程の「Filters」でタグ (AWS::TAGS::TAG) を表示するよう設定し、メニューの「Resources」-「TAGS」-「TAG」からタグが付いているリソースを表示することができます。

クリックすると拡大します

複数のリソースにタグを追加する方法として、タグエディターがおすすめです。タグエディターを用いたインスタンスへのタグ付方法は タグエディターのドキュメント をご覧ください。

タグエディタが対応しているサービスはタグエディタのドキュメント「AWS Resource Groups とタグエディタで使用できるリソース」をご参照ください。

6-4. アーキテクチャ図のエクスポート

作成したアーキテクチャ図はメニューの「Actions」-「Export」からエクスポートできます。

クリックすると拡大します

draw.io にエクスポートしてみました。個別のリソースが個々のアイコンで選択できるため、見栄えは draw.io で調整することもできます。

クリックすると拡大します


7. リソースの削除方法

ターゲットアカウント及びアドミンアカウントでのリソース削除方法を説明します。

7-1. ターゲットアカウント側でのリソース削除作業

Workload Discovery on AWS はターゲットアカウントで AWS Config を有効化し、AWS Config が検出した情報を保存する Amazon S3 バケットを作成するため、まず Amazon S3 バケット内のオブジェクトを空にします。

まず、ターゲットアカウントにログインし、ターゲットアカウントにて、Amazon S3 のマネジメントコンソール に移動し、バケット「stackset-aws-perspective-region-impo-configbucket-XXXX」を選択し、「空にする」をクリックします。

クリックすると拡大します

確認画面が表示されるため、「完全に削除」と入力し、「空にする」をクリックします。

クリックすると拡大します

7-2. アドミンアカウント側でのリソース削除作業

次にアドミンアカウントにログインし、StackSetsで作成したリソースを削除します。

アドミンアカウントの StackSets の一覧画面からaws-perspective-region-import-XXXX を選択し、「StackSets からスタックを削除」をクリックします。

クリックすると拡大します

ターゲットアカウントの AWS アカウント ID、StackSets を展開したリージョンを入力します。「スタックを保持」が選択されていないことを確認し、「次へ」をクリックします。

クリックすると拡大します

入力した内容を確認し、「送信」をクリックします。

クリックすると拡大します

ターゲットアカウントに対して、StackSets で作成したリソースの削除が行われ、削除が完了した旨が「オペレーション」タブから確認することができます。

クリックすると拡大します

次に StackSet 自体を削除します。StackSets の一覧画面から、「aws-perspective-region-import-XXXX」を選択し、「StackSetの削除」をクリックします。

クリックすると拡大します

同様に、StackSets の一覧画面から「global-resources-XXXX-template」を選択し、「StackSets からスタックを削除」の手順を行います。

クリックすると拡大します

global-resources-XXXX-template」のスタックが削除されたことを確認します。

クリックすると拡大します

StackSets の一覧画面から、「global-resources-XXXX-template」を選択し、「StackSet の削除」をクリックします。

クリックすると拡大します

StackSets が削除され、ターゲットアカウント側に作成されたリソースが削除されました。

クリックすると拡大します

次に、Workload Discovery on AWS により作成されたリソースは、アドミンアカウントにて CloudFormation スタック一覧 から「aws-perspective-XXXX-ap-northeast-1」及び「aws-perspective」をそれぞれ選択し、「削除」をクリックすることで削除できます。

クリックすると拡大します


8. コスト試算の例

Workload Discovery on AWS は複数の AWS サービスで構成されています。CloudFormation でデプロイすると、規模感がわからず、利用料が不安・・という方も多いと思います。

Workload Discovery on AWS は CloudFormation でのデプロイ時に以下の図のデータコンポーネントで利用している Amazon Neptune、Amazon OpenSearch Service に対して、インスタンスタイプや Multi-AZ の要否を選択出来ます。

単一の AZ にデプロイし、コストを抑えることも可能ですが、AZ 障害発生時の可用性は低下します。また、検出したリソース数に応じて、AWS Config の料金が増加するため、コストはお客様のリソース数に応じて増加します。

試算前提は以下の通りです。

  • バージニア北部リージョンを使用
  • Workload Discovery on AWS をデプロイする CloudFormation テンプレートのデフォルト値を使用
    • Amazon Neptune、Amazon OpenSearch Service は単一の AZ にデプロイ
    • Amazon Neptune のインスタンスタイプは db.r5.large
    • Amazon OpenSearch Service のインスタンスタイプは m6g.large.elasticsearch
サービス インスタンスタイプ 一時間あたりのコスト 月額コスト
Amazon Neptune db.r5.large $0.348 $254.040
Amazon OpenSearch Service m6g.large.elasticsearch $0.128 $93.440
Amazon VPC ( NAT Gateway ) - $0.090 $65.700
AWS Config - $0.003 $0.003
Amazon ECS ( AWS Fargateタスク) - $0.020 $12.010
合計   $0.589 $425.193

※ 2022 年 3 月時点での試算です。コスト試算の詳細は デプロイガイドのコストページ をご参照ください。

Workload Discovery on AWS のコスト最適化の方法として、デプロイガイドでは、Workload Discovery on AWS を利用していないときに、リソースの検出を担う Amazon ECS タスク及びデータストアの Amazon Neptune を停止することで、コスト削減を行う方法が紹介されています。

実施手順はデプロイガイドの「Cost optimization」をご参照ください。


9. まとめ

今回の記事では「Workload Discovery on AWS」の概要や使い方を紹介しました。 マルチアカウントでの利用方法が中心でしたが、もちろん単独のアカウントでも利用することは可能です。

CloudFormation テンプレートを使ってセットアップするだけで、可視化対象のアカウントのリソースのアーキテクチャ図を自動で作成できることをご理解いただけたのではないかと思います。 本ソリューションを活用される際には、Workload Discovery on AWS のデプロイガイド もご一読頂ければと思います。

今後も AWS ソリューション紹介の記事を書いていきたいと思いますので、是非また読んでもらえたら嬉しいです。それではまた次の記事でお会いしましょう !


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

佐藤 裕介
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト

ソリューションアーキテクトとして、製造業分野のお客様を中心に様々なお客様を支援させて頂いています。AWS と出会いクラウドの楽しさを知り、お客様にもクラウドの楽しさを知ってほしいと思い日々働いています。
好きなサービスは、AWS Lambda と Amazon Connect で、難しいことを考えずにシュッと使えるサービスが好きです。
プライベートでは 3 歳の双子男児の父で日々育児に翻弄されています。

山澤 良介
アマゾン ウェブ サービス ジャパン合同会社
テクニカルソリューションアーキテクト

テクニカルソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。
前職では主にネットワーク案件を担当していたため、好きなサービスは、AWS Direct Connect と AWS Transit Gateway です。
休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っているほか、オフシーズン中もオフトレ施設に行っています。

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する