AWS for startups: the setup we'd pick, and the checklist to go with it.

The default AWS setup for a startup, in one paragraph.

Three AWS accounts under AWS Organizations (management, staging, production). People sign in through IAM Identity Center, never as root. One region, close to your customers. Containers on ECS with Fargate, Postgres on RDS, files in S3, CloudFront in front. Secrets in Secrets Manager or Parameter Store. CloudTrail, GuardDuty and a budget alert switched on in the first week. Everything written in Terraform from day one.

That's it. Nothing on that list needs a platform team, and none of it has to be thrown away when you grow. The rest of this guide explains each choice, the traps that cost money, and a checklist by stage you can work through.

Account structure: separate prod from everything else.

The single most useful thing you can do on AWS costs nothing. AWS Organizations is offered at no additional charge, and it lets you put production in its own account. A mistake in staging then can't delete a production database, and a leaked staging key can't read customer data.

A layout that fits a team of two to twenty:

• Management account. Billing, Organizations, Identity Center. No workloads, ever.
• Production account. Customer data lives here and only here.
• Staging account. Staging, previews, experiments. Developers get broad access.
• Later, a log archive and a security tooling account, when a SOC 2 audit or an enterprise customer asks where logs go.

IAM Identity Center is free and replaces IAM users for people. Everyone gets one login with MFA and picks the account and role they need. Leavers are removed in one place. If you already use Google Workspace or Microsoft Entra, connect it as the identity source.

Lock the root user away. Give it MFA, delete any access keys, and point its email at a shared inbox rather than a founder's personal address. Once you have Organizations, turn on centralised root access: AWS then lets you remove root credentials from member accounts entirely, and new member accounts are created without them.

Region choice: pick one and stay there.

Choose the region closest to most of your users, unless a customer contract or data residency rule says otherwise. EU customers asking about GDPR will be happier with Frankfurt, Ireland or Stockholm than with Virginia. If you have no preference, us-east-1 gets new services first and is among the cheapest regions.

Then stay in one region. Multi-region adds data transfer, replication and a second copy of everything to patch, and very few startups need it before they have a contract that demands it. Spread across Availability Zones inside your region instead. That covers most outages a small company will ever see.

Budgets and cost alarms: set them before the first deploy.

AWS doesn't stop spending when you run out of money. It sends a bill. So set up the alarms on day one:

• An AWS Budget on the monthly total, alerting at 50%, 80% and 100% of what you expect to spend. Budget monitoring and notifications are free.
• A budget on gross cost, before credits. If credits cover the bill, the net figure stays at zero and tells you nothing until the month they run out.
• Cost Anomaly Detection, emailing a shared address. It catches the runaway Lambda loop or the forgotten GPU instance within a day or so.
• Cost allocation tags for environment and service, so the bill can be split by what caused it.

Send alerts to a channel people actually read. An alert that lands in a former employee's inbox is no alert. Our AWS cost guide for startups goes further into where the money goes once you're running.

AWS credits for startups, briefly.

AWS Activate gives self-funded startups $1,000 (up to $5,000 for some) through Founders, and backed startups up to $200,000 through Portfolio, via an accelerator or investor. Separately, new AWS accounts get $100 in Free Tier credits, with up to $100 more for trying services, for up to six months. To use Activate credits the account must be on a paid plan.

We cover tiers, eligibility and rejection reasons in AWS Activate credits. The thing to plan for is the end. Credits hide the real bill, so architecture choices made while AWS is "free" show up all at once. Model the date with the AWS credits runway calculator, and if it's close, read what to do when credits are ending.

The security baseline: small, and switched on early.

You don't need a security team to get the basics right. You need these, in every account:

• MFA for every human, enforced through Identity Center. No IAM users with long-lived access keys for people.
• A CloudTrail trail for the whole organisation, writing to an S3 bucket nobody can delete from. The first copy of management events delivered to S3 is free, and the console keeps 90 days of event history at no charge.
• GuardDuty in every account and region you use. New accounts get a 30-day free trial, after which you pay by volume of logs and events analysed. The trial tells you what it will cost before you commit.
• S3 Block Public Access at the account level, and encryption on RDS and EBS.
• CI deploys through OIDC roles, not access keys pasted into GitHub secrets. Most CI platforms support this; compare CI/CD tools on OIDC to AWS.
• A guardrail policy in Organizations that stops anyone disabling CloudTrail or leaving the organisation.

This list is also most of the infrastructure half of a SOC 2 readiness project. If enterprise customers are already asking for a report, see SOC 2 for startups.

Backups: the restore is the part that matters.

RDS automated backups let you restore to any point in the retention period. Set retention to at least 7 days in production, and longer if you can afford it. Read the fine print on deletion: unless you choose to retain automated backups, they are deleted along with the database. Manual and final snapshots survive.

Three habits cover most of the risk:

• Turn on deletion protection for the production database.
• Copy snapshots to a separate account, so a compromised production account can't wipe its own backups.
• Restore into staging once a quarter and time it. An untested backup is a hope, not a plan.

Turn on versioning for S3 buckets that hold anything customers uploaded, with a lifecycle rule that expires old versions so storage doesn't grow forever.

To write down RTO and RPO and price the recovery options, use our disaster recovery plan template.

What to avoid early.

• Kubernetes without a one-sentence reason and someone to own upgrades.
• Multi-region before a contract requires it.
• Microservices for a team of four. One deployable app and one worker is fine.
• Hand-built resources in the console. Whatever you click together today, someone has to reverse-engineer at Series A.
• Savings Plans or Reserved Instances while the architecture is still changing, or while credits pay the bill.
• Logs kept forever. CloudWatch log groups default to never expiring. Set retention in weeks.
• One shared AWS account for everything, including a co-founder's side project.
• Services closed to new customers. Check a service's status page before building on it; App Runner is the recent example.

Not sure when this stops being a side job for your CTO? Our DevOps for startups guide and when to hire a DevOps engineer cover that.