A FinOps Guide to Comparing Containers and Serverless Functions for Compute

In the evolving landscape of cloud computing, you face a critical decision when optimizing compute resources: Containers or Serverless Functions? However, this isn’t an either-or proposition, in some cases you can use both. The key to effective cost management and operational efficiency lies in understanding that both technologies have their place in a well-architected cloud environment. The choice depends on your specific use case, workload characteristics, and overall application architecture. These factors will help you determine the right compute service for your needs.

What are Containers?

Containers, in cloud computing, are image files that contain all your application files to run software. They excel in scenarios needing consistent, reproducible environments, efficient resource utilization, and simplified deployment across different environments. Containers also provide a high degree of control over the runtime environment, which can be crucial for applications with specific dependencies or configuration requirements. For this blog we will focus on Amazon Elastic Container Service (Amazon ECS).

When to use Amazon ECS?

Key scenarios for Amazon ECS are:

Long-running processes
Applications that need full control over runtime and environment
Workloads with steady, predictable traffic

What is Serverless?

A Serverless architecture is a cloud computing approach that allows developers to build and run applications without managing the underlying infrastructure. Serverless services include Amazon Sagemaker Servereless and Amazon DynamoDB. For this blog we will focus on Serverless compute using AWS Lambda Functions. AWS Lambda’s pricing model, based on memory allocation and execution time, can lead to significant cost savings for dynamic workloads.

When to use AWS Lambda?

Key scenarios for AWS Lambda are:

Event-driven, stateless workloads
Highly variable or unpredictable traffic patterns
Short-running processes (< 15 minutes)
When you want to minimize operational overhead

How to compare AWS Lambda and Amazon ECS?

To evaluate when the AWS Lambda or Amazon ECS is best for your workload, you’ll want to look at the following four components.

1. Lifecycle and Load Profile

Amazon ECS

When evaluating Amazon ECS for your application, consider their always-on nature and ability to handle multiple sequential requests without restarting. This persistent runtime makes Amazon ECS ideal if your workload has steady, predictable traffic patterns where consistent performance is critical. Amazon ECS excels in scenarios requiring long-running processes, significant memory requirements, or when you need to maintain state between requests. However, be prepared to manage scaling configurations and recognize that you’ll pay for resources even during idle periods. Choose Amazon ECS when your application demands stable response times, has consistent traffic, or requires specific runtime environments that benefit from persistent initialization.

AWS Lambda

To take advantage of AWS Lambda, assess whether your workload aligns with an on-demand execution model. Function architectures are more appropriate for variable or dynamic traffic patterns, event-driven processing, and when cost optimization is paramount since you only pay for actual execution time. Consider the impact of potential cold starts on latency-sensitive applications, execution time limits (typically 15 minutes or less), and memory constraints of up to 10GB. Choose AWS Lambda when you want to minimize operational overhead, need automatic scaling without capacity planning, have unpredictable traffic patterns, or want to optimize costs for infrequently used services where paying for idle capacity doesn’t make economic sense.

2. Comparing costs of AWS Lambda and Amazon ECS

When comparing the costs of Amazon ECS and AWS Lambda, it’s essential to consider real-world deployment scenarios rather than simple one-to-one comparisons. Let’s explore this through the lens of a typical microservices application running five services, each handling approximately 100,000 requests daily.

Container Deployment Options and Costs

With Amazon ECS on Amazon Elastic Compute Cloud (Amazon EC2), you might run your services on two t3.medium instances costing approximately $60 per month ($0.0416/hour per instance). What’s crucial to understand is that these instances can efficiently host multiple Amazon ECS—typically 8-12 Amazon ECS per t3.medium instance, depending on your workload characteristics. This means all five microservices could potentially run on these instances, bringing your total infrastructure costs to around $70 monthly (including data transfer), or approximately $0.0000047 per request across all services. AWS Cost and Usage Reports (CUR) calculates and distributes your shared EC2 instance cost at the ECS task level, so you can better chargeback the cost to your business unit. Read about the Split Cost Allocation Data feature in this blog Improve cost visibility of Amazon ECS and AWS Batch with AWS Split Cost Allocation Data.

Amazon ECS on AWS Fargate offers a different cost model, charging per vCPU ($0.04048/hour) and memory ($0.004445/hour per GB). For a typical configuration of 0.5 vCPU and 1GB memory per service, you’re looking at about $90 monthly for all five services. While this might seem higher than EC2, remember that Fargate eliminates the need for cluster management and provides more granular scaling capabilities.

Function Costs and Considerations

Running these same services on AWS Lambda presents a different cost structure. Each service would incur request charges ($0.20 per million requests) and compute costs based on memory allocation and execution duration. For our example, with 256MB memory allocation and 500ms average execution time, you’re looking at approximately $34.50 monthly for all five services. However, these costs can scale linearly with traffic, unlike container deployments where costs remain relatively stable.

Fig 1. Monthly Cost Comparison of Deployment Options

Considerations when comparing costs of Functions and Amazon ECS

Development and testing environments present unique opportunities for cost optimization across both container and function architectures. Modern container orchestration platforms like Amazon ECS offer sophisticated scaling capabilities, allowing Amazon ECS to scale to zero during off-hours through capacity providers or scheduled scaling. For an 8-hour workday, two t3.medium instances running only during business hours would cost approximately $13.31/month, while Fargate provides more granular scaling by charging only for task runtime. Similarly, Lambda’s pay-per-use model means costs typically range from $6-7/month for development workloads.

Both approaches can be highly cost-effective when implementing automated environment management, scheduling resources around working hours, and right-sizing for development needs. The choice between Amazon ECS and AWS Lambda for development environments often comes down to team workflow, testing requirements, and existing tooling rather than cost considerations alone.

The decision shifts for production workloads with high, consistent utilization. Consider a high-traffic application: Container costs with AWS Savings Plans: $730/year per instance (1-year commitment), offering savings up to 50% over on-demand pricing. Function costs for consistent, high-volume traffic might exceed these figures due to per-invocation charging. For applications with steady, high-volume traffic running 24/7, container deployments typically prove more cost-effective than AWS Lambda, as the per-invocation costs of AWS Lambda can exceed the fixed infrastructure costs of well-utilized Amazon ECS.

3. Portability

Portability can often factor into the decision-making process. Amazon ECS offer a higher degree of portability, allowing applications to be moved between cloud providers or to on-premises environments with relative ease. This flexibility can be appealing for organizations looking to maintain flexibility in their cloud strategy or those required to operate in multi-cloud environments. AWS Lambda, while more tightly coupled to the cloud provider’s ecosystem, can achieve portability through careful architecture design.

While portability can be a relevant factor, the cost of migrating between compute options should also be considered, as porting to and from AWS Lambda can cost more in engineering/dev time than moving container-based workloads.

4. Optimization Techniques for both AWS Lambda and Amazon ECS

These compute resources have some overlap when it comes to optimization.

Amazon Graviton
- AWS Lambda Graviton Optimization:
  AWS Lambda supports the use of Graviton2 processors, which can provide up to 10% better price-performance compared to x86-based instances. When creating a new AWS Lambda function, select the “ARM64” architecture.
- Amazon ECS Graviton Optimization:
  For containerized workloads running on Amazon ECS or Amazon EKS, you can leverage Graviton2-based Amazon EC2 instances to benefit from the improved price-performance of the Graviton2 processor. Select Graviton2-based instance types, such as the m6g or c6g families.
Memory
- AWS Lambda Memory Optimization:
  For AWS Lambda tasks to find the optimal balance between performance and cost. Start with the minimum memory required and gradually increase it until you achieve the desired performance, continuously monitoring the cost per invocation or task execution. You can also use Lambda Power Tune, an open source tool provided by AWS, to help you visualize and fine-tune your configuration.
- Amazon ECS Memory Optimization:
  Optimize the memory allocation for your Containers by carefully analyzing the actual memory usage patterns. Use tools like Amazon ECS Exec to connect to your running Containers and assess the memory utilization. Adjust the memory limits and requests in your Container definitions to match the real-world requirements of your applications, avoiding over-provisioning, and minimizing unnecessary costs.
Logging
- AWS Lambda Logging Optimization:
  With Lambda, the cost of logging scales with the amount of data logged. Review your Lambda function logs and identify opportunities to reduce unnecessary logging, such as limiting the number of log statements, log levels, and the amount of data logged per event. Leverage AWS CloudWatch Logs Insights to analyze your logs and identify cost optimization opportunities.
- Amazon ECS Logging Optimization:
  Optimize your Container logging by configuring log drivers that minimize costs. For example, use the awslogs or jsonfile log drivers instead of the default docker log driver, which can be more expensive. Additionally, review your Container logs regularly and remove any unnecessary or redundant logging statements to keep your costs in check.
Compute Savings Plans:
- Both Lambda and ECS can leverage Compute Savings Plans. By committing to a consistent level of usage over a 1-year or 3-year term, you can save on your resources.
Spot Instances for Amazon ECS
- For containerized workloads running on Amazon ECS or Amazon EKS, you can leverage Spot instances to achieve significant cost savings. Spot instances can provide up to 90% discounts compared to on-demand pricing, but come with the trade-off of potential workload interruptions. FinOps teams should carefully analyze their workload characteristics and tolerance for interruptions to determine the appropriate use of Spot instances, balancing cost savings with operational resilience.

Making the Decision Amazon ECS vs AWS Lambda

Rather than viewing it as Amazon ECS vs AWS Lambda, we recommend taking a data-driven approach to selecting the right compute option:

Start by understanding your workload characteristics, operational requirements, and traffic patterns
Experiment with both Amazon ECS and AWS Lambda to gather real-world performance and cost data
Leverage the strengths of each technology where it makes the most sense for your application
Be willing to evolve your architecture over time as needs change

Conclusions

Ultimately, the decision between Containers and Serverless Functions – or the implementation of both – should be driven by a thorough understanding of workload characteristics, cost implications, and operational requirements. As FinOps professionals, you should work closely with development and operations teams to analyze usage patterns, model costs under different scenarios, and consider factors like development velocity, operational overhead, and long-term maintainability. By leveraging the strengths of both Containers and Serverless technologies, you can build flexible, cost-effective cloud architectures that adapt to changing business needs while optimizing resource utilization and expenditure.

To learn more about Amazon ECS and Functions on AWS, check out the following resources:

AWS Cloud Financial Management