Amplify Hosting is AWS's "connect a git repo, get a deployed site" service. It's a wrapper around S3, CloudFront, ACM, and CodeBuild — same primitives as the manual setup, packaged into a single dashboard. The result is closer to Vercel than to raw S3 + CloudFront, with the AWS bill and the AWS integrations that come with that.
Two things share the "Amplify" name and they're frequently confused. Amplify Hosting is what this tutorial covers: a git-driven web hosting service that builds your site, deploys it to a CloudFront-backed CDN, gives you a free TLS cert, and re-deploys on every push. Amplify Studio (and the Amplify libraries) are a different product — a full backend platform with generated DataStore APIs, auth flows, and React components. They're related (Amplify Hosting can be paired with Amplify Studio), but Amplify Hosting alone works fine with any backend or no backend. We'll stay on the Hosting side.
The honest pitch: Amplify Hosting is what AWS built when it noticed Vercel and Netlify existed. It does the same things — git connection, branch deploys, environment variables, preview URLs, custom domains. The UX is meaningfully behind Vercel's; the build logs are dense; the CLI exists but most flows assume the console. What you get in exchange is that everything lives in your AWS account: same IAM, same billing, same VPC if you need it, same support contract. For teams that have a "must be on AWS" policy, Amplify Hosting is the path of least resistance.
This tutorial walks the connect-a-repo-to-live-URL flow, points out where Amplify's defaults will surprise you, and shows what the second deploy looks like (which is the deploy-loop you'll live in). We'll also cover when to skip Amplify Hosting entirely — there are a few cases where the manual S3 + CloudFront pipeline ends up cleaner.
amplify.yml*.amplifyapp.com URL).
Amplify will try to detect your framework on the first connection. For the common ones it works without intervention — Next.js, Nuxt, Vite, Create React App, Hugo, plain HTML. For less-common ones (SvelteKit edge runtime, Remix, Astro with adapters), the auto-detect picks defaults that may or may not match your config.
Before connecting, confirm:
npm run build, pnpm build, hugo, etc.)../dist, ./out, ./public, ./.next).In the AWS console, open Amplify → Create new app → Host a web app. Pick your git provider:
After granting access, pick the repo and branch (usually main for production). Click Next.
amplify.yml file Amplify writes for youAmplify shows a YAML file describing the build. For an auto-detected Vite project it looks like:
version: 1
frontend:
phases:
preBuild:
commands:
- npm ci
build:
commands:
- npm run build
artifacts:
baseDirectory: dist
files:
- '**/*'
cache:
paths:
- node_modules/**/*If the detection looks right, accept and move on. If the output directory is wrong (most common error — Amplify guesses dist when yours is build, or vice versa), fix baseDirectory here. You can also commit this as amplify.yml at the repo root to keep the build config in source control.
API_KEY, DATABASE_URL, etc. They're available at build time and (for SSR apps) at request time. Never put secrets in amplify.yml.
Click Save and deploy. Amplify runs the pipeline:
Total time: 2–5 minutes for small projects, longer for large dependency installs. When Deploy turns green, Amplify shows the live URL — https://main.d1234abcde.amplifyapp.com. Click it; your site should load. This URL is HTTPS-enabled, cached on CloudFront edges, and ready before you wire up a custom domain.
App → Domain management → Add domain. Enter mybrand.com. Amplify shows you the subdomain mapping:
mybrand.com → main branchwww.mybrand.com → main branch (with redirect to apex, or vice versa — pick the canonical)Click Save. Amplify provisions an ACM cert (in us-east-1, handled internally — you don't have to think about it) and requests DNS validation:
In the app overview, Connect branch. Pick a feature branch — Amplify creates a separate deployment at https://<branch-name>.d1234abcde.amplifyapp.com. Pushes to that branch trigger preview deploys; the main branch is unaffected.
For PR-based previews: App settings → Previews → enable. Amplify watches the connected GitHub/GitLab repo for open pull requests and creates ephemeral preview URLs per PR. Useful for review; the URL goes away when the PR closes.
git push is the deploy commandThat's it. Push to main → Amplify builds → deploys → invalidates the CloudFront cache → you see the new version at mybrand.com within a few minutes. The CLI exists (amplify push for the Amplify Studio side; amplify pull for syncing config) but for hosting alone you'll rarely use it.
Build logs are at App → branch → build number. Failed builds send an email by default; configure Slack / Discord via App settings → Notifications if you want richer alerting.
You don't already use AWS. Vercel and Netlify have a noticeably better UX, faster build cold-starts (Amplify's CodeBuild containers warm slowly), and friendlier free tiers. The only reason Amplify wins is AWS-account integration — without that, the trade-off doesn't pay.
Your project has unusual build steps that Amplify's CodeBuild image doesn't support well. The CodeBuild Linux image is general-purpose but not exhaustive. If your build needs system-level dependencies, custom apt-get packages, or specific Node versions Amplify hasn't updated to, you'll spend time fighting the image. Manual S3 + CloudFront with your own CI gives you full control over the build environment.
Sub-$1/month static sites. Amplify Hosting starts billing at the first build minute — typically 1¢/build-minute, plus CDN data transfer and serve-request costs. A static site with infrequent deploys is cheaper on raw S3 + CloudFront because you skip the build-minute charge. The line is around 50 deploys/month or so; below that, manual S3 is cheaper.