AWS credits are not one program — they are five or six overlapping pools, and they were designed to combine. The catch is that they only combine cleanly when each pool funds a genuinely distinct workload. This is the definitive guide to the legal stack: which programs add, which collide, the order to file them in, the realistic ceilings ($150K for most, $300K+ for AI-first), and the precise mistakes that get the secondary tracks silently zeroed out.
Almost every founder treats "AWS credits" as one number you either get or do not get. That framing is why most companies leave money on the table — and why the few who over-file get rejected. The accurate model is a stack of distinct, separately-funded pools.
AWS runs at least five credit programs that a single company can hold simultaneously: Activate (the Builders / Founders / Portfolio ladder), Build for Startups (an ISV-build incentive), the Bedrock / generative-AI proof-of-concept pool, the Migration Acceleration Program (MAP), and accelerator- or VC-attached credit benefits. Each has its own funding source inside AWS, its own owning team, and its own approval logic. They were architected to coexist — AWS would rather fund five distinct workloads than cap a growing customer at one number.
That is the good news and the entire trap in one sentence. Because the pools are distinct, they add up. But because they are reviewed by different people against different criteria, filing for several of them with the same justification reads, to AWS, as one workload being counted multiple times. The reviewer does not reject the whole stack — they approve the anchor and silently downgrade the rest. The founder sees "$100K approved" and never learns the extra $50K was on the table and lost on a technicality.
So "how do I stack AWS credits to the maximum" is really two questions wearing one coat. First: which pools is my company structurally eligible for? Second — and this is the one that decides the dollar figure — can I describe a genuinely separate workload for each pool I file? The rest of this guide is about answering the second question correctly, because that is where the money is won or lost.
One reframing before the mechanics. The ceiling is not set by how aggressively you ask. It is set by how much distinct, AWS-shaped work you can credibly point at. A company with one product and modest infrastructure has a real ceiling around $100K no matter how many forms it submits. A company with a core platform, a separable data or media pipeline, and a real generative-AI initiative has three legitimate stories to tell — and that is what reaches $150K and beyond.
Before the rules of combination, the components themselves. Each of these is a real, separately-funded AWS program with its own ceiling and its own owner. Knowing what each one is for is what lets you assign workloads to them without overlap.
Read each entry as "what AWS believes this money is buying." The reviewer for each pool is checking that your application matches that belief. Stacking works when your workloads happen to map onto five different beliefs.
What it funds: general-purpose AWS infrastructure for an institutionally-backed startup — compute, database, networking, storage, observability. This is the big, flexible base layer.
Ceiling: $100K is the typical award; the range runs $25K–$100K and is discretionary. There is no public form — it is filed by a VC with Portfolio Sub-Program access or by an AWS partner via the ACE (APN Customer Engagements) program.
Role in a stack: the anchor. File this first; everything else layers around it. Because it covers "general infrastructure," it is also the pool most likely to absorb a second workload by accident — which is exactly why the additive tracks have to be scoped narrowly against it.
What it funds: a specific, buildable workload on a defined set of AWS services — a data pipeline, a media-processing system, an analytics layer, an event-driven backend. AWS treats it as an ISV-build incentive: credits in exchange for building real product on AWS services.
Ceiling: typically +$25K at Series-A scale, awarded against a named project.
Role in a stack: the first additive layer. It only survives review if the project it names is clearly not the same thing Portfolio is already funding. "We run on AWS" is not a Build for Startups workload — that is Portfolio. "We are building a video transcoding pipeline on MediaConvert and Elemental" is.
What it funds: a generative-AI proof of concept on Amazon Bedrock — model inference, a RAG system, an agent, an evaluation harness — with Bedrock as the inference backbone.
Ceiling: $10K–$50K depending on the substance of the POC. At Series-A the common approval is $25K; the $50K end requires a serious, well-scoped AI initiative.
Role in a stack: the second additive layer, and the one with the most upside. A real AI workload is the easiest distinct story to tell because the services (Bedrock, model access) are visibly different from a general infrastructure footprint. This is also the pool that, scaled up via the GenAI track, pushes a stack past $300K.
What it funds: moving an existing workload onto AWS from another cloud or on-premise. Credits are tied to the migration itself across Assess → Mobilize → Migrate phases.
Ceiling: roughly 25% of projected migration cost at Mobilize, up to ~50% at Migrate. For a substantial migration this is $25K–$200K+; it is not a fixed number but a percentage of real work.
Role in a stack: a parallel track rather than a simple add-on. MAP funds the act of migrating; Activate funds running the result. They legitimately coexist because they fund different phases of the same journey — but only when there is a real migration, not a greenfield build dressed up as one.
What it funds: the standing credit benefit attached to an accelerator (Y Combinator, Techstars, and similar) or built into a VC's portfolio perks. Usually $5K–$25K.
Ceiling: varies by program; commonly $5K–$25K.
Role in a stack: mostly baseline, not addition. These typically draw from the same Activate Founders pool that the self-serve and Portfolio tracks already touch. Treat them as credits you have likely already consumed or that fold into Portfolio rather than sitting on top of it. The honest math counts them once, not twice.
This is the load-bearing section. The difference between a $150K stack and a $100K stack with two silent rejections is a single principle that AWS applies consistently across every credit pool: one workload, one funding source.
State it plainly: AWS funds workloads, not companies, and it will not fund the same workload twice. Every stacking rule below is a corollary of that sentence. The reviewer for each pool is, in effect, asking "has AWS already paid for this exact thing under another program?" If the answer is yes, that pool is downgraded — usually to zero — while the anchor stays approved.
The practical test, the one a partner runs before filing anything beyond Portfolio, is the separate-workload test: can you describe this pool's workload using different AWS services, a different objective, and a different owner than the workload Portfolio is already funding? If yes, it stacks. If you find yourself reusing the same paragraph with the service names swapped, it does not — and filing it anyway risks a flag, not just a zero.
Three concrete patterns make this real:
A second rule sits underneath the first: projections have to be plausible per pool. Each application carries a projected-spend figure, and the reviewer sanity-checks it against your stage and headcount. A ten-engineer Series-A projecting $200K/month of consumption to justify a larger stack does not get a larger stack — it gets the projection marked implausible and the discretionary awards trimmed downward. The stack grows by adding believable workloads, never by inflating one.
The reason this matters so much for stacking specifically: the additive tracks are discretionary, and discretion runs through credibility. The anchor (Portfolio) usually clears on company quality alone. The +$25K and +$50K layers are judgment calls, and the judgment is "does this company actually have this second workload?" Everything you do to make each workload concrete and separately-owned is what protects the marginal credits.
Stacking is not just which programs you combine but the sequence you file them in. The order is not arbitrary; it follows from how AWS reviewers read a set of related applications and from which awards are anchors versus judgment calls.
The governing idea: establish the anchor, then layer additive tracks against it, then treat baseline credits as already-counted. Filing out of order — leading with a small POC, or submitting the additive tracks before the anchor is in review — weakens the narrative and invites the double-counting question prematurely.
File Activate Portfolio first, scoped to general infrastructure for the core product. This is the largest single pool and the one most likely to clear cleanly. It establishes the baseline the reviewer reads everything else against, and it sets the "general infrastructure" boundary so the additive tracks can be scoped outside it.
With the anchor defining "general infrastructure," file Build for Startups and the Bedrock POC against workloads that sit clearly outside that boundary — the media pipeline, the AI agent, the analytics layer. File them close together (often the same week) so they read as a coherent, honest portfolio of distinct initiatives rather than an afterthought tacked on months later. Each one names its own services and its own objective.
If a substantial migration is genuinely happening, file MAP as a parallel track — it funds the migration phases while Portfolio funds the running result. Do not manufacture a migration to unlock MAP; a greenfield build relabeled as a migration collapses into collision with Portfolio and risks the whole stack's credibility.
Accelerator and self-serve Founders credits are baseline. If you already hold a YC or self-serve $5K, it folds into the Activate lineage rather than adding to Portfolio — do not file it again expecting +$5K on top. Counting it twice is a double-count against yourself, and it makes the rest of the stack look padded.
File the biggest gated pool first as the anchor (Portfolio), layer the additive tracks against clearly separate workloads in the same window, add MAP only against a real migration, and treat accelerator / self-serve credits as already-spent baseline. Order protects the marginal credits; disorder invites the double-counting question.
Founders read "$1M in AWS credits" headlines and anchor on the wrong number. The realistic ceiling for a stack depends entirely on how much distinct, AWS-shaped work the company can point at. Here is the honest distribution.
There are three bands, and which one you are in is set by your workloads, not your ambition. Treat the figures as the credible center of each band, not a promise — every award is discretionary.
Band 1 — single-product company: ~$100K. One product, general infrastructure, no separable second workload and no real AI initiative. The honest ceiling is the Portfolio anchor alone, ~$100K. Filing additive tracks here is what produces the silent $0 downgrades. The right move is to take the $100K cleanly and revisit when a second workload genuinely exists.
Band 2 — multi-workload company: ~$150K. A core platform plus a genuinely separable workload (a data or media pipeline) plus a real Bedrock POC. This is the canonical $150K stack — $100K Portfolio + $25K Build for Startups + $25K Bedrock POC — and it is achievable for a large share of Series-A companies because most have more than one distinct thing running than they initially realize.
Band 3 — AI-first or large-migration company: $300K+. Two paths reach this band. The generative-AI path: a substantive AI product where the Bedrock POC scales toward $50K and the GenAI track (the competitive accelerator) contributes a much larger award on top of a Portfolio base — total credit pools in the several-hundred-thousand range for selected companies. The migration path: a substantial MAP migration ($200K+ at 25–50% of migration cost) running parallel to a Portfolio base. Both require real substance; neither is reachable by filing more forms for the same work.
No amount of aggressive filing moves a single-product company past ~$100K. The lever that moves the ceiling is distinct, credible, AWS-shaped workloads — a separable pipeline, a real AI initiative, a genuine migration. $150K is the typical multi-workload outcome; $300K+ belongs to companies with real generative-AI substance or a substantial migration.
| Pool | What it funds | Typical ceiling | Filed how | Stacking role |
|---|---|---|---|---|
| Activate Portfolio | General infrastructure for the core product | $100K | Partner via ACE / VC sub-program | Anchor — file first |
| Build for Startups | A specific buildable workload (pipeline / analytics) | +$25K | Partner-filed against a named project | Additive — needs a distinct workload |
| Bedrock / GenAI POC | A generative-AI proof of concept on Bedrock | +$10K–$50K | Partner-filed against the AI initiative | Additive — biggest upside |
| MAP | Migrating an existing workload onto AWS | 25–50% of migration cost | Partner via APN, phased | Parallel — needs a real migration |
| Accelerator / VC credits | Standing program / portfolio benefit | $5K–$25K | Program-attached / self-serve | Baseline — count once, not on top |
Every failed stack fails in one of a handful of recognizable ways. None of them trigger a loud rejection — the anchor is approved and the extras quietly vanish — which is why founders repeat them. Here is the honest list.
Read these as the inverse of the separate-workload test. Each one is a way the additive tracks end up describing work AWS has already funded under the anchor, or work the company cannot credibly claim at all.
Abstract rules are easy to nod at and hard to apply. Here is the full reasoning for a representative multi-workload company, end to end, so the separate-workload test is concrete.
The company: a Series-A B2B SaaS, roughly fifteen engineers, already on AWS. It runs a core application platform, ingests and processes a meaningful volume of customer data through a separable pipeline, and is starting a customer-facing AI assistant.
Step 1 — anchor. Portfolio is filed first for general infrastructure: the application servers, the primary database, networking and observability. Scope is deliberately "the core platform" so the boundary is clear. Expected award: $100K. This is the layer that clears on company quality.
Step 2 — first additive layer. The data pipeline is a genuinely separate workload — different services (streaming ingestion, transformation, an analytics store), a different objective (data processing, not serving the app), arguably a different owner (data engineering, not platform). It is filed as Build for Startups against that named pipeline. Because it passes the separate-workload test, it adds rather than collides. Expected award: +$25K.
Step 3 — second additive layer. The AI assistant runs on Bedrock — a visibly different service footprint and a clearly distinct objective. It is filed as a Bedrock POC against that initiative. This is the easiest distinct story to tell precisely because the AI services do not overlap with the general infrastructure or the data pipeline. Expected award: +$25K.
Step 4 — baseline. The company holds a $5K self-serve credit from a year ago. It folds into the Activate lineage; it is not re-filed as an addition. Honest total counts it once, already inside the Portfolio picture.
The result: three applications, three distinct workloads, three separate service footprints, filed in the same window by one partner. Expected combined pool: $150K. Nothing is downgraded because nothing is double-counted. Had the same company filed all three against "running our SaaS on AWS," it would have landed at $100K with two silent $0s — the same effort, $50K less credit.
The band a company lands in is decided before any form is filed — by how many distinct, credible, AWS-shaped workloads it can actually point at. The dollar figure follows the workloads, not the ambition.
| Variable | ~$100K (single workload) | ~$150K (multi-workload) | $300K+ (AI-first / large migration) |
|---|---|---|---|
| Distinct workloads | One | Two–three | Three+ incl. substantial AI or migration |
| Pools in the stack | Portfolio only | Portfolio + Build + Bedrock POC | Portfolio + GenAI track, or Portfolio + large MAP |
| What carries the award | Company quality (anchor) | Distinct workload narratives | AI substance / real migration scale |
| Bedrock POC role | Often none | +$25K against an AI initiative | +$50K and/or GenAI accelerator on top |
| Most likely failure mode | Over-filing → silent $0s | Double-counting one layer | Manufacturing substance that is not real |
| Honest move if you are below it | Take $100K, revisit later | Name the second workload precisely | Build the real AI/migration first |
Situation: The founder had self-filed a single Activate application "to run on AWS" and been approved at $100K — and assumed that was the ceiling. They did not realize their data pipeline and their new AI assistant were two additional, distinct workloads that AWS funds under separate programs. They were about to leave $50K unclaimed.
What CloudRoute did: Routed within a day to a UK partner with ACE access. The partner ran the separate-workload test on a short call, confirmed the pipeline (Build for Startups) and the assistant (Bedrock POC) were genuinely distinct from the core platform, and filed all three in the same week — Portfolio scoped to general infrastructure, Build for Startups against the named pipeline, the Bedrock POC against the assistant. The pre-existing self-serve $5K was counted as baseline, not re-filed.
Outcome: Combined credit pool approved within ~16 days: $150K, with no track downgraded — because each application described a distinct workload. CloudRoute's commission was paid by the partner out of AWS engagement funding; the customer paid $0.
pools stacked: 3 · downgrades: 0 · credits secured: $150K (up from $100K self-filed) · cost to customer: $0
CloudRoute runs the separate-workload test, then routes you to a vetted AWS partner who files each application against a distinct workload via ACE. Each layer earns its credits; nothing gets zeroed. Customer pays $0; AWS funds.