Thnkrr — Why These AWS Services, and What We'd Switch To

Companion to 18-aws-services-and-costs.md. One section per service: why it's the right pick for this pilot, and the pre-planned exit if we ever want to change it.

The standing rule (docs/04 §11): AWS is certain for the pilot, but nothing may depend on AWS to exist. Every AWS touchpoint sits behind a small adapter interface in our code (storage, mailer, imageScreen), and the non-AWS side of each adapter runs every day in development. Switching vendors is a config change plus a data copy — never a rewrite. That rule is why the alternatives below are real options, not wishful thinking.

S3 — file storage

Why it's the best fit here:

• It is the industry-standard way to store files, and — crucially — its protocol is a de-facto standard that many vendors implement. Our code speaks "the S3 protocol," not "Amazon."
• Presigned uploads let the browser send image bytes straight to the bucket, so our one API server never carries file traffic — fewer moving parts, the pilot's core criterion.
• Eleven-nines durability for user photos and backups with zero operational work from us.
• At our volume it costs cents; there is no cheaper managed option worth an extra vendor.

Alternatives (in order we'd consider them):

Proof the exit works: development runs on MinIO (an S3-compatible server in Docker) every day. The database stores file keys, never URLs, and images are served from our own domain — so the bucket vendor can change without touching data or links.

CloudFront — image delivery (CDN)

Why it's the best fit here:

• The permanent free tier (1 TB + 10M requests every month) means the pilot pays $0 for all image delivery. No alternative beats free.
• It sits natively in front of S3 (S3→CloudFront transfer is free) with no extra account, billing relationship, or integration work.

Alternatives:

Exit cost: near zero. A CDN is a DNS-level layer; media URLs are on our own domain, so swapping CDNs is a DNS change and a cache warm-up, invisible to users and to the database.

SES — transactional email

Why it's the best fit here:

• Cheapest option in the market at $0.10 per 1,000 emails, pay-as-you-go, no monthly fee. (SES also sells tiered "plans" — Essentials at $0.16/1,000 and up; irrelevant at our volume, we stay pay-as-you-go.)
• We send only three plain, low-volume emails (verify, reset, consent). We need deliverability and a price near zero — not templates, campaigns, or analytics.
• Our mailer speaks generic SMTP, and SES has an SMTP endpoint — so SES is just configuration, not integration.

Alternatives:

Proof the exit works: development and tests run against Mailpit (a local SMTP inbox). Switching providers is changing one environment variable.

Rekognition — automated image screening (deferred)

Why it's the (future) pick:

• The one genuinely AWS-proprietary service in the stack — used only because it's the turnkey option already inside our AWS account, priced per image with no minimum.
• Not enabled in the pilot (decision D-9): at pilot volume, human review of every image is safer than a half-tuned automated path, and this is a child-safety surface — fail-closed beats convenient.

Alternatives:

Proof the exit works: the imageScreen adapter seam exists in the pipeline today; the pilot's implementation of it is "send to human queue," which is also the permanent fallback for any vendor's uncertain verdicts.

Text moderation and AWS — evaluated, not used

Text moderation runs on Anthropic's Claude API (not AWS), and the moderation research (docs/15 §2.4) compared the field before the §3a bake-off. Two Amazon options were on the table, for the record:

If Bedrock is ever chosen, it enters through the same rule as everything else: behind the existing moderation connector seam, swappable, with the human queue as the fail-closed default.

Backend hosting & the database — why Render today, and the AWS path later

The API and Postgres deliberately do not run on AWS today (docs/04 §11). Since "should we?" keeps coming up, here is the full reasoning. Costs for every path are in docs/18's last section.

The constraint that decides everything: the backend is one always-on Node process with the job workers (pg-boss) running inside it, polling Postgres every few seconds. That shape is a safety feature — moderation jobs enqueue in the same database transaction as the content they screen. It rules out, on architecture alone:

• Lambda / anything serverless — there is no long-running process to host the workers.
• App Runner (AWS's closest thing to Render) — it throttles CPU to near-zero between web requests and scales on request traffic only. A background worker with no incoming requests is exactly what it starves. The moderation queue stalling silently is the worst failure mode this platform can have.
• Aurora Serverless v2 as a money-saver — its pitch is "pause when idle," and our job queue guarantees the database is never idle. We'd pay ~3× RDS for nothing.

Why Render wins the pilot on merit, not inertia:

• Zero-downtime deploys on git push, TLS, health checks, restart-on-crash, staging → promote — all included, all things we'd assemble by hand on AWS.
• Managed Postgres with automated backups and point-in-time recovery in the same dashboard as the app.
• Comparable or cheaper in dollars ($13–45/month) and much cheaper in attention — and attention is the scarce resource in a pilot run by a tiny team.
• Nothing about it is load-bearing lock-in: the app is a container, the DB is plain Postgres. pg_dump out, restore anywhere.

The AWS paths, ranked for when we do move:

Non-AWS alternatives to Render (same managed-PaaS shape, if Render itself disappoints): Railway (usage-based, ~$5 base), Fly.io (containers near users), Heroku (the original, pricier). For the database alone: Neon and Supabase are excellent managed Postgres, but their serverless/auto-suspend economics are wasted on a database our job queue never lets sleep — a plain always-on Postgres is the honest fit.

The exit, proven: everything runs in Docker locally every day; the database is vanilla Postgres 16 with plain SQL migrations. Moving Render → AWS (or anywhere) is: build the container, restore a pg_dump, repoint DNS. Days, not months — by design.

What we deliberately do NOT use AWS for

The pattern: AWS is used where it's a commodity behind a standard protocol (files, email, CDN), and avoided everywhere it would become architecture. That's what keeps the exit cheap and the pilot bill at a few dollars.