🙂

Workload Discovery on AWS を組織アカウント、スイッチロールの状態で試してみました【はじめに〜事前準備編】

2022/10/17に公開

AWS

IAM

CloudFormation

tech

はじめに

AWS Organizationsのサービスを有効にして管理アカウント（踏み台アカウント）を経由で各アカウントにスイッチロールするようにしています。しかし実はスイッチロールのまま構成をしている時にインターネット上の技術情報がそのまま使えない、エラー頻発なことが多々あります。権限周りのことは難しいですね。

今回は Workload Discovery on AWS というソリューションでマルチアカウント内のワークロードを一括で可視化することを試みた中で、前提条件が違うことで起こった事象とその対処をまとめておきたいと思います。

本記事対象者

システムを構築したけれど、マルチアカウント運用なので、全アーキテクチャ図を手動で更新するのは大変なので自動で更新したい
Organizationsで組織アカウントを管理している。マルチアカウントで運用中
踏み台アカウント経由のスイッチロールでそのまま作業したい

Workload Discovery on AWS とは

AWSのアカウントおよびリージョン全体のリソースをマッピングし、それらをWebサイトで提供されているUIで可視化します。またワークロードのアーキテクチャ図や、ワークロードごとのコストも可視化することができます。以前は AWS Perspectiveと呼ばれていました。

例えば、AWS公式のHands-on for Begginers「スケーラブル Web サイト構築ハンズオン」で構築されたワークロードを可視化したものが下図です。

alt
画像引用元：マルチアカウント環境のリソースを可視化「Workload Discovery on AWS」を試してみる
2022-09-02 builders.flash記事より

私は普段、AWSの認定試験のトレーナーをしている関係で、トレーニーの方々のためのハンズオン用のアカウントを作成し管理しています。踏み台アカウント経由で現在は10アカウント。その他社内用検証環境や開発環境を含めると20近いアカウントが存在します。

これらのアカウント内のワークロードのパラメータをどのように管理していくのがベターなのか、色々なソリューションを試す中で、今回の Workload Discovery on AWS の情報に辿り着きました。

以下の項で、AWS公式builders.flashの”マルチアカウント環境のリソースを可視化「Workload Discovery on AWS」を試してみる”を手順通りに構築していく中で、前提条件が違うが故に起こった事象、その対策を記していきたいと思います。

前提条件（事前準備）

1.アカウント

※以下の引用部分は全て「マルチアカウント環境のリソースを可視化 Workload Discovery on AWS を試してみる」 2022-09-02 builders.flash記事より

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

以下のAWSアカウントを2つ以上用意します。

Workload Discovery on AWS をデプロイして管理するアカウント（アドミンアカウント)
Workload Discovery on AWS で可視化したいアカウント (ターゲットアカウント)

アドミンアカウントのAWS Lambdaの「Concurrent executions」（同時実行可能値）は新規アカウント作成直後は10しかありません。1,000にするクォータの引き上げをリクエストして処理済にしておく必要があります。ちなみに今回の私の場合は2営業日程度でした。

*参照：「Amazon AthenaとAWS Glue StackとGremlinStackの不具合について」 https://github.com/awslabs/workload-discovery-on-aws/issues/243

2.CloudFormationテンプレートの準備

・CloudFormation テンプレート

Workload Discovery on AWS は大きく 2 種類の CloudFormation テンプレートを利用することで可視化を実現します。Workload Discovery on AWS は大きく 2 種類の CloudFormation テンプレートを利用します。
※テンプレートの詳細は次回のデプロイ編で説明します。

・アドミンアカウントにデプロイする CloudFormation テンプレート１つ

workload-discovery-on-aws.template

・ターゲットアカウントにデプロイする CloudFormation テンプレート 2つ

1つのアカウントに1つデプロイするグローバルリソーステンプレート
lobal-resources.template

1つのアカウントのリージョンごとにデプロイするリージョナルリソーステンプレート
regional-resources.template

・CloudFormation StackSets

CloudFormation テンプレートを、可視化対象のターゲットアカウントに個別に展開するのは骨の折れる作業です。複数のアカウントに CloudFormation テンプレートを一括で展開する方法として、AWS CloudFormation StackSets があります。

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

※今回の私の記事では行わないアクセス許可の設定

1種類目: Organizationでアカウント管理していない場合　→ セルフマネージド型アクセス許可

アドミンアカウントとターゲットアカウントで CloudFormation テンプレートの展開に必要な IAM ロールを作成する方法

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

セルフマネージド型アクセス許可では以下２つの用意されたテンプレートをデプロイします。

アドミンアカウントに StackSet の管理者用 IAM ロール AWSCloudFormationStackSetAdministrationRole

ターゲットアカウントに StackSet の展開用の IAM ロール AWSCloudFormationStackSetExecutionRole

※今回の私の記事で行うアクセス許可の設定

2種類目: Organizationでアカウント管理している場合　→ サービスマネージド型アクセス許可

AWS Organizations を利用して、AWS Organizations の管理下のアカウントにアクセス許可を与える方法

サービスマネージド型のアクセス許可を使用する場合、AWS Organizations が管理するアカウントにスタックインスタンスをデプロイできます。このアクセス許可モデルを使用すると、必要な IAM ロールを作成する必要はありません。ユーザーに代わって StackSets が IAM ロールを作成します。このモデルでは、将来組織に追加されるアカウントへの自動デプロイを有効にすることもできます。サービスマネージド型のアクセス許可を使用してスタックセットを作成および管理する方法の詳細については、次のトピックを参照してください。

AWS Organizations で信頼されたアクセスを有効にする（英文）

委任された管理者の登録（英文）

サービスマネージド型のアクセス許可を持つスタックセットの作成（英文）

トピックは３つありますが、今回は1番目の「AWS Organizations で信頼されたアクセスを有効にする」と2番目の「委任された管理者の登録」の設定まででOKです。

3.AWS Organizationsで信頼できるアクセスを実現する

AWS Organizationsで信頼されたアクセスを管理する手順

管理アカウントのアカウント管理者のみが、信頼されたアクセスを有効にする権限を持っています。管理者ユーザーとは、AWSアカウントへの全権限を持つIAMユーザーです。

スタックセットの作成ウィザードで信頼されたアクセスを有効にするには、次の手順を実行します。

・管理アカウントの管理者としてAWSにサインインし、AWS CloudFormationコンソールへ

・ナビゲーションペインから、StackSetsを選択します。信頼できるアクセスが無効になっている場合、信頼できるアクセスを有効にするよう促すバナーが表示されます。

・「信頼できるアクセスを有効にする」を選択します。

以下のバナーが表示されたら、信頼できるアクセスは正常に有効化されています。

4.委任された管理者の登録をする

Organizationの管理アカウント以外でアドミンアカウントを作成するために、アカウントの登録をします。

これで Workload Discovery on AWS を　Organization管理下のアカウントでデプロイ、参照する事前準備が完了しました。次回はいよいよデプロイです。ここでもOrganization管理下では公式記事の手順と違うところがありますのでご紹介します。

ここまでの手順で公式記事と私の環境での前提条件の相違点まとめ

	公式記事（builders.flash）	私の環境
スイッチロール	-	◯
アドミンアカウント	独立（OU外）	Organizationの管理アカウント以外でアドミンアカウントを作成
ターゲットアカウント	独立（OU外）	アドミンアカウントとは別の組織単位（OU内）
Stack Sets	セルフマネジメント型	サービスマネジメント型