Lesson 19 of 30

AWS Amplify for Frontend Deployment

Q: Your team is deciding whether to deploy a Next.js frontend via AWS Amplify Hosting or hand-roll S3 + CloudFront + a GitHub Actions pipeline. How would you reason about that decision?

A strong answer covers: Names the actual tradeoff: Amplify trades fine-grained control (cache behaviors, invalidation logic, headers) for a managed build/deploy pipeline and less operational setup; Recognizes that Amplify Hosting for SSR frameworks runs the server-rendered portion as managed compute, not purely static hosting — it isn't a strict superset of the S3 + CloudFront static pattern; Factors in team size and existing AWS operational expertise as the real deciding variable, not a blanket preference for either approach.

This track's CloudFront and CI/CD lessons show how to wire up S3, CloudFront, and a pipeline by hand. Amplify is AWS betting a frontend team would rather not — the same convenience-for-control trade Elastic Beanstalk makes on the compute side.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

What's the core tradeoff AWS Amplify Hosting makes compared to manually configuring S3, CloudFront, and a CI pipeline yourself?

Convenience and speed of setup, in exchange for less fine-grained control over the underlying infrastructureAmplify is simply a cheaper, strictly superior way to do the same thing with no real downsideAmplify only works for purely static sites, so it trades away support for server-rendered frameworks entirely

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on AWS Amplify for Frontend Deployment

What interviewers actually ask about this, and what a strong answer has to cover.

Your team is deciding whether to deploy a Next.js frontend via AWS Amplify Hosting or hand-roll S3 + CloudFront + a GitHub Actions pipeline. How would you reason about that decision?

A strong answer covers

Names the actual tradeoff: Amplify trades fine-grained control (cache behaviors, invalidation logic, headers) for a managed build/deploy pipeline and less operational setup
Recognizes that Amplify Hosting for SSR frameworks runs the server-rendered portion as managed compute, not purely static hosting — it isn't a strict superset of the S3 + CloudFront static pattern
Factors in team size and existing AWS operational expertise as the real deciding variable, not a blanket preference for either approach

Likely follow-ups

If Amplify is running SSR as managed compute under the hood, what kind of constraint from this track's Lambda discussion might now apply to the app that wouldn't apply to a purely static S3 site?
Your team has a dozen stale feature-branch environments still live on Amplify months after those PRs merged. What's the practical downside of that, and how would you prevent it recurring?

Practice these with the AI interviewer →

The plain-language idea

AWS Amplify is a frontend-specific platform-as-a-service: connect a git repository, and Amplify builds and deploys on every push — no manually wiring together S3, CloudFront, and a CI pipeline the way this track's CloudFront and CI/CD lessons walk through by hand. Under the hood it's still provisioning something like that same infrastructure, but you never touch it directly.

Amplify is really two products people conflate:

Amplify Hosting — the git-push-to-deploy piece: build settings, a managed CDN, TLS certificates, and automatic per-branch deploy URLs, for both static sites and server-rendered frameworks.
Amplify's backend toolkit — a way to provision auth (backed by Cognito), an API (backed by AppSync or API Gateway), and file storage (backed by S3) from frontend code, without hand-configuring each service separately.

This lesson is about the hosting half. It exists for the same reason Elastic Beanstalk exists on the compute side: doing this by hand is a well-understood but genuinely multi-step job, and Amplify trades the control that comes from owning each step for not having to do them.

See it in a real thing: a build spec instead of a pipeline

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: .next
    files:
      - "**/*"
  cache:
    paths:
      - node_modules/**/*

That's the entire deploy configuration. Connect the repo, point Amplify at this amplify.yml, and every push to the tracked branch triggers this build and ships the result — Amplify provisions and manages the CDN distribution, certificate, and cache invalidation itself. Compare that to the CI/CD lesson's manual sequence: authenticate via OIDC, s3 sync, then a separate cloudfront create-invalidation call. Amplify collapses that into a config file it interprets for you.

What people usually miss

Watch out

Amplify isn't only hosting. Its backend toolkit for auth, API, and storage is a separate product decision from "should we deploy our frontend through Amplify" — a team can use one without the other, and conflating them leads to assuming you're locked into the full stack when you're not.
Every git branch can become its own live environment automatically. That's genuinely useful for preview deploys on a pull request, but stale feature branches left connected keep generating (and billing for) live environments nobody's looking at — it needs the same cleanup discipline as any other auto-provisioned resource.
SSR support means Amplify-hosted apps can inherit Lambda-shaped constraints. If the server-rendering layer runs as managed compute behind the scenes, execution limits and cold-start behavior become relevant in a way they never are for a purely static S3 + CloudFront site.
Less control is the actual price, not a footnote. Fine-grained cache-control headers, custom invalidation logic, and hand-tuned cache behaviors are all things the manual S3 + CloudFront setup gives full access to; Amplify abstracts them behind its own defaults, which is exactly the trade a PaaS makes.

Why this matters in interviews

"When would you reach for Amplify instead of hand-rolling S3 + CloudFront + a pipeline?" tests whether a candidate can name the actual tradeoff — convenience and velocity versus fine-grained control — rather than treating a managed platform as a strictly better version of the manual setup.