DevelopersIO 2026 Osakaで「サーバーフルコンピューティング？AWS Lambda」というタイトルで登壇しました #devio2026
リテールアプリ共創部@大阪の岩田です。
2026/9/29に開催されたDevelopersIO 2026 OsakaのDay2にて「サーバーフルコンピューティング？AWS Lambda」というテーマで登壇させて頂きました。
このブログでは登壇内容について簡単に紹介します。
Lambdaの歴史
AWS Lambdaはre:Invent2014で発表された歴史のあるサービスです。
WebArchiveに保存されていた過去のドキュメントを見る限り、リリース当初はイベントドリブンである点がアピールされており、まだ「サーバーレス」といった説明は無かったようです。
「サーバーレス」という言葉が使われ始めたのは2017年頃だったと記憶しています。2017年5月の段階ではLambdaのデベロッパーガイドにも「サーバーレス」という単語が登場しています。
そして2026年9月現在ではAWS Lambdaは「サーバーレスコンピューティングサービス」であると説明されています。
では「サーバーレス」とはどういう意味でしょうか？よく言われるのが、利用者にサーバーの存在を意識させないアーキテクチャであるということです。以下3つの特性を備えたもの、それを「サーバーレス」であると定義するケースが多いと思います。
- マネージドサービス
- 完全従量課金
- 高可用性
Lambdaはこれらの特性を備えており、利用者からサーバーの存在を隠蔽するサービスといえます。この特性についてもう少し具体例を見ていきます。
サイジングから考えるLambdaの設計思想
Lambda Functionにおけるサイジングの考え方はEC2と比較するとシンプルです。メモリの割り当てを調整するのが基本で、CPUパワーやNW帯域はメモリに比例して決まります。指定できる項目が少ないがゆえにシンプルです。
別の例としてProvisioned Concurrencyの設計思想からもLambdaというサービスの設計思想が伺えます。詳細は以下のブログで解説しているのですが、Provisioned CapacityでもProvisioned Rateでもなく、Provisioned Concurrencyという機能が実装された背景から、利用者にサーバーの存在を意識させたくないという一貫した設計思想が感じられます。
サーバーの存在が隠蔽されていることのデメリット
サーバーの存在を意識しなくて良いというのはメリットですが、トレードオフとしてデメリットも存在します。例えばですが、Lambda実行環境の基盤となるハードウェアは指定できません。この特性によって、運次第でパフォーマンスが変わり得ます。Lambdaに限らずFargateでも同様ですが、いわゆるCPUガチャと呼ばれる現象については多くの方が検証結果を公開されています。
Lambdaに関する直近の各種アップデート
以前と比べると、最近のLambdaはサーバーの存在を意識したような使い方もできるように幅が広がってきています。
個人的にはre:Invent2025以後のアップデートを以下の4つに分類しています。
- durable functions
- Lambda Managed Instances
- Lambda MicroVMs
- その他の細かな機能追加/改善
これらのアップデートによって、ユーザーは必要に応じてよりOS寄りの低レイヤを意識してLambdaが利用できるように進歩しています。
Lambda Managed Instances(LMI)
まずLambda Managed Instances(LMI)について紹介します。この機能についてはDevIOでも多数のブログが執筆されています。
Lambda Managed Instances の記事一覧 | DevelopersIO
ざっくりいうとECS マネージドインスタンスのLambda版ですね。Lambda実行環境の基盤となるEC2インスタンスのインスタンスタイプが指定できる機能です。サーバーレスなのにサーバーが指定できるというのが面白いですね。
詳細は上記の記事一覧を見てもらうと色々と解説されているのですが、LMIを利用する場合はよりサーバーやOSの存在を意識してコードを書かないと、思わぬ落とし穴にハマる可能性があります。内部的なアーキテクチャの違いをしっかり意識しましょう。このセッションでは主に以下の点について解説しました。
セキュリティ境界の違い
通常のLambdaはFirecrackerのMicroVMがセキュリティ境界となりますが、LMIにおいてはFirecrackerのレイヤは存在しません。EC2インスタンスがセキュリティ境界となり、EC2インスタンスは自AWSアカウントが占有利用できます。
同時実行モデルの違い
同時実行モデルの違いにも注意が必要です。通常のLambdaは1つの実行環境が同時に処理するリクエストは1つまでです。それに対してLMIでは1つの実行環境が複数のリクエストを同時に処理します。
これらの違いを意識することで以下ブログで紹介したようなLMIならではの構成をとることもできます。
Lambda MicroVMs
次に紹介したのがLambda MicroVMsです。
こちらはFirecrackerのスナップショット機能を使ってMicroVMを起動/停止/再開できる機能です。MicroVMのイメージはDockerfileをもとに自身のユースケースに合わせたイメージがビルドできるようになっています。
Lambdaの名を冠してはいますが、Lambda Functionとは全くの別物です。ドキュメントの記述やAWS CLIのコマンド体系からもLambda MicroVMsはLambda Functionとは別ものであることが伺えます。これまでLambda Functionが一人っ子だったLambdaファミリーにLambda MicroVMsという弟（妹かも）が生まれたようなイメージです。
これまで単に「Lambda」というとLambda Functionのことを指していることが多かったのですが、今後は注意が必要かもしれませんね。
ユースケースとして以下ブログの内容を紹介しました。
MicroVMのイメージにcode-serverを導入しておけばCloud9の代替としてハンズオン用の環境手配に便利に使えそうと予想しているのですが、ここは未検証なので今後検証していきたいです。
その他のアップデート
その他にもOS寄りのレイヤーを意識できるようになったアップデートとして以下を紹介しました。
選択肢が増えるというのは良いことです。
まとめ
「サーバーレス」の代表格としてサーバーの存在を意識せずに利用できるLambdaですが、サービスのアップデートによって以前はできなかったような使い方もできるように進歩してきました。
OSの管理・運用責任を負わなくて良い点は一貫して変わっていませんが、必要に応じてサーバー抽象化のレベルを選択できるようになっています。単なるイベントドリブンなFaaSサービスではなく、ワークロードに合わせた最適なコンピューティング環境が選べるサービスとして進化を続けていると言えるでしょう。約2ヶ月後のre:Invent2026でも何かアップデートがあるのでしょうか？今後もLambdaの進歩に期待したいですね！
登壇資料
参考
- [AWS新サービス] AWS Lambda #reinvent | DevelopersIO
- Lambda MicroVMsでeBPFプログラムを実行してみた | DevelopersIO
- GitHub Actionsのセルフホステッド ランナーをLambda MicroVMs上で実行してみた | DevelopersIO
- Lambda のネットワーク帯域幅を Service Quotas で 3,000 Mbps に引き上げて実測してみた | DevelopersIO
- Lambda の S3 Files でダイレクトリードを設定できるようになったので効果を測ってみた | DevelopersIO
- Amazon S3 FilesをLambdaからマウントして仕様検証してみた | DevelopersIO
- Lambdaの内部アーキテクチャ教えます！A serverless journey: AWS Lambda under the hood #SVS405 #reinvent | DevelopersIO
- Fargate の CPU アーキテクチャと世代別のベンチマークで ECS の実行基盤を選ぶ - Hatena Developer Blog
- FargateのCPU性能の違い - Speaker Deck
- AWS LambdaのOS情報を色々見てみる 〜Lambdaのインスタンスガチャを検証する〜 - misc.tech.notes
