(aws-bedrock-agentcore-alpha): allow tagging service-created runtime application log group
- Dominant language
- TypeScript
- Stars
- 12.9k
- Forks
- 4.6k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 83
Description
### Describe the feature
When creating a Bedrock AgentCore Runtime with `@aws-cdk/aws-bedrock-agentcore-alpha`, AgentCore creates the default application CloudWatch Log Group automatically at:
`/aws/bedrock-agentcore/runtimes/{agentRuntimeId}-DEFAULT`
The `RuntimeProps.tags` property applies tags to the `AWS::BedrockAgentCore::Runtime` resource, but there does not appear to be a supported way to apply tags to the automatically created CloudWatch Log Group.
This is important for environments that use tag-based controls for PII data isolation, cost allocation, retention/compliance automation, or access governance.
### Use Case
We need to isolate resources that may contain PII using mandatory resource tags. The AgentCore runtime application log group can contain application logs from runtime invocations, so it needs to carry our required data classification tags, for example:
```ts
{
DataClassification: 'PII',
Environment: 'prod',
}
```
However, because the log group is created by the AgentCore service and not as a CDK-managed `logs.LogGroup`, we cannot apply tags to it through CDK at deployment time.
### Current Behavior
`RuntimeProps.tags` only tags the Bedrock AgentCore Runtime resource. It does not tag the service-created CloudWatch Log Group.
The runtime exposes `runtime.applicationLogGroup`, but this is an imported/reference-style log group for the default endpoint log group name. Applying tags through CDK does not work for this service-created log group.
I tested the available tagging approaches and they do not apply the required tags to the AgentCore-created application log group.
### Proposed Solution
Expose a supported way to configure tags for the AgentCore runtime application log group, for example:
```ts
new agentcore.Runtime(this, 'Runtime', {
agentRuntimeArtifact,
applicationLogGroupTags: {
DataClassification: 'PII',
Environment: 'prod',
},
});
```
Alternatively, allow users to provide or pre-create a custom application log group:
```ts
const logGroup = new logs.LogGroup(this, 'ApplicationLogGroup', {
logGroupName: '/aws/bedrock-agentcore/runtimes/...',
});
Tags.of(logGroup).add('DataClassification', 'PII');
new agentcore.Runtime(this, 'Runtime', {
agentRuntimeArtifact,
applicationLogGroup: logGroup,
});
```
Another acceptable option would be a CDK-supported escape hatch or custom resource that tags the service-created log group after it exists.
### Other Information
Current workaround options are limited because the log group name depends on the generated AgentCore runtime ID and the log group is created by the AgentCore service, often after first invocation. This makes it difficult to enforce required tags at deployment time in regulated environments.
This affects Bedrock AgentCore CDK alpha Runtime users who need mandatory tags on CloudWatch Log Groups for PII/data isolation policies.
### Acknowledgements
- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change
Contributor guide
Research direction
Start by tracing the Runtime implementation in @aws-cdk/aws-bedrock-agentcore-alpha, including RuntimeProps.tags and runtime.applicationLogGroup, to understand how the service-created log group is represented. Compare the proposed applicationLogGroupTags, a supplied logs.LogGroup, and a custom-resource escape hatch, then identify the package's relevant tests. Done means users have a supported way to apply required tags to the automatically created application log group without breaking existing Runtime behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, typescript
- Domain
- cloud, observability
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100