← Articles

April 4, 2026 · Tim Fraser, Cloud Operations Lead

AWS for Startups — What You Actually Need (and What You Don't)

You just raised a seed round. Or you're bootstrapping and every dollar counts. Either way, someone on the team needs to set up AWS, and the sheer number of services makes it feel like you need a PhD in cloud architecture just to ship a web app.

You don't. Most SaaS startups need the same handful of services. The trick is knowing which ones to use, which ones to skip, and when the answer changes as you grow.

What a typical SaaS startup actually needs

If you're building a standard web application — API backend, database, frontend — here's what your AWS footprint should look like at the early stage:

Compute: One or two EC2 instances, or a small ECS cluster if you're running containers. Start with t3.medium or t3.large. Graviton (t4g) instances give you about 20% better price-performance if your stack supports ARM. Don't over-provision — you can resize in minutes. Database: One RDS instance running PostgreSQL or MySQL. db.t3.medium or db.t4g.medium is fine for most startups under 10,000 users. Skip Multi-AZ until you actually need high availability — it doubles your database cost and at the early stage, 30 seconds of downtime during a failover is not your biggest problem. Storage: S3 for file uploads, static assets, backups. It's cheap, durable, and you'll never outgrow it. Use lifecycle policies from day one to move old objects to cheaper storage classes. CDN: CloudFront in front of your frontend and static assets. It's practically free at low traffic volumes and makes your site fast globally. You can also put it in front of your API for caching and DDoS protection. DNS and certificates: Route 53 for DNS, ACM for free TLS certificates. Simple, reliable, and one less thing to manage.

That's it. Five services. You can have this running in a day.

What to avoid at small scale

Here's where startups burn money:

NAT Gateway. If your instances are in private subnets and need outbound internet access, a NAT Gateway costs about $32/month just to exist, plus $0.045/GB for data processing. At scale this makes sense. At startup scale, put your instances in a public subnet with proper security groups instead, or use VPC endpoints for AWS services. Elasticsearch / OpenSearch. The smallest OpenSearch domain costs roughly $70/month and you probably don't have enough data to justify it. Use PostgreSQL full-text search until it genuinely can't keep up — for most startups, that's a long time. EKS. Kubernetes is powerful but the control plane alone costs $73/month, and the operational overhead is real. Unless your team already knows Kubernetes well, ECS or even plain EC2 with a deploy script will serve you better. You can always migrate later. Multiple environments that mirror production. Your staging environment does not need to be the same size as production. Use smaller instances, single-AZ databases, and tear down what you're not using. A staging RDS that runs 24/7 at Multi-AZ costs the same as production. Managed services you could skip. ElastiCache when your database isn't even under load. SQS when a simple cron job would do. Step Functions when a for-loop works fine. Each managed service adds cost and complexity. Add them when you feel the pain, not before.

When things change

The services that are right at $500/month aren't necessarily right at $5,000/month. As you scale, you'll need to reconsider your architecture. The challenge is knowing when.

Common inflection points:

The problem is that most startup CTOs are too busy building product to notice these inflection points until something breaks.

How plainfra helps

plainfra connects to your AWS account with read-only access and lets you ask plain-English questions about your infrastructure. But for startups, the real value is the weekly health report.

Every week, plainfra scans your account and emails you a prioritised summary: what's over-provisioned, what's under-provisioned, what's costing more than it should, and what security issues need attention. If you manage multiple AWS accounts — say, production and staging — the report covers all of them.

You don't need to remember to check your instance sizing or review your security groups. plainfra checks for you and tells you when something needs your attention. When your t3.medium is consistently at 15% CPU, you'll know. When that NAT Gateway someone added for testing is quietly costing $32/month, you'll know.

For a startup CTO who's also writing code, talking to customers, and hiring — that weekly email is the difference between catching a problem early and discovering it on next month's bill.

Try plainfra free → 50K tokens, 7 days, no charge. Or see the interactive demo →.