Why AWS is a great place to start a new project

AWS for new projects sounds like the wrong order of operations. It’s the platform with 200-plus services and the console that makes people close the tab. Surely you start on something simpler and “move to AWS when you need it”?

The argument here is the opposite. AWS is the best place to start precisely because starting costs nothing, the ceiling is effectively infinite, and you never have to do the migration. The one real downside is setup complexity, and that’s a problem you solve once, not a bill you pay monthly.

What a new project costs on AWS in month one

An idle AWS project costs $0. There’s no subscription, no minimum spend and no per-seat fee. You’re billed for resources that run, by the unit they consume, and most of the pieces a new project needs are free at low volume.

Here’s what a typical small web project uses and what it costs while traffic is near zero:

The right-hand column comes from the AWS Free Tier page, which lists the allowances that never expire. Check it before you rely on a number; AWS adjusts them occasionally.

Two things stand out. First, every structural piece (accounts, IAM, the deploy connection) is free regardless of plan. Second, the allowances are generous enough that a project with a handful of users often stays at $0 for months. We dig into the plan details, including the credits that new accounts receive and the catch for accounts in an Organization, in the AWS Free Tier in 2026, explained.

Pay per use is the right model for an idea

A flat monthly fee charges you for the possibility of traffic. Pay-per-use charges you for traffic. While a project is an idea, the second number is zero.

That sounds trivial until you count projects. If you start something new every few weeks, flat fees compound: $20 here, $15 there, for things that may or may not go anywhere. Each one feels small. Together they’re a tax on experimenting, and the natural response is to experiment less.

On AWS, ten dormant projects cost the same as one: nothing. You can keep every experiment deployed and reachable at a URL indefinitely, and only the ones that find users ever appear on the bill. That’s the economics you want when you’re trying to find out which idea works, which is the whole game in the early days. See why speed of iteration matters for the other half of that argument.

The flip side is real: pay-per-use means a mistake can also cost money, where a flat plan would just throttle you. That’s why a budget alert and a separate account per project are non-negotiable, and we cover both in how to avoid a surprise AWS bill.

Scaling without rebuilding

The serverless building blocks you’d pick for a tiny project (Lambda, DynamoDB, S3, CloudFront, SQS) are the same ones that run at enormous scale. You don’t outgrow them; you just pay more as usage grows.

This is the argument against “start simple, migrate later.” Migrations are where projects go to die. The code that was quick to write on a hobby platform has to be rewritten against a different database, a different auth system and a different deploy model, usually right when the project is finally busy enough to matter.

On AWS the scaling story is mostly boring:

• A Lambda function that handles one request a day handles a thousand a second without changes. You may raise a concurrency quota.
• DynamoDB on-demand pricing scales from zero to millions of requests with no capacity planning.
• S3 and CloudFront don’t have a “too big” setting.
• When you do need something heavier, a container service or a relational database, it’s in the same account, on the same network, under the same permissions.

There’s a lock-in argument against this, and it’s fair: code written against DynamoDB and Lambda is AWS code. The honest response is that every platform has lock-in, and the question is whether you’d ever want to leave. The usual reason people leave a hosting platform is that they hit its ceiling. AWS doesn’t have one you’ll reach.

What actually hurts: the setup

The hard part of AWS for new projects isn’t running anything. It’s the first afternoon: creating an account, structuring it so a second project doesn’t share it, writing IAM roles, and wiring a deploy pipeline that doesn’t involve pasting access keys into GitHub.

Done properly, that afternoon looks like this:

1. Create a management account and enable AWS Organizations.
2. Create a member account for the project, so it’s walled off from everything else. (Why one account per project covers the reasoning.)
3. Set up IAM Identity Center so you sign in without long-lived keys.
4. Create an OIDC identity provider for GitHub and an IAM role that trusts one repository on one branch.
5. Write the deploy workflow.
6. Add a budget alert.
7. Scaffold the project, commit, push, confirm the deploy works.

Every step is documented. The Organizations guide and the IAM OIDC guide are thorough. But it’s seven steps across three consoles, with several places to make a mistake that you won’t notice until something leaks or a deploy fails on a Friday. Seasoned teams budget days for it. Solo developers usually do half of it and promise to finish later.

The fix is to treat setup as a product problem rather than a chore: do it once, correctly, and make it repeatable. A platform team does this for a company with a “landing zone.” TigerSoup does it for individuals and small teams, creating the account, the roles, the OIDC connection and the first commit for a new project in under a minute, with nothing it creates costing anything until you run something.

A sensible starter stack

For most new web projects, a static frontend on S3 and CloudFront with a Lambda API and DynamoDB is the right starting point. It’s $0 idle, scales without changes, and every piece is in the always-free tier.

Concretely:

• Frontend: a static build (Astro, Next.js static export, plain HTML) in S3, served by CloudFront with a certificate from ACM. This site runs that way.
• API: Lambda functions behind API Gateway or a Lambda function URL. Node, Python and Go all cold-start fast enough for a small app.
• Data: DynamoDB on-demand. If you know you need SQL, Aurora Serverless v2 scales down to very little, though not to zero; start with DynamoDB unless you’re sure.
• Infrastructure as code: AWS CDK or SAM, committed to the repo, so the whole stack deploys from GitHub Actions and can be torn down with one command.
• Deploys: GitHub Actions with OIDC, no stored keys. Production gated behind the main branch.

Skip EC2, load balancers and NAT gateways until you have a reason. Those are the pieces with hourly charges, and they’re the usual source of a “why is this costing $40 a month” moment on a project with no users.

If you build with AI agents, this stack has one more advantage: it’s all code in one repository, so a CLAUDE.md file can describe the whole thing in a page and the agent can deploy it the same way you do.

Where this fits

Picking AWS is step zero on the new project setup checklist. It costs nothing to start, you never migrate off it, and the only real cost is the setup afternoon, which you can automate away.

TigerSoup is a free Mac app that does that afternoon for you: a separate AWS account for the project, a private GitHub repository, and keyless deploys wired between them, in under a minute. Everything it creates lives in your own AWS and GitHub accounts, so there’s nothing to move if you stop using it.