LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AWS Organizationsの一括請求とは — 複数アカウントの請求を集約する

AWS Organizationsの一括請求（Consolidated Billing）とは、複数のAWSアカウントの支払いを1つにまとめる機能です。Organizationには1つの管理アカウント（management account）があり、Organization内のすべてのメンバーアカウント（member account）の請求額を管理アカウントが支払う構成になります^*1。

一括請求の利点は、AWS公式のドキュメントで次のように整理されています。第一に、複数アカウント分の請求が1通にまとまり、まとめて追跡できる点。第二に、コストと使用量データを結合してダウンロードできる点。第三に、Organization内の使用量を合算することで、ボリューム料金の割引・リザーブドインスタンス（RI）の割引・Savings Plansの割引を複数アカウントで共有できる点です^*1。これにより、個々のアカウントを単独で運用するより低い総額になる場合があるとされています^*1。一括請求機能そのものに追加料金は発生しません^*1。

注意したいのは、メンバーアカウントの請求書はあくまで参考情報という位置づけである点です。実際にどのボリューム割引・RI割引・Savings Plans割引がどのメンバーアカウントに再配分されるかは、管理アカウント側の設定によって変わります^*1。つまり「請求が1本化される」ことと「割引が最適に配分される」ことは、自動的にイコールではなく、管理アカウント側での確認・設定が必要という理解が出発点になります。

なお、AWS Organizations自体は一括請求だけの機能ではなく、アカウントの一元管理・組織単位（OU）へのグルーピング・サービスコントロールポリシー（SCP）によるガバナンス適用など、複数アカウント環境を管理するための総合的な機能群です^*2。本稿では、その中でも法人がコスト最適化の観点で押さえておきたい「請求の集約」と「割引の仕組み」に絞って解説します。コスト配分タグの設計やSCPによるガバナンス強化は、目的が異なる別の論点として扱います。

使用量合算によるボリュームディスカウント

一括請求の中核にあるのが、使用量合算によるボリュームディスカウントの仕組みです。AWSの一部サービス（データ転送やAmazon S3など）には、使用量が一定のしきい値を超えると単価が下がるボリューム料金ティアが設定されています^*3。一括請求を使うと、AWSはOrganization内のすべてのアカウントを1つのアカウントであるかのように扱い、全アカウント分の使用量を合算したうえでどの料金ティアが適用されるかを判定します^*3。

AWS公式ドキュメントに掲載されている考え方を用いると、次のように説明されます。管理アカウントの利用者がデータ転送量8TB、メンバーアカウントの利用者が4TBを使用した場合、単独のアカウントであればそれぞれ低い方の料金ティアの単価で計算されますが、一括請求で合算すると合計12TBとして扱われ、上位のティアに到達した分だけ単価が下がる区間が生じます^*3。合算後に生じた割引分は、各アカウントの使用量に応じてAWSが配分する仕組みです^*3。単独アカウントのままだった場合と比較して、合算した場合の方が総額が下がるケースがあるとAWSは説明しています^*3。

この合算は、EC2などの無料利用枠（Free Tier）にも及びます。Organization全体の合計使用量に対して無料利用枠が適用され、アカウントごとに個別に無料枠が付与されるわけではありません^*3。無料枠の超過を把握するための予算アラートは既定で有効になっていないため、管理アカウント側で明示的に有効化しておく必要があります^*3。

法人がコスト最適化の文脈でこの仕組みを活用するうえで重要なのは、複数の子会社・事業部・環境（本番/検証/開発など）でアカウントを分けている企業ほど、合算のメリットを得やすいという点です。逆に言えば、アカウントごとの使用量が小さくティアの境界に届かない状態が続く場合、一括請求を導入していても合算効果を実感しにくいというのが実態でしょう。自社のアカウント群がどのサービスをどの程度使っているかを事前に棚卸ししたうえで、合算によってティアに到達する見込みがあるかを確認しておくことが、導入効果を見積もる第一歩になります。

また、料金ティアの具体的な単価やしきい値はサービスごと・時期ごとに変わり得るため、本稿では数値を固定的には示しません。実際の単価は、AWS公式の料金ページで都度確認する運用が前提になります。

Savings Plans・リザーブドインスタンスのアカウント間共有

ボリュームディスカウントとは別に、コミットメント型の割引であるリザーブドインスタンス（RI）とSavings Plansも、一括請求のもとでアカウント間の共有対象になります。

RIは請求上「1つのアカウント」として扱われる

AWS公式ドキュメントでは、請求の観点においてOrganization内のすべてのアカウントを1つのアカウントとして扱うため、あるアカウントが購入したRIによる時間単価の割引を、Organization内の他のアカウントも受け取れると説明されています^*4。この共有は既定で有効になっており、管理アカウントの「Billing preferences（請求設定）」画面から無効化することも可能です^*4。

Savings Plansは共有モードを選べる

Savings PlansもRIと同様にOrganization内で共有できますが、共有の粒度をより細かく制御できる点が特徴です。管理アカウントは、Organization内のどのアカウントに対してRI・Savings Plansの割引共有を有効化・無効化するかを、アカウント単位で設定できます^*5。加えて、Organization全体で共有する方式のほか、AWS Cost Categoriesを使ってアカウントをグループ化し、特定グループ内で優先的に共有する方式、グループ外には共有しない方式など、複数の共有モードが用意されています^*5。共有を受けるには、購入元アカウント・受益アカウントの双方で共有設定が有効になっている必要があり、割引はまず購入したアカウント自身の使用量に適用されたうえで、余剰分が他アカウントに回る順序で処理されます^*5。

Savings Plansの割引はOrganizationをまたいでは共有できない点にも注意が必要です。請求代行（Billing transfer）を利用している場合でも、Savings PlansやRIは購入時点で所属していたOrganization内でのみ有効という制約があります^*4*5。M&Aや組織再編でOrganizationの構成が変わる場合は、この制約が既存の割引に影響し得る点を事前に確認しておく必要があります。

コスト最適化の観点では、この共有設定を「入れているつもりで入っていない」状態が起こり得る点が実務上の落とし穴です。例えば新しくOrganizationに参加したメンバーアカウントは、共有設定が意図した状態になっているかを都度確認しないと、既存のRI・Savings Plansの恩恵を受けられないままオンデマンド料金で稼働し続けるケースが考えられます。定期的に請求設定画面を確認する運用ルールを、アカウント追加のたびに組み込んでおくことが望ましいでしょう。

コストの可視化とアカウント別の配分把握

請求が一括化され、割引がアカウント間で共有されると、次に必要になるのが「結果としてどのアカウント・どの部門がいくら使っているか」を可視化する工程です。ここで使われる代表的なツールがAWS Cost Explorerです。

Cost Explorerは、コストと使用量のデータを可視化・分析するためのツールで、グラフ表示に加えてコスト・使用状況レポート、RIレポートなどを通じて内容を掘り下げられます^*6。過去13カ月分のデータを表示でき、今後18カ月分のコスト予測やRI購入の推奨も確認できます^*6。管理アカウントからは、Organization内の全アカウントを横断した集計と、メンバーアカウントごとの個別レポートの両方にアクセスできます^*1。

ここで意識しておきたいのは、一括請求そのものは「支払いの一本化」と「割引の合算」を実現する機能であり、部門別・プロジェクト別にコストを配分して管理会計に落とし込む機能とは役割が別だという点です。アカウント単位の粒度で部門を分けている場合はCost Explorerのアカウント別グループ化だけでも配分の把握が可能ですが、1つのアカウント内で複数プロジェクトが混在している場合は、コスト配分タグなど別の仕組みを組み合わせる必要があります。この配分タグの設計・運用は本稿の主題である請求集約の仕組みそのものとは別軸の論点であるため、ここでは深く扱いません。

もう1点実務上重要なのは、メンバーアカウントがOrganizationから離脱した場合の挙動です。離脱すると、そのアカウントはOrganization在籍中に生成されたCost Explorerのデータへアクセスできなくなります。データ自体が削除されるわけではなく、管理アカウント側からは引き続き参照可能で、離脱したアカウントが再度Organizationに参加すれば、そのアカウントからも再びアクセスできるようになります^*1。組織再編でアカウントの出入りがある企業では、この挙動を踏まえて過去データの保全方針を決めておく必要があります。

導入時の設計の勘所（管理アカウントの分離・請求と権限の切り分け）

一括請求を機能させるうえでの設計上の要点は、「請求を集約すること」と「権限を集約すること」を意図的に切り分けて考える点にあります。

管理アカウントは請求専用の入れ物にしない判断もある

管理アカウントは請求の責任を負う特別な立場ですが、同時にOrganizationの各種設定を変更できる強い権限を持つアカウントという顔も持ちます。ワークロードを直接稼働させるアカウントと管理アカウントを分離し、管理アカウントには請求・組織管理に関する操作のみを許可する設計が、多くの企業で採用されている考え方でしょう。管理アカウントで本番アプリケーションを直接稼働させてしまうと、請求管理の権限とワークロード運用の権限が同じアカウントに同居する形になり、権限分掌の面でリスクが高まる点に注意が要ります。

コストの閲覧権限とインフラの操作権限は別物として設計する

経理・情シスの担当者がコストを確認したいだけの場合でも、管理アカウントへのアクセス権限を渡すと、Organizationの設定変更やRI・Savings Plansの共有設定変更まで操作できてしまう場合があります。閲覧のみを目的とするユーザーには、IAMポリシーでCost Explorerの参照権限に限定したロールを用意するなど、コストの可視化に必要な権限と、請求設定・組織設定を変更できる権限を分けて付与する設計が実務上重要になります。

RI・Savings Plans共有設定は導入時に方針を固める

前述の通り、RI・Savings Plansの共有はアカウント単位・グループ単位で細かく制御できます^*5。導入時点で「どのアカウント群で割引を優先的に共有するか」「特定の環境（開発・検証など）は共有対象から外すか」といった方針を固めておかないと、後から個別に設定を見直す作業が発生しやすくなります。特に事業部ごとにコストを厳密に按分したい企業では、共有モードの選択がコスト配分の公平性に直結するため、経理側の要件を踏まえて技術側と共同で設計する進め方が有効です。

外注時に確認すべき設計範囲と引き継ぎの論点

AWS Organizationsの一括請求設計をSIerやクラウド専業ベンダーに外注する場合、「Organizationを作成してアカウントをまとめる」作業だけを依頼すると、割引共有やコスト可視化の設計が手薄になりがちです。発注前後で確認しておきたい論点を整理します。

内製に必要なもの

一括請求・マルチアカウントのコスト最適化を内製で運用するには、AWS Organizationsの構造理解に加えて、請求設定（Billing preferences）の操作経験、Cost Explorerを用いたコスト分析の知見、RI・Savings Plans購入計画を継続的に見直す運用体制が必要です。単発でOrganizationを構築した経験があっても、割引共有モードの継続的なチューニングや、アカウント増減にあわせた設計の見直しまで対応できる人材は限られるのが実情でしょう。社内に専任の担当者を置けない場合、初期設計は外部の知見を借り、運用ルールをドキュメント化したうえで引き継ぐ進め方が現実的です。

発注先への確認

提案書に「AWS Organizationsを導入し一括請求を有効化します」とだけ記載されている場合、それだけでは設計の中身が見えません。RI・Savings Plansの共有モード（Organization全体共有か、グループ単位共有か）をどう設計するか、管理アカウントとワークロード用アカウントを分離する方針か、コスト可視化はCost Explorerの標準機能で足りるのか追加のレポート基盤が要るのか、といった点を具体的に質問し、回答の解像度を確認する必要があります。「請求がまとまる」ことだけを成果物として説明するベンダーの場合、割引共有やアカウント設計まで踏み込んだ提案になっているかを重ねて確認した方がよいでしょう。

契約明記

契約段階では、Organizationの構成図（管理アカウント・OU・メンバーアカウントの関係）、RI・Savings Plans共有設定の一覧、コスト可視化の設定内容（Cost Explorerのレポート定義など）を納品物として明記しておく必要があります。これらの資料がないまま契約が終了すると、後任の担当者や別のベンダーに引き継ぐ際、既存の請求設定を1つずつ確認し直すところから作業を始めることになりかねません。特にRI・Savings Plans共有はアカウント単位で個別設定されているため、設定意図が記録されていないと、なぜそのアカウントだけ共有対象から外れているのかを後から判断できなくなるおそれがあります。

一括請求の仕組み自体は導入して終わりではなく、アカウントの増減や事業部再編のたびに設計を見直し続ける運用が前提です。発注時には、初期構築だけでなく、こうした継続的な見直しをどの範囲まで契約に含めるかも確認しておくことが望ましいといえます。

まとめ：一括請求でコスト最適化を機能させる3つの判断軸

本稿では、AWS Organizationsの一括請求を軸に、使用量合算によるボリュームディスカウント、RI・Savings Plansのアカウント間共有、コストの可視化までを整理しました。要点を3つの判断軸に集約します。第一に、一括請求は「請求の一本化」と「割引の合算」を実現する仕組みであり、部門別のコスト配分やガバナンス強化とは別の論点として捉える視点が欠かせません。第二に、RI・Savings Plansの共有は既定の設定のままにせず、アカウント単位・グループ単位でどう共有するかを導入時に方針として固めておく必要があります。第三に、外注する場合も「請求がまとまる」ことだけを成果物とせず、割引共有の設計根拠とアカウント構成図・設定一覧の引き継ぎ範囲を契約前に確認する姿勢が、長期的なコスト最適化の運用品質を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「Consolidating billing for AWS Organizations」（AWS Billing）https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html
2. *2　出典：AWS「What is AWS Organizations?」（AWS Organizations User Guide）https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
3. *3　出典：AWS「Effective billing date, account activity, and volume discounts」（AWS Billing）https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-effective.html
4. *4　出典：AWS「Reserved Instances」（AWS Billing）https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-behavior.html
5. *5　出典：AWS「Reserved Instances and Savings Plans discount sharing」（AWS Billing）https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-off.html
6. *6　出典：AWS「Analyzing your costs and usage with AWS Cost Explorer」（AWS Cost Management）https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html

Tweet