Skip to main content

AWS Glossary

AWS Amplify Gen 2

Amplify Gen 2 is the TypeScript-first, code-first rewrite of AWS Amplify — defining auth, data, storage, and functions in code with sandbox per-developer environments.

Definition

AWS Amplify Gen 2 is the second-generation rewrite of AWS Amplify. You define auth, data, storage, functions, and AI resources in TypeScript under amplify/, and npx ampx deploys branch environments and per-developer sandboxes. Gen 2 replaces the Gen 1 CLI-and-JSON workflow with a code-first model built on AWS CDK under the hood — the practical AWS answer for React, Next.js, React Native, and similar teams that want managed backends without assembling CDK pipelines from scratch.

When to use it

  • Building full-stack web or mobile apps on React, Next.js, Vue, Angular, Swift, or Android with a managed AWS backend
  • Teams that want per-developer sandboxes without maintaining separate CDK bootstrap stacks for every engineer
  • MVPs and production apps where AppSync + Cognito + S3 + Lambda patterns fit, and TypeScript is the team default
  • Bedrock-backed features via Amplify AI Kit when you want model calls wired into the same backend definition

When not to use it

  • Workloads that need custom VPC topology, Direct Connect, or hybrid networking as first-class concerns — use CDK or Terraform
  • Fine-grained control over every AppSync resolver, pipeline, or VTL template — Amplify abstracts the data layer
  • Polyglot backend teams without TypeScript — Gen 2 is intentionally TS-first
  • Replacing a mature Gen 1 app in one cutover — migrate feature by feature using AWS’s migration path

Tips

  • Treat amplify/backend.ts (or your defineBackend entry) as the contract: one place for auth, data, storage, and function wiring
  • Run npx ampx sandbox delete when a feature branch merges — orphaned sandboxes are a common silent cost leak
  • Drop into raw CDK constructs inside Amplify when you need resources Amplify does not wrap (custom VPC endpoints, unusual IAM patterns)
  • Pin Amplify package versions across the team; Gen 2 moves quickly and mismatched @aws-amplify/backend versions cause synth drift
  • Use branch-based deploys for staging and production; reserve sandboxes for individual developer iteration

Gotchas

Serious

  • Sandbox sprawl: Each engineer’s sandbox creates real AWS resources. Without cleanup policy or lifecycle automation, idle sandboxes accumulate spend and orphaned Cognito pools.
  • Gen 1 assumptions: Gen 1 amplify push workflows, category folders, and CLI prompts do not map 1:1. Porting config without reading the Gen 2 data/auth APIs breaks auth flows silently.
  • Over-abstraction: Teams that fight Amplify’s opinions on the data layer often fork resolvers in ways Amplify upgrades overwrite — know when to exit to CDK for that slice.

Regular

  • Amplify Hosting and Amplify backend are related but deployed through different commands — confusing the two delays first deploy.
  • Local ampx sandbox requires valid AWS credentials with deploy permissions; SSO session expiry mid-sandbox shows up as cryptic CloudFormation failures.
  • Generated client types lag schema changes until you re-run codegen — stale types cause runtime mismatches that TypeScript does not catch at build time.

Official references

Need help with this topic?

Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.