7 AWS Architecture Mistakes Startups Make That Become Expensive at Scale

These decisions seem fine at 10 users. At 10,000, they're production incidents, security risks, or five-figure monthly bills.

Early-stage startups make architecture decisions under pressure with incomplete information. Most turn out fine. Some don't, and the ones that don't tend to compound quietly until they're either a major cost driver, a security risk, or the reason for an unplanned rewrite.

These are the patterns we see most often when doing architecture reviews for growth-stage companies.

1. A single AWS account for everything

One account for dev, staging, and production seems simple — until a developer accidentally runs a migration against prod, or a security group change in dev creates a hole that auditors find, or you need to demonstrate environment isolation to an enterprise customer.

Separate accounts are cheap to set up early and expensive to migrate to later. Production should always be isolated. Set this up before you have production traffic.

2. Admin IAM credentials in CI/CD

We still find AdministratorAccess keys stored as GitHub Actions secrets. This is a critical vulnerability — if your repository is compromised, your entire AWS account is compromised. Use OIDC federation from GitHub Actions to assume least-privilege deployment roles. This is straightforward to set up and eliminates a major credential leak vector.

3. RDS in a public subnet

Databases should never be publicly accessible. Yet we regularly see RDS instances launched in public subnets with security group rules limiting access by IP. IPs change, and someone will eventually open it to 0.0.0.0/0 "temporarily." Put databases in private subnets with no internet gateway route. Use VPC endpoints or a bastion host for administrative access.

4. No database backups tested

RDS automated backups are enabled by default — but the default retention is 7 days, and most teams have never tested a restore. Extend retention to 30 days for production, enable point-in-time recovery, and run a quarterly restore drill. You don't have backups until you've proven you can restore from them.

5. CloudWatch alarms that nobody acts on

The alarm that fires at 90% CPU on a t3.micro and sends an email to a shared inbox that nobody monitors is not observability — it's a liability. Alarms should: be on symptoms (latency, error rate) not causes (CPU, memory), route to someone who can act on them, and have a runbook link.

Three meaningful alarms your on-call actually responds to are worth more than 200 alarms nobody reads.

6. N+1 queries at scale

An API that makes one database query at 100 users makes 100 queries at 10,000 users. ORM-generated queries are particularly prone to this. The fix is the same as it's always been: query analysis, eager loading, and a read cache for frequently accessed data. At early scale this is invisible; at growth scale it's the cause of your first production incident.

7. No cost attribution at all

When you can't see which service, team, or customer is driving AWS costs, you can't optimize. Cost allocation tags take 30 minutes to set up but require SCPs and tagging policies to actually work consistently. Set this up early — once you're spending $50k/month, retroactive tagging is painful.

The common thread

All of these are easy to fix at zero traffic. They get progressively harder — and more expensive — as your system grows. The right time to audit your infrastructure for these patterns is before your Series A, not after your first security incident.