I spoke at DevelopersIO 2026 Osaka with a presentation titled "Serverful Computing? AWS Lambda" #devio2026
This page has been translated by machine translation. View original
This is Iwata from the Retail App Co-Creation Division @ Osaka.
At Day 2 of DevelopersIO 2026 Osaka held on 2026/9/29, I gave a presentation on the theme "Serverful Computing? AWS Lambda".
In this blog, I will briefly introduce the content of my presentation.
History of Lambda
AWS Lambda is a service with a long history, announced at re:Invent 2014.
Looking at past documentation saved in WebArchive, it appears that at the time of release, the event-driven nature was emphasized, and there was no mention of "serverless" yet.
I recall that the word "serverless" started being used around 2017. By May 2017, the word "serverless" had already appeared in the Lambda Developer Guide.
And as of September 2026, AWS Lambda is described as a "serverless computing service."
So what does "serverless" mean? A commonly cited explanation is that it is an architecture that eliminates the need for users to be aware of the existence of servers. I think many cases define "serverless" as something that has the following three characteristics:
- Managed service
- Fully pay-as-you-go
- High availability
Lambda has these characteristics and can be said to be a service that hides the existence of servers from users. Let's look at some more concrete examples of these characteristics.
Lambda's Design Philosophy from a Sizing Perspective
The concept of sizing in Lambda Functions is simpler compared to EC2. The basics involve adjusting memory allocation, and CPU power and network bandwidth are determined proportionally to memory. It is simple precisely because there are fewer items to specify.
As another example, the design philosophy of Lambda as a service can also be seen from the design philosophy of Provisioned Concurrency. The details are explained in the blog below, but from the background of why Provisioned Concurrency was implemented — rather than Provisioned Capacity or Provisioned Rate — you can sense a consistent design philosophy of not wanting users to be aware of the existence of servers.
Disadvantages of Server Existence Being Hidden
While not having to be aware of servers is an advantage, there are also disadvantages as a trade-off. For example, you cannot specify the underlying hardware for the Lambda execution environment. Due to this characteristic, performance can vary depending on luck. Not limited to Lambda but also with Fargate, many people have published verification results regarding the phenomenon commonly known as the "CPU gacha."
Recent Various Updates Related to Lambda
Compared to before, recent Lambda has expanded in scope to allow usage that is more aware of the existence of servers.
Personally, I categorize the updates since re:Invent 2025 into the following four categories:
- durable functions
- Lambda Managed Instances
- Lambda MicroVMs
- Other minor feature additions/improvements
With these updates, users have progressed to be able to use Lambda while being more conscious of the lower OS-level layers as needed.
Lambda Managed Instances (LMI)
First, I will introduce Lambda Managed Instances (LMI). Many blogs have been written about this feature on DevIO as well.
List of articles on Lambda Managed Instances | DevelopersIO
Roughly speaking, it's the Lambda version of ECS Managed Instances. It is a feature that allows you to specify the instance type of the EC2 instance that serves as the foundation for the Lambda execution environment. It's interesting that you can specify a server even though it's serverless.
The details are explained in various ways in the article list above, but when using LMI, there is a possibility of falling into unexpected pitfalls if you don't write code with a stronger awareness of servers and the OS. Be sure to be aware of the differences in internal architecture. In this session, I mainly explained the following points.
Differences in Security Boundaries
With regular Lambda, the Firecracker MicroVM serves as the security boundary, but with LMI, there is no Firecracker layer. The EC2 instance serves as the security boundary, and the EC2 instance can be used exclusively by your own AWS account.
Differences in Concurrency Models
Attention must also be paid to the differences in concurrency models. With regular Lambda, one execution environment processes at most one request at a time. In contrast, with LMI, one execution environment processes multiple requests simultaneously.
By being aware of these differences, you can also adopt configurations unique to LMI, such as those introduced in the blog below.
Lambda MicroVMs
Next, I introduced Lambda MicroVMs.
This is a feature that allows you to start, stop, and resume MicroVMs using Firecracker's snapshot functionality. MicroVM images can be built based on Dockerfiles tailored to your own use case.
Although it bears the name Lambda, it is an entirely different thing from Lambda Functions. From the documentation and the AWS CLI command structure, it can be seen that Lambda MicroVMs are separate from Lambda Functions. It's like Lambda, which previously had Lambda Function as an only child, now has a younger sibling in the form of Lambda MicroVMs (could be a brother or sister).
Until now, simply saying "Lambda" often referred to Lambda Functions, but going forward this may require some attention.
As use cases, I introduced the content from the following blogs.
I anticipate that installing code-server in the MicroVM image would make it conveniently usable as a Cloud9 alternative for setting up hands-on environments, but this is unverified, so I would like to verify it in the future.
Other Updates
I also introduced the following as other updates that allow you to be more aware of OS-level layers.
Having more options is a good thing.
Summary
Lambda, the representative of "serverless," can be used without being aware of the existence of servers, but service updates have brought progress, enabling use cases that were not previously possible.
The fact that you don't need to bear responsibility for OS management and operations has remained consistently unchanged, but it has become possible to choose the level of server abstraction as needed. It can be said that Lambda continues to evolve not merely as an event-driven FaaS service, but as a service that allows you to choose the optimal computing environment suited to your workload. Will there be any updates at re:Invent 2026 in about two months? I look forward to continued progress from Lambda!
Presentation Materials
References
- [New AWS Service] AWS Lambda #reinvent | DevelopersIO
- Tried Running eBPF Programs on Lambda MicroVMs | DevelopersIO
- Tried Running GitHub Actions Self-Hosted Runners on Lambda MicroVMs | DevelopersIO
- Tried Raising Lambda Network Bandwidth to 3,000 Mbps via Service Quotas and Measured the Actual Results | DevelopersIO
- Tried Configuring Direct Read with Lambda S3 Files and Measured the Effect | DevelopersIO
- Tried Mounting Amazon S3 Files from Lambda and Verified the Specifications | DevelopersIO
- Let Me Tell You About Lambda's Internal Architecture! A serverless journey: AWS Lambda under the hood #SVS405 #reinvent | DevelopersIO
- Choosing ECS Execution Infrastructure with Benchmarks by Fargate CPU Architecture and Generation - Hatena Developer Blog
- Differences in Fargate CPU Performance - Speaker Deck
- Taking a Closer Look at OS Information in AWS Lambda ~ Verifying Lambda Instance Gacha ~ - misc.tech.notes
