agentcore: L2 constructs don't set node.defaultChild, breaking applyRemovalPolicy

[sanyamk23]

I noticed this while fixing #38262, and I am posting it as a tracking issue because the problem is not isolated to Memory.

Most of the bedrockagentcore L2 constructs create their Cfn resource plus at least one other child (usually a ServiceRole). Because of that, CDK never auto-assigns the Cfn resource as node.defaultChild, and calling applyRemovalPolicy() on the L2 throws:

CannotApplyRemovalPolicy: Cannot apply RemovalPolicy: no child or not a CfnResource.

This affects the following constructs (from a quick scan of packages/aws-cdk-lib/aws-bedrockagentcore/lib):

• tools/browser.ts
• tools/code-interpreter.ts
• memory/memory.ts (fixed in fix(bedrockagentcore): set default child on Memory L2 so applyRemovalPolicy works #38313)
• identity/workload-identity.ts
• identity/oauth2-credential-provider.ts
• identity/api-key-credential-provider.ts
• runtime/runtime.ts
• runtime/runtime-endpoint.ts
• evaluation/online-evaluation.ts
• evaluation/custom-evaluator.ts
• gateway/gateway.ts
• gateway/targets/target.ts
• observability.ts (creates several Cfn children)

The fix is the same one-liner in each case: assign this.node.defaultChild = this.__resource (or whatever the Cfn field is) right after constructing it, matching how s3.Bucket and dynamodb.Table do it.

I have done Memory in #38313. I am happy to work through the rest if that is okay, or anyone else can grab individual ones. I thought a single tracking issue was better than opening twelve separate ones.

Progress

• memory/memory.ts (fixed in fix(bedrockagentcore): Memory does not set defaultChild, breaking applyRemovalPolicy #38282, fix(bedrockagentcore): set default child on Memory L2 so applyRemovalPolicy works #38313 closed in favor of it)
• runtime/runtime.ts (fixed in fix(bedrockagentcore): set default child on Runtime L2 so applyRemovalPolicy works #38328)
• gateway/gateway.ts (fixed in fix(bedrockagentcore): set default child on Gateway L2 so applyRemovalPolicy works #38329)
• tools/browser.ts
• tools/code-interpreter.ts
• identity/workload-identity.ts
• identity/oauth2-credential-provider.ts
• identity/api-key-credential-provider.ts
• runtime/runtime-endpoint.ts
• evaluation/online-evaluation.ts
• evaluation/custom-evaluator.ts
• gateway/targets/target.ts
• observability.ts

I will work through the remaining ones as separate small PRs so each is easy to review.

[pahud]

Hi @sanyamk23,

┌──────────────────────────────────────────────────────────────┐
│ 🔴 Reported State                                            │
│ applyRemovalPolicy() throws on bedrockagentcore L2s          │
└────────────────────────────┬─────────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────────┐
│ 🔍 Root Cause                                                │
│ node.defaultChild never explicitly set on these L2s          │
│ memory.ts uses id 'Memory' (breaks auto-detect)              │
└────────────────────────────┬─────────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────────┐
│ 🟢 Suggested Fix                                             │
│ Add `this.node.defaultChild = this.__resource` after L1 init │
└──────────────────────────────────────────────────────────────┘

I wasn't able to run a full local build, but from my analysis of the source code the root cause is confirmed. The Resource.applyRemovalPolicy() method relies on node.defaultChild resolving to the underlying CFN resource.

The Memory case is genuinely broken because its L1 is created with id 'Memory' rather than 'Resource', so the constructs library's auto-detection (which only looks for children named 'Resource' or 'Default') finds nothing:

aws-cdk/packages/aws-cdk-lib/aws-bedrockagentcore/lib/memory/memory.ts

Line 748 in c896fa4

this.__resource = new CfnMemory(this, 'Memory', cfnProps);

One important note: the fix should NOT rename the child id to 'Resource'. The construct id feeds into the CloudFormation logical ID, so renaming it would cause every existing deployment to replace its Memory resource (delete + recreate) on the next update — destructive for a stateful resource in a stable module. The explicit assignment in your PR is exactly right because it fixes defaultChild without touching logical IDs:

this.node.defaultChild = this.__resource;

For the other constructs (browser, code-interpreter, runtime, gateway, etc.) that already use 'Resource' as the L1 id, auto-detection technically works today, but explicitly setting node.defaultChild is the established CDK best practice — matching how s3.Bucket, dynamodb.Table, and NestedStack do it — and makes them resilient to future refactoring.

Thanks for filing this as a tracking issue and already working through the fixes. The approach in your PRs (#38282, #38328, #38329) is correct, and small reviewable PRs per construct is the right way to land this. Nice work!