I Built a “AWS CDK NodejsFunction”… but for AWS Fargate

#aws #cloud #cloudnative #npm

Deploying a NodeJS application on a Fargate shouldn’t be harder than deploying it on Lambda. But it usually does.

I worked with ECS Fargate for years and I know the pain: Dockerfiles, ECR, task definition, container definition, IAM roles, networking, logging, autoscaling. None of it is wrong, but its just repeating boilerplate. You can find full code example of Fargate Service on NodeJS here.

At the same time for Lambda its pretty simple — you just use package AWS provided for us https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda_nodejs.NodejsFunction.html

This frustration led me to build fargate-nodejs — open source abstraction that helps developers create Fargate NodeJS service with just one Construct.

Idea: Lambda Style, Fargate Runtime

The core idea behind fargate-nodejs is simple:

You provide a Node.js entry file
The construct creates a production-ready Fargate service

No Dockerfile, no manual writing of ECS resources.
The goal is to hide most repetitive decision.

High-Level Architecture

Here’s how the construct works internally (simplified):

Your Node.js code is bundled using esbuild

A minimal container image is created automatically

An ECS task definition and Fargate service are generated

IAM roles and CloudWatch logs are configured

Optional integrations: Application Load Balancer (for HTTP services), Autoscaling, SQS-based workers

The result is standard AWS infrastructure, just created through a higher-level abstraction.

Example: HTTP Service on Fargate

A minimal Express app:

import express from 'express';

const app = express();

app.get('/', (_, res) => {
  res.send('Hello from Fargate');
});

import { FargateNodejsService } from 'fargate-nodejs'

new FargateNodejsService(this, 'MyService', {
  entry: './src/index.ts',
  containerPort: 3000,
});