AWS Lambda 90分実行の衝撃：LMIで変わるサーバーレスの限界と設計思想

深夜の障害対応で、Lambdaの15分タイムアウトに泣かされた経験は、多くのエンジニアが一度は通る道ではないだろうか。重いデータ変換処理や、外部APIを叩きまくるバッチ処理が、あと少しで終わるというところで『Task timed out』の無慈悲なログと共に強制終了される。あの絶望感は、まさにデッドロックに陥ったプロセスを眺める時の徒労感に似ている。2026年9月、AWS Lambdaが最大90分（5,400秒）の実行時間をサポートしたというニュースは、この長年の制約に対する一つの回答だ。しかし、これは単なる『上限緩和』という甘い言葉で片付けてはいけない。このアップデートは、Lambdaの根幹である『オンデマンド・ゼロスケール』という哲学を一部放棄し、よりインフラに近い『Lambda Managed Instances (LMI)』という領域へ踏み込むことを意味しているからだ。

まず、この90分という数値が適用される条件を冷静に整理する必要がある。同期呼び出しは依然として15分のままであり、API Gatewayの背後で90分待たせるようなアーキテクチャはそもそも設計思想として誤りである。対象となるのは、非同期呼び出し、あるいはSQSやKinesisといったイベントソースマッピング（ESM）経由の実行のみだ。そして何より重要なのが、LMIという実行モードの採用である。LMIは、Lambdaの皮を被ったEC2インスタンスと言っても過言ではない。プロビジョニングやパッチ適用はAWSが管理するが、メモリは最低2,048MBが必須となり、何より『ゼロスケールしない』という特性を持つ。これは、使われない時間帯でもインスタンスが起動し続け、コストを垂れ流すリスクを孕んでいる。我々エンジニアは、この『利便性』と『コスト』のトレードオフを、これまで以上にシビアに計算しなければならない。

以下の表は、今回のアップデートにおける呼び出し方法ごとのタイムアウト制限をまとめたものだ。この構造を理解せずに導入すれば、本番環境で予期せぬタイムアウトエラーに遭遇し、深夜の呼び出しを受けることになるだろう。

この表が示す通り、LMIは万能ではない。特に、これまでLambdaの最大の武器であった『使った分だけ払う』というコストモデルが崩れる点は、経営層やコスト管理担当者への説明において最大の障壁となるはずだ。EC2料金に管理費15%が上乗せされるこのモデルは、常時稼働するワークロードには適しているが、スパイク性の高い処理には不向きである。我々が直面しているのは、単なる機能追加ではなく、サーバーレスアーキテクチャの『再定義』なのだ。

今回のアップデートで最も技術的興奮を覚えるのは、Durable Functionsとの組み合わせだ。これまで、Durable Functionsは『実行状態をチェックポイントとして永続化し、複数回のInvocationにまたがってワークフローを完走させる』という強力な武器を持っていた。しかし、1ステップあたりの処理時間が15分に制限されていたため、重いデータ処理をステップ内に詰め込むには、細切れの分割が必要だった。これが90分に伸びることで、ステップの粒度を大幅に粗くできる。これは、スパゲッティコードのように複雑に分割されていたワークフローを、より直感的で保守性の高いコードへとリファクタリングできる可能性を秘めている。

検証を通じて明らかになったのは、LMI環境下での『ゾンビプロセス』の懸念だ。LMIはタイムアウトが発生しても、即座にプロセスをKillするわけではない。呼び出し元へのエラー応答と、実行中のコードの継続が非同期に発生する。もしDurable Functionsの設計で、タイムアウトを単なる『区切り』として利用しようとすれば、古いInvocationと新しいInvocationが競合し、チェックポイントの整合性を破壊するリスクがある。だからこそ、検証で示されたように『context.wait()』を用いて明示的にInvocationを終了させる設計が不可欠となる。これは、分散システムにおける『冪等性』と『状態管理』の重要性を改めて我々に突きつけている。

また、長時間実行に伴うネットワークや接続管理の考慮も忘れてはならない。15分であれば無視できたNAT Gatewayのアイドルタイムアウト（350秒）や、DBのコネクション切断、DNSのTTLといった問題が、90分という時間軸では確実に顕在化する。これらは、単にLambdaのタイムアウト値を5400に変更すれば解決するような甘い話ではない。アプリケーションコード側で、コネクションの再確立やリトライ戦略をより堅牢に実装する必要がある。特に非同期呼び出しのリトライ設定は、15分時代とは比較にならないほど慎重に設計しなければならない。失敗した90分の処理が、デフォルト設定で安易にリトライされれば、コストとリソースの無駄遣いどころか、下流システムへの過負荷という二次災害を引き起こすだろう。

結局のところ、この90分という猶予は、我々エンジニアに『より高度な設計能力』を要求している。インフラの制約が緩和されたからといって、コードの品質が低ければ、それは単に『より長く動くバグ』を生み出すだけだ。我々は、この新しい武器を手に、どのようなアーキテクチャを描くべきか。サーバーレスという抽象化された世界で、あえてLMIという『インスタンスの匂い』がする領域に踏み込む覚悟はあるか。そして、そのコストを正当化できるだけのビジネス価値を、我々のコードは生み出せているだろうか。このアップデートは、単なる機能拡張ではなく、我々エンジニアの設計思想に対する『問い』そのものなのである。