2025年 AWS re:Invent で AWS Lambda の実行基盤にAmazon EC2 を使うAWS Lambda Managed Instanceがリリースされました。
AWS Lambda Managed Instance
AWS Lambda は2014年のリリース当初、その実行基盤にはEC2が使われていましたが、コスト最適化やコールドスタートの最適化等を求めAWS内部では専用実行基盤へと移行がなされています。一方EC2ももちろん進化を継続し様々なコンピュートオプションやSavins Plan等様々な料金プランが提供されています。
CPU 処理能力に見る Lambda とEC2 のコスト
Lambda は処理にかかった時間のみCPUとメモリに対する課金が行われるため非常に安価にコンピュート処理を実現できます。一方アイドル時間には課金がされないことが大きめメリットであり、多くの場合非同期処理、イベント処理などはLambdaを使うとシステム全体としてはコスト効率が良くなります。
一方抽象化されたサーバレス基盤はEC2と比べ同じCPU処理能力あたりの単価は高額になります。したがって定常的に処理が行われるような場合、EC2で処理を行った方が安くなる傾向があります。（どれほどCPUを利用し続けるかに依存します）
AWS Lambda Managed Instance のメリット・デメリット
それを踏まえたうえでAWS Lambda Managed Instance のメリット・デメリットを整理すると以下の様になります。
メリット：
EC2に対するReserved Instance や Savings Plan という割引オプションが適応される。同じCPU処理量であればコスト削減が期待できる。
Lambda ではCPUアークテクチャはIntel か ARM しか指定できないが、個別CPUファミリーを指定できる。
EC2に展開されるLambda実行環境（OS、ミドルウェア）のメインテナンスはAWSにより行われるため、通常のEC2より運用性が向上する。
デメリット：
コンピュートリソースを専有するためアイドル時間も課金が継続する。
確保済EC2リソースを越える水平スケーリングはEC2に依存するため標準Lambdaより遅い
EC2インスタンスタイプは限定されており料金は15%の管理費用が上乗せされる。
という整理になります。
さっそくやってみる
1. IAM ロールの準備
まずLambdaがEC2を管理するためのIAMロールを準備します。 AWSLambdaManagedEC2ResourceOperatorというインラインポリシーが準備されていますのでそちらをアタッチしておきます。
2. Capacity Provider の作成
Lambdaのマネージメントコンソール、左ペインから Capacity Providerをクリックして Create Capacity Provider をクリックします。
EC2を起動するネットワークを指定します。
先ほど作成したIAMロールを指定します。
起動したいインスタンスタイプを指定します。何も指定せずにCPUアーキテクチャだけを指定しておくと結構大きなインスタンス(xlarge等)が起動しますので、必ず指定したほうがよさそうです。すべてのEC2インスタンスが利用できるわけではなく以下に一覧があります。なお安価なtシリーズは利用できず、他のインスタンスファミリーもlarge以上が必要です。
処理量に応じてEC2インスタンスをスケールさせるかどうか指定することが可能です。Maximum vCPU countは空欄にしておけば必要な分だけスケールしますが、その反面コストコントロールが難しくなりますので、ここは運用に求められる要件に応じて設定を行います。
3. 関数の作成
Capacity Providerの作成が完了すると、関数を作成できます。
通常の関数作成ではなくCapacity Providerの画面から行います。
関数が作成されるとEC2の起動が開始します。
あとはいつも通りLambda関数として使えます。