セキュリティサービス部 佐竹です。
AWS アカウントが AWS Organizations（組織）に参加 or 離脱する時の CloudTrail イベントを監視し通知したいという運用に関しアップデートがありましたので、そのキャッチアップと共に現状を整理しました。
はじめに
2026年5月28日に AWS Organizations の運用に関連して、メンバーアカウントの参加および離脱（脱退）に関する新しい CloudTrail イベントが追加されました。
追加されたイベントは「AccountJoinedOrganization」と「AccountDepartedOrganization」の2つです。
今回はこの追加と、今までの運用を踏まえて、メンバーアカウントの参加および離脱（脱退）に関するイベントを整理することが目的です。
なお、本ブログ記事は AWS Organizations の運用を行っている中級～上級 AWS (DevOps) エンジニアを想定して記述しております。また、そのためにかなり詳細を記述しているため長文となっています。
これまでに記述したブログ
2020年12月に、私は「アカウントの新規作成を監視し、通知する」という目的で上記ブログを記述しています。
さらに2024年11月に「新規作成だけではなく、組織間の移動や解約も監視、通知する」というブログを記述しました。
このときに、CreateAccount, CreateAccountResult, CloseAccount などなど・・・複数のイベント（≒ API Call）をご紹介してきましたが、種類が多くなかなかに混乱します。
そこに加えて AccountJoinedOrganization とAccountDepartedOrganization が追加されたことで、さらにややこしくなったと感じます。
こうなってくると「AWS Organizations におけるアカウントの追加、削除（参加、離脱）に関して、どのイベントを監視し通知すべきなのか？」という疑問が生まれます。
というわけで、まずは AWS アカウントの追加、削除（参加、離脱）に関するイベントを整理します。
AWS ドキュメント
なお本ブログは以下の AWS 公式ドキュメント（API リファレンス）を正としています。
参加および離脱に関するイベントの詳細
アカウントの作成と閉鎖時
まずは組織でメンバーアカウントを「作成する」「閉鎖する」という2点に絞って解説します。
CreateAccount
AWS Organizations で新しいメンバーアカウントの作成を申請する操作（API Call）です。この処理は非同期で行われるため、申請自体が正常に受け付けられても、すぐにアカウントが使えるようになるわけではありません。
AWS のバックグラウンドでは、管理アカウントから会社名や住所などの情報を引き継いだり、管理用の IAM ロールを自動作成したりするセットアップ処理（初期化）が数分かけて行われます。リクエストを送った時点では、この裏側のセットアップが最終的に成功するか失敗するかまでは確定していないため、成否を判断するには後続のイベントを待つ必要があります。
例えば新規アカウント発行時に「メールアドレスの重複」等により、処理が「Failed」することがあります。よって、この API Call イベントを監視しているだけでは、正しくアカウントの発行（新規作成）をキャッチできない場合があります。
CreateAccountResult
CreateAccount によるバックグラウンドのセットアップ処理が最終的にどうなったか、その結果を記録する CloudTrail イベントです。このイベントには「成功」と「失敗」のどちらかが記録されます。
補足ですが、このイベントは「API Call」自体ではありません。ですので、API Reference に掲載がありません。先の CreateAccount を AWS 側が受け取った後、後続のイベントとして CloudTrail に返すものです。
私が過去のブログでも掘り下げたように、監視運用の観点では、CreateAccountResult における「成功（SUCCEEDED）」のイベントを検知対象とするのが適切です。前述したメールアドレスの重複などによって作成が失敗した場合、結果としてアカウント自体が作成されません。アカウントが存在しなければ、その後のセキュリティ設定や監視の有効化といった運用プロセスにつなげる必要がないため、失敗イベントを監視することは運用上のノイズになってしまいます。
確実に新しいアカウントが組織に誕生したタイミングを捉えるためには、このイベントの成功をトリガーにする必要があります。
CreateAccountResult の実例
実際に CloudTrail から確認してみると「CreateAccount」の後に「CreateAccountResult」のイベントが記録されていることがわかります。
{ "eventVersion": "1.08", "userIdentity": { "accountId": "999999999999", "invokedBy": "AWS Internal" }, "eventTime": "2026-06-09T06:47:38Z", "eventSource": "organizations.amazonaws.com", "eventName": "CreateAccountResult", "awsRegion": "us-east-1", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": null, "responseElements": null, "eventID": "b9e70be0-f0da-4038-82ce-aaaaaaaaaaaa", "readOnly": false, "eventType": "AwsServiceEvent", "managementEvent": true, "recipientAccountId": "999999999999", "serviceEventDetails": { "createAccountStatus": { "id": "car-05efc21e72ed499ba5b0bbbbbbbbbbbb", "state": "SUCCEEDED", "accountName": "****", "accountId": "111111111111", "requestedTimestamp": "Jun 9, 2026 6:47:36 AM", "completedTimestamp": "Jun 9, 2026 6:47:38 AM" } }, "eventCategory": "Management" }
なお、「999999999999」が管理アカウントで、「111111111111」がメンバーアカウントのアカウント ID です。
CloseAccount
AWS Organizations で組織内のメンバーアカウントの閉鎖を申請する操作（API Call）です。CreateAccount と同様にこの処理も非同期で行われるため、申請自体が正常に受け付けられても、その瞬間にアカウントの閉鎖が完了するわけではありません。
AWS のバックグラウンドでは、対象アカウントのステータス変更やリソースの停止に伴う処理が実行されます。リクエストを送った時点では、この裏側の閉鎖処理が最終的に成功するか失敗するかまでは確定していないため、実際にアカウントが閉じられたかどうかを判断するには、後続のイベントを待つ必要があります。
CloseAccountResult
CloseAccount によるバックグラウンドの閉鎖処理が最終的にどうなったか、その結果を記録する CloudTrail イベントです。
こちらも CreateAccountResult と同様に「API Call」自体ではないため、API Reference には掲載されていません。申請が受け付けられ、アカウントのステータスが PENDING_CLOSURE から閉鎖完了を示す「CLOSED」へと正常に遷移した後に、CloudTrail に追加されるイベントとなっています。
監視運用の観点では、同様に CloseAccountResult が重要になります。
CloseAccountResult の実例
こちらも同様の順序です。
{ "eventVersion": "1.11", "userIdentity": { "accountId": "999999999999", "invokedBy": "organizations.amazonaws.com" }, "eventTime": "2026-06-09T08:51:39Z", "eventSource": "organizations.amazonaws.com", "eventName": "CloseAccountResult", "awsRegion": "us-east-1", "sourceIPAddress": "organizations.amazonaws.com", "userAgent": "organizations.amazonaws.com", "requestParameters": null, "responseElements": null, "eventID": "45153fe3-1e03-464c-92c2-aaaaaaaaaaaa", "readOnly": false, "eventType": "AwsServiceEvent", "managementEvent": true, "recipientAccountId": "999999999999", "serviceEventDetails": { "closeAccountStatus": { "accountId": "111111111111", "state": "SUCCEEDED", "requestedTimestamp": "Jun 9, 2026 8:51:38 AM", "completedTimestamp": "Jun 9, 2026 8:51:38 AM" } }, "eventCategory": "Management" }
「999999999999」が管理アカウントで、「111111111111」がメンバーアカウントのアカウント ID です。
注意：SUSPENDED と CLOSED の違い
AWS アカウントを閉鎖すると、現在組織のアカウント一覧では「Closed」と表示されます。これは現在2つある状態のうち「State」を表示しています。
上記はマネジメントコンソールの表示です。ポップアップされている英語の翻訳は以下の通りです。
これらのアカウントは、お客様または AWS によって閉鎖されており、閉鎖後90日間の猶予期間が設けられています。アカウントは、この猶予期間中に再開できます。この状態は現在、「SUSPENDED」アカウントステータスに相当します。
まだアカウント自体は完全に削除されているわけではなく90日間の猶予期間中を指し示しており、この状態は元来「SUSPENDED」として知られていました。
以下の AWS CLI の結果の通り、現時点ではアカウントには「State」だけでなく「Status」も含めて2つの状態を示す返り値があります。
~ $ aws organizations describe-account --account-id 111111111111 { "Account": { "Id": "111111111111", "Arn": "arn:aws:organizations::999999999999:account/o-orgid/111111111111", "Email": "ssss-test@serverworks.co.**", "Name": "ssss-test", "Status": "SUSPENDED", "State": "CLOSED", "Paths": [ "o-orgid/r-wwww/ou-wwww-00000000/111111111111/" ], "JoinedMethod": "CREATED", "JoinedTimestamp": "2026-06-09T06:35:58.905000+00:00" } }
このように「State」と「Status」が同時に返却される状況になっていますが、2026年9月9日を境に「State」フィールドのみが有効（唯一の基準）になります。つまり今コンソールに表示されている「Closed」は正です。
以下は AWS からのメールによるお知らせ本文です。
AWS Organizations has transitioned from the account status (Status field) to the new account state (State field) to provide more detailed account lifecycle information. The new State field offers enhanced granularity with values including PENDING ACTIVATION, ACTIVE, SUSPENDED, PENDING CLOSURE, and CLOSED, available through both the AWS Organizations console and APIs (DescribeAccount, ListAccounts, ListAccountsForParent, ListDelegatedAdministrators).
Starting September 9, 2025, we have begun a one-year transition period where both Status and State fields will be available in the API responses. After September 9, 2026, the Status field will be permanently removed. If you use automated processes for account management, we recommend updating your systems to use the State field before the deprecation date. For more information, see Updates to account status information in AWS Organizations [1] or visit our documentation [2].
---以下、日本語訳---
AWS Organizations では、アカウントのライフサイクル情報をより詳細に提供するため、アカウントステータス (Status フィールド) から新しいアカウント状態 (State フィールド) に移行しました。新しい State フィールドでは、PENDING ACTIVATION、ACTIVE、SUSPENDED、PENDING CLOSURE、CLOSED などの値を含む、より詳細なステータス情報が得られます。これらの値は、AWS Organizations コンソールと API (DescribeAccount、ListAccounts、ListAccountsForParent、ListDelegatedAdministrators) の両方で利用可能です。
2025 年 9 月 9 日より、Status フィールドと State フィールドの両方が API レスポンスで利用可能となる 1 年間の移行期間を開始しました。2026 年 9 月 9 日以降、Status フィールドは完全に削除されます。アカウント管理に自動化プロセスを使用している場合は、廃止日までにシステムを更新して State フィールドを使用することをお勧めします。詳細については、AWS Organizations のアカウントステータス情報の更新 [1] を参照するか、ドキュメント [2] をご覧ください。
関連する告知ページは以下の通りで、廃止1年前となる2025年9月に出ています。
Status フィールドについては以下のドキュメントにまとまっていますため、あわせてご覧ください。なお、State には現在「5つの状態（PENDING ACTIVATION、ACTIVE、SUSPENDED、PENDING CLOSURE、CLOSED）」があります。
SUSPENDED は今後ペナルティを受けたことを示す
ここで念のため、SUSPENDED について補足をします。
まず結論から記述すると、SUSPENDED は引き続き「State」でも利用されます。
どのように利用されるかというと、AWS ドキュメントからの引用となりますが以下の通りです。
In this state, the account is unusable because AWS has restricted access. The account holder can still view billing information and contact Support, who can explain why the account is suspended.
---以下、日本語訳---
この状態は、AWS がアクセスを制限しているため、アカウントは使用できません。アカウント所有者は請求情報を確認したり、サポートに問い合わせてアカウント停止の理由を説明を受けることは可能です。
これまでは、自分でアカウントを閉鎖した（90日間の猶予期間中の）場合も、システム内部では SUSPENDED と表現されていました。
ですが、新仕様においては、上記説明にある通り「AWS has restricted access（AWS がアクセスを制限した）」、つまり料金未払いや規約違反、セキュリティインシデントなどで AWS 側からペナルティとして強制停止された状態を指す専用のステータスとして再定義されました*1。
この2つに分離されたことで、自ら閉じたアカウントと、AWS によって強制処理されたアカウントを今後はすぐに区別できるようになったわけです。
補足: 強制的にアカウントが Suspend されるケース
まずは利用料金の未払いがあげられます。
AWS_BILLING_SUSPENSION_NOTICE– Your account has outstanding charges and has been suspended, or you deactivated your account.
また、 Abuse Notice （アカウントの不正利用）へ反応しない場合も同様です。
Note: If you don't respond to an abuse notice within 24 hours, AWS might block your resources or suspend your AWS account.
注：不正利用に関する通知に24時間以内に対応しない場合、AWS はお客様のリソースをブロックしたり、AWSアカウントを一時停止したりする可能性があります。
組織間の移動時
新規作成や閉鎖といったライフサイクルとは別に、既存のメンバーアカウントを別の AWS Organizations 組織へ移動させる（離脱と受け入れ）運用が発生することもあります*2。以下はそれに関連する主な API 及び関連するイベントです。
これら組織間の移動手続きに関しては、公式のナレッジセンターにも一連の流れがまとまっていますので、あわせて参照してください。
RemoveAccountFromOrganization
管理アカウントが、指定したメンバーアカウントを組織から強制的に追い出す（キックアウト）する操作であり、その API Call です。この操作が実行されると、対象のアカウントは組織の管理下から外れ、スタンドアロンのアカウントとなります。
InviteAccountToOrganization
他の組織に所属している、あるいはスタンドアロン状態の既存のメンバーアカウントを自組織へ招待するリクエスト（API Call）です。注意点として、この API Call はあくまで「招待を送る」という非同期の手続きであるため、招待が最終的にどうなったかを追跡するには、後述するハンドシェイク関連の状態を確認する必要が出ます。
送った招待は「CancelHandshake」を用いてキャンセルすることも可能です。
AcceptHandshake
送られた招待（ハンドシェイク）を、招待された側が受け入れる操作（API Call）です。
DeclineHandshake
送られた招待（ハンドシェイク）を、招待された側が拒否する操作（API Call）です。
LeaveOrganization
メンバーアカウント側が、自発的に所属している組織から離脱してスタンドアロンになるための操作（API Call）です。
マルチアカウント運用における統制の観点から、また我々のようなリセラーの管理下においては、管理アカウントの SCP（サービスコントロールポリシー）においてこの操作を明示的に Deny します*3。このため、実際のエンタープライズ運用においては、基本的に実行が封じられていることが多い操作となります。
AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール
LeaveOrganization の禁止については、以下も参考になるでしょう。
運用におけるハンドシェイクの状態管理について
InviteAccountToOrganization を実行すると、非同期処理の管理のために「Handshake」というオブジェクトが作成され、固有の HandshakeId が発行されます。
招待を送った側の組織は、この HandshakeId を使って DescribeHandshake や ListHandshakesForOrganization などのAPIを呼び出すことで、相手がどう対応したかを追跡できます。ハンドシェイクには State 属性があり、相手の操作によって以下のようにリアルタイムに更新されます。
ドキュメントで定義されている State の有効な値は以下の6つです。
REQUESTED: 受信者（招待されたアカウント）からの応答を待っている状態OPEN: 複数の受信者に送信され、すべての受信者が応答した状態。送信者がハンドシェイクアクションを完了できる状態CANCELED: 送信者が招待を途中でキャンセルした状態ACCEPTED: 受信者によって承諾された状態DECLINED: 受信者によって拒否された状態EXPIRED: ハンドシェイクの有効期限が切れた状態
これまでとこれから
ここまで見てきたように、AWS Organizations の組織に所属するメンバーアカウントが増減することを検出するには運用上の手間が大きいことがわかります。
- アカウントの新規作成は
CreateAccountではなく、CreateAccountResultの「成功」を監視する - アカウントの閉鎖は
CloseAccountではなく、CloseAccountResultの「成功」を監視する - アカウントの追い出しは
RemoveAccountFromOrganizationを監視する - アカウントの移管の依頼は
InviteAccountToOrganizationを監視する - アカウントの移管の受け入れは
AcceptHandshakeを監視する
このように、これまでは「アカウントが組織に参加した」「組織から離脱した」という状態変化を捉えるために、複数の異なる API Call や非同期の結果イベントを個別に監視し、組み合わせる必要がありました。
そこで登場するのが、今回追加された AccountJoinedOrganization と AccountDepartedOrganization という2つの新しいメンバーシップイベントです。
これらのイベントの追加により、これからの監視設計は「どの API が実行されたか」を個別に追いかける形から、「組織に変化があったか」という目的ベースのイベントを直接トリガーにする形へと、シンプルに整理できるようになりました。
AccountJoinedOrganization
新しいメンバーアカウントが組織に参加した際に、管理アカウントのイベント履歴に記録される新しいメンバーシップイベントです。
このイベントは、CreateAccount が成功したとき、または他組織からの招待に対して AcceptHandshake が実行されて受け入れが成功したときに、ほぼリアルタイムで発報されます。
イベントの要素には joinedMethod フィールドが含まれており、「joinedMethod:CREATED（新規作成による参加）」や「joinedMethod:INVITED（招待による参加）」のように、どのような経緯で組織に参加したかというコンテキストも記録されます。
これまでは新規発行と外部からの移管で異なる API やイベントを別々にフックして監視ロジックを組む必要がありましたが、今後はこの AccountJoinedOrganization を一元的に監視するだけで、組織へのアカウント追加を網羅できるようになります。つまり、「メンバーアカウントの増加時に、非常に監視運用が楽になる」のです。
AccountJoinedOrganization の実例1(CREATED)
「CreateAccount」 で検証してみたところ、以下の通りの順序となりました。
「CreateAccountResult」とほぼ同時、実際に秒レベルのタイムスタンプでは「AccountJoinedOrganization」と同時刻になってます。
以下が実際の JSON です。
{ "eventVersion": "1.11", "userIdentity": { "accountId": "999999999999", "invokedBy": "organizations.amazonaws.com" }, "eventTime": "2026-06-09T06:47:38Z", "eventSource": "organizations.amazonaws.com", "eventName": "AccountJoinedOrganization", "awsRegion": "us-east-1", "sourceIPAddress": "organizations.amazonaws.com", "userAgent": "organizations.amazonaws.com", "requestParameters": null, "responseElements": null, "eventID": "beac3d74-50a6-4ff8-8f14-123123123123", "readOnly": false, "eventType": "AwsServiceEvent", "managementEvent": true, "recipientAccountId": "999999999999", "serviceEventDetails": { "accountId": "111111111111", "joinedTime": "Jun 9, 2026 6:47:38 AM", "joinedMethod": "CREATED" }, "eventCategory": "Management" }
「999999999999」が管理アカウントで、「111111111111」がメンバーアカウントのアカウント ID です。
"joinedMethod": "CREATED" となっていることも確認できています。
AccountJoinedOrganization の実例2(INVITED)
{ "eventVersion": "1.11", "userIdentity": { "accountId": "999999999999", "invokedBy": "organizations.amazonaws.com" }, "eventTime": "2026-06-22T03:24:11Z", "eventSource": "organizations.amazonaws.com", "eventName": "AccountJoinedOrganization", "awsRegion": "us-east-1", "sourceIPAddress": "organizations.amazonaws.com", "userAgent": "organizations.amazonaws.com", "requestParameters": null, "responseElements": null, "eventID": "cf969b62-0d98-4118-a256-asdfasdfasdf", "readOnly": false, "eventType": "AwsServiceEvent", "managementEvent": true, "recipientAccountId": "999999999999", "serviceEventDetails": { "accountId": "111111111111", "joinedTime": "Jun 22, 2026 3:24:11 AM", "joinedMethod": "INVITED" }, "eventCategory": "Management" }
INVITED の場合の JSON 出力は上記の通りでした。
AccountDepartedOrganization
メンバーアカウントが組織から離脱した際に、管理アカウントのイベント履歴に記録される新しいメンバーシップイベントです。これも同様に、「メンバーアカウントの減少時に、非常に監視運用が楽になる」と期待されました。
実際、既存のメンバーアカウントを別の AWS Organizations 組織へ移動させる場合には、ほぼリアルタイムにこのイベントが発報されます（自発的に脱退したアカウントの場合は「LEFT」、管理アカウントによって離脱させられたアカウントの場合は「REMOVED」）。
しかし、アカウントを閉鎖（CloseAccount）した場合の挙動には注意が必要なことが動作検証からも判明しています。CloseAccount を行った場合、先述の CloseAccountResult はほぼ即時に出力されますが、AccountDepartedOrganization はそのタイミングでは発報されません。
これは AWS の仕様によるものです。アカウント閉鎖リクエストが成功した後は90日間の猶予期間（先に記述した State が CLOSED の状態）が設けられており、この90日間の待機期間が経過してアカウントが完全に削除（permanent termination）された段階で、初めて Organizations が CloudTrail に AccountDepartedOrganization イベントを記録します。またその際、イベント内の「departedMethod」には CLEANED と記録されます。
After the permanent termination of the account after the 90-day waiting period, Organizations logs a membership event in CloudTrail. The event is an
AccountDepartedOrganizationevent withdepartedMethod:CleanedanddepartedTime. This event is available only in the management account's event history.---以下、日本語訳---
90日間の待機期間が経過し、アカウントが完全に削除された後、Organizations は CloudTrail にメンバーシップイベントを記録します。このイベントは、
departedMethod:CleanedとdepartedTimeを含むAccountDepartedOrganizationイベントです。このイベントは、管理アカウントのイベント履歴でのみ利用可能です。https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html
したがって、アカウント閉鎖にともなう組織からの離脱を即時検知して運用に繋げたい場合には、この AccountDepartedOrganization だけを監視していると、通知までに90日間のタイムラグが発生してしまいます。離脱の即時性を担保したいシステムにおいては、AccountDepartedOrganization 単体での監視に依存せず、引き続き CloseAccountResult も追加で監視対象に含める設計が必要となります。
AccountDepartedOrganization の実例1(LEFT)
組織間の移管作業の場合、CloudTrail のイベント履歴は以下の通りの順序となりました。
AcceptHandshake よりも、AccountDepartedOrganization のほうが早く記録されています。
また実際に組織からメンバーアカウントが離脱した時に AccountDepartedOrganization の JSON は以下の通りでした。
{ "eventVersion": "1.11", "userIdentity": { "accountId": "999999999999", "invokedBy": "organizations.amazonaws.com" }, "eventTime": "2026-06-22T03:09:17Z", "eventSource": "organizations.amazonaws.com", "eventName": "AccountDepartedOrganization", "awsRegion": "us-east-1", "sourceIPAddress": "organizations.amazonaws.com", "userAgent": "organizations.amazonaws.com", "requestParameters": null, "responseElements": null, "eventID": "eac53c72-5185-4f07-af90-asdfasdfasdf", "readOnly": false, "eventType": "AwsServiceEvent", "managementEvent": true, "recipientAccountId": "999999999999", "serviceEventDetails": { "accountId": "111111111111", "departureTime": "Jun 22, 2026 3:09:17 AM", "departureMethod": "LEFT" }, "eventCategory": "Management" }
ちなみに、作成されたばかりの AWS アカウントは、組織間の移動がすぐにはできず「4日間」の待機が必要です。
A newly created account has a waiting period before it can be removed from its organization. You must wait until at least four days after the account was created.
https://docs.aws.amazon.com/ja_jp/organizations/latest/APIReference/API_LeaveOrganization.html
もし上記検証を実施される場合には本仕様に留意してください。
では一体、何を監視したらいいか？の案
これまで見てきた全ての仕様を鑑みると、以下が現時点のベストプラクティスになると考えています。
| 監視の目的 | 監視すべきCloudTrailイベント |
|---|---|
| 組織へのアカウント追加（作成＆参加） | AccountJoinedOrganization |
| 組織からのアカウント削除（離脱＆閉鎖） | AccountDepartedOrganizationCloseAccountResult |
アカウントが増加する場合の監視設計
アカウントが組織に新しく加わるケースにおいては、新イベントである AccountJoinedOrganization のみを監視対象とするシンプルな設計で問題ありません。
新規作成（joinedMethod: CREATED）であっても、他組織からの移管（joinedMethod: INVITED）であっても、このイベントがほぼリアルタイムで一元的に発報されるためです。これまでの仕様のように、CreateAccountResult や AcceptHandshake を個別に拾い上げる必要がなくなるため、EventBridge のルール定義を簡素化できます。
アカウントが減少する場合の監視設計
一方で、アカウントが組織から離れるケースにおいては、新イベントの AccountDepartedOrganization と、従来からある CloseAccountResult（state が SUCCEEDED のもの）の2つを併用して監視する設計が求められます。
RemoveAccountFromOrganization による組織からのキックアウトや、メンバーアカウントが自ら行う LeaveOrganization による離脱は AccountDepartedOrganization で即時に検出することが可能になります。しかし、CloseAccount によるアカウント閉鎖については、90日間の猶予期間が明けるまで AccountDepartedOrganization が発報されないというタイムラグが存在します。
運用の現場において「アカウントが閉じられたこと」を即座に通知したいケースが状況的には多いと考えられることから、CloseAccountResult の成功イベントも並行してフックしておく必要があるでしょう。
なお、実際に AWS アカウントは90日経過後に完全に閉鎖され、AccountDepartedOrganization では「departedMethod」が CLEANED として記録されます。それまでの間は「CLOSED」のステータスとしてコンソール上に残り続けます。
そして、完全に閉鎖されるまでは、アカウントを復旧（再開）させることが可能であり、アカウントの復旧時には CloudTrail にメンバーシップイベントが記録されることはありません。これは AWS 側がペナルティとして強制停止させた状態となる（新しい意味での）「SUSPENDED」も同様です。
よって、完全なるアカウントの閉鎖である「departedMethod」が CLEANED として記録されることを本来は正しい処理タイミングとすべきです。つまり CloseAccountResult の監視は余計なノイズとなる可能性があります。
と言っても、基本的には CloseAccount によるアカウント閉鎖を行ったアカウントを復帰させることは稀なため、業務的には CloseAccountResult の監視もしておくことが現状は良いのではとして記述しております。ここは、ユースケースに応じて使い分けてください。
まとめ
本日は AWS Organizations の運用で役立つ、追加された新しい CloudTrail イベントである AccountJoinedOrganization と AccountDepartedOrganization の仕様と、それらを踏まえたアカウント監視設計をどうすべきかについて詳細に記述しました。
今回のアップデートと現状の仕様を整理すると以下の通りです。
- アカウントの参加は
AccountJoinedOrganizationの1つに集約可能です - アカウントの離脱は
AccountDepartedOrganizationとCloseAccountResultの2つを組み合わせると実運用に沿った監視が可能になると考えられます CloseAccountResultの監視は余計なノイズとなる可能性があるため、実運用に応じて通知の要否を決定してください- アカウントの状態管理は2026年9月9日の
Statusフィールド廃止に向けて、Stateフィールド（CLOSEDやSUSPENDED）を基準にしたロジックへの移行も必要に応じて行ってください - アカウントの状態を示す State には
PENDING ACTIVATION、ACTIVE、SUSPENDED、PENDING CLOSURE、CLOSEDの5つがあります - 新しい State の
SUSPENDEDは「AWS 側から未払いなどのペナルティとして強制停止された状態」を示すようになっています
新イベントの登場によってすべてが一元化されるわけではなく、アカウント閉鎖における90日間の猶予期間の仕様により、離脱側には依然として組み合わせの考慮が必要である点が今回の検証における重要な気付きでした。ドキュメントにその旨の説明はあったのですが、実際に動作確認してその仕様に気付いたため、やはり実際に動作確認を行うことの重要性に気付きました。
本ブログが、移行期間中の State フィールドへの対応も含め、マルチアカウント運用のアカウント増減の監視設計を見直す際の参考になれば幸いです。
SNS で通知する時に活用したい Input transformer について
SNS ＆ Slack 通知で活用したい Input transformer の使い方については本ブログには収まり切りませんでしたので、以下のブログを合わせて参考にしてください。
では、またお会いしましょう。
*1:AWS Organizations のホワイトペーパー「Organizing Your AWS Environment Using Multiple Accounts」には「Suspended OU」の作成が推奨されていますが、この名称も今後は「Closed OU」と変更すべきな気がします
*2:我々はこれを「移管」と呼んでいます
*3:この操作自体が「アカウント乗っ取り」の攻撃に使われる可能性もあるため
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
