Skipping the fundamentals — this chapter assumes you already know Amplify hosts frontends and provisions backends. Here we look at the concepts that actually determine how you use it well.

The Two Amplify Products, and Why the Distinction Matters

AWS actually ships two related but architecturally distinct things under the Amplify name: Amplify Hosting, which is a managed static-site and SSR (server-side rendering) delivery service built on top of S3 and CloudFront, and the Amplify Libraries/CLI (now largely superseded by Amplify Gen 2), which is a backend-as-code toolchain that provisions Cognito, AppSync, DynamoDB, Lambda, and S3 resources from declarative definitions. Confusing the two is the single biggest source of misunderstanding for engineers coming in mid-level: Hosting is a deployment target, the backend tooling is an infrastructure generator. You can use Amplify Hosting with a hand-built backend and no Amplify backend tooling at all, and plenty of production teams do exactly that.

Amplify Gen 2 vs Gen 1: A Real Architectural Shift

Gen 1 Amplify (the CLI-driven `amplify add auth`, `amplify push` model) generated CloudFormation from interactive prompts and stored configuration in a `team-provider-info.json` file that frequently caused merge conflicts in teams. Gen 2 replaced this with TypeScript-defined infrastructure (`amplify/backend.ts`), deployed through AWS CDK under the hood, with per-branch cloud sandboxes. This is not a cosmetic API change — it moves Amplify from “wizard-generated infrastructure” to “code-reviewable infrastructure,” which is the distinction that matters once you’re running Amplify at team scale rather than for a solo side project.

You may likeAWS Elastic Beanstalk→

Fullstack Branch Deployments

A concept beginners rarely encounter but that governs almost everything in a real Amplify setup: every connected Git branch can have its own fully isolated backend environment — its own Cognito user pool, its own AppSync API, its own DynamoDB tables. This is what “fullstack branch deployment” means, and it is the mechanism that lets a `feature/checkout-v2` branch get a completely separate backend from `main` without any manual AWS console work. Understanding this is essential before you can reason about environment sprawl, cost, and data isolation in Amplify.

The Amplify Sandbox

In Gen 2, each developer can spin up a personal, ephemeral cloud backend called a “sandbox” tied to their local machine, distinct from any deployed branch environment. It watches your local backend code and hot-deploys changes to a scratch set of AWS resources in seconds. This solves a real intermediate-level pain point: previously, testing a backend change meant either running against a shared dev environment (risking collisions with teammates) or mocking AWS services locally (drifting from real behavior).

Amplify’s architecture is best understood as a control plane sitting above a set of standard AWS data-plane services.

flowchart TB
    DEV["Developer Git Push"] --> REPO["Git Repository (GitHub / GitLab / Bitbucket / CodeCommit)"]
    REPO --> BUILD["Amplify Build System (CodeBuild-backed)"]
    BUILD --> CDK["CDK Synthesis (Gen 2 backend.ts)"]
    CDK --> CFN["CloudFormation Stack per Branch"]
    CFN --> COGNITO["Cognito User Pool (Auth)"]
    CFN --> APPSYNC["AppSync GraphQL API"]
    CFN --> DDB["DynamoDB Tables"]
    CFN --> LAMBDA["Lambda Functions"]
    CFN --> S3STORE["S3 Storage Bucket"]
    BUILD --> ARTIFACT["Frontend Build Artifact"]
    ARTIFACT --> S3HOST["S3 Hosting Bucket"]
    S3HOST --> CF["CloudFront Distribution"]
    CF --> USER["End User Browser"]
    APPSYNC --> DDB
    LAMBDA --> DDB
    COGNITO --> APPSYNC
    

Amplify Hosting Layer

This layer is responsible for building your frontend (React, Next.js, Vue, Angular, or plain static HTML) inside a managed build container, then publishing the output to an S3 bucket that sits behind a CloudFront distribution. It also manages custom domains, TLS certificates via ACM, redirects and rewrites, and password-protected preview environments for branches.

Amplify Backend Layer

The backend layer is a thin authoring surface over CDK. When you define auth, data, and storage resources in `backend.ts`, Amplify synthesizes those into standard CloudFormation constructs — a Cognito User Pool and Identity Pool for auth, an AppSync GraphQL API backed by DynamoDB for data, and an S3 bucket with fine-grained IAM policies for storage. Nothing here is proprietary infrastructure; it is standard AWS resources wired together with sensible defaults.

What actually happens, step by step, when Amplify builds and deploys your application.

Tracing a single user request from browser to database and back.

sequenceDiagram
    participant U as User Browser
    participant CF as CloudFront
    participant APP as React/Next.js App
    participant COG as Cognito
    participant GQL as AppSync GraphQL
    participant DDB as DynamoDB
    U->>CF: Request app shell
    CF->>U: Cached static assets
    U->>COG: Sign-in request
    COG->>U: JWT (ID + Access Token)
    APP->>GQL: GraphQL query with JWT
    GQL->>COG: Validate token / check auth rule
    GQL->>DDB: Resolve query via VTL/JS resolver
    DDB->>GQL: Item data
    GQL->>APP: JSON response
    APP->>U: Rendered UI
    

The lifecycle splits cleanly into two phases that intermediate engineers often conflate: the deploy-time lifecycle (described in the previous chapter — code becomes infrastructure) and the request-time lifecycle (a live user interacting with that infrastructure). At request time, static assets are served directly from CloudFront’s edge cache with no backend involvement at all — this is why Amplify-hosted apps feel fast even under load, the compute-heavy work only happens for actual data operations. Authenticated data operations route through AppSync, which evaluates authorization rules defined in your data schema (owner-based, group-based, or public rules) before touching DynamoDB at all — authorization is enforced at the resolver layer, not left to application code, which closes off an entire class of bugs where a forgotten server-side check would otherwise leak data.

Real-Time Data via Subscriptions

AppSync additionally maintains WebSocket connections for GraphQL subscriptions, so when one client mutates data, subscribed clients receive a push update without polling. This is the mechanism behind Amplify’s much-cited “offline-first, real-time sync” capability, and it is implemented through DynamoDB Streams triggering AppSync’s subscription resolution pipeline, not through any polling loop on the client.

The Core Trade-off: Velocity vs Control

Every layer of abstraction Amplify adds trades some infrastructure control for delivery speed. A team standing up a new full-stack app can be live with auth, a GraphQL API, and hosting in an afternoon — a genuinely meaningful advantage for prototypes, MVPs, and small-to-mid teams. But that same abstraction becomes friction once requirements diverge sharply from what the generated CloudFormation expects: a team needing a highly customized VPC topology, cross-account resource sharing, or non-standard IAM boundary policies will eventually find themselves fighting the abstraction rather than benefiting from it. The honest framing, used by architects evaluating Amplify for a new project, is that it is excellent for the first 80% of a typical full-stack app’s infrastructure and requires “escape hatches” (direct CDK access) for the remaining 20%.

Because Amplify’s hosting layer is fundamentally S3 plus CloudFront, static asset delivery inherits CloudFront’s scalability characteristics directly: no server to overwhelm, no connection pool to exhaust, effectively unbounded read throughput at the edge. The scaling questions that matter in practice live one layer down, in the backend services Amplify provisions.

You may likeAWS Batch→

AppSync and DynamoDB Scaling

AppSync itself is fully managed and scales horizontally without configuration — there is no “instance count” to tune. The real scaling lever is DynamoDB table capacity mode. Amplify defaults new tables to on-demand capacity, which auto-scales to traffic but carries a per-request cost premium compared to well-tuned provisioned capacity. Teams operating at meaningful scale frequently switch specific hot tables to provisioned capacity with auto-scaling policies once traffic patterns stabilize, trading some operational simplicity for materially lower cost per million requests.

Cold Starts in Lambda Resolvers

Custom Lambda resolvers (used for business logic AppSync’s built-in resolvers can’t express) are subject to standard Lambda cold-start latency — typically 100ms-1s depending on runtime and package size. This is invisible under steady traffic but shows up as tail latency spikes after idle periods, a detail that matters for latency-sensitive interactive features like search-as-you-type.

Amplify inherits the high-availability posture of the underlying managed services it provisions, which is a meaningfully different reliability story than a hand-built app running on self-managed EC2 instances. S3, CloudFront, Cognito, AppSync, and DynamoDB are all AWS-operated multi-AZ services with published availability SLAs, meaning Amplify applications get multi-AZ resilience for free, without the team ever configuring an Availability Zone.

What Amplify Does Not Solve

Multi-Region resilience is a different matter — a standard Amplify app deploys to a single AWS Region by default. Achieving multi-Region failover requires deliberate additional architecture: DynamoDB Global Tables for cross-region data replication, Cognito User Pool replication strategies (which are non-trivial), and Route 53 health-check-based failover routing in front of multiple regional CloudFront distributions. This is squarely an “escape hatch” scenario — Amplify does not hide this complexity, it simply doesn’t solve it by default, and treating single-Region deployment as “highly available” without this additional work is a common intermediate-level misconception.

Authentication and Authorization Are Separate Layers

Cognito handles authentication — proving who a user is — via User Pools, issuing signed JWTs after successful sign-in. Authorization — what an authenticated (or unauthenticated) user is allowed to do — is a separate concern enforced primarily at the AppSync resolver layer through schema-defined rules: owner-based rules (a user can only read/write records they created), group-based rules (tied to Cognito User Pool groups like “admin”), and public/private/protected access rules for S3 storage. Conflating these two layers is a common source of security misconfiguration; a correctly authenticated user with an overly permissive authorization rule can still access data they shouldn’t.

IAM Roles Behind the Scenes

Every Amplify backend resource operates under least-privilege IAM roles generated automatically during synthesis — a Lambda resolver gets only the DynamoDB permissions its code path requires, not blanket table access. This is a genuine security advantage over manually wired infrastructure, where overly broad IAM policies are a persistent, common mistake.

Secrets and Environment Variables

Sensitive values (third-party API keys, database credentials for external systems) are managed through Amplify’s secret storage, backed by AWS Systems Manager Parameter Store, rather than being committed to `amplify.yml` or checked into source control — a distinction that matters because build logs and repository history are both durable, widely-accessible artifacts.

Amplify surfaces build logs directly in its console for every deployment, but the deeper operational visibility — request latency, error rates, resolver-level performance — lives in the underlying services’ native CloudWatch integration, not in Amplify’s own UI. AppSync publishes request/error/latency metrics to CloudWatch automatically; Lambda resolvers log to CloudWatch Logs by default; DynamoDB exposes throttling and consumed-capacity metrics through CloudWatch as well.

What to Actually Watch

For an intermediate operator, three CloudWatch signals matter most in practice: AppSync’s 4XXError and 5XXError metrics (authorization failures vs resolver failures, respectively), DynamoDB’s ThrottledRequests (a strong signal that on-demand capacity or provisioned auto-scaling limits are being hit), and Lambda’s Duration and Throttles metrics for any custom resolvers. None of this is Amplify-specific instrumentation — it is standard AWS service telemetry, which means existing CloudWatch dashboards, alarms, and X-Ray tracing setups a team already runs for other AWS workloads apply directly to an Amplify-provisioned backend with no special adaptation.

flowchart LR
    MAIN["main branch"] -->|auto-deploy| PROD["Production Backend + Hosting"]
    STAGE["staging branch"] -->|auto-deploy| STAGEENV["Staging Backend + Hosting"]
    FEAT["feature/* branches"] -->|auto-deploy| PREVIEW["Ephemeral Preview Environments"]
    PROD --> DOMAIN1["app.example.com"]
    STAGEENV --> DOMAIN2["staging.example.com"]
    PREVIEW --> DOMAIN3["pr-123.example.com"]
    

The amplify.yml Build Specification

Every Amplify app is governed by a build specification file defining discrete phases: `preBuild` (dependency installation), `build` (the actual compile/bundle step), and `postBuild` (optional steps like cache warming). This is directly analogous to CodeBuild’s `buildspec.yml`, which is unsurprising since Amplify’s build system is CodeBuild underneath a managed abstraction.

Preview Deployments for Pull Requests

A frequently underused feature at the intermediate level: Amplify can automatically stand up a complete, isolated preview environment — frontend and backend both — for every open pull request, then tear it down automatically on merge or close. This turns code review into a genuine end-to-end review, since reviewers interact with a live, fully functional version of the change rather than reading a diff and imagining the runtime behavior.

Framework-Aware SSR Support

For Next.js and similar SSR/ISR frameworks, Amplify Hosting doesn’t just serve static files — it provisions Lambda@Edge or CloudFront Functions to handle server-rendered routes, detecting the framework’s build output format automatically and routing requests accordingly. This is a meaningfully more complex deployment target than plain static hosting, and it’s the reason SSR apps sometimes see different latency characteristics than equivalent static-export apps on the same platform.