8.3 Encryption with AWS KMS & Cross-Account Access Patterns

8.3 Encryption with AWS KMS & Cross-Account Access Patterns

This independent study guide by OpenExamPrep helps candidates prepare for the AWS Certified Generative AI Developer - Professional (AIP-C01) examination. Enterprise policies and regulatory obligations commonly require encryption, access control, retention, and audit evidence. Whether a customer managed KMS key is required depends on the applicable policy, resource, and cross-account design; AWS-managed encryption is not automatically noncompliant. Furthermore, large enterprise architectures rarely operate out of a single AWS account; they deploy multi-account landing zones using AWS Organizations, where centralized AI accounts govern foundation models, provisioned throughput, and curated knowledge bases, while distinct business unit spoke accounts consume these services.

Achieving compliance and operational excellence requires mastering AWS Key Management Service (AWS KMS) Customer Managed Keys (CMKs), key policy construction, and cross-account identity delegation.

---

AWS KMS Customer Managed Keys (CMKs) vs. AWS Managed Keys

By default, Amazon Bedrock encrypts customer assets at rest using AWS owned or AWS managed keys (such as aws/bedrock or aws/s3). However, for production workloads subject to regulatory compliance, AWS Managed Keys exhibit critical limitations:

[!IMPORTANT] When an external account must decrypt data protected by an AWS managed KMS key such as aws/s3, the key policy cannot be edited to authorize that external principal. Use a customer managed key for a cross-account resource path that requires explicit key-policy delegation. Map the exact encrypted resource; not every Bedrock cross-account invocation directly decrypts the same key.

---

KMS Integration Points Across Bedrock Components

Amazon Bedrock integrates with AWS KMS across four distinct architectural touchpoints:

1. Model Customization & Fine-Tuning

When submitting a fine-tuning or continued pre-training job:

• Input Training Data: S3 bucket objects containing training/validation JSONL data must be decryptable by the Bedrock customization execution role (kms:Decrypt, kms:DescribeKey).
• Custom Model Weights: Output model weights saved to Amazon Bedrock storage are encrypted with a designated CMK. Bedrock requires kms:GenerateDataKey, kms:Decrypt, kms:DescribeKey, and kms:CreateGrant to attach persistent encryption grants to the customized artifact.

2. Bedrock Knowledge Bases & RAG

• S3 Document Ingestion: The Knowledge Base execution role decrypts source documents during synchronization using kms:Decrypt.
• Transient Ingestion Storage: Bedrock temporarily encrypts chunked text and intermediate embeddings during processing before writing to the vector index.

3. Amazon OpenSearch Serverless (AOSS) Vector Collections

• Every AOSS collection requires an Encryption Policy.
• The encryption policy defines the KMS CMK ARN used to encrypt the vector index.
• Crucial Rule: The encryption policy must be created and bound to the collection name before the collection is created. Encryption settings cannot be modified after creation.

4. Bedrock Agents & Session Memory

• Bedrock Agents store multi-turn conversation memory and session state.
• Administrators can configure a KMS CMK to encrypt agent session data, ensuring that historical chat transcripts and transient action group tool states remain encrypted at rest.

---

Production KMS Key Policy for Bedrock

To allow Amazon Bedrock to utilize a Customer Managed Key, the KMS key policy must grant permissions to the Bedrock service principal or execution role. The following key policy demonstrates least-privilege delegation with confused deputy mitigation:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowKeyAdministration",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowBedrockServiceEncryptedAccess",
      "Effect": "Allow",
      "Principal": {
        "Service": "bedrock.amazonaws.com"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:DescribeKey",
        "kms:CreateGrant"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:bedrock:us-east-1:111122223333:*"
        }
      }
    },
    {
      "Sid": "AllowCrossAccountSpokeAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444455556666:role/SpokeApplicationRole"
      },
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

[!NOTE] Grant requirements depend on the Bedrock resource and how the key is supplied. Use the current service-role and KMS documentation for that resource, constrain kms:CreateGrant with documented conditions when it is required, and do not add it reflexively to every data key policy.

---

Cross-Account Access Patterns for Enterprise Generative AI

In modern enterprise cloud governance, organizations establish a Central AI Account (Hub) containing costly provisioned throughput deployments (e.g., Claude 3.5 Sonnet Provisioned Throughput), proprietary fine-tuned models, and standardized Knowledge Bases. Multiple Consumer Spoke Accounts (e.g., Account B: E-Commerce, Account C: Customer Service) invoke these shared resources.

┌──────────────────────────────────────────────┐
│ Consumer Spoke Account (444455556666)        │
│                                              │
│  ┌───────────────────────┐                   │
│  │ Application Lambda    │                   │
│  │ (SpokeAppRole)        │                   │
│  └──────────┬────────────┘                   │
│             │ 1. sts:AssumeRole              │
└─────────────┼────────────────────────────────┘
              ▼
┌──────────────────────────────────────────────┐
│ Central AI Account (111122223333)            │
│                                              │
│  ┌───────────────────────┐                   │
│  │ CentralBedrockRole    │                   │
│  │ (Trusts SpokeAppRole) │                   │
│  └──────────┬────────────┘                   │
│             │ 2. Calls bedrock:InvokeModel   │
│             │ 3. Uses KMS CMK Decrypt        │
│             ▼                                │
│  ┌────────────────────────────────────────┐  │
│  │ Bedrock Provisioned Throughput Model   │  │
│  │ / Central Knowledge Base               │  │
│  └────────────────────────────────────────┘  │
└──────────────────────────────────────────────┘

The Bidirectional Authorization Handshake Rule

Cross-account access in AWS requires an explicit bidirectional permission handshake. Access is denied if either side of the handshake is missing:

1. Spoke Account (Caller):
   • The application IAM role (SpokeAppRole in Account 444455556666) must have an IAM policy granting sts:AssumeRole on the central role ARN (arn:aws:iam::111122223333:role/CentralBedrockRole).
2. Central Account (Target Role Trust Policy):
   • The central IAM role (CentralBedrockRole) must have a trust policy allowing arn:aws:iam::444455556666:role/SpokeAppRole to assume it.
3. Central Account (Permissions Policy):
   • CentralBedrockRole must possess permissions to execute bedrock:InvokeModel on the provisioned model ARN or bedrock:Retrieve on the knowledge base ARN.
4. KMS Key Policy Delegation:
   • If the Bedrock model, knowledge base, or underlying S3 bucket is encrypted with a KMS CMK, the central KMS key policy must grant kms:Decrypt to CentralBedrockRole (or directly to SpokeAppRole if direct cross-account invocation is configured).

Step-by-Step Invocation Flow:

1. The spoke application calls AWS Security Token Service (STS) AssumeRole requesting temporary credentials for CentralBedrockRole.
2. STS validates the trust relationship and returns temporary security credentials (access key, secret key, and session token).
3. The spoke application initializes an Amazon Bedrock client using the assumed temporary credentials.
4. The application invokes the Bedrock model or Knowledge Base in the central account. Bedrock decrypts required artifacts using the central KMS CMK and returns the inference output.

---

Common Exam Traps & High-Stakes Scenarios

• Trap: Attempting Cross-Account S3 Sync with AWS Managed Keys (aws/s3). When building a Knowledge Base in Account A that ingests data from an S3 bucket in Account B, the S3 bucket must be encrypted with a Customer Managed Key (CMK). AWS-managed keys (aws/s3) cannot be shared across accounts, causing Knowledge Base data ingestion to fail with AccessDeniedException.
• Trap: Omitting kms:CreateGrant for Model Customization. When launching fine-tuning jobs encrypted with a KMS CMK, engineers frequently grant kms:Decrypt and kms:GenerateDataKey but omit kms:CreateGrant. The fine-tuning job will immediately fail at initialization because Bedrock cannot establish the cryptographic grant to manage the resulting model weights.
• Trap: Modifying AOSS Encryption Post-Creation. Questions testing vector database encryption often propose altering the KMS key on an existing OpenSearch Serverless collection. AOSS encryption policies can only be applied at collection creation; existing collections cannot be migrated to a new KMS key without creating a new collection and re-indexing.
• Trap: Unidirectional Cross-Account Configuration. If an exam question asks why a cross-account invocation fails despite the central role having full Bedrock permissions, verify whether the spoke account's IAM identity policy explicitly allows sts:AssumeRole on the central role. Both sides must authorize the interaction.