マネージドサービス部 佐竹です。
AWS Resource Explorer のマルチアカウント検索機能を組織で有効化し、実際に利用してみたところ「ちょっとばかり期待と違った」という話を紹介します。また前提となる AWS Resource Explorer マルチアカウント検索の詳細な設定方法についても解説しています。
はじめに
AWS Resource Explorer は2022年11月に発表されたサービスです。
利用している AWS アカウントの全リージョンのリソースをまとめて検索できるサービスであり、無料で利用が可能です。
そして本サービスは2023年11月に「マルチアカウント検索」に対応しました。以下がその機能の詳細を説明している AWS 公式ブログです。
これによって、組織における「全アカウント＆全リージョン」のリソースが検索可能となり、マルチアカウント管理のリソース棚卸に非常に強力なツールとなりました。
今回はこの機能を有効化して実際に使ってみた感想を記載していきます。
マルチアカウント検索のセットアップ
まずは、マルチアカウント検索のセットアップ方法について詳細に解説します。
先にセットアップのための全体像を知る
AWS Resource Explorer のマネジメントコンソールにおける左端のメニュー「Explore resources > 設定」を選択すると、以下の画面が表示されます。
この画面の右上にある「組織で Resource Explorer を設定」ボタンから AWS Organizations における組織でのマルチアカウント検索を設定する画面に移動できますが、まずはこの画面の3ステップを確認します。
- 組織で Resource Explorer を設定
- マルチアカウントビューを作成および共有する
- アカウント全体でリソースを検索する
画像には上の通りの「3ステップ」が記載されているのですが、このステップは実際の設定とは少々説明の粒度がズレており理解を困難にしています。
ということで、同じ設定画面なのですが、少し先に進めると出てくる「別の説明画面」がありますのでこちらをご覧ください。こちらをご覧いただければ、4つのステップで進めることがよくわかるかと存じます。
マネジメントコンソールとは少々文言を変えますが、それは以下の4ステップです。
- Resource Explorer のために信頼されたアクセスを有効とする
- Resource Explorer のフルアクセス許可を委任された管理者アカウントに割り当てる ※委任は必須ではなくオプションです
- マルチアカウント検索用に Resource Explorer を設定 (Quick Setup or CloudFormation)
- マルチアカウントリソースビューを作成および共有する ※共有は RAM によって行うものでオプションです
この4ステップ(＋α)で進めていきます。
これは「先の AWS 公式ブログ」で記載のあった 次の 4 つのステップで組織のためにマルチアカウント検索を設定できます。 という4つのステップと順番は異なるものの内容は同じものとなっています。
では順に説明していきます。
信頼されたアクセスの有効化と委任設定（オプション）
マネジメントコンソールにおいては、先のステップ「1」と「2」を同時に進めます。
コンソールで設定を行う画面は、先に紹介しました「設定 > 組織で Resource Explorer を設定」から設定が可能ですが、以下の画面からでも同様の画面に遷移できます。
AWS Resource Explorer のトップ画面の右上「Resource Explorer をオンにする」を押下すると以下の画面が表示されます。
ここでさらに、画面右上の「マルチアカウント設定」を押下します。
そうすると上図の画面が表示されます。「信頼されたアクセスを有効にする」ために、それぞれのチェックボックスにチェックを入れます。
委任は必須ではないため、今回は指定せずに「確認」を押下し設定を完了します。もちろん設定頂いても問題はありません。
Quick Setup で Resource Explorer を設定
次のステップでは、組織の Resource Explorer を設定するために、①Systems Manager の Quick Setup (高速セットアップ) か ②CloudFormation StackSets を利用することになります。
今回はよりお手軽であろう「Systems Manager の Quick Setup (高速セットアップ)」で実装することとします。なお、Systems Manager の Quick Setup は結局のところ CloudFormation StackSets を実行するための機能ですので、最終的には CloudFormation StackSets が動作します。
また、ここで少々 Quick Setup に関する補足を行います。以下のブログで詳しく記載しているのですが、Quick Setup には多少癖があります。
それが事前に設定が必要となる「補足事項1. ホームリージョン」と「補足事項2. 委任管理者」に関してです。特に Quick Setup は「委任管理者」には未対応のため、マネジメントアカウントで Quick Setup を実行することとなります。
さらに加えて重要なのが、先のブログでも記載している以下の2点です。
- Quick Setup で実行される CloudFormation StackSets は、AWS Organizations の管理アカウントが実行対象とならないため仕様のため、もし管理アカウントにも配備されたい場合は個別に対応が必要となる
- Quick Setup が実行可能なリージョンにのみリソースが配備されるため、具体的には大阪リージョンは Quick Setup に対応しておらず除外される
この2点についても十分にご留意ください。
ということで上記をご理解いただけた後に Quick Setup を行います。
設定画面の「Quick Setup で設定を作成」ボタンを押下し、Quick Setup の「組織の Resource Explorer を設定」を開きます。
アグリゲータインデックスリージョンは、全リージョンの情報をどのリージョンに集約して表示するかという設定です*1。ここで指定したリージョンにおいては、Resource Explorer が全リージョンの情報をまとめて表示するようになりますので、メインで利用するリージョンを選択してください。今回は「アジアパシフィック (東京) ap-northeast-1」を選択します。
次の設定「ターゲット」では、全アカウントを対象としたいため「組織全体」を指定します。
「設定マネージャーの詳細 - optional」と「タグ - optional」はそれぞれオプションのため、今回は指定せずに「作成」を押下します。
Quick Setup が正しく実行されると、CloudFormation StackSets が動作します。
Quick Setup の「設定の詳細」を確認すると上図のように実行状況が確認できます。
さて、各アカウントで実際は何が作成されているのでしょうか？ ここでは IAM Role 以外のものを紹介します*2。
調査のために、作業を行っていたマネジメントアカウントからメンバーアカウントへとスイッチロールしてからの紹介となります。
1つ目が AWS Resource Explorer における「インデックス」の作成です。AWS Resource Explorer では各リージョンにおけるインデックスを元に情報を収集するため、インデックスの作成が各リージョンにて行われます。
なお、先の画面で「全 17 個中 16 個の AWS リージョンにインデックスを作成しました。」と記載があったのは、上図の通り「大阪リージョン」が設定されていないためです。
AWS Resource Explorer は大阪リージョンに対応していますが、Quick Setup が大阪リージョンに未対応のためこのような状況になっています。後追いでの対応となってしまいますが、大阪リージョンのインデックスを別途追加することで大阪リージョンのリソースも検索の対象にすることが可能です*3。
2つ目が「ビュー」です。「all-resources」という名のビューが自動的に作成され、ここにはそのアカウントの全リージョンのリソース情報が集約されています。
Quick Setup による CloudFormation StackSets が無事に完了したら、次のステップです。
マルチアカウントリソースビューを作成
設定における「4つのステップ」のうち、最後のステップです。
ここまでの設定で、組織における全てのメンバーアカウントでそれぞれ AWS Resource Explorer が有効化され、また全リージョンのリソース情報を集約する「all-resources」という名のビューが作成されるところまで行きつきました。
仕上げとして、マルチアカウントリソースビューを作成します。
設定画面から「マルチアカウントビューを作成」を押下して進めていきます。
「ビューの作成」画面でまずはビューの「名前」を入力します。ここはお好きな名前を入れてください。今回は「Organization-wide-View」という名称にしています。
次に「アカウントスコープ」では「組織全体のリソースの可視化」のラジオボタンを選択します。「組織」については特に変更はせず「Root」のままで問題ありません。
「リージョン」ではアグリゲータインデックスであるリージョンがデフォルトで選択されていると思われますが、ここは「アグリゲータインデックスリージョン」を必ず設定する必要があるため確認の上そのまま進めます。
「リソースフィルタ」と「追加のリソース属性」はそのままとし、全リソースを対象としながらタグ情報を集約します。
設定が完了したら「ビューの作成」を押下します。
これでマルチアカウントビューが完成しましたが、各アカウントの全リージョンのインデックスを収集するには時間がかかるため、しばし待ちましょう。この間にさらにやることがあります。
[追加作業1] マネジメントアカウントでインデックスを作成する
4つのステップでは不足している作業があります。
それは「マネジメントアカウントにおける AWS Resource Explorer 設定」です。何故かというと、繰り返しになりますが CloudFormation StackSets がマネジメントアカウントで実行されないためです。
マネジメントアカウントだけはこれまでの設定から置いてけぼりにされており、このままではマネジメントアカウントの情報が閲覧できないため、煩雑ながら手動で対応します。と言いましても、手順は非常に簡単です。
設定画面から「インデックスを作成」を押下します。
「インデックスを作成するリージョン」では手動で全てのチェックボックスにチェックを入れます*4。その後「インデックスを作成」を押下します。
次に「アグリゲータインデックスリージョン」を他と合わせます。具体的には「アジアパシフィック (東京) ap-northeast-1」を「アグリゲータインデックスリージョン」として設定します。
画像では既に変更済ですが、該当のリージョンを選択した後「インデックスタイプの変更」を押下します。
「インデックスのタイプ」において「アグリゲータインデックス」のラジオボタンを選択し、「変更の保存」を押下します。
一覧において「アジアパシフィック (東京) ap-northeast-1」の「タイプ」が「アグリゲータ」になれば完了です。
この作業により、マネジメントアカウントの全リージョンのリソース情報がマルチアカウントビューにも取り込まれるようになります。
[追加作業2] マネジメントアカウントでデフォルトのビューを設定する
ここまで設定が完了すると、設定画面の最上部に表示される「AWS マネジメントコンソールでの統合検索を使用したリソース検索の統合はオフになっています」という項目のうち、「2/3」までにチェックが入っているはずです。
- Resource Explorer は、このアカウントの 1 つ以上の AWS リージョンで有効になっています。
- 集約インデックスは AWS リージョンで設定されます。
- デフォルトのビューは、アグリゲータインデックスを含むリージョンに存在します。
このうちの3つ目も念のため完了させておきましょう。
左端メニューの「ビュー」を開くと先ほど作成した「Organization-wide-View」が「マルチアカウントスコープ」として存在しています。まず、こちらを選択します。
その後、「アクション」を開き、一覧から「デフォルトとして設定」を押下します。
「アジアパシフィック (東京) ap-northeast-1 のデフォルトビューとして「Organization-wide-View」を設定しますか?」という確認画面が出るため、「デフォルトとして設定」を押下して完了します。
ここまで設定が完了すれば「3/3」の全ての設定が完了したことになり、設定画面の最上部の文言は上図及び以下の表示に変更されます。
統合検索には、ビュー「Organization-wide-View」を使用したリソースの結果が含まれます
AWS マネジメントコンソールでの統合検索によるリソースの検索がオンになっています。
これで AWS Resource Explorer マルチアカウント検索の設定作業の説明が終了となります。お疲れ様でした。
手順の振り返りは「まとめ」で行うとして、ここからは機能の所感を記載していきます。
実際にマルチアカウント検索を使ってみた感想
ではやっと、もう1つの本題である AWS Resource Explorer のマルチアカウント検索の使い勝手について所感を記載していきます。
タグを予めリソースへ付与すれば活用の幅がより広がる
まず AWS Resource Explorer の取得できるのは主に以下の情報です。
- リソースタイプ
- ARN (Amazon Resource Name)
- リソースの存在する Region
- リソースが所属する AWS アカウント ID
- リソースに付与されている全てのタグ情報
つまりは、詳細な情報は Resource Explorer では取得が難しいことがわかります。反対にいうと、「タグをベースに検索する」にはかなり有用な機能となり得るでしょう。
ですので、使い勝手としては、Tag Editor に近いという印象を持ちました*5。
IP アドレス等の詳細が取得できない
実のところ、本機能はエンドユーザ様からの「特定の AWS アカウントにある全てのインスタンスの棚卸を行いたい」という要望をトリガーに検証を開始しました。
棚卸の用途によっては本機能が十分に活躍する場もあると考えますが、今回は「情報として各サーバの IP アドレスが欲しい」という依頼がありました。
resourcetype:ec2:instance で検索した結果を以下に示しますが、AWS Resource Explorer では IP アドレスなど VPC に紐づく情報が表示できません。
ですので、EC2 インスタンスのマネジメントコンソールのような「インスタンス一覧表」を作成できるかも、と期待してみると、少々残念な気持ちになります。
余談ですが、依頼頂きましたインスタンスの棚卸情報については、EC2 インスタンスのマネジメントコンソールの情報に加えて、AWS Systems Manager のインベントリの情報を加えたものをご提示することとして対応しました*6。
OR 条件が検索で利用できない
AWS Resource Explorer の検索クエリーは全て「AND」条件での検索となり、「OR」条件が利用できません。
これは以下公式ドキュメントにも記載があります。
When you use multiple filters, Resource Explorer evaluates the expression by combining the prefixes with implicit logical AND operators.
複数のフィルターを使用する場合、リソース エクスプローラーはプレフィックスを暗黙的な論理 AND 演算子と組み合わせて式を評価します。
そのため、例えば「アジアパシフィック (東京) ap-northeast-1」と「アジアパシフィック (シンガポール) ap-southeast-1」にある EC2 インスタンスの一覧を一度で検索し表示したい、ということができません。
この検索は、各リージョンが AND 検索によって評価されるため「そのようなリソースはない」という結果になります。
その代わりと言ってはなんですが、「ワイルドカード演算子」が利用できるため Tag:Environment=prod* のようにすることで、Environment タグキーのバリューが Prod と Production のリソースを同時に検索対象とするようなことは可能です。
大文字と小文字を区別できない
こちらも公式ドキュメントからの引用ですが、Resource Explorer の検索では大文字と小文字が区別されない仕様です。
Resource Explorer の検索では大文字と小文字は区別されないので、大文字・小文字の使用だけが異なるキー名や値は判別することができません。
そのため、先の具体例で「Tag:Environment=prod* のようにすることで、Environment タグキーのバリューが Prod と Production のリソースを同時に検索対象とすることが可能」と記載したのは誤りではなく、そもそも大文字小文字を区別しないためこのような結果になるのです。
なおこの仕様は若干の違和感がある方もいらっしゃるでしょう。
上のブログでも解説している通りですが、タグは大文字小文字を区別します。例えば「Name」タグと「name」タグは別のタグとして判断されてしまうのです。
ですが Resource Explorer ではそれを考慮しません。個人的には大文字小文字を区別するオプションがあれば良いなと少し感じました*7。
リソースの存在確認には有用
Resource Explorer は先に記載した通り、「タグ情報」をメインにした検索に有用であると記載しましたが、そもそものリソースの存在確認をする使い方に向いている機能だと感じました。
この画像は「VPC」が存在するかどうかの確認を Resource Explorer で行った結果となっています。
以下のブログでもご紹介している通りですが、セキュリティを鑑みたアカウントの発行対応を行う場合にデフォルト VPC を全て削除することがあります。
デフォルト VPC を全て削除するとなると、メインで利用するリージョン以外の VPC は存在しないのが常となりますが、この検索によって各リージョンの VPC がまだ残っている AWS アカウントがあることが簡単にわかります。
補足するとこれは「他社様から移管のあった AWS アカウント」で、これらの AWS アカウントにはデフォルト VPC が削除されずに残っている状態であることがわかっています。
このように、リソースの存在を確認するには一定の効果がある機能だと感じました。
まとめ
本ブログでは「AWS Resource Explorer のマルチアカウント検索機能を組織で有効化する手順」をステップバイステップでご紹介すると共に、使い勝手についての所感を記載しました。
マルチアカウント検索のセットアップ手順のまとめ
まずは AWS Resource Explorer マルチアカウント検索の「セットアップ手順のまとめ」を記載しておきます。
- AWS Resource Explorer で信頼されたアクセスの有効化と委任（※委任はオプション）
- Quick Setup もしくは CloudFormation StackSets で Resource Explorer を全アカウント×全リージョンで有効化
- AWS Resource Explorer のマルチアカウントリソースビューを作成
- [追加作業1] マネジメントアカウントで各リージョンのインデックスを作成後、アグリゲータインデックスリージョンを設定
- [追加作業2] マネジメントアカウントでデフォルトのビューを設定
- [必要な場合] 各アカウントの AWS Resource Explorer で「Quick Setup 未対応リージョン（大阪）」のインデックスを手動で追加
マルチアカウント検索の使い勝手の所感まとめ
続いてマルチアカウント検索の使い勝手の所感まとめです。
- タグを予めリソースへ付与すれば活用の幅がより広がる
- IP アドレス等の（リソースに付随する）詳細が取得できない
- OR 条件が検索で利用できない
- 大文字と小文字を区別できない
- リソースの存在確認には有用
結果的に Resource Explorer のマルチアカウント検索は期待通りの機能ではなかったのですが、無料で提供されている機能であることを忘れてはいけないでしょう。本機能の今後のアップデートを楽しみにしたいと思います。
では、またお会いしましょう。
*1:画面ではアグリゲーターインデックスリージョンとなっていますが、本ブログではアグリゲータで統一します
*2: IAM Role は AWS-QuickSetup-ResourceExplorerRole-xxxxx-ap-northeast-1 等の名前がついた Role が各リージョンに作成されます
*3:CloudFormation StackSets の場合は大阪リージョンも対応できる想定ですので、Quick Setup を利用されずに StackSets の採用も良いでしょう https://docs.aws.amazon.com/ja_jp/resource-explorer/latest/userguide/manage-service-all-org-with-stacksets.html
*4:他と異なり、アジアパシフィック (大阪) ap-northeast-3 も含まれていますがご容赦を
*5:もちろんタグエディターのようにタグをまとめて付与したり修正することはできないのですが
*6:AWS アカウント横断では取得できないため、対象 AWS アカウント全てにログインして取得しました
*7:何のためのタグポリシーなのでしょう https://blog.serverworks.co.jp/tag-policies
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
