Migrate a Node.js app to AWS: the right compute target, the data layer, and the cutover.

ILong-running service or event-driven?

Most bad Node.js-on-AWS architectures come from forcing a long-running app into Lambda, or the reverse. Start from the shape of the workload.

Long-running services benefit from staying warm: a persistent API, a WebSocket server, a worker draining a queue, anything with a database pool or an in-memory cache. They want a container that boots once and serves many requests. On AWS that is ECS with Fargate.

Event-driven workloads are bursty, stateless and often idle: S3-triggered processing, webhook receivers, scheduled jobs, fan-out from SQS or EventBridge. Lambda bills only while code runs and scales from zero automatically.

The trap is the middle. A steady-traffic Express API wrapped for Lambda pays a cold-start tax on latency, fights connection exhaustion against the database, and can cost more than a small always-on Fargate task. Lambda is excellent for spiky and idle work; it is a poor fit for steady, latency-sensitive, pool-heavy APIs.

IIPicking the Node.js compute target

There are several ways to run Node on AWS. For a team migrating an existing app, these are the sensible ones.

• ECS on Fargate: The default for production Node APIs: serverless containers with VPC networking, a load balancer, per-service scaling, and separate API and worker services. The process boots once per task, so pools are reused and there is no cold start. ECS Express Mode creates the service, load balancer and scaling from one image for simple web services.
• Lambda and API Gateway: Per-request billing and scale from zero, for spiky APIs, webhooks, scheduled jobs and event triggers. Costs: cold starts on latency-sensitive paths, a 15-minute execution limit, payload limits, and connection pressure on relational databases. Provisioned concurrency removes cold starts but also scale-to-zero.
• App Runner (existing users only): App Runner was the Heroku-like option, but it closed to new customers on April 30, 2026. New teams should use ECS Express Mode instead.
• EKS or ECS on EC2: Only for specific needs (existing Kubernetes, GPUs, placement). Overkill for a single Node app.

IIIThe data layer: RDS or Aurora, DynamoDB, ElastiCache

The compute choice gets the attention; the data layer is where migration risk lives. The mapping is mechanical and your ORM usually does not change.

Relational. PostgreSQL or MySQL through an ORM or raw drivers moves to Amazon RDS (like-for-like) or Aurora (storage that grows on its own, faster failover, up to 15 readers, Serverless v2 for spiky load). Same wire protocol, so you change the connection string and move the data.

DynamoDB. A fit for key-value or single-table designs needing very high throughput, and it pairs well with Lambda because it uses HTTP connections. It is not a drop-in for a relational app: joins, ad-hoc queries and cross-table transactions make that a refactor.

Redis and files. ioredis or node-redis for caching, BullMQ queues, sessions and rate limits moves to Amazon ElastiCache (Redis OSS or Valkey) with a connection-string change. Uploads must go to S3: local-disk writes break as soon as you run more than one task. Self-hosted Elasticsearch moves to Amazon OpenSearch Service.

IVWebSockets: ALB and Fargate, or API Gateway WebSocket APIs

WebSockets are long-lived and Lambda is ephemeral, so real-time often decides the compute choice.

The low-friction path for Socket.IO or ws is a long-running container on Fargate behind an Application Load Balancer, which handles WebSocket upgrades natively. Your real-time code does not change. Across several tasks, add the Socket.IO Redis adapter on ElastiCache so a message emitted on one task reaches clients on another.

Amazon API Gateway WebSocket APIs manage connections for you and invoke Lambda on connect, disconnect and message events. They scale to large connection counts with no servers, but it is a different programming model: you rebuild the connection lifecycle around API Gateway routes and a connection store. Good for greenfield fan-out; usually not worth it for an existing Socket.IO server.

VDockerizing, secrets and CI/CD

Three mechanical tasks make up most of the hands-on work for a long-running Node app.

Dockerfile. A multi-stage build: npm ci and your build in the first stage, then a slim runtime image that copies only production dependencies and the build output, runs as non-root, sets NODE_ENV=production, and starts node dist/main.js directly. Push to Amazon ECR.

Secrets. Split process.env by sensitivity: secrets in AWS Secrets Manager (which can rotate RDS credentials), plain config in SSM Parameter Store. ECS (or Lambda) injects both as environment variables, so process.env.DATABASE_URL works as before.

CI/CD. Keep GitHub Actions and add build and test, push to ECR, and an ECS service update with health checks and rollback. Or use CodePipeline, CodeBuild and CodeDeploy for blue/green on ECS. Lambda apps use AWS SAM, the Serverless Framework or AWS CDK.

VIThe database cutover: DMS, DNS and a short window

Everything else can be built and tested without touching production. The database cutover is the one moment that touches live data.

AWS DMS does a full load into RDS or Aurora, then streams ongoing changes where your source database allows it, so at cutover you switch to an already-current copy. If change data capture is not possible from your current host, or the database is small, use a dump and restore inside a maintenance window and time a test run first.

The cutover: maintenance mode, drain the last changes, pause workers, switch DATABASE_URL and Redis settings, update Route 53 (TTL lowered a day ahead), check that writes land in RDS, leave maintenance. Re-check sequence or auto-increment values after a data-only load. Keep the old environment as a rollback until you are confident.

VIIWho runs the move, and who can fund it

You can do this yourself with the steps above. Many teams have a partner run the landing zone, the containers and the cutover.

Partner-filed funding: AWS says the Migration Acceleration Program (MAP) helps offset initial migration costs. It is built for migrations with meaningful ongoing AWS spend, so a small seed-stage API may not qualify. When the migration does qualify, your matched partner files it and AWS approves: typically $50K to $150K for startups. Depends on the workload; AWS approves. Activate credits are separate, and you apply for those yourself.

CloudRoute matches you with one vetted AWS partner. Startups pay CloudRoute nothing; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.

VIIINode.js-specific gotchas

The small set of things that turn a clean migration messy.

• Lambda cold starts: A cold function plus your dependency tree adds latency to the first request. Keep latency-sensitive synchronous APIs on Fargate, trim dependencies, or pay for provisioned concurrency.
• Connection exhaustion: Many Lambda invocations or autoscaled tasks each opening pools can exceed the database's connection limit. Use Amazon RDS Proxy and size pools per task.
• Local disk and in-memory state: Uploads, sessions and caches kept in one process break across tasks. Use S3 and ElastiCache.
• Socket.IO across tasks: Without the Redis adapter, messages do not reach clients on other tasks.
• Graceful shutdown: Handle SIGTERM so in-flight requests and jobs finish when ECS replaces a task during a deploy.