- Building a serverless AWS website on raw primitives teaches the kind of hands-on skills abstracted platforms like Amplify quietly hide from you.
- This serverless AWS website uses Vite instead of Next.js — a deliberate choice that cuts build overhead for purely static marketing pages.
- CloudFront’s hard requirement for ACM certificates in us-east-1 is a real gotcha that trips up even experienced AWS practitioners.
- Origin Access Control has replaced Origin Access Identity as the modern standard for securing S3 buckets behind CloudFront distributions.
Why Build a Serverless AWS Website the Hard Way?
There’s a version of this story where a developer spins up a serverless AWS website in forty minutes using AWS Amplify, clicks through a few console screens, and calls it done. Josh Blair, a software and cloud consultant behind bonefishsoftware.com, did the opposite — and for entirely deliberate reasons. His goal was to build and deploy a production company website using raw AWS primitives: CloudFormation, CodePipeline, CodeBuild, S3, and CloudFront, with no abstraction layers softening the edges.
That choice reflects a real tension in cloud development right now. Platforms like AWS Amplify, Vercel, and Netlify have made deployment almost frictionless — but they do it by hiding exactly the infrastructure decisions that matter most in enterprise environments. When something breaks at 2am in a production system, the engineer who understands what’s actually being provisioned is worth considerably more than the one who only knows how to click through a wizard.
Blair’s project isn’t just a portfolio piece. It’s a working demonstration of how to architect, automate, and operate a serverless AWS website the way it would actually be built inside a serious engineering organisation. Understanding every layer of a serverless AWS website — from certificate provisioning to CDN configuration — is what separates practitioners who can only deploy from those who can truly operate.
Choosing Vite Over Next.js — A Smart, Underrated Call
One of the more interesting technical decisions in this build is the choice of Vite over Next.js as the frontend tooling. Next.js has become almost the default React framework recommendation, and for dynamic applications with server-side rendering or API routes, that reputation is deserved. But for a static marketing site — pages that don’t change per-request, don’t need a Node.js server, and just need to be fast — Next.js is genuine overhead.
Vite produces a clean dist/ directory of static assets: HTML, CSS, JavaScript, images. That output drops directly into an S3 bucket and gets served globally through CloudFront with zero server-side complexity. Local development iteration is faster too, which matters more than people admit when you’re tweaking component layouts repeatedly. For a serverless AWS website built on purely static output, this is the right tool for the job.
This kind of framework pragmatism is worth paying attention to. The industry has a habit of defaulting to the most feature-complete tool regardless of whether those features are needed. Choosing Vite here isn’t settling — it’s appropriate engineering. The site’s architecture includes six page components (Home, Services, Technologies, Portfolio, Team, and Contact) alongside shared components for navigation and footer, all wired up from typed data files. Clean, maintainable, and completely static at build time.
Raw CloudFormation: Building a Stronger Mental Model
The infrastructure is written entirely in CloudFormation — AWS’s native infrastructure-as-code tool — rather than the AWS CDK, Terraform, or Pulumi. That’s a meaningful distinction. CDK lets you write infrastructure in TypeScript or Python, which feels natural to developers, but it abstracts away the CloudFormation templates being generated underneath. Blair’s explicit reasoning: understanding CloudFormation directly, before reaching for higher-level abstractions, builds a stronger mental model of what’s actually being deployed in a serverless AWS website.
This is the same argument that experienced engineers make about learning C before Python, or understanding TCP/IP before building with HTTP libraries. Abstractions are only as useful as your understanding of what they’re abstracting. In AWS specifically, when CloudFormation stacks fail to roll back cleanly or when a CDK diff produces an unexpected resource replacement, the engineer who can read raw CloudFormation is the one who fixes it.
The project splits infrastructure into four distinct stacks, each deployed to the appropriate region:
- certificate.yml — ACM certificate provisioned in us-east-1 (mandatory for CloudFront)
- website.yml — S3 bucket and CloudFront distribution, deployed to us-west-2
- pipeline.yml — CodePipeline and CodeBuild configuration, deployed to us-west-2
- contact-api.yml — SAM template defining API Gateway, a Python Lambda, and DynamoDB for the contact form, deployed to us-west-2
That separation of concerns across stacks isn’t just tidy — it reflects real-world enterprise patterns where different teams own different infrastructure layers and need independent deployment lifecycles.
The us-east-1 Certificate Constraint Nobody Warns You About
If you’ve ever set up a custom domain with CloudFront and wondered why your certificate request needs to go into a completely different region from everything else you’re building, welcome to one of AWS’s more persistent operational quirks. CloudFront is a global service, and it only reads ACM certificates from us-east-1, full stop. It doesn’t matter if your S3 bucket, your Lambda functions, and your DynamoDB table all live in us-west-2 or ap-southeast-1. The certificate has to be in us-east-1.
This isn’t a design choice Blair made — it’s an AWS architectural constraint documented in the CloudFront developer guide. But it’s the kind of constraint that doesn’t surface until you’re deep into a deployment, and it’s the reason the project isolates certificate provisioning into its own dedicated stack. Building it separately also means the certificate can be managed and renewed independently, which becomes important as sites age. Anyone building a serverless AWS website with a custom domain will hit this constraint eventually.
Origin Access Control: The Modern Way to Lock Down S3
Another detail worth examining is the use of Origin Access Control (OAC) rather than the older Origin Access Identity (OAI) for securing the S3 bucket. OAC is AWS’s current recommended approach — it supports all S3 operations, works with SSE-KMS encrypted buckets, and uses AWS SigV4 request signing, which is the same signing mechanism used across modern AWS service integrations.
OAI still works, and plenty of existing infrastructure still uses it, but AWS has quietly positioned OAC as the replacement. For new builds, there’s no reason to use OAI. The practical effect in both cases is the same from a user perspective: the S3 bucket is completely private, with no public access, and CloudFront acts as the sole authorised entry point. Direct S3 URL access returns an access-denied error. Content is only served through the CDN, which means you get HTTPS enforcement, global edge caching, and custom domain support without exposing raw storage infrastructure. This security model is a cornerstone of any well-architected serverless AWS website.
CI/CD: Every Push to Main Triggers a Full Deploy
The serverless AWS website is wired up to a fully automated CI/CD pipeline using AWS CodePipeline and CodeBuild. Every push to the main branch on GitHub kicks off a complete build and deploy cycle — no manual steps, no console clicks required after initial setup. The buildspec.yml file in the repo root tells CodeBuild exactly what to do: install dependencies, run the Vite build, and push the resulting static assets to S3, followed by a CloudFront cache invalidation to ensure users get fresh content.
This is the pattern that makes the whole system genuinely production-grade rather than just a demo. A serverless AWS website that requires manual deployment steps isn’t a production website — it’s a liability. Automated pipelines mean that content updates, dependency patches, and bug fixes ship consistently and repeatably, without relying on whoever happens to have the right credentials on their local machine.
For a consulting business, that reliability isn’t just technical hygiene. It’s a live demonstration of capability. Any prospective client who looks under the hood of bonefishsoftware.com is seeing an example of exactly the kind of infrastructure the company is being hired to build for them.
What This Build Actually Teaches the Industry
The broader implication of Blair’s approach is a quiet pushback against the abstraction-first culture that’s taken hold in cloud development. Platforms like Vercel and Netlify are excellent products, and for many use cases they’re absolutely the right answer. But the AWS ecosystem runs on CloudFormation and IAM and VPCs and all the underlying primitives that those platforms paper over. Enterprise cloud engineering, the kind that keeps critical infrastructure running at scale, requires practitioners who can work at that level.
Building a serverless AWS website from scratch using raw infrastructure tooling — even for something as modest as a consulting company’s marketing site — is one of the most honest ways to develop and demonstrate that capability. As AI-assisted development tools increasingly help with code generation, the engineers who understand the infrastructure layer, who can read a CloudFormation template and know exactly what resources it will create, are going to be increasingly differentiated from those who only work at the framework level. That gap is going to matter more, not less, as cloud systems grow more complex. Every serverless AWS website built on raw primitives is a practitioner proving they understand what’s actually running beneath the surface.
Source: https://dev.to/josh_blair/building-a-production-company-website-on-aws-project-overview-2dhm
