Backend / Cloud: AWS / Developer tools / README.md

AWS Amplify Gen 2

Updated 4 min read index source
On this page6
  1. What changed in Gen
  2. What it actually provisions
  3. Authorisation is the part worth knowing
  4. Where it fits, and where it does not
  5. Related
  6. Interview angle

AWS Amplify Gen 2

Amplify is AWS’s full-stack toolkit: it provisions the backend a web app needs

  • auth, data, storage, functions - and hosts the frontend. Gen 2, generally available since 2024, is a rewrite of how that backend is defined.

What changed in Gen 2

Gen 1 was a CLI that asked questions and wrote generated config. Gen 2 defines the backend as TypeScript in your repository.

ts 
// amplify/data/resource.ts
const schema = a.schema({
  Invoice: a.model({
    total: a.float().required(),
    status: a.enum(["draft", "sent", "paid"]),
  }).authorization(allow => [allow.owner()]),
});

That file is the source of truth. It generates the DynamoDB tables, the AppSync GraphQL API, the resolvers, and a typed client for the frontend - so the React code gets completion on a model you defined once.

The practical consequences:

  • Per-developer sandboxes. npx ampx sandbox deploys a personal cloud stack that redeploys on save, replacing the shared-dev-environment problem.
  • Branch-based environments. A git branch maps to a full environment, because the backend definition is in the branch.
  • It is CDK underneath. Gen 2 compiles to CloudFormation via CDK, and you can drop into raw CDK for anything the shortcuts do not cover.

What it actually provisions

Amplify concept The AWS service
defineAuth Cognito user pool and identity pool
defineData AppSync plus DynamoDB
defineStorage S3 with access rules
defineFunction Lambda

This table is the answer to most Amplify interview questions. Nothing here is new infrastructure - it is a code generator over services you could write by hand, with the wiring and IAM roles filled in.

Authorisation is the part worth knowing

Amplify’s authorization rules compile into AppSync resolver logic, which is what makes the data layer usable without writing a backend.

ts 
.authorization(allow => [
  allow.owner(),                       // creator only
  allow.group("admin"),                // Cognito group
  allow.authenticated().to(["read"]),
])

allow.owner() stamps the record with the caller’s Cognito subject and filters every query by it. That is real per-row authorisation without a service layer, and it is why Amplify suits multi-user CRUD apps.

The limit is equally important: these rules are per-model, evaluated at the API. Cross-model invariants (“only the invoice owner’s accountant may read the linked payment”) do not express well, and you end up in a custom resolver or a Lambda - at which point a normal API may have been the simpler start.

Where it fits, and where it does not

Good fit. A React or Next.js app with standard auth, CRUD over per-user data, file uploads, and a small team that wants to ship without operating infrastructure. Amplify Hosting adds CI/CD, preview environments per pull request, and a CDN.

Poor fit. A Python backend. Amplify’s data layer generates JavaScript and GraphQL resolvers; a FastAPI service is not what it wants to sit in front of. If the backend is Python, use Amplify only for hosting the frontend, or skip it and use API Gateway with Lambda directly.

The lock-in question. The generated backend is CloudFormation, so it is inspectable and exportable, but the model definitions, the typed client and the authorisation DSL are Amplify’s. Moving off means rewriting the data layer. That is an acceptable trade for a product finding its shape and a bad one for a system with an established backend team.

Interview angle 5

  • “What is Amplify Gen 2 and how does it differ from Gen 1?” - a full-stack toolkit where the backend is defined as TypeScript in the repository rather than by a CLI writing generated config. Because the definition lives in the branch, each branch is an environment and each developer gets a personal cloud sandbox that redeploys on save.
  • “What does it actually create?” - Cognito for auth, AppSync over DynamoDB for data, S3 for storage, Lambda for functions, compiled to CloudFormation through CDK. It is a generator over services you could wire by hand, and you can drop to raw CDK when the shortcuts run out.
  • “How does authorisation work?” - declarative per-model rules that compile into AppSync resolvers. allow.owner() stamps the Cognito subject on the record and filters queries by it, giving per-row authorisation with no service layer. The limit is that rules are per-model, so cross-model invariants push you into custom resolvers.
  • “Would you use it with a Python backend?” - not for data. The generated layer is GraphQL and JavaScript, so it does not sit in front of FastAPI. Use Amplify Hosting for the frontend and API Gateway with Lambda for the Python API.
  • “What is the lock-in?” - the output is CloudFormation and inspectable, but the schema DSL, authorisation rules and typed client are Amplify-specific, so leaving means rewriting the data layer. Fine for a product still finding its shape, poor for an established backend.

Contents 0