AWS
AWS for indie builders without the pain
The five AWS services that matter, why bills surprise people, and when the complexity pays off.
9 min read · Updated July 1, 2026
AWS is the default cloud. It is also a maze of acronyms, billing dimensions, and footguns that have emptied indie dev bank accounts.
You do not need all of AWS. You need five services and the discipline to ignore everything else until a real requirement forces your hand.
The five services you actually need
S3 — Object storage. User uploads, static assets, backups, log archives. Pennies per GB. The foundation of almost every AWS stack.
CloudFront — CDN in front of S3 or your origin. Caches assets globally, terminates TLS, cuts egress from your servers. Pair it with S3 for static sites and file delivery.
Lambda — Functions on demand. Webhooks, cron jobs, image thumbnailing, glue between services. Pay per invocation and duration. No server when idle.
RDS — Managed Postgres or MySQL. Automated backups, patches, failover options. More expensive than Postgres on a VPS but less ops than running it yourself on EC2.
SES — Email sending. Transactional mail from your app — password resets, receipts. Cheap at volume if you verify domains and stay out of the spam folder.
That is the indie starter set. S3 plus CloudFront for assets. Lambda for small compute. RDS when you need relational data with SLAs. SES for mail.
Add EC2 or ECS later if Lambda’s limits bite. Add SQS when you need queues. Ignore EKS unless someone pays you to learn Kubernetes.
Why bills surprise people
AWS pricing is ** dimensional**. You pay for storage, requests, egress, compute seconds, data transfer between services, NAT gateways, public IPv4 addresses, and features you enabled once and forgot.
Classic surprises:
Egress — Data leaving AWS to the internet costs money. CloudFront helps for static assets. API responses straight from RDS-backed EC2 in one region do not.
NAT Gateway — Private subnets that need outbound internet pay per hour plus per GB. A forgotten NAT in three AZs is hundreds per month.
Idle resources — Elastic IPs not attached, old EBS volumes, oversized RDS instances “just in case”.
Free tier expiry — Twelve months pass. The same stack doubles.
Region mistakes — Cross-AZ traffic, replicating data you did not mean to replicate.
My advice: set billing alarms on day one. Use Cost Explorer weekly. Tag resources by project. One surprise invoice teaches more than this guide — alarms prevent the lesson from hurting.
A minimal stack in practice
Static marketing site plus API:
- S3 bucket for built HTML and JS
- CloudFront distribution with the bucket as origin
- Lambda behind API Gateway for
/api/* - RDS Postgres (small instance) in the same region as Lambda
- SES for signup emails
Deploy the frontend with CI pushing to S3 and invalidating CloudFront. Keep Lambda functions small and close to RDS region to cut latency and transfer.
You will write more IaC or click more console than on Railway. Terraform or AWS CDK pays off if you stay on AWS long term.
When AWS is worth it
Choose AWS when:
- You need enterprise credibility — clients expect it
- You are already on AWS credits — startups, accelerators, day jobs
- Your architecture maps cleanly to S3 + Lambda + RDS
- You have—or will hire—someone who reads billing dashboards
StackPlan recommends AWS for apps with compliance requirements, heavy object storage, or teams that outgrew a single VPS but need more control than Railway offers.
When to skip it
Use Cloudflare, Railway, Fly, or Hetzner when:
- You want one invoice you can predict in five minutes
- Nobody on the team wants to debug IAM policies
- Your app is a standard web SaaS that fits a managed platform
- NAT gateways and egress math sound like a hobby you reject
AWS is not evil. It is professional-grade. Professional-grade tools expect professional-grade attention.
If you are an indie builder shipping v1, default elsewhere. Reach for AWS when the problem — scale, compliance, storage volume — genuinely outgrows simpler hosts.
Learning which five services matter is the easy part. The hard part is knowing whether your app’s shape and growth path justify opening the AWS console at all — before the bill teaches you the hard way.
Reading is one thing. Shipping is another.
Answer four questions about your app and StackPlan recommends a stack on AWS, with real monthly costs at your traffic.
Plan my stack — free