[BUG] DataZone-generated AOSS encryption policy uses a numeric domain ID prefix that never matches Bedrock IDE collection names

[marcinc]

Summary

When the AmazonBedrockKnowledgeBase blueprint is enabled in SMUS, every project environment deployment fails because the OpenSearch Serverless encryption security policy that DataZone auto-creates at domain setup time uses a resource pattern derived from a numeric prefix of the domain ID. That pattern never matches the actual per-environment collection names, which are based on random alphanumeric environment IDs.

Affected version

@aws-mdaa/datazone-l3-construct v1.5.0

Component

packages/constructs/L3/governance/datazone-l3-construct/lib/private/sagemaker-domain-helper.ts
Function: createToolingResources() — AOSS encryption security policy creation

Error message

Project environment AmazonBedrockKnowledgeBase (<env-id>) failed to deploy in the account <account> and region <region> due to the failure:
  No matching security policy of encryption type found for collection name: bedrock-ide-<env-id>
    CloudFormation stack ID: DataZone-Env-<env-id>
    Service: OpenSearchServerless
    Status code: 400

Root cause

When AmazonBedrockKnowledgeBase is enabled as a managed blueprint, DataZone automatically creates an AOSS encryption security policy at domain setup time. The policy is named bedrock-ide-<domain-id-suffix> (e.g. bedrock-ide-634dh0rdxl8bpx for domain dzd-634dh0rdxl8bpx). However, the resource pattern DataZone generates is:

collection/bedrock-ide-<numeric-prefix>-*

where <numeric-prefix> is only the leading digit characters stripped from the domain ID suffix. For domain dzd-634dh0rdxl8bpx this produces collection/bedrock-ide-634-*.

AOSS collections created per project environment are named bedrock-ide-<env-id>, where <env-id> is a random alphanumeric string entirely unrelated to the domain ID (e.g.bedrock-ide-49furjjoz0ih79). The generated pattern collection/bedrock-ide-634-* never matches these names, so AOSS rejects the CreateCollection call for every environment.

Proposed Fix

Pre-create the AOSS encryption security policy in CDK with the same name DataZone would generate (bedrock-ide-<domain-id-suffix>) but with the correct broad resource pattern collection/bedrock-ide-*. Because DataZone checks for an existing policy with that name
before creating its own, it finds the pre-created policy and skips overwriting it.

if (domainId) {
  const domainIdSuffix = Fn.select(1, Fn.split('dzd-', domainId));
  new CfnSecurityPolicy(scope, `${domainName}-bedrock-ide-aoss-encryption`, {
    name: Fn.join('', ['bedrock-ide-', domainIdSuffix]),
    type: 'encryption',
    policy: Stack.of(scope).toJsonString({
      Rules: [{ Resource: ['collection/bedrock-ide-*'], ResourceType: 'collection' }],
      AWSOwnedKey: false,
      KmsARN: kmsKey.keyArn,
    }),
  });
}

The domainId is passed in from the primary createDomain() call via domainResources.domain.attrId. The cross-account call path intentionally omits it -- DataZone manages AOSS policies for cross-account scenarios separately.

Workaround

Update the existing AOSS encryption security policy directly. First retrieve the current policy version:

aws opensearchserverless get-security-policy \
  --type encryption \
  --name bedrock-ide-<domain-id-suffix> \
  --region <region>

Note the policyVersion value, then update the resource pattern:

aws opensearchserverless update-security-policy \
  --type encryption \
  --name bedrock-ide-<domain-id-suffix> \
  --region <region> \
  --policy-version <current-version> \
  --policy '{"Rules":[{"Resource":["collection/bedrock-ide-*"],"ResourceType":"collection"}],"AWSOwnedKey":false,"KmsARN":"<tooling-key-arn>"}'

After updating the policy, delete the failed project environment and recreate it. CloudFormation does not retry a failed environment stack automatically.

Impact

• Severity: Blocker -- every AmazonBedrockKnowledgeBase environment creation fails after the AOSS policy is first written by DataZone with the wrong pattern.
• Scope: Domains with AmazonBedrockKnowledgeBase in enabledManagedBlueprints. Other Bedrock sub-blueprints that create AOSS collections would be affected by the same pattern mismatch if they follow the same naming convention.
• Unaffected: Blueprints that do not create AOSS collections

[suddash24]

Hi @marcinc,

Thank you for the detailed and well-documented bug report. We've completed our initial investigation and can confirm this is a legitimate, reproducible issue.

Our findings align with your analysis:

• The createToolingResources() code path does not pre-create or correct the AOSS encryption security policy — it relies entirely on DataZone's auto-generated policy, which uses a numeric-prefix pattern from the domain ID that structurally cannot match the random alphanumeric environment IDs assigned to collections.
• This is a deterministic failure affecting every domain that enables AmazonBedrockKnowledgeBase in enabledManagedBlueprints.

Regarding PR #51:

We are actively evaluating the pull request. The approach of pre-creating the AOSS encryption policy with the correct wildcard pattern (collection/bedrock-ide-*) leveraging DataZone's existing-policy check to prevent overwrite is sound. We've also confirmed that the fix correctly uses customer-managed KMS encryption (consistent with MDAA's security standards) and that the broader wildcard is appropriately scoped to the bedrock-ide- prefix within a single domain boundary.

We'll provide a detailed review on the PR shortly. Thank you for both identifying the issue and contributing the fix.