Both AWS Amplify and Google Cloud Run will host a Next.js application, and both will look fine in a demo. The difference shows up three months in, when the build takes nine minutes, the bill arrives, and someone asks why the first request after a quiet night takes four seconds. This is how we choose between them.

The two hosting models are not the same shape

Amplify is a managed front-end platform. You connect a repository, Amplify runs your build, uploads static output to a CDN, and packages your server-rendered routes into a managed compute layer behind CloudFront. You do not see the container. You configure the build through amplify.yml and environment variables, and that is most of the surface area.

Cloud Run is a container platform. You produce a Docker image that listens on a port, push it to Artifact Registry, and Cloud Run runs it, scaling instances up with traffic and down to zero when idle. Nothing about it is Next.js-specific. You own the Dockerfile, the Node version, the process manager, and anything else you install.

That single difference drives almost everything else. Amplify makes decisions for you and is fast to stand up. Cloud Run makes you decide and gives you somewhere to put anything unusual.

Build and deploy

On Amplify, a git push triggers a build. Branch-based preview environments come essentially free, which is genuinely useful when a client wants to review a feature before it merges. Build caching for node_modules and the .next cache is a configuration entry, and getting it right is the difference between a three-minute and a nine-minute build.

# amplify.yml
version: 1
frontend:
  phases:
    preBuild:
      commands: [npm ci]
    build:
      commands: [npm run build]
  artifacts:
    baseDirectory: .next
    files: ['**/*']
  cache:
    paths:
      - node_modules/**/*
      - .next/cache/**/*

On Cloud Run you build the image yourself, normally with Cloud Build or GitHub Actions. It is more setup, but the build is reproducible locally, which matters when a build fails only in CI. A multi-stage Dockerfile using Next.js standalone output keeps the runtime image small, and small images start faster.

Cold starts and latency

Cloud Run scales to zero by default. If your app gets a request after a quiet period, the platform starts a container, Node boots, and the first response is slow. For a marketing site with steady traffic this is invisible. For an internal tool used twice a day, it is the first thing your client complains about. The fix is a minimum instance count, which removes the cold start and removes scale-to-zero savings at the same time. Decide which you want before launch, not after.

Amplify's server-side layer has its own warm-up behaviour, but you have fewer levers. If your route handlers are heavy, you cannot pin instances the way Cloud Run lets you.

Cost shape

Amplify bills for build minutes, data served and server-side request duration. It is predictable for content sites and gets expensive if you have chatty server routes or very frequent deployments across many preview branches.

Cloud Run bills for CPU and memory while a request is being handled, plus requests. With scale-to-zero and modest traffic, a small app can be close to free. With a minimum instance count you are paying for an always-on container, which is closer to a small VM. Neither is universally cheaper; the traffic pattern decides.

When we pick Amplify

  • The project is a marketing site or content site with mostly static routes.
  • The client is already on AWS and wants one bill and one IAM model.
  • Per-branch preview URLs for stakeholder review matter more than runtime control.
  • Nobody on the client side wants to maintain a Dockerfile after we hand over.

When we pick Cloud Run

  • The app needs system dependencies, a specific runtime version, or a sidecar process.
  • There are background or scheduled jobs that belong next to the app.
  • The stack already uses Firebase, Cloud SQL or Firestore, so keeping data and compute in one project reduces egress and IAM complexity.
  • The client wants portability — the same image runs on any container host.

What we do either way

Whichever platform we deploy to, the same non-negotiables apply: a separate staging environment with its own data and credentials, secrets in the platform's secret store rather than committed files, a health check endpoint wired to monitoring, log retention configured deliberately, and a documented rollback. The hosting choice is reversible. Losing a production database because backups were never verified is not.

If you are choosing between the two for a real project and want a second opinion on the trade-offs, we are happy to talk it through.