AWS Amplify
Managed build-and-host for frontend web apps — it hosts the app that calls your API and signs users in, not the API itself. Here's what Amplify is good for, what it costs, how it connects to API Gateway and Cognito, and the mistakes Design Beaver catches as you draw.
What Amplify is
Amplify Hosting takes a frontend app — a static site, a single-page app (React, Vue, Angular), or a server-side-rendered app (Next.js, Nuxt) — and builds, deploys, and hosts it for you. Connect a Git branch and Amplify runs CI/CD on every push, serves the result through an AWS-managed CDN, and hands you custom domains with automatic SSL and per-branch preview URLs.
On a diagram, Amplify hosts the caller. The browser loads the app from Amplify, and that app then calls your API Gateway backend for data and signs users in against Cognito. Amplify is the entry point to your frontend, not your backend — API Gateway is the front door to that. Design Beaver models Amplify as a regional, CDN-fronted host rather than a subnet resident, and validates as you draw which way its edges are allowed to point.
When to use Amplify (and when not to)
Reach for Amplify when you want push-to-deploy hosting for a frontend without managing S3, CloudFront, and a build pipeline by hand, when your app is Next.js or Nuxt SSR and you want managed server-side rendering rather than wiring Lambda@Edge yourself, or when you want PR and branch preview deployments with automatic SSL on custom domains out of the box.
Don’t reach for it for a purely static site you already ship through your own S3 + CloudFront pipeline — that stack is cheaper and more controllable. It’s also not a backend: anything that’s actually an API or server process belongs behind API Gateway plus Lambda or another compute tier, with the Amplify-hosted frontend calling it. And if you need fine-grained CDN, cache, or WAF control beyond Amplify’s managed distribution, use CloudFront directly.
Variants: static hosting vs SSR
The meaningful fork is how the app renders at request time. Build-instance sizes are a cost and performance knob, not an architecture choice.
| Option | What it is |
|---|---|
| Static / SPA hostingdefault | Hosts pre-built static assets (SSG output, a single-page app bundle) served from Amplify's managed CDN. No server-side compute at request time. |
| SSR (compute) hosting | Managed server-side rendering for Next.js/Nuxt apps — Amplify runs the framework's server at request time (image optimization, middleware, dynamic routes) without you provisioning Lambda/compute. |
Amplify pricing
Amplify bills pay-as-you-go across three axes with no minimum: build compute per build-minute by instance size, hosting storage per GB stored per month, and hosting served per GB out. The one to watch is per-GB-served egress — it’s the charge that scales with your site’s popularity. For a steady-traffic static site, a self-managed S3 + CloudFront stack is usually cheaper; Amplify’s value is the managed CI/CD and SSR, not the lowest raw hosting cost.
Pay-as-you-go across three axes: build compute (per build-minute, by instance size), hosting storage (per GB stored/month), and hosting served (per GB served out). No minimum fee.
| Option | Representative rate |
|---|---|
| static | ~$0.023 per GB stored/month + ~$0.15 per GB served (data transfer out) |
| ssr-compute | Same storage + served rates, plus SSR request and compute-duration charges for the managed rendering |
| build-standard | Build compute billed per build-minute by instance size — Standard (4 vCPU / 8 GB) ~$0.01/min; Large and XLarge run at higher per-minute rates |
Free tier
- New AWS accounts (2025 Free Tier change): up to $200 in AWS Free Tier credits usable across eligible services (including Amplify) for 6 months after account creation — replaces the old always-free build/hosting allotment
Keeping the bill down
- For a purely static site with steady traffic, a self-managed S3 + CloudFront stack is usually cheaper than Amplify's per-GB-served rate — Amplify's value is the managed CI/CD and SSR, not the lowest raw hosting cost
- Watch per-GB-served egress at high traffic — it's the charge that scales with popularity
us-east-1 (rates vary by region). Rates as of 2026-07. Verify at the official pricing page before using for real cost estimates — this list is not kept in sync with AWS pricing changes.
How Amplify connects to other services
Amplify sits at the frontend edge, and its edges point outward: it serves the app to the user’s browser, and the hosted app calls your backend. The rule that matters is direction — the data flow is frontend → API, never API → frontend. Design Beaver models each of these edges and what it needs, so it validates as you draw that you’re pointing them the right way.
- User
Serves the frontend app (static assets or SSR responses) to the end user's browser over HTTPS via Amplify's managed CDN — this is the edge the user actually loads the site from
The hosted frontend calls the API — browser code (or the SSR server) makes HTTPS requests to an API Gateway endpoint for the app's data. API Gateway is the public backend front door; Amplify hosts the caller
The frontend authenticates the user against a Cognito user pool (hosted UI or the Amplify Auth SDK) to obtain a JWT, then attaches that token to its API Gateway calls
Anti-patterns Design Beaver catches
These are the Amplify mistakes that pass a diagram review but cost you money or break the architecture’s shape — the ones the validation engine flags as you draw.
Using Amplify Hosting to serve a purely static site you already build and ship through your own S3 + CloudFront pipeline
Why it breaksYou pay Amplify's managed CI/CD + per-GB-served premium for hosting you're already doing more cheaply and controllably yourself
Do this insteadKeep S3 + CloudFront for the static case; reach for Amplify when you specifically want its Git CI/CD, PR previews, or managed SSR
Expecting Amplify Hosting to be your API backend
Why it breaksAmplify Hosting serves frontend assets and SSR — it is not an HTTP API layer for your own business logic; there's no request-routing/integration model like API Gateway's
Do this insteadPut business logic behind API Gateway + Lambda (or another compute tier) and have the Amplify-hosted frontend call it
Gotchas that bite in production
- Amplify Hosting is not an API backend. It serves frontend assets and SSR responses; it has no request-routing or integration model for your own business logic the way API Gateway does. Business logic goes behind API Gateway and compute, and the Amplify-hosted app calls it.
- Static-only sites can cost more than S3 + CloudFront. For a purely static site you already build yourself, you’re paying Amplify’s managed CI/CD and per-GB-served premium for hosting you could do more cheaply. Amplify earns its keep on Git CI/CD, PR previews, and managed SSR — not raw hosting cost.
- Browser calls need CORS and a token. Calls from the Amplify-hosted app to API Gateway need CORS configured on the API, and the Cognito token attached on each request if the API has an authorizer. A missing token against a protected API means every call is rejected.
Further reading
Frequently asked questions
When should you use AWS Amplify Hosting?
Is AWS Amplify a backend or a frontend host?
How does Amplify connect to API Gateway and Cognito?
How much does AWS Amplify Hosting cost?
Validate your Amplify architecture as you draw
Design Beaver checks your AWS design in real time — missing queues, invalid connections, and security anti-patterns, caught before you ship. It’s live in beta, free, and runs in your browser with no account.
Open the app →Prefer email? Get new features in your inbox: