Building Microservices on AWS: Lambda vs ECS Fargate

Selecting the right compute model is one of the biggest architectural decisions teams face on AWS. This guide contrasts serverless functions powered by AWS Lambda with containerized services running on Amazon ECS with Fargate. You’ll find side-by-side diagrams, architecture variants (including API Gateway front doors), and a comprehensive comparison of cost, performance, security, scaling, and operational trade-offs to help you decide which approach fits your next workload.

Quick summary

• Lambda: best when you want operational simplicity, per-request scaling, and pay-per-use billing. Ideal for event-driven and bursty workloads with small to medium execution times.
• ECS Fargate: best when you need long-running processes, complex containerized applications, predictable performance, or more control over the runtime and networking. Good for services requiring larger memory/CPU, lower latency for warm workloads, or specialized dependencies.

Contract (what this guide covers)

• Inputs: HTTP requests arriving at API Gateway / ALB. Data store is typically DynamoDB or RDS.
• Outputs: HTTP responses to clients and operational artefacts (metrics, logs, traces).
• Error modes: cold starts (Lambda), task restarts or scaling delays (Fargate), partial failures, timeouts, and throttling.

Diagrams

Lambda-based microservice

%%{init: {'securityLevel': 'loose', 'flowchart': {'htmlLabels': true}}}%%
graph TD
    subgraph "Client"
        U[<i class="fa fa-user"></i> User]
    end

    subgraph "AWS Cloud"
        R53[<i class="fa fa-road"></i><br/>Route 53]
        ACM[<i class="fa fa-shield-alt"></i><br/>ACM Certificate]
        APIGW[<i class="fa fa-door-open"></i><br/>API Gateway]
        Authorizer[<i class="fa fa-lock"></i><br/>Lambda Authorizer]
        Lambda[<i class="fa fa-microchip"></i><br/>AWS Lambda]
        IAM[<i class="fa fa-key"></i><br/>IAM Role & Policy]
        DB[<i class="fa fa-database"></i><br/>SQL/NoSQL Database]
    end

    subgraph "Observability"
        CW[<i class="fa fa-chart-line"></i><br/>CloudWatch Logs]
        XRay[<i class="fa fa-search-location"></i><br/>AWS X-Ray]
    end


    U -- "Step 1: HTTPS Request<br/>api.yourdomain.com" --> R53
    R53 -- "Step 2: Resolves to" --> APIGW
    APIGW -. "Step 3: Invoke authorizer" .-> Authorizer
    Authorizer -. "Step 4: Allow / Deny policy" .-> APIGW
    APIGW -- "Step 5: Triggers" --> Lambda
    Lambda -- "Step 6: Performs CRUD" --> DB
    DB -- "Step 7: Returns data" --> Lambda
    Lambda -- "Step 8: Returns response" --> APIGW
    APIGW -- "Step 9: Sends HTTP Response" --> U
    APIGW -. "Uses for SSL/TLS" .-> ACM
    Lambda -. "Executes with" .-> IAM
    Lambda -. "Writes logs to" .-> CW
    Lambda -. "Sends traces to" .-> XRay

    classDef aws fill:#FF9900,stroke:#333,stroke-width:2px;
    class R53,APIGW,Authorizer,Lambda,DB,ACM,IAM,CW,XRay aws;

ECS Fargate-based microservice

%%{init: {'securityLevel': 'loose', 'flowchart': {'htmlLabels': true}}}%%
graph TD
    subgraph "Client"
        U[<i class="fa fa-user"></i><br/>User]
    end

    subgraph "AWS Cloud"
        R53[<i class="fa fa-road"></i><br/>Route 53]
        ACM[<i class="fa fa-shield-alt"></i><br/>ACM Certificate]
        ALB[<i class="fa fa-project-diagram"></i><br/>Application Load Balancer]
        subgraph "ECS Service (Fargate)"
          direction LR
          IAM[<i class="fa fa-key"></i><br/>IAM Role & Policy]
          TaskA[<i class="fa fa-box-open"></i><br/>Tasks 1:n]
          AuthLib[<i class="fa fa-lock"></i><br/>Auth Library Task]
        end
        RDS[<i class="fa fa-database"></i><br/>SQL/NoSQL Database]
    end

    subgraph "Observability"
        Logs[<i class="fa fa-chart-line"></i><br/>CloudWatch Logs]
        Traces[<i class="fa fa-search-location"></i><br/>AWS X-Ray]
    end

    U -- "Step 1: HTTPS Request<br/>service.yourdomain.com" --> R53
    R53 -- "Step 2: Resolves to" --> ALB
    ALB -- "Step 3: Routes traffic" --> TaskA

    TaskA -- "Step 4: Call auth library" --> AuthLib
    AuthLib -- "Step 5: Allow / Deny" --> TaskA
    TaskA -- "Step 6: Read / Write" --> RDS
    RDS -- "Step 7: Returns data" --> TaskA

    TaskA -- "Step 8: JSON response" --> ALB

    TaskA -. "Telemetry" .-> Logs
    TaskA -. "Traces" .-> Traces
    TaskA -. "Task role permissions" .-> IAM
    AuthLib -. "Policy logs" .-> Logs

    ALB -- "Step 9: Sends HTTP response" --> U
    ALB -. "Uses TLS cert" .-> ACM

    classDef aws fill:#FF9900,stroke:#333,stroke-width:2px;
    class R53,ACM,ALB,IAM,TaskA,AuthLib,RDS,Logs,Traces aws;

ECS Fargate-based microservice with API Gateway front door

%%{init: {'securityLevel': 'loose', 'flowchart': {'htmlLabels': true}}}%%
graph TD
    subgraph "Client"
        U2[<i class="fa fa-user"></i><br/>User]
    end

    subgraph "AWS Edge"
        R532[<i class="fa fa-road"></i><br/>Route 53]
        APIGW2[<i class="fa fa-door-open"></i><br/>API Gateway]
        ACMEdge[<i class="fa fa-shield-alt"></i><br/>ACM - API Gateway]
        Authorizer2[<i class="fa fa-lock"></i><br/>Lambda Authorizer]
        VPCLink[<i class="fa fa-exchange-alt"></i><br/>VPC Link]
    end

    subgraph "Amazon VPC"
        ACM2[<i class="fa fa-shield-alt"></i><br/>ACM Certificate]
        ALB2[<i class="fa fa-project-diagram"></i><br/>Private ALB]
        IAM2[<i class="fa fa-key"></i><br/>IAM Role & Policy]
        subgraph "ECS Service (Fargate)"
            Tasks[<i class="fa fa-box-open"></i><br/>Tasks 1:n]
        end
        RDS2[<i class="fa fa-database"></i><br/>Amazon RDS]
    end

    subgraph "Observability"
        Logs2[<i class="fa fa-chart-line"></i><br/>CloudWatch Logs]
        XRay2[<i class="fa fa-search-location"></i><br/>AWS X-Ray]
    end

    U2 -- "Step 1: HTTPS Request<br/>api.yourdomain.com" --> R532
    R532 -- "Step 2: Resolves to" --> APIGW2
    APIGW2 -. "Step 3: Invoke authorizer" .-> Authorizer2
    Authorizer2 -. "Step 4: Allow / Deny policy" .-> APIGW2
    APIGW2 -. "TLS cert" .-> ACMEdge
    APIGW2 -- "Step 5: Private integration" --> VPCLink
    VPCLink -- "Step 6: Forward to VPC" --> ALB2
    ALB2 -- "Step 7: Route to tasks" --> Tasks
    Tasks -- "Step 8: Read / Write" --> RDS2
    RDS2 -- "Step 9: Result set" --> Tasks
    Tasks -- "Step 10: JSON response" --> ALB2
    ALB2 -- "Step 11: Sends response" --> APIGW2
    APIGW2 -- "Step 12: Sends HTTP Response" --> U2

    Tasks -. "Telemetry" .-> Logs2
    Tasks -. "Traces" .-> XRay2
    Tasks -. "Task role permissions" .-> IAM2
    ALB2 -. "Uses TLS cert" .-> ACM2

    classDef aws fill:#FF9900,stroke:#333,stroke-width:2px;
    class R532,APIGW2,ACMEdge,Authorizer2,VPCLink,ACM2,ALB2,Tasks,RDS2,IAM2,Logs2,XRay2 aws;

Alt text: Flowchart of an ECS Fargate service fronted by API Gateway (ACM TLS + Lambda authorizer) that uses a VPC link to reach a private ALB balancing Fargate tasks with RDS and shared observability.

Snapshot cards

Detailed comparison

Below, we compare the three reference architectures across the dimensions that typically drive decision-making: cost, limitations, latency, scalability, operations, security, and portability.

1) Cost model

• Lambda + API Gateway
• Pay per invocation (ms × memory) with optional Provisioned Concurrency charges.
• Near-zero cost when idle, but sustained high throughput can exceed the cost of containers.
• Additional spend if you enable step functions, EventBridge fan-out, or provisioned capacity.
• ECS Fargate + Public ALB
• Pay per vCPU and GB-hour while tasks run, plus ALB hours/LCU usage.
• Predictable for steady workloads; you control task density and scaling thresholds.
• Image size, registry pulls, and NAT egress affect cost but are manageable with tuning.
• ECS Fargate + API Gateway + Private ALB
• Inherits Fargate + ALB costs and adds API Gateway per-request charges and VPC Link hourly fees.
• Useful when the gateway’s features (authorizers, usage plans) offset the higher per-request price.

Recommendation: Serverless remains the cheapest option for spiky workloads; public ALB Fargate wins for steady utilization; the hybrid gateway pattern is worth the premium when you need shared edge controls or partner-facing quotas.

2) Timeouts and request duration

• Lambda + API Gateway
• API Gateway REST/HTTP APIs enforce a 29-second timeout for synchronous calls (Lambda itself can run 15 minutes asynchronously).
• Queue/async patterns or WebSocket APIs are required for long-running work.
• ECS Fargate + Public ALB
• ALB supports long-lived connections, streaming, and WebSockets with no hard 29-second ceiling.
• The overall timeout is governed by your service logic and ALB idle timeouts (default 60 seconds, configurable).
• ECS Fargate + API Gateway + Private ALB
• The API Gateway front door still enforces the 29-second limit before traffic reaches the ALB.
• Consider chunked responses, streaming through ALB directly, or asynchronous APIs if requests may exceed that window.

Recommendation: choose a pure ALB front door when you need indefinite request duration or bidirectional streaming; stay with Lambda or the gateway pattern when edge controls matter more than long-lived connections.

3) Startup latency & cold starts

• Lambda + API Gateway
• Cold starts are noticeable for JVM and .NET functions; Provisioned Concurrency or SnapStart can mitigate this issue.
• Authorizer functions also need warming; keep them lightweight or pre-warm during business hours.
• ECS Fargate + Public ALB
• Running tasks stay warm, so latency is steady; scaling out takes tens of seconds while new tasks pull images and start.
• Min/desired task counts and capacity providers help hide startup latency during spikes.
• ECS Fargate + API Gateway + Private ALB
• The same container startup profile as the public ALB pattern; the Lambda authorizer remains warm independently.
• Consider enabling ECS Task Scale-In protection or predictive scaling for consistent API Gateway responses.

Recommendation: for ultra-low latency or predictable warm services, prefer Fargate; use Lambda when you can tolerate cold-start spikes or are willing to pay for Provisioned Concurrency.

4) Scalability and concurrency limits

• Lambda + API Gateway
• Scales to meet demand within seconds; default regional concurrency quota is 1,000 (increaseable).
• Per-function reserved and provisioned concurrency let you isolate noisy neighbors.
• ECS Fargate + Public ALB
• Scaling speed tied to task launch time; use Application Auto Scaling with step or target-tracking policies.
• Constrained by service quotas (tasks per service/cluster) and ALB target group connection limits.
• ECS Fargate + API Gateway + Private ALB
• ECS scaling considerations remain; API Gateway adds account-level RPS/concurrency quotas that protect your backend.
• VPC Link bandwidth also factors into burst capacity (managed by NLB under the hood).

Recommendation: Lambda is best for immediate concurrency spikes; Fargate provides more predictable, controlled scaling once tasks are warm; the gateway variant gives you throttling knobs at both the edge and container layers.

5) Operational complexity

• Lambda + API Gateway
• Focus on function code, IAM policies, environment variables, and deployment packages.
• AWS manages runtime patching and fleet; you monitor metrics/logs and adjust concurrency.
• ECS Fargate + Public ALB
• Own container image build pipelines, base OS updates, task definitions, autoscaling, and ALB target groups.
• Need strategies for image scanning, secrets injection, and dependency patching.
• ECS Fargate + API Gateway + Private ALB
• Includes all container ops plus API Gateway stage management, usage plans, and Lambda authorizer lifecycle.
• Valuable when centralized edge governance outweighs the added operational surface.

Recommendation: choose Lambda for the lightest operational load, Fargate when runtime control is essential, and the hybrid when you must combine container governance with API Gateway’s policy surface.

6) Developer experience & dependencies

• Lambda + API Gateway
• Fast feedback for lightweight handlers; frameworks like SAM, SST, or Serverless streamline local testing.
• Heavy frameworks are possible, but they inflate cold-start times and package sizes.
• ECS Fargate + Public ALB
• Full container parity between dev and prod; you can include native libraries, background workers, and cron sidecars.
• Requires familiarity with container tooling and longer inner-loop cycles when rebuilding images.
• ECS Fargate + API Gateway + Private ALB
• Same container DX as public ALB, plus the need to version API Gateway definitions and Lambda authorizer code.
• Useful when frontend/mobile teams already rely on API Gateway features (SDK generation, usage plans).

Recommendation: Lambda accelerates small teams and event-driven features; containers shine when you need heavyweight runtimes or consistent local environments.

7) Security, networking posture & TLS

• Lambda + API Gateway
• API Gateway terminates TLS with ACM; Lambda runs outside your VPC by default.
• Optional VPC access requires ENIs but keeps the edge public; least-privilege IAM roles per function/authorizer.
• ECS Fargate + Public ALB
• Tasks live in private subnets; ALB (public) handles TLS termination.
• Security groups, task roles, and VPC security patterns (NAT, service meshes) are under your control.
• ECS Fargate + API Gateway + Private ALB
• API Gateway terminates TLS; VPC Link (NLB) tunnels to a private ALB in your VPC.
• Gives you API Gateway’s authentication, throttling, and WAF while keeping services private.

Recommendation: Choose the gateway patterns when you require consistent edge authentication and TLS; use the public ALB path when you prefer direct control and minimal intermediaries.

8) Data & caching strategies

• Lambda + API Gateway
• Optimized for DynamoDB, Aurora Serverless, S3, and similar managed stores via lightweight SDK calls.
• Keep connections warm using RDS Proxy or DynamoDB global tables when latency is a concern.
• ECS Fargate + Public ALB
• Full access to RDS/Aurora, self-managed databases, Kafka, or legacy endpoints in the VPC.
• Can run local caches, sidecars, or Redis clients with long-lived connections.
• ECS Fargate + API Gateway + Private ALB
• Same data options as the public ALB model; API Gateway can add response caching or usage throttles upstream.

Recommendation: Lambda shines with managed serverless databases, while Fargate excels when you need persistent connections or custom data stores.

9) Observability & debugging

• Lambda + API Gateway
• CloudWatch Logs, X-Ray, Lambda Insights, and API Gateway execution logs are available with minimal setup.
• Local emulation via SAM CLI, LocalStack, or SST.
• ECS Fargate + Public ALB
• Choose between FireLens, Fluent Bit, or OTEL collectors to ship logs/traces.
• Debug using container tooling, exec sessions, and service mesh observability if adopted.
• ECS Fargate + API Gateway + Private ALB
• Combine API Gateway metrics/logs with container-level telemetry.
• Monitor the Lambda authorizer separately to catch policy or latency regressions.

Recommendation: Lambda provides the fastest path to structured telemetry; containers give you deep visibility but require more instrumentation.

10) CI/CD workflow

• Lambda + API Gateway
• Deploy rapidly with SAM, CDK, SST, or Serverless Framework; use Lambda versions/aliases and API Gateway stages for rollbacks.
• ECS Fargate + Public ALB
• Build/push container images (CodeBuild, GitHub Actions, etc.), then roll out via blue/green or canary deployments using CodeDeploy or weighted target groups.
• ECS Fargate + API Gateway + Private ALB
• Combine container pipelines with API Gateway stage promotion and Lambda authorizer deployment, coordinating edge and backend releases.

11) Resiliency & failover

• Lambda + API Gateway
• Multi-AZ by default; leverage retries, DLQs, and multi-region active/active with Route 53 latency routing.
• ECS Fargate + Public ALB
• Achieve resilience through multi-AZ task placement, health checks, and optional cross-region replicas or Global Accelerator.
• ECS Fargate + API Gateway + Private ALB
• Duplicate API Gateway stages, VPC Links, and ALBs across regions for active/standby; API Gateway adds edge throttling and request validation.

12) Portability & ecosystem lock-in

• Lambda + API Gateway
• Highly managed, AWS-specific programming model; porting to other clouds usually means re-architecting.
• ECS Fargate + Public ALB
• Containers plus IaC translate to Kubernetes, ECS on EC2, or other cloud runtimes with moderate effort.
• ECS Fargate + API Gateway + Private ALB
• Workloads remain portable, but API Gateway and Lambda authorizer features keep the edge solution AWS-centric.

13) Extra capabilities & integrations

• Lambda + API Gateway
• Native integrations with EventBridge, Step Functions, SQS/SNS, direct AWS SDK permissions, and managed throttling.
• ECS Fargate + Public ALB
• Layer WAF/Shield, service meshes (App Mesh/Istio), sidecars for auth/observability, or custom ingress controllers.
• ECS Fargate + API Gateway + Private ALB
• Access API keys, usage plans, REST/HTTP/WebSocket endpoints, PrivateLink partner integrations, and canary deployments at the gateway.

Example cost & performance scenarios

• Scenario A: Low-traffic API for a small SaaS with occasional spikes. Use Lambda for minimal ops and cost-effective idle behavior.
• Scenario B: High-throughput image-processing service where each request runs for dozens of seconds. Use Fargate to avoid large Lambda duration costs and timeout constraints.
• Scenario C: A WebSocket chat server requiring persistent connections. Use Fargate (or ECS with ALB WebSocket support / App Runner) rather than Lambda.
• Scenario D: Partner-facing API needing centralized throttling and IAM authorizers while containers handle heavy lifting. Use the API Gateway + VPC Link + Fargate pattern.

Implementation notes & best practices

• When using Lambda:
• Keep functions focused and small. Prefer multiple single-purpose functions over one large monolith.
• Use Provisioned Concurrency for latency-sensitive endpoints and weigh the cost trade-off.
• Cache database connections using techniques suitable for serverless environments (e.g., utilizing DynamoDB or RDS Proxy for relational databases).
• Use environment variables for configuration and parameter store or Secrets Manager for secrets.
• When using Fargate:
• Right-size CPU and memory for your tasks. Use autoscaling with sensible cooldowns.
• Keep container images lean and use multi-stage builds.
• Configure health checks on the ALB and container to ensure proper task replacements.
• Use task IAM roles and fine-grained security groups.
• When using Fargate with API Gateway + VPC Link:
• Keep the Lambda authorizer lightweight; monitor its latency and concurrency separately.
• Treat the VPC Link/NLB as infrastructure code (CDK/Terraform) and place ALBs in private subnets.
• Document API Gateway stage deployments alongside container releases to avoid drift.

When to choose which (cheat sheet)

• Pick Lambda when:
• Requests are short-lived (< 30s) and stateless.
• Traffic is spiky or unpredictable.
• You want minimal ops and rapid development.
• Pick Fargate when:
• You need long-running processes, websockets, or streaming.
• Your app has heavy startup time (JVM/Spring) or large native dependencies.
• You require advanced VPC networking and port controls.
• Pick Fargate with API Gateway when:
• You want container runtime control plus API Gateway features (Lambda authorizers, usage plans, API keys).
• Partner traffic or mobile clients depend on gateway throttles, SDK generation, or consistent edge policies.
• You must keep services private while presenting a unified public API domain.

Conclusion

Both Lambda and ECS Fargate are excellent options for building microservices on AWS. The right choice depends on your workload characteristics, latency requirements, operational preferences, and cost model. Small, event-driven, and bursty services favor Lambda. Predictable, long-running, and dependency-heavy services are well-suited for Fargate.