AWS OrganizationsのStatusが9月9日廃止、Stateへ置換する手順

AWS OrganizationsのStatusは2026年9月9日に廃止されました。AWSの機能発表 で示された対象はDescribeAccount、ListAccounts、ListAccountsForParentであり、これらのAccountオブジェクトを読む処理はStateへ切り替える必要があります。

移行はフィールド名の置換だけでは終わりません。2026年9月9日の廃止に対応するには、Statusへの依存を洗い出し、CLI・SDKを更新したうえで、Stateの5値と欠損・未知値を扱う分岐を設計し、3つのAPIを回帰テストします。

1. Statusへの依存を処理単位で洗い出す

最初に、リポジトリ内の「Status」「.Status」「["Status"]」「['Status']」を大文字小文字を区別して検索します。APIレスポンスを直接読むコードだけでなく、JSONPathやJMESPathの式、型定義、保存スキーマ、監視ルール、テスト用fixtureも対象です。

文字列検索では見つからない依存もあります。Organizationsクライアントを生成する箇所から呼び出し先を追い、Accountオブジェクトのデシリアライズ、共通ラッパー、レスポンス変換を確認してください。

見落としやすいのは、アカウント払い出し後にACTIVEを待つジョブ、SUSPENDEDを除外する棚卸し、CSVやJSONを渡す下流連携です。内部判定を変更しても、出力契約にStatus列が残れば移行は完了しません。呼び出し元、判定内容、出力先、変更担当、テストの有無を一覧にすると、同時に更新すべき依存関係を切り分けられます。

• DescribeAccountによる単一アカウントの確認
• ListAccountsによる組織全体の棚卸し
• ListAccountsForParentによるルートまたはOU直下の取得
• レスポンスを加工するバッチ、監視、アカウント払い出し処理
• Statusを列名や必須項目として受け取る下流システム

2. AWS CLIとSDKを更新する

コードを変更する前に、実行環境がStateを取得できる世代か確認します。AWS Organizationsユーザーガイド が示す条件は、AWS CLI 2.29.0以降、または2025年9月9日より後にリリースされたSDKです。同じページは対象となる3つのAPIと、後述する5つのState値も定義しています。

「aws --version」で実際に呼び出されるCLIを確認し、開発端末だけでなく、CIイメージ、コンテナ、Lambda Layer、定期実行ホストの固定バージョンも調べます。更新後は権限のある検証環境で「aws organizations describe-account --account-id 123456789012」を実行し、Account内にStateが含まれることを確認してください。

SDKはパッケージの公開日だけで判断せず、ロックファイルとデプロイ済み成果物の実バージョンを確認します。Account型またはレスポンス辞書にStateがなく、更新後も取得できない場合は、Statusへのフォールバックを増やすのではなく、古い依存物や別の実行バイナリが残っていないかを調べます。

公式ドキュメントにはStatusとStateが「現在」併存するという移行期の記述が残っていますが、同じページが指定する廃止日は2026年9月9日です。実装では日付を過ぎてもStatusが返ることを互換性の根拠にせず、Stateを必須のレスポンス契約として扱います。

3. Stateの5値に合わせて分岐を作り直す

StateはPENDING_ACTIVATION、ACTIVE、SUSPENDED、PENDING_CLOSURE、CLOSEDの5値です。従来のACTIVEやSUSPENDEDだけを前提にした二分岐へ新しい値を流すと、利用不能なアカウントを利用可能と誤判定するおそれがあります。

• PENDING_ACTIVATION：サインアップが完了しておらず、アカウントは利用できない。
• ACTIVE：アカウントは稼働状態で、権限と組織ポリシーの範囲内でAWSサービスを利用できる。
• SUSPENDED：AWSがアクセスを制限しており、アカウントは利用できない。
• PENDING_CLOSURE：閉鎖リクエストの処理中で、完了まではアカウントを利用できる。
• CLOSED：AWSサービスへアクセスできない。閉鎖開始から90日間はコンソールに表示され、その期間はサポートへ復元を相談できる。

アカウント払い出し処理では、ACTIVEだけを「利用準備完了」とするのが明確です。PENDING_ACTIVATIONは待機または要対応、SUSPENDEDは自動変更の停止、PENDING_CLOSUREとCLOSEDは新規リソース配置や権限付与の対象外、といった業務分岐を定義します。通知先や再試行間隔はAWSの状態定義ではなく、自社の運用要件として決めてください。

未知のStateや値の欠損をACTIVEへ丸めてはいけません。安全側に失敗させ、アカウントID、呼び出したAPI、受信値をログやメトリクスへ残します。列挙値を下流へ転送する場合は、受信側が未知値を保留または拒否できることも確認します。

4. 読み取りコードと下流契約を置き換える

Pythonの辞書なら「account.get("State")」、JavaScriptなら「account.State」のように参照先を変更します。値がない場合にStatusへ戻る恒久的なフォールバックは設けず、「古い実行環境または想定外のレスポンス」として明示的に失敗させます。

AWS CLIでは、例えば「aws organizations list-accounts --query 'Accounts[].{Id:Id,State:State}'」のように射影を更新します。ListAccountsForParentのJMESPath式も同様に変更し、シェルスクリプトが列位置に依存している場合はフィールド名による取得へ切り替えます。

下流との移行時期を分ける必要があるなら、AWSから取得したStateを内部のaccount_stateへ保存し、旧status列の削除を別の契約変更として管理します。ただし、CLOSEDをSUSPENDEDへ変換すると「閉鎖済み」と「AWSによる停止」の違いが失われます。旧形式への変換が避けられない期間は、対応表と失われる情報を明記し、受信側のState対応後に旧列を撤去します。

5. 3つのAPIと例外入力を回帰テストする

回帰テストは、Stateを読めること、状態別の分岐が正しいこと、一覧取得でアカウントを取りこぼさないことに分けます。実環境で5状態をそろえる必要はありません。単体テストではAccountレスポンスのfixtureを各状態について作り、結合テストでは権限のある非本番環境から実際のStateを取得します。

1. PENDING_ACTIVATIONで利用可能通知や後続の払い出し処理が実行されないこと。
2. ACTIVEだけが通常の後続処理へ進むこと。
3. SUSPENDEDで自動変更を止め、定義した通知またはエラーを生成すること。
4. PENDING_CLOSUREをACTIVEと同一視せず、閉鎖処理中として扱うこと。
5. CLOSEDをアクセス可能と判定せず、終了済みの経路へ進めること。
6. Stateの欠損と未知値で安全側に失敗し、監視から検知できること。

ListAccountsとListAccountsForParentではページネーションも試験します。ListAccounts APIの仕様 では、結果が空でもNextTokenが返る場合があるため、NextTokenがnullになるまで取得を続けるよう定めています。最初の空配列だけを見て終了する実装では、後続ページのアカウントを取りこぼします。

結合テストでは、同じアカウントIDをListAccounts、適切な親を指定したListAccountsForParent、DescribeAccountで取得し、Stateと業務上の判定が一致することを確認します。デプロイ後にStatus参照を再検索し、State欠損、未知値、状態別の処理件数を監視できれば、名称変更ではなくレスポンス契約と業務分岐まで含めた移行が完了します。