AWS Lambda FAQs

AWS Lambda offers three form factors. They share the same serverless foundation: you don't manage servers, you pay only for what you use, and Lambda manages networking and isolation.

• Lambda Event Functions (formerly Lambda functions) run your code in response to events and API calls. Your existing Lambda functions are now called Event Functions, and you don't need to change your code or redeploy them. You write a handler, connect it to a trigger such as Amazon API Gateway, Amazon S3, or Amazon SQS, and Lambda runs it. By default, each execution environment processes one request at a time, and Lambda fully manages the lifecycle. An invocation can run for up to 15 minutes by default, or up to 90 minutes for asynchronous and event source mapping invocations on Lambda Managed Instances. Durable functions support multi-step workflows that last up to one year. You pay per request plus GB-seconds of execution time. Event Functions run on Lambda-managed compute, or on Lambda Managed Instances in your account, where one execution environment can process multiple requests at the same time.
• Lambda Web Functions run web applications and API backends as HTTP servers. Your Node.js code listens on a port and handles HTTP requests directly, using web frameworks such as Express, Hono, or React Router without adapters. Each execution environment serves multiple concurrent requests. Lambda provides an HTTPS endpoint and scales your application with traffic, including to zero when it's idle. You can also deploy across multiple AWS Regions behind a single endpoint. Each HTTP request can run for up to 15 minutes, with a default of 30 seconds. You pay per request, plus active CPU time (per second) and memory for each execution environment's lifetime.
• Lambda MicroVMs are isolated compute environments that you control. They're built for workloads that need a dedicated environment for each user or job, such as running user-generated or AI-generated code. Each MicroVM runs a full Amazon Linux 2023 operating system from a MicroVM image that you provide, and your application connects users to their MicroVM through HTTPS endpoints. You run, suspend, resume, and terminate MicroVMs through the API, and you can set idle policies to suspend and resume them automatically. Memory and disk state are preserved while a MicroVM is suspended. Each MicroVM has a total lifespan of up to 8 hours, including both running and suspended time. You pay per second of compute while a MicroVM runs, plus snapshot storage while it's suspended.

AWS Lambda supports a wide range of popular programming languages. Each has an idiomatic programming experience tailored to that language. Visit documentation to learn more.

Every Lambda execution environment runs inside a dedicated Firecracker microVM with its own kernel, memory, and file system — no two environments share a kernel or memory space. Event Functions isolates each request in its own environment. Web Functions serves multiple concurrent requests within a single environment, but each environment is still VM-isolated from all others. MicroVMs provides the same Firecracker-based isolation with customer-controlled lifecycle and state preserved across sessions, purpose-built for workloads that execute untrusted or AI-generated code. Visit the Lambda documentation to learn more.

AWS Lambda stores code in Amazon S3 and encrypts it at rest. AWS Lambda performs additional integrity checks while your code is in use. For sensitive information, such as database passwords, we recommend you use client-side encryption using AWS Key Management Service and store the resulting values as ciphertext in your environment variable. You will need to include logic in your AWS Lambda function code to decrypt these values. Visit documentation to learn more.

AWS Lambda encrypts your code at rest in Amazon S3 and performs integrity checks while your code is in use. All execution environments run inside Firecracker microVMs with hardware-level isolation, so your code and data are never shared with other tenants. For sensitive configuration such as database credentials or API keys, store encrypted values in environment variables using AWS Key Management Service and decrypt them in your function code. Lambda also supports VPC connectivity for functions that need to access resources inside your private network. Visit the data protection documentation to learn more.

Yes. You can easily create and modify environment variables from the AWS Lambda Console, CLI, or SDKs. To learn more about environment variables, see the documentation.

AWS Lambda automatically monitors Lambda functions on your behalf, reporting real-time metrics through Amazon CloudWatch, including total requests, account-level and function-level concurrency usage, latency, error rates, and throttled requests. You can view statistics for each of your Lambda functions via the Amazon CloudWatch console or through the AWS Lambda console. You can also call third-party monitoring APIs in your Lambda function.
 

Visit Troubleshooting CloudWatch metrics to learn more. Standard charges for AWS Lambda apply to use Lambda’s built-in metrics.

AWS Lambda is a serverless compute service that charges you only for what you use. Lambda Event Functions are priced per request and execution duration. Lambda MicroVMs are priced per instance-second. Lambda Web Functions are priced per requests and active CPU time. Please see the AWS Lambda pricing page for details.

A Lambda Web Function runs a standard application that listens for HTTP requests on a port, rather than a handler that responds to discrete events. You bring an application built on a web framework such as Express or Hono, and Lambda runs it on managed infrastructure, handling scaling, availability, and the underlying compute. A single execution environment can serve multiple concurrent requests, so fewer cold starts occur and response times stay consistent under variable traffic. You are billed for the active CPU time your code consumes and the memory it uses, so you don't pay for CPU time spent waiting on I/O such as database queries or downstream API calls.

Lambda Web Functions provides the following benefits:

• Adaptive scaling – Web Functions scale automatically with your traffic, from zero when idle up to your workload's demand, with no capacity planning or resource provisioning required.
• Multi-concurrency – A single execution environment can serve multiple requests at the same time, rather than one request at a time. This reduces the number of environments needed, lowers the frequency of cold starts, and delivers more consistent response times under variable traffic.
• Active CPU billing – You are billed for the active CPU time your code consumes and the memory it uses, so you don't pay for CPU time spent waiting on I/O such as database queries or downstream API calls.
• Response streaming – Web Functions can stream responses to clients as data is produced, using server-sent events (SSE) and chunked transfer, which is well suited to AI and generative responses, media, and other real-time workloads.
• Higher limits – Web Functions raise several limits to better fit web workloads, including a deployment package size of up to 512 MB, environment variables up to 32 KB, larger request and response payloads, and request headers up to 64 KB.

Start with how your workload is invoked. A Web Function is the right choice when your workload serves HTTP traffic such as a web application, a REST or GraphQL API, a server-side-rendered site, or a streaming endpoint . If your code is instead triggered by AWS events such as messages, streams, or storage changes (Amazon SQS, Amazon Kinesis, Amazon S3, or Amazon EventBridge), use an Event Function. If you need to run untrusted or AI-generated code in an isolated, per-session sandbox with a customer-managed lifecycle, use Lambda MicroVMs.

Within HTTP workloads, a Web Function is a particularly strong fit when:

• Your requests spend time waiting on I/O, such as database queries, downstream API calls, or model inference. You are billed for active CPU time rather than wall-clock time, and multi-concurrency lets a single execution environment serve other requests during that wait.
• Your traffic is variable or bursty. Web Functions scale automatically, and because each execution environment can serve multiple concurrent requests, fewer cold starts occur and response times stay more consistent.
• You need to stream responses, such as token-by-token output from a large language model, using server-sent events or chunked transfer.

You are billed across three dimensions: the active CPU time your code consumes, the memory it uses, and the number of requests it processes. You are not billed for CPU time spent waiting on I/O, such as database queries, network calls, or downstream API responses. Because a single execution environment can serve multiple concurrent requests, compute costs are shared across those requests.

Each Web Function endpoint is served over HTTPS and can be secured using AWS IAM. You control who can invoke the endpoint through IAM permissions. When you configure IAM authentication on an endpoint, callers must sign their requests with AWS SigV4 credentials, and only principals you grant permission can invoke the function. To serve an IAM-authenticated endpoint to the public internet, you can put Amazon CloudFront in front of your Web Function and use it as the origin. CloudFront signs viewer requests to the endpoint using its origin access control, and your Web Function remains protected by IAM. This pattern is well suited to web applications and APIs that need dynamic content from a Web Function alongside cached and static content. Because the endpoint is standard HTTPS, you can also front a Web Function with other HTTP entry points. An Application Load Balancer (ALB) or Amazon API Gateway can sit in front of a Web Function to provide capabilities such as custom domains, request routing, or additional authorization layers.

Yes. Multi-region deployment is an opt-in capability configured at the endpoint level, and Lambda offers two endpoint types depending on whether you want Lambda to route traffic for you or to manage routing yourself. An endpoint is the built-in HTTPS entry point that receives client requests and routes them to your Web Function, with configurable authentication and throttling.

With a multi-region endpoint, you specify the regions you want, and Lambda replicates your Web Function code to each of them. Lambda provides a single endpoint and routes each request to the region with the lowest latency for the viewer, so users are served from the nearest available region without any routing configuration on your side. With per-region endpoints, Lambda still replicates your code to each region you specify, but you are responsible for managing how traffic reaches each regional domain. Each region exposes its own endpoint, and you control the routing in front of them  to direct requests according to your own latency, failover, or data-residency requirements. In both cases, multi-region deployment is opt-in and applies only to the regions you choose.

Lambda automatically reports metrics to Amazon CloudWatch and captures everything your application writes to standard output and standard error (in Node.js, console.log and console.error) to CloudWatch Logs, with no logging agent or SDK required. You can emit structured JSON logs, set separate application and system log levels to control detail and cost, query fields in CloudWatch Logs Insights, publish custom metrics using the embedded metric format (EMF), and view HTTP signals such as status codes, latency, and error rates. For a Web Function deployed across multiple regions, metrics and logs are centralized in the home region, giving you a single place to view aggregate traffic, latency, and error rates across all the regions where your code is replicated. 

Yes. You can connect a Web Function to your Amazon Virtual Private Cloud (VPC) using a Lambda network connector. A network connector is a reusable Lambda resource: you create it once and reference it from each Web Function revision that needs VPC access. With an egress network connector, outbound traffic from your Web Function goes through network interfaces in the connector's subnets, and your VPC route tables, security groups and network ACLs apply. Use a network connector to reach private resources such as Amazon RDS databases or internal services.

An event source is an AWS service or developer-created application that produces events that trigger an AWS Lambda event function to run. Some services publish these events to Lambda by invoking the cloud function directly (for example, Amazon S3). Lambda can also poll resources in other services that do not publish events to Lambda. For example, Lambda can pull records from an Amazon Kinesis stream or an Amazon SQS queue and execute a Lambda function for each fetched message.Many other services, such as AWS CloudTrail, can act as event sources simply by logging to Amazon S3 and using S3 bucket notifications to trigger AWS Lambda event functions

Formerly known as Lambda Functions, Lambda Event Functions is the foundation for event-driven workloads. Please see our documentation for a complete list of event sources.

You can invoke a Lambda function using a custom event through AWS Lambda’s invoke API. Only the function owner or another AWS account that the owner has granted permission can invoke the function. Visit the Lambda Developers Guide to learn more.

Yes, you can package any code (frameworks, SDKs, libraries, and more) as a Lambda Layer and manage and share them easily across multiple event functions.

Use Lambda durable functions when you want to build logic within Lambda's familiar programming model, with local testing, IDE integration, and your preferred programming language. Use AWS Step Functions when you need visual workflow design, cross-team visibility, 220+ native service integrations, or zero-maintenance infrastructure. Many applications benefit from using both together.

AWS Lambda durable functions currently support JavaScript, TypeScript, Python and Java. Learn more about supported runtimes.

For the latest availability, visit the AWS Capabilities by Region page.

Yes. While the per-invocation timeout remains 15 minutes, Lambda durable functions can suspend and resume across multiple invocations using wait capabilities such as timers, callbacks, and polling conditions. When you invoke durable functions asynchronously, the durable execution timeout can extend up to one year, enabling use cases such as human-approval workflows, scheduled reminders, and multi-day processing pipelines. For on-demand functions, there are no compute charges during suspension.

The execution timeout (up to 1 year) governs how long an execution can run. The retention period (up to 90 days) governs how long history and checkpoint data are retained after the execution reaches a terminal state. Retention does not affect running executions. See Durable function configuration.

No. For on-demand functions, when using the wait capabilities of the durable execution SDK, there are no compute charges during suspension. For more information, see the pricing page and the developer guide.

You can wrap each unit of work in a step with automatic retries. If a step fails after retrying, your handler code can catch the error and run compensating steps, such as refunding a payment or releasing a reservation. Because each completed step is checkpointed, including compensations, successfully completed work is not repeated on retry. This pattern helps you build reliable multi-step processes, such as order fulfillment or payment workflows, without writing custom retry and state-tracking logic.

Execution state is stored in a fully managed internal state store. Each checkpointed operation, such as a step or callback, can store up to 256 KB of data. This limit applies to the data returned from the operation. Data operated on within an operation, such as reading and writing large S3 objects, does not count against this limit. If an operation needs to return a large result, you can configure custom serializers in the SDK to offload payloads to Amazon S3 or Amazon DynamoDB and pass only a reference through the checkpoint.

Lambda durable functions use the same account-level concurrency pool as standard Lambda functions. Concurrency slots are released during waits, so thousands of executions can wait without consuming concurrency. Learn more about AWS Lambda quotas.

You can test durable functions locally without AWS credentials using the durable execution SDK for your supported programming language. AWS SAM CLI also supports local invoke, callbacks, and durable execution management, making it straightforward to develop and debug before deploying. Learn more about testing durable functions.

AWS Lambda SnapStart can improve startup performance from several seconds to as low as sub-second for latency sensitive applications. SnapStart works by snapshotting your function's initialized memory (and disk) state and caching this snapshot for low-latency access. When your function is subsequently invoked, Lambda resumes execution environments from this pre-initialized snapshot instead of initializing them from scratch, improving startup latency. For resiliency, Lambda maintains cached copies of your snapshot and automatically applies software updates, such as runtime upgrades and security patches to them. Visit documentation to learn more.

Lambda SnapStart is a simple function level configuration that can be configured for new and existing functions by using Lambda API, the AWS Management Console, AWS Command Line Interface (CLI), AWS SDK, AWS Cloud Development Kit (CDK), AWS CloudFormation, and the AWS Serverless Application Model (SAM). When you configure Lambda SnapStart, every function version that is published thereafter benefits from the improved startup performance offered by Lambda SnapStart. To learn more about Lambda SnapStart, see the documentation.

Lambda SnapStart is a performance optimization that helps your functions to achieve faster start-up times by reducing the variable latency incurred during execution of one-time initialization code. While Lambda SnapStart reduces startup latency, it works as a best-effort optimization, and does not guarantee elimination of cold starts. If your application has strict latency requirements and requires double-digit millisecond startup times, we recommend you use PC.

Lambda SnapStart supports multiple runtimes, including Java 11 (and newer), Python 3.12 (and newer) and .NET 8 (and newer). Future versions of runtimes will be supported after they are released. For all runtimes supported by Lambda, see the Lambda runtimes documentation.

Yes. You can configure a Lambda SnapStart function to access resources in a virtual private cloud (VPC). For more information on how to configure your function with a VPC, see the Lambda documentation.

Yes, you will be charged for caching a snapshot over the period that your function version is active, for a minimum of 3 hours and per milli-second thereafter. The price depends on the amount of memory you allocate to your function. You are also charged each time Lambda resumes an execution environment by restoring your snapshot, with the price depending on the amount of memory you allocate to your function. To learn more about pricing for SnapStart, visit AWS Lambda Pricing.

SnapStart pricing does not apply to supported Java managed runtimes, which can only cache a snapshot for up to 14 days.

Provisioned Concurrency gives you greater control over the performance of your serverless applications. When enabled, Provisioned Concurrency keeps functions initialized and hyper-ready to respond in double-digit milliseconds.

You can configure concurrency on your function through the AWS Management Console, the Lambda API, the AWS CLI, and AWS CloudFormation. The simplest way to benefit from Provisioned Concurrency is by using AWS Auto Scaling. You can use Application Auto Scaling to configure schedules, or have Auto Scaling automatically adjust the level of Provisioned Concurrency in real time as demand changes. To learn more about Provisioned Concurrency, see the documentation.

Provisioned Concurrency adds a pricing dimension, of ‘Provisioned Concurrency’, for keeping functions initialized. When enabled, you pay for the amount of concurrency that you configure and for the period of time that you configure it. When your function executes while Provisioned Concurrency is configured on it, you also pay for Requests and execution Duration. To learn more about the pricing of Provisioned Concurrency, see AWS Lambda Pricing.

No. AWS Lambda is designed to run many instances of your functions in parallel. However, AWS Lambda has a default safety throttle, for the number of concurrent executions per account per region (visit here for info on default safety throttle limits). You can also control the maximum concurrent executions for individual AWS Lambda functions, which you can use to reserve a subset of your account concurrency limit for critical functions, or cap traffic rates to downstream resources.

If you wish to submit a request to increase the concurrent execution limit, you can use Service Quotas to request a limit increase request.

On exceeding the maximum concurrent executions limit, AWS Lambda functions being invoked synchronously will return a throttling error (429 error code). Lambda functions being invoked asynchronously can absorb reasonable bursts of traffic for approximately 15-30 minutes, after which incoming events will be rejected as throttled. In case the Lambda function is being invoked in response to Amazon S3 events, events rejected by AWS Lambda may be retained and retried by S3 for 24 hours. Events from Amazon Kinesis streams and Amazon DynamoDB streams are retried until the Lambda function succeeds or the data expires. Amazon Kinesis and Amazon DynamoDB Streams retain data for 24 hours.

The default maximum concurrent execution limit is applied at the account level. However, you can also set limits on individually functions as well (visit here for info on Reserved Concurrency).

Each synchronously invoked Lambda function can scale at a rate of up to 1000 concurrent executions every 10 seconds. While Lambda's scaling rate is suitable for most use cases, it is particularly ideal for those with predictable or unpredictable bursts of traffic. For example, SLA-bound data processing would require predictable yet rapid scaling to meet processing demand. Similarly, serving breaking news articles, or flash sales could drive unpredictable levels of traffic in a short period of time. Lambda's scaling rate can facilitate such use cases without additional configurations or tooling. Additionally, the concurrency scaling limit is a function-level limit, which means each function in your account scales independently of other functions.

On exceeding the retry policy for asynchronous invocations, you can configure a “dead letter queue” (DLQ) into which the event will be placed; in the absence of a configured DLQ the event may be rejected. On exceeding the retry policy for stream-based invocations, the data would have already expired and therefore rejected.

Lambda MicroVMs is a serverless compute primitive that combines VM-level isolation, near-instant launch and resume, and state persistence across interactions. Built on the same Firecracker virtualization powering 15 trillion+ monthly Lambda Function invocations, MicroVMs are purpose-built for workloads that execute user- or AI-generated code. Start a MicroVM, connect over HTTPS, and begin executing code without managing compute infrastructure.

Use Lambda MicroVMs when your workload needs an isolated compute environment that starts near-instantly, preserves state across interactions (up to 8 hours), or requires privileged operating system capabilities. Common use cases include interactive development environments, vulnerability scanning and security testing, data analytics platforms, CI/CD pipelines, AI coding assistants, and agent sandboxes. In each case, you can use Lambda MicroVMs to provision an isolated compute environment per user or task, with near-instant latency through MicroVMs’ snapshot-based startup. For more information, visit the Lambda MicroVMs developer guide.

If your application can be packaged as a container and run on Amazon Linux 2023, it can be used with Lambda MicroVMs. Lambda MicroVMs support up to 32 GB of memory and 16 vCPUs. As Lambda MicroVMs are run from pre-initialized snapshots, applications generating unique content during initialization may need to integrate with service-provided hooks for compatibility. For more information, visit the Lambda MicroVMs developer guide.

Each MicroVM runs on an isolated kernel, memory space, and disk state powered by Firecracker virtualization. AWS manages the underlying infrastructure, from network routing to isolation boundary enforcement.

For inbound networking, each MicroVM uses a dedicated URL and JWE-based authentication, enabling you to send each user’s traffic to their assigned MicroVM using HTTP/2, WebSockets, and gRPC. For outbound networking, MicroVMs provide connectivity to the public internet and to resources in your private Amazon VPC. For more information, visit the networking section in the Lambda MicroVMs developer guide.

When a MicroVM is suspended, its full memory and disk state is preserved for up to 8 hours and you are no longer charged for compute usage. Suspended MicroVMs can be resumed automatically or programmatically with near-instant speed through snapshotting. Use suspend and resume to retain session context across interactions, while reducing costs during idle periods. Some applications may need to integrate with service-provided hooks when resuming from snapshots, such as to re-establish network connections or refresh cached values. For more information, visit the Lambda MicroVMs developer guide.

Lambda MicroVMs are priced across three dimensions: compute (per-second, based on baseline and peak usage), snapshot operations and storage, and data transfer. You can provision for your baseline with the flexibility to scale vertically up to 4x peak when workloads demand it. Baseline charges apply while your MicroVM is running and usage exceeding the baseline is charged per active consumption. For more information, visit the AWS Lambda pricing page.

AWS Lambda MicroVMs are covered by the AWS Lambda Service Level Agreement, which provides a Monthly Uptime Percentage commitment of at least 99.5% for instance-level availability. For more information, visit the AWS Lambda Service Level Agreement.

You grant permissions to your Lambda function to access other resources using an IAM role. AWS Lambda assumes the role while executing your Lambda function, so you always retain full, secure control of exactly which AWS resources it can use. Visit Setting up AWS Lambda to learn more about roles.

When you configure an Amazon S3 bucket to send messages to an AWS Lambda function, a resource policy rule will be created that grants access. Visit the Lambda Developer Guide to learn more about resource policies and access controls for Lambda functions.

Access controls are managed through the Lambda function role. The role you assign to your Lambda function also determines which resource(s) AWS Lambda can poll on its behalf. Visit the Lambda Developer Guide to learn more.

You can enable Lambda functions to access resources in your VPC by specifying the subnet and security group as part of your function configuration. Lambda functions configured to access resources in a particular VPC will not have access to the internet as a default configuration. To grant internet to these functions, use internet gateways. By default, Lambda functions communicate with resources in a dual-stack VPC over IPv4. You can configure your functions to access resources in a dual-stack VPC over IPv6. For more details on Lambda functions configured with VPC, see Lambda Private Networking with VPC.

Code Signing for AWS Lambda offers trust and integrity controls that enable you to verify that only unaltered code from approved developers is deployed in your Lambda functions. You can use AWS Signer, a fully-managed code signing service, to digitally sign code artifacts and configure your Lambda functions to verify the signatures at deployment. Code Signing for AWS Lambda is currently only available for functions packaged as ZIP archives.

You can create digitally signed code artifacts using a Signing Profile through the AWS Signer console, the Signer API, SAM CLI or AWS CLI. To learn more, please see the documentation for AWS Signer.

AWS Lambda can perform the following signature checks at deployment:

• Corrupt signature - This occurs if the code artifact has been altered since signing.
• Mismatched signature - This occurs if the code artifact is signed by a signing profile that is not approved.
• Expired signature - This occurs if the signature is past the configured expiry date.
• Revoked signature - This occurs if the signing profile owner revokes the signing jobs.

To learn more, please see the AWS Lambda documentation.

There is no additional cost when using Code Signing for AWS Lambda. You pay the standard price for AWS Lambda. To learn more, please see Pricing.

To provide you a simplified and enhanced logging experience by default, AWS Lambda offers advanced logging controls such as the ability to natively capture Lambda function logs in JSON structured format, control the log level filtering of Lambda function logs without making any code changes, and customize the Amazon CloudWatch log group Lambda sends logs to.

You can capture Lambda function logs in JSON structured format without having to use your own logging libraries. JSON structured logs make it easier to search, filter, and analyze large volumes of log entries. You can control the log level filtering of Lambda function logs without making any code changes, which enables you to choose the required logging granularity level for Lambda functions without sifting through large volumes of logs when debugging and troubleshooting errors. You can also set which Amazon CloudWatch log group Lambda sends logs to, making it easier to aggregate logs from multiple functions within an application in one place. You can then apply security, governance, and retention policies to logs at the application level rather than individually to every function.

You can specify advanced logging controls for your Lambda functions using AWS Lambda API, AWS Lambda console, AWS CLI, AWS Serverless Application Model (SAM), and AWS CloudFormation. To learn more, visit the launch blog post for advanced logging controls or the Lambda Developer Guide.

Yes, you can use your own logging libraries to generate Lambda logs in JSON structured format. To ensure your logging libraries work seamlessly with Lambda’s native JSON structured logging capability, Lambda will not double-encode any logs generated by your function that are already JSON encoded. You can also use Powertools for AWS Lambda library to capture Lambda logs in JSON structured format.

There is no additional charge for using advanced logging controls on Lambda. You will continue to be charged for ingestion and storage of your Lambda logs by Amazon CloudWatch Logs. See CloudWatch pricing page for log pricing details.

CloudWatch Application Signals is an application performance monitoring (APM) solution which enables developers and operators to easily monitor the health and performance of serverless applications built with Lambda. Application Signals provides pre-built, standardized dashboards for critical application metrics, correlated traces, and interactions between Lambda functions and their dependencies — all without requiring manual instrumentation or code changes from developers.

CloudWatch Logs Live Tail is an interactive log streaming and analytics capability which provides real-time visibility into logs, making it easier to develop and troubleshoot Lambda functions. This allows developers to quickly test and validate code or configuration changes in real time, accelerating the author-test-deploy cycle (also known as the “inner dev loop”) when building applications with Lambda. The Live Tail experience also enables operators and DevOps teams to detect and debug failures and critical errors in Lambda function code more efficiently, reducing the mean time to recovery (MTTR) when troubleshooting Lambda function errors.

Lambda@Edge allows you to run code across AWS locations globally without provisioning or managing servers, responding to end-users at the lowest network latency. You just upload your Node.js or Python code to AWS Lambda and configure your function to be triggered in response to Amazon CloudFront requests (i.e., when a viewer request lands, when a request is forwarded to or received back from the origin, and right before responding back to the end-user). The code is then ready to execute across AWS locations globally when a request for content is received, and scales with the volume of CloudFront requests globally. Learn more in our documentation.

To use Lambda@Edge, you just upload your code to AWS Lambda and associate a function version to be triggered in response to Amazon CloudFront requests. Your code must satisfy the Lambda@Edge service limits. Lambda@Edge supports Node.js and Python for global invocation by CloudFront events at this time. Learn more in our documentation.

Lambda@Edge is optimized for latency-sensitive use cases where your end viewers are distributed globally. All the information you need to make a decision should be available at the CloudFront edge, within the function and the request. This means that use cases where you are looking to make decisions on how to serve content based on user characteristics (e.g., location, client device, etc.) can now be executed and served close to your users without having to be routed back to a centralized server.