Mastering AWS Cloud Infrastructure for Startups

I've lost count of how many founders have shown me an AWS architecture diagram covered in NAT gateways, multi-region failover, and a Kubernetes cluster sized for a million users — for a product with forty signups. Nobody's being reckless on purpose. They're copying what they read in a "how Netflix does it" blog post, or what a contractor built last time, and assuming that's just what "doing AWS properly" looks like. It isn't. It's how you burn your seed round on idle compute.

I'm Jessica, and I've spent most of my career pulling startups back from that trap — teams over-building and quietly bleeding cash, or under-securing and getting a bad wake-up call. Here's the conversation I have most often: what to actually run, what to spend on, what to lock down even at two people, and how to grow it without a rewrite every six months.

Right-Size Before You Optimize

Enterprise AWS architecture solves enterprise problems: regulatory audit trails, five-nines uptime commitments, hundreds of engineers shipping into the same account, traffic patterns that genuinely need multi-AZ everything. Almost none of that applies to a startup with a handful of engineers and a product still finding its market. Copying it early doesn't make you look serious — it makes your burn rate look serious, for capacity you're not using.

The right question isn't "what would a big company run?" It's "what does my traffic and my team actually need this quarter?" A single, well-monitored EC2 instance running your app and database can comfortably serve thousands of daily users. That's not a compromise — it's correctly-sized infrastructure. Add redundancy and complexity when a specific, observed problem demands it, not because a diagram you saw online had it.

The Core Services You'll Actually Reach For

You don't need to know all of AWS. You need to know five or six services cold, and know when each one is the right tool.

Compute: EC2, Lightsail, or Lambda

EC2 is a virtual machine you control fully — install what you want, run any language, resize it as you grow. It's the default choice for most web apps. If EC2 feels like too many knobs for your first deploy, Lightsail gives you the same compute with a simpler, flat-priced setup — a good starting point if you just want your app live without becoming a networking expert first. Lambda is different in kind: you don't run a server at all, you run a function that fires on an event — a file upload, an API call, a scheduled job — and pay per invocation. It's excellent for background jobs and spiky, infrequent workloads, and a poor fit for an always-on, latency-sensitive main application.

Database: RDS

RDS is a managed Postgres, MySQL, or MariaDB instance where AWS handles patching, backups, and failover. Running your own database on a bare EC2 box feels cheaper on paper, but the moment you need a 3am restore from backup, you'll understand exactly what you were paying RDS for. This is not a corner worth cutting.

Object Storage: S3

S3 stores files — uploads, exported reports, static assets, backups — durably and cheaply, without you managing any disks. If your app handles images, documents, or logs, they belong in S3, not on your app server's local disk, which vanishes the moment that instance gets replaced.

CDN: CloudFront

CloudFront caches static content — JS bundles, CSS, images — at edge locations close to your users, so pages load faster and your origin takes less load. You don't need this on day one; you need it once you have real traffic, especially from users outside your primary region.

DNS: Route 53

Route 53 is AWS's DNS service — it points your domain at your infrastructure and can do health-check-based failover. Not exciting, but it's the thing that breaks everything if misconfigured, so set it up deliberately rather than as an afterthought.

Cost Control Isn't Optional — It's a Skill

AWS bills are famous for surprising people, and almost always for avoidable reasons.

• Set up AWS Budgets and billing alerts on day one. Not after your first scary invoice. A budget alert at, say, 80% of your expected monthly spend costs nothing and catches runaway resources — an unattached load balancer, a forgotten dev environment, a misconfigured autoscaling group — before they become a bad surprise.
• Start on-demand, move to Savings Plans once your baseline is stable. On-demand is more expensive per hour but has zero commitment — right for the exploratory phase where instance sizes and counts are still changing. Once you've run the same baseline capacity for a few consistent months, a Compute Savings Plan or Reserved Instance can cut that steady-state cost by 30-50%. Committing to reserved capacity too early is how people end up paying for capacity they later have to resize away from.
• Use autoscaling instead of provisioning for your peak. Size your fleet for Black Friday-style traffic and run it year-round, and you're paying peak price for idle capacity 350 days a year. An autoscaling group that adds instances under load and removes them when load drops means you pay roughly for what you use.
• Resist "just in case" over-provisioning. The classic mistake is picking a beefy instance size "so we don't have to worry about it," or leaving three environments running 24/7 when staging only gets used during business hours. Right-size based on actual CloudWatch metrics, not anxiety.

Security Basics That Aren't Negotiable, Even for a Team of Two

Small teams sometimes treat security as something to "get to later." Please don't. These three things take an afternoon and prevent the incidents that actually kill trust in a young company.

IAM and Least Privilege

Never use your AWS root account for daily work — lock it away with MFA and use it only for account-level tasks that require it. Create individual IAM users (or better, IAM roles via SSO) for every person and service, and grant only the permissions each one actually needs. If your deploy script only needs to push to S3 and update ECS, don't give it admin. A leaked credential with narrow permissions is an incident. A leaked credential with admin access is a company-ending event.

VPC Basics: Public vs. Private Subnets

Your Virtual Private Cloud is your own network inside AWS. The core idea to internalize: things that need to be reachable from the internet (a load balancer) go in a public subnet; things that don't (your database, your app servers) go in a private subnet and are only reachable from inside your VPC. This single pattern — public edge, private everything-behind-it — blocks a huge share of the opportunistic scanning and drive-by attacks that hit exposed databases and admin panels.

Secrets Manager or Parameter Store, Never Hardcoded

Database passwords, API keys, and tokens should never live in your code, your environment files committed to git, or your Docker image. Use AWS Secrets Manager (or the free tier, Systems Manager Parameter Store) to store them, and have your application fetch them at runtime with an IAM role. It's a small setup cost that eliminates one of the most common causes of real-world breaches: a credential sitting in plain text in a public repo.

A Reference Architecture for a Typical Web App

Here's the shape I recommend once a startup outgrows "one instance running everything" — no fancy diagram needed, just picture it:

Traffic hits Route 53, which resolves your domain to an Application Load Balancer in a public subnet. The load balancer terminates HTTPS and forwards requests to your app servers — EC2 instances in an autoscaling group, or containers on ECS — living in a private subnet, unreachable directly from the internet. Those app servers talk to an RDS instance, also private, for relational data. Uploaded files and static assets go to S3, and if you serve a lot of static content or have geographically spread-out users, CloudFront sits in front to cache and speed up delivery. Secrets and config live in Secrets Manager, pulled at boot rather than baked into images. That's the whole picture — five or six services, each doing one job, with a clean public/private boundary in the middle.

How This Should Evolve as You Grow

The mistake isn't starting simple — it's staying simple past the point it's costing you reliability, or jumping ahead of the point it's actually needed. A reasonable path: start with a single EC2 instance running your app, paired with RDS, while validating the product. Once you have real, sustained traffic and downtime starts costing revenue, move to an autoscaling group behind a load balancer for redundancy and elastic capacity. As your team grows and you're shipping multiple services or deploying more often than your EC2 workflow comfortably supports, move to containers on ECS for faster, more consistent deploys without the overhead of managing Kubernetes. Only reach for EKS once you have a specific need Kubernetes solves that ECS doesn't — multi-cloud portability, a particular ecosystem tool you depend on, or a platform team large enough to own the complexity. For most startups, that point arrives much later than expected, if it arrives at all.

Mistakes That Actually Cost Startups Money

• Leaving dev/staging running 24/7 when it's only used during work hours — a scheduled shutdown can cut that cost by two-thirds.
• Over-provisioning "flagship" instance sizes before there's traffic data to justify them.
• Forgetting data transfer costs — moving data between regions or out to the internet adds up fast and is easy to overlook until the bill arrives.
• Orphaned resources — unattached EBS volumes, idle load balancers, old snapshots — quietly accumulating cost after a project ends.
• Committing to Reserved Instances too early, before usage patterns are stable, and getting locked into capacity that no longer fits.
• Skipping billing alerts and finding out about a runaway cost a month later instead of the same day.

None of this requires a platform team or a six-figure AWS budget. It requires picking the handful of services that match what you're actually building, setting a couple of guardrails around cost and access on day one, and being honest with yourself about when your traffic — not your ambitions — actually justifies the next layer of complexity. Build for the startup you are right now. You can always add the enterprise parts later, once you're lucky enough to need them.