モダナイゼーションの中でも、運用負荷を最も大きく削減できる可能性があるのが サーバーレス化です。ただし、既存システムをそのままLambdaに移行しようとすると、いくつかの制約に直面します。本記事ではその移行パターンと注意点を解説します。

SAA レベル：基礎概念

サーバーレス化が適する既存ワークロード

間欠的に実行されるバッチ処理（夜間集計処理等）
イベント駆動で発生する処理（ファイルアップロード時の変換処理等）
トラフィックが予測しづらいAPIバックエンド

SAA 試験のポイント

Lambda関数の実行時間制限は最大15分です。既存のバッチ処理をそのままLambda化しようとして、処理時間が15分を超える場合は、そのままでは移行できないという制約がSAAで頻出します（2-1のサーバーレス記事でも触れた基本制約）。

SAP レベル：高度な設計シナリオ

イベント駆動への再設計

SAP 試験のポイント

既存の同期的でシーケンシャルな処理フロー（バッチ処理がステップを順番に実行する構成）を、そのままLambda関数1つに移植しようとすると、実行時間制約に抵触します。SAPレベルでは、処理を複数の小さなステップに分解し、Step Functionsでオーケストレーションすることで、各ステップは15分以内に収まりつつ、全体としては長時間の処理フローを実現する再設計が問われます。

大量データ処理の代替手段

SAP 試験のポイント

15分の実行時間制約や、Lambdaのメモリ制約（最大10GB）を超えるような大規模なバッチ処理（ペタバイト級のETL処理等）は、無理にLambdaで実現しようとせず、**AWS Glue（サーバーレスETL）やECS/Fargateタスク（実行時間制約なし）**への移行を検討することがSAPレベルの判断として問われます。「サーバーレス化＝必ずLambda」という短絡的な理解は誤りです。

処理特性	推奨されるサービス
短時間・イベント駆動	Lambda
長時間・大規模データ処理のETL	AWS Glue
長時間・カスタムロジックのバッチ処理	ECS/Fargate タスク（スケジュール実行）

設計上の落とし穴

「実行時間制約を回避するために、Lambda関数の中で別のLambda関数を非同期に呼び出し続けてリレー形式で処理を継続する」という力技の設計は、エラーハンドリングと可観測性が著しく低下し、SAPレベルではアンチパターンとして扱われます。素直にStep Functionsでオーケストレーションするか、より長時間実行に適したサービス（ECS/Fargate、Glue）を選択することが正しい判断です。

既存コードの移植性の考慮

既存のアプリケーションロジックがOS依存の機能（特定のライブラリ、ファイルシステム操作）に強く依存している場合、Lambdaの実行環境（コンテナベースのサンドボックス）への移植に追加の改修が必要になることがある
Lambda Web Adapterのようなツールを使うと、既存のWebフレームワーク（Express等）で書かれたアプリケーションを、大きな変更なしにLambda上で動かすことも可能

まとめ

SAA: サーバーレス化に適するワークロードの特性、Lambdaの15分実行時間制約を理解する。
SAP: Step Functionsによる長時間処理の分解、大規模データ処理における適切なサービス選択（Glue/ECS）ができる。

次は レガシーDBからAurora/DynamoDBへの移行戦略を見ていきましょう。