Do AWS credits expire? Yes — and the validity window is different for every credit type.

IEvery AWS credit type and its validity window

There are eight standard AWS credit programs that issue dated promotional balances. Each has a different validity window. Knowing which window applies to the credits in your account is the first step in planning consumption.

The validity window starts on the issuance date — the date AWS applies the credit to your account, not the date you submitted the application. Issuance dates are visible in the AWS Billing dashboard under the promotional credits view. The expiration date listed alongside each credit line is the date after which the remaining balance is forfeited.

Validity windows are program-specific, not negotiable, and not contingent on consumption volume. A $100K Activate Portfolio award issued on 2026-06-15 expires on 2028-06-15. If you have consumed $87K by the expiration date, the remaining $13K is forfeited. If you have consumed $100K by month 18, the credit balance is exhausted and the expiration date is moot.

IIAWS does not grant extensions on credit validity

The expiration date is fixed at issuance. There is no extension process, no appeal channel, and no partial reversal — even if the underutilization is the result of a delayed product launch, a pivot, or a business event that pushed consumption later than projected.

AWS publishes the validity windows in the credit issuance email and on the AWS Billing dashboard, and the dates are treated as final. The AWS Partner Network does not have an extension submission path for Activate credits — partners who file a credit application cannot also file an extension request after issuance.

The reasoning is structural. AWS funds the credit pool from a fixed program budget. Extending an individual credit award is functionally the same as issuing a new credit award, and AWS would prefer the new credit application go through the standard channel (new application, new review, new attestation) rather than as an extension of an old award. The result is that extensions effectively do not exist; you re-apply.

Re-applying is sometimes viable. A startup that received Portfolio at seed stage and reached the 24-month expiration with material unused balance can file a fresh Activate application at the next funding milestone (a Series-A or a meaningful seed-extension). The new application is treated as a separate award — not an extension — with its own validity window. The unused balance from the original Portfolio award is still forfeited.

There is no appeal process. AWS support tickets opened to request an extension are routed to the credit program team, which responds with the standard "credits expire on the issuance-plus-validity date; no extensions" template. CloudRoute partners have not seen an exception granted in the routed-engagement history.

IIIThe automatic application mechanic — credits burn down on their own

AWS credits do not require manual redemption. They auto-apply against the monthly AWS invoice in expiration order — oldest-expiring first — until the credit pool is exhausted or expires.

When the AWS billing system generates the monthly invoice, the promotional credit balance is consumed before the invoice is finalized. The customer sees a final invoice with the credit reduction applied as a line item. No manual claim is required, no form is submitted, and no support ticket is opened.

The application order is expiration-date-ascending. If a customer has $25K of Build for Startups credits expiring on 2027-03-15 and $100K of Portfolio credits expiring on 2028-06-15 in the same account, the monthly invoice first consumes from the Build for Startups balance (earlier expiration) until that balance is exhausted, then begins consuming from the Portfolio balance.

Within the same expiration date, the application order is FIFO (first-in-first-out) based on issuance date. This rarely matters in practice — credit lines with identical expiration dates are usually portions of the same award.

There are two narrow scenarios where the auto-application can be misleading. The first is when credits are earmarked to a specific service — Bedrock POC credits can only consume against Bedrock-related charges, not against general EC2 or RDS. If the monthly invoice has no Bedrock charges, the Bedrock POC balance does not consume that month. The second is when the monthly invoice includes Marketplace billings (Datadog, Snowflake, etc.) — Activate credits do not consume against Marketplace charges, so a customer with a $4K/month bill that is 90% Marketplace SaaS will see only the 10% AWS-native portion consumed.

IVThe AWS Billing dashboard — where to see your credit balance and expiration

Every AWS account has a Billing and Cost Management dashboard accessible to the root user and to IAM users with billing permissions. The promotional credits view is the canonical source for current credit balance, source attribution, and expiration dates.

The credit balance is shown under Billing and Cost Management → Credits in the AWS console. The view lists every promotional credit line currently in the account, broken down by source — meaning the originating program (Activate Portfolio, Build for Startups, Bedrock POC, MAP, etc.). Each line shows the original credit amount, the remaining balance, the issuance date, and the expiration date.

The remaining balance updates monthly when the AWS invoice is finalized. The view does not reflect intra-month consumption — meaning if a customer has consumed $3K of credits between the 1st and the 15th of the month, the remaining balance shown on the 15th is still the month-start balance. Real-time consumption visibility requires using the Cost Explorer view rather than the Credits view.

The expiration date shown is the final date on which the credit line is consumable. After that date, the line is removed from the account and the remaining balance is forfeited. AWS sends a notification email 30 days before expiration to the account billing-contact email. Customers who have not configured the billing contact correctly sometimes miss this notification and discover the expiration only when reviewing the Billing dashboard at end-of-month.

For accounts in AWS Organizations, the Credits view at the management account level shows credits across all linked accounts, with attribution to the linked account where the credit was issued. Credits issued at the linked-account level are consumable against that linked account only; they do not flow up to the management account or down to other linked accounts. This matters for Series-A teams using AWS Organizations for environment separation (production, staging, sandbox) — the credits typically need to be issued against the account that will consume them.

VThe Bedrock POC 6-month checkpoint — what it actually checks

The Bedrock POC credit pool is the only standard AWS credit program with a checkpoint inside the 12-month validity window. Knowing what the checkpoint actually evaluates matters because a forfeit at the 6-month mark removes the remaining balance before the validity expiration date.

At the 6-month mark, AWS reviews the Bedrock consumption history on the account. The review is automated for most awards — the AWS billing system checks whether Bedrock charges have appeared on the account in the prior 6 months. If yes, the credit line continues without intervention. If no, the credit line is flagged for manual review.

A manual-review flag does not automatically trigger forfeit. The Bedrock program team contacts the partner who filed the credit application (or the customer directly if no partner was attached) to ask about POC status. If the response indicates active POC work — even at a small scale — the credit line typically continues. If the response indicates the POC has been abandoned, the team pivoted, or the project never started, the remaining balance is reversed out.

The threshold for "demonstrable POC progress" is not a fixed dollar amount of consumption. CloudRoute partners report cases where $500 of Bedrock consumption over 6 months passed the checkpoint, and cases where $10K of consumption triggered additional questions because the consumption pattern looked like one-off testing rather than sustained workload. The signal AWS looks for is sustained inference patterns — recurring API calls, an evaluation harness running, a production workload integrating Bedrock — rather than total dollar volume.

The forfeit rate at the 6-month checkpoint is approximately 5% of Bedrock POC awards in CloudRoute's routed-engagement data. The 5% is almost entirely teams that explicitly abandoned the Bedrock workload — pivoted to a different inference provider, descoped the AI feature, or paused the project. Slow POCs that maintain even minimal consumption generally pass.

VIThe burn-rate sufficiency math — does the validity window matter for you?

Whether the validity window is a binding constraint depends entirely on your monthly AWS burn. At low burn, the validity window is the constraint and unused credits forfeit. At high burn, the credit pool is the constraint and the validity window is irrelevant.

The relevant calculation is: credit pool divided by monthly burn equals consumption window in months. Compare the consumption window to the validity window.

At Series-A typical burn — $5K/month across compute, database, networking, and observability — a $100K Activate Portfolio award has a consumption window of 20 months. The Portfolio validity window is 24 months. Consumption finishes within validity, with a 4-month margin. This is the modal Series-A profile; the credit pool is fully consumed before expiration, and the validity window is not a binding constraint.

At higher burn — $10K/month or more, common for AI-heavy workloads or video pipelines — the same $100K Portfolio award has a consumption window of 10 months. The credit pool is exhausted well before the 24-month validity expires. The validity window is irrelevant; the constraint is the credit pool size, and the strategic question shifts to whether additional credits can be stacked (Build for Startups, Bedrock POC) or whether the account is ready to transition to EDP/PPA negotiation.

At lower burn — $2K/month, common for early-stage workloads that have not yet hit growth — the same $100K Portfolio award has a consumption window of 50 months. The validity window is 24 months. Roughly half the credit pool is forfeited at expiration. This is the pattern where strategic credit timing matters: applying for Portfolio when projected consumption is below ~$3K/month tends to leave material unused balance.

The break-even burn rate for full $100K Portfolio consumption within the 24-month validity window is approximately $4,200/month. Below that rate, expiration becomes a real risk. Above that rate, the credit pool is the binding constraint.

VIIWhen the credit balance is underused — and when it is exceeded

CloudRoute's routed-engagement data shows two distinct patterns at credit expiration or exhaustion: the underused balance pattern at the low-burn end, and the exceeded balance pattern at the high-burn end. Both are common; both signal different strategic next steps.

The underused balance pattern appears in approximately 10% of Series-A Portfolio awards. The application projected a consumption rate higher than the actual rate — usually because the engineering roadmap slipped, the migration was delayed, or the product pivoted away from AWS-heavy services. At the 24-month expiration, the account has $10K–$40K of unused balance, which is forfeited.

The underused pattern is most common when the credit application was filed early in the burn cycle (before the workload was on AWS) and the actual burn ramped more slowly than projected. The pattern is less common when the application was filed mid-burn, with 3–6 months of historical AWS consumption to anchor the projection.

The exceeded balance pattern appears in the higher-burn category — typically AI startups consuming Bedrock at scale, video pipelines, or workloads with large data egress charges. The credit pool is exhausted well before the validity expiration. After exhaustion, the account becomes a paying AWS customer at full list price. The credit conversation is functionally over.

The exceeded balance pattern is a common transition signal. When a startup exhausts $100K Portfolio in 10 months, the next logical step is not "apply for more credits" — at scale, Activate is no longer the right mechanic. The next step is the EDP (Enterprise Discount Program) negotiation or a PPA (Private Pricing Agreement), both of which offer committed-spend discounts of 10–25% on ongoing consumption. The trigger for moving to EDP is typically $25K/month of sustained AWS spend, which is functionally what an exceeded-balance customer is demonstrating.

Between the two patterns sit the modal customers — the ~70% of Series-A Portfolio awards that consume between $70K and $100K of the $100K pool over the 24-month window. These customers exhaust the pool around month 18–22, with no material forfeit and no urgent transition signal at expiration. They typically continue as paying AWS customers without an EDP negotiation until burn scales further.

VIIIStrategic implication — when to apply so the validity window aligns with burn

The validity window is a binding constraint for low-burn applicants. The way to avoid forfeit is to time the application so the validity window aligns with peak consumption rather than with the trough.

For a Series-A startup that just closed funding but has not yet migrated to AWS, the projected burn for the first 6 months is typically low — the migration is in progress, the production workload has not cut over, and the dev/staging environments are the only consumption. Filing Portfolio at month 0 means the 24-month validity window opens at the trough.

The alternative timing — filing Portfolio at month 3 or 4, after the migration cutover when the production workload is live — opens the validity window at the start of peak consumption. The same $100K credit pool consumes faster, the validity window is less likely to bind, and the forfeit risk drops.

The trade-off is that delayed application means delayed credit availability. The first 3 months of AWS bills are paid at full list price rather than against credits. For a $5K/month workload, that is $15K of pre-credit spend — material, but not catastrophic, and the offsetting reduction in forfeit risk often makes the trade worthwhile.

The reverse case — filing Portfolio too late, after the workload is already at scale — has its own problem. A startup that has been on AWS at $20K/month for 12 months and then files Portfolio will consume the $100K in 5 months. The credit pool is small relative to ongoing burn, and the strategic move is to skip Portfolio and start the EDP negotiation directly.

The narrow sweet spot for Portfolio application is when projected burn is between $4K and $10K per month at the time of application, with the workload either already on AWS or migrating within 90 days. In that band, the 24-month validity window aligns with the 12–24 month consumption window, and the credit pool is fully consumed without material forfeit.

IXThe claw-back scenario — when AWS revokes credits post-issuance

Once credits are issued, they are normally consumed against the account without further AWS intervention. There is one rare scenario in which AWS revokes credits already in the account: a post-issuance eligibility-verification failure.

AWS's credit programs include a verification clause permitting the company to revoke credits if the eligibility attestation is later found to be inaccurate. The clause is enforced rarely — CloudRoute partners report claw-back rates below 1% across thousands of partner-filed credit applications — but it exists and is worth knowing about.

The two scenarios most commonly trigger a claw-back. The first is when the company is found, post-issuance, to be a direct AWS competitor in a way that was not visible at application time. This typically occurs when a startup pivots — for example, a SaaS company that received Portfolio credits and then pivoted to launching a competing cloud infrastructure product. AWS may revoke the unused credit balance at the point of pivot.

The second scenario is fraudulent application material — fabricated funding, misrepresented founder identity, or shell-company structures designed to obtain credits without a legitimate workload. CloudRoute partner pre-vetting is structured to filter these cases before submission, which is part of why the claw-back rate on routed applications is at the low end of the band.

A claw-back removes the unused balance from the account. Consumed credits are not reversed — meaning the customer is not retroactively billed for AWS consumption that was paid by credits prior to the claw-back date. The financial impact is forward-only: the customer pays full list price from the claw-back date onward.

For ordinary, legitimately funded Series-A startups consuming AWS for a normal workload, the claw-back risk is functionally zero. The scenario is included here for completeness; it is not a realistic concern for the modal Portfolio applicant.

XThe "credit reissuance" myth — there is no automatic re-up

A common misconception is that AWS automatically reissues credits at the validity expiration date, or that the validity window can be extended by upgrading to a higher-tier credit program. Neither is true. Reissuance is not automatic; new awards are separate applications, not extensions.

At the 24-month Portfolio expiration date, AWS does not automatically issue a fresh Portfolio award. The customer can file a new Activate application — typically at a new funding milestone like a Series-B closure — but the new application is treated as a separate award. The unused balance from the original Portfolio is forfeited; the new award starts at zero and runs its own 24-month validity from the new issuance date.

Filing a new Portfolio application without a new funding milestone is generally not productive. AWS reviewers look for new institutional vouching as the trigger for a new award — a follow-on round, a meaningful seed-extension, or an acquisition by a venture-backed parent. Without a new vouching signal, the new application is typically rejected or downgraded.

The narrow exception is the funding-milestone transition — a startup that received Founders at pre-seed, Portfolio at seed, and reaches Series-A can file a fresh Portfolio application at Series-A. The new Series-A Portfolio award is a separate $100K pool with a fresh 24-month validity, independent of the seed-stage Portfolio that is approaching expiration. This is functionally a "Portfolio refresh" at the funding-milestone transition, but it is not automatic — the new application must be filed and reviewed like the first one.

The other path that resembles reissuance is the move from Activate to MAP at Series-B. A startup that exhausted Portfolio during Series-A and is now scaling AWS workloads through a larger migration can file a MAP record, which produces a fresh credit pool tied to the migration phases. The MAP pool is calibrated to the migration scope and can exceed the original Portfolio pool, but it is a different program with different mechanics — not an extension of Portfolio.

XIMAP credits — the special staggered timeline

MAP credits do not follow the standard "issuance plus validity window" model. They are issued at the completion of each migration phase, with each tranche carrying its own validity window from its own issuance date. The effective MAP credit timeline is a staggered series of partial awards rather than a single pool.

The migration phases are Assess, Mobilize, and Migrate. Each phase has its own scope of work and its own credit payout at completion. Credits do not accumulate upfront, which means a customer who exits the program early — for example, completing Assess but not Mobilize — receives only the Assess-phase credit and forfeits the Mobilize and Migrate phase payouts that have not yet been earned.

The Assess phase typically pays $10K–$25K at completion. The Assess work is the sizing, architecture, and migration plan — typically 2–4 weeks of partner-led discovery. The Assess credit lands when the AWS partner submits the Assess deliverable and AWS approves the sign-off. Validity from the Assess credit issuance date is typically 12 months.

The Mobilize phase typically pays $25K–$100K at completion. The Mobilize work is the pilot — landing zone setup, identity, networking, security baseline, and a pilot workload migration. This phase takes 4–8 weeks. The Mobilize credit issues at sign-off, with 12 months validity from that date.

The Migrate phase typically pays $50K to $500K+ at completion, depending on migration size. The Migrate work is the production cutover — moving the bulk of the workload from the source environment to AWS. This phase takes 8–24 weeks. The Migrate credit is the largest of the three and typically has 12–24 months validity from issuance.

The staggered timeline matters for planning. A migration that takes 18 months end-to-end produces three credit tranches landing at month 3, month 8, and month 18. The first tranche is approaching expiration when the third tranche is issued. Customers who plan their MAP migration without modeling the tranche timeline sometimes find that the Assess credit expires before the Migrate phase is complete, leaving unused balance forfeited.

The strategic move is to time the consumption — to schedule paid AWS workload during the migration window so the Assess credit consumes within its 12-month validity rather than sitting unused. CloudRoute partners managing a MAP engagement typically build a consumption ramp aligned to the tranche issuance dates.

XIIA real anonymized example — what expiration looks like in practice

A representative case from the CloudRoute routed-engagement history, with identifying details abstracted. The numbers are real; the company is not named.

Series-A B2B SaaS startup. 12 engineers. Closed Series-A in May 2024 from a tier-2 institutional venture firm. The startup applied for Activate Portfolio via a CloudRoute-routed AWS partner in early June 2024. The application was filed through ACE and approved on 2024-06-15. The credit balance posted to the AWS account on 2024-06-15 — $100K of promotional credits, validity 2026-06-15.

Initial AWS consumption ran lower than the application projection. The team had been on Heroku and the migration to AWS ran 7 weeks behind the original plan. Monthly AWS consumption averaged $1,800 for the first 6 months while the migration was in progress, then ramped to $4,200/month over months 7–12 as the production workload cut over, then plateaued at $5,500/month for months 13–22.

By the 24-month expiration date — 2026-06-15 — the cumulative credit consumption was $87,000. The remaining $13,000 was forfeited at expiration. The AWS Billing dashboard showed the Portfolio line item removed from the account on 2026-06-16; the team's monthly invoice from 2026-07-01 onward billed full list price.

The forfeit was not catastrophic — the team had consumed 87% of the pool and avoided $87K of AWS spend over 24 months — but the $13K unused balance was a direct result of the slow migration ramp. If the migration had cut over on the original schedule, the consumption window would have closed roughly 4 months earlier and the pool would have been fully consumed.

The team's next move is the typical Series-B path: continued AWS consumption at $5,500/month for several quarters, with an EDP negotiation triggered when sustained spend exceeds $25K/month (likely during the Series-B raise). No fresh Portfolio application is planned, since the workload is now established and the next credit conversation is EDP, not Activate.