AWS Lambda

このページで押さえる論点

• サーバーレスとイベント駆動、料金の考え方
• Lambda の上限値（実行時間・メモリ・ペイロード・パッケージサイズ）
• 呼び出し方の 3 種類（同期・非同期・イベントソースマッピング）と失敗時の扱い
• 同時実行数（予約同時実行・プロビジョニング済み同時実行・スロットリング）
• コールドスタートと、その対策（SnapStart など）
• メモリの設定と性能・コスト
• アクセス権限と VPC 内のリソースへの接続
• Lambda・Fargate・EC2 の使い分け

サーバーレスとイベント駆動、料金の考え方

サーバーレスとは、サーバーが存在しないという意味ではなく、サーバーの用意・OS の更新・台数の増減を AWS に任せられるという意味です。Lambda では、関数のコードと設定（メモリ量、タイムアウトなど）を登録するだけで、リクエストが増えれば AWS が自動で実行環境を増やします。

イベント駆動型アーキテクチャとは、「何かが起きた（イベント）」ことをきっかけに処理を動かす設計です。たとえば「S3 に画像がアップロードされたら、Lambda がサムネイル画像を作る」「API Gateway にリクエストが来たら、Lambda が DynamoDB からデータを返す」といった形です。処理と処理が直接呼び合わないので、疎結合になり、部品ごとに独立して増減できます。試験ガイドでも「イベント駆動型、マイクロサービス、多層アーキテクチャを設計する」「サーバーレスを使う場面を判断する」ことが求められます。

料金の考え方

通常の関数の料金はリクエスト数と実行時間で決まります。実行時間は 1 ミリ秒単位で切り上げて計算され、割り当てたメモリが大きいほど単価が上がります（GB 秒という単位）。オンデマンド実行では処理のない時間に実行時間分の料金はかからないため、アクセスがまばら・予測できないワークロードほど、常時起動の EC2 より安くなりやすいのが特徴です。AWS の料金ページでは、毎月 100 万リクエストと 40 万 GB 秒の無料利用枠を案内しています。プロビジョニング済み同時実行や追加ストレージなどは別料金です。Compute Savings Plans は Lambda にも適用されます。

Lambda の上限値

この表の同期リクエストとレスポンスの 6 MB は、通常のバッファ応答の上限です。レスポンスストリーミングを使う場合は、応答を最大 200 MB まで返せます。非同期呼び出しのペイロードの上限は、以前は 256 KB でしたが、現在の公式の値は 1 MB です。古い問題集では 256 KB と書かれていることがあるので注意してください。

呼び出し方の 3 種類と失敗時の扱い

Lambda 関数の呼び出され方は、大きく 3 種類あります。どの種類かによって、失敗したときの再試行の仕組みが変わります。

非同期呼び出しの再試行と失敗時の送信先

非同期呼び出しで関数がエラーになると、Lambda は既定でさらに 2 回再試行します（1 回目と 2 回目の間は 1 分、2 回目と 3 回目の間は 2 分待ちます）。スロットリングなどで実行できなかった場合は、既定で最大 6 時間、再試行を続けます。再試行の回数やイベントを保持する時間は短くすることもできます。

それでも処理できなかったイベントを残す方法は 2 つあります。

• 送信先（Destinations）: 成功時・失敗時それぞれに送信先を指定でき、SQS、SNS、Lambda、EventBridge、S3（失敗時のみ）に呼び出しの記録を送れます。記録には関数の応答やエラーの内容も含まれます。
• デッドレターキュー（DLQ）: 失敗したイベントだけを、SQS の標準キューか SNS の標準トピックに送ります。送られるのはイベントの内容だけです。

再試行があるため、同じイベントで関数が 2 回以上実行されることがあります。関数は、同じイベントを重ねて処理しても結果が変わらない作りにしておきます。

イベントソースマッピングとトリガーの違い

S3 や SNS は、イベントが起きると自分から Lambda を呼び出します（トリガー）。一方、SQS や Kinesis のようなキュー・ストリームは、Lambda の側が読みに行き、複数のレコードをまとめて 1 回の実行で処理します（イベントソースマッピング）。まとめる件数（バッチサイズ）や、まとめるまで待つ時間（対象ソースに応じて最大 300 秒）を設定できます。

SQS では、関数がバッチ内の 1 件でも失敗すると、既定ではバッチ全体が可視性タイムアウト後に再配信されます。成功したメッセージまで再処理したくない場合は、部分バッチ応答を有効にし、失敗したメッセージだけを再試行させます。キューの可視性タイムアウトは、関数タイムアウトの少なくとも 6 倍にバッチウィンドウを加えた値を目安にします。何度も処理に失敗したメッセージを隔離するには、SQS キュー側の再配信ポリシーとSQS DLQを設定します。これは Lambda の非同期呼び出しに設定する DLQ／送信先とは別の仕組みです。

同時実行数

同時実行数とは、ある瞬間に並行して処理しているリクエストの数です。目安は次の式で求められます。

同時実行数 ＝ 1 秒あたりのリクエスト数 × 1 回の平均実行時間（秒）

たとえば毎秒 100 件のリクエストがあり、1 回 0.5 秒かかるなら、同時実行数は 50 です。同時実行数は、リージョン内のすべての関数の合計で既定 1,000 が上限です。上限を超えたリクエストはスロットリング（実行を断られること）されます。同期呼び出しなら呼び出し元にエラーが返り、非同期呼び出しなら Lambda が再試行します。

図で省略した点を補足します。同時実行数は、関数ごとに 10 秒あたり 1,000 の実行環境のペースで増やせます。また、1 秒あたりのリクエスト数にも、同時実行数の上限の 10 倍（既定では毎秒 10,000 件）という上限があります。

予約同時実行とプロビジョニング済み同時実行

予約同時実行を設定すると、その関数が使える数の上限にもなります。アカウント全体の上限が既定の 1,000 の場合、通常は 100 を未予約の関数用に残すため、予約できる合計は 900 までです。予約同時実行も設定している場合、プロビジョニング済み同時実行はその予約枠内に設定します。プロビジョニング済みの枠を超えたリクエストは、通常の同時実行枠へあふれる場合があります。予約上限やアカウント上限に達していればスロットリングされます。

コールドスタートと、その対策

Lambda が新しい実行環境を用意するときは、コードのダウンロード、ランタイムの起動、関数の初期化コード（ハンドラーの外に書いた処理）の実行が必要です。この準備の時間をコールドスタートと呼び、その回の応答が遅くなります。処理が終わった実行環境はしばらく残り、次のリクエストで再利用されます（ウォームスタート）。この場合、初期化は繰り返されません。

• 初期化をハンドラーの外に書く: SDK のクライアントやデータベースの接続をハンドラーの外で作ると、ウォームスタートでは再利用されます。
• プロビジョニング済み同時実行: 指定した数の実行環境を初期化済みにして待機させるので、その数の範囲でコールドスタートを抑えます。実行環境のリセットなどで遅延が残る場合もあり、追加料金がかかります。
• Lambda SnapStart: 関数のバージョンを発行するときに、初期化済みの状態のスナップショットを作って保存し、そこから実行環境を再開して起動時間を短縮します。Java 11 以降、Python 3.12 以降、.NET 8 以降で使えます。プロビジョニング済み同時実行や EFS、512 MB を超える一時ストレージとは併用できません。

メモリの設定と性能・コスト

Lambda では CPU を直接指定できず、メモリの量に比例して CPU が割り当てられます。メモリ 1,769 MB で 1 vCPU 相当です。そのため、CPU を多く使う処理が遅いときは、メモリを増やすと速くなります。メモリを増やすと 1 ミリ秒あたりの単価は上がりますが、実行時間が短くなるので、合計の料金が変わらない、または下がることもあります。試験ガイドでも「Lambda のメモリ量など、適切なリソースのサイズを選ぶ」ことが挙げられています。

適切なメモリ量を探すには、AWS Compute Optimizer の推奨を使えます（x86_64 アーキテクチャの関数が対象です）。

アクセス権限と VPC 内のリソースへの接続

2 種類の権限

• 実行ロール: 関数が他の AWS サービスを使うための IAM ロールです。関数から S3 を読み書きする、DynamoDB に書き込む、ログを CloudWatch Logs に送るといった権限を与えます。アクセスキーを関数のコードや環境変数に書くのではなく、実行ロールで権限を渡します。
• リソースベースのポリシー: 「誰がこの関数を呼び出してよいか」を決めるポリシーです。S3 や SNS、他のアカウントから関数を呼び出す許可を与えます。

VPC 内のリソースへの接続

Lambda 関数は、既定では AWS が管理する VPC の中で動き、インターネットにアクセスできます。プライベートサブネットにある RDS などに接続したいときは、関数を自分の VPC にアタッチします（サブネットとセキュリティグループを指定）。Lambda は Hyperplane ENI というネットワークインターフェースを自動で作って VPC につなぎます。実行ロールには、ネットワークインターフェースを作成する権限（AWSLambdaVPCAccessExecutionRole など）が必要です。

VPC にアタッチした関数は、既定ではその VPC から到達できるリソースへ接続します。パブリックサブネットを選んだだけではインターネットに出られず、関数にもパブリック IP アドレスは付きません。インターネットに出る必要があるなら、プライベートサブネットから NAT ゲートウェイ経由で経路を作ります。S3 や DynamoDB などの AWS サービスだけに接続するなら、VPC エンドポイントを使う方法もあります（「VPC 接続」のページを参照）。

データベースへの大量接続と RDS Proxy

Lambda は同時実行数が増えると、実行環境ごとにデータベースへ接続を作るため、RDS の接続数があふれることがあります。Amazon RDS Proxy を間に置くと、データベースへの接続をプールして共有・再利用できるので、接続の作りすぎを防げます。フェイルオーバー時にもアプリの接続を保ったままスタンバイに切り替えられます。

なお、よく使われるサーバーレスアプリケーションのひな形は、AWS Serverless Application Repository で検索・デプロイ・公開できます。

Lambda・Fargate・EC2 の使い分け

「運用の手間を最小に」「サーバーの管理をしたくない」なら、まず Lambda が候補です。ただし 15 分を超える処理なら Fargate、コンテナの詳しい選び方は「コンテナ」のページで扱います。複数の Lambda 関数を順番どおりに実行し、途中の失敗も扱いたい場合は、AWS Step Functions でワークフローとして組み立てます。

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「タイムアウトを延ばせば、1 時間かかる処理も Lambda で動かせる」→ ✕。上限は 900 秒（15 分）です。長い処理は Fargate や AWS Batch、または Step Functions で分割します。
• 「VPC にアタッチした Lambda をパブリックサブネットに置けばインターネットに出られる」→ ✕。パブリック IP アドレスが付かないため出られません。プライベートサブネットと NAT ゲートウェイを使います。
• 「予約同時実行はコールドスタートを防ぐ」→ ✕。予約同時実行は枠の確保と上限の設定です。遅延を抑える方法はプロビジョニング済み同時実行（追加料金あり）や SnapStart ですが、どちらも遅延を完全に保証するものではありません。
• 「CPU の数を指定して処理を速くする」→ ✕。Lambda は CPU を直接指定できません。メモリを増やすと CPU も比例して増えます。
• 「非同期呼び出しが失敗したら、イベントはすぐに消える」→ ✕。関数エラーなら既定で 2 回再試行され、それでも失敗したイベントは送信先や DLQ に残せます。
• 「非同期呼び出しで送れるデータは 256 KB まで」→ 現在は ✕。公式の上限は 1 MB に変わっています。

まとめ: SAA 試験で押さえるポイント

• Lambda はサーバー管理不要・使った分だけ（リクエスト数と 1 ミリ秒単位の実行時間）の料金で、イベント駆動型の設計の中心になる
• 上限: 実行時間最大 15 分、メモリ 128 MB〜10,240 MB、/tmp 最大 10,240 MB、ペイロードは同期 6 MB・非同期 1 MB
• 呼び出し方: 同期（API Gateway など）、非同期（S3・SNS、エラー時に 2 回再試行）、イベントソースマッピング（SQS・Kinesis などをポーリング）
• 非同期の失敗は送信先（Destinations）かDLQに残す
• 同時実行数 ＝ リクエスト数/秒 × 実行時間（秒）。リージョンの既定上限は 1,000 で、超えるとスロットリング
• 枠の確保・制限は予約同時実行（無料）、コールドスタート対策はプロビジョニング済み同時実行（有料）や SnapStart
• CPU はメモリに比例。遅い計算処理はメモリを増やす
• VPC にアタッチした関数がインターネットに出るには NAT ゲートウェイ。DB 接続があふれるなら RDS Proxy