AWS Configアグリゲータによる収集データを、AWS LambdaからAPIで取得する

クラウドインテグレーションサービス部の内海です。

皆さんはAWS Configと聞くと何をイメージされますか？多くの場合、AWS Configの使い方は、下記のようなものになるかと思います。

• AWSリソースの設定を収集・記録・評価
• 定められたルールに対して各リソースの設定が準拠/非準拠かどうかを評価
• 必要に応じ、準拠するように設定を変える修復アクションを行う

それだけではなく、AWS Configには「アグリゲータ」という機能もあり、複数アカウントまたは複数リージョンの各リソースの設定データを簡単に1アカウントに集約できます。収集した結果はマネジメントコンソールやCLIのほか、AWS Lambda等からAPIで取得もできます。この機能を使えば、任意の処理の中でクロスアカウントのリソース情報を参照/付加するということが容易にできるようになります。

例えば、AWS Lambdaから別アカウントに存在するリソースのタグ情報などを直接参照しようとすると、スイッチロールが必要になるので実装が面倒になりがちです。こんなとき、AWS Configアグリゲータによってマルチアカウントのリソース情報を1つのアカウントに集約しておけば、AWS Lambdaにおけるスイッチロール処理の実装が不要になります。

今回は、AWS Configアグリゲータで収集したマルチアカウントのリソース情報を、AWS Lambdaから取り出す方法についてご紹介します。

環境構成と前提

AWS Configアグリゲータの情報をAWS Lambdaから取り出すテストをするために、下記の構成を作ります。

また、今回の検証は、下記の状態となっていることを前提として手順を進めます。

• AWS Configを有効化済みのAWSアカウントが2つ用意されている
• ソースアカウント（テスト構成図でいう「アカウントB」）でEC2が起動している

AWS Configアグリゲータの作成と承認

アカウントAでAWS Configアグリゲータの作成

まず、集約アカウントであるアカウントAでAWS Configアグリゲータの作成を行います。

AWSマネジメントコンソールにサインインし、AWS Configサービス画面を開きます。左側メニューから[アグリゲータ]を選択し、[アグリゲータを作成]をクリックします。

以下のキャプチャの通り設定していきます。ここではアグリゲータ名は「Test_Config_Aggregator」としています。

[アカウント]の項目で、対象となるAWSアカウントIDを入力します。今回はアカウントBのものを入力しました。

※ AWS Organizationsを利用しており、組織内全てのアカウントを追加したい場合は[組織を追加する]を選択することで簡易に設定ができます。

最後に[リージョン]の項目でリージョンを指定します。ここでは東京リージョン（ap-northeast-1）を指定しています。ここまで入力したら、右下の[アグリゲータを作成]をクリックして作成します。

これでAWS Configアグリゲータの作成は完了です。

アグリゲータ名をクリックすると、この時点ではアカウントBのステータスが「未完了」になっていますが、この後アカウントBで「Configアグリゲータの承認」を行えば完了になるため、今は気にしなくて大丈夫です。

アカウントBでAWS Configアグリゲータの承認

ソースアカウントであるアカウントBにログインし、AWS Configアグリゲータの承認を行います。

アカウントBのAWS Configサービス画面に行くと、[アグリゲータ]の[認証]の項目に①という青いアイコンがあります。[認証]をクリックすると、先ほどのアカウントAのIDからの承認依頼が表示されているので、[承認]をクリックして承認します。

認証のステータスが「承認済」になることを確認します。このあと、しばらく時間を置くとアカウントA側から見てアカウントBのステータスが「OK」になります。

承認後、すぐに確認するとFAILEDまたは未完了となる場合がありますので、10分程度時間を置いてみてください。

Lambda関数とIAMロールの作成

アカウントAでAWS Lambda用IAMロールの作成

AWS LambdaからAWS Configアグリゲータの収集データを取得するには、AWS Configの「GetAggregateResourceConfig」アクションを許可するIAMポリシーが必要になります。これを許可するIAMポリシーを含むAWS Lambda用のIAMロールを作成します。

IAMポリシーおよびIAMロールの詳細な作成手順は本記事では割愛します。下記に最低限必要なポリシーとロールの信頼関係のJSONのみ記載します。

※ ポリシー名、ロール名は何でも良いので、お好みで変えていただいて大丈夫です。

IAMポリシー「GetAggregateResourceConfig」許可ポリシー（JSON）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "config:GetAggregateResourceConfig",
            "Resource": "*"
        }
    ]
}

IAMロール「GetConfigAggregatorForLambda」 信頼関係（信頼されたエンティティ）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

今回は手順のシンプルさを重視し、Resourceを絞っていませんが、実務で利用する際は、ポリシーのResource部分をワイルドカードではなく、今回利用するConfigアグリゲータのみに限定することをお勧めします。

アカウントAのAWS LambdaでアカウントBのEC2情報を抜き出し

先ほどの設定でアカウントAのAWS ConfigアグリゲータにアカウントBのEC2を含むリソース情報が集約されたので、これをアカウントAのAWS Lambdaから取得します。

アカウントAでランタイム Python3.11を選択したLambda関数を作成します。作成時には、AWS Lambdaのデフォルトの実行ロールの変更から先ほど作成したIAMロール（本記事ではロール名「GetConfigAggregatorForLambda」）を選択するようにしてください。

以下のPythonコードによって、アカウントBにあるEC2のNameタグ情報をアカウントAのConfigアグリゲータから取り出し、printでLambda実行ログ上にNameタグを出力させます。

Lambdaコード

import boto3
 
config_client = boto3.client('config')
 
def lambda_handler(event, context):
 
    account = '<アカウントBのAWSアカウントID>'
    instanceId = '<今回タグ情報を取得するアカウントBの特定のEC2のインスタンスID>'
 
    # boto3のAPI「get_aggregate_resource_config」を利用して、ConfigアグリゲータからEC2リソース情報を取得
    # インスタンスIDをキーとして該当するアカウントBの該当EC2を特定
    config_response = config_client.get_aggregate_resource_config(
        ConfigurationAggregatorName='Test_Config_Aggregator' ,
        ResourceIdentifier={
            'SourceAccountId': account,
            'SourceRegion': 'ap-northeast-1',
            'ResourceId': instanceId,
            'ResourceType': 'AWS::EC2::Instance',
        }
    )
 
    # 該当EC2のConfigデータが入ったconfig_responseからNameタグ情報を抜き出し、printでコンソール出力
    tag = config_response['ConfigurationItem']['tags']['Name']
    print(tag)

accountとinstanceIdは各環境に応じて修正してください。コード中の「ConfigurationAggregatorName＝」の値は、先ほどの手順で作成したAWS Configアグリゲータの名前を指定します。

AWS Lambdaの実行テスト

これで構成は完了したので、AWS Lambdaのテストイベントからテストを実行し、コンソールに該当EC2のNameタグが出力されることを確認します。

該当するAWS Lambdaの「テスト」タブをクリックし、テストイベント項目の右端「テスト」をクリックします。テストイベントの中身は何でも良いので、デフォルトから変更しなくて大丈夫です。

「実行中の関数：成功」と表示されたら「詳細」をクリックし、キャプチャの下部赤枠の部分に今回のNameタグが出力されていることを確認します。

想定通り、AWS Lambdaがスイッチロール等を経ることなく、異なるアカウントのEC2タグ情報を取得できました。

活用事例

「では、この仕組みは実運用でどのように活用できるのか？」と気になった方もいらっしゃるかと思います。

そこで私が企業の本番システムで導入した、マルチアカウント環境でのCloudTrailイベント通知機能での活用事例をお伝えします。

マルチアカウント環境CloudTrailイベント通知機能

とある企業の情報システム部門で、EC2の起動/停止のAPI操作が行われたときにEメールで情報システム担当者に通知したいという要望がありました。

最初に思い付いた構成は、EventBridgeによってCloudTrailのEC2起動/停止API操作ログをトリガーに、SNSトピックに通知するというものでしたが、情報システム担当者から、「一目で対象がわかるように該当のEC2の名前（Nameタグ）を表示してほしい」という要望がありました。CloudTrailイベント通知にはEC2のインスタンスIDはあってもタグは含まれていないため、前述の構成では実現できませんでした。

そこでやり方を検討した結果、今回のAWS Configアグリゲータの情報に至りました。AWS ConfigアグリゲータとAWS Lambdaを加えて実装したイベント通知の構成図がこちらです。

EventBridgeとSNSの間にAWS Lambdaを挟み、そのAWS Lambdaにおいて起動/停止検知したEC2インスタンスIDをキーにしてAWS Configアグリゲータから該当EC2のNameタグを引っ張り、SNS経由で担当者にEメール通知する、という構成を作ることで、無事にやりたいことを実現することができました。

AWS Configアグリゲータはマルチアカウントの対応も簡単なので、将来対象アカウントが増えたときも比較的簡単に処理することができます。

おわりに

AWS Configサービスについては、設定の準拠/非準拠を見る用途での利用が多く、アグリゲータについての記事は比較的少ないですが、今回のケースのように、クロスアカウントでリソース情報をAPIからスイッチロール無しで手軽に取得したいというケースでは活躍することもあります。マルチアカウントを管理する担当者の方は、ぜひ覚えておいていただけたらいつか役に立つ日が来るかもしれません。

今回はAWSに関するご紹介でしたが、ラックではOCI、Azure、Google Cloudについても取り扱っています。お客様のシステム環境の課題に合わせて、適切なソリューション・サービスを提案いたしますので、マルチクラウドやハイブリッドクラウドも含めたシステム構成に関するお悩みがございましたら、ぜひラックまでお問い合わせください。

プロフィール