AWS Activate Credits: What You Actually Get, and How to Qualify

Two tiers, and the gap between them is the whole story

Activate splits into a Founders package and a Portfolio package. Founders is the self-serve route: you apply directly, no investor is involved, and the credit lands against your account almost immediately. Portfolio carries the six-figure ceiling everyone has heard about, and it is only reachable if AWS already recognises the accelerator, incubator, fund or startup programme behind you.

Recognised is doing real work in that sentence. AWS maintains a roster of partner organisations, each holding its own allocation and its own member portal. Your accelerator either sits on that roster with an Activate organisation ID to hand out, or it does not, and no amount of arguing your traction will move you across the line.

The practical read is simple. Bootstrapped and building now, apply for Founders today, because it costs an hour and the credit is real. About to join an accelerator or close a round with a participating fund, wait and go through them, because the two tiers are not in the same league and you only get one claim per entity.

Eligibility is checked against your account, not your pitch

There is no diligence in the usual sense. Nobody reads a deck, nobody asks for revenue, nobody checks a cap table. What AWS does check is mechanical: the account you nominate must not have received Activate credit before, your company should be young rather than established, and your email should sit on your own domain rather than a free mailbox.

One credit per company is the rule that catches people. If a co-founder claimed Founders credit on a personal AWS account during a weekend project, that entity is spent. Nominate a clean account created for the business, ideally the management account of an AWS Organizations setup, so the credit sits where your production billing will eventually consolidate.

Company age gating is the other quiet filter, and it works against you in an unusual direction: the longer you sit on the idea before applying, the closer you drift to the cut-off. That argues for registering the entity and claiming the credit in the same quarter you start building, rather than years into a side project that never quite launched.

What the credits absorb, and what still hits your card

Credits are applied automatically against your monthly bill before your payment method is charged, service by service, with no action from you. They cover the bulk of what an early product actually runs on: compute, storage, managed databases, networking and the usual serverless pieces. For most teams that is effectively the entire infrastructure line.

What they do not absorb is the part people budget wrong. Anything bought through AWS Marketplace, upfront payments on reserved instances or savings plans, elevated support tiers and tax all sit outside the credit and land on the card. So does anything billed by a third party whose product merely happens to run on AWS.

The consequence is that a credited account still produces an invoice most months, usually small, occasionally not. Turn on a billing alarm and a budget the day the credit lands, because the balance drains silently and the first signal that it has gone is a full-price invoice nobody planned for.

• Third-party software bought through AWS Marketplace
• Upfront payments on reserved instances and savings plans
• Support tiers above the basic plan
• Tax, depending on your billing jurisdiction
• Anything invoiced by a vendor that is merely hosted on AWS

Timing beats size, every time

Credits carry a fixed window from the date they are issued, and unused balance does not roll over. That single mechanic decides whether the programme is worth anything to you. A large credit claimed at idea stage, burned at a trickle while you are still designing screens, expires having paid for almost nothing you could not have run on the free tier.

So sequence the application against your actual burn. Apply when you have a workload that costs real money: a live product with users, a training run, a data pipeline, a migration off someone else's platform. Until then the free tier covers you, and the credit keeps its full value for the month you genuinely need it.

The counter-argument is that programmes change and eligibility windows close, so claiming early at least guarantees you have something. That risk is real, but a credit that expires unused is worth exactly the same as one you never claimed, and the window you are protecting against is usually company age, which you can fix by applying the quarter you start building.

How to actually apply

The Founders application is short: company name, a URL, a one-line description of what you are building, and your AWS account ID. There is no pitch, no financials, no interview. Approval is largely automated and the credit appears in your billing console shortly afterwards, tied to that account and no other.

Portfolio runs the other way round. Your accelerator, incubator or fund holds the allocation and issues you an Activate organisation ID, which you enter during the application. Ask them for it before you touch the form. Applying cold drops you into Founders by default, and there is no retroactive upgrade once the entity has been credited.

That ordering point is worth repeating, because it is the most expensive mistake available in this programme. Founders credit claimed in month one, followed by acceptance into an accelerator in month four, means the larger allocation your programme was holding for you is now unreachable. If a partner programme is plausibly in your near future, wait for it.

Do not architect for credits you will not have

The failure that costs more than the credit is worth is designing infrastructure you cannot afford once the balance reaches zero. Credits make managed services feel free, so teams reach for the expensive managed option everywhere, and an architecture that looked sensible while credited becomes an unpayable monthly bill the quarter after it lapses.

Model the uncredited bill before you commit. Take your current monthly consumption, project it at the scale you expect in a year, and ask whether that figure is one you would sign off with your own money. If it is not, the credit is subsidising a decision you would not otherwise make, and the reckoning is simply deferred.

For a straightforward web application, a platform host is frequently cheaper in practice than credited AWS, because the credits run out and the operational overhead does not. Vercel, Supabase and Neon each cover a slice of what you would otherwise assemble by hand, and each runs its own startup programme, so the comparison is credited against credited rather than credited against list price.

Stack it, and apply everywhere else too

None of these programmes carry an exclusivity clause. Google runs an equivalent cloud programme with a higher published ceiling and its own partner route, covering Firebase as well as raw compute, and if your workload is portable there is no reason not to apply to both and take whichever approves first. Nothing in either agreement asks you to pick a side.

Cloud credits also arrive bundled through routes that have nothing to do with cloud providers. Incorporation services and startup banking products ship partner perk bundles that include infrastructure credits alongside everything else a new company buys, and those stack on top of anything you claim directly. Brex and Stripe Atlas are the two most commonly worth checking first.

Work through the list in one sitting rather than one application at a time. Most of these programmes gate eligibility on company age, so the window in which you qualify for all of them at once is narrow and it opens the day you incorporate. The directory tracks the current SaaS and infrastructure offers, including the cloud, database and platform programmes most early teams end up stacking, with the live terms attached.