FAST: AWS Labs' Fullstack AgentCore Template, and What It Actually Deploys
Flexible Fullstack solution template for production-ready deployments of any use case on Amazon Bedrock AgentCore.
At a glance
- What is it?
- FAST is a forked starter repository that ships a working React-plus-AgentCore stack so you can spend your time on prompts and tools instead of Cognito wiring. It is opinionated about documentation, not about agent frameworks.
- Who is it for?
- Adopt FAST if you are a delivery scientist or engineer who needs a secured, web-accessible AgentCore app in an AWS account and would rather edit prompts and tools than write Cognito and CDK wiring. Do not adopt it if you need a framework that constrains agent behaviour, or if you are deploying outside AWS, since AgentCore is described as its only central dependency.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The undifferentiated heavy lifting FAST is meant to remove
The README is direct about the target user: delivery scientists and engineers, not frontend or infrastructure specialists. The stated goal is to move a full stack AgentCore application from weeks to days by handling what the author calls the undifferentiated heavy lifting. That phrase is doing real work here. What FAST removes is not the agent, and not the prompt. It removes the Cognito user pool, the Amplify hosting, the API Gateway authorizer, the AgentCore Runtime and Gateway configuration, and the deployment scripts that tie them together. What remains, by the README's own framing, is prompt engineering and GenAI implementation details. That is a narrow and specific claim, and it is the right one to evaluate the project against. If your bottleneck is agent logic rather than account wiring, FAST does not address your bottleneck. If your bottleneck is that nobody on the team wants to write a Cognito authorizer, it does.
What the baseline system ships, and why it is deliberately small
The out-of-the-box application is a multi-turn chat agent with tools. The README calls it very, very simple and then insists this should not deter anyone whose use case is entirely different, because customizing FAST is the intended use. Two tools are wired in. The first is a Gateway tool: a Lambda behind AgentCore Gateway with authentication, which counts words and letter frequency in text. The second is the AgentCore Code Interpreter, which runs Python in an isolated sandbox with session management and state persistence, on a prebuilt runtime with common libraries. Neither tool is interesting on its own. Their value is that they exercise two different execution paths, one through Gateway with auth and one direct to a managed sandbox, so the plumbing for both is already proven when you replace them. A team that reads the tool list as the product has misread the repository; a team that reads it as two worked examples of how to attach a tool has read it correctly.
The four authentication flows, and where they can break
The architecture diagram documents four flows, and they are the most substantive part of the material. A user signs in to the React app hosted on Amplify against a Cognito User Pool using the Authorization Code grant, and Cognito returns a JWT access token. The frontend sends that JWT in the Authorization header to AgentCore Runtime, which validates it against the same user pool. Separately, the frontend calls API Gateway, authenticated by a Cognito User Pools Authorizer using the same JWT. The interesting leg is the third: Runtime authenticates to Gateway with the OAuth2 Client Credentials grant, machine to machine, and user identity is propagated into that M2M token by a Cognito V3 Pre-Token Lambda. Gateway then evaluates Cedar policies against the user's claims for fine-grained access control. That design means the Gateway never trusts a bare service identity; it sees who the original user was. It also means the Pre-Token Lambda is load-bearing. If the claims it injects are wrong or missing, the Cedar evaluation has nothing to match on, and the failure will look like an authorization denial rather than a token bug. That is the first place to look when Gateway calls fail in a fork.
Deploying the baseline: five commands and a choice you must make
The README gives the CDK path explicitly. From infra-cdk, run npm install, then cdk bootstrap once per account and region, then cdk deploy. Then, from the repository root, run python scripts/deploy-frontend.py. That is the whole out-of-the-box deployment. A Terraform path exists in infra-terraform/ with its own README, and the guidance is to choose one infrastructure tool and delete the other directory from your fork. Take that instruction literally. Keeping both means two sources of truth for the same stack, and any change you make to one silently diverges from the other. The repository also carries a docker/ directory with a docker-compose.yml and a Dockerfile.frontend.dev for local frontend development, which is where you would iterate on UI before redeploying. Detailed instructions live in docs/DEPLOYMENT.md rather than in the README, which is consistent with the project's stated position that best practices belong in documentation rather than in code.
Documentation as the extension mechanism, and the risk that carries
FAST's central design choice is that expert knowledge is codified in documentation in the repository, not in code. The README describes including that documentation in an AI coding assistant's context, or instructing the assistant to use the best practices and snippets found there, so that the assistant can customize the frontend and infrastructure. Steering docs and assistant rules (there is a .amazonq/ directory for Amazon Q, and GitHub Actions under .github/workflows/) exist to push assistants toward those docs. This is a real mechanism, not marketing, but it has a failure mode worth naming. The quality of what you get out depends on the assistant actually reading the docs, and nothing in the repository enforces that. The README claims agnosticism across agent SDKs (Strands, LangGraph and others) and across coding assistants (Q, Kiro, Cline, Claude Code and others), which is what makes the template broadly usable and also what makes it thin. A template that supports every assistant cannot tune its steering for any one of them. Expect to spend time checking that generated infrastructure matches the security posture the docs describe, rather than assuming the assistant applied it.
Where FAST is the wrong tool
Two cases stand out. The first is any deployment target that is not AWS. AgentCore is described as the only central dependency, and every flow in the architecture diagram runs through Cognito, Amplify, API Gateway, Lambda or AgentCore itself. There is no portable core to lift out. The second is a team that wants the framework to decide how agents are structured. FAST is explicitly agnostic to agent SDK, which means it takes no position on agent design; it gives you a place to put an agent and a secure path to reach it, and nothing more. If you need opinionated orchestration, you are bringing that yourself. A third, softer case: the project has no releases retrieved, so there is no versioned artifact to pin against. You are adopting a repository at a commit, and your upgrade path is whatever the maintainers push to main. For a starter template that is arguably correct, since you fork it once and own it, but it does mean you cannot treat FAST as a dependency you bump.
The alternative: building the same stack by hand
The realistic alternative is not another template. It is assembling the pieces yourself: a Cognito user pool with an Authorization Code grant, an Amplify-hosted React app, an API Gateway with a Cognito authorizer, an AgentCore Runtime and Gateway, and a pre-token Lambda to carry user identity into the M2M token. The difference is not capability, since FAST is built from those same services. The difference is where the decisions live. Hand-building puts every auth flow, Cedar policy and IAM boundary in code you wrote and can explain line by line. FAST puts them in a baseline you inherited, documented in prose that an assistant is supposed to read. For a team with an existing platform group and strong opinions about identity, hand-building avoids inheriting decisions you would have made differently. For a delivery scientist with a use case and a deadline, FAST is the shorter path, and the trade is that you must audit the inherited auth flows before you put real users behind them.
Licence and maintenance
FAST is Apache-2.0, which permits commercial use, modification and redistribution, and includes an express patent grant. It also requires that you retain the licence and attribution notices, and it provides no warranty. That is a permissive licence, but it is not a legal opinion and the terms should be read in full before you redistribute a fork. On maintenance, the honest read of the material is that FAST is designed to be forked and then owned by you, not consumed as a library. The README frames your task as customizing the fork, and with no releases retrieved there is no version to track. Upstream changes to the baseline therefore arrive as repository history you must diff against your fork by hand. The practical cost is concentrated in the auth flows: if the Pre-Token Lambda or the Cedar policy wiring changes upstream, that is the part of your fork most likely to need the change merged, because it is the part you are least likely to have modified intentionally.
Editorial conclusion
Adopt FAST if you are a delivery scientist or engineer who needs a secured, web-accessible AgentCore app in an AWS account and would rather edit prompts and tools than write Cognito and CDK wiring. Do not adopt it if you need a framework that constrains agent behaviour, or if you are deploying outside AWS, since AgentCore is described as its only central dependency. Before committing, verify three things in your fork: that the four authentication flows in the architecture diagram match your identity requirements, that the Cedar policies on the Gateway express your access rules, and that you have deleted whichever of infra-cdk/ or infra-terraform/ you are not using, because the README says to pick one and remove the other.
Community notes