mgarden

Serverless Framework vs Terraform

4 min read

serverless aws iac claude-curated

Two of the most common ways to deploy serverless workloads on AWS. They optimise for different things: Serverless Framework is opinionated about AWS Lambda + API Gateway + their satellites; Terraform is a general-purpose infrastructure-as-code (IaC) tool that doesn’t know or care what you’re deploying.

Serverless Framework

A Node-based CLI. The unit of deployment is a serverless.yml describing functions, events that trigger them, IAM permissions, and supporting resources. Under the hood it generates a CloudFormation stack.

service: my-api
provider:
  name: aws
  runtime: nodejs20.x
functions:
  hello:
    handler: src/hello.handler
    events:
      - httpApi:
          path: /hello
          method: get

Strengths:

  • Fast time-to-first-Lambda — a typical “Lambda + API Gateway + DynamoDB” stack is a dozen lines of YAML.
  • Packaging built in — bundles Node modules, prunes dev dependencies, handles layers.
  • Plugin ecosystem — serverless-offline (local invocation), serverless-esbuild (bundling), serverless-iam-roles-per-function, etc.
  • Per-function IAM with a plugin (default is one shared role).

Weaknesses:

  • Node dependency — even for a Python Lambda, you need Node and npm in CI.
  • CloudFormation under the hood — slow deploys at high resource counts, hard 500-resource per-stack limit (per region), opaque diffs.
  • YAML at scale — serverless.yml becomes unwieldy past ~30 functions; splitting requires the compose plugin or multiple services.
  • Licensing — the v4 release moved to a paid licence above a revenue threshold; the open Foundation fork exists.

Terraform

HCL-based, provider-agnostic IaC. Manages an explicit state file that maps declarations to real resources, and shows a plan diff before applying.

resource "aws_lambda_function" "hello" {
  function_name = "hello"
  runtime       = "nodejs20.x"
  handler       = "src/hello.handler"
  filename      = data.archive_file.hello.output_path
  role          = aws_iam_role.lambda.arn
}

Strengths:

  • One tool for everything — Lambda, VPC, RDS, GitHub repos, Datadog monitors, Cloudflare DNS, all in the same workflow.
  • Module ecosystem — community modules cover most of AWS at a higher abstraction.
  • Mature state model — workspaces, remote state, locking, drift detection, import / moved blocks.
  • No Node dependency — single static binary.

Weaknesses:

  • No app deployment opinions — packaging Lambda zips, S3 uploads, and triggering deploys is your problem (or terraform-aws-lambda module’s).
  • Slower iteration on app code — every code change needs a re-zip and re-apply; Serverless Framework optimises for this loop.
  • Verbose for serverless-only stacks — IAM, log groups, integrations all spelled out.
  • Licensing — HashiCorp moved to BSL; OpenTofu is the open fork now in the Linux Foundation.

When teams pick which

Teams reach for Serverless Framework (or AWS SAM / CDK) when:

  • The system is mostly Lambda + API Gateway + DynamoDB.
  • The team is small and wants to ship without learning Terraform.
  • Hot reload and local invocation matter for dev velocity.
  • Plugins solve problems they don’t want to write themselves.

Teams reach for Terraform when:

  • They have non-AWS infra to manage (DNS, SaaS, monitoring) — one tool wins.
  • The platform team owns infra and product teams consume modules.
  • The estate is broader than serverless — VPC, RDS, EKS, etc.
  • They want predictable, plan-driven changes across all infrastructure.

Hybrid approach

A common pattern in mature orgs:

  • Terraform owns shared/foundational infrastructure: VPCs, accounts, IAM baseline, RDS, KMS, Route 53, observability.
  • Serverless Framework / SAM / CDK owns application stacks: the Lambdas, API Gateways, queues, and event rules that change with the application.

The boundary is roughly “infra that lives longer than any one application” vs “infra that ships with the app”. The two layers reference each other through SSM Parameter Store, CloudFormation exports, or Terraform remote state outputs.

AWS SAM — the third option

AWS SAM (Serverless Application Model) is an AWS-native CloudFormation extension. Same CFN under the hood as Serverless Framework, but defined by AWS, packaged with the AWS CLI tooling, no third-party dependency.

  • Pros: official, free, integrates cleanly with sam local invoke, sam build, CFN-native.
  • Cons: smaller plugin ecosystem than Serverless Framework, more verbose than serverless.yml for the same setup, still CloudFormation underneath.

A reasonable choice for AWS-only shops that want to avoid third-party tools.

See also

References

Graph View

Backlinks