AWS Lambdaが90分制限へ緩和！サーバーレス設計の常識を覆す開発現場の選択肢

• 事実と背景：AWS Lambda Managed Instancesのタイムアウト制限が従来の15分から90分へと6倍に大幅緩和された。
• 技術的変革：長時間実行が可能になり、Graviton5対応やコールドスタート90ms化などインフラ性能も劇的に向上している。
• 現場への影響：バッチやETLの「15分の壁」を回避できる一方、冪等性の担保やコスト管理など新たな設計規律が求められる。

深夜2時、本番環境のバッチ処理が「15分」の制限時間に達して突如デッドロックのように強制終了する。エラーログには無情にもタイムアウトの文字が刻まれ、エンジニアはデータの不整合を解消するために手動でリカバリスクリプトを流す――。このような悪夢を、我々クラウドエンジニアは何度経験してきただろうか。2014年の誕生時にわずか5分だったAWS Lambdaの実行制限時間は、2018年に15分へと拡張された。しかし、データ量の増加やAI推論、複雑なETL（抽出・変換・格納）処理が日常化した現代の開発現場において、この「15分の壁」は常に開発者を苦しめる呪縛であり続けた。

これまで我々は、この制限を回避するために数々の「ダクトテープ（その場しのぎの補修）」を貼ってきた。処理を細切れにしてAWS Step Functionsで数珠つなぎにしたり、Amazon SQSを挟んで分散キューイングを構築したり、あるいはサーバーレスの思想を諦めてAmazon ECS TasksやAWS Batchへ処理を逃がすといったアーキテクチャの複雑化を受け入れてきたのだ。AWSのプリンシパルエンジニアであるRajesh Pandey氏が「顧客から『長時間実行可能なLambdaはいつになるのか』と聞かれた回数は数え切れない。ようやく、Lambdaの最大実行時間をめぐる多くのダクトテープを剥がすことができる」と語ったように、今回の90分への制限緩和は、現場の悲願が結実した瞬間であると言える。

特に、AWS Lambda Managed Instancesにおいてこの90分制限が適用されたことは極めて象徴的だ。Managed Instancesは、従来のイベント駆動型Lambdaとは異なり、定常的なワークロードに対して複数のリクエストを同一インスタンスで処理し、EC2ベースの柔軟な価格体系を享受できるモデルである。さらに、最新のGraviton5プロセッサを搭載したEC2インスタンスのサポートも開始され、コンピューティング効率は劇的に向上している。これにより、メディア変換、大規模な財務計算、Webスクレイピング、そして近年需要が爆発している「AIエージェントの自律的なワークフロー（Agentic Workflows）」といった、数十分単位で連続稼働するヘビーな処理を、インフラ管理の手間なくLambda上で直接実行することが可能になったのである。

しかし、シニアエンジニアとしての私の直感は、この「90分」という甘美な響きに手放しで歓喜することを拒んでいる。実行時間が6倍に伸びたということは、裏を返せば「障害発生時の影響範囲とリトライのコストも6倍、あるいはそれ以上に膨れ上がる」という不都合な真実を意味しているからだ。ここで我々が直視しなければならないのは、分散システムにおける大原則である「冪等性（Idempotency）」の設計である。

AWS Lambdaは「Exactly-Once（正確に一度だけ）」の実行を保証していない。ネットワークの瞬断や内部エラーにより、同一のイベントが複数回デリバリーされることは日常茶飯事だ。1分の処理であれば、リトライによるオーバーヘッドや二重書き込みのリスクは比較的小さく抑えられる。だが、80分間実行し、データベースに大量のレコードを書き込んだ後にクラッシュした関数が、最初から再実行されたらどうなるだろうか。適切な冪等性設計が施されていなければ、データの重複、不整合、あるいは外部APIへの二重課金といった致命的なバグを引き起こす。AWS公式も警告している通り、Powertools for AWS Lambdaなどを活用し、同一の処理が何度走っても同じ結果になるような「防弾仕様」のコードを書くことが、これまで以上に強く求められる。

さらに、経済性の観点からも慎重な議論が必要だ。以下の比較表に示す通り、従来のイベント駆動型Lambdaと、今回90分制限が適用されたManaged Instancesでは、その性質が大きく異なる。

コミュニティの指摘にあるように、もし90分間フルにCPUを回し続けるような処理であれば、Lambda Managed Instancesを使うよりも、Amazon ECS（Fargate）やAWS Batchを利用した方がコストパフォーマンスにおいて圧倒的に有利になるケースが多い。サーバーレスの最大のメリットは「使った分だけ支払う」ことによる無駄の排除だが、長時間実行タスクにおいては、その経済的合理性が逆転しやすい。我々は「Lambdaでできるから」という安易な理由でアーキテクチャを選択するのではなく、コンピュートコストと運用の複雑性のトレードオフを冷徹に計算しなければならない。

サーバーレスの先駆者でありAWS HeroのYan Cui氏が「『サーバーを動かすこと』と『Lambdaを呼び出すこと』の境界線がさらに曖昧になっていくことに、一抹の寂しさを覚える」と吐露した言葉には、深い洞察が含まれている。本来、サーバーレスとは「状態を持たない（ステートレス）」「短寿命」「イベント駆動」という制約を受け入れる代わりに、無限のスケールと運用の極小化を手に入れるトレードオフだった。しかし、コールドスタートが90msまで短縮されるようなマイクロVM技術の極限進化（Firecrackerやオンデマンドスナップショット）が進む一方で、Managed Instancesのように「常時稼働に近く、長時間実行可能な」モデルへとLambdaが拡張されていく様は、先祖返りのようにも映る。

この技術的転換期において、我々現場のエンジニアが明日から取るべき「実践的な処方箋」は明確だ。まず第一に、AWS SAM（Serverless Application Model）やCI/CDパイプライン（GitHub ActionsやAWS CodePipeline）を用いた「インフラのコード化（IaC）」と「自動テスト」を開発プロセスの絶対条件とすることだ。実行時間が長いLambda関数ほど、ローカル環境での再現やデバッグが困難になる。CI/CDを通じて、ステージング環境へ即座にデプロイし、実データに近い環境で統合テストを回す仕組みがなければ、90分制限の恩恵はただの「デバッグ地獄」へと変貌する。

第二に、15分を超える処理をLambdaに実装する際は、必ず「チェックポイント（中間状態の保存）」を設計に組み込むことだ。90分の処理が失敗した際、最初からやり直すのではなく、最後に成功したステップから再開できるようにステートを管理する。これはStep Functionsを組み合わせるか、アプリケーションレイヤーで進捗をDynamoDB等に記録することで実現できる。

最後に、我々は自らに問いかけなければならない。インフラ管理の煩わしさから解放されるためにサーバーレスを選んだはずの我々が、90分という「自由」を手に入れた結果、アプリケーションコードの中に複雑な分散トランザクションや冪等性の管理という「新たな技術的負債」を抱え込んではいないだろうか。サーバーレスが「ただの便利な、しかし割高な仮想マシン」に退化してしまうのか、それとも真のクラウドネイティブな進化を遂げるのか。その鍵を握っているのは、AWSのスペック値ではなく、我々エンジニアの設計規律そのものなのだ。