The Complete AWS Infrastructure Setup for a Node.js SaaS

Why Infrastructure Decisions Made in Month One Matter in Year Three

Infrastructure is the part of a SaaS product that nobody thinks about until it fails. By then, the cost of fixing it is enormous — because everything else has been built on top of it. The setup we describe here is what we deploy for client products from day one, so that scaling from 100 to 100,000 users does not require a rewrite of the infrastructure layer.

The Core Components

A production-grade Node.js SaaS on AWS requires the following components, and each of these should be provisioned through Terraform — no manual console clicks:

• VPC with public and private subnets across at least two availability zones.
• ECS Fargate or EKS for container orchestration.
• RDS PostgreSQL in Multi-AZ for the primary database.
• ElastiCache Redis for session storage, caching, and queue metadata.
• Application Load Balancer with HTTPS termination.
• S3 + CloudFront for static assets and user-uploaded media.
• SES or Resend for transactional email.
• Route 53 for DNS management.
• ACM for SSL certificate provisioning and renewal.
• CloudWatch for logs, metrics, and alarms.
• AWS Secrets Manager for all secrets — no hardcoded credentials, ever.

ECS Fargate vs EKS: The Honest Comparison

For most SaaS products under 20 services, ECS Fargate is the right choice. It is simpler to operate, cheaper at low to medium scale, and requires no cluster management overhead. You define task definitions (essentially Docker Compose for production), services that maintain a desired count of running tasks, and let Fargate handle the underlying compute.

EKS becomes worth the complexity when you need advanced scheduling (GPU workloads, spot instance management), service mesh capabilities (Istio, Linkerd), or you are already standardised on Kubernetes tooling across your organisation. At fewer than 20 microservices with a team of under 10 engineers, EKS's operational overhead will consume more engineering time than it saves.

The Terraform Module Structure

infrastructure/
├── environments/
│   ├── staging/
│   │   └── main.tf        # Staging-specific variable values
│   └── production/
│       └── main.tf        # Production-specific variable values
├── modules/
│   ├── networking/        # VPC, subnets, security groups, NAT
│   ├── ecs/               # ECS cluster, task definitions, services
│   ├── rds/               # RDS instance, parameter groups, backups
│   ├── redis/             # ElastiCache cluster
│   ├── alb/               # Load balancer, target groups, listeners
│   ├── s3-cloudfront/     # Bucket, distribution, origin policies
│   └── monitoring/        # CloudWatch dashboards, alarms, log groups
└── shared/
    └── backend.tf         # Remote state configuration (S3 + DynamoDB lock)

Zero-Downtime Deployments

ECS handles zero-downtime deployments through rolling updates. The deployment process: ECS launches new tasks with the new container image, waits for them to pass health checks, then terminates old tasks. The load balancer drains connections from old tasks before termination.

The configuration that matters:

• Set the minimum healthy percent to 100% and the maximum percent to 200%. This ensures old tasks are not terminated before new tasks are healthy.
• Implement a /health endpoint that checks database and Redis connectivity — not just HTTP 200.
• Set the ALB deregistration delay to 30 seconds to allow in-flight requests to complete before a task is terminated.
• Handle SIGTERM in your Node.js application to gracefully close the HTTP server and finish in-flight requests.

Database Migration Strategy

Running database migrations as part of the application startup is dangerous. If your deployment has 3 tasks and the first one runs migrations while the other two are still running the old code, you have a window where old code is running against a new schema. The solution: run migrations as a separate ECS task before updating the application service. Your CI/CD pipeline should be: run migrations → verify migrations succeeded → deploy new application containers.

Cost Optimisation Without Compromising Reliability

The three highest-impact cost optimisations for early-stage SaaS:

1. RDS right-sizing: Start with db.t4g.medium and scale up based on actual CPU and memory metrics. Most early-stage products are dramatically over-provisioned on database compute.
2. NAT Gateway: Each NAT Gateway costs ~$32/month plus data transfer. If your private subnets need outbound internet access only for a few services, using a single NAT Gateway in one AZ (with failover tolerance, not full HA) saves $32–96/month at early stage.
3. Spot instances for non-critical workloads: Background job processors and non-customer-facing services can run on Spot instances at 70% cost reduction. Never run your customer-facing API on Spot without a fallback.

Secrets Management

Every secret — database passwords, API keys, JWT secrets — lives in AWS Secrets Manager. ECS tasks retrieve secrets at startup via the secrets field in the task definition. Application code reads from environment variables. No secrets in code, no secrets in environment files committed to version control.

Rotation: configure automatic rotation for database credentials using Secrets Manager's built-in rotation for RDS. For third-party API keys, set calendar reminders for rotation and update the secret value — ECS tasks will pick up the new value on their next restart.