AWS SAM Setup and Serverless Backend Deployment

Why AWS SAM, Not Serverless Framework?

We migrated five projects from Serverless Framework to AWS SAM and saw benefits every time: fewer workarounds, transparent CloudFormation stack, native integration with CDK. SAM is not just another abstraction layer — it's the official AWS tool, fully compatible with CloudFormation: the output is a full stack that can be versioned and rolled back. Instead of 50 lines of CloudFormation for Lambda + API Gateway + IAM Role, you write 10 lines of SAM. This reduces backend development time by 40% and lowers the risk of configuration errors. A typical SAM project costs 30–50% less than the Serverless Framework equivalent, thanks to less code and no plugins.

Our AWS-certified engineers have 5 years of experience in serverless architectures and have delivered over 30 SAM projects. We guarantee compatibility with your stack and cost optimization — for example, using Graviton2 saves up to 20% on Lambda, and infrastructure costs drop by 40% when migrating from EC2 to Lambda. As AWS states: "SAM is the easiest way to build serverless applications".

Comparison: SAM vs. Serverless Framework

How to Set Up CI/CD for SAM?

Continuous integration and delivery are mandatory in any production architecture. SAM integrates seamlessly with popular pipelines: GitHub Actions, GitLab CI, AWS CodePipeline. A typical scenario: on push to the main branch, it runs sam build and deploys to the prod environment with automatic approval of Change Sets.

# .github/workflows/deploy.yml (fragment)
- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/GitHubActions
    aws-region: eu-west-1
- name: SAM build and deploy
  run: |
    sam build
    sam deploy --no-confirm-changeset --no-fail-on-empty-changeset

For multi-environment configuration, use samconfig.toml with different profiles. Rollback is done via the standard CloudFormation rollback-stack command — zero downtime.

What Is Included in SAM Backend Setup?

Our work covers the full cycle: from auditing your current architecture to delivering documentation.

• Architecture document: service diagram, Lambda runtime selection, memory and timeout calculations.
• template.yaml: all resources (Lambda, API Gateway, DynamoDB, SQS, S3) with policies and environment variables.
• Lambda source code: handlers in TypeScript/Node.js 20, JWT authorizer, middlewares, tests.
• Configuration of environments: dev/staging/prod with different stages, SSM parameters for secrets.
• CI/CD pipeline: ready-to-use workflow for GitHub Actions or GitLab CI.
• Documentation and training: README with example calls, variable descriptions, developer instructions.
• Guarantee: one week of post-deployment support to fix any incidents.

Quick Start: Installation and Structure

brew tap aws/tap
brew install aws-sam-cli
# or: pip install aws-sam-cli
sam --version  # SAM CLI, version 1.x
sam init --runtime nodejs20.x --dependency-manager npm --app-template hello-world --name my-backend

Project structure:

• template.yaml — SAM template
• samconfig.toml — deployment config
• src/handlers/ — handlers (api.ts, auth.ts, worker.ts)
• src/shared/ — shared code (db.ts, response.ts)
• events/ — test events
• __tests__/ — tests

Template and Handler Configuration

Key elements of template.yaml:

AWSTemplateFormatVersion: '2010-09-31'
Transform: AWS::Serverless-2016-10-31
Description: My Web Backend

Globals:
  Function:
    Runtime: nodejs20.x
    Architectures: [arm64]
    MemorySize: 512
    Timeout: 10
  Api:
    Cors:
      AllowMethods: "'*'"

Resources:
  ApiGateway:
    Type: AWS::Serverless::HttpApi
    Properties:
      StageName: !Ref Stage
      Auth:
        DefaultAuthorizer: LambdaAuthorizer
        Authorizers:
          LambdaAuthorizer:
            FunctionArn: !GetAtt AuthFunction.Arn

  ApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/handlers/api.handler
      Events:
        AnyRoute:
          Type: HttpApi
          Properties:
            ApiId: !Ref ApiGateway
            Method: ANY
            Path: /api/{proxy+}
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref MainTable
    Metadata:
      BuildMethod: esbuild
      BuildProperties:
        Minify: true
        Target: es2022

Example Lambda Authorizer:

import { verify } from 'jsonwebtoken';

export const handler = async (event) => {
  const token = event.headers?.authorization?.replace('Bearer ', '');
  if (!token) return { isAuthorized: false };
  try {
    const payload = verify(token, process.env.JWT_SECRET!);
    return { isAuthorized: true, context: { userId: String(payload.sub) } };
  } catch {
    return { isAuthorized: false };
  }
};

How to Optimize SAM Costs?

• Use Graviton2 (arm64) — save up to 20% on Lambda.
• Set Provisioned Concurrency only for critical functions.
• Configure CloudWatch Lambda Insights to monitor and identify inefficient requests.
• Move static assets to S3 + CloudFront, don't overload API Gateway.
• Optimize deployment package size: esbuild minification, tree-shaking.

Local Development and CI/CD

For local execution, we use sam local start-api with a mocked DynamoDB via Docker. Environment configuration is set in samconfig.toml:

[default.deploy.parameters]
stack_name = "my-backend-dev"
s3_bucket = "artifacts-bucket"
region = "eu-west-1"
parameter_overrides = "Stage=dev"

Deployment is done with:

sam build && sam deploy --config-env dev
# or for prod
sam build && sam deploy --config-env prod

The process includes building (esbuild minification), generating Change Set, and applying. Rollback uses the standard CloudFormation rollback-stack command.

Process and Timelines

A basic SAM backend with one Lambda and DynamoDB — 1–2 days. A full architecture with an authorizer, background workers, and multiple environments — 4–5 days. Adapting existing Express/Fastify code — 3–5 days.

Contact us to evaluate your project — our engineers will analyze your current architecture and prepare a commercial proposal. Order turnkey AWS SAM setup — we'll handle all the infrastructure, from templates to CI/CD.

Why Serverless Development? The Real Economics and Technical Trade-offs

Serverless does not mean "without servers". Servers exist—you just don't manage them. It's more accurate to think of it as "without server management": no OS patching, no nginx configuration, no disk space monitoring. The function receives an event, processes it, and returns a response. The provider decides where to run it. Мы занимаемся serverless-архитектурой более 5 лет и реализовали 30+ проектов на AWS Lambda, Vercel Functions и Cloudflare Workers. Гарантируем, что ваша система масштабируется без переплат — при условии правильного выбора платформы и оптимизации холодного старта.

Cold start — Lambda's main pain point on Node.js. In VPC, cold start reached 10 seconds before recent improvements. For production functions with latency requirements: Provisioned Concurrency (keeps instances warm), SnapStart for Java, minimize bundle via tree-shaking. Our typical optimization reduces cold start from 3.2s to 400ms.

Practical case: an image processing function (resize, WebP conversion, upload to S3). Bundle with sharp was 40MB due to native binaries. Solution: Lambda Layer with sharp, main function 800KB. Cold start dropped from 3.2s to 400ms. Lambda Layers — shared dependencies between functions. Up to 5 layers per function, each up to 250MB. Standard practice: layer with heavy dependencies (sharp, puppeteer, ffmpeg), layer with common business logic. Infrastructure for Lambda via AWS CDK or Terraform. SAM — for beginners, CDK — for serious projects with type safety.

Edge Runtime is fundamentally different: the function runs on a V8 isolate in the nearest Vercel CDN point (120+ regions). No cold start as such — the isolate starts in ~0ms. But strict limitations: no Node.js API (fs, crypto via Web API), no database access via TCP (only via HTTP API), bundle size up to 4MB. Edge Runtime is ideal for: middleware (auth check, redirect, A/B test), response transformations, geolocation logic, Edge Config. Not suitable for: accessing PostgreSQL, heavy computations, file system operations.

Cloudflare Workers run on V8 isolates in 300+ points of presence. Latency for the user is literally the nearest data center. Cold start < 1ms. Workers Durable Objects solve the state problem at the edge: each Durable Object is a single coordination point, running in one region. Ideal for: game rooms, real-time documents, rate limiting without races. Workers KV — eventually consistent storage. Writes propagate to all regions in ~60 seconds. Not suitable for financial transactions, suitable for configs, feature flags, cache. D1 — SQLite on the edge. Works great on a single read replica, write latency depends on distance to primary region. Not ideal for global write-heavy applications.

Ecosystem: Hono.js — a minimalist router that works on Workers, Deno, Bun, Node.js. Good choice if you need unified code for edge and server.

Vendor lock-in — a real problem. Lambda-specific code (handler signature, Lambda context) is hard to port. Hono.js, Remix, or adapters like @hono/node-server help keep logic portable. Мы проектируем абстракции, позволяющие сменить провайдера с минимальными изменениями.

How We Optimize Cold Start in AWS Lambda?

Cold start is Lambda's worst enemy. Here’s a step‑by‑step optimisation checklist we apply:

1. Minimise bundle size — tree‑shake dependencies, use Lambda Layers for native binaries (sharp, puppeteer). Target < 1MB.
2. Enable Provisioned Concurrency for latency‑critical functions — costs extra but cuts cold start to near zero.
3. Use SnapStart for Java (Lambda) — reduces init time by 90%+.
4. Avoid VPC unless necessary — if you need VPC, use AWS PrivateLink or Elastic Network Interface optimisation.
5. Warm‑up strategies — scheduler pinging function every 5 minutes (but only for low‑volume functions, otherwise Provisioned Concurrency cheaper).

Result: our clients typically see cold start drop from 2–4s to under 500ms. For a fintech API handling 50k requests/day, that means 3 fewer seconds of latency per request during peak scale.

When Does Serverless Not Fit? Cost Comparison

Serverless saves money when traffic is unpredictable or sparse — up to 70% reduction compared to dedicated servers. But it becomes expensive under constant high load. Example: a function processing 1 million requests/day at 300ms each costs about $100–200/month on Lambda. Equivalent EC2 instance might cost $50/month. For such steady workloads, Fargate or EC2 is cheaper.

Long computations (>15 min on Lambda, >30s on Vercel) require Fargate or a regular server. WebSocket server with state — no persistent process. Tasks with frequent disk access — ephemeral storage, /tmp on Lambda 512MB–10GB.

What’s Included in Serverless Development Service?

Мы предлагаем serverless-разработку под ключ. В каждый проект входит:

• Архитектурная документация (схема event‑driven потоков, выбор платформы, justification).
• Реализация функций с unit‑ и integration‑тестами.
• CI/CD pipeline (GitHub Actions / GitLab CI) с preview‑деплоями.
• Infrastructure as Code (Terraform / AWS CDK / Pulumi).
• Мониторинг и observability (OpenTelemetry, structured logging, distributed tracing).
• 30‑дневная пост‑релизная поддержка и оптимизация производительности.

Typical Mistakes in Serverless Development and How We Avoid Them

• Ignoring cold start — we measure and budget for it from day one.
• Over‑engineering state — many teams try to use Workers Durable Objects for simple caching; KV is often enough.
• No distributed tracing — without trace IDs across SQS › Lambda › DynamoDB streams, debugging is blind. We integrate AWS X‑Ray or OpenTelemetry automatically.
• Underestimating cost at scale — we simulate load patterns and compare serverless vs. container costs before committing.

Закажите serverless архитектуру под ключ — свяжитесь с нами для бесплатной оценки вашего проекта. Сроки: от 2 недель для MVP, до 10 недель для миграции монолита. Стоимость рассчитывается индивидуально, ориентировочно от $2,000 до $15,000 в зависимости от сложности.