Partner-filed AWS credits, explained — what the ACE program is, who can file, and why AWS built it this way.

IWhat "partner-filed" actually means structurally

The term "partner-filed AWS credits" refers to a specific submission path inside the AWS Activate program: an AWS Partner Network member enters an opportunity record on your behalf through the ACE portal, rather than you submitting the public self-serve Activate form. The distinction is not cosmetic — the two paths route to different reviewer pools with different credit ceilings.

The self-serve path is the one most founders encounter first. You visit aws.amazon.com/startups/credits/, fill in a public form, attach a deck, and wait. The form lands in what AWS internally treats as the "low-touch" reviewer queue — staffed by junior Activate program coordinators whose job is to process volume and clear simple approvals quickly. The ceiling for self-attested submissions is the $5K Activate Founders tier. The form does not offer a Portfolio option because Portfolio is not available through that route.

The partner-filed path is the one most founders never see. An AWS Partner Network member logs into Partner Central (partner.amazon.com), navigates to the ACE module, and submits a structured opportunity record naming you as the customer. The record carries the partner's attestation — meaning the partner is putting their APN reputation behind the legitimacy of the application. The record lands in a higher-trust reviewer queue staffed by Activate program managers whose ceiling extends to $25K Founders (partner-filed), $50K–$100K Portfolio (partner-filed), $10K–$50K Bedrock POC, and $25K Build for Startups.

The mechanical difference comes down to who is named on the file. A self-attested file says "trust me, I'm a real startup." A partner-attested file says "trust me, plus this Advanced-tier AWS partner is vouching that I'm a real startup and the use case is AWS-compatible." AWS extends additional credit volume against the additional vouch because the partner has something to lose if the application is fraudulent.

The economic flow is also distinct. Self-serve applications cost AWS nothing in partner economics because there is no partner involved. Partner-filed applications trigger partner tier-attribution credit (the partner earns ACE credit toward maintaining their tier), often partner MDF (Marketing Development Funds, distinct from credits to the customer), and in some cases APN Funding allocations. The customer remains outside the payment loop in both cases.

CloudRoute exists at this layer: we route startup inquiries to AWS partners with high ACE approval rates, and the partner handles the ACE submission. The routing decision factors in the startup's stage, region, use case, and stack — and the partner's ACE track record for that exact credit pool. Customer pays $0 because the partner is paid by AWS for the engagement, not by the startup.

IIThe ACE program: gating, eligibility, and what partners see when they log in

ACE stands for APN Customer Engagements. It is the gated portal AWS partners use to register customer opportunities and request engagement-related funding (including the credit pools that fund startup-stage applications). Understanding what ACE actually is helps clarify why partner-filed credits exist as a distinct path.

Access to ACE is restricted by AWS Partner Network tier. The four tiers are Registered, Select, Advanced, and Premier. Registered partners have no ACE submission rights. Select partners have limited ACE rights — they can submit some opportunity types but not the full credit pool catalog; in practice, Select tier partners cannot file Activate Portfolio applications. Advanced and Premier tier partners have full ACE submission rights, including Portfolio, Build for Startups, and Bedrock POC tracks. To reach Advanced tier, a partner must complete ACE training (a multi-module certification), maintain a minimum number of approved opportunities per quarter, hold relevant AWS Certifications across their staff, and pass an annual partner review.

When an eligible partner logs into Partner Central and navigates to the ACE module, they see a workspace that looks similar to a sales CRM — opportunity records arranged by stage (Identified, Submitted, Validated, Approved, Launched, Closed), filterable by funding source, AWS service, customer industry, and geographic region. Each opportunity record has roughly 40 fields. The partner fills the customer-facing fields based on customer inputs (company name, URL, use case, projected AWS consumption), the partner-facing fields based on their own engagement scope (partner role, projected deal size, engagement timeline), and the funding-source field by selecting which credit pool the application targets.

Once submitted, an ACE record progresses through validation states. Initial submission triggers an automated check (company exists, URL resolves, no sanctions matches). Manual review by an AWS reviewer follows — typically a Partner Development Manager (PDM) or an Activate Program Manager (APM) depending on the funding source. The reviewer either approves, requests clarification, downgrades the credit amount, or rejects. Each state change is logged in the ACE record and visible to the partner; the customer does not see ACE directly but receives notification when credits land in the AWS billing console.

Partners also earn tier-attribution credit when an ACE record reaches Approved or Launched state. Tier-attribution credit is the internal AWS metric used to evaluate whether a partner maintains their current tier or qualifies for promotion. A partner who consistently files high-quality ACE records that get approved (rather than rejected or downgraded) builds tier-attribution credit faster than one whose submissions get rejected. This is the structural incentive for partners to vet customer inquiries carefully before submitting — a rejected ACE record is a small but real tax on the partner's tier standing.

IIIThe reviewer queue distinction: low-touch vs. partner-attested

The phrase "self-serve goes one place, partner-filed goes another" is technically true and structurally important. AWS routes the two submission paths to different reviewer pools with different latitude on credit amounts.

The self-serve Activate reviewer queue is the entry-level processing pool. Its staff is trained to clear volume — the daily caseload runs into the hundreds of applications globally. The reviewer's job is to confirm that the submitting company exists, that the use case is AWS-compatible (not a competitor, not a sanctioned entity, not obviously fraudulent), and that the requested credit amount falls within the $1K Builders or $5K Founders ceiling that the self-serve queue is authorized to grant. Anything above $5K is not within this queue's authority. The queue is not authorized to approve Portfolio, Bedrock POC, or Build for Startups regardless of the merits of the application — those funding sources are gated to the partner-attested queue.

The partner-attested reviewer queue (which receives ACE submissions) operates with different authority. Reviewers in this pool are more senior — typically Activate Program Managers with multi-year tenure, sometimes Partner Development Managers handling industry-vertical specialization. Their authority extends to the full Activate funding catalog: $25K Founders (partner-filed), $50K–$100K Portfolio, $10K–$50K Bedrock POC, $25K Build for Startups. They have discretion to approve at the higher end of each range when the application warrants it, and they have discretion to downgrade or reject when it does not.

The two queues do not share authority. A self-serve application cannot be "upgraded" mid-review to a Portfolio award; the reviewer in the low-touch queue is structurally unable to grant Portfolio amounts. If a founder submits the self-serve form and asks the reviewer to upgrade them to $100K, the reviewer's response is a polite redirect to "consider applying through a partner via the ACE program." The two paths are not equivalent at different volumes — they are different paths with different gates.

The trust differential between the queues is the load-bearing mechanism. Self-attested submissions carry only the founder's representations: the company name, the URL, the deck, the use case paragraph. Partner-attested submissions carry the same representations plus an AWS-tier-accredited partner attaching their reputation. The partner has spent quarters (sometimes years) building toward Advanced or Premier tier; they have material APN funding at stake; they face real cost if their attestations turn out to be misrepresentations. AWS extends additional credit ceiling against that additional reputational stake.

One practical implication: founders who submit the self-serve form first and then attempt to escalate to Portfolio later sometimes face a small friction. The reviewer in the partner-attested queue can see the prior self-serve submission, and may ask the partner to explain why the customer is now seeking a higher credit amount. The answer is usually straightforward (the original $5K was a small bridge; the company has since closed a Series-A and the Portfolio application reflects the new stage). But it adds 2–4 days to the application timeline. CloudRoute generally recommends going directly to partner-filed at Series-A rather than starting with self-serve and escalating.

IVWhy AWS built it this way: attestation economics and accountability

The two-queue design is not arbitrary. It is the result of a specific structural problem AWS faced — how to extend $100K credit packages to early-stage startups without creating an unbounded fraud surface — and the partner-attestation mechanic is the solution.

If AWS opened a public form for $100K credit applications and processed them with the same low-touch reviewer pool that handles $5K applications, the fraud rate would be unmanageable. The cost of fraud at the $5K tier is bounded — a fraudulent $5K credit is annoying but small. At $100K per fraudulent submission, the absolute losses scale fast, and AWS would have to invest in much heavier per-application due diligence (corporate verification, founder identity verification, projected-spend modeling, conflict-of-interest checks) to maintain a defensible loss rate. That heavy due diligence would slow legitimate applications to weeks or months.

Rather than absorb that cost directly, AWS designed the partner-attestation mechanic. A partner who is willing to file an ACE record on a customer's behalf is implicitly attesting that the customer is real, the use case is plausible, and the projected spend is reasonable. The partner has skin in the game — they have invested months or years building toward their AWS tier, and a pattern of fraudulent or low-quality ACE submissions costs them tier standing, ACE access, and downstream APN funding. The partner is, in effect, a paid distributed validator of legitimacy.

This is why partners take ACE submissions seriously. A partner who files an obviously bad ACE record (a company that does not actually exist, a use case that is clearly a competitor of AWS, projected spend numbers that are implausible for the company's stage) faces real cost: the reviewer rejects the record, the partner's tier-attribution credit takes a hit, and repeated low-quality submissions trigger a partner review that can result in ACE access suspension or tier downgrade. The partner has every incentive to vet the customer before filing — which is exactly the work AWS would otherwise have to do internally.

For the customer (you), the implication is that the partner you work with is not a passive paperwork conduit. They are doing real vetting before they submit. They will ask about your funding stage, your projected AWS workload, your use case scope, your team size, your AWS account history. Not because the form requires it, but because they need to convince themselves the application is legitimate enough to attach their name to. If a partner declines to file your application, it is rarely because of malice — it is usually because they do not believe the application is likely to be approved, and a rejected application costs them tier credit they would rather preserve.

CloudRoute's routing model is built around this dynamic. We route inquiries to partners who specialize in the customer's profile (stage, region, use case) precisely because a partner who has filed many similar applications has high confidence in the approval probability — which means they are willing to file quickly without extensive back-and-forth, and the customer's wall-clock to credits-approved is shorter as a result.

VWhat is actually in an ACE record: the field-by-field contents

An ACE opportunity record is not a free-form narrative. It is a structured object with roughly 40 fields, of which 15–20 are mandatory for a credit-eligible submission. Knowing the field structure clarifies what the partner needs from you and why.

The partner gathers the customer-facing fields from a brief intake (typically a 30-minute discovery call plus a one-page worksheet). They populate the partner-facing fields from their own engagement scope. The record is then submitted as a single ACE opportunity, and AWS's reviewer evaluates the whole record against the funding source the partner has selected.

• Customer name + corporate URL — your legal entity name and your primary website. The reviewer's automated check confirms the URL resolves and that the entity exists in standard corporate databases (Crunchbase, LinkedIn Company, public filings).
• Use case description — typically 1–3 paragraphs the partner drafts based on your inputs. This is the narrative explanation of what your company does, what AWS services you intend to use, and what the credit will fund.
• Projected AWS consumption — itemized by AWS service category (EC2, RDS, S3, Bedrock, Lambda, OpenSearch, etc.). The reviewer uses this as the primary plausibility check on the credit amount requested.
• Engagement type — typically "Build" (new workload on AWS) or "Migrate" (workload moving from another platform). Credit eligibility differs by engagement type; most Activate credit pools require Build or Migrate.
• Estimated annual deal size — the projected AWS spend after credits are exhausted. This is the field that tells AWS what the customer is worth to them long-term.
• Partner role description — what the partner is contributing to the engagement (architecture review, migration execution, ongoing managed services, etc.). This justifies the partner's involvement and the engagement-funding flowing to them.
• Funding-source request — the specific Activate sub-pool the partner is targeting: Portfolio ($50K–$100K), Build for Startups ($25K), Bedrock POC ($10K–$50K), Founders (partner-filed, $5K–$25K).
• Customer AWS account ID — your existing AWS account number, or a placeholder if the partner is creating a new account as part of the engagement.
• Customer funding stage and most recent round — Series-A, seed, etc., with named lead investor where applicable. This is the primary signal the reviewer uses to confirm Portfolio eligibility.
• Engagement timeline — when the partner expects the work to begin and when the customer expects to be live on AWS.
• Industry vertical — fintech, healthtech, B2B SaaS, e-commerce, etc. Some verticals are routed to specialized reviewers (e.g., regulated industries like healthcare go to a reviewer with HIPAA experience).
• Competing cloud presence — whether you are currently on GCP, Azure, Heroku, or another platform, and whether the engagement is a migration from that platform.

VIThe 8-step checklist the ACE reviewer runs through

AWS reviewers do not write narrative evaluations of each ACE record. They pattern-match against a structured checklist. Knowing the checklist clarifies why some records get approved quickly and why others get downgraded or rejected.

Reviewers process volume — typically 30–60 records per reviewer per week at the partner-attested tier. The checklist exists to make that volume tractable while maintaining loss-rate discipline. The order of the questions is also the order in which the reviewer reads the record.

• 1. Is this a real company? — The corporate URL resolves; LinkedIn page exists; the named founders are findable; the funding history is verifiable through Crunchbase or news mentions. Pass rate at this gate: ~95%. Failures are typically formation-stage entities whose paperwork has not yet propagated to public databases.
• 2. Is the use case AWS-compatible? — The projected workload uses AWS services in volume — not just static asset hosting on S3, but compute (EC2/ECS/Lambda), database (RDS/DynamoDB/Aurora), AI (Bedrock/SageMaker), or specialized services. Reviewers downgrade applications where the AWS service mix is trivially small.
• 3. Is the projected spend plausible? — For a Series-A startup with 10–20 engineers, projected AWS spend of $3K–$15K per month is plausible. Projected spend of $200K per month with no historical AWS account or evidence of comparable workload is not plausible and triggers a credit-amount downgrade.
• 4. Does the partner have a track record? — Partners with consistent ACE approval rates above 70% on similar submissions get fast-tracked. Partners with low historical approval rates or no recent activity get additional scrutiny. This is the field most invisible to founders but is one of the most consequential.
• 5. Is the company already an AWS customer? — Existing AWS customers have visible spend history. A customer at $4K per month for 18 months requesting $100K in credits is straightforward to evaluate — the math works. A customer with no AWS history requesting $100K relies more heavily on the partner attestation to compensate.
• 6. Is the company a competitor? — AWS does not fund competitors. Direct competitors include other cloud providers, AI infrastructure companies whose primary product overlaps with Bedrock or SageMaker, and certain data-platform companies. Approximately 2% of submissions hit this filter, often because the founder did not realize their product overlaps with a recent AWS service launch.
• 7. Does the projected spend justify the requested credit amount? — A $100K credit award is implicit forward investment by AWS in 24+ months of customer relationship. The reviewer checks that the projected annual deal size (post-credit-exhaustion) justifies that forward investment. The threshold is roughly: projected annual deal size should be at least 1.5× the requested credit amount.
• 8. Are there any sanctions or AML flags? — Automated check against US export-control lists, OFAC sanctions lists, and AWS's internal restricted-customer registry. Failure is rare but absolute — an automated flag here results in immediate rejection regardless of the other fields.

VIIHow the partner gets paid (and why the customer pays $0)

The structural reason customer cost is $0 is that partner economics are routed entirely through AWS rather than through the customer. Three distinct payment flows fund the partner: APN Funding, MDF (Marketing Development Funds), and tier-attribution credit. None of these flow through the customer.

APN Funding is the largest flow for ACE-active partners. AWS allocates funding to partners based on the volume and quality of opportunities they bring into the ACE pipeline. A partner who files 20 high-quality ACE records that reach Approved or Launched state in a quarter receives significantly more APN Funding the following quarter than one who files only two. The funding can be used by the partner for engineering staff, sales enablement, customer-facing engagements, or AWS-related infrastructure costs. From AWS's perspective, APN Funding is a direct investment in partner capacity — they are paying partners to maintain the distributed validation function that ACE depends on.

MDF (Marketing Development Funds) is a separate flow tied to joint marketing activity. When a partner co-runs a campaign, event, or content asset that promotes AWS services, AWS reimburses the partner for the marketing spend up to a pre-approved budget. MDF is not directly tied to specific ACE records, but partners with strong ACE pipelines typically qualify for larger MDF allocations because their joint marketing reaches qualified pipeline. The customer is unaware of MDF; it operates between the partner and AWS marketing.

Tier-attribution credit is the internal AWS metric that drives partner tier maintenance and progression. Approved ACE records build tier-attribution credit; rejected or low-quality records erode it. The economic value of tier-attribution credit is indirect but substantial: maintaining Advanced or Premier tier unlocks higher APN Funding allocations, broader ACE access, preferential routing in AWS's customer-referral system, and eligibility for specialized partner programs (Migration Partner, Generative AI Partner, etc.). Partners optimize submission quality precisely because tier-attribution credit compounds over multiple quarters.

The customer is outside all three flows. You do not invoice the partner for any portion of the credits. You do not receive an invoice from the partner for the application work. You do not see MDF or APN Funding amounts. From your perspective, the partner files the ACE record, AWS approves it, credits show up in your billing console, and the partner separately receives funding from AWS that you never see. CloudRoute, in turn, is paid by the partner — a routing commission paid out of the partner's engagement funding, not out of your wallet. The customer-pays-$0 structure is not promotional language; it is the literal outcome of the payment flows.

One important consequence: because the partner is paid by AWS for ACE submissions rather than by you, the partner has no incentive to lock you in via contract clauses, multi-year minimums, or per-month retainers tied to credit access. CloudRoute partners specifically commit to 30-day handover terms — meaning you can move the engagement in-house, to a different partner, or away from AWS at any point without contractual penalty. The credits already in your AWS account remain yours regardless of what happens to the partner engagement.

VIIIWhat CloudRoute does: routing startups to partners with high ACE approval rates

The partner-filed mechanic is the underlying AWS construct; CloudRoute is the routing layer that helps startups find the right partner for their specific situation. The routing decision is non-trivial because ACE approval rates vary significantly by customer profile and partner specialization.

Not all AWS partners are equally good at filing ACE records for every customer type. A partner that specializes in enterprise migrations may have a 90% Portfolio approval rate for Series-B+ migrations but a 50% approval rate for early-stage Bedrock POC applications, because their reviewer relationships and their ACE template library are oriented toward the former. A partner specialized in early-stage AI startups may have inverse performance. Routing a startup to a partner whose specialization does not match the startup's profile increases the probability of rejection or downgrade, which costs the partner tier credit and costs the customer wall-clock time on a retry.

CloudRoute maintains a routing index across several axes: customer funding stage (pre-seed, seed, Series-A, Series-B), region (US-East, US-West, UK, EU, MENA, India, APAC), industry vertical (fintech, healthtech, B2B SaaS, e-commerce, deep tech), AWS service profile (compute-heavy, AI-heavy, data-heavy, edge-heavy), and engagement type (Build vs Migrate). For each axis, we track which partners have demonstrated ACE approval rates above 70% on similar submissions in the trailing 12 months. Routing decisions match the inquiry profile to the partner with the highest demonstrated approval rate for that profile.

The routing operation is not a marketplace where partners bid for inquiries. It is a curated match. When you submit an inquiry to CloudRoute (typically a three-field form: company name, funding stage, use case in one sentence), our admin reviews the inquiry against the routing index and assigns one partner. You do not see five partners in parallel; you see one. The partner you see is the one whose specialization, region, and ACE track record most closely match your profile. If you do not connect with that partner for any reason, we re-route — but we do not run multiple parallel matches because parallel matches create ACE conflicts (two partners filing competing records for the same customer trigger automatic rejection of both).

The customer does not pay CloudRoute. The partner pays CloudRoute a routing commission on closed engagements. The commission is funded out of the partner's engagement-funding pool (APN Funding, MDF) rather than out of any payment from you. The customer-pays-$0 structure extends from the AWS-funds-credit-pool layer through the partner-pays-CloudRoute layer — at no point does the customer enter the payment graph.

This is the reason CloudRoute does not run a typical SaaS pricing model. There is no monthly fee for being on the routing index, no per-inquiry charge, no enterprise tier. The unit economics work because we route enough qualified inquiries to enough partners that the aggregate commission flow funds the operation. From your side, the only thing you do is submit a 3-minute inquiry and take a 30-minute discovery call with the matched partner.

IXThe Portfolio Sub-Program: when your VC can file directly

Partner-filed via ACE is the most common path to Portfolio credits, but it is not the only one. The AWS Partner Network Portfolio Sub-Program allows a small number of venture capital firms to file Portfolio applications directly on behalf of their portfolio companies, bypassing the partner intermediation step.

The Portfolio Sub-Program is structured as a sub-track within the AWS Partner Network. Member VCs receive a limited form of ACE access — specifically, the ability to submit Portfolio-tier credit applications for their portfolio companies. The VC does not become a full AWS partner; they do not provide technical services, run engagements, or receive engineering-related APN funding. Their access is scoped to credit-application submission for the companies in their portfolio.

Approximately 30 venture capital firms have Portfolio Sub-Program access as of 2026. The list includes most of the well-known multi-stage and Series-A-focused firms: Andreessen Horowitz, Sequoia, Bessemer, Greylock, Founders Fund, NEA, Khosla Ventures, Index Ventures, GV (Google Ventures, despite the Google affiliation), Lightspeed, Accel, Insight Partners, Tiger Global, General Catalyst, Y Combinator (for its later-stage portfolio companies; YC seed checks typically go through the YC partnership benefit instead). The list is not public; AWS does not publish it. Founders typically find out whether their VC is in the program by asking the firm directly — and most VCs are aware of whether they have access.

When a VC files via the Portfolio Sub-Program, the application goes through the same partner-attested reviewer queue that handles partner-filed ACE submissions. The credit ceiling is the same ($100K Portfolio). The approval rate is broadly similar. The timeline differs: a responsive VC can submit within 1–2 weeks of the founder asking, and credits typically land 10–14 days after submission. A non-responsive VC may take 4–6 weeks to submit because Portfolio submissions are not the firm's core workflow and they may forget or deprioritize the request.

CloudRoute's practical guidance is straightforward: ask your VC whether they are in the Portfolio Sub-Program and whether they can submit within one week. If yes and they actually do it within that window, take the VC path — there is no marginal benefit to routing through a partner if the VC path is fast and direct. If the VC says no or does not respond within a week, route through a partner via ACE. The two paths reach the same Portfolio credit ceiling on similar timelines; the determining factor is which sponsor (VC or partner) is more responsive in your specific case.

One caveat: a small number of VCs use the Portfolio Sub-Program as a value-added benefit they market to founders, then file applications poorly. A VC that has never actually used their Portfolio Sub-Program access before is not necessarily faster than a partner; they may be slower because they are learning the process on your application. If your VC offers to submit but cannot answer basic questions about the timeline or what fields they will need from you, that is a signal to route through a partner in parallel.

XWhy your AWS account manager cannot grant credits directly

Founders frequently arrive at CloudRoute after having tried to negotiate credits directly with an AWS account manager (AM) or sales rep. The conversation typically ends with the AM offering a small "POC credit" of $5K–$10K and pointing the founder back to the Activate program. The reason is structural: credit grant authority does not live in the sales organization.

AWS account managers are sales staff. Their compensation and performance metrics are tied to revenue from their assigned accounts — typically mid-market and enterprise accounts with existing committed spend. AMs have authority to negotiate commercial terms within established programs: Enterprise Discount Program (EDP) commitments, Private Pricing Agreement (PPA) discount tiers, Marketplace co-sell structures. They do not have authority to grant unfunded startup credits at the $25K–$100K scale, because that authority is held by the Activate program manager pool, which is administratively separate from the sales organization.

The Activate program manager pool is a small team within AWS's startup-focused organization. They review ACE submissions and self-serve Activate applications. They have specific budget authority across the Activate funding sub-pools (Portfolio, Founders, Build for Startups, Bedrock POC) and operate to internal target approval rates and loss rates for each pool. A startup that wants $100K in Portfolio credits is asking for budget from this pool — and the only paths into the pool are the self-serve Activate form and ACE submissions.

This is why AM conversations with unfunded startups typically end with a $5K–$10K offer. The AM is offering what they have authority to grant directly — a small POC credit allocated from their account-specific discretionary budget — and pointing the founder toward the Activate program for anything larger. The AM is not being unhelpful; they are accurately describing the authority structure. The founder who interprets the small POC offer as "all AWS will give me" misreads the situation.

Founders sometimes try to escalate up the AWS sales hierarchy — talking to a sales director, a regional VP, or an industry lead — under the assumption that someone senior enough must have credit grant authority. This is also structurally incorrect. Sales seniority does not unlock Activate budget; the budget lives in a different organization. Senior AWS sales staff can sometimes make introductions to the Activate program team, which is helpful when the founder does not have a partner relationship, but the introduction still routes the conversation back to either self-serve or a partner-filed ACE submission.

The practical implication is that founders who are deep in conversations with AWS sales should ask their AM directly: "Can you connect me to an AWS partner who handles ACE submissions for Series-A startups?" The AM's response is often quick and helpful — they have a list of partners they refer to regularly. Alternatively, route through CloudRoute and bypass the AM relationship for the credit-application leg, while keeping the AM engaged for downstream commercial conversations (EDP negotiation post-Series-B, for example).

XITimeline mechanics: why partner-filed Portfolio takes 11–18 days and Bedrock POC takes longer

The timeline for partner-filed credit applications is not uniform across funding sources. Portfolio applications typically take 11–18 days from partner submission to credits landing in the AWS billing console. Founders (partner-filed) takes 7–10 days. Bedrock POC takes 14–28 days. The differences are driven by which reviewer pool handles each funding source.

Portfolio applications route to the core Activate program manager pool. This pool is staffed to a target turnaround of 8–14 business days per record, with caseload smoothing across reviewers. Approximately 70% of Portfolio applications are approved on first pass without clarifying questions; the remaining 30% trigger one round of clarification (typically about projected spend itemization or use case scope), which adds 3–5 business days. The 11–18 day envelope captures both first-pass approvals and one-round-clarification approvals; outright rejections are rare and typically resolve within the same window.

Founders (partner-filed) applications route to a faster sub-queue within the same pool. The Founders tier is lower-stakes (ceiling $25K versus Portfolio $100K), so the review depth is correspondingly lighter. First-pass approval rates are higher (~85%), and turnaround typically lands at 7–10 days. Founders applications are sometimes used as a quick first credit drop for startups that need cloud spend covered immediately while a Portfolio application processes in parallel — though stacking Founders with Portfolio is not always permitted depending on the use case overlap.

Bedrock POC applications route to a Bedrock-team-adjacent reviewer pool. This pool is structurally slower than the core Activate pool because (a) it is smaller, staffed by reviewers with specific Bedrock-team coordination requirements, and (b) the review checklist is longer — the reviewer evaluates not just the standard 8-step ACE checklist but also the Bedrock-specific POC plan (chosen model, eval methodology, budget itemization, POC timeline). The additional review depth typically adds 4–7 days to the timeline, putting Bedrock POC at 14–28 days from submission to credits applied.

Build for Startups applications route through the core Activate pool and run on a timeline similar to Portfolio (14–21 days). Build for Startups is often filed concurrently with Portfolio because the use case is additive and the paperwork overlaps; filing both at once does not extend either timeline materially.

A practical observation from CloudRoute's routed-pipeline data: the timeline is most predictable when the partner has filed many similar applications recently. A partner whose last 10 Portfolio applications all approved in 12–14 days is likely to land your application in the same window. A partner who has filed only a few applications in the past quarter may take longer because the reviewer relationship is less established and the partner's ACE template library may need adjustment for your specific profile. CloudRoute's routing decision factors in recent partner activity precisely because it materially affects the customer's wall-clock to credits.

XIICommon misconceptions founders arrive with

The partner-filed credit mechanic is structurally specific, and the surface-level descriptions in most "how to get AWS credits" guides leave room for several persistent misconceptions. Clarifying them upfront saves wasted application cycles.

These are the misconceptions CloudRoute hears most often during inquiry triage. Each one points to a different aspect of the mechanic where intuition tends to diverge from how the program actually works.

• "I can negotiate credits directly with my AWS sales rep." — Credit grant authority does not flow through sales reps. AMs can offer small POC credits from their discretionary budget (typically $5K–$10K) but cannot grant Activate Portfolio amounts. The Activate program manager pool holds Portfolio budget authority; the only paths to that pool are self-serve Activate forms and partner-attested ACE submissions.
• "Partner-filed means the partner pays me." — The partner is an intermediary, not a funder. AWS funds the credit pool; the partner files the application; AWS approves; credits land in your AWS billing console. The partner is paid by AWS through APN Funding, MDF, and tier-attribution credit — not by transferring funds to you and not by invoicing you.
• "I need to already be on AWS to qualify." — No. Partner-filed credits work for greenfield AWS accounts. The application form has a field for AWS account ID, but the partner can submit with a placeholder and the account can be created during the engagement. Roughly 25% of Series-A applications CloudRoute routes are greenfield AWS situations; the credits land in the new account just as they would in an existing one.
• "The partner will lock me into a long-term contract." — Not in the CloudRoute model. Partners commit to 30-day handover terms; you can take the work in-house, switch partners, or move off AWS at any point without contractual penalty. The credits in your AWS account remain yours regardless of what happens to the partner engagement.
• "Partner-filed is slower than self-serve." — Not for the credit amount you actually want. Self-serve is fast (3–7 days) but capped at $5K. Partner-filed Portfolio is 11–18 days for $100K. On a credit-per-day basis, partner-filed is roughly 12× faster than self-serve at the Portfolio tier.
• "I can apply through multiple partners in parallel to hedge my bets." — Do not do this. Two partners filing competing ACE records for the same customer trigger automatic rejection of both records and create a partner-side conflict that takes weeks to resolve. Choose one partner per credit application. If a partner is not responsive, withdraw the engagement and route to a different one — but only one ACE record per customer at a time.
• "My credits will only work for the specific use case I described." — Activate Portfolio credits are not earmarked to a specific use case. They burn down against any covered AWS service freely (excluding Marketplace SaaS purchases and AWS Professional Services). Bedrock POC credits are the exception — they are earmarked to Bedrock workloads. Build for Startups credits are loosely tied to the project described in the application but are not strictly earmarked.

XIIISelf-serve vs. partner-filed vs. VC-filed — side by side