はじめに

本文書では、Turbonomicの8.14.4でリリースされたマルチアカウントAWSターゲットの機能についてご紹介します。
特に多数のAWSアカウントの管理をされている環境などでは有用な機能かと存じますので、よろしければご参照下さい。

これまでのAWSアカウントの管理

大前提としてAWSのアカウントの構成ですが、一般的に、一定規模以上の環境では、こちらの絵の様に、AWS Organizationが構成され、そのとりまとめのアカウントとして管理アカウント（Management Account）が課金情報も含めた最も強力な権限を持つアカウントとして存在し、その配下に、各部門であったり組織単位でメンバーアカウント（Member Account）が構成されます。

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_getting-started_concepts.html

これまでのTurbonomicの AWSアカウント登録構成

これまでTurbonomicに各アカウントを登録する際は、以下の様な構成で登録頂くのが一般的でした。

AWS Billing Account : 管理アカウント（管理アカウントで作成されたCURを読むため）
AWS Account①：メンバーアカウント①
AWS Account②：メンバーアカウント②
AWS Account③：メンバーアカウント③
：

但し、この形ですと、メンバーアカウントの数が少ない分にはよいのですが、アカウント数が多くなるにしたがって、各メンバーカウント上での設定や、Turbonomicの登録に手間がかかるケースがありました。（スクリプトなどで自動化は可能ですが、それもまた面倒）

新機能：AWSクロスアカウントIAMロールによる自動登録

今回、2024年12月にリリースされた8.14.4では "AWSクロスアカウントIAMロール"を用いる事によって、このメンバーアカウントの登録の自動化が可能になりました。これによって、以下の様に管理アカウントのみの登録によって、その配下のメンバーアカウントの検出・管理が可能になりました。

AWS Billing Account : 管理アカウント（管理アカウントで作成されたCURを読むため）
AWS Account全て：管理アカウント（管理アカウントの登録のみで、配下のメンバーアカウントを自動追加）

仕組み

具体的には、AWSのCloudFormationのStackSetを用いて、管理アカウント配下のメンバーアカウント上に、Turbonomicの操作に必要となるIAMロールを自動的に作成する事によって実現しています。（そして、そのメンバーアカウント上のIAMロールに対しては、管理アカウント上のIAMユーザー・ロールからのアクセスが許可されます）

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html

設定手順

具体的な設定手順は以下マニュアルの方をご参照頂ければと思います。
https://www.ibm.com/docs/ja/tarm/latest?topic=turbonomic-setting-up-aws-cross-account-iam-role

なお、この辺りの設定については、最近のTurbonomicではユーザーフレンドリーなUIが意識されており、以下の様な画面の指示に従う事で、マニュアルをあまり参照しなくても設定は可能かもしれません。（とはいえ、最初はマニュアルを熟読頂く事をお勧めします）

UIからの設定手順実行例

※以下は管理アカウント上のIAMユーザーを用いた設定例となります。（SaaS版Turbonomicでは、IAMユーザーに代わってIAM Roleを用いた設定も可能です。）

設定 -> ターゲットの追加 -> AWS

Multiple Accountsを選択（こちらが今回追加された新機能のマルチアカウント対応）

設定に必要なIAMユーザーのポリシーのJSONファイルをクイックガイドからダウンロード（ここは従来のAWSアカウントの設定と同じ。管理アカウント上にEC2などの最適化対象のリソースがあれば、ここの設定によって管理可能となります）

対象ポリシーを持つIAMユーザーのアクセス・シークレットキーを登録の上、次へ

新機能：配下のメンバーアカウントへのアクセスに際して必要となるCloudFormationのテンプレートをダウンロード。管理アカウント上でStackSetを作成し、その際に指定したメンバーアカウント用のIAMロールの名前（デフォルトではTurbonomic_Org_Access）を指定し、次へ。

プロキシ経由のアクセスが必要な場合は入力の上、登録。

設定完了後の状況

AWS管理アカウント

CloudFormationのStackSetの詳細。配下のメンバーアカウントがスタックインスタンスとして表示され、その処理が成功している状況。

AWSメンバーアカウント

管理アカウントで定義されたStackSetによって、メンバーアカウント上のCloudFormationのスタックが実行された状況。また、その処理の中でIAMRoleが作成されている。

作成されたIAMRoleを確認。管理アカウントのIAMユーザー（Turbonomicへ登録したユーザー）に対して信頼関係が設定されている為、管理アカウントのIAMユーザー経由で、こちらのメンバーアカウント上のEC2等のリソースの検出が可能になっている状況。

Turbonomicのターゲット設定

AWS Organizationというタイプで登録が完了した状態。

管理アカウント一つの登録で、管理アカウント自身、及び、配下のメンバーアカウントが検出された状況

まとめ

いかがでしょう、これまで多数のAWSアカウントが存在した場合には、一つ一つ個別に設定・登録が必要でしたが、この機能によって、一括して纏めて登録が可能となりましたので、結果、大幅な作業工数の削減につながる事がご想像できたのではないかと思います。

一方で、運用上の意図（例えば特定のアカウントはTurbonomicの管理対象にはいれたくない）といった場合には、引き続き、これまでと同様に、個別のアカウントとしての登録も可能ですので、その辺りは適材適所で使い分けて頂ければと思います。

※なお、マニュアルにも記載されておりますが、一つのアカウントを重複して管理させることは出来ませんので、例えば、既に個別のメンバーアカウントが登録された状態で、クロスアカウントが利用可能な管理アカウントを追加した際は、関連ターゲットがDuplicate Targetとしてエラーが表示されます。
ただ、これは予期される動作となりますので、その際は、登録済みの個別のメンバーアカウントを削除頂く事で、継続して対象EC2インスタンスなどの管理が可能です。ご承知おき下さい。