AWS Lambda and Serverless [2026]: Complete Guide to

What Serverless Actually Means (and What It Doesn't)
AWS Lambda Fundamentals: Triggers, Runtimes, and Limits
Lambda vs ECS vs App Runner vs EC2
Lambda Function Anatomy with Code Examples
Event Sources: API Gateway, S3, SQS, DynamoDB, EventBridge
Lambda for AI Workloads: Bedrock and Document Processing
IaC: AWS SAM vs Serverless Framework
The Cold Start Problem: Causes and Solutions
Cost Comparison: Serverless vs Containers at Scale
Step Functions for Serverless Orchestration
Frequently Asked Questions

Key Takeaways

Is AWS Lambda still worth using in 2026? Yes. AWS Lambda remains the dominant serverless compute option in 2026 for event-driven, bursty, or infrequent workloads.
What is the biggest downside of AWS Lambda? Cold starts are Lambda's most cited downside — the latency penalty incurred when AWS initializes a new execution environment for your function.
When should I use Lambda vs ECS vs EC2? Use Lambda for event-driven tasks, API backends under moderate traffic, ETL pipelines, and anything with spiky or unpredictable load.
Can AWS Lambda run AI and machine learning workloads? Lambda is excellent for AI inference orchestration and document processing, though not for training models.

Serverless compute turned ten years old in 2025. What started as a niche pattern for small event handlers has become the default architecture for APIs, data pipelines, AI backends, and automation workflows at companies from pre-seed startups to Fortune 100 enterprises. AWS Lambda alone processes trillions of function invocations per month.

But "serverless" is also one of the most misunderstood terms in software engineering. This guide cuts through the noise. You'll understand what serverless actually is, how Lambda works under the hood, when to use it versus containers or EC2, and how to build production-grade serverless systems including AI pipelines on Amazon Bedrock — in 2026.

15min

Lambda max execution timeout

10GB

Max memory per Lambda function

Free invocations per month (AWS free tier)

What Serverless Actually Means (and What It Doesn't)

Serverless means you do not manage servers — no provisioning, no patching, no scaling configuration. You write a function, deploy it, and AWS handles all underlying infrastructure automatically, billing you only per request and execution time with zero charge when idle. The infrastructure is entirely abstracted away.

The defining characteristics of a serverless platform are:

No provisioning: You never SSH into a machine or choose an instance type for your function code.
Pay-per-use: You are billed for execution time and requests, not for idle capacity.
Auto-scaling: Functions scale from zero to thousands of concurrent executions in seconds, automatically.
Event-driven: Functions are triggered by events — HTTP requests, file uploads, queue messages, database changes — not running continuously.

Serverless vs FaaS: What's the Difference?

Function-as-a-Service (FaaS) is the compute layer of serverless — Lambda, Azure Functions, Google Cloud Run. "Serverless" is a broader architectural pattern that also includes managed databases (DynamoDB, Aurora Serverless), serverless messaging (SQS, SNS, EventBridge), and serverless storage (S3). You can build an entirely serverless system where every component auto-scales and charges per use.

The model is not universally better than containers or VMs. It is a trade-off. You gain operational simplicity and cost efficiency for bursty workloads. You give up fine-grained runtime control, accept execution time limits, and introduce cold start latency. Knowing when those trade-offs work in your favor is the key skill.

AWS Lambda Fundamentals: Triggers, Runtimes, and Limits

AWS Lambda runs your code in a stateless micro-VM built on Firecracker, supports Python 3.12, Node.js 22, Java 21, .NET 8, Go, and container images up to 10GB, with a hard 15-minute execution limit and default concurrency of 1,000 per region — understand these limits before designing your architecture. AWS manages the execution environment and provisions new instances as demand grows.

Supported Runtimes in 2026

Lambda supports managed runtimes maintained by AWS, custom runtimes via the Runtime API, and container images up to 10GB. The most commonly used runtimes are:

Python 3.12 / 3.13 — dominant for data, ML, and scripting workloads
Node.js 22.x — fastest cold starts for lightweight API handlers
Java 21 — enterprise standard; best paired with SnapStart
.NET 8 — C# and F# for Microsoft-stack teams
Go 1.x (custom runtime) — compiled binary, minimal cold start
Container Image — any language/runtime, packages up to 10GB

Key Hard Limits

Limit	Value	Notes
Max execution timeout	15 minutes	Not suitable for long ETL or batch jobs
Max memory	10,240 MB (10 GB)	CPU scales proportionally with memory
Deployment package size (zip)	50 MB compressed / 250 MB unzipped	Use container image for larger deps
Ephemeral storage (/tmp)	512 MB – 10 GB (configurable)	Not persisted between invocations
Default concurrency limit	1,000 per region	Soft limit; can request increase
Payload size (synchronous)	6 MB request / 6 MB response	Use S3 for large file transfers

Lambda vs ECS vs App Runner vs EC2

Use Lambda for event-driven workloads under 15 minutes with variable traffic; use ECS Fargate for long-running containerized services; use App Runner for HTTP services that need automatic scaling without load balancer configuration; use EC2 only for sustained compute, GPU workloads, or full OS access. The right choice depends on traffic patterns, latency requirements, and operational preferences.

AWS Lambda

Best for event-driven, spiky workloads

Zero-to-scale in milliseconds. Ideal for APIs under ~10M req/month, ETL triggers, automation, and AI pipeline steps. No containers to manage.

ECS Fargate

Best for long-running containerized services

Run Docker containers without managing EC2. Best for services that need sustained throughput, custom runtimes, or exceed Lambda's 15-min limit.

App Runner

Best for HTTP services with auto-scaling

Fully managed HTTP container service. Simpler than ECS for teams that want container benefits without the load balancer / task definition complexity.

EC2

Best for sustained compute, GPU, or OS control

Direct server access. Choose EC2 for ML training, high-throughput batch processing, GPU workloads (G5, P4 instances), or legacy lift-and-shift apps.

Factor	Lambda	ECS Fargate	App Runner	EC2
Startup time	Milliseconds (warm)	~30–60 sec	~5–10 sec	~1–5 min
Max execution time	15 min	Unlimited	Unlimited	Unlimited
Scales to zero	Yes	No	Yes (pause)	No
Custom runtime	Via container image	Any Docker image	Any Docker image	Full OS
GPU support	No	Limited	No	Yes (G5, P4)
Pricing model	Per request + GB-sec	Per vCPU/mem/hour	Per vCPU/mem/hour	Per instance/hour
Infra management	None	Cluster + task defs	Minimal	Full

Lambda Function Anatomy with Code Examples

Every Lambda function follows the same pattern: a handler function receives an event object (shape varies by trigger — API Gateway, S3, SQS, etc.) and a context object with metadata, then returns a response. Initialize SDK clients outside the handler to reuse them across warm invocations — this single pattern reduces latency by 50–200ms on warm calls.

Python Handler

Python 3.12 — lambda_function.py

import json
import boto3
import os

# Initialized outside handler — reused across warm invocations
s3_client = boto3.client('s3')
TABLE_NAME = os.environ['DYNAMODB_TABLE']

def handler(event, context):
    """
    Entry point for Lambda. Called on every invocation.
    event  — dict with trigger-specific data
    context — runtime metadata (function name, deadline, etc.)
    """
    # Parse body if coming from API Gateway
    body = json.loads(event.get('body', '{}'))
    user_id = body.get('user_id')

    if not user_id:
        return {
            'statusCode': 400,
            'body': json.dumps({'error': 'user_id required'})
        }

    # Business logic here
    result = process_user(user_id)

    return {
        'statusCode': 200,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps(result)
    }

def process_user(user_id: str) -> dict:
    # DynamoDB lookup, S3 read, Bedrock call, etc.
    return {'user_id': user_id, 'status': 'processed'}

Node.js Handler

Node.js 22.x — index.mjs (ES Module)

import { DynamoDBClient, GetItemCommand } from '@aws-sdk/client-dynamodb';

// SDK client lives outside handler — reused on warm starts
const dynamo = new DynamoDBClient({ region: 'us-east-1' });

export const handler = async (event, context) => {
  const { pathParameters, body } = event;
  const itemId = pathParameters?.id;

  try {
    const { Item } = await dynamo.send(new GetItemCommand({
      TableName: process.env.TABLE_NAME,
      Key: { id: { S: itemId } }
    }));

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

    return {
      statusCode: 200,
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(Item)
    };
  } catch (err) {
    console.error(err);
    return { statusCode: 500, body: JSON.stringify({ error: 'Internal error' }) };
  }
};

Critical Performance Pattern: Initialize Outside the Handler

Any object created outside the handler function — SDK clients, database connections, loaded config — is reused across warm invocations of the same execution environment. This is one of the most impactful Lambda optimizations. Move your boto3.client(), DynamoDB clients, and Bedrock clients outside the handler. They will be initialized once on cold start and reused for all subsequent calls.

Event Sources: API Gateway, S3, SQS, DynamoDB Streams, EventBridge

Lambda integrates natively with API Gateway (synchronous HTTP), S3 (async file processing), SQS (batch queue workers), DynamoDB Streams (change data capture), and EventBridge (scheduled and event-routed triggers) — each with different retry behaviors and invocation models that directly affect how you handle failures. Rather than polling for work, functions are invoked by events — making the architecture reactive, loosely coupled, and highly scalable.

API Gateway (HTTP)

The most common trigger. API Gateway HTTP API v2 routes HTTP requests directly to Lambda with low latency (typically under 10ms of added overhead). Use HTTP API for REST and WebSocket APIs; use REST API (v1) only when you need advanced features like request validation models or usage plans.

S3 (Object Storage Events)

Trigger Lambda when objects are uploaded, deleted, or modified. The canonical use case: a user uploads a PDF to S3, Lambda is triggered, it processes the document (extract text, chunk for RAG, call Bedrock for summarization), and writes results to DynamoDB. S3 triggers are asynchronous — Lambda retries automatically on failure.

SQS (Queue-Based Processing)

Lambda polls SQS queues and processes messages in batches. This is the safest pattern for high-volume, at-least-once processing. Lambda scales up workers as the queue depth grows and scales to zero when the queue is empty. Configure ReservedConcurrency to prevent a queue spike from consuming your entire account concurrency limit.

DynamoDB Streams

React to every insert, update, or delete in a DynamoDB table. Common patterns: replicate data to Elasticsearch/OpenSearch for search, trigger downstream notifications, maintain audit logs, or invalidate caches. DynamoDB Streams delivers ordered, shard-based change data capture at millisecond latency.

EventBridge (Event Bus)

AWS's managed event bus. Route events from your own applications, AWS services, or third-party SaaS platforms (Stripe, Zendesk, GitHub) to Lambda functions using rule-based filtering. EventBridge Scheduler (formerly CloudWatch Events) is the modern way to run Lambda on a cron schedule.

Trigger	Invocation Model	Retry Behavior	Common Use Case
API Gateway	Synchronous	No automatic retry	REST APIs, webhooks
S3	Asynchronous	2 retries (configurable)	File processing, ETL
SQS	Polling (batch)	Via DLQ after max receives	Queue workers, fan-out
DynamoDB Streams	Polling (shard)	Blocked until success or expiry	Change data capture
EventBridge	Asynchronous	2 retries (configurable)	Scheduling, event routing
SNS	Asynchronous	3 retries with backoff	Fan-out pub/sub

Lambda for AI Workloads: Calling Bedrock and Processing Documents

Lambda is the dominant compute layer for serverless AI pipelines in 2026 — it handles orchestration and event-driven processing while Bedrock provides the inference, with a typical end-to-end latency of around 300ms for a warm Lambda calling Claude 3.5 Haiku for summarization. Lambda handles the orchestration and event-driven glue work; Bedrock provides Claude 3.5, Llama 3, Titan Embeddings, and others without any model hosting infrastructure.

~300ms

Typical Lambda + Bedrock latency for a summarization call (warm function, Claude Haiku)

Excludes Bedrock model inference time, which varies by model and input length

Calling Amazon Bedrock from Lambda (Python)

Python — Lambda + Bedrock (Claude 3.5 Haiku)

import json
import boto3

# Initialize Bedrock client outside handler (warm start optimization)
bedrock = boto3.client(
    service_name='bedrock-runtime',
    region_name='us-east-1'
)

MODEL_ID = 'anthropic.claude-3-5-haiku-20241022-v1:0'

def handler(event, context):
    # Get document text from S3 event or request body
    document_text = event['document_text']

    payload = {
        'anthropic_version': 'bedrock-2023-05-31',
        'max_tokens': 1024,
        'messages': [
            {
                'role': 'user',
                'content': f'Summarize the following document in 3 bullet points:\n\n{document_text}'
            }
        ]
    }

    response = bedrock.invoke_model(
        modelId=MODEL_ID,
        body=json.dumps(payload),
        contentType='application/json',
        accept='application/json'
    )

    result = json.loads(response['body'].read())
    summary = result['content'][0]['text']

    return {
        'statusCode': 200,
        'body': json.dumps({'summary': summary})
    }

Production AI Pipeline Pattern

The most common serverless AI pipeline in 2026:

User uploads PDF → S3 triggers Lambda (document-processor)
Lambda extracts text, chunks into 512-token segments
Lambda calls Bedrock Titan Embeddings for each chunk
Embeddings stored in OpenSearch Serverless (vector index)
API Gateway → Lambda (query-handler) → Bedrock Claude for RAG response
Results written to DynamoDB; DynamoDB Stream triggers notification Lambda

Every component scales to zero. Total infrastructure cost for low-volume workloads can be under $10/month.

Infrastructure as Code: AWS SAM vs Serverless Framework

Define Lambda infrastructure as code from day one using AWS SAM (native, CloudFormation-based, with local emulation via sam local invoke) or Serverless Framework (cloud-agnostic, larger plugin ecosystem) — clicking through the console is not repeatable and will cost you in production incidents. Both tools let you define functions, event sources, IAM policies, and supporting resources in a single version-controlled config file.

AWS SAM (Serverless Application Model)

SAM is AWS's native IaC tool for serverless. It extends CloudFormation with shorthand syntax for Lambda functions, API Gateway, DynamoDB tables, and event source mappings. It includes a local emulator (sam local invoke, sam local start-api) that runs Lambda in a Docker container for offline testing.

AWS SAM — template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Serverless AI document processor

Globals:
  Function:
    Runtime: python3.12
    MemorySize: 1024
    Timeout: 30
    Environment:
      Variables:
        TABLE_NAME: !Ref DocumentTable

Resources:
  DocumentProcessor:
    Type: AWS::Serverless::Function
    Properties:
      Handler: lambda_function.handler
      CodeUri: src/document_processor/
      Policies:
        - S3ReadPolicy:
            BucketName: !Ref DocumentBucket
        - DynamoDBWritePolicy:
            TableName: !Ref DocumentTable
        - Statement:
            Effect: Allow
            Action: bedrock:InvokeModel
            Resource: '*'
      Events:
        S3Upload:
          Type: S3
          Properties:
            Bucket: !Ref DocumentBucket
            Events: s3:ObjectCreated:*

  DocumentBucket:
    Type: AWS::S3::Bucket

  DocumentTable:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: document_id
        Type: String

Serverless Framework

Serverless Framework is cloud-agnostic (AWS, Azure, GCP) and uses a YAML config that generates CloudFormation behind the scenes. It has a richer plugin ecosystem and is popular in teams that deploy to multiple clouds. The serverless.yml syntax is often more concise than SAM for simple functions.

SAM vs Serverless Framework: Quick Pick

AWS-only project, want native tooling: SAM
Multi-cloud or rich plugin ecosystem needed: Serverless Framework
Large team already using Terraform: Use the AWS Lambda Terraform module instead — keep IaC consistent
CDK users: AWS CDK has a @aws-cdk/aws-lambda-nodejs construct that bundles Lambda functions with esbuild automatically

The Cold Start Problem: Causes and Solutions

A cold start adds 100ms to 3+ seconds of latency on the first invocation after a function is idle — Node.js functions with minimal dependencies cold-start in under 200ms, while Java with Spring or Python with large ML libraries can exceed 3 seconds. Provisioned Concurrency (fixed cost), Lambda SnapStart for Java, and keeping packages lean are the three main mitigations. The cold start occurs when AWS must initialize a new execution environment: download the deployment package, start the Firecracker micro-VM, initialize the runtime, and run your initialization code.

~200ms

Typical cold start for Python/Node.js Lambda with standard AWS SDK dependencies

Java without SnapStart: 1,000–4,000ms. Java with SnapStart: under 200ms.

Root Causes of Slow Cold Starts

Large deployment packages — every imported library adds download and parse time
Heavy initialization code — loading large ML models, parsing big config files outside the handler
VPC attachment — Lambda functions inside a VPC historically had 10–15 second cold starts; AWS fixed this with Hyperplane ENIs in 2020, but VPC still adds ~100–200ms
JVM startup — Java's classloading and JIT compilation are inherently slow to initialize

Solutions in 2026

Solution	How It Works	Cost	Best For
Provisioned Concurrency	Pre-warms N execution environments; they stay ready	~$0.015/GB-hr	Latency-critical production APIs
SnapStart (Java)	Snapshots initialized JVM state; restores instead of re-initializing	No extra charge	Java 11+ Lambda functions
Minimize package size	Tree-shake deps, use Lambda Layers for shared libs	Free	All runtimes
Lazy loading	Import heavyweight libraries inside the function path, not module-level	Free	Python, Node.js
Keep warm (ping)	EventBridge rule calls function every 5 min to prevent deallocation	~$0 (free tier)	Low-traffic functions with strict latency SLA

SnapStart: The Cold Start Killer for Java

AWS SnapStart, launched in 2022 and expanded to all Java 11+ runtimes, takes a snapshot of the initialized Lambda execution environment after the init phase completes. On subsequent cold starts, Lambda restores from the snapshot instead of re-running initialization. This reduces Java cold starts from 2–4 seconds to under 200ms — bringing Java on par with Python and Node.js. Enable it with a single config flag: SnapStart: ApplyOnPublishedVersions.

Cost Comparison: Serverless vs Containers at Scale

Serverless compute is cheapest at low-to-moderate traffic. As requests-per-second grow, the per-invocation pricing model eventually exceeds the cost of running a continuously provisioned container. Knowing the crossover point is essential for architecture decisions.

Lambda pricing (us-east-1, 2026): $0.20 per million requests + $0.0000166667 per GB-second. The first 1 million requests and 400,000 GB-seconds per month are free.

Monthly Traffic	Lambda Cost (512MB, 200ms avg)	ECS Fargate Cost (0.25 vCPU / 0.5GB)	Verdict
100K requests	~$0.02	~$11 (min. 1 task)	Lambda wins
1M requests	~$0.20 + ~$1.70 = ~$1.90	~$11	Lambda wins
10M requests	~$2 + ~$17 = ~$19	~$22 (2 tasks avg)	Roughly equal
100M requests	~$20 + ~$170 = ~$190	~$110 (10 tasks avg)	Fargate wins
1B requests	~$1,900	~$550 (50 tasks avg)	Fargate wins significantly

The Real Cost Comparison Is More Nuanced

The table above compares pure compute costs. In practice, Lambda's operational savings — no load balancer configuration, no container orchestration, no autoscaling policy tuning — represent real engineering hours. For most teams processing under 50M requests/month, Lambda's lower operational overhead justifies the higher per-unit compute cost. The tipping point for switching to Fargate is typically around 50–100M requests/month for a typical API workload.

Step Functions for Serverless Orchestration

Lambda functions are stateless. When you need to chain multiple functions together — with branching logic, parallel execution, retries, and state — you need an orchestrator. AWS Step Functions is the native answer.

Step Functions defines workflows as state machines using Amazon States Language (ASL), a JSON/YAML format. Each state can invoke a Lambda function, call an AWS SDK service directly (DynamoDB, SQS, Bedrock), wait for a callback, or run parallel branches.

When to Use Step Functions

Multi-step document processing: extract text → chunk → embed → store → notify
Human-in-the-loop workflows: wait for approval before proceeding (callback pattern)
Parallel fan-out: process 1,000 items simultaneously with Map state
Long-running workflows: Step Functions can wait up to 1 year for a callback, far beyond Lambda's 15-minute limit
Error handling with retries: define retry logic and catch clauses declaratively in the state machine instead of imperatively in code

Step Functions ASL — AI Document Pipeline (simplified)

{
  "Comment": "AI document processing pipeline",
  "StartAt": "ExtractText",
  "States": {
    "ExtractText": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789:function:extract-text",
      "Next": "ChunkAndEmbed",
      "Retry": [{ "ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 3 }]
    },
    "ChunkAndEmbed": {
      "Type": "Map",
      "MaxConcurrency": 10,
      "ItemsPath": "$.chunks",
      "Iterator": {
        "StartAt": "EmbedChunk",
        "States": {
          "EmbedChunk": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:us-east-1:123456789:function:embed-chunk",
            "End": true
          }
        }
      },
      "Next": "StoreEmbeddings"
    },
    "StoreEmbeddings": {
      "Type": "Task",
      "Resource": "arn:aws:states:::dynamodb:putItem",
      "Parameters": {
        "TableName": "DocumentEmbeddings",
        "Item": { "document_id": { "S.$": "$.document_id" } }
      },
      "End": true
    }
  }
}

Express vs Standard Workflows

Standard Workflows are exactly-once, durable, and audit all state transitions to CloudWatch. Maximum duration: 1 year. Priced per state transition (~$0.025 per 1,000). Use for business-critical, long-running workflows.

Express Workflows are at-least-once, high-throughput (100K executions/sec), and priced per execution duration. Maximum duration: 5 minutes. Use for high-volume event processing pipelines where cost matters more than exactly-once guarantees.

Build real serverless systems — hands-on

Precision AI Academy's October 2026 bootcamp covers Lambda, Bedrock, Step Functions, and production cloud architecture over two intensive days. Five cities. Forty seats per city.

Reserve Your Seat — $1,490

Denver · NYC · Dallas · Los Angeles · Chicago · October 2026

The bottom line: AWS Lambda is the right default for event-driven workloads — API backends, file processing pipelines, AI orchestration, and scheduled jobs — where traffic is variable and you want zero infrastructure management. The 15-minute execution limit and cold start latency are manageable with proper architecture. At very high sustained throughput, run the numbers against ECS Fargate. For AI workloads, the Lambda + Bedrock combination is the fastest path to production serverless AI without owning any model infrastructure.

Frequently Asked Questions

Is AWS Lambda still worth using in 2026?

Yes. AWS Lambda remains the dominant serverless compute option in 2026 for event-driven, bursty, or infrequent workloads. Its value proposition — pay only for execution time, zero infrastructure management, automatic scaling — is unchanged. The platform has matured significantly with SnapStart for Java, improved cold start performance across all runtimes, and native integration with AI services like Bedrock. For stateless, short-lived compute tasks, Lambda is still the fastest path from code to production.

What is the biggest downside of AWS Lambda?

Cold starts are Lambda's most cited downside — the latency penalty incurred when AWS initializes a new execution environment for your function. In 2026, this is largely a solved problem for most workloads. Provisioned Concurrency eliminates cold starts by pre-warming environments, and SnapStart (for Java) reduces initialization from seconds to under 200ms. For Node.js and Python functions with lean dependencies, cold starts rarely exceed 200–400ms. The real downside for sustained, high-throughput traffic is cost: at tens of millions of requests per month, containers on ECS Fargate often become cheaper.

When should I use Lambda vs ECS vs EC2?

Use Lambda for event-driven tasks, API backends under moderate traffic, ETL pipelines, and anything with spiky or unpredictable load. Use ECS Fargate when you need long-running processes, containers for reproducibility, or when Lambda's 15-minute timeout is a constraint. Use EC2 for sustained high-CPU workloads, GPU instances, or when you need fine-grained OS control. App Runner is a middle ground — container-based but fully managed, best for HTTP workloads that outgrow Lambda's limits.

Can AWS Lambda run AI and machine learning workloads?

Lambda is excellent for AI inference orchestration and document processing, though not for model training. The most common pattern in 2026 is Lambda as the event-driven orchestrator that calls Amazon Bedrock (Claude, Llama, Titan) for inference, processes results, and writes to DynamoDB or S3. Lambda's 10GB memory limit and 15-minute timeout are sufficient for document chunking, embedding generation, and RAG pipeline steps. For heavier ML inference where you need GPU, use SageMaker Endpoints or ECS with GPU-enabled task definitions.

"Serverless is not a destination — it is a spectrum. The best architectures in 2026 combine Lambda for event-driven glue, managed services for persistence, and containers only where the operational trade-off is worth it."

AWS Lambda and Serverless in 2026: Complete Guide to Event-Driven Architecture

In This Article