aws/aws-cdk

Describe the bug The convertArnPrincipalToAccountId() method in AWSSecureCDK_Peru (secure-cdk-lib/aws-cdk/packages/aws-cdk-lib/aws-logs/lib/log-group.ts) strips IAM principals down to just the AWS account ID when generating CloudWatch Logs resource policies via .grantRead(). For example, CDK generates: {"AWS": "211125612616"} But CloudFormation/AWS normalizes this to: {"AWS": "arn:aws:iam::211125612616:root"} These are semantically identical, but CloudFormation drift detection treats them as different, causing every stack that uses logGroup.grantRead() with a cross-account role to be flagged as drifted on every evaluation cycle. This is generating recurring false-positive SEV3 tickets for our team (IMDbPro-DISCO) across multiple stacks and environments: V2139077722 — IMDbListGraphQLStack (Prod) V2114817343 — IMDbListGraphQLStack (Gamma) V2096862319 — Fleet-PodMonitoringStack (Prod) V2000840049 — NotificationProcessorStack (Prod) Suggested fix: Update convertArnPrincipalToAccou

Describe the bug When using TableV2MultiAccountReplica with TableEncryptionV2.customerManagedKey(), the generated CloudFormation template is missing the top-level SSESpecification property on the AWS::DynamoDB::GlobalTable resource. This causes CloudFormation to fail with: Resource handler returned message: "Invalid request provided: ReplicaSSESpecification and SSEType must be null when SSE is set to default." Regression Issue Select this option if this issue appears to be a regression. Last Known Working CDK Library Version No response Expected Behavior The TableV2MultiAccountReplica construct should render a top-level SSESpecification with SSEEnabled: true and SSEType: "KMS" when using customer-managed key encryption, matching the behavior of TableV2: { "Type": "AWS::DynamoDB::GlobalTable", "Properties": { "TableName": "MyGlobalTable", "GlobalTableSourceArn": "arn:aws:dynamodb:us-west-2:111111111111:table/MyGlobalTable", "SSESpecification": { /* <=== this */

Describe the bug When RemovalPolicy.RETAIN_ON_UPDATE_OR_DELETE is set on DatabaseCluster, DatabaseInstance, or ServerlessCluster, the helper resources they create (subnet groups and instances) do not inherit the policy. They are silently left with CloudFormation's default Delete behavior, meaning they will attempt to be destroyed on stack deletion but usually fail because they are in use. Affected Constructs aws-cdk-lib/aws-rds.DatabaseClusterNew aws-cdk-lib/aws-rds.DatabaseInstanceNew aws-cdk-lib/aws-rds.ServerlessClusterNew ##Root Cause Found three references in RDS that compare removal policies against RemovalPolicy.RETAIN only, missing RETAIN_ON_UPDATE_OR_DELETE which was added later. helperRemovalPolicy in aws-rds/lib/private/util.ts This function determines the policy applied to helper resources (subnet groups, cluster instances). It predates RETAIN_ON_UPDATE_OR_DELETE and only handles RETAIN: https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-rds/lib/private

Describe the bug Using TableV2 with dynamo_stream=StreamViewType.NEW_IMAGE and attaching a DynamoEventSource to a Lambda produces deprecation warnings during cdk synth. The warnings originate inside CDK's own grantStreamRead() call — not from user code. There is no way to avoid them from user-land. doing cdk synth leads to warnings: Regression Issue Select this option if this issue appears to be a regression. Last Known Working CDK Library Version No response Expected Behavior No deprecation warnings when using only supported, non-deprecated APIs. Current Behavior Warnings appear once per TableV2 instance that has a DynamoEventSource attached. Reproduction Steps table = dynamodb.TableV2( self, "MyTable", partition_key=dynamodb.Attribute(name="pk", type=dynamodb.AttributeType.STRING), dynamo_stream=dynamodb.StreamViewType.NEW_IMAGE, billing=dynamodb.Billing.on_demand(), ) fn.add_event_source( lvs.DynamoEventSource( table=table, starting_position

Describe the feature The Step Functions SubmitBatchJob task automatically adds a policy to the state machine execution role to allow submitting jobs from any job definition in the account: aws-cdk/packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/batch/submit-job.ts Lines 309 to 324 in 3dd0dda private configurePolicyStatements(): iam.PolicyStatement[] { return [ // Resource level access control for job-definition requires revision which batch does not support yet // Using the alternative permissions as mentioned here: // https://docs.aws.amazon.com/batch/latest/userguide/batch-supported-iam-actions-resources.html new iam.PolicyStatement({