Choosing AWS Amplify for a Developer Platform Marketing Site

Every developer tool needs a website. And every developer building that tool has to resist the urge to over-engineer it.

When we started building smplkit, we needed a marketing site that was simple to maintain, inexpensive to run, and deployed automatically from source control. The platform itself runs on AWS — ECS Fargate, RDS PostgreSQL, the usual suspects — so the question was how much of that infrastructure muscle to apply to a marketing site that serves static HTML.

The answer, it turns out, is almost none.

The Options

We evaluated four approaches, roughly in order of increasing complexity:

AWS Amplify Hosting — a managed static hosting service that connects to a GitHub repo, builds on push, and serves through CloudFront. Think of it as Netlify or Vercel, but inside your existing AWS account.

S3 + CloudFront + GitHub Actions — the classic AWS static site stack. Upload files to S3, serve them through CloudFront, wire up a GitHub Actions workflow to deploy on push. Full control, but you’re managing bucket policies, CloudFront distributions, cache invalidation, ACM certificates, and deployment scripts yourself.

Self-hosting on a VM — running Nginx or Caddy on an EC2 instance. Maximum control, maximum operational overhead for serving static files.

Third-party static hosting (Netlify, Vercel, Cloudflare Pages) — excellent developer experience, but introduces a dependency outside our existing AWS ecosystem.

Why Amplify Won

Amplify Hosting gave us everything we needed with the least operational surface:

Push to main, site deploys. That’s the entire workflow. No GitHub Actions YAML to maintain, no S3 sync commands, no CloudFront invalidation scripts. Amplify watches the repo and handles the build-deploy cycle automatically.

It includes a CDN (it literally uses CloudFront under the hood), manages TLS certificates, handles the www redirect, and provides preview deployments for branches if we ever want them. The cost for a low-traffic marketing site is negligible — we’re talking single-digit dollars per month.

The decisive factor was consistency. Our entire infrastructure is on AWS, managed through Pulumi. Having the marketing site on the same cloud provider means one billing account, one set of credentials, and one operational mental model. It’s not that Netlify or Vercel are bad — they’re great — it’s that adding another vendor for a static site didn’t justify the context switching.

What S3 + CloudFront Actually Costs You

The S3 + CloudFront option deserves a closer look because it’s what most AWS-experienced developers reach for first. And it works — it’s how many production static sites run. But the setup cost is real:

You need an S3 bucket with the right policy (public read, or OAI/OAC for CloudFront-only access). A CloudFront distribution with the bucket as origin. An ACM certificate in us-east-1 (CloudFront requires that specific region, which trips up everyone the first time). DNS records in Route 53. A GitHub Actions workflow to sync files and invalidate the CloudFront cache on deploy. Error pages configured. Logging set up if you want it.

Each piece is straightforward. The sum of them is a half-day of infrastructure work, plus a CI/CD pipeline to maintain forever. Amplify does all of this with a single console setup and a main branch connection. Same result, less machinery.

Why Not Netlify or Vercel?

Both are excellent products, and for many teams they’re the right choice. Vercel in particular has deep Next.js integration that’s hard to beat. Netlify’s form handling and identity features are genuinely useful.

We chose against them for one reason: keeping the vendor count down. smplkit’s production infrastructure runs entirely on AWS. Adding a second cloud provider for a marketing site means another account to manage, another billing relationship, another set of access controls, and another vendor to evaluate for security and compliance when enterprise customers ask about our infrastructure.

For a company with dedicated DevOps staff, this is trivial overhead. For a solo founder, every additional vendor is a mental burden that compounds over time.

What We’d Reconsider

If smplkit’s marketing site ever needed server-side rendering, edge functions, or dynamic content at the CDN layer, we’d look at this again. Amplify supports some of that through its fuller hosting platform, but frameworks like Next.js on Vercel or Remix on Cloudflare Pages are more mature in that space.

For now, a static site deployed on push is exactly right. The marketing site is a brochure, not an application, and treating it that way keeps our attention on the product.

The Broader Lesson

Early-stage developer tools live or die on focus. Every hour spent yak-shaving on marketing site infrastructure is an hour not spent on the product. The right question isn’t “what gives me the most control?” — it’s “what lets me stop thinking about this?”

For us, that was Amplify. Your answer might be different depending on your existing stack, but the principle holds: pick the most boring, most managed option that meets your requirements, and move on to the interesting problems.

smplkit is a platform of operational services for SaaS teams. We’re building in the open — follow along on the blog or check out the docs.