What's This?
Here is where most people would put a portfolio. Unfortunately SRE work does not lend itself well to a portfolio. Cloud architecture isn't something people work on as a hobby project in their garage. Even if it was, that code belongs to my employer. I can't publish it.
This site is the thing I can show you. The code is at github.com/devney/www.devney.net. It is a small static site. I generally followed the AWS Well-Architected Framework, but not entirely. The Framework helps you understand the pros and cons of decisions you make while building systems on AWS. Let's talk about some of these decisions.
How the Site Works
Simplicity was a core goal for implementing this site. I chose a static site for security, reliability, and ease of maintenance.
Files live in a private, encrypted S3 bucket. CloudFront is the only reader, via Origin Access Control. The only public surface is the CDN, on purpose.
A CloudFront function on viewer-request 301s extra hostnames and trailing slashes to the canonical URL.
There are two stacks from the same Terraform: nonprod.devney.net and www.devney.net. They do not share state, so a nonprod experiment cannot replace www.
How the Site Deploys
Never do anything manually! Deployment is automated via Terraform. Automated gates will block merge if there are secrets in the code, poor formatting, or any other tests I can think up. As a final manual gate, a human (me) has to type "yes" to the Terraform plan and code does the rest.
And the code does as little as possible itself. It leverages managed services, offloading almost all the operational toil. The merge gates? GitHub Actions and repo secrets scanning. Dependabot files PRs for known vulnerabilities.
Never do anything manually, unless there's a good reason! DNS is hosted in ZoneEdit for cost reasons.
How I Know the Site Is Up
What's important about observability for a small personal site? Mostly just that I know it's up. What's up? Important distinction: I want to know that users can actually retrieve the site. Showing that Nginx is up or that the load balancer is serving 200s are proxy measures at best. I could alert on those, but it's much better to actually test the site.
So every 5 minutes a Lambda GETs / and /about.html. Both must return 200. Fail twice in a row and I get email. The probe uses a custom User-Agent so I can tell it from a person in the access logs. CloudFront's 5xx-rate alarm is a poor uptime check here: the site is quiet, and missing data is treated as not breaching. The probe is the actual uptime check.
I still keep access logs, a few metric filters, Insights queries, and a dashboard. Those are for "what happened?" They are not how I decide whether to get out of bed.
I used Lambda plus EventBridge instead of a Synthetics canary. For two URLs and one operator, a GET is enough, and it is less toil for less money.
Why I Expect It to Stay Up (Security and Reliability)
There's very little more reliable than S3 plus CloudFront. Compute hosts (Lambda as the origin, Elastic Beanstalk, Fargate, App Runner, Lightsail) fail more often than a bucket and a CDN. That's why this site is static, fronted by CloudFront. The simplicity is the reliability.
The same setup makes security easy. There is just so very little infrastructure to protect. Content is stored encrypted, and a bucket policy blocks anyone besides CloudFront from reading objects in S3. That's it.
Cost Optimization, Performance Efficiency, Sustainability
These three are the same decision as the rest of the site. Cost Optimization is a bucket, a CDN, Price Class 100, and about 17c a month. Performance Efficiency is CloudFront at the edge: cache, compression, HTTP/2 and HTTP/3, and no origin compute to tune. Sustainability is AWS running the hardware, and no idle compute for a quiet site.
What I Refused
It would be fun to overbuild this. Cognito users, fine-grained RBAC, Firehose into a data lake, an alert on every click. Unfortunately I just don't need those things for this small personal site, and I can't justify them. No WAF, no tracing in X-Ray, no PrivateLink to S3.
Operational Excellence is doing the things that are appropriate, not everything that is possible.
What Still Fails
The Well-Architected Framework calls out even more I can do! Multi-Region disaster recovery. Regular game days.
These features missing from this site are not an oversight. There was a conscious decision to leave these out because again:
Operational Excellence is doing the things that are appropriate, not everything that is possible.