DatabaseCluster: MonitoringRole not created by default when using readers and writers

[hertino76]

Describe the bug

I've a Typescript app where I developed a library to create an Aurora Mysql database, this library was created with aws-cdk v2.68, we used this to create a database in production using azure DevOps and cloudFormation (we've a functional database), we used the InstanceProps property, and then we saw a message that this element is deprecated in a new version.

Then we updated to aws-cdk v2.82, and I replaced instanceProps according to the migration recommendations just changing the location of the properties as the code below: (https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds-readme.html#migrating-from-instanceprops)

Although no other change was made, there is no way to preserve the Instance IDs when we migrated to using "Writer and Reader" elements and also use the monitoringInterval element.

` Code :

 let cluster = new rds.DatabaseCluster(scope, 'DBCluster', {
  clusterIdentifier: props.nomCluster,
  engine: rds.DatabaseClusterEngine.auroraMysql({ version: varVersion }),
  defaultDatabaseName: props.nomDB,
  credentials: rds.Credentials.fromSecret(this.dbSecret),
  parameterGroup: this.parameterGroupCluster,
  monitoringInterval: Duration.seconds(60),
  copyTagsToSnapshot: false,
  storageEncrypted: true,
  backtrackWindow: Duration.hours(6),
  backup: {
    retention: Duration.days(RetentionDays.ONE_WEEK),
    preferredWindow: '01:00-03:00',
  },
  cloudwatchLogsExports: ['audit'],
  preferredMaintenanceWindow: 'Sat:03:00-Sun:11:00',
  deletionProtection: true,
  removalPolicy: RemovalPolicy.RETAIN,
  vpc: props.vpc,
  vpcSubnets: props.vpcSubnetsData,
  securityGroups: [props.securityGroup],

  writer : rds.ClusterInstance.serverlessV2('instance1', {
    parameterGroup: this.parameterGroupInst,
    publiclyAccessible: false,
    autoMinorVersionUpgrade: true,
    allowMajorVersionUpgrade: false,
    enablePerformanceInsights: true
  }),  ...`

Then we compiled the code, and when we tried to deploy the infrastructure we got several differences with the infra deployed before, and there shouldn't be any differences, in the photo below you can see the differences show, I consider that the one that causes the problem is the first element, the MonitoringRole element which will be destroyed, even though this element was never uses in the code, which means that the application must re-create the instance when deploying and, as a result, deestroy our functional implementation.

aws diff results:

Expected Behavior

aws diff shows zero differences when I upgrade to Writer and Reader elements

Current Behavior

aws diff show theses differences :

Reproduction Steps

1. Create a library app (appA-Lib) with Typescript, npm and aws-cdk.
2. First version of "Lib" application with InstanceProps element:

import { Environment, Duration, RemovalPolicy, } from 'aws-cdk-lib'
import { RetentionDays } from 'aws-cdk-lib/aws-logs'

import * as sm from 'aws-cdk-lib/aws-secretsmanager';
import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';

export interface IAuroraDbProps {
  environment?: any,
  nomCluster: string,
  nomBD: string,
  parameterGroupCluster: any,
  parameterGroupInst: any,
  SG: any, 
  vpc: any
}

var varVersion: rds.AuroraMysqlEngineVersion;

export class AuroraDb extends Construct {
  public readonly dbSecret: sm.Secret;
  public readonly cluster: rds.DatabaseCluster;

  constructor(scope: Construct, id: string, props: IAuroraDbProps) {
    super(scope, id);

    this.dbSecret = new sm.Secret(scope, 'Secret', {
      description: 'Secret DB',
      generateSecretString: {
        secretStringTemplate: JSON.stringify({ username: 'admin2' }),
        excludePunctuation: true,
        includeSpace: false,
        generateStringKey: 'password',
        excludeCharacters: '/@"\' '      }
    });

    varVersion = rds.AuroraMysqlEngineVersion.VER_3_02_1;
    
    let cluster = new rds.DatabaseCluster(scope, 'ClusterDB', {
      clusterIdentifier: `${props.nomCluster}`,
      engine: rds.DatabaseClusterEngine.auroraMysql({ version: varVersion }),
      defaultDatabaseName: props.nomBD,
      instances: 2,
      credentials: rds.Credentials.fromSecret(this.dbSecret),
      parameterGroup: this.parameterGroupCluster,

      monitoringInterval: Duration.seconds(60),
      copyTagsToSnapshot: false,
      storageEncrypted: true,
      backtrackWindow: Duration.hours(6),
      backup: {
        retention: Duration.days(RetentionDays.ONE_WEEK),
        preferredWindow: '01:00-03:00',
      },
      cloudwatchLogsExports: ['audit'],
      preferredMaintenanceWindow: 'Sat:03:00-Sun:11:00',,
      deletionProtection: true,
      removalPolicy: RemovalPolicy.RETAIN,

      instanceProps: {
        instanceType: new ec2.InstanceType('serverless'),
        vpc: props.vpc,
        vpcSubnets: props.vpcSubnetsData,
        securityGroups: [props.securityGroup],
        parameterGroup: this.parameterGroupInst,
        publiclyAccessible: false,
        autoMinorVersionUpgrade: true,
        allowMajorVersionUpgrade: false,
        enablePerformanceInsights: true        
      }
    });
}
}

3. Build the library version.
4. Create a Typescript applicaton (appB) using the created library and deploy a database with this code.
5. Upgate to aws-cdk v2.82 (although I believe that the initial version may be v2.82)
6. Second version of the Library application using Writer and Reader elements:

import { Environment, Duration, RemovalPolicy, } from 'aws-cdk-lib'
import { RetentionDays } from 'aws-cdk-lib/aws-logs'

import * as sm from 'aws-cdk-lib/aws-secretsmanager';
import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';

export interface IAuroraDbProps {
  environment?: any,
  nomCluster: string,
  nomBD: string,
  parameterGroupCluster: any,
  parameterGroupInst: any,
  SG: any, 
  vpc: any
}

var varVersion: rds.AuroraMysqlEngineVersion;

export class AuroraDb extends Construct {
  public readonly dbSecret: sm.Secret;
  public readonly cluster: rds.DatabaseCluster;

  constructor(scope: Construct, id: string, props: IAuroraDbProps) {
    super(scope, id);

    this.dbSecret = new sm.Secret(scope, 'Secret', {
      description: 'Secret DB',
      generateSecretString: {
        secretStringTemplate: JSON.stringify({ username: 'admin2' }),
        excludePunctuation: true,
        includeSpace: false,
        generateStringKey: 'password',
        excludeCharacters: '/@"\' '      }
    });

    varVersion = rds.AuroraMysqlEngineVersion.VER_3_02_1;
    
    let cluster = new rds.DatabaseCluster(scope, 'ClusterDB', {
      clusterIdentifier: `${props.nomCluster}`,
      engine: rds.DatabaseClusterEngine.auroraMysql({ version: varVersion }),
      defaultDatabaseName: props.nomBD,
      credentials: rds.Credentials.fromSecret(this.dbSecret),
      parameterGroup: this.parameterGroupCluster,

      monitoringInterval: Duration.seconds(60),
      copyTagsToSnapshot: false,
      storageEncrypted: true,
      backtrackWindow: Duration.hours(6),
      backup: {
        retention: Duration.days(RetentionDays.ONE_WEEK),
        preferredWindow: '01:00-03:00',
      },
      cloudwatchLogsExports: ['audit'],
      preferredMaintenanceWindow: 'Sat:03:00-Sun:11:00',,
      deletionProtection: true,
      removalPolicy: RemovalPolicy.RETAIN,

      writer : rds.ClusterInstance.serverlessV2(`${props.nomCluster}` + 'instance1', {
        parameterGroup: this.parameterGroupInst,
        publiclyAccessible: false,
        autoMinorVersionUpgrade: true,
        allowMajorVersionUpgrade: false,
        enablePerformanceInsights: true
      }),
    readers : [
        rds.ClusterInstance.serverlessV2(`${props.nomCluster}` + 'instance2', {scaleWithWriter: true}),
      ],
      serverlessV2MinCapacity: minCap,
      serverlessV2MaxCapacity: maxCap,

    });
}
}

8. Build the library version.
9. Update the application (appB) using the new version of the library.
10. Try to deploy a Aurora MySql database with this code --> you will get Differences

Possible Solution

Check why aws-cdk finds differences in the MonitoringRole element when we update these elements and we use monitoringInterval. The problem isn't version 2.82 itself, because I did a test with this version without changing the InstanceProps element and the deployment works fine, the error doesn't show up until I change the element to Writer.

Additional Information/Context

No response

CDK CLI Version

2.82.0 (build 3a8648a)

Framework Version

No response

Node.js Version

npm: '9.3.1', node: '18.14.0',

OS

Windows 10 Entreprise 21H2

Language

Typescript

Language Version

Version 5.0.4

Other information

No response

[peterwoodworth]

I think that you can use the instanceIdentifiers property to make sure the instance logical IDs don't get replaced.

Regards to the monitoring role - it appears that one is not automatically created when using the new API. In the modern _createInstances method, we only pass in the monitoring role that was passed in as a prop - the bind method won't automatically create a monitoring role under the hood

aws-cdk/packages/aws-cdk-lib/aws-rds/lib/cluster.ts

Line 642 in 006b542

monitoringRole: props.monitoringRole,

To contrast, in the legacy code the role gets created if not passed in

aws-cdk/packages/aws-cdk-lib/aws-rds/lib/cluster.ts

Line 1248 in 006b542

monitoringRole = props.monitoringRole || new Role(cluster, 'MonitoringRole', {

Thanks for reporting!

[hertino76]

I could clarify that when we first deployed the database with cdk before using writers and readers, the application created a default Monitoring role, with the new implementation it tries to destroy it.

[hertino76]

Please let me know if this issue is fixed and if it is implemented in the "Bug Fix" version of aws-cdk, because I saw something that looks like a bug in the Pull Request.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.