aws-ai-stack: a five-service Serverless Framework boilerplate for Bedrock

Five services, one compose file

The top-level tree is the architecture diagram:

ai-chat-api/  auth/  business-api/  business-worker/  event-bus/  website/

Each directory is its own Serverless Framework service, coordinated by `serverless-compose.yml` at the root. That single file is the reason the project is worth reading: it makes the dependency order between services explicit rather than implicit, which is usually the hardest part of adopting the Serverless Framework on a multi-service codebase.

The root `package.json` is minimal and worth quoting in full, because it explains the dependency story:

  "name": "serverlessinc-example",
  "version": "1.0.0",
  "description": "Lambda AI Boilerplate (LAB) for Serverless Framework V.4",
  "private": true,
  "workspaces": [
    "**"
  ]

The workspaces glob of `"**"` means one root install covers every service, and the name `serverlessinc-example` plus the description calling it the Lambda AI Boilerplate are leftovers from the Serverless Inc example this grew out of. The description also pins the framework version at V4, which matters because Serverless Framework v3 and v4 differ in configuration and plugin behaviour.

The README states the domain-oriented intent directly: you can easily remove the pieces you do not need, like AI Chat or authentication. The `event-bus/` directory is the shared layer that makes the async design work, since the business API publishes to EventBridge and the worker consumes from it.

What each service actually gives you

The feature list is the honest inventory of this repository, so it is worth reading as a checklist of what exists in code.

The auth service is the most complete. It provides an API Gateway authorizer, login and registration endpoints on Lambda with Express.js, a DynamoDB table for user records, a shared library for JWT token authentication, and a frontend wired to those endpoints. That is a real auth flow rather than a stub, and the JWT approach is a reasonable default for a first deployment with the caveat that rotating the shared secret invalidates existing sessions.

The AI chat service implements streaming responses on Lambda, calling Bedrock, which is the piece people usually struggle to get right because streaming responses from Lambda through API Gateway require response streaming rather than a buffered return. The README lists supported models as Claude 3.5 Sonnet, Llama3.1, Mistral Large 2 and others via Bedrock, and states plainly that application data never leaves AWS and is not sent to model providers. That is the substantive privacy argument for the architecture, and it holds as long as you do not add your own third-party model call.

The business API is an Express.js placeholder for your own logic, and the worker consumes events from the shared EventBridge bus. Both are scaffolding by design.

On the front end, the README calls it a vanilla React app served from a Lambda function, which is a slightly odd combination of words that works out to mean a Vite-style build served as a static site through the function, configured locally with `VITE_` environment variables.

Deploy, then switch to dev mode for everything else

The getting started path is three steps, and the third one is the one to notice. Install the framework globally, install dependencies once at the root, and deploy:

npm i -g serverless

serverless deploy

The README points at Serverless Dev Mode for day-to-day work, which emulates Lambda locally and proxies requests to the real service, and it can be run per service:

serverless auth dev

Redeploying an individual service takes the service name as an argument, which is what makes the per-service split pay off once you are iterating:

serverless auth deploy

The website service is treated separately because a static site served from a Lambda function does not need Dev Mode. It does need to know where the other two services live, and the README gives you the command to extract those URLs from the deployed stacks:

export VITE_CHAT_API_URL=$(serverless aiChatApi info --json | jq -r '.outputs[] | select(.OutputKey == "ChatApiUrl") | .OutputValue')
export VITE_AUTH_API_URL=$(serverless auth info --json | jq -r '.outputs[] | select(.OutputKey == "AuthApiUrl") | .OutputValue')

Then you build and run locally as usual. Note that the service identifier in that command is `aiChatApi`, while the README refers to the same service elsewhere as `ai-chat`, so the exact name you pass to the CLI matters and the prose is not entirely consistent about it. The website also needs this configuration on first run, which is the one friction point in an otherwise smooth local workflow.

Bedrock model access is the step that blocks newcomers

Before deploying, you have to enable the underlying model in the Bedrock console, and the README devotes the most cautionary prose in the document to this. The example requires `meta.llama3-70b-instruct-v1:0` to be enabled, AWS does not enable models by default, and you must request access per model through the console. Enabling is free, but AWS sends a confirmation email and it can take a few minutes.

The failure mode the README warns about is permissions. Some users cannot enable models because their AWS account lacks sufficient permissions, and the advice is specific: accounts that are new, or that have never had a monthly invoice over a few dollars, may have to contact AWS directly to get models enabled. That is the single most common reason a first deployment of this project fails, and it is not a code problem.

Model names matter too, and they date. The topic list on the repository still includes `llama3`, and the README names Claude 3.5 Sonnet and Mistral Large 2 as available options. Since Bedrock's catalogue changes frequently, treat those as the identifiers the boilerplate was written against rather than a current list, and check what your region actually offers before planning around a particular model.

Custom domains are handled through the `serverless-domain-manager` plugin for API Gateway services and CloudFront distributions for Lambda services, and the README says custom domain naming is disabled for anything other than `prod` deployments.

Multi-environment setup and what CI does for you

Configuration is shared across services with per-environment overrides, which is the Serverless Framework's `${opt:stage, self:provider.stage}` pattern rather than anything specific to this project. The production path in the README is about custom domains and setting a new shared secret for JWT authentication, which is the step that matters most for security: the development secret should not reach production, and rotating it invalidates every issued token.

The CI/CD story is described in two sentences in the feature list: GitHub Actions deploy the services to production, and GitHub Actions deploy pull requests and remove the services after merge. Ephemeral preview environments per pull request are the expensive part of serverless and the part most likely to surprise you on the AWS bill, since every PR creates API Gateway stages, Lambda versions and DynamoDB tables. If you enable this, put a cleanup check on your roadmap.

The GitHub Actions live under `.github/` in the tree, which is where you would add region selection, permissions scoping or a manual approval gate for the production deploy. None of that is described in the README, so treat the workflows as a starting point rather than a hardened pipeline.

Multi-environment support is listed as a feature, and combined with the per-PR teardown it means the boilerplate assumes you want to exercise environment parity rather than deploying one stack and hoping.

Licensing and repository state, stated plainly

Two facts about this repository deserve to be known before you build on it, and neither is hidden.

The first is licensing. No licence is declared anywhere: the root tree contains no `LICENSE` file, and the root `package.json` has no `license` field and is marked private. Without a licence file, the default copyright position applies, which means the legal default is that you may read it but not redistribute it. For a boilerplate you intend to fork as the starting point for a commercial product, that is worth resolving with the project before you rely on it. The name and description in `package.json` also indicate this began as a Serverless Inc example, and examples carry different expectations from a licensed product.

The second is that the README is not complete. It ends partway through the sentence describing production custom domain setup, so the production hardening steps you would most want to read are not in the document. What the README does cover, it covers well: installation, Bedrock enablement with the permission caveat, deployment, local dev mode, per-service redeployment and the URL wiring for the website.

The project is not archived and the last push was 2026-05-12, with 1,006 stars, 91 forks and 7 open issues. There are no published releases, so there is no changelog and no version history to consult, and `serverless.yml` versions across the services are the only place version pinning is recorded. For a reference architecture that is tolerable. For production infrastructure, read the `serverless.yml` files before you trust them.

Editorial conclusion

aws-ai-stack is at its best as a reference architecture you read rather than a template you adopt wholesale. The tree makes the shape of a serverless AI product legible in one screen, with auth, chat, business logic, async events and a frontend each as a separately deployable unit, and the domain-oriented framing means you can delete the parts you do not want. What it does not give you is a finished product or a support commitment: no releases, no licence file in the tree, and a README that stops partway through the production setup section. Copy the service layout and the Bedrock enablement steps, then replace the placeholder business logic with your own.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. serverless/aws-ai-stack on GitHub