AWS Lambdaでマイクロサービスを構成する場合、
言語選択は性能よりも「コスト構造」に影響することがあります。
本記事では、ベンチマークや実測値ではなく、
Lambdaの課金モデル × 言語ランタイムの性質
という観点から、主要言語の理屈上のコスト差を整理します。
Lambdaのコストは何で決まるか
Lambdaの実行コストは、概ね次の要素で決まります。
実行時間（ms）
割り当てメモリ（GB）
起動回数（＝リクエスト数）
コールドスタート頻度
要約すると：
コスト ≒ 実行時間 × メモリ × 呼び出し回数
マイクロサービスでは
「小さい処理を大量に、断続的に実行する」 ため、
この課金モデルの影響を強く受けます。
マイクロサービス × Lambdaで問題になりやすい点
サービス数が多い
各サービスの処理時間は短い
起動と終了が頻繁
この条件下では、
「業務ロジックよりも起動コストの比率」 が支配的になります。
主要言語の理屈上のコスト構造比較
| 言語 | 起動コスト | 実行効率 | メモリ要求 | Lambdaとの相性 | 理屈上のコスト傾向 |
|---|---|---|---|---|---|
| Java | 高い | 高い | 大きい | △ | 高くなりやすい |
| C# (.NET) | 高い | 高い | 大きい | △ | 高くなりやすい |
| Go | 低い | 高い | 中 | ○ | 比較的低い |
| Rust | 非常に低い | 非常に高い | 小 | ◎ | 最も低くなりやすい |
| Node.js | 低い | 中 | 中 | ○ | 中程度 |
| Python | 低い | 低い | 中 | △ | 実行時間次第で増加 |
※ あくまで課金モデルに対する理屈上の傾向です。
なぜ Java / C# は不利になりやすいのか
JavaやC#は、長時間稼働するサービスでは非常に優秀です。
しかしLambdaでは：
JVM / CLR の起動
フレームワーク初期化
GC前提のメモリ確保
といった 「毎回支払う固定費」 が発生します。
マイクロサービスでこれを繰り返すと、
処理自体は速いが、起動税を何度も払う構造
になり、コストが膨らみやすくなります。
なぜ Rust は有利になりやすいのか
Rustは：
ネイティブバイナリ
ランタイム初期化がほぼ不要
GCなし
メモリ使用量が予測しやすい
結果として：
「ほぼ業務ロジックだけに課金される」
構造になり、Lambdaの課金モデルと非常に相性が良くなります。
重要な前提：これは「絶対評価」ではない
本記事の比較は、
同一機能
同一アーキテクチャ
同一トラフィック
を仮定した理屈上の話です。
開発速度
既存資産
チームスキル
フレームワーク最適化
によって、実際の最適解は当然変わります。
まとめ
Lambda × マイクロサービスでは
起動コストが相対的に支配的
Java / C# は設計次第でコストが増えやすい
Rust / Go は課金モデルと相性が良い
言語選定は「速さ」より
**「課金構造との整合性」**で考えると見通しが良くなる