AWS POC funding for Amazon Bedrock is a separate credit pool from Activate Portfolio. It funds $10K–$50K of Bedrock inference plus tightly-coupled supporting infrastructure during a 60-day proof-of-concept window. The pool is partner-filed only via the ACE program; a documented POC plan covering model selection, evaluation methodology, and projected budget is required. This page is a mechanism reference: what the track is, where the money comes from, how the POC plan is structured, why the credits are earmarked, and the 6-month checkpoint AWS uses to enforce real execution.
Bedrock POC funding is structurally distinct from the Activate Portfolio credit pool that most founders think of as "AWS startup credits." Understanding the separation is the first step in understanding why the application paperwork differs and why a startup with Portfolio credits can apply for Bedrock POC funding on top.
Activate Portfolio is the general-purpose credit pool: $1K to $100K of credits applied to the AWS account that can be spent on any AWS service the startup runs. EC2, RDS, S3, CloudFront, Lambda, ECS — any service. The credits are not earmarked. The Portfolio tier the startup qualifies for depends on funding stage, accelerator affiliation, and the partner record filed via ACE.
Bedrock POC funding is the Bedrock-earmarked credit pool: $10K to $50K of credits applied to the AWS account that can only be spent on Amazon Bedrock and a defined set of tightly-coupled supporting services. The credits are earmarked at the billing-promotion level — AWS billing system tracks consumption against Bedrock-eligible service codes and applies the promotional balance only to qualified line items. Non-eligible consumption (EC2 outside of the orchestration role, RDS, general-purpose data warehouse charges) does not draw down the Bedrock POC balance.
The two pools sit alongside Build for Startups, which is the partner-labor and distinct-workload credit pool ($25K typical). The three pools together — Portfolio + Build for Startups + Bedrock POC — form what CloudRoute partners refer to as the standard $150K stack for an AI-native startup. Each pool has its own application paperwork, its own approval criteria, and its own consumption rules. A startup can be approved for one pool, two pools, or all three depending on the workload profile.
The reason Bedrock POC funding warrants its own page on a credit reference is that the application paperwork is meaningfully different from Portfolio. Portfolio applications are short and largely administrative. Bedrock POC applications require a documented POC plan with specific components — a deliverable the founder produces in collaboration with the AWS partner. The components and what AWS reviewers look for are the substance of this page.
The economic logic behind Bedrock POC funding is worth understanding because it explains why the pool is earmarked, why partner-filing is the only mechanism, and why AWS pays close attention to the use-case framing.
Amazon Bedrock is the managed inference platform AWS launched in 2023 to host foundation models from Anthropic (Claude family), Meta (Llama family), Mistral, Cohere, AI21, and Amazon's own Titan and Nova models. The platform is a competitive response to OpenAI's direct API, Google's Vertex AI, Azure's OpenAI Service, and the model-provider direct APIs (Anthropic API direct, Mistral direct, Cohere direct).
The foundation-model providers — Anthropic, Meta, Mistral, Cohere, AI21 — have a strategic interest in driving adoption of their models through Bedrock specifically rather than through their own direct APIs or through competing managed-inference platforms. Bedrock adoption means: enterprise customers picking the Bedrock-hosted version of the model instead of the OpenAI alternative; startups committing to the Bedrock-hosted version during the formative period when inference-platform decisions are being made; the foundation-model provider receiving the consumption revenue through the AWS commercial relationship.
To drive Bedrock adoption, the foundation-model providers commit marketing dollars to AWS — funds allocated to programs, content, partnership activities, and credit pools. AWS converts a portion of those marketing dollars into Bedrock POC funding pools allocated to startups via the AWS Activate program. The pools are not unlimited; they are sized to the marketing-budget commitments from the foundation-model providers each fiscal year. When a startup's partner files a Bedrock POC opportunity record and the application is approved, the credits draw against this pool.
The earmarked nature of the credits maps directly to this funding source. The marketing dollars came from Anthropic, Meta, and Mistral to drive adoption of Bedrock-hosted versions of their models. AWS would not honor the marketing-budget commitment by allowing the credits to fund general EC2 or RDS workloads. The credits can fund Bedrock inference and the tightly-coupled supporting services that exist solely to make the Bedrock workload functional — vector search, orchestration, logging — but not the broader AWS infrastructure. The partner-filed-only mechanism exists because the foundation-model marketing dollars flow through AWS's partner program rather than through direct AWS-to-customer credit issuance.
The eligibility profile for Bedrock POC funding is narrower than Activate Portfolio in some respects (the workload must be Bedrock) and broader in other respects (no funding-stage gate). The combined profile is straightforward.
The required conditions for a startup to be eligible for Bedrock POC funding are: (1) a current or planned Bedrock inference workload — the POC plan must describe a use case that runs through Amazon Bedrock; (2) an AWS account where the credits will be applied; (3) standard AWS Activate eligibility — the startup is not in a restricted industry classification, is not a direct competitor to AWS managed services, and is not subject to other AWS Activate exclusions; (4) a willing AWS partner who will file the POC opportunity record through the ACE program; (5) a documented POC plan containing the required components described later in this page.
The conditions that are notably not required are: a specific funding stage — Bedrock POC funding has no minimum funding-stage requirement, unlike higher Portfolio tiers that require Series-A or Generative AI Accelerator that targets pre-Series-B; an LLC or formal company structure beyond the standard Activate baseline — pre-incorporation founders are typically asked to incorporate before credits apply but the substantive eligibility question is the workload, not the corporate form; existing AWS spend or migration scope — the POC pool does not require a migration story or any prior AWS consumption; team-size minimums — solo founders with credible POC plans are eligible.
Eligibility constraints that distinguish Bedrock POC funding from Generative AI Accelerator: the POC pool does not require the product to be AI-first. An AI-augmented product where Bedrock powers one feature (a specific summarization workflow, a particular extraction pipeline, a single agent workflow) is eligible for Bedrock POC funding even though the overall product would not qualify for the accelerator. The reverse is also true: an AI-first product can be approved for Bedrock POC funding even if it has not yet been accepted into the accelerator. The two tracks are independent.
The use case must be one AWS classifies as a legitimate Bedrock POC rather than a direct competitive workload. AWS reviewers reject use cases framed as direct competition to Anthropic, Meta, or AWS's own Bedrock-adjacent services — for example, a startup explicitly building an inference-platform alternative to Bedrock and applying for Bedrock POC funding to evaluate the incumbent would be rejected. Inference-routing platforms, foundation-model-distribution platforms, and direct Bedrock-competitor products are not eligible. Workloads consuming Bedrock for their own product functionality are eligible.
The POC plan is the substantive deliverable in a Bedrock POC funding application. The plan is a single document — typically 2 to 4 pages — that the partner submits along with the ACE opportunity record. The contents are not freeform; AWS reviewers look for specific components and approve, downgrade, or reject based on what is present.
The five required components of a Bedrock POC plan are: a use case description, a selected model with rationale, an evaluation methodology, a projected inference budget, and a defined POC window. Each component has a specific shape AWS reviewers recognize. Plans that contain all five components in the recognized shape are approved at the $25K typical or $50K ceiling. Plans missing components or substituting vague placeholders are downgraded to the $10K floor or rejected.
The use case description is a one-to-two paragraph statement of what the Bedrock workload is meant to do, written at the level of product specificity rather than category-level abstraction. Examples that pass review: "Extraction of structured fields from supplier invoices ingested as PDFs; the extracted fields populate the accounts-payable ledger; the workflow runs on 500–2,000 invoices per day with a target accuracy of 95% on the primary field set." "Conversational search over the customer's internal product documentation, deployed as a Slack bot, with a target answer-rate of 80% on user questions matched against a 50,000-document corpus." Examples that fail review: "Exploring how generative AI can improve our product." "Building a chatbot." "Evaluating LLMs for various use cases."
The selected model with rationale is a single named model from the Bedrock catalog with a stated reason for the selection. The rationale must be specific to the use case. Examples that pass review: "Claude Sonnet 4 because the use case requires structured extraction from multi-page documents where Sonnet 4's context window and instruction-following both match the requirement, and Haiku underperforms on the held-out evaluation set by 14 F1 points." "Llama 3 70B because the deployment must run inside the customer's VPC with open-weights regulatory requirements and the team has prior fine-tuning experience with the Llama family." "Mistral Large because the deployment serves European customers with data-residency requirements and the model balances cost and quality acceptably at the projected scope." Examples that fail review: "We will use the best model for each use case." "Claude or Llama depending on performance." "Multiple models to be determined during the POC."
The evaluation methodology specifies how the team measures whether the Bedrock workload meets its requirement. A passing methodology contains: a defined test set with a stated size; a defined metric with a stated threshold; a measurement cadence; and a documented baseline for comparison. Example that passes: "Held-out test set of 500 invoices labeled by the accounts-payable team across 30 supplier formats; primary metric is field-level F1 with a passing threshold of 0.95 on the seven required fields; secondary metric is end-user thumbs-up rate from the accounts-payable team with a passing threshold of 80% of processed invoices reviewed without correction; weekly measurement against the test set with regression tracking across model versions; baseline comparison against the prior rule-based extraction system." Examples that fail: "We will measure quality as we go." "Internal review of outputs."
The projected inference budget is a monthly cost estimate broken out by Bedrock service and tightly-coupled supporting services. A passing budget shows specific token volumes and unit economics rather than range estimates. Example that passes: "Bedrock inference $2,100 per month — 12 million input tokens plus 3 million output tokens per month through Claude Sonnet 4 at the published Bedrock pricing; OpenSearch Serverless $500 per month — 80 GB vector index with 200,000 queries per day; Lambda $120 per month — orchestration for invoice ingestion at 1,500 invoices per day; S3 prompt and output logging $40 per month. Total $2,760 per month." Examples that fail: "Approximately $1,000 to $5,000 per month." "Budget to be determined during the POC."
The POC window is a defined 60-day timeframe from the date credits are applied to the AWS account, with a specified mid-point checkpoint and a go/no-go decision at the close of the window. Example that passes: "60-day POC window starting at credits-applied; day-30 checkpoint against the F1 threshold on the held-out test set with a continue/iterate decision; day-60 go/no-go decision based on production-readiness criteria including evaluation threshold met, cost validated against projection, and the accounts-payable team approval of the operating procedure." Plans without a defined window or with open-ended timelines are downgraded.
Bedrock POC credits are not fungible with Activate Portfolio credits. The earmarked mechanic constrains where the balance can be drawn down. Understanding the constraint is necessary for the budget projection to be credible and for the post-approval consumption to actually work as planned.
Bedrock POC credits can fund: Bedrock inference itself — model invocation across any Bedrock-hosted model the startup selects (Claude family, Llama 3, Mistral, Cohere, AI21, Amazon Titan, Amazon Nova); Bedrock Knowledge Bases — the managed RAG service that wraps Bedrock inference with document ingestion, embedding generation, and retrieval orchestration; Amazon OpenSearch Serverless when configured as the vector store for the Bedrock workload's retrieval-augmented generation pipeline; AWS Lambda when used as the orchestration tier for the Bedrock workload (invocation routing, prompt construction, output post-processing); Amazon S3 when used for the Bedrock workload's prompt logging, output logging, and embedding cache storage; data-transfer and networking charges directly attributable to the Bedrock workload.
Bedrock POC credits cannot fund: Amazon EC2 instances running general-purpose application code, web servers, database hosts, or anything outside the narrow orchestration role; Amazon RDS or Aurora running the startup's application database; Amazon DynamoDB used for application state outside the Bedrock workload; CloudFront, Route 53, and content-distribution services unrelated to the Bedrock workload; the startup's general infrastructure footprint regardless of whether some of that infrastructure indirectly supports the Bedrock workload.
The earmarked mechanic is enforced by the AWS billing system at the promotional-credit level. When the AWS billing engine processes a usage line item, it checks whether the service code and the resource tagging match the promotional credit's eligibility configuration. Bedrock inference line items consume the Bedrock POC promotional balance; OpenSearch Serverless line items associated with the Bedrock workload consume it; general EC2 line items do not. The constraint is automatic and does not require startup-side tracking once the eligibility configuration is in place.
The practical implication for the budget projection in the POC plan: the projection must describe consumption that is fundable from the Bedrock POC pool. A projected budget that includes substantial RDS, EC2-outside-of-orchestration, or general-purpose data warehouse consumption signals to the AWS reviewer that the applicant misunderstands the pool. The Bedrock POC budget projection should describe Bedrock inference plus the tightly-coupled supporting services. Startups whose overall AWS workload includes substantial non-Bedrock consumption should describe that separately as Portfolio-funded — and most do, because the standard stack pairs Bedrock POC with Portfolio precisely to handle this separation.
Bedrock POC credits carry a 12-month overall validity from issuance and a 6-month checkpoint against actual Bedrock consumption. The checkpoint is the mechanism AWS uses to enforce real POC execution and to recover credits from startups that file POC plans but do not execute.
The 12-month validity window is the outer time limit on Bedrock POC credit consumption. Credits applied to the account expire 12 months from the issuance date. Unused balance at the expiration date is forfeit; there is no rollover, extension, or transfer mechanism for unused Bedrock POC balance. The window is long enough that a 60-day POC executed in months 1 and 2 leaves 10 months of post-POC consumption window if the workload graduates to production.
The 6-month checkpoint is the mid-validity review AWS conducts against actual Bedrock consumption. At the 6-month mark from credit issuance, AWS examines the consumption pattern: has the startup actually run Bedrock workloads? Is the inference volume reasonably consistent with the budget projection? Has the POC executed according to the plan, or has the credit balance sat untouched? Startups with no Bedrock consumption at the 6-month checkpoint can have remaining credits clawed back to the AWS POC pool; startups with active Bedrock consumption continue to the 12-month expiration.
The checkpoint exists because the Bedrock POC pool is funded by foundation-model-provider marketing dollars allocated to actual Bedrock adoption. Credits sitting unspent in startup accounts do not produce the Bedrock adoption the marketing dollars were meant to drive. The checkpoint enforces real execution by reclaiming unused balance from startups whose POC plans were filed but never run. CloudRoute partners report the checkpoint clawback rate at approximately 15 to 25 percent of issued Bedrock POC credits, with the clawback concentrated in startups whose plans were aspirational rather than imminently executable.
The practical implication for the POC plan: the 60-day window described in the plan should map to an actual execution timeline the startup can deliver. A plan that nominally describes a 60-day window but is filed before the team is ready to execute will fail the 6-month checkpoint and lose remaining credits. Startups that are not in a position to begin POC execution within the first 90 days of credit issuance should defer the Bedrock POC application until the team is execution-ready, even if other parts of the standard stack (Portfolio, Build for Startups) make sense to file immediately. Bedrock POC funding without execution is, structurally, a temporary balance with a 6-month half-life.
Bedrock POC approvals cluster at three levels: the $10K floor for weak applications, the $25K typical for standard well-scoped applications, and the $50K ceiling for applications demonstrating substantial commercial commitment. The variables that tip an approval from one tier to the next are knowable in advance.
The variables that tip an approval from $10K to $25K are: a complete POC plan with all five required components present in the recognized shape; a named model selection with stated rationale specific to the use case; a documented evaluation methodology with a defined test set and a stated metric threshold; a projected inference budget showing specific token volumes and unit economics; a 60-day window with a defined go/no-go decision. The $25K tier is the standard outcome for applications that demonstrate the team understands what a Bedrock POC requires.
The variables that tip an approval from $25K to $50K are: a projected Bedrock inference budget in the $4K to $8K per month range at POC scale — large enough that the POC genuinely tests Bedrock at a meaningful workload level; a clear commercial outcome attached to the workload — paying customers, letters of intent, or comparable evidence that the Bedrock POC supports actual revenue rather than R&D; an explicit commitment to scale Bedrock consumption post-POC — a stated plan to expand Bedrock from the POC workload to broader production deployment within 6 to 12 months of POC close; demonstrated AI and ML team capability — prior production deployment experience, a CTO or technical co-founder with senior ML background, or comparable evidence the team can deliver the POC.
The variables that tip an approval downward to the $10K floor are: a partial POC plan with one or more required components missing or replaced with placeholder text; an unnamed model selection or a hedged "we will evaluate multiple models" framing; an evaluation methodology described in general terms without a test set, metric, or threshold; a budget projection in range form rather than specific token volumes; an open-ended POC timeline. The $10K tier is the standard outcome for applications that demonstrate intent but not specificity.
The variables that tip an approval to outright rejection are: a use case AWS classifies as direct competition to Bedrock or to a foundation-model provider; a use case in a restricted industry classification; an applicant in a regulated jurisdiction where AWS does not extend POC funding; a previous Bedrock POC for the same applicant where the prior credit balance was clawed back at the 6-month checkpoint; a POC plan flagged for plausibility issues — projected consumption inconsistent with the workload description, a team description without credibility for the technical scope, or a use case that does not actually require foundation-model inference (e.g., a workload more appropriately served by a classical ML approach).
Bedrock POC applications are rarely outright rejected — downgrade to the $10K floor is the more common outcome for weak applications. The applications that do get rejected outright cluster in a handful of recognizable patterns.
The first rejection pattern is the "exploring AI" framing — applications where the use case description is category-level rather than product-specific. AWS reviewers consistently reject applications where the use case is described as "exploring how AI can improve our product," "evaluating LLM applications across our business," or "building a generative AI capability." The rejection logic is that exploration does not produce the Bedrock adoption the marketing dollars were meant to drive; the credits would fund evaluation activity that may or may not result in any Bedrock consumption. Applications with this framing are sometimes downgraded rather than rejected when other components are strong, but the framing is a consistent risk factor.
The second rejection pattern is the missing evaluation methodology — applications where the POC plan describes a use case and a model selection but does not specify how the team will measure whether the Bedrock workload meets its requirement. Without an evaluation methodology, AWS reviewers cannot assess whether the 60-day POC will produce a defensible decision. The plan is treated as aspirational rather than executable. Applications missing this component are downgraded to $10K when other components are strong, and rejected when multiple components are weak.
The third rejection pattern is the sub-$500-per-month projected Bedrock consumption — applications where the projected inference budget is too small for the POC framing. The Bedrock POC pool is sized to fund meaningful POC execution; an application projecting $200 per month of Bedrock consumption does not require credit support and is treated as not requiring the pool. The application is either rejected with a recommendation to begin Bedrock consumption directly without POC funding, or redirected to general Activate Portfolio credits where the small consumption can be funded as part of the broader infrastructure budget.
The fourth rejection pattern is the direct-competition classification — applications where the startup's use case competes with Anthropic, Meta, or AWS's own Bedrock-adjacent services. Foundation-model distribution platforms, inference-routing layers that sit between customers and Bedrock, and managed-inference alternatives to Bedrock fall in this classification. The marketing dollars funding the Bedrock POC pool would not be allocated to applications building competing infrastructure. These rejections are typically clear from the application form itself and rarely result in negotiation or appeal.
CloudRoute partners report the aggregate Bedrock POC application outcome rates as roughly 65 percent approved at $25K, 15 percent approved at $50K, 12 percent downgraded to $10K, 5 percent outright rejected, and 3 percent withdrawn before submission after partner review identified the rejection risk. The aggregate approval rate is high; the rejection-pattern recognition exists specifically to keep the rejected and withdrawn fraction low.
Bedrock POC funding is one layer of a three-pool stack. The stacking mechanic — how the three pools fit together to reach the $150K standard stack ceiling — is the practical context most startups need to plan against.
The three pools are: Activate Portfolio ($1K to $100K) for general AWS infrastructure across any service; Build for Startups ($25K typical) for a distinct partner-engineered workload such as a SOC 2 telemetry buildout, a HIPAA-specific architecture, or a vertical-specific deployment; Bedrock POC ($10K to $50K) for Bedrock inference and tightly-coupled supporting services during a 60-day POC window. The three pools together reach the $150K to $175K range that CloudRoute partners refer to as the standard $150K stack for AI-native startups.
The pools are operated by distinct AWS teams and reviewed against distinct criteria. Portfolio is administered by the AWS Activate program operations team and evaluated against the standard Activate eligibility criteria. Build for Startups is reviewed by the AWS Solutions team against the criteria for a distinct partner-engineered workload. Bedrock POC is reviewed by Bedrock-team-adjacent reviewers against the POC plan criteria described in this page. The three reviews proceed in parallel after the partner files the three ACE opportunity records.
The non-overlap requirement applies across the pools. AWS reviewers approve stacks when each pool maps to a distinct purpose. The Bedrock workload itself draws from the Bedrock POC pool; the general application infrastructure draws from Portfolio; a separate distinct workload — vertical-specific architecture, compliance buildout, partner-engineered subsystem — draws from Build for Startups. Stack applications that frame all three pools as funding the same workload tend to be downgraded; applications that articulate distinct purposes for each pool consistently approve.
The stacking timeline is typically: partner files all three opportunity records on the same day; Portfolio approves first (5 to 7 days from filing); Build for Startups follows (7 to 10 days); Bedrock POC closes the cycle (10 to 14 days because of the POC plan review). Total time to all three pools applied to the AWS account: 11 to 18 days from inquiry. The stacking is not strictly sequential — the records can be filed in parallel — and the time-to-balance is determined by the slowest of the three reviews rather than the sum.
Some AI startups stack Bedrock POC funding from AWS with separate standing-credit programs administered directly by Anthropic. The two credit sources are structurally distinct and serve different inference paths.
Anthropic offers credit programs to select AI startups for Claude API direct — the inference path that runs against Anthropic's own API endpoints rather than through Amazon Bedrock. The programs include standing credit allocations for accelerator-affiliated startups, partnership credits for strategic deployments, and developer-platform credits for builders working on Claude integrations. The credits are administered by Anthropic, not by AWS, and apply to Anthropic-direct API consumption rather than Bedrock-hosted Claude consumption.
Bedrock POC funding from AWS applies to Bedrock-hosted Claude — the same underlying Claude models, but routed through Amazon Bedrock's managed inference platform. The pricing for Bedrock-hosted Claude matches the published Bedrock rates; the billing flows through AWS rather than through Anthropic. A startup running Claude on Bedrock can have its consumption funded by Bedrock POC credits applied to the AWS account. The same startup running Claude on Anthropic direct cannot have that consumption funded by Bedrock POC credits — the AWS billing system would not recognize Anthropic-direct charges because they do not flow through AWS.
Some AI startups stack both credit sources. The Anthropic-direct credits fund a portion of the inference workload — typically the workload routed directly to Anthropic's API for specific use cases or specific endpoints — and the Bedrock POC credits fund the Bedrock-hosted portion. The two paths run in parallel in the startup's inference architecture. The standard reason to maintain both is route-specific advantages: Bedrock for VPC isolation and AWS-native integration; Anthropic direct for the most recent model releases that may appear on Anthropic direct before they appear on Bedrock. The credit-stacking is straightforward when the inference architecture supports both routes.
The Anthropic-Bedrock positioning is worth understanding when scoping a Bedrock POC plan. Anthropic publishes guidance comparing the Bedrock-hosted and direct-API paths; the choice between them is partly a function of the deployment requirements (VPC isolation, data-residency, identity and access management) and partly a function of the operational preferences (which billing relationship, which support model, which observability tooling). A Bedrock POC plan can credibly describe Bedrock as the primary path even when the startup maintains Anthropic-direct as a secondary path for specific use cases. AWS reviewers approve Bedrock POC applications that describe this hybrid architecture when the Bedrock workload is articulated clearly.
The 60-day POC window is the structured evaluation period. The pattern after the window closes — what happens with remaining Bedrock POC credits, how the workload graduates to production, and how the credit position evolves — is worth understanding before the POC starts.
The most common pattern across successful Bedrock POCs is graduation to production at the POC window close. The POC plan's day-60 go/no-go decision lands on "go," the production deployment proceeds, and the Bedrock workload continues running. Remaining Bedrock POC credits — if any are left after the 60-day window — burn down against the ongoing production inference billing through the remaining 10 months of the 12-month validity window. The credit balance functions as a partial subsidy on the post-POC production consumption.
The second pattern is iteration before graduation — the day-60 go/no-go lands on "iterate," and the team extends evaluation for an additional 30 to 60 days before committing to production. The credit pool typically supports this iteration because the inference workload during evaluation continues to consume from the Bedrock POC balance. The 6-month checkpoint provides the structural deadline for completing iteration; teams that have not graduated by month 6 risk the clawback if Bedrock consumption has stalled.
The third pattern is graduation followed by scaling beyond the POC pool capacity. The Bedrock workload graduates to production, expands beyond the original POC scope, and consumes inference at a rate that exhausts the Bedrock POC balance before the 12-month validity expires. The startup transitions from Bedrock POC credits to direct Bedrock billing at this point, or layers Activate Portfolio credits, Generative AI Accelerator credits if previously approved, or AWS Enterprise Discount Program (EDP) committed-spend discounts for the post-POC scaling. The transition is operationally straightforward — the billing system simply moves from drawing against the promotional balance to charging the AWS account as the balance approaches zero.
The fourth pattern is workload retirement at the POC window close — the day-60 go/no-go lands on "no-go," the team decides the use case does not require foundation-model inference at the scope evaluated, and the Bedrock workload is wound down. Remaining Bedrock POC credits in this case sit idle until the 6-month checkpoint, at which point AWS typically claws back the remaining balance. This pattern is the least common across approved POCs; the structured POC plan with a documented evaluation methodology rarely fails to produce a credible go decision when the underlying use case was well-scoped.
CloudRoute partners report the post-POC graduation rate at approximately 75 to 80 percent of approved Bedrock POCs progressing to production, 10 to 15 percent extending iteration past day 60, and 5 to 10 percent retiring the workload or pivoting the use case. The graduation rate is high specifically because the POC plan requirements filter out applications where the use case does not justify the foundation-model approach.
The components of a Bedrock POC application are easier to evaluate against a worked example than against component-level descriptions alone. The example below is anonymized but representative of approvals at the $25K typical tier.
The applicant: a Series-A AI legal-tech startup, 14 engineers, deploying a product that supports legal-document review for in-house corporate legal teams. The product extracts structured information from contracts and surfaces the extracted fields in a review interface. The team had previously deployed an early version against OpenAI direct and was migrating to Bedrock for VPC-isolated deployment driven by enterprise customer requirements.
The use case description in the POC plan: "Structured extraction of contract metadata from PDF contracts ingested by in-house legal teams. The extracted fields include party names, effective date, term length, renewal clauses, payment terms, governing law, change-of-control provisions, and assignment restrictions. The extracted fields populate the contract-review interface and support the legal team's workflow for renewal management and contract analytics. Target accuracy of 92% on the eight required fields measured against a held-out test set."
The selected model: "Claude Sonnet 4. The use case requires reasoning across multi-page contracts where context window and instruction-following both materially affect accuracy. Held-out evaluation of Sonnet 4 against Haiku showed Sonnet 4 outperforming on the primary metric by 11 F1 points at 4x the per-call cost; the additional cost is justified by the accuracy margin. Held-out evaluation of Opus showed Opus outperforming Sonnet 4 by 1.4 F1 points at 5x the cost; the marginal accuracy improvement does not justify the cost differential."
The evaluation methodology: "Held-out test set of 200 contracts labeled by a legal-domain expert across 12 contract types and 5 jurisdictions; primary metric is field-level F1 with a passing threshold of 0.92 on the eight required fields; secondary metric is end-user thumbs-up rate from the legal-review team with a passing threshold of 85% of reviewed contracts approved without correction; weekly measurement against the test set with regression tracking across model versions and prompt revisions; baseline comparison against the prior GPT-4 deployment on the same test set."
The projected budget: "Bedrock inference $1,950 per month at POC scale — projected at 8 million input tokens plus 1.5 million output tokens per month through Claude Sonnet 4; OpenSearch Serverless $400 per month — 60 GB vector index used for contract-clause retrieval supporting the extraction prompt construction; Lambda $90 per month — orchestration for contract ingestion at 200 contracts per day; S3 prompt and output logging $35 per month. Total $2,475 per month at POC scale; projection at production scale of 800 contracts per day brings total to $9,400 per month."
The POC window: "60-day POC window starting at credits-applied; day-30 checkpoint against the F1 threshold on the held-out test set with continue/iterate decision; day-60 go/no-go decision based on production-readiness criteria including evaluation threshold met, cost validated against projection, and the customer legal-review teams approval of the operating procedure. Production graduation planned for week 9 conditional on day-60 go decision."
The outcome: the partner filed the Bedrock POC opportunity record alongside Activate Portfolio ($100K) and Build for Startups ($25K for the VPC-isolated deployment architecture). The Bedrock POC application was approved at $25K within 17 days. The POC executed within the 60-day window; the day-60 go/no-go landed on "go" with measured F1 of 0.94 against the 0.92 threshold. Production graduation completed in week 9; the Bedrock POC credit balance burned down against ongoing inference billing through month 10 of the 12-month validity. The 6-month checkpoint was satisfied with active Bedrock consumption; no clawback occurred. Combined credit position from the standard stack: $150K; combined credit position with subsequent Generative AI Accelerator acceptance in the following cohort: $400K.
What separates the $10K floor approval from the $50K ceiling approval across the variables AWS reviewers evaluate.
| Variable | $10K floor | $25K typical | $50K ceiling |
|---|---|---|---|
| Use case description | Category-level framing ("exploring AI") | Product-specific with stated workflow | Product-specific plus commercial outcome attached |
| Model selection | Unnamed or hedged across multiple options | Single named model with brief rationale | Single named model with comparative evaluation against alternatives |
| Evaluation methodology | General "measure as we go" | Defined test set + metric + threshold | Defined test set + multiple metrics + baseline comparison + regression tracking |
| Projected budget | Range estimate ("$1K–$5K/month") | Specific token volumes and service breakdown | Specific budget with explicit post-POC scaling projection ($4K+/month) |
| POC window | Open-ended or undefined | 60-day window with day-60 go/no-go | 60-day window with day-30 checkpoint and explicit production graduation plan |
| Team capability signal | Generalist team, no AI background stated | Some AI/ML experience stated | Demonstrated production AI deployment, senior ML background, comparable evidence |
| Commercial outcome | Not addressed | Implied (product roadmap reference) | Stated (paying customers, LOIs, or specific revenue attribution) |
| Post-POC commitment | Not stated | Implied scale to production | Explicit plan to scale Bedrock 5x to 10x post-POC |
Situation: Series-A AI legal-tech startup running an existing OpenAI direct deployment for contract extraction; migrating to Bedrock for VPC-isolated deployment driven by enterprise customer requirements. Production traffic at approximately $4,200 per month combined inference plus retrieval. Founder had heard about Bedrock POC funding but did not know it was filed separately from the standard Activate Portfolio.
What CloudRoute did: Routed within 14 hours to a US partner with Bedrock production deployment experience and prior legal-tech contract-extraction work. Partner walked the founder through the five POC plan components on a 45-minute scoping call; founder produced first-draft components within 48 hours; partner refined the components into the submission-ready POC plan over the following 72 hours. Partner filed Activate Portfolio ($100K) on day 6 covering general AWS infrastructure plus the OpenSearch Serverless deployment; Build for Startups ($25K) on day 6 for the VPC-isolated deployment architecture as a distinct workload; Bedrock POC ($25K) on day 6 with the documented POC plan including the held-out evaluation against the existing GPT-4 baseline on a 200-contract test set.
Outcome: Standard stack credits approved across the three pools within day 17. Total stacked: $150K. The Bedrock POC executed within the 60-day window with day-30 checkpoint at F1 of 0.93 and day-60 go decision at F1 of 0.94 against the 0.92 threshold. Production graduation completed in week 9; the Bedrock POC credit balance burned down against ongoing inference billing across the following 8 months. The 6-month checkpoint was satisfied with active Bedrock consumption at approximately $8,600 per month inference run-rate; no clawback. The startup subsequently applied to the Generative AI Accelerator in the following cohort and was accepted for additional credits, bringing the combined credit position to approximately $400K.
engagement window: 11 weeks · founder time: ~9 hours · credits secured: $150K (standard stack) plus subsequent accelerator
CloudRoute routes startups to AWS partners experienced in filing the Bedrock POC opportunity record via the ACE program, including the POC plan scoping for the $25K typical and $50K ceiling tiers. We can also route the parallel Activate Portfolio and Build for Startups filings that complete the standard $150K stack.