Who hasn’t built a full-stack app on AWS before, we all know the drill. You need an API (usually Lambda with API Gateway), a frontend, some authentication (Cognito) wired up, and IaC (CDK) to help deploy the app. On their own, none of that is hard, but wiring it up all together, especially in a team where every developer has their own style, always takes an amount of time before you even get to write a single line for the business logic.
Nx Plugin for AWS (@aws/nx-plugin), an AWS Labs open source project, tackles that problem with code generators built on top of Nx. Instead of once again writing out boilerplate for every new service or website, you can just run a generator (CLI), answer a few questions, and get production-ready application code plus the CDK or Terraform to deploy it.
This article introduces what the plugin does, the core concepts, and how to scaffold a complete full-stack app. What sets Nx Plugin apart from just another scaffolding tool?
A note on versioning: at time of this article the plugin was pre-1.0, currently working through a
1.0.0-rc.xrelease candidate series with regular updates. Commands and generator names below were accurate at time of writing, checknpm view @aws/nx-plugin versionbefore you start, given the pace, it’s likely to have moved on since this article published.
A quick primer on Nx
For the uninitiated Nx is a toolkit specifically for monorepos. Two things define Nx:
- A dependency graph across projects. Nx knows how the individual parts of your projects relate to each other (which website depends on which API, which library is shared where), and it uses that graph to only build, test, or lint the things actually affected by a change, with results cached so recurring CI/CD runs should be fast.
-
Generators. Nx has a plugin system where a package can register generators, scripts that scaffold or modify code in your workspace, invoked via the
nx g(ornx generate) command. This is the bit@aws/nx-pluginbuilds on.
Nx is not AWS-specific, rather AWS adopted and built their plugin on top of Nx. @aws/nx-plugin doesn’t replace any of that, it’s a collection of generators in your toolbag that plug into your codebase.
Ideally suited for greenfield projects, with a bit of uplift can work with existing codebases.
So when you run pnpm nx g @aws/nx-plugin:ts#api, you’re using Nx’s own generator mechanism, just pointed at generators AWS Labs has written and opinionated toward AWS services. That also means everything else Nx gives you for free, the dependency graph, caching, task running, applies to the projects the plugin generates without any extra setup.
What it actually gives you
@aws/nx-plugin is a collection of generators for Agentic, API, Lambda, Data Storage, Website (inc Auth), IaC on AWS.
- End-to-end by default. Generators produce both application code and the accompanying infrastructure (CDK or Terraform), so you’re not left in the lurch wiring up deployment separately.
- Component-based. You add pieces as you need them, an API here, a website there, rather than committing to one overwhelming opinionated template.
- Your code, not a black box. Everything generated is regular source in your repo. If you don’t like something, edit it. There’s no hidden framework layer to fight later.
- Type-safe by design. Where it makes sense, type safety flows through from backend to frontend.
- Local-first development. One of the strengths of Nx is you can develop and iterate against pure local dev and testing, alternatively your local code can also be pointed towards your deployed AWS resources.
Worthy callouts
Everything sits inside your monorepo, thanks to Nx Plugin for AWS, you can use it without knowing about Nx which means you get all the benefits of Nx’s dependency graph, caching, and task running without the learning curve for your project.
The @aws/nx-plugin is a build-time tool, not a runtime dependency. Once a generator has performed its job, the plugin is no longer relevant.
You can read every file it produced, commit it, and change it however you want afterwards.
This means:
- There’s no proprietary learning curve or configuration to wrestle with when you need to do something the generator didn’t anticipate. You take what was given to you and edit the generated code directly, the same way you would edit any code you wrote yourself.
- No new layers of abstraction. Generators emit plain code. There’s no opinionated wrapper API or unknown black box getting between you and frontend, backend, CDK or any of the other tools; what you see is exactly what you get.
- The plugin isn’t a dependency. It generates code and steps out of the way. Your application doesn’t import or rely on
@aws/nx-pluginat runtime, so you are never locked in, and there’s no unsightly evidence of it in your code repository either. If you don’t like something in the generated code, you are free to modify it. Generators exist to get you started, not to be a prison with a lock and key.
The generators
Here’s the current set of generators available:
Generator What it doests#project
TypeScript library
ts#api
TypeScript API (tRPC or Smithy) with API Gateway, Lambda, and Powertools
ts#rdb
Relational database support via Aurora RDS
ts#website
React app (Vite)
ts#website#auth
Adds Cognito auth to a website
ts#infra
AWS CDK infrastructure project
ts#lambda-function
TypeScript Lambda with type-safe event sources
ts#mcp-server
MCP server (TypeScript)
ts#agent
Strands Agent (TypeScript)
py#project
Python project (managed with uv)
py#api
Python API (FastAPI) with API Gateway, Lambda, and Powertools
py#lambda-function
Python Lambda with type-safe event sources
py#mcp-server
MCP server (Python)
py#agent
Strands Agent (Python)
connection
Wires projects together, e.g. connecting a frontend to a backend API
terraform#project
Terraform project, for teams that prefer Terraform over CDK
license
Manages LICENSE files and source headers across the workspace
This is a slice, not the full list, the plugin also ships generators for DynamoDB, relational databases in Python, docs sites, and agent-specific infra (AgentCore gateway/harness) among others. See the full generators list in the docs sidebar for everything currently available.
The connection generator is the real workhorse
Sure adding individual components is great, however getting these individual components to play nicely with each other is another.
So my favourite generator: connection is just magic.
It transforms your project in meaningful ways that make sense, i.e connecting a React site to a API actually generates the wiring between the two, rather than leaving you to do it by hand.
A few of the pairings it supports:
React website to an API backend. It generates a type-safe client, sets up the provider your React app needs, and configures auth (IAM or Cognito) so calls are signed correctly. If your API’s types change later, your frontend calls stay in sync without you touching the wiring again.
Frontend to an Agent. Same idea as the API case, your website gets a typed way to talk to a deployed agent.
Agent to an MCP server. Agents often need tools, and MCP servers are how the plugin exposes them. connection handles the IAM-authenticated link between an agent and an MCP server so the agent can call its tools without you writing the boilerplate auth and transport code by hand.
Agent to Agent. Connect two agents together using the A2A protocol.
API (or Agents) to Data. Data meaning Relational Database or Dynamo DB.
Service to service, more generally. Anywhere you’ve got a source project that needs to call a target project’s API, connection is the generator that sets up the client, the auth, and the local dev configuration in one go.
For sake of brevity, too many permutations so better to check out list of various supported connections.
Prerequisites
Before you start, you’ll need:
- Git
- Node 22 or later
- A package manager: pnpm 10+, yarn 4+, bun 1+, or npm 10+
-
uv 0.5.29 or later, plus Python 3.12 (
uv python install 3.12.0) - AWS CLI configured, profile/SSO credentials for the AWS account you’re deploying to
- Docker (Docker Desktop on Mac/Windows, the Engine directly on Linux), or Finch 1.6.0+, required for some generators
Optional IDE extensions
You can get a UI over the generators for the major IDEs, which is useful for those devs like me who may not prefer the terminal experience. Both editors’ extensions are thin wrappers around the same underlying Nx Language Server, so functionality is on par.
JetBrains official Nx Console plugin for JetBrains IDEs (WebStorm, IntelliJ IDEA Ultimate, and others), built and maintained by the Nx team rather than a community fork, with the same generator UI and project graph view.
VS Code, install the Nx Console extension too.
Scaffolding a project
Here’s a typical flow: an API, a AI agent (Strands), a React website with Cognito auth, connected together, with CDK infrastructure to deploy it.
# Create a new workspace
pnpm create @aws/nx-workspace my-project
cd my-project
# Add an API (tRPC)
pnpm nx g @aws/nx-plugin:ts#api --framework=trpc
# Add a Strands AI agent (Python)
pnpm nx g @aws/nx-plugin:py#agent
# Add a React website
pnpm nx g @aws/nx-plugin:ts#website --framework=react
# Add authentication to your website
pnpm nx g @aws/nx-plugin:ts#website#auth
# Connect your website to your API and agent
pnpm nx g @aws/nx-plugin:connection
# Add CDK infrastructure to deploy it all (or choose Terraform)
pnpm nx g @aws/nx-plugin:ts#infra
Enter fullscreen mode Exit fullscreen mode
Once that’s done, you can run everything locally with hot reload:
pnpm nx run-many --target=serve --all
Enter fullscreen mode Exit fullscreen mode
Nifty that both your website and API launch with one CLI command, the website will be available at http://localhost:4200, and changes to either the website or the API will hot-reload as you work. When you’re ready to deploy, the generated CDK (or Terraform) project handles pushing it all to AWS.
Build and deploy
Once you’ve defined your cloud resources (e.g. instantiating the generated constructs in CDK, or wiring up the equivalent Terraform modules), building and deploying is a handful of commands:
# Build everything
pnpm build
# Fix any lint errors automatically
pnpm lint
# If the build reports "The workspace is out of sync", sync it
pnpm nx sync
Enter fullscreen mode Exit fullscreen mode
Then bootstrap and deploy your infrastructure project (named infra by default, swap in whatever you actually called yours):
# Bootstrap (one-time per account/region)
pnpm nx bootstrap infra
# Deploy, CDK
pnpm nx deploy-sandbox infra
# Deploy, Terraform (runs plan then apply)
pnpm nx apply infra
Enter fullscreen mode Exit fullscreen mode
Once deployed, pull down the runtime config so your local website points at the real, deployed API and auth resources instead of local ones (again, swap demo-website for your website project’s actual name):
pnpm nx load-runtime-config demo-website
pnpm nx serve demo-website
Enter fullscreen mode Exit fullscreen mode
Better together with AI assistants
In this day and age, a tech article would be incomplete if I didn’t work AI into the conversation. AI assistants and Nx Plugin are individually great on their own, but together they will give the developer a whole new way of working.
Nx Plugin also has an MCP server available. Workspaces created with the plugin’s preset already include automatic project-level MCP config for six common agents: Claude Code, Cursor, Kiro, Gemini CLI, GitHub Copilot, and Codex. Any of those work inside the workspace with no extra setup, and if you’re using another MCP-compatible assistant, you can still skip typing generator commands entirely with a bit of manual config.
Then just describe what you want:
“Use the Nx Plugin for AWS to build a full-stack app with a React website, an API, Cognito auth, and CDK infrastructure.”
The assistant calls the generators for you through MCP, which is a great way to learn the available options if you have not already familiarised yourself with the documentation, i.e. generator flags available.
Configure your AI assistant
Add it with whichever of these matches your setup:
-
Claude Code installs it as a plugin:
/plugin marketplace add awslabs/nx-plugin-for-awsthen/plugin install nx-plugin-for-aws@nx-plugin-for-aws. -
Kiro gets a dedicated Power (bundling the MCP server with steering docs and workflow guides) via the Kiro Powers panel, or the Kiro CLI via
kiro-cli mcp add.
Most MCP-compatible assistants use this JSON in a configuration file. Add the following:
{
"mcpServers": {
"nx-plugin-for-aws": {
"command": "npx",
"args": ["-y", "@aws/nx-plugin-mcp"]
}
}
}
Enter fullscreen mode Exit fullscreen mode
-
Cursor and Codex add the same MCP server entry to their respective config files (
~/.cursor/mcp.jsonor~/.codex/config.toml). - Cline, Roo Code, and other MCP-compatible assistants can support the above json.
Where to from here
I tried out the Quick Start guide from start to finish, it covers the concepts in this article in more depth, and the Dungeon Adventure tutorial is one of the best guided walkthroughs you’ll see, with most of the generators used together in a full working example.
Final thoughts
Pre-1.0 status (see the note near the top) hasn’t put me off, honestly it is already a solid product and provides a great developer experience.
If you’re already building on AWS, I definitely say it is worth a try. Even just using only one generator earns its keep, say connection to wire up an existing frontend and API, can save you a fair amount of repetitive boilerplate.
If you get stuck or want to chat with other people using it, the maintainers hang out in the #nx-plugin-for-aws channel on the CDK Slack.
Links
- Documentation: https://awslabs.github.io/nx-plugin-for-aws
- GitHub: https://github.com/awslabs/nx-plugin-for-aws