Serverless Framework Comparison and Selection

·23 min read·Cloud and DevOpsintermediate

As cloud-native patterns mature, teams need practical guidance on choosing the right serverless framework for real production workloads.

A developer workstation with code on screen and a diagram showing a serverless API, functions, and event-driven cloud resources, symbolizing framework selection for serverless applications

Every time I start a new serverless project, I find myself asking the same question: do I go with a purpose-built serverless framework, lean on general-purpose IaC tools, or embrace the managed runtime's native experience? It's not academic. The choice affects how fast we ship, how much control we keep, and how we debug at 2 a.m. when something is quietly failing. Over the past few years, I've built APIs, event-driven data pipelines, and background workers using different approaches. Each framework has saved me time in one context and created friction in another. This post is my attempt to distill what I wish I had known earlier: a pragmatic comparison and selection guide grounded in real-world patterns, not just feature lists.

Here’s what to expect: we’ll start with context about where serverless tooling fits today. Then we’ll walk through the main contenders, their capabilities, and practical examples you can run. After that, I’ll share tradeoffs, common pitfalls, and a personal experience section. Finally, we’ll cover getting started, standout features, free resources, and clear guidance on who should use what and who might skip it.

Context: Where serverless frameworks fit in modern cloud development

Serverless is no longer just a runtime; it’s an architectural pattern that spans functions, events, and managed services. In practice, teams use serverless to build HTTP APIs, asynchronous processors, cron jobs, stream consumers, and glue code that connects SaaS platforms. The main runtime environments are AWS Lambda, Google Cloud Functions, Azure Functions, and Vercel/Netlify for front-end-heavy apps. The underlying languages commonly include JavaScript/TypeScript, Python, Go, and Java.

When choosing a framework, the spectrum looks like this:

  • Purpose-built serverless frameworks (Serverless Framework, SST, AWS SAM, Nx + serverless plugins, CDK Lambda Patterns).
  • General-purpose infrastructure-as-code tools that support serverless well (Pulumi, Terraform, CloudFormation, CDK).
  • Native runtimes with CLI experiences (Vercel, Netlify, Firebase Functions, Google Cloud Functions framework).
  • Meta-frameworks that bundle UI and API layers (Next.js on Vercel, Nuxt on Netlify).

In real projects, teams blend these. For example, a product team might use SST for API + event wiring, Terraform for shared platform resources like VPC endpoints, and Vercel for a React front-end that talks to the serverless API. The goal isn’t to pick a “winner” but to match the framework to your team’s skills, deployment cadence, and operational constraints.

Frameworks overview: What they are and how they’re used

Serverless Framework (open-source)

The Serverless Framework (by Serverless, Inc.) was one of the first tools to make serverless development approachable. It provides a declarative serverless.yml for defining functions, events, and resources, with plugins for extending behavior. It supports multiple clouds (AWS, Azure, GCP, Google Cloud Functions, Kubeless), though AWS remains the strongest and most documented path.

Typical usage:

  • Define HTTP endpoints backed by Lambda functions.
  • Wire events like S3 uploads, SQS messages, or EventBridge rules.
  • Provision minimal infrastructure using CloudFormation under the hood.
  • Extend via plugins for local emulation, offline testing, linting, or custom resources.

Who uses it:

  • Startup teams moving from monoliths to serverless APIs.
  • Backend engineers who want a lightweight path to deploy functions quickly.
  • Teams that want multi-cloud experiments without deep IaC investment.

Compared to alternatives:

  • More focused on serverless than general IaC tools (less verbose than raw CloudFormation/Terraform).
  • Less “batteries included” than SST for TypeScript-first development.
  • More mature plugin ecosystem than native tooling for some clouds.

Real-world example:

  • A small API with HTTP endpoints, SQS background processing, and scheduled tasks. The serverless.yml describes functions, routes, and queue triggers. A plugin like serverless-offline enables local testing. Over time, teams often add custom CloudFormation resources (e.g., DynamoDB tables with specific GSIs) directly in the YAML.

SST (Serverless Stack)

SST is an open-source framework built for TypeScript-first development on AWS. It uses AWS CDK under the hood but abstracts common patterns with “Live Lambda Development,” enabling hot reloads and local debugging. It’s popular for teams that want a modern developer experience without managing CDK boilerplate.

Typical usage:

  • Building TypeScript APIs with sst dev for a local live environment.
  • Defining resources (DynamoDB tables, S3 buckets, queues) in code via CDK constructs.
  • Creating scheduled jobs, stream consumers, and EventBridge-driven workflows.
  • Deploying full-stack apps (React/Next.js + API) with shared stacks.

Who uses it:

  • TypeScript-heavy teams seeking a cohesive local dev experience.
  • Teams migrating from Express/Fastify to serverless without losing DX.
  • Projects that benefit from CDK’s power but want higher-level patterns.

Compared to alternatives:

  • More integrated DX than vanilla CDK or Serverless Framework for TypeScript projects.
  • More modern and opinionated than Terraform/CloudFormation for serverless-specific workflows.
  • Less multi-cloud than Serverless Framework (primarily AWS-focused).

Real-world example:

  • A product API where you define a stacks/api.ts with a DynamoDB table, an HTTP API, and event bus rules. SST’s Live Lambda Development allows frontend changes to hit local endpoints that execute in the cloud with hot reloads. This is especially useful when you need to iterate on authentication and data access without a heavy local setup.

AWS SAM (Serverless Application Model)

AWS SAM is an AWS-native framework that extends CloudFormation to simplify serverless resources. It’s well-supported, integrates tightly with AWS tooling (CodeArtifact, CodeBuild, IAM roles), and provides local emulation via sam local.

Typical usage:

  • Enterprises already invested in CloudFormation and AWS-native CI/CD.
  • Teams needing predictable deployments with AWS-first features (Step Functions, IAM policies, VPC configurations).
  • Projects that rely on sam local for local Lambda testing.

Who uses it:

  • Organizations with AWS platform teams enforcing stack consistency.
  • Teams requiring granular IAM and VPC integrations.
  • Developers who prefer native AWS tooling over third-party frameworks.

Compared to alternatives:

  • More AWS-native and stable than multi-cloud frameworks.
  • Less streamlined developer experience than SST for TypeScript projects.
  • More verbose than Serverless Framework for simple APIs, but stronger compliance/auditability.

Real-world example:

  • A regulated application using Step Functions orchestration and Lambda with VPC access. SAM templates define resources and IAM roles, and the CI/CD pipeline uses sam deploy with change sets. Local tests run with sam local invoke to verify event payloads.

Pulumi / Terraform / CDK

General-purpose IaC tools can provision serverless resources as part of broader infrastructure. They shine when serverless is one piece of a larger system (Kubernetes clusters, databases, networking, observability).

Typical usage:

  • Managing serverless resources alongside non-serverless services.
  • Enforcing organizational standards for IAM, tagging, and security.
  • Multi-cloud or hybrid deployments (Pulumi and Terraform).

Who uses it:

  • Platform engineering teams.
  • Organizations with strict compliance and shared platform stacks.
  • Projects that require fine-grained control over all resources.

Compared to alternatives:

  • More powerful for complex, multi-service architectures.
  • Steeper learning curve for simple serverless APIs.
  • Often slower iteration than serverless-first frameworks for small services.

Real-world example:

  • A platform team defines a shared network (VPC endpoints, private subnets) in Terraform. Then, they deploy serverless services using Pulumi or CDK, referencing the shared network outputs. This separation keeps platform governance clear while allowing product teams autonomy.

Vercel and Netlify (Frontend + API)

Vercel and Netlify provide managed platforms for frontend frameworks and serverless functions. They handle CI/CD, previews, and global edge networks, making them ideal for Jamstack sites and lightweight APIs.

Typical usage:

  • Next.js/Nuxt/SvelteKit apps with API routes.
  • Edge functions for low-latency requests.
  • Static sites with serverless backend logic.

Who uses it:

  • Frontend-focused teams.
  • Startups building product-market fit quickly.
  • Projects needing global CDN and instant previews.

Compared to alternatives:

  • Excellent DX for frontend developers, less control over backend infrastructure.
  • Not ideal for complex event-driven systems or strict VPC requirements.

Real-world example:

  • A marketing site with a Next.js front-end and API routes for lead capture. Vercel handles builds and previews, and serverless functions integrate with a CRM API. No infrastructure management required.

Nx + serverless plugins

Nx is a build system for monorepos. With Nx + Serverless or Nx + CDK plugins, teams can manage multiple serverless services in one repository, sharing code, libraries, and CI/CD pipelines.

Typical usage:

  • Monorepos with multiple Lambda services.
  • Shared TypeScript libraries and tooling.
  • Consistent testing, linting, and build pipelines.

Who uses it:

  • Teams with several serverless services under one product.
  • Enterprises consolidating multiple repos.

Compared to alternatives:

  • Strong organizational consistency, more setup overhead for simple projects.
  • Complements any serverless framework, not a replacement.

Real-world example:

  • A monorepo with apps/api (SST stack), apps/processor (Serverless Framework for SQS consumer), and libs/common (shared utilities). Nx run-many tasks deploy services in parallel with caching.

Technical deep dive: Practical patterns and code

Anatomy of a serverless API: The minimal viable structure

Regardless of framework, a serverless API typically contains:

  • Entrypoints (HTTP routes or event handlers).
  • Infrastructure definitions (functions, triggers, data stores).
  • Configuration for environment, secrets, and IAM.
  • Local development tooling for testing.

Below is a minimal project structure that applies to Serverless Framework and SST (TypeScript). It includes an HTTP API with authentication, a DynamoDB table, and an SQS background processor.

Line-based folder structure:

serverless-app/
├── services/
│   ├── api/
│   │   ├── src/
│   │   │   ├── handler.ts
│   │   │   ├── auth.ts
│   │   │   └── routes.ts
│   │   ├── serverless.yml         # for Serverless Framework
│   │   ├── package.json
│   │   └── tsconfig.json
│   └── processor/
│       ├── src/
│       │   └── index.ts
│       ├── serverless.yml
│       ├── package.json
│       └── tsconfig.json
├── stacks/                        # SST stacks (if using SST)
│   ├── api.ts
│   └── processor.ts
├── libs/
│   └── common/
│       ├── src/
│       │   └── utils.ts
│       ├── package.json
│       └── tsconfig.json
├── package.json
├── tsconfig.base.json
└── nx.json                        # optional Nx for monorepo

Serverless Framework example: HTTP API + SQS

We’ll define a REST API using HTTP API events, a DynamoDB table via CloudFormation resources, and an SQS queue for background processing. We’ll also add offline emulation.

services/api/serverless.yml

service: serverless-demo-api

frameworkVersion: '3'

provider:
  name: aws
  runtime: nodejs18.x
  region: us-east-1
  environment:
    TABLE_NAME: ${self:service}-table-${sls:stage}
    QUEUE_URL: ${self:service}-queue-${sls:stage}
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:Query
      Resource: !GetAtt Table.Arn
    - Effect: Allow
      Action:
        - sqs:SendMessage
      Resource: !GetAtt Queue.Arn

functions:
  create:
    handler: src/handler.create
    events:
      - httpApi:
          path: /items
          method: post
  get:
    handler: src/handler.get
    events:
      - httpApi:
          path: /items/{id}
          method: get

resources:
  Resources:
    Table:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:provider.environment.TABLE_NAME}
        AttributeDefinitions:
          - AttributeName: id
            AttributeType: S
        KeySchema:
          - AttributeName: id
            KeyType: HASH
        BillingMode: PAY_PER_REQUEST
    Queue:
      Type: AWS::SQS::Queue
      Properties:
        QueueName: ${self:service}-queue-${sls:stage}

plugins:
  - serverless-offline
  - serverless-esbuild

custom:
  esbuild:
    bundle: true
    minify: false

services/api/src/handler.ts

import { SQSClient, SendMessageCommand } from "@aws-sdk/client-sqs";
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand, GetCommand } from "@aws-sdk/lib-dynamodb";

const sqs = new SQSClient({});
const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));

export const create = async (event: any) => {
  const body = JSON.parse(event.body || "{}");
  const id = body.id || crypto.randomUUID();

  // Save to DynamoDB
  await ddb.send(
    new PutCommand({
      TableName: process.env.TABLE_NAME!,
      Item: { id, name: body.name, createdAt: Date.now() },
    })
  );

  // Enqueue background task
  await sqs.send(
    new SendMessageCommand({
      QueueUrl: process.env.QUEUE_URL!,
      MessageBody: JSON.stringify({ id }),
    })
  );

  return {
    statusCode: 201,
    body: JSON.stringify({ id }),
  };
};

export const get = async (event: any) => {
  const { id } = event.pathParameters || {};

  const result = await ddb.send(
    new GetCommand({
      TableName: process.env.TABLE_NAME!,
      Key: { id },
    })
  );

  if (!result.Item) {
    return { statusCode: 404, body: JSON.stringify({ error: "Not found" }) };
  }

  return {
    statusCode: 200,
    body: JSON.stringify(result.Item),
  };
};

services/api/src/routes.ts (optional helper for typed event parsing)

// Lightweight utility for parsing HTTP API payloads
export function parseBody(event: any) {
  try {
    return JSON.parse(event.body || "{}");
  } catch {
    return {};
  }
}

export function ok(data: any) {
  return { statusCode: 200, body: JSON.stringify(data) };
}

export function created(id: string) {
  return { statusCode: 201, body: JSON.stringify({ id }) };
}

export function notFound(message = "Not found") {
  return { statusCode: 404, body: JSON.stringify({ error: message }) };
}

services/api/serverless-offline usage:

  • Install serverless-offline and serverless-esbuild.
  • Run npx serverless offline to emulate HTTP routes locally. The SQS call will still hit AWS; for full local emulation, consider LocalStack or mock clients in tests.

SST example: TypeScript-first API with Live Lambda

SST’s sst dev spins up a local environment where Lambda functions are invoked in the cloud but can be hot-reloaded. This is especially powerful for fast feedback loops.

stacks/api.ts

import { StackContext, Api, Table, Queue, use } from "sst/constructs";

export function APIStack({ stack }: StackContext) {
  const table = new Table(stack, "Items", {
    fields: {
      id: "string",
    },
    primaryIndex: { key: "id" },
  });

  const queue = new Queue(stack, "Tasks");

  const api = new Api(stack, "Api", {
    defaults: {
      function: {
        bind: [table, queue],
      },
    },
    routes: {
      "POST /items": "services/api/src/handler.create",
      "GET /items/{id}": "services/api/src/handler.get",
    },
  });

  stack.addOutputs({
    ApiEndpoint: api.url,
    TableName: table.tableName,
    QueueUrl: queue.queueUrl,
  });
}

services/api/src/handler.ts (SST-compatible)

import { Table } from "sst/node/table";
import { Queue } from "sst/node/queue";
import { SQSClient, SendMessageCommand } from "@aws-sdk/client-sqs";
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand, GetCommand } from "@aws-sdk/lib-dynamodb";

const sqs = new SQSClient({});
const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));

export const create = async (event: any) => {
  const body = JSON.parse(event.body || "{}");
  const id = body.id || crypto.randomUUID();

  await ddb.send(
    new PutCommand({
      TableName: Table.Items.tableName,
      Item: { id, name: body.name, createdAt: Date.now() },
    })
  );

  await sqs.send(
    new SendMessageCommand({
      QueueUrl: Queue.Tasks.queueUrl,
      MessageBody: JSON.stringify({ id }),
    })
  );

  return { statusCode: 201, body: JSON.stringify({ id }) };
};

export const get = async (event: any) => {
  const { id } = event.pathParameters || {};
  const result = await ddb.send(
    new GetCommand({
      TableName: Table.Items.tableName,
      Key: { id },
    })
  );

  if (!result.Item) {
    return { statusCode: 404, body: JSON.stringify({ error: "Not found" }) };
  }

  return { statusCode: 200, body: JSON.stringify(result.Item) };
};

package.json scripts (mono-repo friendly)

{
  "name": "serverless-demo",
  "version": "1.0.0",
  "scripts": {
    "dev": "sst dev",
    "build": "tsc -b",
    "deploy": "sst deploy",
    "remove": "sst remove"
  },
  "devDependencies": {
    "sst": "^2.0.0",
    "aws-cdk-lib": "^2.0.0",
    "typescript": "^5.0.0"
  }
}

Fun language fact:

  • TypeScript’s type inference in SST constructs makes misconfigurations easier to catch at compile time. If you forget to bind a resource to a function, TypeScript will complain. This often saves deployment time and prevents subtle IAM issues.

Async patterns and error handling

Lambda functions often orchestrate I/O across services. Below are realistic patterns for retries, idempotency, and failure handling.

Idempotent create using DynamoDB condition expressions:

import { ConditionalCheckFailedException } from "@aws-sdk/client-dynamodb";

try {
  await ddb.send(
    new PutCommand({
      TableName: Table.Items.tableName,
      Item: { id, name: body.name, createdAt: Date.now() },
      ConditionExpression: "attribute_not_exists(id)",
    })
  );
} catch (e) {
  if (e instanceof ConditionalCheckFailedException) {
    return { statusCode: 409, body: JSON.stringify({ error: "Already exists" }) };
  }
  throw e;
}

SQS consumer with partial failure handling:

// services/processor/src/index.ts
import { SQSEvent } from "aws-lambda";
import { DynamoDBDocumentClient, UpdateCommand } from "@aws-sdk/lib-dynamodb";
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";

const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({}));

export const handler = async (event: SQSEvent) => {
  const failures: string[] = [];

  for (const record of event.Records) {
    try {
      const payload = JSON.parse(record.body);
      const id = payload.id;

      // Example: update status to processed
      await ddb.send(
        new UpdateCommand({
          TableName: process.env.TABLE_NAME!,
          Key: { id },
          UpdateExpression: "SET #status = :status, processedAt = :ts",
          ExpressionAttributeNames: { "#status": "status" },
          ExpressionAttributeValues: {
            ":status": "processed",
            ":ts": Date.now(),
          },
        })
      );
    } catch (err) {
      // Collect failures; let SQS retry via DLQ configured in serverless.yml
      failures.push(record.messageId);
    }
  }

  // If partial failures are acceptable, return normally and rely on DLQ for poison pills
  if (failures.length > 0) {
    console.warn("Failed messages:", failures);
  }

  return { batchItemFailures: [] }; // for SQS partial response support
};

Here’s the corresponding SQS consumer definition in services/processor/serverless.yml:

service: serverless-demo-processor

provider:
  name: aws
  runtime: nodejs18.x
  region: us-east-1
  environment:
    TABLE_NAME: serverless-demo-api-${sls:stage}-table

functions:
  process:
    handler: src/index.handler
    events:
      - sqs:
          arn: !GetAtt Queue.Arn
          batchSize: 10
          maximumBatchingWindow: 5
    deadLetterQueue:
      arn: !GetAtt DLQ.Arn

resources:
  Resources:
    DLQ:
      Type: AWS::SQS::Queue
      Properties:
        QueueName: ${self:service}-dlq-${sls:stage}

Observability and local testing

Observability matters in serverless because cold starts and distributed traces are hard to reproduce. Consider:

  • Structured logging (JSON) to CloudWatch or external sinks like Datadog.
  • AWS X-Ray for tracing (supported by Lambda layers and SDKs).
  • Metrics dashboards for concurrency and throttling.

Local testing:

  • Serverless Framework: serverless-offline for HTTP emulation, serverless-esbuild for fast builds.
  • SST: sst dev for Live Lambda, sst console for data browsing.
  • AWS SAM: sam local invoke and sam local start-api.

A typical test strategy:

  • Unit tests for handlers with mocked AWS SDK clients.
  • Integration tests against real AWS resources in a dev account (or LocalStack).
  • Contract tests for event payloads (e.g., EventBridge schemas).

Honest evaluation: Strengths, weaknesses, and tradeoffs

Serverless Framework

Strengths:

  • Multi-cloud support and mature plugin ecosystem.
  • Declarative YAML, quick to get started.
  • Good for teams that want simple definitions without heavy IaC.

Weaknesses:

  • Local emulation can be finicky for event-driven flows.
  • Plugin quality varies; complex stacks may need custom CloudFormation.
  • TypeScript-first DX not as polished as SST.

Choose when:

  • You need multi-cloud flexibility or a simple API with background tasks.
  • Your team prefers declarative configuration and minimal abstraction.

Skip when:

  • You want robust local debugging for every resource type.
  • Your project is heavily TypeScript and you value live reloads.

SST

Strengths:

  • Excellent TypeScript DX and Live Lambda Development.
  • CDK under the hood gives power without boilerplate.
  • Strong for full-stack apps and modern patterns.

Weaknesses:

  • AWS-focused; not ideal for multi-cloud.
  • Requires comfort with Node.js/TypeScript tooling.
  • Some teams may prefer pure IaC for auditability.

Choose when:

  • You want fast iteration with TypeScript and AWS.
  • Your team is comfortable with CDK constructs and event-driven designs.

Skip when:

  • Multi-cloud is a requirement.
  • You need heavy compliance with non-AWS toolchains.

AWS SAM

Strengths:

  • AWS-native, stable, and well-documented.
  • Good for regulated environments with strict governance.
  • Integrates tightly with AWS services like Step Functions and Code*.

Weaknesses:

  • Verbosity compared to higher-level frameworks.
  • Less developer-friendly for TypeScript-first APIs.
  • Local emulation has limitations for complex integrations.

Choose when:

  • You rely on AWS-specific services and need IaC consistency.
  • You want a vendor-supported framework with predictable releases.

Skip when:

  • You need rich local dev experiences for all event types.
  • Your team prefers rapid iteration and less YAML.

Pulumi / Terraform / CDK

Strengths:

  • Broad coverage for infrastructure beyond serverless.
  • Strong governance, policy, and multi-cloud (Pulumi/Terraform).
  • Great for platform teams.

Weaknesses:

  • Steeper learning curve and slower iteration for simple APIs.
  • May feel overkill for a single Lambda service.

Choose when:

  • Serverless is part of a larger platform strategy.
  • You need strict control over IAM, networking, and shared resources.

Skip when:

  • You’re building a small, standalone service with minimal infrastructure needs.

Vercel / Netlify

Strengths:

  • Superior DX for frontend developers.
  • Previews, edge functions, global CDN.
  • Minimal ops overhead.

Weaknesses:

  • Limited for complex backend architectures and VPC requirements.
  • Less control over infrastructure and event-driven integrations.

Choose when:

  • You’re building Jamstack apps with lightweight APIs.
  • You want fast iteration and managed CI/CD.

Skip when:

  • You need deep AWS integrations, VPCs, or heavy background processing.

Personal experience: Learning curves and common mistakes

I’ve learned that developer experience is the most underrated factor in serverless success. A team will tolerate some YAML friction if deployments are reliable and debugging is straightforward. Conversely, a fancy local emulator is worthless if it doesn’t accurately reflect IAM and resource configurations.

Common mistakes I’ve made or witnessed:

  • Over-relying on local emulation. serverless-offline is great for HTTP routes, but you can’t fully emulate SQS triggers or IAM policies. I’ve shipped code that worked locally but failed due to missing permissions. Now I run integration tests against a dev account, even if they’re minimal.
  • Uncontrolled resource sprawl. Early projects created many DynamoDB tables and queues per service. Over time, it became costly and hard to reason about. I now prefer shared tables with namespaced keys or careful GSIs, especially when using monorepos with Nx.
  • Poor cold start handling. I’ve shipped functions that imported heavy libraries at the top level, causing cold starts to spike. I learned to defer imports and split code paths. For Node.js, dynamic imports and on-demand loading made a difference. You can’t always measure it locally, so observability is key.
  • Neglecting DLQs. Without dead-letter queues, poison messages silently block processing. Setting DLQs early has saved me hours of debugging.
  • Ignoring idempotency. Retries happen. I’ve seen duplicate records until we added conditional writes and deduplication keys. It’s a small price to pay for reliability.

Moments when serverless frameworks proved valuable:

  • During a hackathon, SST’s Live Lambda saved hours. We could test API changes against real AWS resources without a local stack. It felt like “cloud hot reload.”
  • When building a multi-cloud demo, Serverless Framework’s serverless.yml allowed us to deploy to both AWS and Azure with minimal code changes. It wasn’t perfect, but it validated our approach quickly.
  • When a regulated customer required Step Functions and IAM boundaries, AWS SAM provided clarity and auditability. The deployment pipeline was predictable, and sam validate caught template errors early.

Getting started: Setup, tooling, and workflow mental models

Regardless of framework, the mental model is similar:

  • Define your functions and events (HTTP routes, queues, schedules).
  • Define your data and infrastructure (tables, buckets, topics).
  • Configure IAM and environment variables.
  • Deploy with a single command, then iterate.

Tooling choices

For Serverless Framework:

  • Install: npm i -g serverless or per-project npx serverless.
  • Plugins: serverless-offline, serverless-esbuild, serverless-prune-plugin.
  • Workflow: serverless offline for local dev, serverless deploy for deployment.

For SST:

  • Install: npm create sst or add sst to an existing project.
  • Workflow: sst dev for local live development, sst deploy for production, sst remove to clean up.
  • Console: sst console to inspect resources and data.

For AWS SAM:

  • Install: AWS CLI + SAM CLI.
  • Workflow: sam build and sam deploy. Use sam local invoke and sam local start-api for local testing.
  • Policy: Use sam validate and CloudFormation lint tools (cfn-lint) to catch errors.

For monorepos with Nx:

  • Initialize Nx: npx nx@latest init.
  • Add serverless plugins: nx g @nx/serverless:api or nx g @nx/aws-lambda.
  • Workflow: nx run-many --target=deploy --projects=api,processor to deploy multiple services in parallel.

Sample project setup (SST + monorepo structure)

Initialize and add services:

npx create-sst@latest serverless-demo
cd serverless-demo
npm install -D nx
npx nx init

Add an API stack and processor stack under stacks/, then run:

npx sst dev

For deployment:

npx sst deploy --stage prod

For CI/CD:

  • Use GitHub Actions with aws/configure-credentials.
  • Run sst deploy in pipeline, cache build artifacts for faster runs.
  • Optionally gate deployments with integration tests.

What makes these frameworks stand out

Developer experience

  • SST: Live Lambda is a standout. It shortens the feedback loop by allowing you to hit local endpoints and execute cloud functions in real time.
  • Serverless Framework: Rich plugin ecosystem; it’s easy to add offline emulation, linting, and custom CloudFormation resources.
  • AWS SAM: Stability and alignment with AWS services; strong for teams needing predictable deployments.
  • Vercel/Netlify: Best-in-class for frontend devs; instant previews and edge functions remove ops burden.

Ecosystem strengths

  • CDK (via SST or standalone): Reusable constructs and patterns; good for building internal platforms.
  • Terraform/Pulumi: Governance and multi-cloud; ideal for platform teams.
  • Nx: Monorepo consistency; shared tooling and caching accelerate teams with multiple services.

Maintainability

  • TypeScript-first stacks (SST, CDK) reduce runtime errors and make refactoring safer.
  • Declarative YAML (Serverless Framework, SAM) is easier for smaller teams but can become unwieldy without strict organization.
  • Observability integrations (X-Ray, structured logging) are critical; choose frameworks that make these easy to adopt.

Real outcomes

  • Faster iteration: SST’s live reload shortens cycles for product teams.
  • Operational reliability: SAM’s IaC-first approach reduces drift and improves governance.
  • Cost control: Serverless Framework’s pruning plugins and disciplined resource definition prevent idle resources.

Free learning resources

Summary: Who should use what and who might skip it

Choose Serverless Framework if:

  • You need multi-cloud flexibility or a straightforward YAML-based setup.
  • Your project is a simple API + event processing stack with a small team.
  • You value a mature plugin ecosystem over a tightly integrated TypeScript DX.

Choose SST if:

  • You’re building TypeScript-heavy apps on AWS and want fast iteration.
  • Live Lambda Development and CDK constructs appeal to your team.
  • You’re comfortable with Node.js tooling and modern cloud patterns.

Choose AWS SAM if:

  • You’re in an AWS-heavy organization with compliance and governance needs.
  • You need tight integration with Step Functions, IAM, and VPC.
  • Predictable deployments and native tooling are priorities.

Choose Pulumi/Terraform/CDK if:

  • Serverless is part of a larger platform with diverse infrastructure.
  • Your team is platform-focused and values policy, governance, and multi-cloud.

Choose Vercel/Netlify if:

  • You’re a frontend team building Jamstack apps with lightweight APIs.
  • You want managed CI/CD, previews, and global CDNs without ops overhead.
  • Complex backend architectures and VPCs are not in scope.

If you’re unsure, start small:

  • For a new API, try SST if you’re TypeScript-native.
  • For an AWS-centric team needing governance, start with SAM.
  • For multi-cloud experiments or quick prototypes, use Serverless Framework.
  • For full-stack apps, Vercel/Netlify can be the fastest path to production.

The real-world lesson is this: pick the tool that reduces cognitive load for your team while preserving the right level of control. Frameworks should amplify your workflow, not dictate it. Start simple, add observability early, and adjust as your architecture evolves.

Related Articles