AWS Lambdaとサーバーレス設計入門 オンプレ経験者のためのアーキテクチャ移行ガイド

「サーバーレスって結局、サーバーがないわけじゃないんでしょ？」――オンプレ畑が長いエンジニアなら、一度はそう思ったことがあるはずだ。実際その通りで、裏側にはサーバーがいる。ただし、自分たちで面倒を見る必要がなくなる。OS のパッチ適用も、キャパシティプランニングも、深夜のディスク容量アラートも、全部 AWS に任せられる。この記事では、AWS Lambda を中心にサーバーレスアーキテクチャの基本設計を解説する。オンプレで培った設計感覚をどうクラウドに持ち込むか、移行時に引っかかりやすいポイントも含めて整理した。

なぜサーバーレスなのか？（オンプレとの違い・背景）

オンプレの世界では、アプリケーションを動かすためにまずサーバーを調達し、OS をインストールし、ミドルウェアを入れ、ネットワークを設定する。どんなに小さな処理でも、この一連の「土台づくり」が必要だった。

AWS Lambda はこの土台を丸ごと抽象化する。開発者が書くのは「関数」だけだ。リクエストが来たら関数が動き、終わったらリソースは解放される。常時稼働のサーバーを持たないため、使わない時間の課金はゼロになる。

オンプレとサーバーレスの違いを整理しておこう。

オンプレ経験者にとって最大のパラダイムシフトは「サーバーを管理する」から「イベントに反応する関数を書く」への転換だ。

AWS Lambda の基本的な使い方

1. Lambda 関数を作成する

AWS マネジメントコンソールから Lambda のページを開き、「関数の作成」を選択する。ランタイムは Python 3.12、Node.js 20.x、Java 21 など主要な言語に対応している。

ここでは AWS CLI を使った作成手順を示す。まず、関数のコードを準備する。

# handler.py を作成
cat << 'EOF' > handler.py
import json

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Hello from Lambda'})
    }
EOF

# ZIP に固めてデプロイ
zip function.zip handler.py

# Lambda 関数を作成（東京リージョン: ap-northeast-1）
aws lambda create-function \
  --function-name my-first-function \
  --runtime python3.12 \
  --role arn:aws:iam::123456789012:role/lambda-execution-role \
  --handler handler.lambda_handler \
  --zip-file fileb://function.zip \
  --region ap-northeast-1

2. IAM 実行ロールを設定する

Lambda 関数には必ず IAM ロール（実行ロール）を割り当てる。オンプレで言えば、アプリケーションのサービスアカウントに近い概念だ。

最小権限の原則を守ることが重要で、たとえば S3 バケットへの読み取りだけが必要な関数に、DynamoDB のフルアクセスを付けてはいけない。AWS 管理ポリシーの AWSLambdaBasicExecutionRole をベースに、必要な権限だけを追加するのが定石だ。

3. トリガーを設定する

Lambda はイベント駆動で動く。代表的なトリガーは以下の通りだ。

・Amazon API Gateway: HTTP リクエストを受けて関数を実行。REST API のバックエンドに最適
・Amazon S3: ファイルがアップロードされたタイミングで関数を起動。画像のリサイズや変換処理でよく使う
・Amazon EventBridge: スケジュール実行や他の AWS サービスのイベントをトリガーにできる。cron の代替として優秀
・Amazon SQS: キューにメッセージが入ったら関数を実行。非同期処理の定番パターン
・Amazon DynamoDB Streams: テーブルの変更を検知して関数を起動。データ変更をトリガーにした後続処理に使う

オンプレで cron + シェルスクリプトで回していたバッチ処理は、EventBridge + Lambda に置き換えられるケースが多い。

# EventBridge ルールで毎日 9:00 JST に実行するスケジュールを作成
aws events put-rule \
  --name daily-batch-rule \
  --schedule-expression "cron(0 0 * * ? *)" \
  --region ap-northeast-1

# Lambda 関数をターゲットに設定
aws events put-targets \
  --rule daily-batch-rule \
  --targets "Id"="1","Arn"="arn:aws:lambda:ap-northeast-1:123456789012:function:my-first-function"

料金の仕組み（コスト感覚）

Lambda の料金体系はシンプルだ（2026年3月執筆時点、東京リージョン: ap-northeast-1）。

・リクエスト数: 100万リクエストあたり $0.20 USD（月100万リクエストまで無料枠あり）
・実行時間: 1ミリ秒単位で課金。128MB メモリ設定で 1ms あたり $0.0000000021 USD
・無料枠: 毎月100万リクエスト + 40万GB秒の実行時間が無料（12か月限定ではなく恒久無料枠）

オンプレ感覚だとピンと来ないかもしれない。具体例で考えてみよう。1日1万リクエスト、1回の実行時間が平均200ms、メモリ256MBの関数を動かした場合、月額は $1〜2 USD 程度で収まる。同じ処理を EC2（t3.micro）で常時稼働すると月 $10 USD 前後かかるので、断続的な処理ならサーバーレスのコスト優位性は明らかだ。

ただし、常時高負荷で秒間数千リクエストが来るような処理は、EC2 や Amazon ECS（コンテナ）のほうがコスト効率が良い場合もある。「使った分だけ払う」モデルは、処理にムラがある場合に真価を発揮する。

サーバーレス設計の実務 Tips

コールドスタート対策

Lambda 関数が一定時間呼ばれないと、実行環境が破棄される。次のリクエストで環境を再構築する時間が「コールドスタート」だ。Python や Node.js なら数百ミリ秒程度だが、Java は数秒かかることもある。

対策として「Provisioned Concurrency（プロビジョンド同時実行数）」を設定すれば、事前に実行環境を温めておける。レイテンシが重要な API のバックエンドでは検討する価値がある。

関数の粒度設計

オンプレのモノリシックなアプリケーションを Lambda に移行する際、1つの巨大な関数にしてしまうのはアンチパターンだ。「1つの関数 = 1つの責務」を意識して、適切な粒度で分割しよう。

たとえば「注文処理」なら、受付・在庫確認・決済・通知をそれぞれ別の関数にして、Amazon SQS や AWS Step Functions でつなぐ。オンプレで言えば、マイクロサービス化と同じ発想だ。

環境変数と AWS Systems Manager Parameter Store

データベースの接続情報や API キーを関数内にハードコードしてはいけない。Lambda の環境変数機能か、AWS Systems Manager Parameter Store、または AWS Secrets Manager を使って外部化する。

オンプレで /etc 配下の設定ファイルに書いていた情報は、これらのサービスに移行するイメージだ。

Linux サーバーの基礎やシェルスクリプトの知識は、Lambda の開発でも役に立つ。基礎を固めたい方は、姉妹サイトLinuxMaster.JPで詳しく解説しているので参考にしてほしい。

よくあるトラブルと対処法

・タイムアウト: Lambda のデフォルトタイムアウトは3秒。重い処理では最大15分まで延長できるが、それでも足りない場合は AWS Step Functions で分割するか、Amazon ECS への切り替えを検討する
・メモリ不足: Lambda のメモリは128MB〜10,240MBの範囲で設定可能。メモリを増やすと CPU パワーも比例して上がるため、処理速度の改善にも効く
・権限エラー（AccessDenied）: 実行ロールに必要な権限が不足している。CloudWatch Logs でエラー内容を確認し、IAM ポリシーを見直す。最小権限の原則を守りつつ、必要な権限は漏れなく付与すること
・同時実行数の上限: アカウントごとにリージョン単位で同時実行数の上限（デフォルト1,000）がある。大量のリクエストが想定される場合は、事前に上限緩和申請を行う
・デプロイパッケージのサイズ制限: ZIP 形式で50MB（直接アップロード）、S3 経由で250MB（解凍後）が上限。依存ライブラリが多い場合は Lambda レイヤーで分離するか、コンテナイメージ（最大10GB）でのデプロイを検討する

本記事のまとめ

AWS Lambda とサーバーレスアーキテクチャの基本を、オンプレ経験者の視点から解説した。