How do I reduce Lambda costs through architecture migration, pricing models, and alternative compute options?

Resolution

Understand Lambda pricing components

Lambda pricing consists of the following components:

• Lambda charges for requests by the million.
• Lambda charges for the duration per millisecond based on the amount of allocated memory. Arm architecture for AWS Graviton2 processors offers savings compared with x86_64.
• Provisioned concurrency costs are optional charges to keep functions initialized and ready to respond.
• AWS bills you for the initialization (INIT) phase duration for on-demand invocations.
• Lambda Managed Instances uses Amazon Elastic Compute Cloud (Amazon EC2) pricing models to reduce costs.
• Lambda charges for durable functions operations by the million, plus data storage charges.

For more information, see Lambda pricing.

Note: The Lambda free tier includes 1 million requests and 400,000 GB-seconds of compute each month. The Compute Savings Plans support Lambda usages for a percentage of savings on duration and provisioned concurrency charges.

Migrate from x86_64 to Arm architecture

When you migrate Lambda functions from x86_64 to Arm architecture, you can reduce duration charges.

To migrate your architecture, take the following actions:

• Confirm that your runtime is compatible. Python, Node.js, Java, .NET, and Ruby runtimes work on both architectures without code changes.
• Rebuild native dependencies or compiled binaries for the Arm64 target.
• If you use container images, then update your base image to an Arm64.
• Change the function's architecture setting to arm64 on the Lambda console, AWS Command Line Interface (AWS CLI), or infrastructure-as-code template.
• Test the function with production capable workloads to check the performance and compatibility.
• After the migration, monitor Amazon CloudWatch usage metrics to confirm that the function works as expected.
  Note: For compiled languages, such as Go or Rust, you must cross-compile your binary for the linux/arm64 target.

For more information, see Selecting and configuring an instruction set architecture for your Lambda function.

Right-size memory configuration

Lambda allocates CPU power proportional to memory. When you over-provision memory, you increase costs. When you under-provision memory, execution times are longer and you potentially incur higher costs.

To right-size your memory, take the following actions:

• Use the Lambda Power Tuning tool to analyze your function's performance at different memory settings. For more information, see aws-lambda-power-tuning on the GitHub website.
• Identify the memory configuration that provides a balance of cost and performance.
• Update your function's memory setting to the optimized value.
  Note: If you increase memory beyond the point where your function is CPU bound, then resources degrade. Use Power Tuning to view the inflection point.

For more information, see How do memory and computing power affect AWS Lambda cost?

Use Lambda Managed Instances for high-traffic functions

For functions with predictable, high-traffic workloads, use Lambda Managed Instances to run functions on Amazon EC2 instances. This approach maintains Lambda's operational simplicity and supports EC2 Savings Plans and Reserved Instances for a discount over on-demand pricing.

It's a best practice to use Lambda Managed Instances when your function has steady-state, predictable traffic and you require EC2 commitment-based pricing discounts. Also, use Lambda Managed Instances when you require up to 32 GB of memory.

To use Lambda Managed Instances, take the following actions:

• Create a capacity provider for your function, or use infrastructure-as-code.
• Select the EC2 instance type that matches your workload requirements.
• Configure scaling parameters for minimum and maximum instances.
• Apply existing EC2 Savings Plans or purchase Reserved Instances for cost savings.

Use Lambda durable functions for long-running workflows

For multi-step workflows that include wait times or external dependencies, use Lambda durable functions. Durable functions incur no compute charges during wait periods and can suspend execution for up to one year.

Create Lambda durable functions when your workflow has natural breaks between processing steps. Also, use durable functions to avoid AWS Step Functions orchestration overhead for basic workflows when your workflow includes waits for external events.

When you use durable functions, take the following actions:

• Use steps and waits primitives in your handler code to define checkpoints.
• Deploy and test the function with your workflow.
  Note: Compare durable function pricing with Step Functions pricing for your specific workflow volume.

Choose an alternative compute service for workloads that exceed Lambda quotas

Lambda has a maximum execution timeout of 15 minutes. If your workload requires continuous compute beyond this quota without natural checkpoints, then use Step Functions or AWS Batch.

Step Functions

Use Step Functions with Lambda in the following scenarios:

• You can break your process into individual steps.
• Each step completes within 15 minutes. 
• You want to maintain serverless architecture and pay-per-use pricing.
• You require built-in error handling and retry logic.
• Use Step Functions to run an AWS Batch job. Use AWS Batch when you have batch processing jobs that require dynamic resource allocation or job dependencies and scheduling.
• Use Step Functions with AWS Batch when you require integration with EC2 Spot Instances for additional cost savings.

Fargate

Use AWS Fargate instead of Lambda in the following scenarios:

• Your process is monolithic and difficult to break into smaller steps
• Your workload runs on a predictable schedule. 
• You require execution times beyond 15 minutes without modification.
• You want to minimize the effort to refactor existing code. 

To migrate to Fargate, take the following actions:

• Use Docker to containerize your application.
• Push the container image to Amazon Elastic Container Registry (Amazon ECR).
• Create an Amazon Elastic Container Service (Amazon ECS) task definition that specifies your container configuration.
• Create an Amazon ECS cluster with the Fargate launch type.
• Use Amazon EventBridge to configure a schedule to run tasks at specified intervals.
• Set up CloudWatch Logs to monitor usage.

Note: It's a best practice to evaluate the total cost of ownership when you choose between Lambda and other compute services. Include development effort, operational overhead, and compute charges in your total cost of ownership evaluation.

Related information

Optimizing your AWS Lambda costs – Part 1

Optimizing your AWS Lambda costs – Part 2