Terraform AWS setup for startup MVP: a fixed-scope baseline that survives your first 10 customers

If you are a technical founder or early CTO at a seed-stage SaaS company, “Terraform AWS setup for startup MVP” is not a 400-line tutorial that spins up one EC2 instance and an S3 bucket. It is the smallest Infrastructure as Code (IaC) baseline your app can run on in us-east-1 or eu-west-1, redeploy after every GitHub merge, and grow when customer ten becomes customer two hundred — without a six-figure platform hire.

At Wolverine Solution (Montréal; US and EU delivery), we ship Web Applications, AI & LLM Systems, and DevOps & Cloud work on fixed scope. The cut line for MVP Terraform on AWS: VPC + private subnets, Application Load Balancer (ALB), ECS Fargate or AWS App Runner for containerized Node.js / Python APIs, Amazon RDS for PostgreSQL (or Aurora Serverless v2 when spiky), Amazon ECR, AWS Secrets Manager, Amazon CloudWatch, AWS WAF only when you expose a public API, and IAM roles scoped per service. Not a bespoke Kubernetes (EKS) cluster on day one.

Tools and standards you will actually touch in the first sprint: Terraform 1.5+, HashiCorp AWS provider, terraform-aws-modules on the Terraform Registry, remote state in S3 with DynamoDB locking, OIDC trust to GitHub Actions, Route 53 hosted zones, ACM TLS certs, and optionally Terraform Cloud or Spacelift if you want drift detection without building it yourself.

What should a Terraform AWS setup for a startup MVP actually include?

A startup MVP Terraform stack on AWS should provision VPC networking, a container runtime, managed PostgreSQL, secrets storage, observability hooks, and CI deploy roles — and exclude EKS, multi-region failover, and service meshes until revenue proves the need. Start with one staging environment, then clone modules for production with stricter IAM and backups.

Founders over-build when they treat week-one infra like Netflix or Stripe. They under-build when they SSH into a single t3.small and call it “devops.” The MVP middle path:

Layer	MVP default	Defer until post-PMF
Compute	ECS Fargate behind ALB, or App Runner for simpler HTTP services	EKS, autoscaling beyond 2–3 tasks
Database	RDS PostgreSQL db.t4g.micro / small, automated backups	Read replicas, Aurora multi-AZ hardening
Secrets	Secrets Manager or SSM Parameter Store	Custom HashiCorp Vault cluster
State	S3 backend + DynamoDB lock table	Multi-workspace orchestration
CI/CD	GitHub Actions → ECR → deploy	Argo CD, blue/green with CodeDeploy
Edge	CloudFront + ACM when you serve static Next.js	Global WAF rule packs

Why Terraform here, not ClickOps: your first engineer will re-create staging six times. IaC gives you a PR-reviewed infra diff, rollback, and a due-diligence artifact investors and acquirers expect. Why not Pulumi/CDK only: Terraform’s module ecosystem and hiring pool still win for agency handoffs — we document modules; your team owns the repo on day one.

How do you structure Terraform repos so a startup team can maintain them?

Structure Terraform for a startup MVP as separate root modules per environment (env/staging, env/production), shared child modules (modules/network, modules/ecs-service, modules/rds), one remote state bucket per account, and pinned provider versions — never one flat directory with hard-coded resource names.

A layout we ship and hand off:

infra/
├── modules/
│   ├── vpc/           # vpc, public/private subnets, NAT (single NAT for MVP)
│   ├── ecs-cluster/   # cluster, task exec role, CloudWatch log group
│   ├── ecs-service/   # task def, service, target group, autoscaling stub
│   ├── rds/           # postgres, subnet group, parameter group, backup window
│   └── github-oidc/   # IAM role for Actions deploy
├── env/
│   ├── staging/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   └── production/    # copy pattern; stricter vars
└── bootstrap/         # one-time: state bucket + lock table

Rules that prevent Friday-night outages:

• Pin versions. required_version and required_providers blocks; upgrade on schedule, not on deploy Friday.
• No secrets in .tfvars committed to git. Use Secrets Manager data sources or CI-injected env vars for bootstrap only.
• Tag everything. Environment, Project, ManagedBy = terraform, CostCenter — AWS Cost Explorer will thank you at month three.
• One state file per env. Blast radius stays contained; terraform destroy in staging does not touch prod.
• Use registry modules for VPC/RDS (terraform-aws-modules/vpc/aws, terraform-aws-modules/rds/aws) and wrap them — do not fork 800 lines on day one.

Checkpoint: if a new hire cannot run terraform plan in staging within 30 minutes using only your README, the repo structure failed — not the hire.

Which AWS services should you Terraform first for a typical SaaS MVP?

Terraform AWS services in this order for a SaaS MVP: bootstrap remote state, VPC networking, RDS PostgreSQL, ECR repository, ECS cluster and Fargate service (or App Runner), ALB + ACM certificate, Route 53 records, GitHub OIDC deploy role, and CloudWatch alarms on 5xx and RDS storage — then stop.

Week 1 — foundation

1. Bootstrap state (bootstrap/main.tf): S3 bucket (versioning on), DynamoDB lock table, minimal IAM for CI.
2. VPC module: two AZs, public subnets for ALB, private for ECS tasks and RDS, one NAT Gateway (cost tradeoff accepted for MVP).
3. Security groups: ALB → app tier → RDS; no 0.0.0.0/0 on database ports.

Week 2 — runtime

4. ECR repo per service; lifecycle policy to prune untagged images.
5. ECS Fargate task definition: CPU/memory sized for Node 20 or Python 3.12 API containers; awslogs driver.
6. ALB listener HTTPS with ACM cert; HTTP → HTTPS redirect.
7. RDS PostgreSQL 16: db.t4g.micro or small, 7-day backup retention, storage_encrypted = true, publicly_accessible = false.

Week 3 — delivery and ops

8. GitHub Actions workflow: OIDC assume role → docker build → push ECR → ecs update-service.
9. Route 53 alias to ALB; optional CloudFront in front of static Next.js on S3 if marketing site is separate.
10. CloudWatch alarms: ALB HTTPCode_Target_5XX_Count, RDS FreeStorageSpace, ECS service running count < desired.

For AI & LLM MVPs (RAG pipelines, agent workers), add an SQS queue module and a second Fargate service for async embedding jobs — still no EKS. For mobile backends, the same stack holds; push notifications later via SNS when product asks.

How much does Terraform AWS setup for a startup MVP cost — in AWS and in agency time?

Expect roughly $120–$350/month in AWS run-rate for a lean MVP stack (single NAT, Fargate 0.25–0.5 vCPU, small RDS, minimal log retention), plus $0 Terraform OSS licensing — and fixed-scope DevOps effort from $6.4k for a production-grade baseline with CI, docs, and handoff, typically 2–4 weeks calendar time.

AWS monthly (directional, us-east-1)

Item	MVP range
NAT Gateway	$32–45 + data
ALB	$18–25 + LCU
Fargate (1–2 tasks)	$25–80
RDS db.t4g.small	$25–45
CloudWatch logs	$5–20
Secrets Manager	$2–8
Total	~$120–$350

Costs spike when founders add a second NAT per AZ, oversized RDS, or always-on GPU — none belong in MVP Terraform.

People time: a senior platform engineer bills 40–80 hours to go from empty AWS account to documented modules, CI green, and runbooks. Agencies on T&M often burn 120+ hours re-discovering the same VPC diagram. Fixed-scope SOWs should name deliverables: module list, environments, CI pipeline, diagram, and a 60-minute handoff session — not “DevOps support.”

KPI for your infra spend: AWS bill ≤ 8% of MRR until $14k MRR; if higher, you over-provisioned or left debug resources running. Review: monthly in Cost Explorer, tagged by Environment.

What mistakes do startups make when they Terraform AWS for an MVP?

The most common mistakes are provisioning EKS or multi-AZ everything on day one, storing Terraform state locally, running RDS publicly accessible for “easier debugging,” skipping IAM least-privilege for CI roles, and never defining a destroy/rollback runbook — each creates cost, security, or recovery debt before product-market fit.

Mistake → fix

• EKS because “we’ll need it later.” → Fargate now; migrate to EKS only with a written trigger (e.g., >15 microservices or custom sidecar requirements).
• Flat main.tf with 900 lines. → Split modules; enforce terraform fmt and tflint in CI.
• Production credentials on a laptop. → SSO (AWS IAM Identity Center), no long-lived access keys in Slack.
• No backup test. → Quarterly restore drill on RDS snapshot to staging — 30 minutes, high leverage.
• Terraform and app deploy coupled. → App ships via Actions; infra changes via separate workflow with required plan artifact on PRs.

If you searched wolverine software or wolverine app, this is Wolverine Solution — we build custom SaaS and internal tools for founders and SMB operators, not unrelated consumer apps. (And no, we did not build wolverine pc.)

What SaaS-specific infrastructure decisions should Terraform encode on day one?

Early SaaS infra fails on product boundaries, not missing services. Before customer one, Terraform should encode three decisions: where tenant data lives, how webhooks and background jobs run, and how staging mirrors production auth and data shape — not just which AWS services you provision.

Tenant and data boundaries. Even single-tenant v1 benefits from a organization_id (or equivalent) column strategy and separate S3 prefixes per tenant if you store uploads. Terraform modules should tag resources with DataClass = customer_pii where applicable — auditors and enterprise prospects ask early.

Webhooks and async work. Stripe billing webhooks, Clerk/Auth0 session events, and email provider callbacks need a stable HTTPS endpoint on the ALB (or App Runner URL) plus an idempotent worker — usually the same ECS service or a dedicated worker service with SQS in front. Encode the queue, dead-letter queue, and IAM policy in Terraform; do not hardcode queue URLs in application env vars without a module output.

Staging parity. Staging should use the same module tree as prod with smaller instance sizes — not a different hosting vendor. Auth flows break when staging runs Supabase and prod runs RDS with different JWT issuers. Match Route 53 (or Cloudflare) DNS patterns: staging.app.example.com and app.example.com on the same ALB listener rules where possible.

Adding RAG or support bots? Staging needs the same OpenSearch/pgvector shape as prod — eval scores lie when retrieval infrastructure differs.

What does the 4-week timeline look like week by week?

A 4-week Terraform AWS timeline is a sequence of acceptances: state and VPC by end of week 1, identity and runtime by end of week 2, data and alarms by end of week 3, CI gates and runbooks by end of week 4. Miss an acceptance and the calendar slips. The scope does not quietly expand.

1. Week 1: Repo layout (modules/ + envs/), remote state, VPC, tagging, Flow Logs. Exit: terraform apply for network in dev.
2. Week 2: OIDC roles, ECS/EKS skeleton, ALB, ACM, Secrets pattern. Exit: hello-world service reachable over HTTPS in dev.
3. Week 3: RDS, S3, backups, CloudWatch alarms, SNS. Exit: app talks to DB; restore drill documented.
4. Week 4: Staging parity, PR plan checks, prod apply path, runbooks, live acceptance. Exit: signed checklist + recorded walkthrough.

US and EU founders often pick one primary region first (us-east-1 or eu-central-1 / eu-west-1) and encode a second region as a later module—not week-1 multi-region. That keeps fixed scope honest.

What can wait until after the first paying customer?

A multi-account security organization, a custom developer platform, a service mesh, multi-region failover, a full policy-as-code program — most of that can wait. Defer a control when the current customer contract and data classification don’t require it. Just record the trigger that will make it necessary, because infrastructure maturity left to memory never happens.

Reasonable post-launch triggers:

Add later	Trigger
Separate security and log-archive accounts	Enterprise security review or multiple production accounts
Multi-region disaster recovery	Contractual uptime requirement that one region cannot meet
Terraform policy as code	Multiple deployers or repeated review mistakes
Web application firewall tuning	Public attack traffic or customer requirement
SIEM integration	Audit volume exceeds manual investigation
Kubernetes	Workload or deployment constraints justify its operating cost
SOC 2 readiness program	Sales pipeline requires formal assurance

SOC 2 asks for none of Kubernetes, multi-cloud infrastructure, or a particular Terraform module hierarchy. It asks for controls that are defined, followed, and evidenced.

Acceptance KPI: every deferred control has an owner and a measurable adoption trigger. Review the list after the third paying customer or on November 16, 2026, whichever comes first.

FAQ

How long does Terraform AWS setup take for a startup MVP?

For an experienced team, 2–4 weeks to production-ready staging plus production clone: bootstrap state, VPC, RDS, ECS or App Runner, ALB, CI deploy, and basic alarms. Solo founders following tutorials often need 6–10 weeks because they redo networking and IAM three times. Fixed-scope agency delivery targets one written architecture diagram, module README, and handoff call so your first hire extends rather than replaces the stack.

Should startups use ECS Fargate or AWS App Runner for an MVP?

Use App Runner when you have one stateless HTTP API or container and want the fastest path with minimal Terraform surface. Choose ECS Fargate when you need sidecars, background workers, private subnet placement, or multiple services behind one ALB — typical for Next.js BFF + Python API + queue worker. Both beat EKS on ops burden for teams under five engineers.

Do you need Kubernetes on AWS for an MVP?

No — most seed-stage SaaS MVPs do not need EKS. Fargate or App Runner covers container workloads until you have clear multi-tenancy, custom networking, or team experience that justifies control-plane cost. Investors rarely reward Kubernetes in due diligence; they reward uptime, deploy frequency, and sane AWS bills.

Can Terraform manage staging and production on the same AWS account?

Yes, and many startups start that way: separate Terraform workspaces or directories, separate state files, separate VPCs or at minimum separate subnets and security groups. Use distinct IAM roles for CI deploy per environment. Move to separate AWS accounts under AWS Organizations when you need blast-radius isolation — often after SOC 2 scoping, not before first paying customer.

When should a startup hire an agency vs hire a DevOps engineer?

Hire an agency for a fixed-scope foundation when you need infra in weeks, not quarters, and no full-time platform hire yet — typical from pre-seed through ~15 engineers. Hire in-house when deploys are daily, compliance scope grows (SOC 2, HIPAA), and someone needs to own on-call for platform 24/7. Agencies should hand off modules and runbooks; they should not become permanent T&M “cloud babysitters.”

---

Do we need Terraform if we already deploy on Vercel and Supabase?

Not immediately. Vercel + Supabase is a valid pre-PMF stack for many US/EU seed SaaS products. Move to Terraform on AWS when you need private networking, custom worker runtimes, predictable egress costs at scale, enterprise prospects asking for data residency, or staging/prod parity your current host cannot mirror. The trigger is a concrete product or compliance requirement — not “we should sound more serious.”

Does a Terraform landing zone make us SOC 2 compliant?

No. Terraform can implement and document technical controls, but SOC 2 also covers policies, access reviews, vendor management, incident response, evidence, and consistent operation over time. A landing zone supports readiness. It doesn’t replace an audit or prove the team follows the controls it declared.

Ready to ship infra that matches your product scope?

Wolverine Solution delivers fixed-scope DevOps & Cloud work — Terraform modules on AWS, GitHub Actions CI, ECS Fargate or App Runner, RDS PostgreSQL, and handoff docs your team owns — alongside Web Applications, Mobile Apps, and AI & LLM Systems when the MVP is more than empty VPCs.

Book a 30-minute scoping call. We will map your current repo (Next.js, Node, Python, React Native), name what belongs in MVP Terraform vs phase two, and return a written fixed-scope estimate — no open-ended retainer required.

---

Need this built? Our team does fixed-scope fixed-price mvp — scoped, priced and delivered in weeks.