AWS Lambda実装パターンと運用

AWS Lambda関数の実装パターン、トリガー連携、スケーリング戦略、レイヤー管理、エッジ処理、バージョニング、セキュリティを含む実装・運用ガイド。

学習順Step 57 / 83サービスLambda試験ドメインパフォーマンス

AWS Lambda実装パターンと運用

AWS Lambdaはサーバーレスコンピューティングの中核サービスです。単なる関数実行基盤を超えて、複雑なイベント駆動型アーキテクチャを構築するための実装パターンと運用ノウハウが重要です。

Lambda関数の基本構成

関数コンポーネント

Lambda関数を実装する際の主要要素は以下の通りです：

要素	説明
コード	関数の本体。スクリプト言語は組み込みエディタで編集、またはデプロイパッケージとしてアップロード
ランタイム	コード実行環境。Node.js、Python、Java、Go、PowerShell、C#、Ruby 等をサポート
ハンドラー	関数呼び出し時に実行されるメソッド。例：`index.handler`
デプロイパッケージ	コード＋依存関係をまとめたZip形式。50MBを超える場合はS3からアップロード

実行環境の管理

AWS側でランタイム環境が完全に管理される マネージド型サービス
ユーザーはコード記述に専念、インフラ管理は不要
複数のランタイムに対応し、プログラミング言語の自由度が高い

Lambda関数の課金体系

Lambda利用料は リクエスト数 と 実行時間 に基づいて計算されます。

課金の仕組み

リクエスト数: 関数が呼び出された回数で課金
実行時間: コード実行開始から完了・中止までの時間
- 単位：100ミリ秒で切り上げ
- メモリ割り当てに比例してコンピューティング時間（GB-秒）の課金発生

無料枠

月間100万件のリクエスト が無料
月間40万 GB-秒 のコンピューティング時間が無料

コスト効率

サーバーを常時保持する従来型アーキテクチャと比べて大幅なコスト削減が可能
実際の使用分のみ課金される従量課金モデル

Lambda関数の制限事項

Lambda関数を効率的に実行するため、以下の制限が設定されています。

実行制限

項目	デフォルト	最大値
タイムアウト	3秒	900秒（15分）
メモリ	128MB	10,240MB
/tmp ストレージ	–	10,240MB

同時実行制限

項目	デフォルト	最大値
同時実行数	100	1,000（申請で数十万まで引き上げ可能）
Lambda Layers	–	最大5つまで

制限への対応

タイムアウトに達すると関数は自動的に停止されるため、長時間実行が必要な処理にはLambdaは不向きです。

Lambda関数の呼び出しパターン

Lambda関数は2つの異なる呼び出しモードで実行されます。

1. 同期呼び出し

呼び出し元 → Lambda関数 → 結果を待つ

特徴：

関数の実行完了まで呼び出し元が待機
実行結果が呼び出し元に返される
エラーが発生した場合、呼び出し元で処理可能

用途：

API Gateway経由のREST API
同期的な処理が必要なケース

適用例：

Webアプリケーションのエンドポイント
リアルタイムデータ取得

2. 非同期呼び出し

呼び出し元 → Lambda関数へリクエスト送信 → 呼び出し元は続行
             （関数は独立して実行）

特徴：

関数コードからのレスポンスを待機しない
呼び出し元は即座に別の処理へ進行
関数は独立したリクエストコンテキストで実行

用途：

イベント処理
バッチ処理
非リアルタイム処理

適用例：

S3イベントトリガー
SNS/SQSからのメッセージ処理
定期実行タスク

AWSサービスとの連携パターン

Lambda関数は多くのAWSサービスをトリガーまたは連携先として利用できます。

主要な連携先サービス

サービス	連携方式	用途
Amazon S3	イベント通知	ファイルアップロード時の処理
Amazon DynamoDB Streams	ストリーム処理	データベース変更の非同期処理
Amazon Kinesis	ストリーム処理	ストリーミングデータのリアルタイム処理
Amazon SNS	メッセージ配信	パブリッシュ・サブスクライブパターン
Amazon SQS	キューイング	非同期メッセージ処理
Amazon Cognito	ユーザーイベント	ユーザー認証・登録イベント処理
Amazon CloudWatch Events	スケジュール	定期的なタスク実行

ユースケース別の構成例

例1: S3 + Lambda + DynamoDB

S3にファイルアップロード
    ↓
Lambda関数が自動トリガー
    ↓
ファイル内容を処理
    ↓
結果をDynamoDBに保存

このパターンで、画像処理、ログ分析、データ変換等が実現できます。

例2: SQS + Lambda（複数同時実行）

SQS キューにメッセージ蓄積
    ↓
複数のLambda関数が並行処理
    ↓
DynamoDBにデータ保存

IoTセンサーデータの一括処理など、スケーラビリティが必要なケースに適しています。

例3: API Gateway + Lambda + DynamoDB

クライアント → API Gateway
              ↓
           Lambda関数
              ↓
           DynamoDB

Webアプリケーションのバックエンドサーバーをサーバーレスで実装できます。

Lambda関数のスケーリング戦略

Lambda関数の同時実行性を制御する3つの方法があります。

1. オートスケーリング（デフォルト）

10リクエスト → 6つのLambda関数が同時実行

仕組み：

リクエストごとに実行環境の個別インスタンスをプロビジョニング
自動的にスケール（デフォルトで最大1,000同時実行）

特徴：

設定不要で自動対応
予測不可能なトラフィック変動に強い

課題：

コールドスタート遅延
スケーリングが制御不能になる可能性

2. 予約同時実行（Reserved Concurrency）

Lambda関数A：同時実行100に制限
Lambda関数B：同時実行150に制限
（他の関数がスケーリングを妨げない）

利点：

特定の関数の同時実行数を予約・保証
他の関数のスケーリングが影響しない
スケーリングが制御不能にならない

用途：

ダウンストリーム（DynamoDBなど）の容量制限に合わせたい場合
他の関数と共存させたい場合

3. プロビジョニング済み同時実行（Provisioned Concurrency）

リクエストされた数の実行環境を初期化
    ↓
関数呼び出しに即座に応答できる準備完了

利点：

コールドスタート遅延を完全に排除
応答時間が予測可能

コスト：

オートスケーリングより高額
利用していない環境にも課金が発生

用途：

低レイテンシーが必須の場合
予測可能な負荷パターンがある場合

Lambda Layers：共通コンポーネント管理

複数のLambda関数で共通するコンポーネント（ライブラリ、カスタムランタイム、共通ユーティリティ）を集約します。

Layersの構造

Lambda関数A ─┐
             ├─ Lambda Layer
Lambda関数B ─┤（共通コンポーネント）
             │
Lambda関数C ─┘

Layersの活用メリット

コードの重複排除
- 共通ライブラリを1箇所で管理
- アップデートが容易
デプロイパッケージサイズの削減
- 関数ごとのZipサイズが小さくなる
- デプロイ速度向上
バージョン管理
- 共通コンポーネントのバージョンを一元管理
- 複数バージョンの並行運用も可能

設定上限

1つの関数に最大5つのLayersが適用可能
合計アップロードサイズ：最大250MB

Lambda@Edge：エッジロケーションでのコード実行

CloudFrontの配信コンテンツをLambda関数によってエッジロケーションで処理します。

Lambda@Edgeの概要

CloudFront ディストリビューション
    ↓
エッジロケーション（世界中に分散）
    ↓
Lambda関数がリクエスト/レスポンス処理

処理タイミング

Lambda@Edgeは CloudFrontの4つのタイミングで関数を実行できます：

タイミング	説明	用途
Viewer Request	クライアント→CloudFront	リクエスト検証、キャッシュ制御
Origin Request	CloudFront→オリジン	認証、キャッシュミス時の処理
Origin Response	オリジン→CloudFront	レスポンス変更、キャッシュヘッダー調整
Viewer Response	CloudFront→クライアント	セキュリティヘッダ追加、レスポンス整形

実装例

ユースケース: セキュリティヘッダの追加

オリジン上のアプリケーションコードを変更することなく、すべてのオリジン応答に HTTP セキュリティヘッダ（X-Content-Type-Options、X-Frame-Options等）を追加してセキュリティとプライバシーを向上させます。

Lambda@Edgeのメリット

グローバル分散実行：ユーザーに近いロケーションでコード実行
低レイテンシー：エッジで処理完結、オリジンへのリクエスト削減
セキュリティ強化：オリジンのコード変更不要でフィルタリング・検証実装

VPC内リソースへのアクセス

Lambda関数がVPC内のプライベートリソース（RDSデータベース、EC2等）にアクセスする場合の設定。

VPCアクセス設定

Lambda関数 → ENI（Elastic Network Interface）
         → VPC内のサブネット
         → 対象リソース

設定手順

VPC指定
- サブネットID を指定
- セキュリティグループID を指定
ENI作成
- 指定したサブネットからDHCPで動的にIP割り当て
- ENI経由で VPC 内リソースに接続
IAM ロール設定
- IAM ロールに AWSLambdaVPCAccessExecutionRole ポリシーをアタッチ
- これにより VPC ENI 作成・削除権限が付与される

注意点

VPC アクセス設定時、Lambda 関数の起動遅延が増加する可能性
コールドスタート対策として、プロビジョニング済み同時実行の利用を検討

RDS プロキシとの連携

Lambda関数からRDSデータベースへの接続を効率化します。

RDS Proxyの役割

Lambda → RDS Proxy → RDS DB
（複数の接続） （接続プーリング） （効率的な利用）

メリット

メリット	説明
接続プーリング	無駄なコネクションを削減、DB接続効率向上
IAM認証	RDS Proxyへの接続に IAM 認証を使用
暗号化	TLS/SSLによる通信暗号化
高可用性	フェールオーバーによる冗長性、マネージド運用

スケジュール実行

特定時刻をトリガーにしてLambda関数を定期実行します。

実装パターン

特定時刻に実行したいバッチ処理
        ↓
CloudWatch Events（EventBridge）でスケジュール定義
        ↓
Lambda関数が自動トリガー

用途

日次レポート生成
キャッシュのクリア
定期的なデータ同期
メンテナンスタスク

バージョニングと段階的デプロイ

Lambda関数のバージョン管理により、本番環境での段階的なデプロイが実現できます。

バージョンの特徴

特性	説明
不変性	一度発行したバージョンは変更不可
発行方法	`PublishVersion` API により明示的に発行
番号管理	発行するたびにバージョン番号が増加

エイリアス：バージョンへのポインタ

エイリアスを使用することで、バージョン番号を直接管理せずに特定バージョンを指定できます。

エイリアス：prod
    ↓
バージョン：v5

段階的な本番デプロイ（カナリアデプロイ）

エイリアスに対して複数バージョンに加重を設定します：

API Gateway
    ↓
エイリアス（prod）
    ├─ 旧バージョン（v4）：加重70%
    └─ 新バージョン（v5）：加重30%

このパターンで、新バージョンへのトラフィック段階的に移行可能です。

デプロイ戦略

カナリアデプロイ：新バージョンに10~30%のトラフィックを流す
モニタリング：エラー率やレイテンシーを監視
段階的昇格：問題がなければ徐々にトラフィックを増加
完全切り替え：安定性確認後、旧バージョンを廃止

コード署名によるセキュリティ

Lambda関数にコード署名を付与することで、信頼されたコードのみが実行されるようにします。

AWS Signer

開発者 → コード署名（AWS Signer）
      ↓
    デジタル署名されたパッケージ
      ↓
Lambda関数（署名検証）
      ↓
信頼できるコードのみ実行

コード署名の利点

利点	説明
信頼性確保	本当に信頼できるコードが実行されることを保証
改ざん検出	コード改ざんを検出して実行を阻止
コンプライアンス	セキュリティ要件への対応