AWS Configの新規リソースタイプ対応を検証、AWS Organizationsの記録結果と注意点

はじめに

今回は、2026年9月2日に発表されたAWS Configの新規リソースタイプ対応について説明します。

今回のアップデートでは60種類のリソースタイプが追加されました。Amazon BedrockやAmazon EC2、Amazon SageMakerなど幅広いサービスが対象となっていますが、その中にAWS Organizations関連のリソースも含まれています。組織のアカウントやポリシーといった情報をAWS Configの構成アイテムとして記録できるようになるため、マルチアカウント環境のガバナンスという観点では気になるアップデートかと思います。

筆者も手元のAWS Control Tower環境で確認してみたのですが、AWS Configの委任管理者であるAuditアカウントでAWS Configの画面を開いたところ、表示されたのは一部のポリシーのみで、アカウントや組織自体のリソースは表示されませんでした。そこで、管理アカウントやメンバーアカウントでも確認し、どのアカウントで何が記録されるのかを調べました。本稿ではその結果を説明します。なお、一部の挙動については原因を特定できていないため、確認できた事実と筆者の推測を区別して記載しています。

AWS ConfigのOrganizationsリソースタイプ対応とは

公式発表によると、今回追加された60種類のうち、AWS Organizations関連は以下の4種類です。

いずれも、Config recorderで全リソースタイプの記録を有効にしていれば自動的に記録対象となり、AWS Config rulesやAWS Config aggregatorでも利用できる、と発表文には記載されています。

表のとおり、AWS::Organizations::PolicyはSCPに限らず組織ポリシー全般を対象とするリソースタイプです。CloudFormationのリソースリファレンスでも、ポリシータイプにかかわらず同一のリソースタイプとして扱われています。組織ポリシーには多くの種類があるため、SCPだけが対象ではない点を押さえておくとよいでしょう。

また、AWS::Organizations::ResourcePolicyはRCPと名前が紛らわしいのですが、両者は別のものです。CloudFormationのリソースリファレンスによると、これはポリシー管理を委任管理者に委任するためのリソースベースポリシーを指します。第33回で管理アカウントの操作として設定した委任ポリシーが、このResourcePolicyにあたります。RCP自体はAWS::Organizations::Policyの対象です。

なお、今回の発表には含まれていませんが、AWS Configでサポートされているリソースタイプの一覧にはAWS::Organizations::OrganizationalUnitも記載されています。AWS Configのコンソールでリソースタイプを絞り込む際にも、上記の4種類に加えてOrganizationalUnitを選択できます。本稿では、このOrganizationalUnitを含めた5種類を対象に確認しています。

構成アイテムが作成されるリージョン

AWS Organizations関連のリソースはグローバルリソースにあたります。グローバルリソースの記録先については、AWS CloudFormationのドキュメントに以下の記載があります。

Global resource types onboarded to AWS Config recording after February 2022 will be recorded only in the service’s home Region for the commercial partition

2022年2月以降にAWS Configの記録対象へ追加されたグローバルリソースタイプは、そのサービスのホームリージョンでのみ記録されるという仕様です。AWS Organizationsのホームリージョンはus-east-1であるため、Organizations関連のリソースの構成アイテムもus-east-1にのみ作成されます。記録先のリージョンを設定で選ぶことはできません。筆者の環境でも、東京リージョンでAWS Configの画面を開いた場合、これらのリソースは表示されませんでした。マネジメントコンソールやCLIで確認する際は、us-east-1を参照するようにしてください。

検証環境

本稿では、AWS Control Towerで構築した下記の環境で確認を行いました。

• 

Auditアカウントは、Control Towerの設定によりAWS Configの委任管理者として登録されているアカウントで、本稿のために新たに設定したものではありません。なお、本稿の確認は、AWS Config aggregatorで集約した情報ではなく、各アカウント自身が記録したリソースを対象にしています。

AuditとWorkloadの2アカウントでは、Control Towerが作成したConfig recorderであるaws-controltower-BaselineConfigRecorderが稼働しており、recordingGroupの設定は2アカウントとも以下のとおり同一でした。

{
  "allSupported": true,
  "includeGlobalResourceTypes": false,
  "recordingStrategy": {
    "useOnly": "ALL_SUPPORTED_RESOURCE_TYPES"
  }
}

allSupported: trueかつALL_SUPPORTED_RESOURCE_TYPESの設定であるため、新しく追加されたリソースタイプも自動的に記録対象になるはずの状態です。一方、管理アカウントにはConfig recorder自体が存在していませんでした。

管理アカウントでの確認

前述のとおり、筆者の環境では管理アカウントにConfig recorderが存在しないため、確認用にus-east-1へConfig recorderと配信チャネルを作成しました。

重要： 本番のOrganizations管理アカウントに対する変更となるため、実施する場合は影響範囲を確認してください。全リソースタイプを記録する設定にすると、管理アカウント内のほかのリソースも記録対象となり、その分の料金が発生する点にも注意が必要です。なお、メンバーアカウントでは、第32回で紹介したControl Tower管理のSCPにより、Config recorderの設定変更が拒否されます。

配信先のS3バケットとバケットポリシーを用意したうえで、以下のコマンドを実行します。IAMロールには、AWS ConfigのサービスリンクロールであるAWSServiceRoleForConfigを指定しています。

~ $ aws configservice put-configuration-recorder --region us-east-1 --configuration-recorder '{
>   "name": "default",
>   "roleARN": "arn:aws:iam::{管理アカウントID}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig",
>   "recordingGroup": { "allSupported": true, "includeGlobalResourceTypes": true }
> }'
~ $ aws configservice put-delivery-channel --region us-east-1 --delivery-channel '{
>   "name": "default",
>   "s3BucketName": "{バケット名}"
> }'
~ $ aws configservice start-configuration-recorder \
>   --configuration-recorder-name default --region us-east-1

なお、ここではincludeGlobalResourceTypesをtrueにしており、falseになっているAuditやWorkloadのConfig recorderとは設定が異なります。ただし、ドキュメントによると、この設定はIAMのユーザーやグループ、ロールなどのグローバルリソースにのみ適用されるもので、Organizations関連のリソースは対象外です。そのため、この違いはOrganizations関連のリソースの記録には関係しません。

記録開始から約20分後、AccountとOrganizationalUnitが記録されました。AWS Configのコンソールでリソースのインベントリを開き、リソースタイプをOrganizations関連の5種類に絞り込むと、組織内の5つのアカウントと4つのOUが表示されています。

• 

一方、Organization・Policy・ResourcePolicyはすぐには記録されず、1週間近く経っても表示されない状態が続きました。その後、改めて確認したところ、これらも記録されていました。get-resource-config-historyで最初の構成アイテムの記録日時を確認した結果は以下のとおりで、Config recorderを作成してから記録が始まるまでの時間は、リソースタイプによって大きく異なりました。

Policyには、SCP・RCP・宣言型ポリシー・Backupポリシーなど9種類の組織ポリシーが30件すべて記録されていました。FullAWSAccessやRCPFullAWSAccessといったAWS管理ポリシーや、後述するAuditアカウントでの確認のために作成したRCPも含まれています。リソースのインベントリでも、5種類すべてのリソースが表示されるようになりました。

• 

Config委任管理者アカウントでの確認

次に、AWS Configの委任管理者であるAuditアカウントで確認します。Auditアカウントでは、冒頭で触れたとおりPolicyのみが6件表示され、それ以外のリソースタイプは表示されませんでした。同じ設定のConfig recorderが稼働しているWorkloadアカウントでは、5種類とも表示されませんでした。

• 

ところが、組織内にはlist-policiesで確認できる組織ポリシーが、AWS管理ポリシーを含めて9種類・30件存在するにもかかわらず、表示されているのは6件のみでした。内訳はSCP3件、宣言型ポリシー2件、Backupポリシー1件で、表示されている6件とそれ以外の24件の間に、アタッチの有無やポリシータイプによる違いは見られませんでした。また、30件のうち1件は、確認のために新規作成したRCPです。このRCPは、管理アカウントでは記録されたのに対し、Auditアカウントには執筆時点でも表示されていません。

原因を調査するため、表示されていたポリシーについてget-resource-config-historyで構成アイテムの履歴を確認しました。

~ $ aws configservice get-resource-config-history \
>   --resource-type AWS::Organizations::Policy \
>   --resource-id p-xxxxxxxxxx \
>   --region us-east-1
{
    "configurationItems": [
        {
            "version": "1.3",
            "accountId": "{AuditアカウントID}",
            "configurationItemCaptureTime": "2026-03-24T21:36:25.562000+09:00",
            "configurationItemStatus": "ResourceDiscovered",
            "arn": "arn:aws:organizations::{管理アカウントID}:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxxx",
            "resourceType": "AWS::Organizations::Policy",
            "resourceId": "p-xxxxxxxxxx",
            "resourceName": "Deny_Except_Root_Billing_Modify",
            "awsRegion": "us-east-1"
        }
    ]
}

※ 一部の項目は省略しています。

構成アイテムが記録された日時を示すconfigurationItemCaptureTimeは2026年3月24日で、今回のアップデートが発表された9月2日よりも前でした。宣言型ポリシーとBackupポリシーについても確認したところ、上記のSCPを含めいずれも3月24日の21時36分から43分の間に記録されたものでした。なお、同じポリシーを管理アカウントで確認すると、構成アイテムの記録日時は9月12日となっており、Auditアカウントに残っている3月24日のものとは別に記録されていました。

AWS Configのリソースのインベントリ画面には、「リソースタイプフィルタを使用すると、現在記録中のリソースに加え、過去に記録されたリソースも表示されます」という説明があります。これらを踏まえると、Auditアカウントに表示されていた6件は、現在記録されているものではなく、過去のある時点で記録された構成アイテムが残っているものと筆者は考えています。3月24日時点で記録された経緯は確認できていませんが、新規に作成したRCPが表示されないことや、組織内のポリシーの一部しか表示されないこととも整合します。

以上から、執筆時点の筆者の環境では、Organizations関連のリソースが新たに記録されているのは管理アカウントのみで、Config委任管理者アカウントやメンバーアカウントでは記録されていない、という状況です。

課題となりやすいポイント

最後に課題となりやすいポイントを紹介します。

（1）筆者の環境では、Organizations関連のリソースは管理アカウントでのみ記録されました。Control Towerのランディングゾーンでは管理アカウントにConfig recorderが存在しない場合があり、その場合はそのままでは記録されません。記録するには管理アカウントにConfig recorderを作成する必要がありますが、全リソースタイプを記録する設定にすると、管理アカウント内のほかのリソースも記録され、料金が発生します。Organizations関連のリソースだけを記録したい場合は、INCLUSION_BY_RESOURCE_TYPESで記録対象のリソースタイプを限定する設定を検討するとよいでしょう。

（2）Config委任管理者アカウントでAWS Config aggregatorを利用して組織全体を集約している場合も、記録元となる管理アカウントにConfig recorderがなければ、Organizations関連のリソースは集約されません。委任管理者アカウントから一元的に確認できる前提で設計しないよう注意してください。

（3）Config recorderで記録を有効にしても、すぐに記録されるとは限りません。筆者の環境では、AccountとOrganizationalUnitが約20分で記録された一方、Organization・ResourcePolicy・Policyは記録が始まるまでに7〜9日かかりました。特に発表から間もない時期は、記録されないからといって対象外や設定の誤りとすぐに判断せず、時間を置いて確認するとよいでしょう。

（4）Organizations関連のリソースの構成アイテムはus-east-1にのみ作成されます。東京リージョンを中心に運用している環境では、確認先のリージョンを誤らないよう注意してください。

おわりに

今回は、AWS ConfigのAWS Organizations関連リソースタイプ対応について、Control Tower環境でどのアカウントに何が記録されるのかを説明しました。管理アカウントでは5種類すべてのリソースタイプが記録されることを確認できましたが、記録が始まるまでに時間がかかるリソースタイプがあることや、Config委任管理者アカウントでは記録されないことなど、利用する前に把握しておきたい点もありました。本稿が、AWS Organizations環境でAWS Configの活用を検討されている方の参考になれば幸いです。