Does consolidated billing save money? (2026)

Akal Cloud Updated 8 min read

Quick answer

Yes, and it is free to enable. AWS's own worked example saves $81.92 on a $2,088.96 data transfer bill, about 3.9 percent, purely from reaching a volume tier faster. Reserved Instance and Savings Plans discount sharing is worth far more, because an unused commitment in one account covers usage in another. The catch is the free tier: AWS applies it to total usage across the whole organization rather than to each account, so many small accounts lose out.

Consolidated billing is free to turn on, so the usual question is not whether to use it but how much it actually returns. AWS publishes a worked example, and the answer for volume tiering alone is about 4%. The commitment sharing underneath it is worth far more, and there is one thing joining an organization takes away that nobody mentions.

What is consolidated billing in AWS?

One payer for many accounts. Per the consolidated billing documentation: "every organization in AWS Organizations has a management account that pays the charges of all the member accounts." AWS lists four benefits, and the last one is the reason there is no decision to make: "No extra fee – Consolidated billing is offered at no additional cost."

The mechanism behind the savings is stated in one sentence: "for billing purposes, AWS treats all of the accounts in the organization as if they were one account."

Does consolidated billing save money?

Yes, through three separate mechanisms, and they are worth very different amounts:

MechanismTypical value
Volume pricing tiers reached fasterLow single-digit percent on tiered services
Reserved Instance and Savings Plans discount sharingUp to the full commitment discount on usage that would otherwise be uncovered
Credit sharing across accountsWhatever would otherwise expire unused

AWS's own summary names the first two: "Combined usage – you can combine the usage across all accounts in the organization. This shares the volume pricing discounts, Reserved Instance discounts, and Savings Plans. This can result in a lower charge for your project, department, or company than with individual standalone accounts."

How much does volume tiering actually save?

AWS publishes the arithmetic in its volume discounts documentation, which is unusual enough to be worth quoting in full. Two accounts, 8 TB and 4 TB of data transfer, against illustrative rates of "$0.17 per GB for the first 10 TB of data transferred and $0.13 for the next 40 TB":

"For the 12 TB that Bob and Susan used, Bob's management account is charged ($174.08 * 10 TB) + ($133.12 * 2 TB) = $1740.80 + $266.24 = $2,007.04. Without the benefit of tiering across the consolidated bill, AWS would have charged Bob and Susan each $174.08 per TB for their usage, for a total of $2,088.96."

That is a saving of $81.92 on a bill of $2,088.96, or about 3.9%. Useful, not transformative. The benefit comes from volume that would have been billed at a higher tier inside one account being billed at a lower one once usage is pooled, so it grows with how much usage sits just above a tier boundary. It does not require either account to be small. Two accounts each moving 20 TB would individually pay $174.08 for their first 10 TB and $133.12 for the next 10 TB, which is $3,072 each and $6,144 together, while the same 40 TB pooled is ($174.08 x 10) + ($133.12 x 30) = $5,734.40. That saving is $409.60, larger in both dollars and percentage. Consolidation stops paying on this meter only when every account already reaches the cheapest tier on its own.

The tier reset matters too. Per Understanding Consolidated Bills, "to measure usage, AWS treats all accounts in an organization as a single account. Member accounts don't reach tier thresholds individually", and "as each month begins, your service usage is reset to zero." Volume tiering is a monthly benefit that has to be re-earned, so it favours organizations with sustained high usage rather than spiky usage.

AWS distributes the benefit rather than keeping it at the payer: "AWS then allocates each member account a portion of the overall volume discount based on the account's usage." That allocation is what produces the blended rates people find confusing in the CUR, which is a separate subject covered in amortized vs unblended cost and in why Cost Explorer and your CUR differ.

Does the AWS free tier still apply per account?

No, and this is the cost of joining rather than a benefit of it:

"For services such as Amazon EC2 that support a free tier, AWS applies the free tier to the total usage across all accounts in an AWS organization. AWS doesn't apply the free tier to each account individually."

An organization with twenty sandbox accounts does not get twenty free tiers. It gets one, spread across all of them. For a consultancy or a training environment where each account was individually inside the free tier, joining an organization can raise the total bill even while volume tiering lowers the rate.

The alerting is also organization-shaped by default: "free tier budgets are not enabled for organizations by default. Management account can opt in to free tier usage alerts through the Billing and Cost Management console. Free tier usage alerts aren't available to individual member accounts." So the account owner who is burning the shared free tier cannot see it, and the payer has to opt in to find out. Budget alerting more generally is compared with anomaly detection in AWS Budgets vs Cost Anomaly Detection.

How do Reserved Instances and Savings Plans work across accounts?

They are shared by default, in both directions. Per the Reserved Instances documentation: "all accounts in the organization can receive the hourly cost benefit of Reserved Instances that are purchased by any other account."

This is where the real money is. An unused reservation in one account automatically covers matching usage in another, which turns a stranded commitment into a discount. It is also switchable: "you can turn off Reserved Instance discount sharing on the Preferences page on the Billing and Cost Management console."

Turning it off is a legitimate choice when teams buy their own commitments and must not free-ride on each other. It is an expensive choice by default, because it re-strands every reservation. Before touching that setting, look at utilization: a commitment that is not fully used is unrecoverable waste, which is the distinction drawn in Savings Plans coverage vs utilization.

One limit worth knowing if you run more than one organization: "when you use billing transfer, Reserved Instances and Savings Plans apply only to the AWS Organizations where they're purchased, regardless of which account pays the bill. You can't purchase or share Reserved Instances and Savings Plans across multiple AWS Organizations."

Who pays when an account joins an organization mid-month?

The bill splits at the join date. AWS: "when the member account owner accepts your request to join the organization, you immediately become responsible for the member account's charges. If the member account joins in the middle of the month, the management account is billed only for the latter part of the month." The example: "if a member account joins an organization on March 10, then AWS bills the management account for the member account's period of usage starting on March 10. The member account's original owner is still billed for the first part of the month."

Credits do not follow that rule, which catches people who join an organization specifically to pool credits. Their timing is different enough to need its own treatment: see how AWS credits actually apply.

Two consequences of membership that arrive later. Member bills stop being authoritative: "the member account bills are for informational purpose only. The management account might reallocate the additional volume discounts, Reserved Instance, or Savings Plans discounts that your account receives." And leaving is lossy:

"When a member account leaves an organization, the member account can no longer access Cost Explorer data that was generated when the account was in the organization. The data isn't deleted, and the management account in the organization can still access the data. If the member account rejoins the organization, the member account can access the data again."

We see the same shape from the data side when onboarding organizations: the Cost and Usage Report belongs to the payer, so member accounts we onboard have no export of their own and their history is only reachable through the management account's report. If a member account is going to be spun out, its cost history has to be exported before it leaves, not after.

Does an AWS Support plan cover the whole organization?

No. This is the most common wrong assumption about consolidated billing, and the support charges documentation states the correction directly:

"AWS calculates Support fees independently for each member account. Typically a Support subscription for a member account does not apply to the entire organization. Each account subscribes independently."

Two qualifications follow. Enterprise Support is different: "Enterprise Support plan customers have the option to include multiple accounts in an aggregated monthly billing." And commitments carry their support fee with them: "Support fees associated with Reserved Instance and Savings Plan purchases apply to the member accounts that made the purchase." An account that buys the organization's Savings Plans therefore carries a support fee proportional to a purchase made on everyone's behalf, which is worth knowing before you centralise purchasing into one account.

What does consolidated billing cost you?

Nothing in fees, and four things in practice:

  • One free tier instead of many. The largest real cost, and the only one that can make the total bill go up.
  • Member accounts lose an authoritative bill. Their figures are informational, so internal chargeback has to be built on the payer's CUR rather than on member invoices.
  • Cost history is hostage to membership. An account that leaves loses its Cost Explorer history until it rejoins.
  • The management account becomes load-bearing. AWS's own guidance in Understanding Consolidated Bills is to keep it empty: "as a best practice you shouldn't use the management account to run AWS services. An exception is for services and resources that are required to manage the organization itself. For example, as part of managing your consolidated billing you might create an S3 bucket in the management account to store AWS Cost and Usage Reports."

None of those outweigh discount sharing for an organization of any size. They are the reasons to plan the account structure before merging rather than after, because the exit is the expensive direction.

If your goal in consolidating is chargeback rather than discount, the billing family is only the first step: the allocation itself is a separate problem with its own failure modes, covered in AWS Cost Categories split charge rules and why cost allocation tags show up empty.

Share LinkedIn X Hacker News Reddit

See this on your own bill

Akal Cloud connects in about two minutes and shows the same numbers against your real AWS accounts.

Get started on AWS Marketplace

Related reading