Describe the feature
The L2 Runtime construct in @aws-cdk/aws-bedrock-agentcore-alpha does not expose an accessor for the AgentCore-managed default application log group at /aws/bedrock-agentcore/runtimes/{agentRuntimeId}-DEFAULT (where container stdout lands).
Proposal: add a public applicationLogGroup: logs.ILogGroup (or similar) property on Runtime that returns an imported reference to that log group, so downstream constructs (metric filters, alarms, subscription filters) can attach to it without hardcoding the path.
Use Case
We run four AgentCore runtimes (one FastAPI assistant, three conversation-analysis agents) in CDK-managed stacks. We attach AWS::Logs::MetricFilter resources to each runtime's stdout log group to extract business metrics from structured log output (e.g. $.tool_status = "error", $.synthesis_fallback = true).
Two problems with the current L2:
-
No accessor forces us to hardcode the path. We construct /aws/bedrock-agentcore/runtimes/${runtime.agentRuntimeId}-DEFAULT as a string literal. If AWS ever changes the path format (e.g. add an endpoint suffix), every consumer silently breaks with zero-match metric filters — and since the failure mode is "alarm stays in OK," we've been bitten by this twice already without noticing for days.
-
The group is lazy-created on first invocation, but MetricFilter CREATE requires it to exist at CFN deploy time. Fresh deploys race AgentCore's first invocation. We work around this with logs.LogRetention (the same idempotent custom resource Lambda uses for Function.logGroup), but this means two things own the group's creation: AgentCore and our LogRetention. That's fragile — any tags AgentCore adds, any retention policy AgentCore sets, drift silently.
Exposing the group as a construct property — ideally one that guarantees the group exists at deploy time, similar to Lambda's Function.logGroup — would let us remove both the hardcoded path and the ownership race.
Proposed Solution
Add an applicationLogGroup: logs.ILogGroup property to Runtime that returns an imported reference to the default-group ARN:
const runtime = new agentcorealpha.Runtime(this, 'Runtime', { /* ... */ });
new logs.MetricFilter(this, 'ToolErrors', {
logGroup: runtime.applicationLogGroup, // <-- new
filterPattern: logs.FilterPattern.stringValue('$.tool_status', '=', 'error'),
metricNamespace: 'MyApp',
metricName: 'ToolExecutionErrors',
});
Other Information
Current workaround we're using:
// Pre create with exact name used by the construct
const retention = new logs.LogRetention(scope, 'AppLogGroupRetention', {
logGroupName: `/aws/bedrock-agentcore/runtimes/${runtime.agentRuntimeId}-DEFAULT`,
retention: logs.RetentionDays.ONE_MONTH,
});
const logGroup = logs.LogGroup.fromLogGroupArn(scope, 'AppLogGroup', retention.logGroupArn);
Acknowledgements
AWS CDK Library version (aws-cdk-lib)
2.251.0 (with @aws-cdk/aws-bedrock-agentcore-alpha 2.251.0-alpha.0)
AWS CDK CLI version
2.1120.0
Environment details (OS name and version, etc.)
macOS / Node 22 / bun 1.3.9
Describe the feature
The L2
Runtimeconstruct in@aws-cdk/aws-bedrock-agentcore-alphadoes not expose an accessor for the AgentCore-managed default application log group at/aws/bedrock-agentcore/runtimes/{agentRuntimeId}-DEFAULT(where container stdout lands).Proposal: add a public
applicationLogGroup: logs.ILogGroup(or similar) property onRuntimethat returns an imported reference to that log group, so downstream constructs (metric filters, alarms, subscription filters) can attach to it without hardcoding the path.Use Case
We run four AgentCore runtimes (one FastAPI assistant, three conversation-analysis agents) in CDK-managed stacks. We attach
AWS::Logs::MetricFilterresources to each runtime's stdout log group to extract business metrics from structured log output (e.g.$.tool_status = "error",$.synthesis_fallback = true).Two problems with the current L2:
No accessor forces us to hardcode the path. We construct
/aws/bedrock-agentcore/runtimes/${runtime.agentRuntimeId}-DEFAULTas a string literal. If AWS ever changes the path format (e.g. add an endpoint suffix), every consumer silently breaks with zero-match metric filters — and since the failure mode is "alarm stays in OK," we've been bitten by this twice already without noticing for days.The group is lazy-created on first invocation, but MetricFilter CREATE requires it to exist at CFN deploy time. Fresh deploys race AgentCore's first invocation. We work around this with
logs.LogRetention(the same idempotent custom resource Lambda uses forFunction.logGroup), but this means two things own the group's creation: AgentCore and our LogRetention. That's fragile — any tags AgentCore adds, any retention policy AgentCore sets, drift silently.Exposing the group as a construct property — ideally one that guarantees the group exists at deploy time, similar to Lambda's
Function.logGroup— would let us remove both the hardcoded path and the ownership race.Proposed Solution
Add an
applicationLogGroup: logs.ILogGroupproperty toRuntimethat returns an imported reference to the default-group ARN:Other Information
Current workaround we're using:
Acknowledgements
AWS CDK Library version (aws-cdk-lib)
2.251.0 (with @aws-cdk/aws-bedrock-agentcore-alpha 2.251.0-alpha.0)
AWS CDK CLI version
2.1120.0
Environment details (OS name and version, etc.)
macOS / Node 22 / bun 1.3.9