Your infra should cost $180/mo until it deserves $680/mo: the honest stages of AWS infrastructure

Most “production-grade AWS architecture” articles describe a stack that costs $600–$1,000 a month, then quietly shame you for not having it. Multi-AZ everything, read replicas, RDS Proxy, WAF, four environments. The diagrams are beautiful. The implication is that anything less is amateur hour.

Here’s what those articles never say: infrastructure has maturity stages, and skipping ahead is one of the most reliable ways to burn runway. I run both versions of the same stack — a $180/mo MVP configuration and a $680/mo production configuration — and the difference between them is not “amateur vs. professional.” It’s “pre-PMF vs. post-PMF.” Buying the second one before you’ve earned it is just setting $500/mo on fire, every month, for a year or more.

Stage 1: the $180/mo stack #

Here’s the actual line-item breakdown of the MVP stack:

Note what this stack does include: a real VPC with public and private subnets across two AZs, EKS with proper IAM, Secrets Manager with an operator syncing into the cluster, Terraform for everything, CI/CD with plan-on-PR and gated apply, and automated database migrations. The bones are professional. The sizing is honest.

What Stage 1 legitimately skips — and why that’s fine #

Multi-AZ RDS (skipped, saves ~$230/mo at production sizing).Multi-AZ protects you against an AZ failure, which happens maybe once a year per region. Pre-PMF, your realistic worst case is 20–60 minutes of downtime while RDS recovers, announced to a user base of dozens. Your automated snapshots still exist. You will not lose data; you’ll lose an afternoon.

Read replica (skipped, saves ~$115/mo).You don’t have read traffic. A t4g.micro handles thousands of queries per second of the kind early-stage apps generate. Adding a replica before you have a read bottleneck is cargo-culting.

RDS Proxy (skipped, saves ~$22/mo).Connection pooling matters when you have many pods churning connections or Lambda fan-out. With a handful of long-lived app pods, your driver’s built-in pool is fine.

HA Redis (skipped, saves ~$35/mo).If your single Redis node dies, sessions reset and your cache is cold for ten minutes. Pre-PMF, that’s a non-event. Treat Redis as ephemeral and it can’t hurt you.

WAF (skipped, saves ~$15–20/mo plus rule sprawl). Rate limiting at the app layer plus an ALB that only exposes 443 covers the realistic threat model of a product nobody is targeting yet.

One AWS environment instead of four.Dev, staging, shared, prod — each with its own RDS and Redis — quietly multiplies your bill. One prod environment plus local Docker Compose for development is genuinely enough until you have a team stepping on each other.

None of these are corners cut. They’re costs deferred until the failure mode they protect against actually costs you more than the line item does.

The real upgrade triggers #

Don’t upgrade on vibes. Upgrade when one of these happens:

1. Sustained real traffic.Not a Hacker News spike — sustained load where the t4g.micro’s CPU credits matter and p95 latency degrades during business hours.
2. Your first enterprise customer’s security questionnaire.The moment a contract or vendor review asks about RPO/RTO, multi-AZ, and DDoS mitigation, the $680 stack stops being optional. This is the most common trigger, and it arrives with revenue attached — which is exactly when you should pay for it.
3. On-call pain.The second time you’re restoring a database at 2 a.m. or hand-warming a Redis cache during peak, the math flips: multi-AZ at $230/mo is cheaper than your weekends.
4. A read-heavy feature ships.Dashboards, analytics, exports. That’s when the replica earns its keep.
5. Connection storms.If you’ve moved to autoscaling pods or async workers and Postgres connection counts spike on deploys, RDS Proxy goes from luxury to necessity.

If none of these have happened, the $680 stack is a vanity purchase.

Stage 2: the $680/mo stack, and what each dollar buys #

Each line maps to a specific failure mode you’ve now decided is too expensive to tolerate. That’s the right way to read an architecture diagram: not “is this best practice?” but “which outage am I buying my way out of, and is that outage currently cheaper than the line item?”

What stays constant — so the upgrade isn’t a rebuild #

This is the part that makes staging viable instead of a trap. Both stacks share:

• The same VPC layout. Public + private subnets, same CIDR philosophy. Stage 1 uses 2 AZs; Stage 2 uses 3. Adding an AZ is a variable change, not a redesign.
• The same Terraform module structure. network, eks, ecr, rds, redis, secrets— identical module names and interfaces. The prod repo’s rds module has multi_az, proxy, and replica as options; the MVP just sets them small or off. Upgrading is mostly editing tfvars.
• Containers and EKS from day one.This is the one place I deliberately overspend early (that $73 control plane). Because the app already runs in Kubernetes with Helm charts, secrets syncing, and migration Jobs, “scaling up” never means “re-platforming.”
• The same CI/CD shape.Plan on PR, comment the diff, gated apply on merge. The pipeline doesn’t know how big the database is.

The migration path from $180 to $680 is: add an AZ, resize the database with a maintenance window, flip multi_az = true, add the proxy and replica, add the WAF module, stand up dev/staging. A weekend of careful work, not a quarter of rebuilding.

The takeaway #

The $680 architecture isn’t wrong — it’s early. Pre-PMF, the $500/mo difference is $6,000 a year that buys you protection against failure modes that would cost you almost nothing. Post-PMF, with enterprise contracts and real traffic, the same $500 is trivially justified by a single avoided incident.

Spend like Stage 1. Architect like Stage 2. Upgrade when a trigger fires, not when a blog post makes you feel inadequate.