AWS Organizationsを使ったまま請求代行を検討する時の技術チェックリスト
はじめに
請求代行の検討で「AWS Organizations（一括請求）を使っています」と伝えると、営業担当から「対象外ですね」の一言で終わってしまうケースをよく聞きます。
以前書いた記事（AWS請求代行サービスを技術者目線で検討した時にハマった技術的ポイントまとめ）でもOrganizations周りには軽く触れましたが、今回はそこだけを掘り下げます。「Organizationsを使っている」は実はかなり曖昧な表現で、何が本当にブロッカーなのかを技術的に切り分けると、選べる選択肢はもう少し増えます。
この記事は「Organizationsだから絶対無理」と思っている方向けの、確認すべき技術ポイントのチェックリストです。
TL;DR
- Organizationsのうち請求代行と本当に競合するのは一括請求（Consolidated Billing）機能そのもの。SCP・RAM・タグポリシーは別問題であることが多い
- 「Organizationsを使っている」ではなく「何のために使っているか」を棚卸しするのが最初の一歩
- 選択肢は主に3つ：①解除する ②組織管理対応プランを選ぶ ③対象アカウントだけ切り出す
- RI/Savings Plansをアカウント間で共有している場合、③の切り出しで共有プールから外れる影響を必ず試算する
- どの選択肢も一長一短で、「みんなこうしている」という正解はない
1. そもそも何が競合しているのか
Organizationsは請求以外にも複数の機能を束ねています。
| 機能 | 請求代行との関係 |
|---|---|
| 一括請求（Consolidated Billing） | 直接競合する。支払い先（Payer）を変更する必要があるため |
| Service Control Policy（SCP） | 請求とは独立。Payerが変わっても維持できることが多い |
| リソース共有（RAM） | 請求とは独立 |
| タグポリシー・バックアップポリシー | 請求とは独立 |
請求代行事業者が「Organizations使用中は対象外」と言う時、正確には「一括請求機能を使っている限り対象外」という意味であることがほとんどです。SCPでガードレールを敷いているだけなら、実は選択肢はもう少しあります。
まず自社のOrganizationsが実際に何のために使われているかを確認してください。
# Organizationの基本情報を確認
aws organizations describe-organization
# 有効化されている機能セットを確認(ALL or CONSOLIDATED_BILLING)
# ALLの場合はSCP等も有効。CONSOLIDATED_BILLINGのみなら一括請求専用
aws organizations describe-organization --query 'Organization.FeatureSet'
# SCPが実際にアタッチされているか確認
aws organizations list-policies --filter SERVICE_CONTROL_POLICY
# 全アカウントの一覧と状態を確認
aws organizations list-accounts
FeatureSet が CONSOLIDATED_BILLING のみで、SCPやRAMを積極的に使っていないなら、Organizationsは実質「請求をまとめるためだけ」に存在している可能性があります。その場合、後述の選択肢①・③のハードルはぐっと下がります。
2. 選択肢を技術的に比較する
選択肢A：Organizationsを解除する
もっともシンプルですが、影響範囲も一番広い選択肢です。
member アカウントは、支払い方法・連絡先情報などの要件を満たしていれば、AWS標準のセルフサービス機能で組織から離脱できます。要件を満たさない場合はサポートケースでの対応が必要になるため、まず対象アカウントが離脱要件を満たしているかを確認してください。
確認すべき副作用：
- SCP・タグポリシー等、Organizations機能に依存しているガードレールが外れる
- アカウント間のRI/Savings Plans共有プールから外れる
- 一括請求で受けていたボリュームディスカウント（該当する場合）を失う
「請求のためだけにOrganizationsを使っていた」チームでない限り、この選択肢は運用への影響を過小評価しがちです。
選択肢B：組織管理に対応したプランを選ぶ
Organizations環境のまま請求代行を使う専用プランを持つ事業者を選ぶ方法です。国内だとクラスメソッドの組織管理プランなどが該当します。ただし、公開情報を見る限り一律割引プランより条件が変わる（割引率が下がる、対象範囲が変わる等）ケースが多いため、通常プランの割引率だけを見て比較しないよう注意してください。
弊社（CloudCost）はこの記事の執筆時点では組織管理プランを持っておらず、Organizations使用中の環境は適用に制限があります。この記事はあくまで技術的な選択肢の整理であり、自社サービスへの誘導を意図したものではありません。
選択肢C：Organizations非使用のアカウントのみを切り出す
全アカウントを一括で移行するのではなく、「discountの恩恵が大きいアカウントだけ」を個別に組織から切り出して請求代行に出す方法です。本番環境の使用量が集中している1〜2アカウントだけ動かす、といった運用が現実的にはよくあります。
この方法の技術的な論点は「切り出すアカウントがRI/Savings Plansの共有プールにどれだけ依存しているか」です。
# アカウントごとのRI利用状況を確認する例（Cost Explorer API）
aws ce get-reservation-utilization \
--time-period Start=2026-06-01,End=2026-07-01 \
--granularity MONTHLY
切り出し候補のアカウントが、他アカウントが購入したRI/SPの恩恵を大きく受けている場合、切り出した瞬間にその恩恵を失い、請求代行の割引で得る金額を相殺してしまうことがあります。ここを試算せずに切り出すと「思ったより下がらなかった」という結果になりがちです。
3. 意思決定の簡易フロー
Organizationsの用途は？
├─ 請求をまとめる目的がメイン（SCP等は未使用）
│ └─ 選択肢A（解除）または選択肢C（一部切り出し）を検討
│
├─ SCP・RAM等のガバナンス機能を積極活用している
│ └─ 選択肢B（組織管理対応プラン）を優先的に検討
│ （なければ選択肢Cで一部アカウントのみ切り出し）
│
└─ RI/Savings Plansをアカウント間で大きく共有している
└─ 切り出す前に必ず共有プールへの影響を試算
まとめ：技術評価チェックリスト
-
describe-organizationでFeatureSetを確認した（ALL か CONSOLIDATED_BILLING か） - SCP・RAM・タグポリシーの利用有無を確認した
- 対象アカウントがセルフサービス離脱の要件を満たすか確認した
- RI/Savings Plansの共有状況とアカウントごとの依存度を試算した
- 組織管理対応プランを持つ事業者の条件（割引率・対象範囲）を比較した
- 「全アカウント一括移行」ではなく「一部アカウントの切り出し」の可能性を検討した
おわりに
「Organizationsだから請求代行は無理」で終わらせず、何が本当にブロッカーなのかを切り分けると選択肢は増えます。とはいえ、どの選択肢もトレードオフがあり、正解は組織構成とガバナンス要件次第です。
質問やフィードバックがあればコメントでお気軽にどうぞ。
📝 立場の開示：筆者はクラウドコスト合同会社（CloudCost）でAWS・Google Cloudの請求代行サービスを担当しています。本記事では自社サービスの現状の制約（Organizations対応プランを持たないこと）も含めて触れていますが、公平な立場とは言えない点はご留意ください。他社サービスの記述は公開情報に基づく事実ベースで書いており、特定事業者の検討を否定する意図はありません。