Concepts

The @aws/nx-plugin is an Nx plugin that provides a toolkit for building and deploying full-stack applications on AWS. It gives you a collection of Generators which scaffold production-ready application code and the infrastructure to deploy it — type-safe, locally runnable, and ready to ship.

Rather than starting from a blank page, you (or your AI agent) pick the components you need — APIs, websites, authentication, AI agents, infrastructure — provide a few configuration options, and the plugin generates best-practice starter code. It even wires projects together for you (including updating existing files via AST transforms) to produce type-safe clients between your frontend and backend.

Built on Nx and its generators

Nx is a smart build framework for managing monorepos. It is language agnostic, letting TypeScript, Python, infrastructure and more live and build together in a single workspace. Its build system uses caching and dependency graph analysis to only rebuild what changed and run tasks in parallel, keeping testing, linting and building fast as your workspace grows.

Every piece of functionality in the @aws/nx-plugin is delivered as an Nx Generator — automated scaffolding that produces consistent code structures from predefined templates. Generators can be invoked via the Nx CLI, the Nx Console IDE plugin, or by your AI assistant through the Nx Plugin for AWS MCP Server.

Because every component is a generator, you only add what you need, when you need it. Start with an API, add a website later, connect them when you’re ready — each step is a single command.

Build with proven frameworks

The @aws/nx-plugin deliberately avoids building custom abstractions on top of the tools you already know. Instead of inventing bespoke frameworks, runtimes or wrappers, it scaffolds idiomatic code using established, widely-adopted open-source projects. This means your existing skills carry over directly, you can rely on the official documentation for each framework, and you’re never locked into a layer that only this plugin understands.

The generated code stands on the shoulders of best-in-class frameworks, including:

MCP

AWS CDK

Terraform

The plugin’s value is in how these pieces are configured and connected together for AWS — not in replacing them.

Open for modification

All generated code is your code. The @aws/nx-plugin is a build-time tool, not a runtime dependency — once a generator has run, the plugin is no longer in the picture. You can read every file it produced, commit it, and change it however you like.

This means:

No escape hatches. There’s no proprietary configuration surface to learn or wrestle with when you need to do something the generator didn’t anticipate. You edit the generated code directly, the same way you would edit any code you wrote yourself.
No new layers of abstraction. Generators emit plain, idiomatic code for the underlying frameworks. There’s no wrapper API or magic indirection sitting between you and React, tRPC, FastAPI, CDK or any of the other tools — what you see is what runs.
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-plugin at runtime, so you’re never blocked by it and never locked in.

If you don’t like something in the generated code, you are free to modify it. Generators give you a head start, not a cage.

Minimal dependencies

The @aws/nx-plugin strives to keep the number of global dependencies to a minimum. What you need to get started boils down to which generators you invoke.

As an example, any TypeScript-based generator will only require Node to be installed. For Python-based projects, UV is the only requirement.

Type safety

The @aws/nx-plugin employs type-safety to simplify the developer experience via IDE completions, while also eliminating runtime errors which would otherwise only surface in a non type-safe implementation. As such, all components that are vended are type-safe by default.

Type safety flows across project boundaries: when you connect a website to an API, the generated client shares types with the backend, so a change to an API contract surfaces as a compile-time error in your frontend rather than a bug in production. Refactor with confidence.