AWS Innovation Sandbox is a $10K–$25K credit pool earmarked for evaluating emerging AWS services where Bedrock POC funding does not quite apply — Bedrock Agents, Bedrock Knowledge Bases v2, Amazon Q Business, Amazon Q Developer, newer SageMaker features. The pool is partner-filed via the ACE program against a 30–60 day evaluation window. Credits come from AWS service-team marketing budgets allocated to driving adoption of services still in the emerging stage. This page is a mechanism reference: what the sandbox is, when it fires instead of Bedrock POC funding, what the application paperwork contains, and the service-team relationship that comes with the credits.
AWS Innovation Sandbox is the partner-led funded POC environment AWS uses to drive adoption of emerging services. The credit pool is structurally distinct from Bedrock POC funding, Activate Portfolio, and Build for Startups; it serves a specific economic purpose tied to AWS service-team product development.
Innovation Sandbox sits in the AWS credit landscape as the funding mechanism for emerging-service evaluation. Where Activate Portfolio funds general AWS infrastructure ($1K to $100K), Build for Startups funds distinct partner-engineered workloads ($25K typical), and Bedrock POC funds general Amazon Bedrock inference workloads ($10K to $50K), Innovation Sandbox funds the narrower category of evaluating a specific emerging AWS service against a defined use case. The 2026 examples are Bedrock Agents, Bedrock Knowledge Bases v2, Amazon Q Business, Amazon Q Developer, and newer SageMaker features such as SageMaker HyperPod recipes and SageMaker Unified Studio components still in adoption-driving phase.
The structural distinction is the scope of the evaluation. Bedrock POC funding scopes around general Bedrock inference — a 60-day window where the team evaluates whether Claude, Llama, or Mistral on Bedrock supports the workload at the target metric. Innovation Sandbox scopes around a specific emerging service — a 30 to 60 day window where the team evaluates whether Bedrock Agents handles an autonomous workflow, whether Amazon Q Business answers internal-documentation queries at the required accuracy, whether Bedrock Knowledge Bases v2 ingestion handles the corpus shape. The two pools are not interchangeable; an application filed in the wrong pool is downgraded or redirected.
The credit pool size is calibrated to the narrower scope. Innovation Sandbox engagements fund $10K to $25K per evaluation — large enough to support meaningful consumption of the emerging service across the 30 to 60 day window, smaller than Bedrock POC because the scope is bounded to one service evaluation rather than a general Bedrock workload. The $25K ceiling typically applies to evaluations with substantial projected consumption ($3K to $5K per month on the emerging service plus tightly-coupled supporting infrastructure); the $10K floor applies to evaluations with smaller projected consumption.
The filing mechanism is the AWS ACE program, the same partner-mediated channel that handles Bedrock POC and Build for Startups filings. Innovation Sandbox does not have a direct-customer application path on the AWS Activate portal. The mechanism is structurally partner-mediated because the funding originates from AWS service-team marketing budgets allocated through the partner program rather than through direct AWS-to-customer credit issuance. CloudRoute routes startups to AWS partners who file the Innovation Sandbox ACE opportunity record on the startup behalf at zero cost.
The most common question on Innovation Sandbox is how to know whether a particular AI workload should be filed under Innovation Sandbox or Bedrock POC funding. The distinction is the scope of the evaluation, not the strength of the application.
Bedrock POC funding fires when the workload is general Bedrock inference — the team is evaluating whether a foundation model on Bedrock supports a defined use case at the required accuracy and cost. The use case in a Bedrock POC plan typically references the inference itself: extraction, summarization, classification, conversational interface, retrieval-augmented generation against documents. The model under evaluation is the central variable; Bedrock is the inference platform that hosts the model.
Innovation Sandbox fires when the workload is evaluation of a specific emerging AWS service — the team is evaluating whether Bedrock Agents handles an autonomous multi-step workflow, whether Amazon Q Business answers internal queries against the enterprise corpus, whether the SageMaker emerging-feature handles the training or deployment pattern. The emerging service is the central variable; the foundation model is a component of the broader service evaluation rather than the variable under test.
Concrete examples clarify the distinction. A team evaluating Claude Sonnet against Llama 70B for invoice extraction files a Bedrock POC application; the model selection is the variable, Bedrock is the platform. A team evaluating Bedrock Agents to orchestrate a customer-support autonomous workflow (where the agent makes tool calls, retrieves knowledge, escalates to humans) files an Innovation Sandbox application; the agent framework is the variable, the underlying model is selected by the framework. A team evaluating Bedrock Knowledge Bases v2 against a custom OpenSearch implementation for a 100,000-document corpus files an Innovation Sandbox application; the managed RAG service is the variable, the underlying model serves the retrieval pipeline.
Some workloads sit on the boundary and could plausibly be filed under either pool. AWS reviewers report that the partner-filing decision generally follows the workload component that drives the consumption budget. If the projected inference consumption dominates the projected emerging-service consumption (typical case for general Bedrock inference workloads), Bedrock POC is the right pool. If the projected emerging-service consumption (Bedrock Agents invocations, Q Business queries, Knowledge Bases retrieval operations) dominates the budget projection, Innovation Sandbox is the right pool. Misfiled applications are typically redirected to the correct pool during the partner-filing review rather than rejected outright; CloudRoute partners screen for the correct pool before submission.
Innovation Sandbox credits come from a different source than Bedrock POC credits. Understanding the source clarifies why the pool exists, why credits are smaller, and why service-team office hours come bundled with the engagement.
Bedrock POC funding is sourced from foundation-model-provider marketing dollars — Anthropic, Meta, Mistral, Cohere, AI21 commit marketing budgets to AWS that AWS converts into Bedrock-earmarked credit pools to drive adoption of Bedrock-hosted versions of those models. The economic logic is the model providers want Bedrock primacy over OpenAI direct, Anthropic direct, and competing managed-inference platforms.
Innovation Sandbox credits come from a structurally different source: AWS service-team marketing budgets allocated to driving adoption of emerging AWS services. Each emerging service inside AWS has a service team responsible for product development, customer acquisition, and adoption metrics. When a service launches and enters the adoption-driving phase, the service team receives a marketing budget calibrated to the launch goals — including a credit-pool allocation that the team uses to fund customer evaluation engagements. The pool is administered through AWS Activate and routed to startups via the ACE program in the same partner-filed format as Bedrock POC, but the funding source and the approving entity are distinct.
The service-team funding origin explains several features of the Innovation Sandbox engagement. The credits are smaller because each service team operates within a bounded marketing budget rather than drawing from the multi-provider foundation-model marketing pool. The evaluations are time-bounded because the service team wants feedback fast — the goal is to inform the service roadmap within the current development cycle, not to support open-ended consumption. The service-team office hours that accompany the engagement exist because the service team wants direct customer feedback channels; the relationship is structurally bidirectional.
The practical implication for the application: a Bedrock POC plan articulates the workload requirements and the model evaluation methodology, and AWS reviewers approve based on whether the plan demonstrates real Bedrock execution capability. An Innovation Sandbox application articulates the workload requirements, the emerging service under evaluation, the specific feedback the team will be able to provide back to AWS about the service experience, and AWS reviewers approve based on whether the engagement will produce feedback the service team can act on. The Innovation Sandbox application is partly an evaluation plan and partly a feedback commitment — the credits are funded by service-team marketing dollars allocated to real customer feedback that informs product development.
The eligibility profile for Innovation Sandbox is narrow on the workload dimension (the engagement must center on an emerging AWS service in active adoption-driving phase) and broad on the funding-stage dimension (no funding-stage gate beyond standard Activate baseline).
The required conditions for a startup to be eligible for Innovation Sandbox credits are: (1) a planned evaluation of a specific emerging AWS service — the application must name a single service in the current emerging-service set (Bedrock Agents, Bedrock Knowledge Bases v2, Amazon Q Business, Amazon Q Developer, SageMaker emerging features, or whatever the current adoption-driving set is at filing time); (2) an AWS account where the credits will be applied; (3) standard AWS Activate eligibility — the startup is not in a restricted industry classification and is not subject to other Activate exclusions; (4) an AWS partner willing to file the Innovation Sandbox ACE opportunity record; (5) a defined use case that genuinely exercises the emerging service in a way the service team will recognize as adoption-relevant.
The conditions notably not required are: a specific funding stage — Innovation Sandbox has no minimum funding-stage requirement and approvals at the seed stage are common; an LLC or formal company structure beyond the standard Activate baseline; existing AWS spend; team-size minimums. Solo founders and pre-revenue startups are eligible when the use case genuinely exercises the emerging service. The service team funding the pool wants feedback from real builders evaluating the service; the funding-stage filter does not apply because the feedback value is independent of funding stage.
The use case must be one AWS classifies as legitimate evaluation of the emerging service against a real product requirement. Applications described as "exploring what Bedrock Agents can do" or "evaluating Amazon Q for our workflows" without a specific product requirement attached are downgraded or rejected. Applications described in terms of the specific evaluation — "evaluating whether Bedrock Agents can autonomously triage customer support tickets across our existing knowledge base and CRM integration with a target deflection rate of 35%" — produce approvals at the standard tier. The reviewers want to see a real product question the evaluation answers.
The service set under Innovation Sandbox shifts over time. A service that has matured past the adoption-driving phase exits the Innovation Sandbox pool; its general consumption moves to Activate Portfolio funding or, in the case of Bedrock-related services, to Bedrock POC funding. A service freshly launched into the adoption-driving phase enters the Innovation Sandbox pool. The current 2026 emerging-service set centers on Bedrock Agents, Bedrock Knowledge Bases v2, Amazon Q Business, Amazon Q Developer, and a rotating subset of SageMaker emerging features. CloudRoute partners track the current emerging-service set and route applications to the active pool.
The Innovation Sandbox application is shorter than a Bedrock POC application but contains specific components the partner submits with the ACE opportunity record. The substantive deliverable is an evaluation plan tied to the specific emerging service.
The four required components of an Innovation Sandbox application are: a use case description tied to the emerging service, the specific metrics the evaluation will capture, the evaluation window, and the projected consumption budget. Each component has a recognized shape AWS reviewers look for. Applications containing all four components in the recognized shape approve at the typical $20K tier; applications with one or more weak components downgrade to the $10K floor; strong applications with substantial projected consumption and clear feedback commitment approve at the $25K ceiling.
The use case description is a one-paragraph statement of what the evaluation is meant to determine, anchored to the specific emerging service under test. Examples that pass review for Bedrock Agents: "Evaluation of Bedrock Agents to autonomously triage incoming customer support tickets across our help-center knowledge base and CRM contact context. The agent receives the ticket, retrieves relevant documentation, drafts a response, and either auto-resolves the ticket or routes to a human agent. Target metrics: 35% auto-resolution rate at acceptable quality, average handling time reduced by 50%, escalation rate stable." Examples that fail: "Exploring Bedrock Agents for various customer-support use cases." Examples that pass review for Amazon Q Business: "Evaluation of Amazon Q Business as the internal documentation search interface for our 200-person engineering organization across our Confluence, Notion, and GitHub-hosted internal docs. Target metrics: 80% answer-rate on representative employee queries, sub-3-second answer latency, source attribution quality acceptable to engineering reviewers."
The metrics section names the specific data points the team will capture about the emerging service during the evaluation. AWS service teams want feedback that informs product roadmap; the metrics section is partly an evaluation methodology and partly a feedback commitment. Typical metrics for Bedrock Agents evaluations: tool-call latency, accuracy on multi-step workflows, integration friction with the existing application stack, cost per agent invocation against the projected budget. Typical metrics for Amazon Q Business: answer accuracy on a representative query set, latency, source-attribution quality, false-positive rate on out-of-scope queries. Typical metrics for SageMaker emerging features: training throughput, deployment latency, integration with existing MLOps tooling, cost-fit against the workload pattern.
The evaluation window names the timeframe — typically 30 days for narrowly-scoped evaluations or 60 days for broader evaluations exercising multiple aspects of the emerging service. The window should map to a realistic execution timeline the team can deliver; Innovation Sandbox engagements that miss the window without active consumption can have remaining credits clawed back at the close of the window. The window also defines when the service-team office hours apply — typically scheduled across the evaluation window with a kickoff session in the first week, a mid-window check-in, and a closing session where the team shares the feedback the service team will use.
The projected consumption budget is a monthly cost estimate broken out by the emerging service and tightly-coupled supporting infrastructure. The budget should describe consumption that is fundable from the Innovation Sandbox pool — the emerging service itself plus the supporting services that genuinely support the evaluation. Example for a Bedrock Agents evaluation: "Bedrock Agents invocations $1,800 per month — projected at 60,000 agent invocations averaging 4 tool calls per invocation; underlying Bedrock model consumption $800 per month — Claude Sonnet 4 for agent reasoning; Lambda orchestration for tool execution $200 per month; OpenSearch Serverless $300 per month — knowledge-base vector index for retrieval; CloudWatch logging $50 per month. Total $3,150 per month at evaluation scale." The budget should be specific to the emerging service and the evaluation scope; range estimates are downgraded.
Innovation Sandbox credits typically issue in a single tranche at application approval. A subset of engagements split the credits across two tranches — an initial evaluation tranche and a scaling evaluation tranche — when the evaluation scope warrants it.
The single-tranche pattern is the typical issuance mechanic for Innovation Sandbox credits. The full credit balance ($10K, $20K, or $25K depending on the approval tier) applies to the AWS account at approval. The 30 to 60 day evaluation window starts at credits-applied. Consumption draws from the balance across the window; remaining balance at the window close burns down against ongoing consumption of the emerging service during a follow-on grace period typically structured at 60 to 90 days after the formal window closes. Total credit validity from issuance is typically 6 months — shorter than Bedrock POC funding 12-month validity because the engagement is more bounded.
The split-tranche pattern applies to a subset of Innovation Sandbox engagements where the scope warrants an initial-evaluation tranche followed by a scaling-evaluation tranche. The typical case is an engagement that evaluates the emerging service in a narrow initial scope (first 30 days, $10K initial tranche) then expands to a broader scaling scope if the initial evaluation produces favorable results (next 30 days, additional $10K to $15K scaling tranche). The split mechanic gives the service team a midpoint signal — if the initial evaluation surfaces blocking concerns about the service experience, the scaling tranche may be withheld or redirected based on the feedback. CloudRoute partners report split-tranche engagements at roughly 20 to 25 percent of approved Innovation Sandbox applications, concentrated in larger-scope evaluations of Bedrock Agents and Amazon Q Business.
The decision between single-tranche and split-tranche is partly a function of the projected consumption pattern and partly a function of the service team preference for the specific service. Some service teams default to split-tranche structures for visibility into the initial evaluation results before committing the full credit balance; other service teams default to single-tranche to keep the engagement administrative burden low. The application does not typically specify the tranche structure — the structure is determined during AWS-side review based on the service team preference and the evaluation scope. The partner-filing process does not require startup-side input on tranche structure.
The practical implication for the engagement: in a single-tranche structure, the team has the full credit balance available for the entire evaluation window and can pace consumption across the window without tranche-related milestones. In a split-tranche structure, the team executes the initial evaluation within the first 30 days, produces interim feedback for the service-team check-in, and receives the scaling tranche to support the broader evaluation. Both structures support genuine evaluation; the split structure adds a mid-engagement feedback milestone that some service teams value.
The most underappreciated feature of Innovation Sandbox engagements is the bundled service-team relationship. The credits come with optional engineering office hours with the AWS product team responsible for the specific emerging service.
The office-hours mechanic is structural to the Innovation Sandbox engagement. When an Innovation Sandbox application approves, the AWS service team for the specific emerging service receives a notification that a customer evaluation is underway. The service team typically offers optional engineering office hours — direct sessions with members of the product team responsible for the service. The sessions are scheduled across the evaluation window and serve two purposes from the AWS side: providing implementation guidance to the customer team and gathering feedback about the customer experience back to the product team.
A typical office-hours cadence for a 60-day Innovation Sandbox engagement is: a kickoff session in week 1 where the customer team meets the service team, walks through the evaluation plan, and identifies any service-specific implementation considerations the customer team should account for; a mid-engagement session at the 30-day mark where the customer team shares early observations and the service team provides guidance on the second half of the evaluation; a closing session at the 60-day mark where the customer team shares the full evaluation feedback and the service team confirms graduation paths if the evaluation supports continued consumption. Additional ad-hoc sessions can be scheduled when blocking implementation issues surface; the service team is incentivized to remove blockers because unblocking the evaluation produces the feedback the funding was meant to support.
The composition of the service-team participants varies by service and engagement scope. Bedrock Agents engagements typically draw participants from the Bedrock Agents product management team and the engineering team responsible for the agent runtime, the tool-calling integration layer, and the agent observability tooling. Amazon Q Business engagements typically draw from the Q Business product team, the retrieval engineering team, and the enterprise-integration team responsible for the connector ecosystem. SageMaker emerging-feature engagements draw from the specific feature team and the broader SageMaker platform engineering organization. CloudRoute partners report the service-team participation as the highest-value component of Innovation Sandbox engagements — more impactful than the credit balance itself for teams building seriously on the emerging service.
The feedback flowing back to the service team is the economic justification for the engagement from the AWS side. The service team learns where the service experience breaks down in real customer implementations, where the API surface area causes friction, where the documentation gaps create implementation delays, and which integration patterns are most common in the customer evaluation set. The feedback informs the service roadmap directly — features released in subsequent service updates frequently trace back to feedback gathered through Innovation Sandbox engagements. The customer team has indirect influence on the product roadmap of the specific service through participation in the feedback channel.
Innovation Sandbox is one layer in the stacking landscape. It stacks cleanly with Activate Portfolio and Build for Startups, and conditionally with Bedrock POC funding depending on use-case overlap.
Innovation Sandbox stacks with Activate Portfolio. The two pools serve distinct purposes — Innovation Sandbox earmarks credits for the specific emerging-service evaluation; Activate Portfolio funds the general AWS infrastructure the startup runs. A startup running an Innovation Sandbox engagement for Bedrock Agents while operating a broader AWS footprint (EC2, RDS, S3 for application data, CloudFront for content distribution) has Portfolio credits funding the broader footprint and Innovation Sandbox credits funding the Bedrock Agents evaluation specifically. Stacked applications across both pools are common and approve cleanly when the partner-filing articulates the distinct purposes.
Innovation Sandbox stacks with Build for Startups. Build for Startups funds a distinct partner-engineered workload — a SOC 2 telemetry buildout, a HIPAA-specific architecture, a vertical-specific deployment pattern. Innovation Sandbox funds the narrow emerging-service evaluation. The two pools fund different work and AWS reviewers approve the stack when each pool maps to a distinct deliverable. A startup evaluating Amazon Q Business while a partner engineers a HIPAA-compliant deployment architecture has Build for Startups funding the partner labor on the compliance buildout and Innovation Sandbox funding the Q Business evaluation.
Innovation Sandbox stacks with Bedrock POC funding conditionally. When the use cases are distinct, the stack is approved — for example, a Bedrock POC for general Claude inference for invoice extraction plus an Innovation Sandbox for Bedrock Agents evaluating autonomous customer-support workflows. The two pools fund distinct evaluations and AWS reviewers approve the stack. When the use cases overlap — for example, a Bedrock POC scoped around general Bedrock inference for a customer-support workflow plus an Innovation Sandbox scoped around Bedrock Agents for the same customer-support workflow — the reviewer typically approves one pool and redirects the other. The non-overlap requirement is the operative rule.
The practical implication for the standard AI-native stack: Activate Portfolio + Build for Startups + Bedrock POC reaches the $150K stack ceiling that CloudRoute partners refer to as the standard credit position. Innovation Sandbox adds an incremental $10K to $25K when the startup has a clear emerging-service evaluation use case adjacent to the general Bedrock workload. Combined credit position with Innovation Sandbox layered on the standard stack is typically $160K to $175K. The incremental credit is modest in absolute terms but the engagement value comes substantially from the service-team office hours that accompany the credits.
Innovation Sandbox evaluations have defined exit paths. The most common pattern is graduation from the bounded evaluation engagement to a broader Bedrock POC engagement that scopes the evaluated service into production.
The graduation path from Innovation Sandbox to Bedrock POC funding applies when the emerging-service evaluation produces favorable results and the team commits to scaling the workload to production. The Innovation Sandbox engagement scopes the narrow evaluation; the follow-on Bedrock POC engagement scopes the production deployment that uses the evaluated service. The transition is structurally clean — the partner files a separate Bedrock POC opportunity record describing the production scope, AWS reviews the application against the standard Bedrock POC criteria, and the new credit pool applies to the AWS account. The Innovation Sandbox balance burns down across the evaluation window; the Bedrock POC balance funds the production-scope consumption.
The graduation path applies cleanly to Bedrock Agents evaluations and Bedrock Knowledge Bases v2 evaluations because the production deployment falls within the Bedrock-eligible scope of the Bedrock POC pool. A team that evaluates Bedrock Agents over 60 days under Innovation Sandbox and decides to scale the agent workflow to production has a clear Bedrock POC application available for the production scope — the agent invocations, the underlying model inference, the supporting orchestration and retrieval infrastructure all fall within the Bedrock POC eligible-service set. CloudRoute partners report the Sandbox-to-Bedrock-POC graduation rate at approximately 40 to 50 percent of Innovation Sandbox engagements involving Bedrock-family services.
The graduation path differs for Amazon Q Business and Amazon Q Developer evaluations. The Q-family services have their own pricing model and are not part of the Bedrock POC eligible-service set. A team graduating a Q Business evaluation to production typically funds the production consumption through Activate Portfolio credits — the Q Business consumption falls within the broader Activate Portfolio eligible-service set — or through direct AWS billing if the Portfolio balance is exhausted. The graduation path is structurally different but operationally similar: the bounded Innovation Sandbox engagement transitions to production-scope funding through a different pool.
The graduation path for SageMaker emerging-feature evaluations also differs. The mature SageMaker services fall under Activate Portfolio funding; the emerging-feature evaluation runs under Innovation Sandbox, and the production-scope consumption of the feature transitions to Activate Portfolio funding once the feature graduates out of the emerging stage. The transition timing can lag the Innovation Sandbox engagement — a SageMaker feature in active adoption-driving phase at the time of the Innovation Sandbox engagement may still be in the same phase six months later, in which case production-scope consumption can continue against subsequent Innovation Sandbox engagements rather than transitioning to Portfolio. CloudRoute partners coordinate the transition based on the current adoption-stage classification.
The retirement path applies when the evaluation produces unfavorable results and the team decides not to proceed with the evaluated service. The Innovation Sandbox engagement closes at the window close; remaining credit balance typically does not transition to alternative use because the credit pool is earmarked for the specific emerging-service consumption. The service-team feedback the team produced during the engagement still flows back to the AWS service team as planned. CloudRoute partners report retirement-path outcomes at roughly 15 to 20 percent of Innovation Sandbox engagements — meaningfully higher than Bedrock POC retirement rates because emerging-service evaluations carry more inherent uncertainty about whether the service experience supports the customer use case.
The mechanics of an Innovation Sandbox engagement come into focus against a worked example. The example below is anonymized but representative of approvals at the $20K typical tier.
The applicant: a Series-A AI startup, 11 engineers, deploying a product that supports customer-service automation for mid-market SaaS businesses. The product had reached approximately $80K monthly recurring revenue serving 45 customers with a primarily human-in-the-loop architecture where the AI suggested responses and human agents approved or revised before sending. The team was evaluating whether to introduce an autonomous tier where the AI handled tickets end-to-end for the simplest classification of incoming issues. The autonomous tier required orchestrating multiple steps — knowledge-base retrieval, response generation, optional CRM updates, escalation logic — and the team wanted to evaluate Bedrock Agents as the orchestration framework.
The use case description in the Innovation Sandbox application: "Evaluation of Bedrock Agents to autonomously resolve incoming customer support tickets for our SaaS customer base. The agent receives the incoming ticket, classifies the issue type, retrieves relevant documentation from the customer knowledge base, drafts a response, and either auto-resolves the ticket with a confidence threshold of 0.85 or escalates to the human agent queue. Integration points: existing ticket inbox webhook, customer knowledge base accessed via custom retrieval API, CRM context fetched per ticket, escalation queue write-back. Target metrics: 30% auto-resolution rate at acceptable response quality measured by customer satisfaction scoring, average handling time reduced by 40% across the customer base, escalation rate held below 60% on tickets the agent attempts."
The metrics commitment to AWS: "We will capture and share back with the Bedrock Agents service team: tool-call latency distribution across the four integration points; accuracy of the agent classification on a labeled set of 200 representative tickets; cost per agent invocation tracked against the projected budget; integration friction observations on the tool-calling API surface area; agent observability gaps surfaced during the engagement. Feedback compiled and shared back at the 30-day mid-engagement check-in and at the 60-day closing session."
The evaluation window: "60-day window starting at credits-applied. Week 1 kickoff session with the Bedrock Agents service team. Day 30 mid-engagement check-in with interim feedback. Day 60 closing session with full feedback summary and graduation decision."
The projected budget: "Bedrock Agents invocations $1,200 per month — projected at 40,000 agent invocations averaging 3 tool calls per invocation at the published Agents pricing; underlying Claude Sonnet 4 inference $850 per month — model reasoning consumption across the agent invocations; Lambda orchestration for tool execution $180 per month — webhook handlers and CRM integration calls; OpenSearch Serverless $250 per month — knowledge base vector index; CloudWatch logging $60 per month. Total $2,540 per month at evaluation scale; the projection at production scale of 150,000 agent invocations per month brings the projected total to $7,800 per month."
The outcome: the partner filed the Innovation Sandbox opportunity record alongside the standard stack components (Activate Portfolio at $80K covering the broader application infrastructure, Build for Startups at $25K for the SOC 2 architecture buildout the team was completing in parallel). The Innovation Sandbox application approved at $20K within 12 days. The evaluation executed within the 60-day window. The kickoff session with the Bedrock Agents service team surfaced two implementation considerations that materially improved the agent design — a tool-calling pattern the team had not been using and an observability hook the team integrated. The mid-engagement check-in at day 30 showed the auto-resolution rate at 22% against the 30% target; the service team provided guidance on the agent prompt structure that lifted the rate to 28% by day 60. The day-60 go decision graduated the evaluation to production. The feedback the team shared back included three observability gaps the service team subsequently addressed in service updates over the following 6 months — the customer team had material influence on the product roadmap through participation. The graduation path filed a follow-on Bedrock POC application at $25K covering the production-scale Bedrock Agents consumption; the Bedrock POC application approved at $25K within 14 days. Combined credit position from the standard stack plus the Innovation Sandbox plus the follow-on Bedrock POC: approximately $150K.
The two pools serve adjacent purposes. The variables below determine which pool fits a given workload.
| Variable | Innovation Sandbox | Bedrock POC funding |
|---|---|---|
| Pool range | $10K–$25K | $10K–$50K |
| Window | 30–60 days | 60 days |
| Validity from issuance | 6 months typical | 12 months |
| Funding source | AWS service-team marketing budgets | Foundation-model-provider marketing budgets |
| Workload scope | Specific emerging-service evaluation | General Bedrock inference workload |
| Primary variable under test | The emerging service itself | The foundation model selection on Bedrock |
| Typical services in scope | Bedrock Agents, Bedrock Knowledge Bases v2, Amazon Q Business, Amazon Q Developer, SageMaker emerging features | Bedrock inference across Claude, Llama, Mistral, Cohere, AI21, Titan, Nova models |
| Tranche structure | Single tranche typical; split-tranche for larger scopes | Single tranche at approval |
| Service-team office hours | Bundled with the engagement | Not bundled |
| Graduation path | Typically graduates to Bedrock POC or Activate Portfolio for production scope | Typically graduates to direct Bedrock billing or EDP for production scale |
| Stacking with Activate Portfolio | Yes, cleanly | Yes, cleanly |
| Stacking with Build for Startups | Yes, when scopes are distinct | Yes, when scopes are distinct |
| Stacking with each other | Conditionally, when the use cases are distinct | Conditionally, when the use cases are distinct |
Situation: Series-A AI startup operating a customer-service automation product at $80K monthly recurring revenue serving 45 customers. Evaluating whether to introduce an autonomous response tier orchestrated by Bedrock Agents — knowledge-base retrieval, response generation, CRM updates, escalation logic. Founder had heard about general Bedrock POC funding but was uncertain whether the Agents-specific evaluation fit that pool. Wanted partner guidance on filing the right credit application.
What CloudRoute did: Routed within 16 hours to a US partner with Bedrock Agents implementation experience and prior customer-service automation work. Partner identified the workload as Innovation Sandbox scope rather than Bedrock POC scope — the variable under test was the Agents framework, not the underlying model. Partner walked the founder through the four application components on a 30-minute scoping call; founder produced first-draft application content within 24 hours; partner refined the components into the submission-ready application over 48 hours. Partner filed Activate Portfolio ($80K) on day 4 for general AWS infrastructure; Build for Startups ($25K) on day 4 for the SOC 2 architecture buildout the team was completing in parallel; Innovation Sandbox ($20K) on day 4 with the documented evaluation plan including the metrics commitment back to the Bedrock Agents service team.
Outcome: All three credit pools approved within day 12. Total stacked: $125K direct credits. The Innovation Sandbox evaluation executed within the 60-day window. The kickoff session with the Bedrock Agents service team surfaced implementation patterns the team had not been using. The mid-engagement check-in at day 30 showed the auto-resolution rate at 22% against the 30% target; service-team guidance lifted the rate to 28% by day 60. The day-60 go decision graduated the evaluation to production. The team shared three observability gaps with the service team that subsequently shipped in product updates. The follow-on Bedrock POC application for the production-scale Agents consumption approved at $25K. Combined credit position across the engagements: approximately $150K with substantive service-team relationships across Bedrock Agents and adjacent services.
engagement window: 12 weeks · founder time: ~11 hours · credits secured: $125K (initial stack) plus $25K follow-on Bedrock POC
CloudRoute routes startups to AWS partners experienced in filing Innovation Sandbox opportunity records via the ACE program, including the evaluation-plan scoping for the $20K typical and $25K ceiling tiers. We can also route the parallel Activate Portfolio, Build for Startups, and Bedrock POC filings that complete the broader credit stack.