Summary

  • AWS says the final monthly bill uses discount-sharing preferences set at 23:59:59 UTC on the month's last day. Estimated bills use the latest settings.
  • Purchasing-account priority and sharing groups change the order and scope of beneficiaries. Company-wide savings and each division's budget responsibility need an explicit allocation decision.

The organisation chart has an appointment with accounting: 23:59:59 UTC on the last day of the month.

AWS's billing-preferences guide names that instant as the reference for the discount-sharing settings used to calculate the final monthly bill. Estimated bills use the last set of preferences. Between a number a division has watched for weeks and its final allocation sits a boundary somebody has permission to move.

For Savings Plans, the benefit being distributed is a lower price on eligible usage. An application can remain exactly where it is while its account changes position in the queue. No server needs a removal van. Purchasing ownership and the sharing map already have financial work to do.

Three maps for the same benefit

Open sharing, the default, makes discounts available to sharing-enabled accounts across the organisation. Prioritized group sharing serves the purchasing account first, then the defined group, then the remaining sharing-enabled accounts. Restricted group sharing keeps benefits exclusively within the defined group.

Groups are defined through Cost Categories. An account can belong to only one group, groups cannot overlap, and the management account cannot belong to a group. The Savings Plans owner account must be active in discount-sharing preferences.

Those lines have economic force. Under restricted sharing, a remaining benefit cannot cross the boundary to useful demand in the next division. AWS explicitly says group allocation can reduce overall discount optimisation by giving the group priority.

A business unit with its own profit-and-loss responsibility may value precisely that separation. Central procurement may see a lost saving. Both are company objectives. A recommendation in the console cannot settle how much budget independence should cost.

An empty account can make a useful buyer

Ownership gets the first turn. AWS applies Savings Plans to eligible usage in the owner account before sharing with others. Within the applicable allocation stage, usage offering the highest savings percentage comes first. That is a different rule from an unconditional organisation-wide contest for the biggest discount.

An official AWS article published on 25 October describes an account using Lambda that buys its own Compute Savings Plan. Its usage receives the benefit first. An opportunity for a higher percentage saving on m8g Linux EC2 usage in another account can consequently be missed. The example gives no measured dollar loss; it explains how the buyer's identity enters the allocation order.

For central purchasing, AWS proposes the management account or a designated account without workloads. With no eligible owner usage to absorb the benefit first, it can flow to other accounts under the sharing rules. The applications stay home; purchasing changes address.

An account running nothing can therefore have a useful financial role. It separates ownership of the spending commitment from the consumption of computing. Then comes a very real job: internal chargeback. Buying together does not automatically decide who funds the remaining commitment or keeps the savings.

Headquarters sees $100; the teams add up to $70

AWS's article uses an explanatory scenario for a one-year, no-upfront Compute Savings Plan. The management-level recommendation is $100 an hour, while the member-account recommendations total $70. These are illustrative recommendations from different calculation scopes.

The central view combines eligible usage that can share benefits. The individual view considers each account and the benefits already applied to it. Hourly demand patterns and sharing boundaries change the optimisation problem. The article also explains the opposite direction: owner priority can make separate purchases add up to a larger commitment than the central recommendation.

Recommendations calculate history. The official calculation guide says they exclude queued or scheduled purchases and are generated for immediate purchases. Changing groups also changes the accounts considered. A number produced by the old map needs another look before becoming the purchase answer for the new one.

Quantifying the effect in an actual organisation requires owner accounts, sharing preferences, eligible hourly usage and the current commitment inventory.

The month's final second fixes an economic map. Whoever can redraw it helps decide the destination of a discount another division may already have put in its budget. An ordinary reorganisation has a named decision-maker. The discount map deserves one too.

Sources