サーバーレスの代表格、AWS Lambda。使い方次第でコスト削減や開発スピード向上が期待できる一方、向かないタスクに無理に当てはめると逆効果になることがあります。ここでは、プログラミング初心者でも判断できる「向く」・「向かない」タスクのポイントを5つに絞って解説します。
1. 起動頻度が断続的かつ予測できないか
Lambdaはリクエストが来たときだけ起動し、実行時間に応じて課金されます。突発的なトラフィック（例: Webhook 受信、バッチ処理のトリガー）に最適です。逆に、毎秒数百回以上のリクエストが続くような高頻度サービスは、プロビジョンドコンカレンシーのコストが増大し、従来の EC2 やコンテナの方が安定します。
2. 実行時間は数秒〜数分か
Lambda の最大実行時間は 15 分です。画像リサイズやメール送信など、数秒から数分で完了できる処理は問題なく収まります。動画エンコードや大規模データの集計といった長時間処理はタイムアウトリスクが高く、Step Functions との組み合わせが必要になることが多いです。
3. ステートレスであるか
Lambda はインスタンスが使い回されることがありますが、状態を保持しない設計が前提です。リクエストごとに DB から最新情報を取得するか、外部キャッシュ（Redis, DynamoDB）を利用しましょう。セッション情報やローカルファイルに依存する処理は不安定です。
4. パッケージサイズは 250 MB 未満か
デプロイ時のコードと依存ライブラリの合計が 250 MB（圧縮後）を超えるとデプロイできません。軽量な Node.js/TypeScript の関数であれば問題ありませんが、機械学習モデルや大容量バイナリを同梱したい場合は、コンテナイメージ（ECR）や別サービスへの切り出しを検討します。
5. コールドスタートが許容範囲か
Java や .NET のように起動に時間がかかるランタイムは、コールドスタートで数秒の遅延が発生します。ユーザー体感速度が重要なフロントエンドの API では、プロビジョンドコンカレンシーや別のホスティング（Vercel, Cloudflare Workers）を選択した方が安全です。
小さなサンプル：TypeScript で書くシンプルな Lambda
以下は、API Gateway からのリクエストを受け取り、クエリパラメータ name を返すだけの最小構成です。ts-node でローカルテストし、sam build && sam deploy でデプロイできます。
import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';
export const handler = async (
event: APIGatewayProxyEvent
): Promise<APIGatewayProxyResult> => {
const name = event.queryStringParameters?.name ?? 'World';
return {
statusCode: 200,
body: JSON.stringify({ message: `Hello, ${name}!` }),
headers: { 'Content-Type': 'application/json' },
};
};
この関数は ステートレス で、実行時間は数ミリ秒、パッケージサイズも数十KB と、Lambda が得意とする条件をすべて満たしています。
まとめ
- 突発的かつ短時間の処理 → Lambda に向く
- 高頻度・長時間・ステートフル → 従来のサーバーやコンテナが適切
初心者のうちは、まずは「Webhook 受信」や「バッチ起動」などシンプルなケースで Lambda を試すと、サーバーレスのメリットと制約が体感しやすいでしょう。