How AWS credits actually apply (2026)

Credits are the one part of an AWS bill nobody configures and everybody assumes they understand. They are also more common than they used to be: AWS gives new accounts free-tier credits, and documents a further USD $100 in credits for completing activities, so a first bill is now often a credit question rather than a usage question. AWS decides which credit to spend, which service to spend it on, and which account in your organization receives it, and it publishes the order it does all three in. Knowing that order is the difference between a credit that covers the workload it was granted for and one that quietly pays for somebody else's data transfer.

How are AWS credits applied to your bill?

Automatically, and without asking you. The Applying AWS credits documentation states the basic behaviour: "AWS credits are automatically applied to bills to help cover costs that are associated with eligible services… Credits are applied until they are exhausted or they expire." And in case that leaves any doubt: "credits don't require customer selection to apply during the billing process. AWS will automatically apply eligible credits to applicable services."

Within an account, the target is picked by size: "credit is applied to the largest services charge (for example, Amazon EC2, Amazon S3). Then, the consumption will continue in a descending pattern for the remainder of the service charges."

So a credit granted for a proof of concept will land on whatever your biggest eligible line is that month, which is usually not the proof of concept.

Which order does AWS apply multiple credits in?

Three tiebreakers, in this order, for a single or standalone account:

The design intent is spelled out elsewhere on the same page: "AWS applies the credit to the largest available charge across all eligible sellers of record. This means that AWS tries to apply your credits before they expire. So they might use a generic credit for a specific service."

That last sentence is the useful one. AWS optimises for using credits up, not for matching them to intent. If you hold a broad credit and a narrow one, the broad credit can be consumed on charges the narrow one would have covered, leaving the narrow one to expire against nothing. The ordering rules make that less likely than it sounds, but only when the expiry dates cooperate.

AWS's own example, with the numbers: "credit one is for 10 dollars, it expires January 2026, and it can be used for either Amazon S3 or Amazon EC2. Credit two is for 5 dollars, it expires December 2026, and it can be used only for Amazon EC2… AWS selects credit one for application first because it expires sooner than credit two."

How do AWS credits work across an organization?

With sharing on, which is the default, AWS walks down from the owning account to the biggest spender across the billing family:

"The process repeats until the credit is consumed, or all customer spend is covered." The owning account is served first, so a credit granted to a team's account does cover that team's usage before it leaks. What it does after that is find the largest account in the organization, which for most groups means production.

Turning sharing off changes it to the obvious behaviour: "credits are applied to only the account that received the credits." Two details make that setting harder to use than it looks. It is decided at the end of the period: "bills are calculated using the credit sharing preference that is active on the last day of the month." And it is centralised: "in an organization, only the payer account can turn credit sharing off or on."

Can you control which accounts a specific AWS credit covers?

Yes, and it is the least known feature on this page. Credit-level sharing preferences let you scope a single credit to a group of accounts rather than choosing between all-or-nothing:

"Credit-level sharing preferences — Define which accounts can use a specific credit based on your cost allocation structure using Cost Categories."

The mechanism is a cost category rule: "for Cost category, select an existing cost category from the dropdown, or choose create a new cost category to define your sharing group", then "for Rule, select a rule to define which accounts are included in the sharing group."

So a credit granted for a specific programme can be pinned to the accounts in that programme, using the same cost category you already built for chargeback. If you do not have one, the mechanics of building one are in AWS Cost Categories: split charge limits.

There is a prerequisite that catches people: "both the credit owner account and the recipient accounts must have credit sharing activated." A credit-level preference does not override an account that has sharing turned off. And removing the preference falls back rather than blocking: "when a credit-level sharing preference is removed, the credit reverts to the default sharing behavior based on the credit sharing activation settings for accounts in your organization."

There is also a pause button on any individual credit. The credit details page carries a status, and one of the values is "Paused — the credit is turned off but can be turned back on to be consumed. To change a credit's status between Active and Paused, use the status toggle on the credit details page." Pausing a broad credit for a month is the crude way to stop it being spent on the wrong thing before you have a cost category ready.

What can AWS credits not be used for?

A longer list than most people expect, published in the AWS Promotional Credit Terms and Conditions:

"Unless authorized by us, Promotional Credit will not be applied to any fees or charges for Amazon Mechanical Turk, AWS Managed Services, Ineligible AWS Support, AWS Marketplace, AWS Professional Services, AWS Training, AWS Certification, Amazon Route 53 domain name registration or transfer, any Services for mining for cryptocurrency, any other Services as may be designated by your AWS contracting entity, or any upfront fee for any Services such as Savings Plans and Reserved Instances."

Three of those matter for ordinary cost planning:

• AWS Marketplace. Third-party software bought through Marketplace is not covered, which surprises teams whose observability or security stack is a Marketplace subscription.
• Upfront commitment fees. "Any upfront fee for any Services such as Savings Plans and Reserved Instances" is excluded, so you cannot spend an expiring credit by buying an All Upfront commitment with it.
• Some support tiers. "Ineligible AWS Support" is defined in the terms as "AWS Support (as described on the AWS Site) that is AWS Enterprise Support, AWS Unified Operations, AWS Enterprise On-Ramp, AWS Resold Support (AWS Enterprise Support, AWS Unified Operations, and AWS Enterprise On-Ramp), and AWS Partner-Led Support."

Tax is excluded as well: "Promotional Credit will not be applied against any sales, use, gross receipts, or similar transaction-based taxes that may be applicable to you." A fully credited bill still has a tax line to pay.

And credits are not an asset: "you may not sell, license, rent, or otherwise transfer Promotional Credit… Promotional Credit has no intrinsic value, is not redeemable for cash, has no cash value, is nonrefundable." The one exception is inside a billing family: the terms note that this "does not restrict authorized sharing of Promotional Credits within an AWS Organization".

What happens to AWS credits when they expire?

They are gone, and the last billing cycle is fully claimable. "Redeemed Promotional Credit will be applied to offset eligible fees and charges incurred during the entire billing cycle in which it expires. Failure to redeem Promotional Credit before its expiration date will result in its forfeiture."

Two things follow. A credit expiring on the 5th of a month still covers that whole month's eligible charges, so there is no need to front-load usage into the first few days. And an unredeemed code is worth nothing after its date: redemption and application are different events, and only the first has a hard deadline you control.

The status vocabulary on the credit details page distinguishes the two endings: "Exhausted — the credit has a zero balance remaining and has been fully consumed" against "Expired — the credit has passed its expiration date and is no longer available for use." Exhausted is the outcome you want.

Where do AWS credits show up in Cost Explorer and the CUR?

In the CUR, as their own line item type. The CUR 2.0 line item columns define Credit as "any credits that AWS applied to your bill. See the Description column for details", with a warning attached:

"AWS might update reports after they've been finalized, if AWS applies a credit to your account for the month after finalizing your bill."

A closed month can therefore change. If you snapshot the CUR for reporting, credit line items are the most likely reason last quarter's number moved.

Credit rows also carry no resource: the same reference notes that line_item_resource_id "is blank for usage types that aren't associated with an instantiated host, such as data transfers and API requests, and line item types such as discounts, credits, and taxes." A credit cannot be attributed to a resource, only to an account and a service, which is why credit-aware chargeback has to be done at the account level. Which cost column includes credits at all is a separate question, answered in amortized vs unblended cost.

On the console side, the balance you see depends on where you look. The Credits page shows the balance "since the last billing date" and "your credit balance is updated each month at the end of the current billing cycle", while the Bills page's Savings tab shows an estimate for the current month. The credit details page splits them explicitly into "amount remaining" ("the remaining balance of the credit as of the last billing cycle") and "estimated amount remaining" ("the estimated remaining balance of the credit for the current month, updated daily"). Reconciling a mid-month figure against the Credits page will not agree, by design.

For tracing where a credit went, the details page has an "Application history tab that shows how the credit has been allocated, including the recipient account, service, product, and amount for each allocation." That is the only place the account-by-account split is visible.

What happens to credits when an account joins or leaves an organization?

The boundary is the first of the month, and it produces a gap that costs real money. AWS's rule for an account that joins mid-month:

"An individual's account credits don't cover the account usage from the day that the individual joined the organization to the end of that month. For this period, the individual's account credits aren't applied to the bill. However, starting the next month, AWS applies the individual's account credits to the organization."

So an account holding credits that joins on the 10th has its credits applied to usage up to the 10th, and then nothing for the rest of the month. Ordinary charges split at the join date instead, which is one of several rules worth reading before a merge: does consolidated billing save money. If you are moving a credit-funded account into an organization, moving it on the first of a month avoids that gap entirely.

Leaving works the same way from the other side: "if an individual leaves an organization during the month, AWS begins applying credits to the individual's account on the first day of the following month", and until then "any credits that she redeems are also applied to the organization's bill".

One more rule catches organizations that acquire accounts to pool credits: "credits are shared with all accounts that join an organization at any point in the month. However, the organization's shared credit pool consists of only credits from accounts that have been part of the organization since the first day of the month." A new member can spend the pool immediately; its own credits do not enter the pool until the next month.

How should you manage AWS credits?

• Check the expiry dates before the balance. AWS applies the soonest-to-expire credit first, so the schedule matters more than the total.
• Scope programme credits with a cost category. Credit-level sharing preferences exist precisely so a credit does not drift to whichever account spends most, and they reuse the allocation structure you already maintain.
• Do not plan to spend a credit on a commitment. Upfront Savings Plans and Reserved Instance fees are ineligible, so an expiring credit cannot be converted into committed-use coverage.
• Move accounts on the first of the month. Joining mid-month creates a period where the account's own credits cover nothing.
• Re-pull closed months. Credits are applied after finalisation often enough that AWS documents it, and the restated figure is the correct one.