(aws-rds): Improve Aurora Serverless Version Support With DatabaseClusterEngine (For ParameterGroup)

See #13936 for additional context.

The CDK docs strongly recommend that you use a versioned engine when using non-serverless clusters, but are not as specific if you are using serverless clusters. So, I can create a ServerlessCluster using something like the following without issue:

cluster = rds.ServerlessCluster(
    self,
    "Database",
    engine=rds.DatabaseClusterEngine.AURORA_POSTGRESQL,
    vpc=database_stack_props["vpc"],
    backup_retention=cdk.Duration.days(7),
    default_database_name="postgres",
    deletion_protection=False,
    enable_data_api=True,
    parameter_group=rds.ParameterGroup.from_parameter_group_name(
        self, "ParameterGroup", "default.aurora-postgresql10"
    ),
    removal_policy=cdk.RemovalPolicy.SNAPSHOT,
    storage_encryption_key=kms_key,
    vpc_subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.ISOLATED),
)

However, if you wish to create a parameter group for your serverless cluster and modify some of the default settings, you cannot use from_parameter_group_name since the imported resource is not able to be mutated (and therefore rds.force_ssl wont show up in your cdk synth output). So the following won’t work:

parameter_group = rds.ParameterGroup.from_parameter_group_name(
    self, "ParameterGroup", "default.aurora-postgresql10"
)
parameter_group.add_parameter("rds.force_ssl", "1")

Additionally, you cannot use an unversioned engine as you will get an error: jsii.errors.JSIIError: ParameterGroup cannot be used with an engine that doesn't specify a version. So the following also won’t work:

parameter_group = rds.ParameterGroup(
    self,
    f"{construct_id}-ParameterGroup",
    engine=rds.DatabaseClusterEngine.AURORA_POSTGRESQL,
    parameters={
        "rds.force_ssl": "1"
    }
)

The only way I was able to create a parameter group for a serverless cluster is by using a specific named version:

parameter_group = rds.ParameterGroup(
    self,
    "ParameterGroup",
    engine=rds.DatabaseClusterEngine.aurora_postgres(
        version=rds.AuroraPostgresEngineVersion.VER_10_14
    ),
    parameters={
        "rds.force_ssl": "1"
    }
)

So, I am in a weird situation where my parameter group MUST be a named version, but my cluster doesn’t. To keep things consistent, I should be using the same version for my ParameterGroup as my ServerlessCluster.

With Aurora Serverless v1, generally there is only a single version or two that is supported (per AWS docs). For example, Aurora PostgreSQL Serverless v1 currently (as of the time of creating this issue) supports 10.12 only. Additionally, if AWS rolls out new version support, it upgrades any existing serverless clusters to that new version.

So, at the core of my problem:

1. If I don’t set a specific ServerlessCluster version, I can’t make a custom parameter group
2. If I set a specific ServerlessCluster version and Amazon bumps the supported version, my next cdk deploy could fail without any code changes

Proposed Solution(s)

1. Create new default serverless parametergroups for Serverless (so instead of default.aurora-postgresql10, I can use default.aurora-postgresql-serverless. Note this may be something beyond CDK, or there may need to be some 🧙 magic 🧙 that maps aurora-postgresql-serverless to the latest supported parameter group version of Serverless (default.aurora-postgresql10)
2. Allow rds.ParameterGroup.from_parameter_group_name to be mutated, or create a new convenience method, such as create_from_parameter_group_name

Or…

1. Add more enums to DatabaseClusterEngine or the underlying props classes like AuroraPostgresEngineVersion that tracks/follows the version that AWS has for serverless (so if I create my database and the enum resolved to10.12, and they upgrade me from 10.12 to 10.14, the enum then resolves to 10.14).

Or…

Other ideas?

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[Nicktho]

I think I have an issue that is related to this. I don’t necessarily need to create a custom ParameterGroup, although as mentioned it is recommended by AWS to specify a version for a cluster’s DatabaseClusterEngine.

If I specify the current version (10.14 as of now), my cdk deploy may break when AuroraServerless updates the minor version. On the other hand, if I don’t, and AuroraServerless updates its major version, my ParameterGroup is no longer compatible:

No engine version specification, resulting in a mismatch with default ParameterGroup when/if AuroraServerless updates their major version:

    new rds.ServerlessCluster(this, 'Cluster', {
      vpc,
      engine: rds.DatabaseClusterEngine.AURORA_POSTGRESQL,
      parameterGroup: rds.ParameterGroup.fromParameterGroupName(this, 'ParameterGroup', 'default.aurora-postgresql10'),
    });

Engine version specified, resulting in a potential failed deploy when/if AuroraServerless updates their minor version:

   new rds.ServerlessCluster(this, 'Cluster', {
      vpc,
      engine: rds.DatabaseClusterEngine.auroraPostgres({
        version: rds.AuroraPostgresEngineVersion.VER_10_14,
      }),
      parameterGroup: rds.ParameterGroup.fromParameterGroupName(this, 'ParameterGroup', 'default.aurora-postgresql10')
    });

The proposed solutions of a serverless specific default ParameterGroup solves this issue for me, as well as the proposed solution of adding another ENUM to DatabaseClusterEngine specific to serverless, as that would allow me to create a parameter group with the same version as that of the cluster.

Alternatively, if an ENUM was added to AuroraPostgresEngineVersion that referenced the latest minor version of a major version available to AuroraServerless, I could pass that in as my cluster engine with DatabaseClusterEngine.auroraPostgres, something like VER_10_SERVERLESS. Or, if a general ENUM was created to reference the current version of AuroraServerless, I wouldn’t need to pass a ParameterGroup at all, something like VER_SERVERLESS

[meragnokhiz]

Looks for me important! Please take action for the serverless approach.