Skip to content

(bedrock-agentcore-alpha): expose runtime default application log group as a Runtime construct property #37796

@sumcoding

Description

@sumcoding

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:

  1. 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.

  2. 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

  • I may be able to implement this feature request
  • This feature might incur a breaking change

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    @aws-cdk/aws-logsRelated to Amazon CloudWatch Logsfeature-requestA feature should be added or improved.needs-triageThis issue or PR still needs to be triaged.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions