AWS Amplify vs S3 + CloudFront for a static 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 smplkit, we needed a marketing site that was simple to maintain, cheap 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 site that serves static HTML.
The answer turns out to be almost none.
The options
Four candidates, in increasing order of self-inflicted complexity. AWS Amplify Hosting: connect a GitHub repo, it builds on push and serves through CloudFront — Netlify or Vercel, but inside your existing AWS account. Third-party hosting (Netlify, Vercel, Cloudflare Pages): excellent developer experience, one more vendor. S3 + CloudFront + GitHub Actions: the classic AWS static stack, full control, all the assembly. And Nginx on an EC2 instance, which is maximum control and maximum operational overhead for serving files that never change.
Why Amplify won
Push to main, site deploys. That’s the entire workflow. No Actions YAML to maintain, no S3 sync commands, no invalidation scripts — Amplify watches the repo and handles the build-deploy cycle. It serves through CloudFront, manages the TLS certificates, handles the www redirect, and does branch preview deployments if we ever want them. A low-traffic marketing site costs single-digit dollars a month.
The decisive factor was consistency. Everything we run is on AWS, managed through Pulumi. The marketing site on the same provider means one billing account, one set of credentials, one operational mental model, and one less vendor to explain in a security questionnaire. The marketing site is a brochure, not an application, and Amplify treats it like one.
What S3 + CloudFront actually costs you
The DIY stack deserves a closer look, because it’s what AWS-experienced developers reach for first, and it works — plenty of production sites run on it. But add up the setup: an S3 bucket with the right policy (public read, or OAC for CloudFront-only access). A CloudFront distribution with the bucket as origin. An ACM certificate that must live in us-east-1, a requirement that isn’t where you’re looking and trips up everyone exactly once. Route 53 records. A GitHub Actions workflow to sync files and invalidate the cache. Error pages. Logging, if you want to know anything later.
Each piece is straightforward. The sum is a half-day of infrastructure work plus a CI/CD pipeline you maintain forever, to get the same result Amplify gives you for a console setup and a branch name.
Why not Netlify or Vercel?
They’re great at this — Vercel’s Next.js integration in particular is hard to beat, and Netlify’s form handling is genuinely useful. We passed for one reason: vendor count. Production runs entirely on AWS, and a second provider for a static site means another account, another billing relationship, another set of access controls, another security review when enterprise customers ask. A company with a platform team absorbs that overhead without noticing. A solo founder pays it out of the same attention budget as the product.
Docs are a separate site
One decision that rode along with the hosting choice: documentation doesn’t live on the marketing site. www.smplkit.com and docs.smplkit.com are different repos, different frameworks, different pipelines — both deployed the same way, on Amplify, from their own main branches.
They’re separate because they change for different reasons at different speeds. The marketing site changes when the business changes — pricing, launches, messaging — a handful of deploys a month. Docs change when the code changes — a renamed parameter, a new endpoint, an SDK release — sometimes several surgical deploys a week. Couple them and every docs fix rides through marketing review, or every marketing tweak risks the docs build.
They also serve people in different modes: one convinces someone deciding whether to use the product, the other informs someone who already decided. And they want different tools — the marketing site is Astro, which is good at landing pages; the docs site is VitePress, which is purpose-built for documentation and would make a terrible homepage. The subdomain (rather than a /docs path) is what makes the independence total: different DNS, different repo, different everything, connected by nothing but ordinary HTML links.
If your documentation is one getting-started page, none of this is worth it. Ours was a multi-product platform’s worth of SDK guides and API references from the start, and retrofitting a split later means migrating content, fixing links, and eating SEO redirects. Start separated. It’s easier to merge two sites than to split one.
The broader lesson
If the site ever needs server-side rendering or edge functions, we’ll revisit — that’s where Vercel and Cloudflare Pages genuinely shine. Until then, the right question was never “what gives me the most control?” It’s “what lets me stop thinking about this?”