EDP Credit Allocation Strategy: How to Stack, Allocate, and Protect AWS Credits

AWS credit packages look like free money. Often they are not — or rather, they are free money that AWS captures back through the structure of your EDP. Across $2.4B+ in AWS spend reviewed across 500+ engagements, we routinely see buyers receive seven-figure credit grants and capture only fractional economic value from them, because the credit allocation terms were negotiated as an afterthought.

This guide is about the mechanics. What types of credits AWS issues, how each type interacts with EDP commitment math, the stack-versus-offset question that determines actual economic value, and the allocation provisions worth negotiating up front.

The credit types AWS actually issues

Most buyers think of AWS credits as a single category. Internally, AWS treats them as at least six distinct instruments, each with its own approval pathway, expiration profile, and EDP interaction rule.

Migration Acceleration Programme (MAP) credits

Grants tied to documented workload migrations from on-prem or competitor clouds. Typical range: 5–25% of the projected first-year AWS spend for the migrated workload, capped at a per-engagement maximum. MAP credits are the largest single category we see and the most negotiable.

Proof-of-Concept (POC) credits

Smaller grants ($25K–$500K typically) supporting evaluation of new services or architectural patterns. Often issued to unlock specific service adoption rather than as broad financial offsets.

Marketing Development Funds (MDF)

Co-marketing dollars for joint AWS-buyer events, content, or campaigns. Technically not credits applied against your AWS bill, but AWS-funded marketing spend that some buyers do not realize is available.

Executive-sponsored credits

Discretionary grants approved by named AWS executives, typically as a relationship-building or deal-rescue instrument. Less predictable, larger per-grant, and the category buyers most consistently fail to ask for.

Marketplace Private Offer credits

Credits tied to specific ISV transactions on AWS Marketplace, often co-funded by the ISV. Increasingly common as Marketplace consolidation accelerates.

Programme-specific credits

Activate (for startups), ProServe (for professional-services engagements), Well-Architected Framework Reviews, and similar programme-specific instruments. Each has eligibility criteria worth checking.

The stack vs offset decision

Once a credit is issued, it interacts with your EDP commitment in one of two ways:

• Offset: credit consumption counts toward your EDP commitment burn. Your invoice goes down but your commitment glide path is unaffected.
• Stack: credit consumption does not count toward your EDP commitment burn. Your invoice goes down AND your remaining commitment grows correspondingly.

Offset is the AWS-preferred default. Stack is materially better for the buyer. The difference is rarely smaller than 30% of credit value and can exceed the full credit value in cases where the buyer would otherwise have under-burned the commitment anyway.

Worked example

A buyer commits $20M annual EDP. AWS grants $2M MAP credit. The buyer consumes $19M in eligible spend (would have under-burned by $1M without credits).

Under offset treatment: The $2M credit reduces invoices by $2M but counts toward commitment, so the buyer is now at $19M consumed against $20M committed. True-up: $1M owed. Net economic benefit: $1M.

Under stack treatment: The $2M credit reduces invoices by $2M and does NOT count toward commitment, so the buyer remains at $17M consumed against $20M committed. True-up: $3M owed. Net economic benefit: still $0 in this scenario, BUT — and this is the key — the buyer has $3M of headroom for additional eligible spend at full discount, which is a stronger forward-looking position.

The right structure depends on your forward consumption trajectory. Stack is almost always better when growth is strong; offset is acceptable when you are confident of meaningful under-burn risk.

Credit expiration management

AWS credits expire. Different credit types expire on different schedules:

• MAP credits: typically 12–24 months from issue date.
• POC credits: typically 6–12 months.
• Activate credits: 12–24 months depending on the tier.
• Executive-sponsored credits: vary widely, sometimes single-quarter expiry.
• MDF: tied to specific marketing campaigns and use-by-date.

Buyers routinely lose 10–30% of issued credit value to expiration. The fix is a credit ledger maintained alongside the EDP spend tracking system. For each issued credit: source programme, issue date, expiration date, eligible services, current balance, projected consumption rate, and projected expiration shortfall. Reviewed monthly. Escalated when projected shortfall exceeds a defined threshold.

Multi-account credit distribution

By default, AWS allocates credits to the management account of your AWS Organization and lets the credit consume against any linked account's spend. This is convenient but creates two problems:

• Attribution opacity. Business units consuming credit see lower invoices than their actual usage, distorting chargeback math.
• Velocity skew. Credits get absorbed by whichever account spends most aggressively, regardless of whether that account is the one the credit was intended to support.

The fix is targeted credit allocation. AWS supports credit pinning to specific linked accounts, specific services, or specific cost-allocation tags. This requires explicit negotiation at credit issuance — the default is broad consumption.

Practical multi-account credit policies

Three patterns we see work well:

1. Pin to source workload. Migration credits pin to the migrated workload's account or tag. Other accounts cannot consume the credit. This preserves the credit-to-workload attribution that justifies the credit in the first place.
2. Pin to business unit. Credits for a specific BU (often the case with executive-sponsored credits) pin to that BU's accounts via cost-allocation tags. Other BUs cannot inadvertently absorb the credit.
3. Time-window pinning. Credits issued late in an EDP term that are at risk of expiring can be temporarily pinned to high-velocity accounts to ensure full consumption before expiry. This requires monitoring discipline.

Credit provisions to negotiate up front

Most buyers negotiate credit amounts. Fewer buyers negotiate credit terms. The terms matter more than the amount in determining realized economic value.

Stack vs offset language

Explicit contractual language specifying whether credits stack against or offset EDP commitment. Default is offset; negotiate for stack on as many credit types as possible. AWS will resist stacking on MAP credits in particular — push back, as stacking on MAP credits is achievable at mid-market and enterprise scale.

Expiration extension rights

The right to request expiration extensions for unconsumed credit balances, subject to AWS approval. Without this provision, AWS extensions are discretionary and inconsistent. With this provision, they become a documented escalation path.

Successor credit conversion

If the buyer changes EDP terms mid-flight — through M&A, restructuring, or renegotiation — what happens to outstanding credits? Default treatment is opaque. Negotiate explicit conversion rights so credits transfer cleanly into successor agreements.

Service eligibility expansion

Many credits are issued with narrow service eligibility (e.g., "applicable to EC2, S3, RDS only"). Negotiate broader eligibility at issuance, especially as AWS regularly launches new services that would otherwise be ineligible.

Reporting transparency

The right to itemized monthly credit consumption reports, broken out by source credit, consuming account, and service. Without this, internal attribution and audit are extremely difficult.

What to avoid

Treating credits as a discount equivalent. A 10% discount on $20M is $2M of value every year for the term. A $2M one-time credit is $2M of value one time. The discount is generally worth more — do not let AWS account teams substitute credits for structural discount.

Over-committing to absorb credit. If AWS offers a $5M credit conditional on a $50M commitment uplift, do the math carefully. The credit is worth $5M at most; the commitment uplift may be worth $50M of under-burn liability. Common trap, especially with Activate and migration credit packages.

Failing to inventory inherited credits. Buyers who acquire companies regularly inherit AWS credit balances that go unrecorded. Audit at every M&A close: pull credit balances from the acquired company's AWS Organization and integrate them into your tracking ledger.

Treating MDF as an afterthought. Marketing Development Funds are not free — AWS expects co-marketing execution — but for buyers who have the marketing function to support it, MDF is real economic value. We have seen enterprise buyers leave $200K–$500K of MDF unclaimed annually simply by not asking.

Putting it together

A credit-aware EDP negotiation produces materially better outcomes than the standard discount-only conversation. Ask for credits explicitly across all six categories. Negotiate stack treatment wherever achievable. Pin credits to source workloads or business units. Track expiration monthly. And resist the common AWS substitution of credits for structural discount.

If you are negotiating an EDP with significant credit exposure, Contact Us for an independent review of the proposed credit terms.

For broader context, see our coverage of EDP negotiation, EDP private pricing, and EDP spend tracking.

Frequently asked questions.