Production Static Website Hosting on AWS Amplify

This is a live case study, not a tutorial — it documents exactly how ranjithr.com, my real personal portfolio, is hosted on AWS today. To be specific about what this is: it is a production static website, not an AWS application or server deployment — there is no compute instance, container, or backend runtime anywhere in this stack. Every push to the main branch on GitHub goes through a fully automated pipeline and is live within minutes, with no server to patch, no manual deploy step, and no dedicated DevOps time spent keeping it online.

The stack is deliberately different from the other two AWS projects on this site. AWS Static Website Hosting and AWS Dynamic Website Hosting both wire S3/EC2, CloudFront, ACM, and Route 53 together by hand to show how the primitives fit. This deployment instead leans on AWS Amplify as a managed layer over the same primitives — it provisions and operates the CloudFront distribution and the TLS certificate itself (and stores the static build output in S3 behind the scenes), triggered directly from GitHub. The trade-off is less manual control in exchange for a genuinely hands-off, git-driven release process, which is the right trade for a portfolio site that changes often and has no ops budget.

A commit becomes a live page through one straight-line path: GitHub triggers Amplify, Amplify serves the build through CloudFront, CloudFront is secured by an ACM certificate, and Route 53 resolves ranjithr.com to that distribution. Google Analytics is kept deliberately separate from this hosting chain — it runs client-side in the visitor's browser after the page has already loaded, and has no part in serving the site itself.

Every service below is one this deployment actually uses today — nothing here is invented or hypothetical. Rather than guess a dollar figure that would go stale, each row lists the cost model AWS actually bills it under. Most of it is usage-based, which is why a low-traffic personal portfolio like this one tends to run for very little — but that is not the same as free, and the real number always depends on your own traffic and usage.

There is exactly one way a change reaches production: push to main. Amplify owns everything after that.

Amplify reads its build steps from a build spec checked into the repo:

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

• HTTPS everywhere — CloudFront redirects all HTTP traffic to HTTPS, and the ACM certificate is validated and renewed automatically with no manual step.
• Secrets stay out of git — analytics IDs and any environment-specific values are set as Amplify environment variables, scoped to the branch, never committed to the repository.
• Least-privilege deploys — Amplify's GitHub integration only needs read access to the repository and its own service role to publish; it never needs direct IAM credentials checked into CI config.
• Immutable releases — every deploy is a new, versioned Amplify build; rolling back means re-promoting a previous build, not hand-editing anything live.

CloudFront serves every static asset from an edge location near the visitor, so repeat views and navigations feel effectively instant. Next.js's own build output (pre-rendered pages, code-split JavaScript, optimized images) means the origin rarely has to do real work on a cache hit.

• Fingerprinted, hashed build assets get long-lived, immutable cache headers.
• HTML is revalidated frequently so a fresh deploy becomes visible without waiting on a manual cache invalidation.
• Images are served through Next.js's image pipeline rather than as unoptimized originals.

Monitoring here is intentionally lightweight, matching the size of the project:

• Amplify build notifications — every build's pass/fail status is visible in the Amplify console and can email or notify on failure.
• Google Analytics — pageviews, traffic sources, and custom events (like the interactions tracked elsewhere on this site) for understanding real visitor behavior. It runs entirely client-side and is kept separate from the AWS hosting stack itself.
• Uptime — CloudFront and Amplify's hosting are managed AWS services with their own published availability SLAs, so there is no separate uptime monitor to run for the hosting layer itself.

• A managed platform like Amplify trades some low-level control (you don't touch the CloudFront distribution or bucket directly) for a much shorter path from commit to production — worth it for a fast-moving personal site, less so for a system that needs fine-grained infrastructure control.
• Keeping the build spec (amplify.yml) in the repository, rather than only in the console, means the entire deploy process is reviewable in a pull request like any other code change.
• Treating preview URLs as public by default, from day one, avoided ever having to retroactively lock one down.

Official documentation for every service used in this deployment:

• AWS Amplify Hosting — User Guide
• Amazon CloudFront — Developer Guide
• AWS Certificate Manager — User Guide
• Amazon Route 53 — Developer Guide
• Amazon S3 — User Guide
• AWS Pricing Calculator
• AWS Free Tier — current terms
• Google Analytics — official documentation

The outcome is a real, production static website that deploys itself: a push to main becomes a live, HTTPS-secured, globally-cached update at ranjithr.com with no manual step in between, running on a usage-based AWS cost model that stays very low for a site at this traffic level — though, since every AWS service here bills by usage rather than a flat fee, the actual cost always depends on traffic and resource usage, not a fixed number. For a personal project, that ratio of automation to operating cost is the entire point of building it this way.