![[アップデート] AWS Lambda Managed Instances のキャパシティプロバイダーがシステムログを CloudWatch Logs に出力するようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-484d8afca1cbe50513cd4d6738af2960/fa0838fa40f247093d532945fc785e88/aws-lambda?w=3840&fm=webp)
[アップデート] AWS Lambda Managed Instances のキャパシティプロバイダーがシステムログを CloudWatch Logs に出力するようになりました
いわさです。
re:Invent 2025 で発表された Lambda Managed Instances（LMI）は、Lambda 関数を自分の AWS アカウント内の専用 EC2 インスタンスで実行できるコンピューティングオプションです。
先日のアップデートで、LMI のキャパシティプロバイダーがシステムログを Amazon CloudWatch Logs に出力するようになりました。
インスタンスの起動・終了・ヘルスチェックといったライフサイクルイベントが JSON 構造化ログとして記録され、プロビジョニングの状況やスケーリングの挙動を確認できるようになっています。
今回こちらを確認してみたので紹介します。
実際に確認してみる
では早速キャパシティプロバイダーのログを確認してみましょう。
キャパシティプロバイダーの作成
今回は検証用にキャパシティプロバイダーを作成しました。
aws lambda create-capacity-provider \
--capacity-provider-name hoge-cp-log-test \
--vpc-config SubnetIds=subnet-b461c1fc,subnet-7c372527,subnet-316fc41a,SecurityGroupIds=sg-ea2297a6 \
--permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::123456789012:role/hoge-lmi-operator-role \
--capacity-provider-scaling-config ScalingMode=Auto
レスポンスに TelemetryConfig が含まれています。
"TelemetryConfig": {
"LoggingConfig": {
"SystemLogLevel": "INFO",
"LogGroup": "/aws/lambda/capacity-provider/hoge-cp-log-test"
}
}
キャパシティプロバイダーを作成した時点で、ログ設定がデフォルトで有効になっていることがわかります。
ログレベルは INFO、ロググループは /aws/lambda/capacity-provider/<キャパシティプロバイダー名> がデフォルトで設定されています。
公式ドキュメントにも明記されているとおり、ログはデフォルトで有効とのこと。
Capacity provider system logs are enabled by default. Lambda sends system logs to CloudWatch Logs automatically when you create a capacity provider.
Lambda コンソールのキャパシティプロバイダー一覧画面で確認すると、作成したキャパシティプロバイダーが Active になっています。
ログの確認
キャパシティプロバイダーに Lambda 関数を紐づけてインスタンスを起動させると、ログが出力されます。
今回は Python 3.13 の Lambda 関数を作成し、キャパシティプロバイダーに紐づけてみました。
キャパシティプロバイダーの詳細画面から「モニタリング」タブを選択すると、CloudWatch メトリクスと合わせて「View logs in CloudWatch」ボタンが表示されます。
「View logs in CloudWatch」をクリックすると CloudWatch Logs コンソールに遷移します。
ロググループ /aws/lambda/capacity-provider/hoge-cp-log-test の中に hoge-cp-log-test/managed-instances というログストリームが自動作成されています。
ログストリームの中身を見てみましょう。
JSON 構造化ログで、インスタンスのライフサイクルイベントが記録されています。
最初のログイベントを展開すると以下のような内容です。
{
"timestamp": "2026-07-26T20:38:16.461460437Z",
"level": "INFO",
"message": "Launching instance",
"metadata": {
"capacityProviderArn": "arn:aws:lambda:ap-northeast-1:123456789012:capacity-provider:hoge-cp-log-test",
"instanceTypes": ["m7a.xlarge"],
"availabilityZones": ["ap-northeast-1a"]
}
}
3 つの AZ（ap-northeast-1a、1c、1d）それぞれに対して「Launching instance」のイベントが記録されています。
約 20 秒後に、各 AZ でインスタンスが正常に起動したログが記録されます。
{
"timestamp": "2026-07-26T20:38:36.435247002Z",
"level": "INFO",
"message": "Launched m7a.xlarge instance i-08f9cc2892127d973 in ap-northeast-1c",
"metadata": {
"capacityProviderArn": "arn:aws:lambda:ap-northeast-1:123456789012:capacity-provider:hoge-cp-log-test",
"instanceTypes": ["m7a.xlarge"],
"availabilityZones": ["ap-northeast-1c"],
"instanceId": "i-08f9cc2892127d973"
}
}
「Launching instance」で起動リクエスト、「Launched ... instance」で起動完了という流れですね。
メタデータにはインスタンス ID、インスタンスタイプ、AZ が含まれているので、どのインスタンスがどこに起動されたかを追跡できます。
EC2 コンソールでの確認
ちなみに、LMI によって起動されたインスタンスは EC2 コンソールのデフォルト表示では見えない場合があります。
EC2 の設定 >「マネージドリソース」タブから「管理リソースの可視性」を「表示可能」に変更すると、LMI のインスタンスも EC2 コンソールに表示されるようになります。
3 つの AZ にそれぞれ m7i.xlarge が 1 台ずつ起動していることが EC2 コンソールからも確認できました。
インスタンスには「管理対象」のバッジが表示されています。
ログ設定の変更
キャパシティプロバイダーの「Additional configuration」タブを選択すると、下部に「Logging configuration」セクションが表示されます。
「編集」をクリックすると、ロググループとシステムログレベルの設定画面が表示されます。
設定項目は 2 つあります。
ロググループは「Default」（デフォルトのロググループ名を使う）と「Custom log group」（任意のロググループ名を指定する）から選択できます。
複数のキャパシティプロバイダーのログを 1 つのロググループに集約したい場合に使えそうです。
システムログレベルは以下の 3 段階から選択可能です。
| ログレベル | 用途 |
|---|---|
| DEBUG (most detail) | システムデバッグ用の詳細情報 |
| INFO | キャパシティプロバイダーの通常動作を記録するメッセージ |
| WARN (least detail) | 対処しないと予期しない動作につながる可能性のあるエラーに関するメッセージ |
公式ドキュメントによると、選択したレベル以下のログのみが送信されるとのこと。
When you select a log level, Lambda sends logs at that level and lower. For example, if you set a capacity provider's system log level to INFO, Lambda doesn't send log outputs at the DEBUG level.
AWS CLI からは update-capacity-provider コマンドの --telemetry-config で設定変更できます。
aws lambda update-capacity-provider \
--capacity-provider-name hoge-cp-log-test \
--telemetry-config '{"LoggingConfig":{"SystemLogLevel":"DEBUG"}}'
トラブルシューティング時は DEBUG にして詳細なログを取り、通常運用時は INFO や WARN にしてログ量を抑えるという使い分けができそうです。
配信先について
公式ドキュメントには Amazon S3 や Firehose への配信もサポートされている旨の記載がありますが、本日時点ではコンソールのログ設定編集画面では CloudWatch Logs のみ選択可能でした。
S3 や Firehose に流したい場合は CloudWatch Logs のサブスクリプションフィルターを使う形になりそうです。
IAM 権限に関する注意点
キャパシティプロバイダーには「オペレーターロール」と呼ばれる IAM ロールが紐づいています。
これは Lambda がキャパシティプロバイダーの代わりに EC2 インスタンスの起動・管理を行うためのロールで、キャパシティプロバイダー作成時に指定するものです。
このオペレーターロールに CloudWatch Logs 関連の権限（logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents）がないと、ログが配信されません。
公式ドキュメントに重要な注意点が記載されています。
If the operator role doesn't have the required permissions, Lambda does not deliver system logs and does not return an error. Make sure that your operator role has the correct permissions to avoid silent log delivery failures.
権限が不足していてもエラーにはならず、ログが配信されないだけなので気づきにくいみたいですね。
AWS マネージドポリシー AWSLambdaManagedEC2ResourceOperator をアタッチしていれば必要な権限は含まれているとのことなので、LMI の初期セットアップ時にこのポリシーをアタッチしていれば追加の対応は不要です。
さいごに
本日は AWS Lambda Managed Instances のキャパシティプロバイダーがシステムログを CloudWatch Logs に出力するようになったアップデートを確認してみました。
デフォルトで有効になっているので、既存のキャパシティプロバイダーでも特に設定変更なくログが出力されているはずです。
インスタンスのライフサイクルイベントが JSON で記録されるので、何か問題が起きたときに調査しやすくなりそうです。
