All Services
Serverless
AWS Lambda
Lambda runs event-driven code without managing servers. It is commonly used behind APIs, in asynchronous workflows, and for data processing.
Explore pricing models, common use cases, infrastructure support, and the AWS services that commonly work with AWS Lambda.
AWS Lambda pricing and cost programs
Pricing model: Serverless request and compute usage
- On-Demand
- Available
- Reserved Instances or reserved capacity
- Not applicable
- Savings Plans
- Available
- Spot
- Not applicable
Billing dimensions: Requests · Duration and memory · Provisioned concurrency · Ephemeral storage
Programs and modes: On-Demand duration · Compute Savings Plans · Tiered duration pricing
Compute Savings Plans cover eligible Lambda duration and provisioned concurrency usage, not every related charge.
Free Tier: Available — verify current offers
Pricing reviewed 2026-07-25. Reviewed against the linked official AWS pricing page. Recheck regional rates and program terms before purchase.
Official AWS pricing
Official AWS sources reviewed 2026-07-21.
Why implement AWS Lambda?
- Runs event-driven code without provisioning or patching servers and scales execution capacity with incoming events.
- Integrates directly with many AWS event sources and destinations, which reduces polling and custom integration infrastructure.
- Charges primarily for requests and execution duration, making it effective for intermittent and bursty workloads within Lambda limits.
How to implement AWS Lambda
- Create a function with a narrowly scoped execution role, choose a runtime and architecture, and package code plus dependencies.
- Configure memory, timeout, ephemeral storage, concurrency, environment or secret references, and the event source or API trigger.
- Publish versions and aliases for controlled releases, then add CloudWatch logs, metrics, alarms, failure destinations, and retry or dead-letter handling.
AWS Lambda best practices
- Initialize SDK clients and reusable connections outside the handler, tune memory with performance tests, and set realistic timeouts.
- Write idempotent handlers because event sources can deliver duplicates; use partial batch responses where supported to avoid reprocessing successful records.
- Apply least-privilege permissions, control concurrency to protect downstream systems, and monitor errors, throttles, duration, iterator age, and cost.
AWS Lambda use cases and server impact
- Event-driven APIs
- File and stream processing
- Scheduled automation and integration glue
Replaces always-on application or worker servers for bounded event-driven functions; architecture must still account for retries, concurrency, state, and service limits.
Official implementation resources
How AWS Lambda works with other AWS services
Arrows show the documented technical direction. Reciprocal navigation does not imply a reverse technical dependency.
Official AWS sources reviewed 2026-07-25.
Amazon API Gateway → AWS Lambda
API Gateway transforms an accepted HTTP, REST, or WebSocket request into a Lambda invocation and returns the integration response to the client.
- Why teams use it
- Teams gain a managed API front door while Lambda supplies independently deployable business logic.
- Permissions and networking
- Grant invocation permission narrowly, validate request payloads, set timeouts and concurrency controls, and avoid leaking backend errors.
- Pricing and security caveats
- API requests, Lambda invocations, duration, and data transfer are separate charges; synchronous API latency and timeout limits bound long-running work.
AWS Lambda → Amazon DynamoDB
Lambda functions call DynamoDB APIs with the function execution role; DynamoDB Streams can separately feed table changes back to Lambda through an event source mapping.
- Why teams use it
- The pairing provides serverless compute and low-operations key-value persistence that scale independently.
- Permissions and networking
- Use least-privilege table and index permissions, design partition keys for traffic, handle retries idempotently, and encrypt sensitive attributes appropriately.
- Pricing and security caveats
- DynamoDB capacity, storage, streams, and Lambda execution are separately billed. A direct write and a stream-triggered invocation are two distinct directions.
Amazon Simple Queue Service → AWS Lambda
A Lambda event source mapping polls an SQS queue, batches available messages, and invokes the function with those records.
- Why teams use it
- The queue absorbs bursts and decouples producers from function concurrency.
- Permissions and networking
- Set the visibility timeout above expected processing time, configure partial batch failure handling and a dead-letter strategy, and make consumers idempotent.
- Pricing and security caveats
- SQS requests and Lambda usage are billed independently. Processing is at least once, so duplicate delivery is expected rather than exceptional.
Amazon EventBridge → AWS Lambda
EventBridge rules match event content and deliver matching events to Lambda as a target.
- Why teams use it
- Producers stay unaware of consumers while teams add filtered asynchronous processing.
- Permissions and networking
- Use resource policies or execution roles as required, define stable event contracts, configure retries and dead-letter handling, and prevent recursive event loops.
- Pricing and security caveats
- Event ingestion, rule matching, archive or replay, and Lambda execution can each add cost; delivery order is not guaranteed for a standard event bus.
AWS Identity and Access Management → AWS Lambda
A Lambda execution role supplies temporary credentials that the function uses when it calls AWS APIs.
- Why teams use it
- Workload roles avoid long-lived embedded access keys and make permissions auditable.
- Permissions and networking
- Grant only required actions and resources, separate deployment from runtime roles, and use resource policies for inbound invocation where supported.
- Pricing and security caveats
- IAM itself has no additional charge, but authorized service calls do. An execution role controls Lambda outbound access, not who may invoke the function.
AWS Lambda → Amazon CloudWatch
Lambda publishes invocation metrics to CloudWatch and can write function logs to CloudWatch Logs when its execution role permits.
- Why teams use it
- The pairing provides a default operational view for errors, duration, throttles, and application output.
- Permissions and networking
- Use structured logs, retention policies, metric filters or embedded metrics, and alarms; never log credentials, tokens, or sensitive payloads.
- Pricing and security caveats
- High-volume logs, custom metrics, queries, and retention can become material costs, and telemetry delivery is not a substitute for idempotent error handling.
Architecture patterns using this service
- Build a secure serverless API on AWS — Authenticate users with Amazon Cognito, validate requests at Amazon API Gateway, run business logic in AWS Lambda, and store application data in Amazon DynamoDB.
- Design event-driven processing with EventBridge, SNS, SQS, Lambda, and Step Functions — Route events with EventBridge or fan them out with SNS, buffer work in SQS, process messages with Lambda, and orchestrate multi-step work in Step Functions when needed.
- Scan uploaded objects for malware and quarantine them on AWS — Land untrusted uploads in a private Amazon S3 bucket, scan them with GuardDuty Malware Protection for S3, route scan results through EventBridge and SQS, and promote only clean objects to a bucket consumers can read.
- Process images and media after an Amazon S3 upload — Take a presigned Amazon S3 upload through EventBridge and SQS to Lambda, Fargate, or AWS Batch workers, write derived assets to a separate bucket, and serve them through CloudFront.
- Run queue-backed asynchronous workers on AWS — Buffer background work in Amazon SQS, process it with Lambda or ECS workers under a concurrency ceiling, keep state in DynamoDB, and use dead-letter queues, redrive, and CloudWatch alarms to keep the system honest.
- Fan out AWS events to isolated consumers — Publish one event to EventBridge or SNS, give every consumer its own SQS queue, retry policy, and dead-letter queue, and let each consumer scale, fail, and deploy without touching the others.
Planning guides that use AWS Lambda