AWS Organizations一括請求（Consolidated Billing）設計入門｜RI・Savings Plans共有とボリューム割引をマルチアカウントで活かす実践ガイド



マルチアカウント構成に移行したはいいが、「リザーブドインスタンス（RI）の割引がどのアカウントに適用されているかわからない」「Savings Plansを購入したのに別アカウントのコストが下がっていた」という経験はないだろうか。

AWS Organizationsで複数のAWSアカウントをまとめると、裏側では一括請求（Consolidated Billing）の仕組みが自動的に動き出す。RI・Savings Plansの割引共有、S3のボリューム割引の集計、クレジット（Promotional Credits）の配布……これらのルールを設計段階で理解しておかないと、想定外のコスト配賦やRI購入ミスにつながる。

この記事では、AWS Organizations一括請求の仕組みをオンプレ経験者向けに整理しながら、RI・Savings Plansの共有設計、ボリューム割引の活かし方、コスト可視化のセット運用まで実践的に解説する。

なぜ一括請求（Consolidated Billing）なのか？オンプレとの違い

オンプレミス環境では、部門ごとにサーバーを物理的に分けることでコストを分離してきた。クラウドに移行してマルチアカウント化すると、各アカウントが独立した「請求エンティティ」のように見えるが、実際にはAWS Organizationsの管理アカウント（旧称: マスターアカウント）が全メンバーアカウントの利用料をまとめて請求される。

この「ビリングファミリー」全体をひとつの消費単位として扱うのが一括請求の本質だ。単純に請求書が1枚になるだけでなく、次の3点がコスト最適化の観点で重要になる。

・RI・Savings Plansの割引共有: あるアカウントで購入した割引を、同じビリングファミリー内の他アカウントの利用に自動適用できる
・ボリューム割引の集計: S3・CloudFront・データ転送などのティアー型料金で、全アカウントの使用量を合算してより低い単価を得られる
・Promotional Creditsの一元管理: AWSから付与されたクレジットを管理アカウント経由でファミリー全体に適用できる

一括請求の構造 — ビリングファミリーとアカウントの役割

1. 管理アカウント（Payer Account）の役割

AWS Organizationsの管理アカウント（Management Account）は自動的にPayer Accountになる。ビリングファミリー全体の請求を受け取り、支払いの責任を持つ。このアカウントはワークロードを乗せないことがベストプラクティスとされており、FinOpsと組織ガバナンスの「司令塔」として機能させる。

メンバーアカウントはそれぞれ独自のAWSリソースを持つが、請求はすべて管理アカウントへ集約される。Cost Explorerや請求コンソールを管理アカウントから参照すると、アカウント別・サービス別のコスト内訳を一覧できる。

2. メンバーアカウントの費用帰属

各メンバーアカウントには「自分のアカウントのコストを見る権限」を与えることができる（IAM経由でBilling Consoleへのアクセスを許可）。ただし、RI・Savings Plansの共有状況などビリングファミリー全体の情報は管理アカウントからしか確認できないため、コスト管理の責任者を管理アカウント側に置く体制を作ることが多い。

RI・Savings Plansの共有設計

1. RIの適用優先順位

ビリングファミリー内でRIはデフォルトで共有される。適用の優先順位は次のとおりだ。

・第1優先: RIを購入したアカウント自身の対象インスタンスに適用
・第2優先: 同ビリングファミリー内の他メンバーアカウントの対象インスタンスに適用

購入アカウントの利用が少なくRIが余っている場合、自動的に他アカウントの利用に割引が適用される。これは便利な反面、「誰のコスト削減になったのか」が不透明になる原因にもなる。

# 【AWS CLI】RI共有の現在の設定を確認する（管理アカウントから実行）
aws organizations describe-organization \
  --query 'Organization.{MasterAccountId:MasterAccountId,FeatureSet:FeatureSet}'

# RI購入状況の一覧（共有先アカウントへの適用を確認）
aws ec2 describe-reserved-instances \
  --filter Name=state,Values=active \
  --query 'ReservedInstances[].{ID:ReservedInstancesId,Type:InstanceType,Count:InstanceCount}'

2. Savings Plansの共有ルール

Savings Plansもデフォルトでビリングファミリー全体に共有される。ただし、RIと異なるのはSavings Plans購入アカウントの利用が満たされた後にのみ、余剰分が他アカウントへ適用される点だ。

・Compute Savings Plans: EC2・Lambda・Fargateをまたいで共有適用。柔軟性が高い分、どのアカウントにいくら適用されたか追跡が複雑になる
・EC2 Instance Savings Plans: 特定のインスタンスファミリー・リージョン固定で適用。共有はされるが適用範囲が限定的
・SageMaker Savings Plans: SageMakerの学習・推論コストに特化。ビリングファミリー内での共有は可能だが、SageMakerを使うアカウントが限られるため影響範囲は狭い

3. 共有を止めたいときの設定

RI・Savings Plansの共有は、特定アカウントでのコスト責任を明確にしたい場合に邪魔になることがある。管理アカウントのAWS Organizationsコンソールから、メンバーアカウント単位でRI/SP共有の無効化が設定できる。

・無効化すると: そのアカウントで購入したRI・SPの余剰を他アカウントに渡さない。また他アカウントのRI・SP余剰もそのアカウントへ流れてこない
・使いどころ: 独立採算が求められる事業部アカウント、顧客向けのマルチテナントアカウント、コスト責任の境界を明確にしたいケース

# 【AWS CLI】Savings Plans共有の設定を確認する（管理アカウントから実行）
# RI/SP共有設定はAWS Billing and Cost Management コンソールから変更
# コンソール操作: AWS Cost Management → Savings Plans → 設定 → RI共有設定
# または Organizations コンソール → ポリシー → 予約インスタンス共有

# メンバーアカウント一覧の確認
aws organizations list-accounts \
  --query 'Accounts[].{Id:Id,Name:Name,Status:Status}'

ボリューム割引をビリングファミリー全体で活かす

1. S3のストレージ料金ティアー

Amazon S3のストレージ料金は使用量に応じたティアー型で、使えば使うほど単価が下がる（2026年10月時点・東京リージョン・標準ストレージクラスの目安）。

このティアーはビリングファミリー全体の合算使用量で計算される。（想定例）アカウントAが40TB、アカウントBが30TBを使っていれば合計70TBとして第2ティアー以降の単価が適用され、各アカウントへ比例配分される。単独アカウントでは下のティアーに届かない場合でも、まとめることで全アカウントが恩恵を受けられる。

2. データ転送コストの集約

AWS外へのデータ転送（インターネット向け）も使用量累積でティアー割引が適用される。アカウントを分けていてもビリングファミリー全体で集計されるため、転送量の多い本番アカウントが他アカウントの転送単価引き下げに貢献する構造になっている。

Promotional Credits（クレジット）の配布ルール

AWSから付与されるプロモーションクレジット（スタートアップ向けActivate、パートナー経由のクレジットなど）は、基本的に付与されたアカウントで消費される。管理アカウントに付与されたクレジットはビリングファミリー全体のコストに充当されるが、メンバーアカウントに付与されたクレジットはそのアカウント内でのみ使われる点に注意が必要だ。

一般的なつまずきとして、クレジットの残高確認を管理アカウントからのみ行い、メンバーアカウント個別のクレジット消費を見落とすケースがある。Cost and Usage Report（CUR）を分析すると、クレジット適用の詳細が確認できる。

コスト分離と可視化の設計

1. Cost Categoriesによるアカウント別分類

一括請求の請求書は1枚にまとまるが、コスト配賦の粒度は自分で設計する必要がある。AWS Cost Categoriesを使うと、「アカウントIDが○○～○○の範囲は事業部A」「特定タグが付いたリソースはプロジェクトB」といったルールを定義して、コストをビジネス軸で分類できる。

・アカウントベースのルール: アカウントIDや組織単位（OU）に紐づけて事業部・環境（本番/ステージング/開発）を分類
・タグベースのルール: リソースタグ（Project: X、CostCenter: 1234など）でリソース単位の帰属を定義
・未分類（Uncategorized）: ルールに合致しないコストはUncategorizedに落ちる。これが膨らんでいる場合はタグ付けルールを見直すサイン

2. コスト配分タグとのセット運用

アカウントを分けただけではサービス内部のリソース（EC2インスタンス1台ごと、Lambda関数1本ごと）のコスト帰属はわからない。コスト配分タグを有効化し、タグ付けポリシーをAWS Organizationsで強制することで、アカウント横断のコスト可視化が完成する。

タグ付けポリシーはAWS Organizationsの機能で、OU単位・アカウント単位でタグキーの大文字小文字ルールや必須タグを強制できる。AWS Cost Categoriesとコスト配分タグの組み合わせがマルチアカウントFinOpsの土台になる。

よくあるつまずきと対処法

・RI購入アカウントの選択ミス: RI余剰がビリングファミリー内で共有されるとはいえ、購入アカウント自身の利用が少ないと他アカウントへの「タダ乗り」が発生しコスト帰属が乱れる。RIとSavings Plansの購入先アカウントは、そのリソースを実際に使うアカウントに揃えるのが原則だ
・RI/SP共有を知らずに無効化: コスト配賦の透明性を高めようとRI共有を全アカウントで無効化すると、既存の割引が突然効かなくなり請求額が跳ね上がる。変更前に現状のカバレッジをCost Explorerで確認すること
・ボリューム割引の過信: S3のティアー割引は魅力的だが、不要なデータを蓄積してまで割引ティアーを狙うのは本末転倒。S3ライフサイクルルールでデータを適切に階層化したうえで、自然に発生する量を集約する
・クレジット残高の見落とし: プロモーションクレジットは有効期限があり、期限切れで消滅する。CURのCredit行を定期的にモニタリングする習慣をつけると良い
・管理アカウントにワークロードを乗せる: 管理アカウントにEC2やRDSを置くと、ガバナンスとワークロードコストが混在し、SCPの設計も複雑になる。管理アカウントはFinOpsと組織管理専用に保つ

本記事のまとめ

一括請求は「請求書が1枚になる」だけの機能ではなく、マルチアカウント環境でのコスト最適化とFinOps設計の土台になる仕組みだ。RI・Savings Plansの共有設計を正しく理解することで、購入したリソースの割引がどこにどう流れるかを掌握でき、コスト配賦の公平性と透明性を両立できる。

AWS Organizationsのガバナンス設計と一括請求の理解を組み合わせ、FinOps実践の導入で、可視化から削減まで一貫した仕組みを作り上げていこう。