EC2とLambdaの違い — 写真を縮小する処理はどこで動かす？

ひよこ

アップロードされた写真を小さくする処理を作りたい！EC2とLambdaはどう選ぶの？

ペンギン先生

EC2はOSから管理する仮想サーバーなど、Lambdaは関数を預けて実行基盤の管理をAWSへ任せるサービスだよ。写真1枚ずつの短い処理か、長く動く処理かで考えよう。ここではEC2のオンデマンド利用と標準的なLambda関数を比べ、別の実行方式は区別するね。

ひよこ

Lambdaは「サーバーレス」って言われるけど、本当にサーバーがないの？

ペンギン先生

サーバーはAWSの裏側にあるよ。Lambdaでもコード、依存ライブラリ、権限、監視などの管理は利用者の仕事なんだ。対応中のマネージドランタイムは通常AWSが更新するけれど、コンテナイメージで配布する関数は利用者が再ビルド・再デプロイする必要があるよ。EC2ではゲストOSの管理も担うんだ。

ひよこ

料金の仕組みはどう違うの？

ペンギン先生

EC2のオンデマンド利用では、基本的に起動中のインスタンスに料金がかかるよ。停止してもEBSなどの料金は残るんだ。標準的なLambda関数はリクエスト数と、割り当てメモリ量に応じた実行時間が基本。2026年10月9日に確認した料金表では月100万リクエストと40万GB秒の無料枠があるよ。ただしProvisioned Concurrencyを有効にした関数は無料枠の対象外で、確保中の料金もかかるんだ。周辺サービスの料金も別に確認しよう。

ひよこ

じゃあLambdaのほうがお得ってこと？

ペンギン先生

常に安いとは言えないよ。例えば実行時間が短く呼び出しも少ない処理と、大きなメモリを使い長時間動く処理では費用が違うんだ。アクセス数だけで決めず、メモリ量、実行時間、リージョン、追加機能、周辺サービス、運用の手間を含めて見積もろう。常時アクセスがあるだけでLambdaが不向きと決まるわけでもないよ。

ひよこ

スケーリング、つまりアクセスが増えたときの対応はどうなるの？

ペンギン先生

EC2はAuto Scalingグループなどを構成して台数を調整できるよ。Lambdaは実行環境を自動で増やすけれど無制限ではないんだ。標準の同時実行枠は1アカウント・1リージョンの全関数で通常1000、新規アカウントはそれより低い場合があるよ。増加速度や呼び出し回数にも制限があるので、実際のクォータと下流のDBの容量を確認しよう。

ひよこ

Lambdaの「コールドスタート」って聞いたことがあるんだけど、何が問題なの？

ペンギン先生

新しい実行環境を作る際の初期化で遅延が加わることだよ。しばらく使っていなかったときだけでなく、同時実行が増えたときにも起こり得るんだ。既存の実行環境が再利用される場合もあり、遅延は言語や初期化処理などで変わるから、実際のアプリで測る必要があるよ。

ひよこ

コールドスタートを解決する方法はあるの？

ペンギン先生

Provisioned Concurrencyで実行環境を事前に初期化できるけれど、確保中の料金がかかり、確保数を超えればコールドスタートが起きる場合もあるよ。SnapStartは初期化済みの状態から復元する方法で、確認時点ではJava 11以降、Python 3.12以降、.NET 8以降に対応しているんだ。対象ランタイムや利用条件を確認して選ぼう。

ひよこ

EC2でもLambdaでもない、中間みたいな選択肢ってあるの？

ペンギン先生

ECSはコンテナの実行を管理するサービスで、その基盤としてEC2やFargateなどを選べるよ。Fargateなら基盤サーバーの管理を任せられるんだ。標準的なLambda関数の1回の実行は最大15分なので、分割できない長時間処理ではEC2やコンテナも候補になる。OSの自由度、処理時間、運用負担を比べて選ぼう。

「写真1枚を小さくする」で考える

写真のアップロード後、一覧用のサムネイルを作るサービスを想像してみましょう。処理自体は同じでも、実行場所の管理をどこまで自分で持つかが違います。

• EC2：起動したサーバーに画像処理のアプリを置く。OSや更新、台数、常駐アプリの管理も考える。
• 標準的なLambda関数：イベントなどから関数を呼び、処理を実行する。コード・ライブラリ・権限・監視は自分で管理する。

これは構成を考える例で、実際のAWS環境を作成する手順ではありません。S3などの保存先、イベントの接続、エラー時の再処理も必要です。

最初に比べる4項目

写真1枚を短時間で処理でき、実行方式の条件に収まるならLambdaが候補になります。特別なOS設定や分割できない長時間処理が必要なら、EC2やコンテナも検討。常時アクセスがあるだけで、Lambdaが必ず高い・不向きとは決まりません。

料金と同時実行を、小さな数字で読む

標準的なLambda関数の計算量の目安は、割り当てメモリ（GB）×実行時間（秒）×実行数です。例えば1GBで0.2秒の処理を1000回なら200GB秒。これは料金計算の一要素で、初期化や方式の条件、リクエスト・保存・通信などの費用は別に確認します。Provisioned Concurrencyは確保中にも料金があり、無料枠の扱いも異なります。

平均の同時実行数の目安は、1秒あたりの要求数×平均実行時間。100要求/秒で平均0.2秒なら約20です。瞬間的な集中や下流のDB・API、要求回数の制限も見る必要があり、この値だけで枠を決めません。

EC2は停止してもEBSなどが残れば料金が続きます。「サーバーを止めたから全費用ゼロ」ではないので、片付けの範囲も決めておきましょう。

戻し方と失敗したときも考える

同じ写真のイベントを再処理した場合に、重複して困らない作りにするかも大切です。どちらの方式でも入力・失敗・再処理・保存結果を確認します。標準Lambdaの15分という条件を、Managed Instancesなど別方式へそのまま当てはめないようにしてください。

料金と権限の入口はAWS入門、コンテナという中間の選択肢はDocker入門へ進めます。

参考資料

2026年10月9日確認。

• AWS — Lambda pricing — 標準関数の費用と無料枠・確保中の課金
• AWS — Lambda quotas — 標準関数の15分と実行方式による差
• AWS — Lambda scaling — 同時実行の計算とクォータ
• AWS — Lambda runtimes — ランタイムと利用者責任
• AWS — SnapStart — 対応条件
• AWS — EC2 state changes — 停止後のEBSと課金
• AWS — EC2 stop/start — 停止・起動の条件
• AWS — ECS — EC2とFargateの基盤