We skip “what is a category.” This chapter covers the concepts that matter at production scale: how Amplify Gen 1 and Gen 2 actually differ architecturally, what an environment really is under the hood, and how the resource graph is composed and versioned.

Gen 1 (CLI-driven) vs. Gen 2 (code-first): two different generation models

Amplify Gen 1 uses the `amplify` CLI to interactively scaffold categories (auth, api, storage) into local configuration that gets synthesized into CloudFormation templates and pushed. Amplify Gen 2 inverts this: infrastructure is defined directly in TypeScript files (`amplify/backend.ts`, `auth/resource.ts`, `data/resource.ts`) that are type-checked and compiled into CloudFormation by the Amplify backend engine, without the same category-wizard interaction model. The practical advanced-level distinction: Gen 2 treats backend definitions as ordinary application code — reviewable in pull requests, refactorable with your IDE’s tooling, testable in isolation — whereas Gen 1’s generated `amplify/backend/*` directory is semi-generated state that’s harder to diff meaningfully and easier to drift from intent.

An “environment” is a fully separate CloudFormation stack tree

Each Amplify environment (`dev`, `staging`, `prod`) is not a configuration flag — it is an entirely separate deployment of the resource graph, with its own CloudFormation stacks, its own Cognito user pool, its own AppSync API, and its own DynamoDB tables. This matters at the advanced level because data does not automatically flow between environments; a user created in the `dev` Cognito pool simply does not exist in `prod`, and switching environments via `amplify env checkout` repoints your local project at an entirely different backend, not a different config value on the same backend.

Data modeling compiles down to AppSync + DynamoDB, not a bespoke database

The Amplify Data category (GraphQL Transformer / `a.schema()` in Gen 2) is a code-generation layer over AWS AppSync and DynamoDB. Directives like `@auth` or authorization rules in Gen 2’s schema builder compile into actual AppSync resolver logic and IAM/Cognito-based authorization rules — understanding that translation is what lets you reason about performance and cost in terms of the underlying DynamoDB access patterns, not just the GraphQL schema.

Understanding what actually happens between `amplify push` (or a Gen 2 sandbox deploy) and a live backend demystifies most of Amplify’s “magic.”

graph LR
  DEF[Backend Definition - TS or CLI State] --> SYNTH[Synthesis: Generate CloudFormation Templates]
  SYNTH --> CFN[CloudFormation Nested Stack Deploy]
  CFN --> COG[Cognito User Pool / Identity Pool]
  CFN --> APPSYNC[AppSync GraphQL API]
  CFN --> DDB[DynamoDB Tables]
  CFN --> FN[Lambda Functions]
  CFN --> S3B[S3 Storage Bucket]
  CFN --> OUT[amplify_outputs.json Generated]
  OUT --> APP[Frontend App Consumes Config]
        

Whether you’re on Gen 1 or Gen 2, the backend definition is ultimately synthesized into a tree of nested CloudFormation stacks — one root stack per environment, with child stacks per category (auth, api, storage). This is why Amplify projects show up as ordinary CloudFormation stacks in the AWS Console: there’s no proprietary runtime managing your resources after deploy, only CloudFormation, exactly as if you’d hand-written the templates yourself.

Amplify Hosting’s build-and-deploy pipeline

For the frontend, Amplify Hosting watches a connected Git branch, runs a build defined in `amplify.yml` inside an isolated build container, and deploys the resulting static assets to a globally distributed CDN. For full-stack branches, Amplify can also trigger a backend deploy as part of the same pipeline run, so a single Git push can update both frontend assets and backend infrastructure atomically from the developer’s point of view — even though, internally, they remain two distinct deploy operations sequenced together.

Tracing a single feature from code change to live, authorized data access shows the full lifecycle Amplify manages across both backend and frontend.

Because Amplify provisions standard AWS services, its scalability ceiling is really the scalability characteristics of Cognito, AppSync, and DynamoDB — understanding that mapping is what lets you reason about limits correctly.

AppSync scales its GraphQL request handling elastically, and DynamoDB tables provisioned by Amplify default to on-demand capacity mode, which scales with traffic without manual capacity planning — but on-demand pricing per request can become expensive at very high, sustained throughput compared to well-tuned provisioned capacity with auto scaling. Advanced teams frequently switch high-traffic tables from on-demand to provisioned mode once traffic patterns stabilize enough to forecast capacity.

GraphQL query design still matters

Amplify doesn’t remove the need for sound data-access design — a poorly modeled `@hasMany` relationship without proper indexes still produces inefficient DynamoDB scans under the hood, no matter how convenient the generated GraphQL query looks. Understanding the underlying single-table or multi-table DynamoDB design Amplify Data generates is essential for diagnosing performance issues at scale.

Because Amplify provisions managed AWS services (Cognito, AppSync, DynamoDB, Lambda, S3), the availability characteristics of an Amplify backend are inherited directly from those services’ own multi-AZ, regionally redundant designs — there is no separate “Amplify availability” to reason about beyond the availability of its constituent services.

Rollback and environment isolation as reliability tools

Because each environment is a fully separate stack tree, a broken change deployed to `staging` cannot directly corrupt `prod` data — the strongest reliability property Amplify’s environment model provides is this blast-radius containment, not automatic rollback (CloudFormation’s own stack rollback-on-failure behavior handles that part).

Amplify’s security model centers on how Cognito-issued identity flows into AppSync authorization rules, and how IAM roles are scoped for unauthenticated versus authenticated access.

Authorization modes compile into real AppSync rules

When you declare an authorization rule (`allow.owner()`, `allow.group(“Admins”)`, `allow.publicApiKey()`) in the Amplify Data schema, it compiles into an actual AppSync authorization configuration — Cognito User Pool auth, IAM auth, or API key auth — attached per operation. Mixing authorization modes on the same model (say, public read via API key, owner-only write via Cognito) is fully supported but must be modeled deliberately, since the default mode applies unless a field or operation explicitly overrides it.

graph TD
  REQ[Client GraphQL Request] --> AUTH{AppSync Auth Check}
  AUTH -->|Cognito JWT valid + owner match| ALLOW_OWNER[Allow: Owner-Scoped Access]
  AUTH -->|Cognito group claim matches| ALLOW_GROUP[Allow: Group-Scoped Access]
  AUTH -->|Valid API key, public rule| ALLOW_PUBLIC[Allow: Public Access]
  AUTH -->|No match| DENY[Deny: GraphQL Authorization Error]
        

Unauthenticated identity pool roles are a common oversight

Amplify’s Cognito Identity Pool setup, by default, can grant an “unauthenticated” IAM role for guest access to certain resources (like public S3 reads). Advanced security reviews specifically audit this unauthenticated role’s permissions, since it’s effectively accessible to anyone who loads the app, authenticated or not.

Because Amplify’s backend is composed of standard AWS services, observability follows the same path as any AppSync/Cognito/DynamoDB/Lambda application: CloudWatch metrics and logs per service, plus Amplify Hosting’s own build and access logs for the frontend pipeline.

Because each category maps to a distinct AWS service, there is no single unified “Amplify dashboard” that replaces per-service CloudWatch observability — advanced teams typically build a consolidated dashboard spanning AppSync, DynamoDB, and Cognito metrics for their specific environment.

Amplify’s deployment model centers on Git branches mapped to environments: pushing to a connected branch can trigger both a backend deploy (CloudFormation stack update) and a frontend build-and-release (to the global CDN) as one coordinated pipeline run, giving teams true full-stack preview environments per pull request when configured with branch-based backends.

graph LR
  PR[Pull Request Branch] -->|Push| BUILD[Amplify Hosting Build Container]
  BUILD -->|amplify.yml build steps| DEPLOY_BE[Backend Deploy - CloudFormation Update]
  BUILD -->|Frontend build output| DEPLOY_FE[Frontend Deploy - Global CDN]
  DEPLOY_BE --> PREVIEW[Full-Stack Preview URL]
  DEPLOY_FE --> PREVIEW
        

Multi-team projects typically layer standard CI checks (linting, tests, security scanning) around Amplify’s own build pipeline rather than relying on it exclusively, since `amplify.yml` is oriented toward build-and-deploy steps, not general-purpose CI orchestration.