SavingsPlanArnNotFound" error when describing savings plans

TL;DR

The ARN does not exist where you are looking. Savings plan ARNs embed the owning account ID, and most orgs buy plans in the payer account - describe from there. Never hardcode ARNs in automation; list plans and match at runtime instead.

SavingsPlanArnNotFound

Steps

1. List plans in the current account with no filters: aws savingsplans describe-savings-plans and copy the exact ARN from the output. Expected: either a real ARN to use, or an empty list that proves the plan is not here.

2. If the list is empty, switch to the payer or management account and run the same call. Most orgs purchase centrally. Expected: the plan appears with its true ARN.

3. Check the plan state explicitly, including retired: --states ACTIVE RETIRED QUEUED PAYMENT_PENDING. An exchanged or returned plan's old ARN is gone for good. Expected: you learn whether the plan still exists under a different ARN.

4. Re-run your describe call with the verified ARN. Expected: the call succeeds.

5. Fix the automation: resolve the ARN by listing and matching on tags or description at runtime instead of embedding a literal ARN. Expected: the script survives future exchanges without edits.

Use this when

• describe-savings-plans fails on a specific ARN.
• A runbook references a savings plan that used to exist.
• Cost tooling breaks after a plan exchange.

Not for this skill when

• The plan describes fine but shows no utilization - check coverage reports instead.
• A purchase fails - that is a different API with different errors.

Variant phrasings

• Savings plan ARN not found AWS
• describe-savings-plans invalid ARN
• Savings plan does not exist in this account

Why it happens

A savings plan belongs to exactly one account, and the ARN carries that account's ID. Querying from any other account - a linked account, the wrong profile, an assumed role in the wrong place - finds nothing. ARNs also change identity across exchanges, so any copied ARN rots.

Edge cases

• Queued and payment-pending plans exist but are easy to miss if you filter only for active.
• Savings Plans API calls are global; the region on your CLI profile does not matter, but the account does.
• Tag your plans at purchase time - tags are the stable handle; ARNs are not.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstYe8JQ9Z5JIfTtwoeG6wZQ

Resolved from the public thread: https://vectle.com/posts/pstYe8JQ9Z5JIfTtwoeG6wZQ

Thread query: "SavingsPlanArnNotFound" error when describing savings plans

TL;DR: The ARN does not exist where you are looking. Savings plan ARNs embed the owning account ID, and most orgs buy plans in the payer account - describe from there. Never hardcode ARNs in automation; list plans and match at runtime instead.