aws-lambda-managed-instances

AWS Lambda マネージドインスタンス（LMI）

ユーザーのアカウント内の EC2 インスタンスで Lambda Event Functions を実行しながら、プロビジョニング、パッチ適用、スケーリング、ルーティング、ロードバランシングは AWS が管理します。Lambda の開発者体験と、EC2 の料金体系およびハードウェアの選択肢を組み合わせています。

最適な組み合わせ： サンドボックス化された CLI の実行と監査ログには、AWS MCP サーバーが最適です。標準の AWS CLI または SAM CLI でも、すべてのガイダンスを利用できます。

注： 本番環境にデプロイする前に、現在の AWS ドキュメントでリージョンごとの提供状況、クォータ、インスタンスタイプを確認してください。

すばやく判断：このワークロードに LMI は適していますか？

指標	LMI が適している場合	Lambda Event Functions が適している場合
トラフィック	安定していて予測可能、月間 5,000 万件以上のリクエスト	突発的で予測不能、トラフィックが長時間ない
実行時間	15 分を超える長時間の非同期処理／ESM ジョブ（LMI では最大 90 分）：ETL／データ処理、メディアのトランスコーディング、ML 推論、金融計算、Web スクレイピング	短時間の呼び出し。15 分を超える実行時間が必要な同期処理（いずれの Lambda でもサポートされていません）
コスト	大規模な実行時間主体の支出	呼び出しが少ない、または不定期
コールドスタート	許容できない（LMI はプロビジョニング済みキャパシティでコールドスタートを解消）	許容できる
コンピューティング	最新の CPU、特定のファミリー、高いネットワーク帯域幅、GPU が必要	Lambda Event Functions のメモリ／CPU で十分
分離	アカウント内の専用 EC2 インスタンス、VPC を全面的に制御	共有 Firecracker マイクロ VM で問題ない
ゼロへのスケール	ゼロにはスケールしませんが、AWS 提供のソリューションを使ってカスタムスケジュールを作成できます	必須（アイドル時の料金が発生しない）
コードの準備状況	スレッドセーフ（Node.js／Java／.NET）または任意の Python コード	スレッドセーフでないコード、変更にコストがかかる

参照先の振り分け

ユーザーのタスクに一致する参照ファイルを 1 つだけ読み込んでください。複数の参照ファイルを事前に読み込まないでください。

ユーザーのニーズ	対応
コスト比較、料金分析、Savings Plans、Reserved Instances	cost-comparison.mdを読む
インスタンスタイプ、メモリのサイジング、vCPU 比率、スケーリングの調整、キャパシティプロバイダーの設定	configuration-guide.mdを読む
スレッドセーフティ、並行性モデル、コードレビューのチェックリスト、複数同時実行への対応状況	thread-safety.mdを読む
変更前後のコード例、ランタイム固有の移行、コネクションプーリング	migration-patterns.mdを読む
IAM ロール、VPC のセットアップ、CLI コマンド、SAM テンプレート、CDK の例	infrastructure-setup.mdを読む
エラー、スロットリング、デバッグ、デプロイの停滞	troubleshooting.mdを読む

トラブルシューティングの要点（問題を診断する際は必ず説明してください）：

• キャパシティプロバイダーが CREATING のまま停止 → 最も多い原因は、プライベートサブネットに NAT ゲートウェイへのルートがないことです（イメージのプルと Lambda サービスとの通信には、インスタンスのアウトバウンドインターネット接続が必要です）
• 関数がスケールしない → バージョンが発行済みであることを確認してください（PublishToLatestPublished: true）
• メモリエラー → LMI の最小値は 2048 MB です

ワークフロー

ステップ 1：ワークロードを評価する

推奨する前に、次の情報を収集してください。

1. トラフィックパターン：一定ですか、それともバースト型ですか？ 1 秒あたりのリクエスト数はどれくらいですか？
2. 現在のコスト：Lambda の月額料金はいくらですか？ 既存の Savings Plans はありますか？
3. ランタイム：Node.js、Java、.NET、Python のどれですか？
4. メモリ／CPU：メモリはどれくらい必要ですか？ CPU バウンドですか、I/O バウンドですか？
5. 実行時間：平均と P99 はどれくらいですか？
6. 同時実行への対応状況：スレッドセーフですか？ /tmp パスを共有していますか？ 呼び出しごとに DB 接続を確立していますか？
7. VPC：すでに VPC 内にありますか？ プライベートリソースへのアクセスが必要ですか？

15 分を超える長時間の非同期／ESM ジョブは、LMI に適しています — LMI は、非同期およびイベントソースマッピングの呼び出しに対して、最大 90 分（5400s）の関数タイムアウトをサポートします（ETL／データ処理、メディアトランスコーディング、ML 推論、金融計算、ウェブスクレイピングなど）。ここで重要な差別化要因となるのは、コストだけでなく実行時間です。

LMI を推奨する場合は、必ず次の点に触れてください。本番環境では、AZ の耐障害性を確保するために最低 3 つの実行環境が必要です（3 未満にはできません）。

ステップ 2：コストを比較する

必須：LMI を推奨する前に、コスト比較を提示してください。

目安：トラフィックが一定の場合、LMI は月間 5,000 万〜1 億件以上のリクエストでコスト競争力を発揮します。正確な比較には、LMI 料金計算ツールを使用してください。

ステップ 3：デプロイを設定する

• インスタンスファミリー（400 種類以上、.large 以上）：C シリーズ（コンピューティング）、M シリーズ（汎用）、R シリーズ（メモリ）。最高の価格性能比を得るには ARM（Graviton）を使用します。
• Graviton インスタンスを使用する場合は、必ず関数設定で Architectures: [arm64] を設定し、一致させてください。
• メモリと vCPU の比率：2:1（コンピューティング）、4:1（汎用、デフォルト）、8:1（メモリ）。最小 2 GB、最大 32 GB。
• vCPU あたりのマルチ同時実行の上限：Node.js 64、Java 32、.NET 32、Python 16。これらはシステム上の上限です。実際に設定するのは PerExecutionEnvironmentMaxConcurrency（vCPU あたりではなく、実行環境あたり）です。
• I/O バウンドのワークロードの場合：各リクエストはネットワーク待機中にほとんど CPU を使用しないため、ランタイムのデフォルト値、またはそれ以上の PerExecutionEnvironmentMaxConcurrency（例：Node.js では 10）を使用します。
• CPU バウンドのワークロードの場合：各リクエストが CPU を飽和させるため、PerExecutionEnvironmentMaxConcurrency を vCPU あたり 1～2 に設定します。
• スケーリング：MinExecutionEnvironments（デフォルトは 3）、MaxVCpuCount（任意、デフォルトは 400 — ベストプラクティスとして明示的に設定）、TargetResourceUtilization。
• 関数タイムアウトは最大 5400s（90 分） — 既存の Timeout フィールドで設定します（CLI の update-function-configuration --timeout 5400、SAM／CFN の Timeout: 5400、またはコンソールを使用）。既存の Timeout フィールドを使用します。別の API、プロパティ、タグ、コード変更は必要ありません。適用されるのは非同期および ESM の呼び出しのみです。同期およびオンデマンドの呼び出しは、Timeout がそれより大きい値でも 15 分の上限が適用されます（GetFunctionConfiguration には設定値が引き続き表示されます）。Init フェーズの上限は引き続き 15 分です。Durable Functions では、各ステップは最大 90 分、複数ステップのワークフローは最大 1 年間実行できます。

ステップ 4：コードを移行する

コードが同時実行に対して安全か確認してください。LMI は、1 つの実行環境内で複数の呼び出しを同時に実行します。

• Python：プロセスベースの分離です。グローバル変数は共有されません。スレッドセーフに関する変更は不要です。/tmp の競合とメモリサイズに注目してください。
• Node.js：ワーカースレッドを使用します。グローバル変数はワーカー内で共有されます。非同期処理の安全性が必要です。
• Java／.NET：OS スレッド／Tasks を使用します。ハンドラーはスレッド間で共有されます。完全なスレッドセーフが必要です。

ステップ 5：インフラストラクチャをセットアップする

1. 2 つの IAM ロールを作成します。実行ロール（関数用）とオペレーターロール（キャパシティプロバイダーの EC2 管理用）です。
2. 3 つ以上の AZ にまたがるサブネットで VPC を設定します。
3. VPC 設定とスケーリング上限を指定して、キャパシティプロバイダーを作成します。
4. キャパシティプロバイダーを関連付けた新しい関数を作成します。
5. バージョンを発行します（インスタンスのプロビジョニングが開始されます）。

ステップ 6：検証と切り替え

1. まず本番以外の環境にデプロイします
2. CloudWatch を監視します：CPU 使用率、メモリ、同時実行数、スロットリング率
3. 呼び出し元のサービスまたはルーティング層でトラフィックを段階的に切り替えます（10% → 50% → 100%）
4. 本番データを 1～2 週間収集した後にコストを比較します
5. 安定したら Lambda Event Function を廃止します

ベストプラクティス

料金（コストについて説明する際は必ず言及）

• 3 つの要素：EC2 インスタンス時間 + 15% の管理手数料 + 100 万リクエストあたり $0.20
• Savings Plans：Compute Savings Plans は EC2 の料金部分に適用されます（最大 60～72% 割引）
• 15% の手数料は、AWS によるプロビジョニング、パッチ適用、スケーリング、ライフサイクル管理のため、EC2 コストに上乗せされます

スケーリング（スケーリングやトラフィックについて説明する際は必ず言及）

• LMI は 50% のトラフィック急増を即座に吸収し、5 分以内に容量を 2 倍にします。トラフィックがそれより速く 2 倍を超えると、リクエストはスロットリングされます
• Lambda Event Functions は即座に 3000 までバーストできますが、LMI はこれに追随できません
• 予測可能な急増に備えて、MinExecutionEnvironments で事前にウォームアップします
• MaxVCpuCount（デフォルトは 400）は、コスト上限として明示的に設定します
• 調整：オフピーク時の容量を減らすには、MinExecutionEnvironments を下げます（AZ の耐障害性を確保するため、最低 3 が必要です）

インスタンスのサイズ設定

• OS のオーバーヘッドとして、インスタンスごとに 1 vCPU + 1 GB を確保します（関数では使用できません）
• 使用可能な容量 = 合計容量 - オーバーヘッド

設定

• 4:1 の比率とランタイムのデフォルトの同時実行数から始めます
• x86 の依存関係がある場合を除き、ARM（Graviton）を使用します
• 特定のハードウェアが必要な場合を除き、インスタンスタイプの選択は Lambda に任せます
• コスト上限を制御するには MaxVCpuCount を設定します
• MinExecutionEnvironments を 3 未満に設定しないでください（AZ の耐障害性が損なわれます）

移行

• I/O 負荷の高い関数から始めます（マルチ同時実行のメリットが最も大きいため）
• キャパシティプロバイダーに関連付ける前に、同時実行に対する安全性を考慮してコードを確認します
• 呼び出し元のサービスまたはルーティング層でトラフィックを段階的に切り替えます
• すべてのログステートメントにリクエスト ID を含めます
• DB プールと SDK クライアントはハンドラーの外で初期化します

運用

• スロットリング率が 1% を超えた場合、および CPU 使用率が 80% を超えた場合に CloudWatch アラームを設定します
• 14 日ごとのインスタンスローテーションを計画します（自動）
• LMI の EC2 インスタンスを手動で終了しないでください（代わりにキャパシティプロバイダーを削除します）
• 必ずバージョンを発行してください。未発行の関数は LMI で実行できません

長時間実行の呼び出し（非同期／ESM、最大 90 分）

• SQS：キューの可視性タイムアウトは、関数のタイムアウト以上である必要があります（90 分の関数では 5400 秒以上）。ESM は作成時と更新時にこれを検証します。ただし、ESM の作成後は、SQS の可視性タイムアウトと関数のタイムアウトをそれぞれ独立して変更できます（ESM API の外部で変更可能です）。この場合、検証を回避できて設定の不一致が再発し、メッセージが再表示されて呼び出しが重複する可能性があります。
• Kinesis／DynamoDB Streams：部分的なバッチ失敗のレポート（ReportBatchItemFailures）を有効にし、最大バッチ処理ウィンドウと並列化係数を調整します。そうしないと、1 件のレコードの失敗でバッチ全体が再試行され、完了済みの作業が最大約 80 分分、再実行される可能性があります。
• 非同期呼び出し：失敗またはタイムアウトした呼び出しは、再試行ポリシー（デフォルトで最大 2 回の再試行）に従い、その後 DLQ／失敗時の送信先にルーティングされます。
• すべての ESM ソースが対象ではありません：Amazon MQ と Amazon DocumentDB の ESM は引き続き 15 分に制限されます。90 分が適用されるのは、SQS、Kinesis、DynamoDB Streams の ESM（および非同期呼び出し）のみです。
• オブザーバビリティに変更はありません：CloudWatch、CloudTrail（完了時またはタイムアウト時に 1 つの Invoke イベント）、X-Ray（単一のトレース）は、従来どおり動作します。90 分の制限に近づく遅い処理フェーズを見つけるには、X-Ray サブセグメントを使用します。

長時間稼働するネットワーク（関数が数十分間実行されるようになりました）

• NAT Gateway のアイドルタイムアウト — NAT Gateway 経由の長時間維持される TCP 接続では、定期的にキープアライブパケットを送信します。
• アイドル接続のタイムアウト（RDS、ElastiCache、外部 API）— 計算の途中でアイドル状態になる可能性のある接続に、接続状態のヘルスチェックや再接続ロジックを追加します。
• DNS TTL — 外部ホスト名を定期的に再解決します。AWS SDK はこれを行いますが、カスタム HTTP クライアントは TTL を超えてキャッシュする場合があります。
• 認証情報 — 実行ロールの一時的な認証情報（ランタイムによって自動更新されます）を使用します。IAM 以外のシークレット（DB パスワード、API キー）については、AWS Secrets Manager または SSM Parameter Store から SDK のキャッシュと定期的な更新を利用して取得します。長期間有効な認証情報をコードや環境変数に埋め込まないでください。

制限の早見表

リソース	制限
メモリ	最小 2 GB、最大 32 GB
非同期／ESM 呼び出しのタイムアウト	90 分（5400s）、既存の Timeout フィールドを使用
同期 + オンデマンド呼び出しのタイムアウト	15 分
初期化フェーズ	15 分
15 分に制限される ESM ソース	Amazon MQ、Amazon DocumentDB（SQS／Kinesis／DynamoDB Streams は 90 分）
実行環境	最小 3（MinExecutionEnvironments、AZ の耐障害性）
インスタンスの稼働期間	14 日（自動置換）
同時実行数／vCPU	64（Node.js）、32（Java／.NET）、16（Python）
ランタイム	Node.js 22+、Java 21+、.NET 8+、Python 3.13+、Rust（provided.al2023）
インスタンスファミリー	C、M、R（.large 以上）
スケーリング	バースト用の余力は TargetResourceUtilization による未使用容量に相当します。新しいインスタンスは数分以内に起動します

セキュリティに関する考慮事項

• オペレーターロールの範囲設定：信頼ポリシーに aws:SourceAccount と aws:SourceArn 条件を追加し、混乱した代理人攻撃を防止します。
• VPC の送信トラフィック：セキュリティグループの送信トラフィックを 0.0.0.0/0 ではなく、VPC エンドポイントのセキュリティグループまたは AWS プレフィックスリストに限定します。
• 認証情報：データベースの認証情報には AWS Secrets Manager または Parameter Store を使用します。シークレットに環境変数を使用しないでください。
• 暗号化：保存データには、SQS SSE、CloudWatch Logs の暗号化（KMS）、S3 のデフォルト暗号化を有効にします。
• ログ記録：CloudWatch Log グループの保持ポリシーを設定します。PII や認証情報をログに記録しないでください。Lambda の CloudTrail データイベントを有効にします。
• インスタンスのローテーション：14 日ごとの自動ローテーションにより、手動での対応なしにセキュリティパッチが適用されます。
• 参考資料：Lambda Security Best Practices、IAM Best Practices

ファイル

ファイル	内容
cost-comparison.md	料金分析、損益分岐点の計算、Savings Plans／RI の影響
configuration-guide.md	インスタンスの選択、メモリ比率、スケーリングの調整、キャパシティプロバイダーの設定
thread-safety.md	ランタイムごとの並行処理モデル、コードレビューのチェックリスト、Powertools との互換性
migration-patterns.md	ランタイムごとの変更前／変更後のコード、コネクションプーリング、段階的な切り替え
infrastructure-setup.md	IAM ロール、VPC の設定、SAM テンプレート、CLI コマンド
troubleshooting.md	よくあるエラー、スロットリング、デバッグ、デプロイの停止