AWS 22：サーバーレス ― Lambda と API Gateway

一言でいうと：乗った分だけ払うタクシー

移動の手段にたとえてみます。

Lambda（ラムダ）は、関数（ある入力を受けて、決まった仕事をして、結果を返す小さなプログラム）を AWS に預けておくと、呼ばれたときだけ動かしてくれるサービスです。

サーバーレスという言葉は「サーバーが無い」という意味ではありません。裏ではもちろん AWS のサーバーが動いています。意味は次の2つです。

Lambda の他にも、S3（第15章）・DynamoDB（第23章）・SQS（第24章）など、「台数を決めずに、使った分だけ払う」部品をまとめてサーバーレスと呼ぶことがあります。

何かが起きたら動く：イベント駆動

EC2 やタスクは、ずっと起きてリクエストを待っています。Lambda は違います。自分からは動かず、何かが起きたときに呼ばれて動きます。この「何かが起きた」という知らせをイベント、イベントで動く作り方をイベント駆動と呼びます。

図の左は、Lambda を呼べるイベントの例です。

呼ばれた関数は、仕事をして、DB に書いたり、結果を返したりして終わります。

このように「何かが起きた → 関数が動く」をつないでいくと、ずっと起きているサーバーを持たずに、サービスの一部を組み立てられます。他にも、DynamoDB の変更（第23章）、CloudWatch のアラーム（第17章）、Cognito のログイン（第26章）など、多くの AWS のサービスが Lambda を呼べます。

1回の呼び出し：イベントを受け取り、結果を返す

Lambda で書くのは、handler（ハンドラー＝受け口）と呼ばれる関数1つです。

図の流れを追ってみます。

Lambda が対応しているランタイム（第21章）は、Node.js・Python・Java・.NET・Ruby などです。第21章のようなコンテナのイメージで関数を配ることもできます。

大事なのは、1回の呼び出しで完結させることです。handler の外に書いた準備（DB への接続を開くなど）は、次の呼び出しで使い回されることがあり、速さの工夫として使われます。でも、それは「たまたま残っていた」だけです。

覚えておきたいことは DB や S3 に置きます。第12章で学んだステートレスの考え方が、Lambda ではいっそう大事になります。

コールドスタート：最初の1回は、準備の分だけ遅い

Lambda は、呼ばれると実行環境（関数を動かすための小さな箱）を用意して、その中で handler を動かします。

図の3つの段を見てください。

準備にかかる時間は、ランタイムやコードの大きさによって、数十ミリ秒から数秒までさまざまです。写真の縮小のような裏側の仕事なら気になりませんが、利用者が画面の前で待っている API だと、たまに遅い応答として見えます。

減らす方法は次のとおりです。

なお、2025年8月から、準備（INIT）の時間もすべての関数で料金の対象になりました。準備を短くすることは、速さだけでなくお金の面でも得です。

同時に来たら、同時に増える

1つの実行環境は、同時に1件だけ処理します。

図のように、10件のリクエストが同時に来ると、Lambda は環境を10個に増やして、並べて処理します。第12章の Auto Scaling のように「CPU が何%になったら増やす」を書く必要はありません。来た数だけ、自動で、すぐに増えます。

この「同時に動いている環境の数」を同時実行数と呼びます。

上限に達すると、それ以上の呼び出しは断られます（スロットリング）。API Gateway 経由ならエラーが返り、S3 や SQS のように後で呼び直してくれる呼び方なら、少し待ってから再試行されます。

増えるのが速いのは Lambda の大きな長所ですが、その先の部品も同じ速さで増えられるとは限りません。この話は後の「RDS とつなぐ」で出てきます。

Lambda の決まりごと：長い仕事・大きな仕事は苦手

Lambda には、使う前に知っておくべき決まりごとがあります。

15分を超える仕事は、次のどれかで分けます。

細かい値は変わることがあるので、実際に使うときは公式ドキュメントの「Lambda クォータ」で確かめてください。

料金：呼ばれた回数 ＋ メモリ × 動いた時間

Lambda の料金は、2つの足し算です。

たとえば、メモリ 1 GB の関数が 2秒動けば 2 GB 秒、512 MB（0.5 GB）の関数が 2秒動けば 1 GB 秒です。

毎月の無料枠は「100万リクエストと 40万 GB 秒」で、これは12か月で切れる無料枠ではなく、期限なく毎月使えます。フォトログの写真の縮小（1日数百回・1回2秒・1 GB）なら、この枠の中に収まる計算です。

気をつける点もあります。

単価はリージョンで違うので、Pricing Calculator（第4章）で試算し、料金ページで確認しましょう。

いつ安いか：少ないうちは Lambda、ずっと多いなら常駐

Lambda は「使った分だけ」なので、いつでも一番安いように思えます。でも、そうとは限りません。

図のグラフは、横がリクエスト数、縦が月の料金です。

リクエストが少ないうちは、Lambda のほうがずっと安くなります。でも、一日中たくさんのリクエストが来ると、どこかで線が交わり（赤い印）、それを超えると常駐しているタスクやサーバーのほうが安くなることがあります。常駐のほうは、1つのタスクが同時にたくさんのリクエストをさばけるからです。

どちらが安いかは、リクエストの数・1回の長さ・メモリで変わります。「サーバーレスだから安い」と決めつけず、Pricing Calculator（第4章）で両方を計算してみましょう。

料金だけでなく、人の手間も比べてください。OS の更新・台数の調整・監視の手間が減ることは、請求書には出ない大きな節約です。

API Gateway：HTTP の受付係

Lambda をアプリやブラウザから HTTP（ブラウザとサーバーが話すときの約束事）で呼ぶには、入口が要ります。その代表が Amazon API Gateway です。

API Gateway は、ホテルのフロントのような受付係です。

図では、アプリからの HTTPS のリクエストを API Gateway が受け、URL ごとに3つの関数へ振り分けています。第11章の ALB が「パスで振り分ける」のとよく似ています。実際、ALB も Lambda を送り先にできます。

API Gateway も、呼ばれた回数とデータ量で課金されるサーバーレスの部品です。台数や大きさを決める必要はありません。

入口の種類：HTTP API・REST API・WebSocket・関数 URL

API Gateway には種類があり、さらに Lambda 自身にも入口があります。

気をつけたいのは、待てる時間です。API Gateway は、関数の返事を待つ時間に上限があります（REST API も HTTP API も既定でおよそ30秒。REST API の一部は申請で延ばせる）。Lambda が15分動けても、利用者を15分待たせることはできません。

長くかかる仕事は、受付で「受け取りました」とすぐに返事をして、実際の処理はキュー（第24章）に預けて後でする、という形にします。これが第24章の話につながります。

RDS とつなぐ：VPC に入れて、接続は RDS Proxy に束ねる

Lambda は、何も設定しなければ AWS が管理するネットワークで動き、インターネット上のものや S3・DynamoDB には届きます。でも、第16章の RDS は VPC のプライベートサブネット（第6章）にあるので、そのままでは届きません。

関数を VPC につなぐ設定をすると、関数がプライベートサブネットの中から RDS に話しかけられるようになります。セキュリティグループ（第8章）も関数に付けられます。

ここで問題になるのが接続数（第13章）です。

これを防ぐのが RDS Proxy です。たくさんの関数からの接続をいったん受け止め、少ない数の接続に束ねて使い回します。

なお、VPC の中の関数からインターネットや S3 へ出るには、第7章の NAT ゲートウェイや VPC エンドポイントが必要になります。

作り方：関数を書いて、きっかけをつなぐ

コンソールで作る場合は、左の4つの手順です。

実務では、関数のコードと、きっかけ・ロール・設定を一緒にコードにします（第18章）。図の右は AWS CDK の例です。

Lambda 専用の道具として AWS SAM（Serverless Application Model）もあります。関数や API をまとめて短く書け、手元で関数を試すこともできます。どちらを使っても、中で作られるのはここまでに見た部品です。

フォトログでは：写真の縮小を Lambda に任せる

フォトログで一番 Lambda に向いているのは、写真の縮小です。

これまで、縮小を Web のタスクの中でやっていると、写真が大きいほど利用者を待たせ、投稿が集中すると Web 全体が重くなりました。Lambda に分けると、Web は写真の縮小を待たずにすぐ返事ができ、縮小は写真の数だけ自動で並んで動きます。

赤字の注意は必ず守ってください。縮小した写真を元と同じバケットに書き戻すと、その書き込みがまた「写真が置かれた」イベントになり、関数が自分を呼び続けます。Lambda には S3 との間のこうした繰り返しを検知して止める仕組みもありますが、それに頼らず、置き場所を分けるのが基本です。

フォトログの「いいね」のような小さな API も、API Gateway ＋ Lambda で作れます。ただし、いいねは一日中たくさん来る仕事です。どちらで動かすかは、前に見た料金の線で考えます。

EC2・コンテナと比べる：いつ Lambda を選ぶか

第16章の EC2、第21章の ECS と並べます。

大事なのは、どれか1つを選ぶのではなく、混ぜて使うことです。フォトログなら次のような分け方がよくあります。

なお、2025年には Lambda の関数を自分の EC2 の上で動かす Lambda Managed Instances という選び方も加わりました。一日中よく使う関数を、EC2 の料金の仕組みで安く動かしたいときの選択肢です。

向く仕事・向かない仕事

Lambda に向くかどうかは、3つの問いで判断できます。

3つとも当てはまれば Lambda が第一の候補です。1つでも外れたら、ECS や EC2 とも比べます。

迷ったときは、まず小さく Lambda で作り、利用者が増えて一日中忙しくなったら常駐に移す、という進め方もよく選ばれます。

よくある落とし穴

Lambda の事故の多くは、「一気に増える」という長所の裏返しです。

最後の「2回来る」は、S3 や SQS のイベントでまれに起きる、仕組みの上で避けられないことです。第24章で詳しく扱います。

片付け：きっかけ・関数・ロググループ

Lambda の関数は、呼ばれなければ料金はほとんどかかりません。それでも、練習で作ったものは次の順で消しておきます。

右の注意の3つは、呼ばれなくても時間で課金されるものです。

「Lambda は使わなければ0円」と思って周りの部品を残すと、請求が来て驚くことになります。