Serverless computing allows you to build and run applications and services without managing servers. Modern applications are increasingly built with a serverless-first strategy, prioritizing the adoption of serverless services.
Subtitles are available in English, French and Spanish. Click here to get the full masterclass.
How to identify?
AWS developed serverless services for all three layers of your stack:
Compute: Lambda, Fargate
Application Integration: EventBridge, Step functions, SQS, SNS, API Gateway, Appsync
Data Store: S3, EFS, DynamoDB, RDS Proxy, and following serverless DB/option: Aurora, Redshift, Neptune, OpenSearch, ElastiCache
Example 1: Lambda VS EC2
If you use EC2 instances, you are probably not always using 100% of the compute capacity. Many customers only use 10–20% of the available capacity at any given time. This average is also affected by high availability and disaster recovery requirements, which often leave servers idle while waiting for failover traffic.
In the on-demand AWS Lambda compute model, you are charged based on the number of requests and the execution time of your code. This can be more cost-effective than running servers 24/7.
AWS Lambda is ideal for event-driven, variable workloads where you want minimal operational overhead and cost-efficiency for intermittent usage.
Amazon EC2 offers the most control and flexibility, making it suitable for consistent high-demand workloads or legacy applications requiring specific configurations.
Example 2: ElastiCache Serverless
Feature | Serverless caching | Self-designed clusters |
Pricing model | Pay-per-use, based on data stored and requests. | Pay-per-hour, based on cache node usage. |
Cache setup | Create a cache with just a name in under a minute. | Provides fine-grained control over cache cluster design. |
Supported ElastiCache version | Valkey 7.2 and higher, Redis OSS version 7.1 and higher, Memcached 1.6.21 and higher | Valkey 7.2 and higher, Redis OSS version 4.0 and higher, Memcached 1.4 and higher |
Multi-AZ | Data is replicated asynchronously across multiple AZs for higher availability and improved read latency. | Provides an option to design the cluster in a single AZ or across multiple AZs. |
Encryption in transit & at rest | Always enabled. | Option to enable or disable. |
Global Data Store | Not supported | Supported |
Data Tiering | Not supported | Supported |
Choose serverless caching if:
You are creating a cache for new or unpredictable workloads.
You have unpredictable application traffic.
You want the easiest way to get started with a cache.
Choose to design your own ElastiCache cluster if:
You are already running ElastiCache Serverless and want finer-grained control over node type, number of nodes, and placement.
You expect predictable application traffic and want control over performance, availability, and cost.
You can forecast your capacity requirements to control costs.
How to fix?
Going serverless on AWS can significantly optimize costs by eliminating the need to manage and pay for idle server capacity.
Build your architecture with a serverless-first strategy.
Predict your workload’s usage and traffic.
Update your existing infrastructure to leverage serverless services.
If resources are provisioned automatically via IaC (such as CloudFormation or Terraform), update the corresponding code to reflect the changes.