--- title: "AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15407/" published: 2026-07-21 updated: 2026-10-17 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説 AWS Lambdaは、サーバーの用意や台数管理をせずに関数単位でコードを走らせるAWSのサーバーレス実行基盤です。この記事では、イベントで関数が起動する仕組み、リクエスト数と実行時間で決まる料金体系、タイムアウト900秒などの主要クォータ、コールドスタートをSnapStartやProvisioned Concurrencyで抑える対策までを一次情報で整理しました。途中にAWS CLIで関数を作って呼び出し、課金時間とメモリ使用量を読むコマンドを置いたので、読みながら手元で動かせます。トリガー設計、EC2やECS Fargateとの使い分け、15分の壁を外す新しい実行形態、採用と見送りの判断基準まで具体的な数値で示します。 ## まとめ：AWS Lambdaの仕組み・料金・制約と採用判断の要点 AWS Lambdaは、イベントをトリガーに関数を起動し、実行した時間とメモリ量に応じて課金するFaaS（Function as a Service）です。サーバーの常時稼働費が発生せず、リクエストが無ければ料金はゼロに近づきます。[AWS Lambdaの料金ページ](https://aws.amazon.com/lambda/pricing/)によれば、無料枠は月100万リクエストと40万GB秒で、超過分はリクエスト100万件あたり0.20USD、実行はx86で1GB秒あたり0.0000166667USD（米国標準リージョン・2026年9月時点の第1段階単価）でした。 設計時に効く制約は、1回の実行が最大900秒（15分）で終わること、割り当てメモリが128〜10,240MBの範囲であること、未使用状態から起動するときのコールドスタート遅延の3つです。イベント駆動でスパイクの大きい短時間処理には向き、15分を超えるバッチや遅延を許容できない常時高負荷のAPIには向きません。ただしこの前提は動いています。チェックポイント方式で最長1年走るdurable functions、EC2インスタンス上で動かすLambda Managed Instancesが加わり、従来はコンテナ基盤に逃がしていた領域の一部をLambdaのまま受けられるようになりました。2026年10月には、Node.jsのHTTPサーバーをそのまま動かす[Lambda Web Functions](https://www.issoh.co.jp/tech/details/18319/)が一般提供となり、従来の関数は「Lambda Event Functions」へ改称されています。 ## AWS Lambdaの仕組みとFaaS・サーバーレスにおける位置づけ AWS Lambdaを設計に落とし込むには、まず「関数・トリガー・実行環境」の3要素と、それがサーバーレスやFaaSという枠組みのどこに位置するのかを押さえます。ここを曖昧にしたまま組むと、状態を持たせてはいけない場所に状態を持たせるなどの設計ミスにつながります。 ### サーバーレスとFaaSから見たAWS Lambdaの立ち位置 サーバーレスは、開発者がサーバー台数やOSを意識せずにコードを動かす考え方の総称です。その中でLambdaは、処理を「関数」という単位に分割し、呼び出されたときだけ起動するFaaSに当たります。データベースやストレージをマネージドで使うBaaSと並ぶ、サーバーレスの中核部品と捉えると位置づけが整理できます。概念全体の使い分けは[サーバーレスとは何か、コンテナとの使い分けを解説した記事](https://www.issoh.co.jp/column/details/13005/)で判断軸を確認でき、FaaSとしての実行時間やコールドスタートの制約は[FaaSの採用判断を解説した記事](https://www.issoh.co.jp/tech/details/13204/)が詳しいです。 ### 関数・トリガー・実行環境で追う起動から破棄までのライフサイクル Lambdaの1回の呼び出しは、イベント発生から実行環境の割り当て、関数コード実行、応答返却へと進む流れです。[開発者ガイドの実行環境の説明](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html)は、この流れをInit・Invoke・Shutdownの3フェーズとして定義しています。実行環境は使い回され、直前の呼び出しで確保したデータベース接続やグローバル変数が次でも残る場合があります。この「ウォームな再利用」を前提に、接続の初期化は関数ハンドラの外で1回だけ行うのが定石です。一定時間呼ばれないと実行環境は破棄され、次回は初期化からやり直しになります。実行環境どうしの分離にはFirecrackerというマイクロVM技術が使われており、隔離の仕組みは[Firecracker（マイクロVM）とは何かを解説した記事](https://www.issoh.co.jp/tech/details/15691/)にまとめました。 ### 対応ランタイムとGraviton（arm64）という2つのアーキテクチャ選択 マネージドランタイムの世代は入れ替わりが速く、古い識別子のまま書かれた解説をなぞると作成そのものが弾かれます。[開発者ガイドのランタイム一覧](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)を見ると、2026年9月時点で提供中の主な識別子は次の表のとおりでした。Node.js 26（`nodejs26.x`）とPython 3.15（`python3.15`）はパブリックプレビューの位置づけで、一般提供の目標時期は2026年11月と告知されています。本番はプレビュー以外から選びます。 | 言語 | 現行の識別子（2026年9月） | 備考 | | ------- | --------------------- | ---------------- | | Node.js | nodejs24.x／nodejs22.x | 20系は2026年4月に非推奨 | | Python | python3.14／3.13／3.12 | 3.10はAL2系で期限が近い | | Java | java25／java21 | 17・11はal2023版へ移行 | | .NET | dotnet10／dotnet8 | 8系は2026年11月に非推奨 | | Ruby | ruby4.0／ruby3.4 | 3.2は非推奨済み | | Go・Rust | provided.al2023 | OSのみのカスタム実行環境 | 基盤側の期限も見落とせません。Amazon Linux 2は2026年6月30日にサポート終了の期日を迎え、`provided.al2`は2026年7月31日に非推奨となりました。AL2ベースのランタイムを使う関数は、AL2023ベースへ寄せる作業を先に済ませます。CPUアーキテクチャはx86\_64とarm64（AWS Graviton）を選べ、対応ランタイムはいずれも両方をサポートしていました。arm64は同一メモリでの実行単価がx86より低く設定されており、標準ライブラリで完結する処理なら切り替えるだけで総額が2割前後下がる計算です。廃止済み識別子でつまずいたら、[Lambda・DynamoDB・API GatewayでREST APIを作るハンズオン](https://www.issoh.co.jp/tech/details/2818/)に廃止スケジュール表と現行版で通るCLIコマンドがあります。 ## AWS CLIで最小のLambda関数を作成し実行して結果を確かめる 仕組みの説明だけでは、料金もコールドスタートも実感が湧きません。ここではAWS CLIだけで、ハンドラを書いてzipで固め、作成して呼び出し、課金対象の時間とメモリ使用量をログから読むところまでを通します。所要は5分程度、無料枠の内側に収まる範囲です。 ### ハンドラを書きzipで固めてcreate-functionで関数を作る手順 まず関数本体を1ファイルで用意します。イベントの中身を受け取り、割り当てメモリを環境変数から読んで返すだけの内容です。実行環境が公開する`AWS_LAMBDA_FUNCTION_MEMORY_SIZE`は、設定したメモリ量をそのまま返します。 ``` # app.py import json import os def handler(event, context): name = event.get("name", "world") return { "statusCode": 200, "memory_mb": os.environ["AWS_LAMBDA_FUNCTION_MEMORY_SIZE"], "request_id": context.aws_request_id, "body": json.dumps({"message": "hello, " + name}), } ``` 次にzipで固めて関数を作ります。`--role`には、AWSLambdaBasicExecutionRoleを付けた実行ロールのARNを指定してください。指定できるオプションは[AWS CLIのcreate-functionリファレンス](https://docs.aws.amazon.com/cli/latest/reference/lambda/create-function.html)にすべて載っています。 ``` zip function.zip app.py aws lambda create-function \ --function-name hello-lambda \ --runtime python3.14 \ --architectures arm64 \ --handler app.handler \ --memory-size 256 \ --timeout 10 \ --zip-file fileb://function.zip \ --role arn:aws:iam::123456789012:role/lambda-basic-exec ``` `--architectures arm64`がGravitonでの実行を指し、`--memory-size`がCPU割り当てと料金を同時に決めます。継続的に管理するならCLIの直打ちからテンプレート管理へ移すのが順当で、入口は[AWS SAMの開発者ガイド](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)と[AWS SAMとCloudFormationの違いを解説した記事](https://www.issoh.co.jp/tech/details/3823/)です。 ### invokeでテスト実行しログと課金時間・メモリ使用量を読む 作成した関数を呼び出します。`--log-type Tail`を付けると実行ログの末尾4KBがBase64で返り、デコードすると課金対象時間（Billed Duration）・使用メモリ（Max Memory Used）・初回だけ現れる初期化時間（Init Duration）を確認できます。 ``` aws lambda invoke \ --function-name hello-lambda \ --cli-binary-format raw-in-base64-out \ --payload '{"name": "issoh"}' \ --log-type Tail \ --query LogResult --output text response.json | base64 --decode cat response.json ``` 出力されるREPORT行の`Init Duration`がコールドスタートの実測値です。同じコマンドを続けて叩くとこの行は消え、ウォームな実行環境が再利用された証拠です。`Max Memory Used`が割り当ての半分にも届かなければメモリは下げられ、上限に張り付いているなら増やす判断になります。この数値をダッシュボードとアラームに載せる方法は[AWS LambdaをCloudWatchで監視する方法をまとめた記事](https://www.issoh.co.jp/tech/details/4028/)で扱っています。 ### メモリ設定を振り直して実行時間と料金が釣り合う値を探す調整手順 チューニングは、メモリを何段階か振って総額を比べる作業に尽きます。設定変更はコマンド1本で、SnapStartを試すときも同じ`update-function-configuration`を使い、発行済みバージョンでのみ有効になるため設定後に`publish-version`まで実行してください。 ``` aws lambda update-function-configuration \ --function-name hello-lambda \ --memory-size 1024 aws lambda update-function-configuration \ --function-name hello-lambda \ --snap-start ApplyOn=PublishedVersions aws lambda publish-version --function-name hello-lambda ``` 手作業の総当たりが面倒なら、[aws-lambda-power-tuning](https://github.com/alexcasalboni/aws-lambda-power-tuning)をデプロイし、Step Functionsに複数のメモリ設定を並列実行させて実行時間と料金の交点をグラフで出す方法があります。 ## AWS Lambdaの料金体系と無料枠・コスト試算の実務ポイント Lambdaの料金は「リクエスト数」と「実行時間×メモリ量（GB秒）」の2軸で決まります。EC2のように起動しているだけで課金される時間課金ではなく、呼ばれた回数と実処理時間だけが対象になる点が、コスト構造を読むうえでの起点です。 ### リクエスト課金とGB秒課金の2軸・月40万GB秒の無料枠の考え方 課金はリクエスト1件ごとの従量と、実行時間にメモリ量を掛けたGB秒の従量を合算します。料金ページの記載では、無料枠は月100万リクエストと40万GB秒で、これは期限のない枠として案内されていました。超過後はリクエスト100万件あたり0.20USD、実行はx86で1GB秒あたり0.0000166667USD（米国標準リージョン・2026年9月時点）が目安になります。1回あたりの課金時間はミリ秒単位で計測されるため、処理を短く終わらせるほど料金は下がります。東京リージョンの実額と、CloudWatch LogsやAPI Gatewayを含めた請求全体の内訳は[Lambdaの料金を東京リージョンの実額で計算する](https://www.issoh.co.jp/tech/details/17740/)で扱っています。 | 課金・設定項目 | 内容（2026年9月時点） | | ----------------------- | ---------------------- | | リクエスト | 100万件あたり0.20USD | | 実行（x86・第1段階） | 1GB秒あたり0.0000166667USD | | 実行（arm64） | x86より2割前後安い | | 無料枠 | 月100万件＋40万GB秒 | | SnapStartキャッシュ | 0.0000015046USD／GB秒 | | SnapStartリストア | 1GBあたり0.0001397998USD | | Provisioned Concurrency | 0.0000041667USD／GB秒 | | メモリ範囲 | 128〜10,240MB（1MB刻み） | | 1vCPU相当 | 1,769MB割り当て時 | ### メモリ設定がCPU性能と総額を同時に動かす料金構造を整理する Lambdaはメモリを128〜10,240MBの範囲で1MB刻みに設定でき、[開発者ガイドのメモリ設定の項](https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html)が明記するとおりCPUはメモリ量に比例して割り当てられます。1,769MBを割り当てた時点で1vCPU相当になり、それ以上はマルチコアで並列処理が効きます。ここに料金の逆説があるのです。メモリを増やすとGB秒の単価は上がる一方、CPUが増えて処理時間が短くなり、総額はむしろ下がる領域が生まれます。CPUバウンドな処理なら、128MBのまま長く回すより512〜1,024MBで一気に終わらせたほうが安い場合が多いでしょう。 ### 段階制の実行単価とSnapStart有効化時に増える課金項目 実行単価は月間のGB秒に応じた段階制で、使うほど後半の単価が下がります。個人検証や中小規模のシステムなら第1段階の単価だけ見れば足り、大規模なイベント処理では段階の切り替わりを試算に含めます。もう1つ、既存の解説でしばしば取り違えられているのがSnapStartの課金です。追加費用が発生しないのはJavaのマネージドランタイムに限られ、PythonとNETのランタイムではスナップショットの保持料金（最低3時間分）とリストア料金が別立てで発生します。Provisioned Concurrencyは待機しているだけで課金されるため、[開発者ガイドのProvisioned Concurrencyの項](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html)で設定単位を確認し、必要な時間帯だけスケジュールで確保する運用に寄せると無駄が減ります。 ## 実行環境の制約とコールドスタート・SnapStartでの高速化 設計の可否を分けるのは料金より制約です。Lambdaには変更できないハードなクォータがあり、これを超えるワークロードは最初から別サービスを選ぶべきです。あわせて、レイテンシに直結するコールドスタートへの対策を実装段階で織り込みます。 ### タイムアウト900秒・メモリ・ペイロードなど主要なクォータ一覧 1回の実行は最大900秒（15分）で強制終了され、これは引き上げできません。[開発者ガイドのクォータ一覧](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)から設計時に効く値を抜き出したのが次の表です。既定の同時実行数はリージョンあたり1,000で、申請により数万規模まで引き上げられます。関数単位のスケール速度にも上限があり、10秒あたり1,000実行環境まで増える仕組みです。新規に作ったAWSアカウントは同時実行とメモリのクォータが低い状態から始まり、使用実績に応じて自動で引き上げられます。 | クォータ項目 | 既定値・上限 | | --------- | --------------- | | タイムアウト | 最大900秒（15分） | | メモリ | 128〜10,240MB | | tmp領域 | 512〜10,240MB | | デプロイzip | 直接50MB・展開250MB | | コンテナイメージ | 最大10GB | | ペイロード | 同期6MB・非同期1MB | | ストリーミング応答 | 1回あたり最大200MB | | 環境変数 | 合計4KB・レイヤーは5つ | | ネットワーク帯域 | 実行環境あたり625Mbps | | 同時実行（既定） | 1,000（申請で増枠可） | | スケール速度 | 10秒で1,000実行環境まで | 意外に早く当たるのがコード保管容量で、Lambda管理のストレージは展開後300GBが上限です。バージョンとレイヤーを消さずに積み上げると本番デプロイが失敗するため、古いバージョンを掃除するか、[セルフマネージドのS3コードストレージ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-self-managed-storage.html)へ切り替えて上限そのものを外します。 ### コールドスタートの発生条件とSnapStartによる起動遅延の緩和 コールドスタートは、実行環境を新規に用意する初回起動の遅延で、ランタイムや依存ライブラリの量に応じて数百ミリ秒から数秒に及びます。緩和策は主に2つです。[SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html)は初期化済みの実行環境をFirecrackerのスナップショットとして暗号化保存し、そこから復元する仕組みで、Java 11以降・Python 3.12以降・.NET 8以降が対象になります（`nodejs24.x`や`ruby4.0`、OSのみのランタイムは対象外）。Provisioned Concurrencyは実行環境をあらかじめ温めておく方式で、2桁ミリ秒の応答を狙えるかわりに待機分の料金が発生します。ミリ秒単位の応答が要るAPIでは後者、バッチ寄りなら前者から検討する順序になります。 SnapStartは制約を先に確認します。有効化できるのは発行済みバージョンとそれを指すエイリアスだけで、開発中の`$LATEST`では使えません。Provisioned ConcurrencyやAmazon EFS、512MBを超えるエフェメラルストレージとは併用できず、提供リージョンからもアジアパシフィックの一部が外れています。1つのスナップショットが複数の実行環境の初期状態になるため、初期化時に生成した乱数・一意なID・一時的な資格情報はそのまま複製されます。一意性が要るものはハンドラの中で生成し直してください。 ### ステートレス前提とVPC接続で踏みやすい実装上の落とし穴と回避 Lambdaは実行環境が破棄される前提のため、状態はDynamoDBやS3などの外部に逃がします。ローカルディスクへの書き込みで永続化を期待すると、次の呼び出しでは消えている失敗パターンにはまります。VPC内リソースへ接続する構成では、以前はENI割り当てで初回が重くなったものの、現在は[開発者ガイドのVPC設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html)が説明するようにネットワークインターフェースが共有され、影響は小さくなりました。とはいえVPC接続は構成を複雑にし、VPCあたりのENI数という別のクォータも絡むため、パブリックエンドポイントで足りるなら無理にVPCへ入れない判断も有効です。 ## 主要なトリガーとユースケース・EC2/ECS/Fargateとの使い分け Lambdaの真価は、AWSの各サービスから直接呼び出せるトリガーの豊富さにあります。どのイベント源とつなぐかで設計パターンが決まり、そこが常時稼働型のEC2やコンテナ基盤との分岐点にもなります。 ### API Gateway・S3・DynamoDB・EventBridgeなど主要トリガー 代表的なトリガーは、HTTPリクエストを受けるAPI Gateway、ファイル格納を検知するS3、テーブル変更を流すDynamoDB Streams、スケジュールやイベント配信のEventBridge、キュー連携のSQS、ストリーム処理のKinesisです。HTTP APIの前段設計は[APIゲートウェイの役割と導入判断を解説した記事](https://www.issoh.co.jp/tech/details/13210/)、イベントバス側の料金と設定は[Amazon EventBridgeの仕組みと採用判断をまとめた記事](https://www.issoh.co.jp/tech/details/15513/)、非同期の全体設計は[イベント駆動アーキテクチャの実装パターンを解説した記事](https://www.issoh.co.jp/tech/details/13226/)が参考になります。処理を疎結合な関数に分け、イベントでつなぐ設計がLambdaの得意分野です。 ### EC2・ECS Fargateとの使い分けとサービス選定の判断軸 常時起動して定常トラフィックをさばくならEC2やECS Fargate、断続的なイベント処理ならLambda、という切り分けが基本線です。15分を超える長時間処理、ミリ秒を争う低レイテンシの常時API、GPUを要する重量推論はLambdaの制約に触れるため、コンテナ基盤へ寄せる判断です。逆に、月数万回のバッチや管理画面の非同期処理のように稼働がまばらな用途では、常時課金のないLambdaが総額で有利になります。移行先の候補になる基盤の中身は、[AWS ECSの起動タイプと料金を解説した記事](https://www.issoh.co.jp/tech/details/3870/)と[AWS FargateとEC2の違いを整理した記事](https://www.issoh.co.jp/tech/details/3304/)で比較できます。 | 観点 | Lambda | ECS Fargate | | ---- | ---------- | ----------- | | 課金 | 実行時間のみ | 稼働時間で課金 | | 最大実行 | 900秒 | 制限なし | | 起動 | コールドスタート有 | 常時稼働可 | | 同時実行 | 1環境で1リクエスト | 1タスクで複数可 | | 向く負荷 | 断続・スパイク | 定常・長時間 | ## 15分の壁を外すLambdaの新しい実行形態と長時間処理の受け皿 「Lambdaは15分まで」「常時高負荷ならコンテナ」という定石は、いまも初期の判断軸として有効です。ただし開発者ガイドには従来の関数とは別枠の実行形態が並ぶようになり、長時間処理と定常トラフィックの扱いに選択肢が増えました。設計を凍結する前に、次の3つを候補に入れて比べます。 ### durable functionsで最長1年の多段ワークフローを回す仕組み [durable functions](https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html)は、チェックポイントとリプレイで進捗を保存しながら、最長1年にわたる多段処理を1つの関数として書ける方式です。処理をステップに包むと結果が記録され、中断後の再開ではステップを飛ばして続きから進みます。待機（wait）の間はコンピュート課金が発生しないため、人の承認待ちや外部システムのポーリングを挟むフローで無駄が出ません。SDKはJavaScript・TypeScript・Python・Javaで提供されます。1実行あたりのdurable操作は3,000まで、永続化データは100MBまでというクォータがあるため、粒度の設計は事前に詰めます。コードで書くか連携図として持つかの分かれ目は[AWS Step Functionsの仕組みと採用判断を解説した記事](https://www.issoh.co.jp/tech/details/15429/)と読み比べてください。Lambdaから別のLambdaを直接呼ぶ構成との違いと、Step Functions側で例外の種類別にリトライを書く手順は[Step FunctionsとLambdaの違い：役割の切り分けとlambda:invoke・リトライの実装手順](https://www.issoh.co.jp/tech/details/18426/)にまとめています。 ### Lambda Managed Instancesが変える課金モデルとスケール挙動 [Lambda Managed Instances](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html)は、Graviton4を含む現行世代のEC2インスタンス上でLambda関数を動かす形態です。従来のマルチテナントなFirecracker分離ではなく、自アカウント内のEC2 Nitroインスタンス上のコンテナで動き、キャパシティプロバイダが境界になります。1つの実行環境が複数の呼び出しを同時に処理するため、I/O待ちの多いWebアプリやバッチでインスタンスの使用率が上がる設計です。課金はEC2の料金に15%の管理手数料を足す形で、Savings PlansやReserved Instancesの割引も効きます。CPU使用率に応じて非同期にスケールし、コールドスタートは発生しない一方、トラフィックが無くてもゼロにはならず設定した最小実行環境が残ります。 ### Lambda MicroVMsのクォータが示す最長8時間という実行時間 もう1つが[Lambda MicroVMs](https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms.html)で、クォータ一覧では1台あたりの最大実行時間が8時間（28,800秒）、アカウントとリージョンあたりの合計メモリが400GB（バージニア北部・オレゴン・オハイオ・東京は1,024GB）と示されています。対応アーキテクチャはARM64（AWS Graviton）でした。900秒に収まらない処理を関数の外へ出さずに済む余地が生まれた一方、同時接続数やリクエスト数の上限がインスタンスサイズごとに決まるため、コンテナ基盤の代替として一律に置き換えられるものではありません。15分に収まらない工程が1つだけ残るケースの逃げ道として評価するのが現実的です。 ## AWS Lambdaを採用すべき条件と見送るべき場面の判断基準 ここでは玉虫色にせず判断を言い切ります。Lambdaは万能ではなく、ワークロードの形が合わなければコンテナやEC2のほうが安く速くなります。自社システムのどの部分に差し込むかを、条件付きで見極めてください。 ### AWS Lambdaの採用が効くワークロードの条件と設計の勘所 採用が効くのは、次の条件が重なるときです。処理が15分以内に完結し、イベント駆動でトラフィックが読みにくく、関数を疎結合に分割できる用途が当てはまります。具体例は、S3アップロードを起点にした画像やドキュメントの変換、Webhook受信、定期バッチ、SQS経由の非同期ジョブといった処理です。これらは稼働がまばらなほどLambdaのコスト優位が大きくなり、運用チームがサーバー管理から解放される効果も実利になります。AWS上でこうしたサーバーレス設計を自社に取り入れるなら、[AWSを含むクラウドインフラ構築の相談窓口](https://www.issoh.co.jp/service/system/aws/)で構成の妥当性を検討できます。 ### AWS Lambdaを見送るべき場面とはまりやすい失敗パターン 見送るべきなのは、1回の処理が15分を超えるETLや動画エンコード、コールドスタートの数百ミリ秒すら許容できない金融系の同期API、GPUを使う大規模なML推論です。これらを標準の関数に載せると、タイムアウト分割の複雑化やProvisioned Concurrencyの常時課金で、かえって高コストになります。前章のdurable functionsやManaged Instancesはこの境界を動かしますが、課金モデルと運用の前提が別物なので無検証で持ち込むのは避けます。もう1つの失敗パターンは、状態をローカルディスクやグローバル変数に持たせて「動いているつもり」になる設計です。実行環境の再利用は保証されないため、状態は必ず外部ストアへ逃がす前提で組みます。境界領域では小さな関数で実測し、料金と遅延の実データを見てから拡張するのが安全です。 ## よくある質問 AWS Lambdaの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。 ### AWS Lambdaは無料で使えますか？ 料金ページの記載では、月100万リクエストと40万GB秒までが無料枠として案内済みです。小規模な非同期処理や個人検証の範囲なら無料枠内で収まることも多く、超過分だけがリクエスト100万件0.20USDなどの従量課金の対象です。本記事のCLI手順は256MBで10秒未満の関数を数回呼ぶだけなので、この枠の内側に収まります。まず無料枠で実測してから本番規模を試算する進め方が向いています。 ### コールドスタートはどのくらいの遅延になりますか？ 実行環境を新規に用意する初回起動で発生し、ランタイムや依存関係の量により数百ミリ秒から数秒の幅があります。実測したいときは`--log-type Tail`付きで呼び出し、REPORT行の`Init Duration`を読んでください。JavaやPython、.NETではSnapStartで1秒未満まで縮められる場合があり、確実に遅延を消したいならProvisioned Concurrencyで実行環境を温めておく方法が有効です。ただしSnapStartは発行済みバージョン限定で、Provisioned Concurrencyとは併用できません。 ### 最大の実行時間は何分までですか？ 標準の関数では1回の呼び出しが最大900秒（15分）で、この上限は引き上げできません。15分を超える処理は、[Step Functions](https://www.issoh.co.jp/tech/details/15429/)で工程を分割する、durable functionsのチェックポイント方式へ寄せる、あるいはECS FargateやEC2など時間制限のない基盤へ移すのが定石です。長時間バッチをそのまま標準の関数に載せる設計は避けてください。 ### どのプログラミング言語が使えますか？ 2026年9月時点のマネージドランタイムは、Node.js（`nodejs24.x`など）、Python（`python3.14`など）、Java（`java25`など）、.NET（`dotnet10`など）、Ruby（`ruby4.0`など）で、GoやRustは`provided.al2023`のカスタムランタイム経由で動かせます。Node.js 26とPython 3.15はプレビュー扱いのため本番では選びません。CPUアーキテクチャはx86\_64とarm64（Graviton）から選べ、arm64のほうが同一メモリの実行単価は低く収まります。 ### EC2とLambdaはどちらを選ぶべきですか？ 定常トラフィックを常時さばくならEC2やECS Fargate、断続的でスパイクの大きいイベント処理ならLambdaが基本の分岐です。稼働がまばらな用途ほどLambdaの従量課金が効き、常時高負荷や15分超の処理ではコンテナ基盤が有利です。EC2の料金モデルを保ったままLambdaの運用に寄せたい場合は、Managed Instancesという中間の選択肢も比較対象に入ります。東京リージョンの管理手数料の実額と標準Lambdaとの損益分岐、CLIでの構築手順は[Lambda Managed Instancesの料金と使い分けを解説した記事](https://www.issoh.co.jp/tech/details/17767/)で扱っています。EC2側の仕組み・料金モデル・採用判断は[Amazon EC2とは何かを実装者目線で解説した記事](https://www.issoh.co.jp/tech/details/15424/)で確認できます。 ## 関連記事 - [サーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説](https://www.issoh.co.jp/column/details/13005/)：Lambdaを含むサーバーレス全体の判断軸を整理した上位概念の記事 - [FaaSとは？サーバーレスとの関係と採用判断を解説](https://www.issoh.co.jp/tech/details/13204/)：Lambdaが属するFaaSの実行時間やコールドスタートの制約を深掘り - [イベント駆動アーキテクチャとは？実装パターンと採用判断を解説](https://www.issoh.co.jp/tech/details/13226/)：Lambdaを非同期でつなぐ設計パターンの全体像 - [APIゲートウェイとは？役割・機能と導入判断を解説](https://www.issoh.co.jp/tech/details/13210/)：HTTPトリガーでLambdaを公開する際の前段設計 - [AWS SAMとは？CloudFormationとの違い・CLIの使い方をわかりやすく解説](https://www.issoh.co.jp/tech/details/3823/)：CLI直打ちからテンプレート管理へ移すときの入口 - [AWS LambdaをCloudWatchで監視する方法｜標準メトリクス・ログ・アラーム](https://www.issoh.co.jp/tech/details/4028/)：課金時間とメモリ使用量を継続的に見る運用側の手順 --- 出典: [AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説]()（株式会社一創）