Every customer with a security team asks the same question. The honest answer decides whether you can take their money or not.
Why AWS — and only the boring parts of AWS — runs both products.
In Part 3 I walked through the bill line by line. About $125 a month, all in. Almost every line goes to one supplier: Amazon Web Services.
Why not Vercel, Fly, Render, or Cloudflare? Because I want my hosting provider to be boring. Not flashy. Not innovative. Not the subject of a Hacker News thread last week about a pricing change. I want it to be the electricity company — plug in, pay the bill, forget it exists. AWS — yes, complicated, ugly, console-with-a-thousand-buttons AWS — is the right answer for the business questions I actually care about.
“Where does your data live?” — the question that decides everything
This question quietly decides which cloud a small software business should pick. It almost never comes from your first customer. It comes from the one who matters — the one whose contract pays for next year, whose security team has a checklist, whose compliance officer needs a clean answer in writing.
“AWS, eu-west-1, with row-level isolation and customer-managed keys at rest” ends the conversation. The security team knows what SOC 2 means when AWS says it. They move on.
“Render, in their us-east region” starts a conversation. Now you’re explaining what Render is, whether they pass their audits, what happens if they get acquired. Every minute there is a minute not closing the deal.
This isn’t because Render is worse. It’s because credibility is a sales feature, and AWS spent twenty years building it for me.
Stable. Scalable. Secure. Nothing fancy.
AWS will not go out of business this year. It will not be acquired by someone with different priorities. It will not deprecate my service with six weeks’ notice. Boring is precisely what suits a business I want to still be running in ten years.
Flashier alternatives might be cheaper for a quarter, nicer on a Tuesday afternoon. They’re also more likely to change shape under me — and when you’re one person, every involuntary migration costs you weeks you don’t have.
“AWS is complicated” — yes, and I use about ten services
People who say AWS is complicated have opened the homepage, seen 200+ services, and recoiled. AWS isn’t a single product. It’s a catalogue. Most of it isn’t for me — it’s for Netflix, Pfizer, and the U.S. Department of Defense.
The handful I use is small and boring: S3 for storage. Lambda for pay-per-use compute. ECS Fargate for containers — not EKS, because Kubernetes is a full-time job I can’t hire for. CloudWatch for logs and metrics, so there’s no second monitoring vendor. SQS for queues. SES, SAM/CloudFormation, and Bedrock for LLM access through the back door. Everything else I deliberately ignore.
Inside that handful I pick the boring option every time. arm64 Graviton, not x86 — same code, ~20% cheaper, no thinking required. Single account, single region until the business needs more. Infrastructure-as-code from day one — anything I clicked together in the console once would haunt me forever.
The pattern: pick the AWS service that has been boring the longest. Boring means well-documented, well-trained-on by Claude and Codex, and unlikely to ship a breaking change next quarter.
100% transparency. 100% control. 100% visibility.
The other reason I run plain Docker containers on ECS — instead of pushing my code to Vercel, Render, Fly, or any “we’ll handle the infrastructure for you” platform — is that I don’t want a vendor “helping” me by dumbing down the access.
When something goes wrong, I want to see the actual CloudWatch logs, attach to the live container with ECS Exec, inspect the actual networking and IAM policies. Not a curated dashboard that shows me the three things the vendor decided were important. Not a friendly abstraction that hides what’s really happening underneath.
The platforms that abstract AWS for you are great when everything works. They’re a nightmare when it doesn’t — because the visibility you need to debug isn’t there. By the time you’ve hit a problem the abstraction can’t explain, you’re paging the vendor’s support team and waiting.
I’d rather use a slightly uglier console and own the visibility. Plain Docker, plain CloudWatch, plain IAM. When something breaks, every layer is inspectable, and the answer is in my account — not in someone else’s ticketing system.
Don’t let the LLM architect your stack
There’s a special trap waiting for anyone using Claude or Codex to build infrastructure. Ask an LLM to “design a production-grade AWS deployment” and you will get back ten Docker containers, three private subnets, two NAT gateways, a managed service mesh, a dedicated observability stack and a CI/CD pipeline so elaborate it has its own architecture diagram.
It will all be technically defensible. It will also cost ten times more than the workload actually needs, and the operational complexity will quietly eat your time for the next two years.
Architect the stack yourself. Let the LLM build what you decided. Claude and Codex are excellent at writing Terraform once you’ve told them the shape. They are poor at deciding what the shape should be — because they have no business context, no cost ceiling, and a strong bias toward the “best-practice” answer over the right-sized one.
The shape decision is yours. The typing is theirs.
Cloudflare sits in front of AWS — for free
One more piece of the stack — bolted onto AWS but not bought from AWS. Cloudflare sits in front of both products as the public front door, and the free tier is one of the most under-claimed deals in modern infrastructure.
What that gets me, for nothing:
- DDoS protection that absorbs the obvious junk before it ever reaches AWS.
- A WAF that blocks the most common attack patterns at the edge.
- TLS certificates managed automatically.
- Edge caching for static assets, taking load off the ECS container.
- A clean answer when a security team asks how traffic is filtered before it hits my origin.
I’d otherwise be paying for AWS Shield Advanced, a managed WAF, and a CDN to do roughly the same job. Cloudflare’s free tier does it well enough that I haven’t yet hit a wall. When I do, the paid tier is still cheaper than the AWS equivalents.
Two clouds. One does commodity hosting. The other does commodity security and edge delivery. Both boring on purpose.
What I deliberately don’t run on AWS
Hosting is commodity. AWS sells commodity hosting better than anyone. The non-commodity parts of the business sit elsewhere on purpose: Supabase for the database (which itself runs on AWS — I pay them to manage Postgres). Stripe for payments — nobody should build their own card processor. Postmark for transactional email, when something has to land in an inbox.
Commodity infrastructure on AWS. Specialists where specialists are worth paying for.
What this gets me in business terms
Back to the four goals from Part 1:
- Coffee budget — line-itemed pricing. Lambda costs $0 when nobody’s using it. The bill is boring and predictable.
- One operator + AI — Claude and Codex have years of AWS documentation to train on. Every problem I hit has been solved publicly before. Newer clouds don’t have that depth yet, and I notice immediately when I try.
- No on-call rota — AWS is good enough that I don’t budget time for cloud outages. I budget for my outages.
- Velocity — boring tools don’t surprise me. Stability is what enables velocity when there’s only one of you.
The electricity-company test
Could I describe what they sell to my grandmother in one sentence? “They store my data and run my code in a really big datacentre.” Good. Buy it from the boring giant.
If the answer involves “we’re reimagining” or “developer-first” or “edge-native” or “AI-powered” — that’s a vendor pitching me a story. I don’t need a story. I need the bill to be small, the system to stay up, and the security team on the other side to nod and move on.
AWS does all three. Nothing fancy.