LASSIC Media らしくメディア
AWS Organizations一括請求でコストを集約する外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- AWS Organizationsの一括請求（Consolidated Billing）は、複数アカウントの料金を管理アカウントが合算して支払う仕組みです。使用量がプールされるため、ボリューム割引・Reserved Instances・Savings Plansの割引を組織全体で共有できます。
- Reserved Instances（RI）とSavings Plans（SP）の割引共有は既定でONになっており、購入アカウントが使い切らなかった分が他のメンバーアカウントへ自動的に適用されます。共有は組織全体・OUグループ・アカウント単位で制御できます。
- 一括請求の設計と運用には、管理アカウントの権限設計・SCPの整合・共有ポリシーの計画が必要です。クラウドコスト最適化の経験がある外注パートナーへの委託と内製の判断軸も整理しています。
目次
- AWS Organizations一括請求とは——管理アカウントが合算して支払う仕組み
- 使用量プールで割引を共有——ボリューム・RI・SP が組織全体に適用される理由
- RI割引とSavings Plansの共有——既定ON・自動適用の仕組み
- 共有のON/OFF制御——組織・OUグループ・アカウント単位で設定できる
- コスト配分の可視化——タグとコスト配分レポートで内訳を把握する
- 外注でAWS Organizationsコスト最適化を進める場合——委託先の選定ポイント
- 内製と外注の比較——必要スキルとリスク管理の違い
- 注意点——権限設計・SCPの整合・共有範囲の計画
- まとめ——一括請求活用を判断する3つの軸
AWS Organizations一括請求とは——管理アカウントが合算して支払う仕組み
AWS Organizationsの一括請求（Consolidated Billing）とは、複数のAWSアカウントを「管理アカウント（Management Account）」が一元的に合算して請求・支払いを処理する機能です*1。各メンバーアカウントが個別に支払うのではなく、管理アカウントがすべてのメンバーアカウントの利用料金をまとめて受け取ります。
アカウントが1つだけであれば、請求は自然とシンプルです。しかし事業部門ごと・プロジェクトごとにAWSアカウントを分離していくと、それぞれのアカウントで個別に請求書が発行され、コストの把握と支払い管理が分散します。
一括請求を使うと、支払いの窓口を管理アカウントに一本化できます。請求書が1枚にまとまり、経理部門への報告やコストの集計が格段に整理されます。さらに後述するとおり、使用量が合算されることで割引適用の効果も高まります。
使用量プールで割引を共有——ボリューム・RI・SP が組織全体に適用される理由
一括請求の中心的なメリットは、全アカウントの使用量がプール（合算）されることです*1。AWSのサービスの多くは、一定量を超えると単価が下がるボリューム割引の仕組みを持っています。アカウントを分けたままではそれぞれの使用量が小さくなり、割引階層に到達しにくくなります。
一括請求では組織内の全アカウントの使用量が合計されるため、単体では割引階層に届かなかった小規模アカウントも、組織全体の使用量の恩恵を受けられます。たとえばデータ転送料・S3ストレージ・CloudWatchログなど、使用量に応じた段階料金が設定されているサービスでこの効果が現れます。
ボリューム割引に加えて、Reserved Instances（RI）とSavings Plans（SP）の割引も組織全体で共有されます。次のセクションでその仕組みを詳しく説明します。
RI割引とSavings Plansの共有——既定ON・自動適用の仕組み
Reserved Instances（RI）の割引は、一括請求を設定した組織内で既定でONになっています*1。あるメンバーアカウントでRIを購入した場合、そのアカウントが使い切らなかったRI割引は、他のメンバーアカウントの同種インスタンスに対して自動的に適用されます。
Savings Plans（SP）も同様の仕組みです*1。組織内のどのアカウントでSPを購入しても、既定では組織全体の使用量に対して適用されます。購入アカウントの使用量でSP割引を使い切れなかった分は、他のメンバーアカウントへ自動的に共有されます。
この仕組みにより、組織内で購入済みのRIやSPが無駄なく活用されます。一方で、共有の適用順序はまず購入アカウントへ優先適用され、余剰分が他アカウントへ流れるという順序です。
共有される前提——割引の自動適用の流れ
RIおよびSPの共有はAWS側で自動的に処理されます。購入アカウントが「今月はこのRIを使いきれなかった」という操作をしなくても、AWSが請求計算時に組織全体の使用量を参照し、割引を割り当てます。担当者がアカウントをまたぐ共有の操作を都度行う必要はありません。
共有されるのはRI・SPの割引率であり、リソース自体が他アカウントで動作するわけではありません。それぞれのアカウントは独立したリソース環境を維持したまま、請求計算の段階で割引が適用される仕組みです。
共有のON/OFF制御——組織・OUグループ・アカウント単位で設定できる
RI割引とSavings Plansの共有は、既定でONですが、組織の管理ポリシーに応じてON/OFFを切り替えられます*2。制御できる単位は大きく3種類あります。
- 組織全体：全メンバーアカウント間でRI/SP割引を共有する。既定の動作です。
- OUグループ（Organizational Unit）単位：特定のOU内のアカウント間でのみ共有を有効にし、他のOUとは共有しない設定も可能です。事業部門ごとにコストを独立させたい場合に利用されます。
- アカウント単位：特定のアカウントだけRI/SPの受け取りをOFFにすることもできます。そのアカウントのコストレポートをRI/SP割引の影響を受けない状態で管理したい場合などに使います。
共有をOFFにしたアカウントのRI/SPは、そのアカウント内の使用量にのみ適用されます。余剰分が発生しても他のアカウントへは流れません。
共有ON/OFFの設計判断——コスト配分の独立性とトレードオフ
共有をONにすると割引の活用効率は高まりますが、どのアカウントがどれだけRI/SP割引を享受したかの内訳が複雑になります。部門間のチャージバック（コストの内部振替）を実施している組織では、共有のON/OFFと合わせてコスト配分タグの設計を検討することになります。
共有をOFFにするとコスト配分の独立性は高まりますが、割引の余剰が発生しやすくなります。どちらが自社の運用方針に合うかを、コスト管理ポリシーと照らし合わせて判断することが実務上の重要なポイントです。
コスト配分の可視化——タグとコスト配分レポートで内訳を把握する
一括請求でコストが合算されても、アカウントごと・プロジェクトごとの内訳を把握したいという要求は残ります。AWSはこの目的に対して、コスト配分タグ（Cost Allocation Tags）とAWS Cost Explorerを提供しています。
コスト配分タグは、リソース（EC2インスタンス・S3バケットなど）にキーと値のペアを付与し、タグ単位でコストを集計する仕組みです。たとえば「Project: alpha」「Department: engineering」といったタグをリソースに付けておくと、Cost Explorerでタグ別のコストを抽出できます。
AWS Organizations内では、管理アカウントからメンバーアカウントのコストレポートを参照することも可能です。Cost Explorerのアカウントフィルターを使うと、特定のメンバーアカウントに絞ったコストの推移・サービス別内訳を確認できます。
コスト配分タグ運用の留意点
タグはリソース作成時から付与しないと、過去のコストを遡って集計することが難しくなります。アカウント数・リソース数が増えると、タグの付け忘れや表記ゆれが発生しやすくなります。
組織全体でタグの命名規則を統一し、新規リソース作成時にタグ付けを強制するSCP（Service Control Policy、組織内のアカウントへ適用するポリシー）を設計しておくと、長期的なコスト配分の精度を維持しやすくなります。
外注でAWS Organizationsコスト最適化を進める場合——委託先の選定ポイント
AWS Organizationsの一括請求設計とRI/SP共有の最適化は、AWS Billing・IAM（Identity and Access Management）・SCP（Service Control Policy）にまたがる設計が必要です。クラウドコスト最適化の実務経験がない場合は、設計の抜け漏れや共有ポリシーの誤設定が発生するリスクがあります。
外注を検討する場合、委託先の選定では以下の観点を確認することが実務上のポイントです。
- AWS Organizations・Billing構成の設計経験：管理アカウントとメンバーアカウントの役割分担設計、SCPの設定経験を持つかどうかを確認します。
- RI/SP購入計画の立案実績：使用量分析とRI/SPの割引設計を一体で進めた経験があるかを確認します。過剰購入になると割引メリットが薄れるため、分析精度が重要です。
- コスト配分タグ設計と継続運用の支援：タグ戦略の策定から、SCP連動によるタグ付け強制設計まで対応できるかを確認します。
- Cost Explorer・請求レポートの活用支援：設計後の継続モニタリングと、レポート活用のサポートが含まれるかを確認します。
元請（プライムベンダー）として受託できるパートナーを選ぶと、設計から運用まで一貫した体制で進められます。多層の再委託では設計意図が伝達されにくくなるため、直接担当する体制かどうかを確認することが判断の基準になります。
内製と外注の比較——必要スキルとリスク管理の違い
| 比較軸 | 内製 | 外注 |
|---|---|---|
| 必要なスキル | AWS Billing・IAM・SCP・Organizations APIの知識。 RI/SP使用量分析・Cost Explorerの操作経験が必要です。 |
設計・分析を委託先が担うため、社内は要件整理と最終承認の役割で進められます。 |
| 設計誤りのリスク | SCPの誤設定でメンバーアカウントの操作が制限されるリスクがあります。 RI過剰購入は割引効果を相殺する場合があります。 |
設計経験のある委託先が対応するため、設定誤りや過剰購入のリスクを低減できます。 |
| 対応スピード | AWS Billing体系の学習コストと分析工数が発生し、着手まで時間を要する場合があります。 | AWS Organizationsの実績がある委託先であれば、分析から設計まで早期に着手できます。 |
| 継続管理 | 社内にノウハウが蓄積され、更新時の自走対応が可能になります。 | 継続監視を委託する場合は委託先依存になります。 内製化計画をセットで設計することが望ましいです。 |
| 向いているケース | AWS Billing管理の経験があるエンジニアが在籍しており、継続的なコスト最適化を内製化したい場合。 | クラウド担当が兼務で分析工数を確保しにくい、またはOrganizations設計の経験が浅い場合。 |
内製で進める場合に必要なスキルと工数の目安
内製でAWS Organizationsの一括請求設計を進めるには、Billing Accountの構成理解・IAMロールの設計・SCPポリシーの作成・RI/SP使用量分析・Cost Explorerを使ったコスト配分レポートの運用スキルが必要です。
これらを未経験から進める場合、組織設計と使用量分析だけでも相応の調査工数が発生します。外注先にOrganizations設計を依頼する場合は、現在のアカウント一覧・サービス別月次コスト・RI/SP購入済み状況を事前に整理しておくと、委託先の提案精度が高まります。
注意点——権限設計・SCPの整合・共有範囲の計画
AWS Organizationsの一括請求はコスト削減に有効ですが、設計を誤ると意図しない動作を引き起こす場面もあります。導入前に押さえておくべき注意点を整理します。
管理アカウントへの権限集中に注意する
管理アカウントはOrganizations全体の設定を制御する中枢です。管理アカウントに不必要に多くのIAMユーザーやロールを付与すると、誤操作や権限の悪用が発生した場合の影響範囲が組織全体に及びます。
管理アカウントへのアクセスは最小権限の原則に基づき厳しく管理し、通常の業務操作はメンバーアカウントで行う設計にすることが実務上の基本です。
SCPの誤設定はメンバーアカウントの操作を制限する
SCP（Service Control Policy）は組織内のアカウントが使えるAWSサービスや操作を制限するポリシーです。たとえば「特定リージョン以外でのリソース作成を禁止する」ようなSCPを設定すると、意図せずメンバーアカウントのサービス利用が制限される場合があります。
SCPの変更は本番環境への影響が大きいため、テスト用のOUで動作確認してから本番のOUへ適用することが基本的な進め方です。SCPの設計と検証には、Organizations全体の構成を理解したうえでの慎重な対応が求められます。
RI/SP共有の範囲は事前に計画する
RI/SPの共有を組織全体でONにすると、あるアカウントが購入したRIが別の事業部アカウントの割引に流用されます。事業部ごとにコストを独立採算で管理している場合、この共有が内部の予算管理を複雑にします。
共有のON/OFF設定は後から変更できますが、変更のタイミングによっては月中のコストレポートに影響が出る場合があります。導入時に共有範囲の設計方針を決めておくと、後からの修正コストを抑えられます。
まとめ——一括請求活用を判断する3つの軸
本稿では、AWS Organizationsの一括請求（Consolidated Billing）の仕組み・使用量プールによるRI/SP割引の共有・共有ON/OFFの制御・コスト配分の可視化方法・外注時の選定ポイント・注意点を整理しました。要点を3つに集約すると次のとおりです。
第一に、一括請求の核心は「使用量プール」によるRI/SP割引の組織全体への波及です。アカウントを分けたままでは各アカウントの使用量が小さくなり、割引階層への到達や余剰RIの有効活用が難しくなります。一括請求を設定することで、組織全体の使用量を合算し割引効果を引き出せます。
第二に、RI/SPの共有は既定でONですが、組織の運用ポリシーに合わせてOU・アカウント単位で制御できます。事業部間のチャージバック管理が重要な組織では、共有の範囲とコスト配分タグの設計をセットで計画することで、割引効果と透明性を両立できます。
第三に、Organizations設計はSCP・IAM・Billing構成が絡み合うため、設計誤りの影響が大きくなります。AWS Organizations設計の実績がある外注パートナーへの委託は、設計ミスによる操作制限や過剰なRI購入のリスクを抑えながら進める有効な選択肢です。
よくある質問
AWS Organizations一括請求は無料で使えますか？
AWS Organizationsの機能自体（一括請求を含む）は追加料金なしで利用できます*1。料金が発生するのは各メンバーアカウントで使用したAWSサービスの利用料のみです。一括請求を設定すること自体でコストが増えることはありません。
既存の個別AWSアカウントを後からOrganizationsに参加させることはできますか？
はい、既存のAWSアカウントを後からOrganizationsのメンバーアカウントとして招待・追加することができます*1。追加したアカウントからは以降の利用料が管理アカウントに合算されます。ただし、既存のRI/SPの扱いや、アカウント追加後のSCP適用範囲については事前に確認が必要です。
RI/SP割引の共有をOFFにした場合、そのアカウントのコストはどうなりますか？
共有をOFFにしたアカウントのRI/SPは、そのアカウント内の使用量にのみ割引が適用されます*2。購入アカウントで使い切れなかった余剰分は他のアカウントへ流れません。また、他のアカウントが購入したRI/SP割引もそのアカウントには適用されなくなるため、共有をOFFにすると割引の活用効率は下がります。事業部ごとのコスト独立性と割引効率のトレードオフを考慮して判断することが大切です。
AWS OrganizationsとAWS Control Towerはどう違いますか？
AWS Organizations（オーガニゼーションズ）はアカウント管理・一括請求・SCPの適用を提供する基盤サービスです。AWS Control Tower（コントロールタワー）はOrganizationsの上に構築されたサービスで、セキュリティ・コンプライアンスのガードレール設定やランディングゾーン（推奨アカウント構成）の自動セットアップを提供します。一括請求だけが目的であればOrganizationsで対応でき、マルチアカウントのガバナンス全体を整備したい場合はControl Towerが参考になります。
AWS Organizationsのコスト最適化を外注する場合、何を準備してから相談すればよいですか？
現在のAWSアカウント一覧・サービス別月次コストの概算・RI/SPの購入済み状況・組織の事業部構成の概要を準備しておくと、委託先の分析と提案精度が高まります。Cost Explorerの過去3〜6ヶ月分のコストレポートをエクスポートしておくと、使用量分析の出発点として活用できます。共有ON/OFFの方針や事業部間のチャージバックの有無も事前に整理しておくと相談がスムーズです。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「Consolidating billing for AWS Organizations」（AWS公式ドキュメント）
- *2 出典：AWS「Turning off Reserved Instance and Savings Plans discount sharing」（AWS公式ドキュメント）
