agent recommended buying RIs per account - the discounts would have been better pooled at the payer level
Fixes RI recommendations that buy per linked account instead of pooling the commitment at the payer account. Use when per-account commitments show low utilization while sibling accounts pay on-demand for the same instance families. It models the pooled alternative, confirms discount sharing is enabled, and sets the agent's default to payer-level placement.
TL;DR: Buy the commitment at the payer account so the discount pools across all linked accounts. Agents analyze one account at a time because credentials and API calls are per-account, so per-account RIs look optimal in that narrow view - while a sibling account pays on-demand for the same instance family. Size one payer-level commitment against total steady-state usage instead.
agent recommended buying RIs per account - the discounts would have been better pooled at the payer level- Map the current state: list RIs per linked account and check whether RI sharing is enabled in the organization settings. Expected: per-account RIs with gaps, while other accounts pay on-demand for the same instance families.
- Model the pooled alternative: sum the steady-state usage across all linked accounts for each instance family and region, then size one payer-level commitment against the total. Expected: higher utilization and a larger effective discount than the scattered per-account RIs.
- Before buying at the payer level, confirm sharing is enabled and check for sharing exclusions (some organizations disable sharing for specific accounts). Expected: a clean yes that the payer-bought RI's discount will actually flow to the linked accounts' usage.
- Set the agent's default: commitment recommendations are sized and placed at the payer account unless the agent can cite a reason not to (for example an account excluded from sharing). Expected: no more per-account RI recommendations without an explicit justification.
Use this when
- RI or savings plan recommendations target individual linked accounts
- You see per-account commitments with low utilization while sibling accounts pay on-demand
- You run an AWS Organization with consolidated billing and want commitment pooling
Not for this skill when
- You have a single account - there is nothing to pool
- RI sharing is deliberately disabled (chargeback or compliance reasons) - respect that decision
- The accounts are in different regions with no overlapping usage - pooling does not help across regions
Variant phrasings
- buy reserved instances at payer account vs linked account
- ri discount sharing across organization accounts
- agent recommended per account ri instead of pooled
- how does aws ri sharing work consolidated billing
Why it happens
Agents analyze one account at a time because credentials and API calls are per-account. The per-account view makes per-account RIs look optimal, and the agent never sees the sibling account running the same instance family on-demand. Consolidated billing pools the discount automatically - but only if the commitment is bought where the pool can see it.
Edge cases
- Savings plans share the same pooling behavior. Apply the same payer-level default to them.
- Account-level reservations exist for a reason in some setups (dedicated capacity). Distinguish capacity reservations from billing discounts before consolidating.
- Organizational units with separate payer accounts (for example after acquisitions) may not share. Verify the billing family structure first.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_OX6LYwoijvIETuGOigxjuQ
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.