Amazon Relational Database Service Construct Library

import aws_cdk.aws_rds as rds

Starting a clustered database

To set up a clustered database (like Aurora), define a DatabaseCluster. You must always launch a database in a VPC. Use the vpcSubnets attribute to control whether your instances will be launched privately or publicly:

You must specify the instance to use as the writer, along with an optional list of readers (up to 15).

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    credentials=rds.Credentials.from_generated_secret("clusteradmin"),  # Optional - will default to 'admin' username and generated password
    writer=rds.ClusterInstance.provisioned("writer",
        publicly_accessible=False
    ),
    readers=[
        rds.ClusterInstance.provisioned("reader1", promotion_tier=1),
        rds.ClusterInstance.serverless_v2("reader2")
    ],
    vpc_subnets=ec2.SubnetSelection(
        subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS
    ),
    vpc=vpc
)

To adopt Aurora I/O-Optimized, specify DBClusterStorageType.AURORA_IOPT1 on the storageType property.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_postgres(version=rds.AuroraPostgresEngineVersion.VER_15_2),
    credentials=rds.Credentials.from_username("adminuser", password=SecretValue.unsafe_plain_text("7959866cacc02c2d243ecfe177464fe6")),
    writer=rds.ClusterInstance.provisioned("writer",
        publicly_accessible=False
    ),
    readers=[
        rds.ClusterInstance.provisioned("reader")
    ],
    storage_type=rds.DBClusterStorageType.AURORA_IOPT1,
    vpc_subnets=ec2.SubnetSelection(
        subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS
    ),
    vpc=vpc
)

If there isn’t a constant for the exact version you want to use, all of the Version classes have a static of method that can be used to create an arbitrary version.

custom_engine_version = rds.AuroraMysqlEngineVersion.of("5.7.mysql_aurora.2.08.1")

By default, the master password will be generated and stored in AWS Secrets Manager with auto-generated description.

Your cluster will be empty by default. To add a default database upon construction, specify the defaultDatabaseName attribute.

To use dual-stack mode, specify NetworkType.DUAL on the networkType property:

# vpc: ec2.Vpc
# VPC and subnets must have IPv6 CIDR blocks
cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_02_1),
    writer=rds.ClusterInstance.provisioned("writer",
        publicly_accessible=False
    ),
    vpc=vpc,
    network_type=rds.NetworkType.DUAL
)

For more information about dual-stack mode, see Working with a DB cluster in a VPC.

If you want to issue read/write transactions directly on an Aurora Replica, you can use local write forwarding on Aurora MySQL and Aurora PostgreSQL. Local write forwarding allows read replicas to accept write transactions and forward them to the writer DB instance to be committed.

To enable local write forwarding, set the enableLocalWriteForwarding property to true:

# vpc: ec2.IVpc


rds.DatabaseCluster(self, "DatabaseCluster",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_07_0),
    writer=rds.ClusterInstance.serverless_v2("writerInstance"),
    readers=[
        rds.ClusterInstance.serverless_v2("readerInstance1")
    ],
    vpc=vpc,
    enable_local_write_forwarding=True
)

Note: Local write forwarding is supported only for Aurora MySQL 3.04 or higher, and for Aurora PostgreSQL 16.4 or higher (for version 16), 15.8 or higher (for version 15), and 14.13 or higher (for version 14).

Use DatabaseClusterFromSnapshot to create a cluster from a snapshot:

# vpc: ec2.Vpc

rds.DatabaseClusterFromSnapshot(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora(version=rds.AuroraEngineVersion.VER_1_22_2),
    writer=rds.ClusterInstance.provisioned("writer"),
    vpc=vpc,
    snapshot_identifier="mySnapshot"
)

By default, automatic minor version upgrades for the engine type are enabled in a cluster, but you can also disable this. To do so, set autoMinorVersionUpgrade to false.

# vpc: ec2.IVpc


rds.DatabaseCluster(self, "DatabaseCluster",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_07_0),
    writer=rds.ClusterInstance.serverless_v2("writerInstance"),
    vpc=vpc,
    auto_minor_version_upgrade=False
)

Updating the database instances in a cluster

Database cluster instances may be updated in bulk or on a rolling basis.

An update to all instances in a cluster may cause significant downtime. To reduce the downtime, set the instanceUpdateBehavior property in DatabaseClusterBaseProps to InstanceUpdateBehavior.ROLLING. This adds a dependency between each instance so the update is performed on only one instance at a time.

Use InstanceUpdateBehavior.BULK to update all instances at once.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.provisioned("Instance",
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.SMALL)
    ),
    readers=[rds.ClusterInstance.provisioned("reader")],
    instance_update_behaviour=rds.InstanceUpdateBehaviour.ROLLING,  # Optional - defaults to rds.InstanceUpdateBehaviour.BULK
    vpc=vpc
)

Serverless V2 instances in a Cluster

It is possible to create an RDS cluster with both serverlessV2 and provisioned instances. For example, this will create a cluster with a provisioned writer and a serverless v2 reader.

Note Before getting starting with this type of cluster it is highly recommended that you read through the Developer Guide which goes into much more detail on the things you need to take into consideration.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.provisioned("writer"),
    readers=[
        rds.ClusterInstance.serverless_v2("reader")
    ],
    vpc=vpc
)

Monitoring

There are some CloudWatch metrics that are important for Aurora Serverless v2.

ServerlessDatabaseCapacity: An instance-level metric that can also be evaluated at the cluster level. At the cluster-level it represents the average capacity of all the instances in the cluster.
ACUUtilization: Value of the ServerlessDatabaseCapacity/ max ACU of the cluster.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.provisioned("writer"),
    readers=[
        rds.ClusterInstance.serverless_v2("reader")
    ],
    vpc=vpc
)

cluster.metric_serverless_database_capacity(
    period=Duration.minutes(10)
).create_alarm(self, "capacity",
    threshold=1.5,
    evaluation_periods=3
)
cluster.metric_aCUUtilization(
    period=Duration.minutes(10)
).create_alarm(self, "alarm",
    evaluation_periods=3,
    threshold=90
)

Capacity & Scaling

There are some things to take into consideration with Aurora Serverless v2.

To create a cluster that can support serverless v2 instances you configure a minimum and maximum capacity range on the cluster. This is an example showing the default values:

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.serverless_v2("writer"),
    serverless_v2_min_capacity=0.5,
    serverless_v2_max_capacity=2,
    vpc=vpc
)

The capacity is defined as a number of Aurora capacity units (ACUs). You can specify in half-step increments (40, 40.5, 41, etc). Each serverless instance in the cluster inherits the capacity that is defined on the cluster. It is not possible to configure separate capacity at the instance level.

The maximum capacity is mainly used for budget control since it allows you to set a cap on how high your instance can scale.

The minimum capacity is a little more involved. This controls a couple different things.

The scale-up rate is proportional to the current capacity (larger instances scale up faster)
- Adjust the minimum capacity to obtain a suitable scaling rate
Network throughput is proportional to capacity

Info More complete details can be found in the docs

You can also set minimum capacity to zero ACUs and automatically pause, if they don’t have any connections initiated by user activity within a specified time period. For more information, see Scaling to Zero ACUs with automatic pause and resume for Aurora Serverless v2.

Another way that you control the capacity/scaling of your serverless v2 reader instances is based on the promotion tier which can be between 0-15. Any serverless v2 instance in the 0-1 tiers will scale alongside the writer even if the current read load does not require the capacity. This is because instances in the 0-1 tier are first priority for failover and Aurora wants to ensure that in the event of a failover the reader that gets promoted is scaled to handle the write load.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.serverless_v2("writer"),
    readers=[
        # will be put in promotion tier 1 and will scale with the writer
        rds.ClusterInstance.serverless_v2("reader1", scale_with_writer=True),
        # will be put in promotion tier 2 and will not scale with the writer
        rds.ClusterInstance.serverless_v2("reader2")
    ],
    vpc=vpc
)

When the writer scales up, any readers in tier 0-1 will scale up to match
Scaling for tier 2-15 is independent of what is happening on the writer
Readers in tier 2-15 scale up based on read load against the individual reader

When configuring your cluster it is important to take this into consideration and ensure that in the event of a failover there is an instance that is scaled up to take over.

Mixing Serverless v2 and Provisioned instances

You are able to create a cluster that has both provisioned and serverless instances. This blog post has an excellent guide on choosing between serverless and provisioned instances based on use case.

There are a couple of high level differences:

Engine Version (serverless only supports MySQL 8+ & PostgreSQL 13+)
Memory up to 256GB can be supported by serverless

Provisioned writer

With a provisioned writer and serverless v2 readers, some of the serverless readers will need to be configured to scale with the writer so they can act as failover targets. You will need to determine the correct capacity based on the provisioned instance type and it’s utilization.

As an example, if the CPU utilization for a db.r6g.4xlarge (128 GB) instance stays at 10% most times, then the minimum ACUs may be set at 6.5 ACUs (10% of 128 GB) and maximum may be set at 64 ACUs (64x2GB=128GB). Keep in mind that the speed at which the serverless instance can scale up is determined by the minimum capacity so if your cluster has spiky workloads you may need to set a higher minimum capacity.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.provisioned("writer",
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.R6G, ec2.InstanceSize.XLARGE4)
    ),
    serverless_v2_min_capacity=6.5,
    serverless_v2_max_capacity=64,
    readers=[
        # will be put in promotion tier 1 and will scale with the writer
        rds.ClusterInstance.serverless_v2("reader1", scale_with_writer=True),
        # will be put in promotion tier 2 and will not scale with the writer
        rds.ClusterInstance.serverless_v2("reader2")
    ],
    vpc=vpc
)

In the above example reader1 will scale with the writer based on the writer’s utilization. So if the writer were to go to 50% utilization then reader1 would scale up to use 32 ACUs. If the read load stayed consistent then reader2 may remain at 6.5 since it is not configured to scale with the writer.

If one of your Aurora Serverless v2 DB instances consistently reaches the limit of its maximum capacity, Aurora indicates this condition by setting the DB instance to a status of incompatible-parameters. While the DB instance has the incompatible-parameters status, some operations are blocked. For example, you can’t upgrade the engine version.

CA certificate

Use the caCertificate property to specify the CA certificates to use for a cluster instances:

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.provisioned("writer",
        ca_certificate=rds.CaCertificate.RDS_CA_RSA2048_G1
    ),
    readers=[
        rds.ClusterInstance.serverless_v2("reader",
            ca_certificate=rds.CaCertificate.of("custom-ca")
        )
    ],
    vpc=vpc
)

Scheduling modifications

To schedule modifications to database instances in the next scheduled maintenance window, specify applyImmediately to false in the instance props:

# vpc: ec2.Vpc

rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_01_0),
    writer=rds.ClusterInstance.provisioned("writer",
        apply_immediately=False
    ),
    readers=[
        rds.ClusterInstance.serverless_v2("reader",
            apply_immediately=False
        )
    ],
    vpc=vpc
)

Until RDS applies the changes, the DB instance remains in a drift state. As a result, the configuration doesn’t fully reflect the requested modifications and temporarily diverges from the intended state.

Currently, CloudFormation does not support to schedule modifications of the cluster configurations. To apply changes of the cluster, such as engine version, in the next scheduled maintenance window, you should use modify-db-cluster CLI command or management console.

For details, see Modifying an Amazon Aurora DB cluster.

Migrating from instanceProps

Creating instances in a DatabaseCluster using instanceProps & instances is deprecated. To migrate to the new properties you can provide the isFromLegacyInstanceProps property.

For example, in order to migrate from this deprecated config:

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    instances=2,
    instance_props=rds.InstanceProps(
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.SMALL),
        vpc_subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PUBLIC),
        vpc=vpc
    )
)

You would need to migrate to this. The old method of providing instanceProps and instances will create the number of instances that you provide. The first instance will be the writer and the rest will be the readers. It’s important that the id that you provide is Instance{NUMBER}. The writer should always be Instance1 and the readers will increment from there.

Make sure to run a cdk diff before deploying to make sure that all changes are expected. Always test the migration in a non-production environment first.

# vpc: ec2.Vpc
instance_props = {
    "instance_type": ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.SMALL),
    "is_from_legacy_instance_props": True
}
cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    vpc_subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PUBLIC),
    vpc=vpc,
    writer=rds.ClusterInstance.provisioned("Instance1",
        instance_type=instance_props.instance_type,
        is_from_legacy_instance_props=instance_props.is_from_legacy_instance_props
    ),
    readers=[
        rds.ClusterInstance.provisioned("Instance2",
            instance_type=instance_props.instance_type,
            is_from_legacy_instance_props=instance_props.is_from_legacy_instance_props
        )
    ]
)

Creating a read replica cluster

Use replicationSourceIdentifier to create a read replica cluster:

# vpc: ec2.Vpc
# primary_cluster: rds.DatabaseCluster


rds.DatabaseCluster(self, "DatabaseCluster",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    writer=rds.ClusterInstance.serverless_v2("Writer"),
    vpc=vpc,
    replication_source_identifier=primary_cluster.cluster_arn
)

Note: Cannot create a read replica cluster with credentials as the value is inherited from the source DB cluster.

Starting an instance database

To set up an instance database, define a DatabaseInstance. You must always launch a database in a VPC. Use the vpcSubnets attribute to control whether your instances will be launched privately or publicly:

# vpc: ec2.Vpc

instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.oracle_se2(version=rds.OracleEngineVersion.VER_19_0_0_0_2020_04_R1),
    # optional, defaults to m5.large
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.SMALL),
    credentials=rds.Credentials.from_generated_secret("syscdk"),  # Optional - will default to 'admin' username and generated password
    vpc=vpc,
    vpc_subnets=ec2.SubnetSelection(
        subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS
    )
)

If there isn’t a constant for the exact engine version you want to use, all of the Version classes have a static of method that can be used to create an arbitrary version.

custom_engine_version = rds.OracleEngineVersion.of("19.0.0.0.ru-2020-04.rur-2020-04.r1", "19")

By default, the master password will be generated and stored in AWS Secrets Manager.

To use the storage auto scaling option of RDS you can specify the maximum allocated storage. This is the upper limit to which RDS can automatically scale the storage. More info can be found here Example for max storage configuration:

# vpc: ec2.Vpc

instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.postgres(version=rds.PostgresEngineVersion.VER_16_3),
    # optional, defaults to m5.large
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.SMALL),
    vpc=vpc,
    max_allocated_storage=200
)

To use dual-stack mode, specify NetworkType.DUAL on the networkType property:

# vpc: ec2.Vpc
# VPC and subnets must have IPv6 CIDR blocks
instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.postgres(version=rds.PostgresEngineVersion.VER_16_3),
    vpc=vpc,
    network_type=rds.NetworkType.DUAL,
    publicly_accessible=False
)

For more information about dual-stack mode, see Working with a DB instance in a VPC.

Use DatabaseInstanceFromSnapshot and DatabaseInstanceReadReplica to create an instance from snapshot or a source database respectively:

# vpc: ec2.Vpc

# source_instance: rds.DatabaseInstance

rds.DatabaseInstanceFromSnapshot(self, "Instance",
    snapshot_identifier="my-snapshot",
    engine=rds.DatabaseInstanceEngine.postgres(version=rds.PostgresEngineVersion.VER_16_3),
    # optional, defaults to m5.large
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.LARGE),
    vpc=vpc
)
rds.DatabaseInstanceReadReplica(self, "ReadReplica",
    source_database_instance=source_instance,
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.LARGE),
    vpc=vpc
)

Automatic backups of read replica instances are only supported for MySQL and MariaDB. By default, automatic backups are disabled for read replicas and can only be enabled (using backupRetention) if also enabled on the source instance.

Creating a “production” Oracle database instance with option and parameter groups:

# Set open cursors with parameter group
parameter_group = rds.ParameterGroup(self, "ParameterGroup",
    engine=rds.DatabaseInstanceEngine.oracle_se2(version=rds.OracleEngineVersion.VER_19_0_0_0_2020_04_R1),
    parameters={
        "open_cursors": "2500"
    }
)

option_group = rds.OptionGroup(self, "OptionGroup",
    engine=rds.DatabaseInstanceEngine.oracle_se2(version=rds.OracleEngineVersion.VER_19_0_0_0_2020_04_R1),
    configurations=[cdk.aws_rds.OptionConfiguration(
        name="LOCATOR"
    ), cdk.aws_rds.OptionConfiguration(
        name="OEM",
        port=1158,
        vpc=vpc
    )
    ]
)

# Allow connections to OEM
option_group.option_connections.OEM.connections.allow_default_port_from_any_ipv4()

# Database instance with production values
instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.oracle_se2(version=rds.OracleEngineVersion.VER_19_0_0_0_2020_04_R1),
    license_model=rds.LicenseModel.BRING_YOUR_OWN_LICENSE,
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.MEDIUM),
    multi_az=True,
    storage_type=rds.StorageType.IO1,
    credentials=rds.Credentials.from_username("syscdk"),
    vpc=vpc,
    database_name="ORCL",
    storage_encrypted=True,
    backup_retention=cdk.Duration.days(7),
    monitoring_interval=cdk.Duration.seconds(60),
    enable_performance_insights=True,
    cloudwatch_logs_exports=["trace", "audit", "alert", "listener"
    ],
    cloudwatch_logs_retention=logs.RetentionDays.ONE_MONTH,
    auto_minor_version_upgrade=True,  # required to be true if LOCATOR is used in the option group
    option_group=option_group,
    parameter_group=parameter_group,
    removal_policy=RemovalPolicy.DESTROY
)

# Allow connections on default port from any IPV4
instance.connections.allow_default_port_from_any_ipv4()

# Rotate the master user password every 30 days
instance.add_rotation_single_user()

# Add alarm for high CPU
cloudwatch.Alarm(self, "HighCPU",
    metric=instance.metric_cPUUtilization(),
    threshold=90,
    evaluation_periods=1
)

# Trigger Lambda function on instance availability events
fn = lambda_.Function(self, "Function",
    code=lambda_.Code.from_inline("exports.handler = (event) => console.log(event);"),
    handler="index.handler",
    runtime=lambda_.Runtime.NODEJS_18_X
)

availability_rule = instance.on_event("Availability", target=targets.LambdaFunction(fn))
availability_rule.add_event_pattern(
    detail={
        "EventCategories": ["availability"
        ]
    }
)

Add XMLDB and OEM with option group

# Set open cursors with parameter group
parameter_group = rds.ParameterGroup(self, "ParameterGroup",
    engine=rds.DatabaseInstanceEngine.oracle_se2(version=rds.OracleEngineVersion.VER_19_0_0_0_2020_04_R1),
    parameters={
        "open_cursors": "2500"
    }
)

option_group = rds.OptionGroup(self, "OptionGroup",
    engine=rds.DatabaseInstanceEngine.oracle_se2(version=rds.OracleEngineVersion.VER_19_0_0_0_2020_04_R1),
    configurations=[cdk.aws_rds.OptionConfiguration(
        name="LOCATOR"
    ), cdk.aws_rds.OptionConfiguration(
        name="OEM",
        port=1158,
        vpc=vpc
    )
    ]
)

# Allow connections to OEM
option_group.option_connections.OEM.connections.allow_default_port_from_any_ipv4()

# Database instance with production values
instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.oracle_se2(version=rds.OracleEngineVersion.VER_19_0_0_0_2020_04_R1),
    license_model=rds.LicenseModel.BRING_YOUR_OWN_LICENSE,
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.MEDIUM),
    multi_az=True,
    storage_type=rds.StorageType.IO1,
    credentials=rds.Credentials.from_username("syscdk"),
    vpc=vpc,
    database_name="ORCL",
    storage_encrypted=True,
    backup_retention=cdk.Duration.days(7),
    monitoring_interval=cdk.Duration.seconds(60),
    enable_performance_insights=True,
    cloudwatch_logs_exports=["trace", "audit", "alert", "listener"
    ],
    cloudwatch_logs_retention=logs.RetentionDays.ONE_MONTH,
    auto_minor_version_upgrade=True,  # required to be true if LOCATOR is used in the option group
    option_group=option_group,
    parameter_group=parameter_group,
    removal_policy=RemovalPolicy.DESTROY
)

# Allow connections on default port from any IPV4
instance.connections.allow_default_port_from_any_ipv4()

# Rotate the master user password every 30 days
instance.add_rotation_single_user()

# Add alarm for high CPU
cloudwatch.Alarm(self, "HighCPU",
    metric=instance.metric_cPUUtilization(),
    threshold=90,
    evaluation_periods=1
)

# Trigger Lambda function on instance availability events
fn = lambda_.Function(self, "Function",
    code=lambda_.Code.from_inline("exports.handler = (event) => console.log(event);"),
    handler="index.handler",
    runtime=lambda_.Runtime.NODEJS_18_X
)

availability_rule = instance.on_event("Availability", target=targets.LambdaFunction(fn))
availability_rule.add_event_pattern(
    detail={
        "EventCategories": ["availability"
        ]
    }
)

Use the storageType property to specify the type of storage to use for the instance:

# vpc: ec2.Vpc


iops_instance = rds.DatabaseInstance(self, "IopsInstance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_39),
    vpc=vpc,
    storage_type=rds.StorageType.IO1,
    iops=5000
)

gp3_instance = rds.DatabaseInstance(self, "Gp3Instance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_39),
    vpc=vpc,
    allocated_storage=500,
    storage_type=rds.StorageType.GP3,
    storage_throughput=500
)

Use the allocatedStorage property to specify the amount of storage (in gigabytes) that is initially allocated for the instance to use for the instance:

# vpc: ec2.Vpc

# Setting allocatedStorage for DatabaseInstance replica
# Note: If allocatedStorage isn't set here, the replica instance will inherit the allocatedStorage of the source instance
# source_instance: rds.DatabaseInstance


# Setting allocatedStorage for DatabaseInstance
iops_instance = rds.DatabaseInstance(self, "IopsInstance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_39),
    vpc=vpc,
    storage_type=rds.StorageType.IO1,
    iops=5000,
    allocated_storage=500
)
rds.DatabaseInstanceReadReplica(self, "ReadReplica",
    source_database_instance=source_instance,
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE2, ec2.InstanceSize.LARGE),
    vpc=vpc,
    allocated_storage=500
)

Use the caCertificate property to specify the CA certificates to use for the instance:

# vpc: ec2.Vpc


rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_39),
    vpc=vpc,
    ca_certificate=rds.CaCertificate.RDS_CA_RSA2048_G1
)

You can specify a custom CA certificate with:

# vpc: ec2.Vpc


rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_39),
    vpc=vpc,
    ca_certificate=rds.CaCertificate.of("future-rds-ca")
)

Scheduling modifications

To schedule modifications in the next scheduled maintenance window, specify applyImmediately to false:

# vpc: ec2.Vpc

rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_39),
    vpc=vpc,
    apply_immediately=False
)

Until RDS applies the changes, the DB instance remains in a drift state. As a result, the configuration doesn’t fully reflect the requested modifications and temporarily diverges from the intended state.

For details, see Using the schedule modifications setting.

Setting Public Accessibility

You can set public accessibility for the DatabaseInstance or the ClusterInstance using the publiclyAccessible property. If you specify true, it creates an instance with a publicly resolvable DNS name, which resolves to a public IP address. If you specify false, it creates an internal instance with a DNS name that resolves to a private IP address.

The default value will be true if vpcSubnets is subnetType: SubnetType.PUBLIC, false otherwise. In the case of a cluster, the default value will be determined on the vpc placement of the DatabaseCluster otherwise it will be determined based on the vpc placement of standalone DatabaseInstance.

# vpc: ec2.Vpc

# Setting public accessibility for DB instance
rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.mysql(
        version=rds.MysqlEngineVersion.VER_8_0_19
    ),
    vpc=vpc,
    vpc_subnets=ec2.SubnetSelection(
        subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS
    ),
    publicly_accessible=True
)

# Setting public accessibility for DB cluster instance
rds.DatabaseCluster(self, "DatabaseCluster",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    writer=rds.ClusterInstance.serverless_v2("Writer",
        publicly_accessible=True
    ),
    vpc=vpc,
    vpc_subnets=ec2.SubnetSelection(
        subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS
    )
)

Instance events

To define Amazon CloudWatch event rules for database instances, use the onEvent method:

# instance: rds.DatabaseInstance
# fn: lambda.Function

rule = instance.on_event("InstanceEvent", target=targets.LambdaFunction(fn))

Login credentials

By default, database instances and clusters (with the exception of DatabaseInstanceFromSnapshot and ServerlessClusterFromSnapshot) will have admin user with an auto-generated password. An alternative username (and password) may be specified for the admin user instead of the default.

The following examples use a DatabaseInstance, but the same usage is applicable to DatabaseCluster.

# vpc: ec2.Vpc

engine = rds.DatabaseInstanceEngine.postgres(version=rds.PostgresEngineVersion.VER_16_3)
rds.DatabaseInstance(self, "InstanceWithUsername",
    engine=engine,
    vpc=vpc,
    credentials=rds.Credentials.from_generated_secret("postgres")
)

rds.DatabaseInstance(self, "InstanceWithUsernameAndPassword",
    engine=engine,
    vpc=vpc,
    credentials=rds.Credentials.from_password("postgres", SecretValue.ssm_secure("/dbPassword", "1"))
)

my_secret = secretsmanager.Secret.from_secret_name(self, "DBSecret", "myDBLoginInfo")
rds.DatabaseInstance(self, "InstanceWithSecretLogin",
    engine=engine,
    vpc=vpc,
    credentials=rds.Credentials.from_secret(my_secret)
)

Secrets generated by fromGeneratedSecret() can be customized:

# vpc: ec2.Vpc

engine = rds.DatabaseInstanceEngine.postgres(version=rds.PostgresEngineVersion.VER_16_3)
my_key = kms.Key(self, "MyKey")

rds.DatabaseInstance(self, "InstanceWithCustomizedSecret",
    engine=engine,
    vpc=vpc,
    credentials=rds.Credentials.from_generated_secret("postgres",
        secret_name="my-cool-name",
        encryption_key=my_key,
        exclude_characters="!&*^#@()",
        replica_regions=[secretsmanager.ReplicaRegion(region="eu-west-1"), secretsmanager.ReplicaRegion(region="eu-west-2")]
    )
)

Snapshot credentials

As noted above, Databases created with DatabaseInstanceFromSnapshot or ServerlessClusterFromSnapshot will not create user and auto-generated password by default because it’s not possible to change the master username for a snapshot. Instead, they will use the existing username and password from the snapshot. You can still generate a new password - to generate a secret similarly to the other constructs, pass in credentials with fromGeneratedSecret() or fromGeneratedPassword().

# vpc: ec2.Vpc

engine = rds.DatabaseInstanceEngine.postgres(version=rds.PostgresEngineVersion.VER_16_3)
my_key = kms.Key(self, "MyKey")

rds.DatabaseInstanceFromSnapshot(self, "InstanceFromSnapshotWithCustomizedSecret",
    engine=engine,
    vpc=vpc,
    snapshot_identifier="mySnapshot",
    credentials=rds.SnapshotCredentials.from_generated_secret("username",
        encryption_key=my_key,
        exclude_characters="!&*^#@()",
        replica_regions=[secretsmanager.ReplicaRegion(region="eu-west-1"), secretsmanager.ReplicaRegion(region="eu-west-2")]
    )
)

Connecting

To control who can access the cluster or instance, use the .connections attribute. RDS databases have a default port, so you don’t need to specify the port:

# cluster: rds.DatabaseCluster

cluster.connections.allow_from_any_ipv4(ec2.Port.all_traffic(), "Open to the world")

The endpoints to access your database cluster will be available as the .clusterEndpoint and .readerEndpoint attributes:

# cluster: rds.DatabaseCluster

write_address = cluster.cluster_endpoint.socket_address

For an instance database:

# instance: rds.DatabaseInstance

address = instance.instance_endpoint.socket_address

Rotating credentials

When the master password is generated and stored in AWS Secrets Manager, it can be rotated automatically:

# instance: rds.DatabaseInstance
# my_security_group: ec2.SecurityGroup


instance.add_rotation_single_user(
    automatically_after=Duration.days(7),  # defaults to 30 days
    exclude_characters="!@#$%^&*",  # defaults to the set " %+~`#/// here*()|[]{}:;<>?!'/@\"\\"
    security_group=my_security_group
)

cluster = rds.DatabaseCluster(stack, "Database",
    engine=rds.DatabaseClusterEngine.AURORA,
    instance_props=cdk.aws_rds.InstanceProps(
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.SMALL),
        vpc=vpc
    )
)

cluster.add_rotation_single_user()

cluster_with_custom_rotation_options = rds.DatabaseCluster(stack, "CustomRotationOptions",
    engine=rds.DatabaseClusterEngine.AURORA,
    instance_props=cdk.aws_rds.InstanceProps(
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.SMALL),
        vpc=vpc
    )
)
cluster_with_custom_rotation_options.add_rotation_single_user(
    automatically_after=cdk.Duration.days(7),
    exclude_characters="!@#$%^&*",
    security_group=security_group,
    vpc_subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS),
    endpoint=endpoint
)

The multi user rotation scheme is also available:

# instance: rds.DatabaseInstance
# my_imported_secret: rds.DatabaseSecret

instance.add_rotation_multi_user("MyUser",
    secret=my_imported_secret
)

It’s also possible to create user credentials together with the instance/cluster and add rotation:

# instance: rds.DatabaseInstance

my_user_secret = rds.DatabaseSecret(self, "MyUserSecret",
    username="myuser",
    secret_name="my-user-secret",  # optional, defaults to a CloudFormation-generated name
    dbname="mydb",  # optional, defaults to the main database of the RDS cluster this secret gets attached to
    master_secret=instance.secret,
    exclude_characters="{}[]()'\"/\\"
)
my_user_secret_attached = my_user_secret.attach(instance) # Adds DB connections information in the secret

instance.add_rotation_multi_user("MyUser",  # Add rotation using the multi user scheme
    secret=my_user_secret_attached)

Note: This user must be created manually in the database using the master credentials. The rotation will start as soon as this user exists.

Access to the Secrets Manager API is required for the secret rotation. This can be achieved either with internet connectivity (through NAT) or with a VPC interface endpoint. By default, the rotation Lambda function is deployed in the same subnets as the instance/cluster. If access to the Secrets Manager API is not possible from those subnets or using the default API endpoint, use the vpcSubnets and/or endpoint options:

# instance: rds.DatabaseInstance
# my_endpoint: ec2.InterfaceVpcEndpoint


instance.add_rotation_single_user(
    vpc_subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS),  # Place rotation Lambda in private subnets
    endpoint=my_endpoint
)

See also aws-cdk-lib/aws-secretsmanager for credentials rotation of existing clusters/instances.

By default, any stack updates will cause AWS Secrets Manager to rotate a secret immediately. To prevent this behavior and wait until the next scheduled rotation window specified via the automaticallyAfter property, set the rotateImmediatelyOnUpdate property to false:

# instance: rds.DatabaseInstance
# my_security_group: ec2.SecurityGroup


instance.add_rotation_single_user(
    automatically_after=Duration.days(7),  # defaults to 30 days
    exclude_characters="!@#$%^&*",  # defaults to the set " %+~`#/// here*()|[]{}:;<>?!'/@\"\\"
    security_group=my_security_group,  # defaults to an auto-created security group
    rotate_immediately_on_update=False
)

IAM Authentication

You can also authenticate to a database instance using AWS Identity and Access Management (IAM) database authentication; See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html for more information and a list of supported versions and limitations.

The following example shows enabling IAM authentication for a database instance and granting connection access to an IAM role.

Instance

# vpc: ec2.Vpc

instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_19),
    vpc=vpc,
    iam_authentication=True
)
role = iam.Role(self, "DBRole", assumed_by=iam.AccountPrincipal(self.account))
instance.grant_connect(role)

Proxy

The following example shows granting connection access for RDS Proxy to an IAM role.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    writer=rds.ClusterInstance.provisioned("writer"),
    vpc=vpc
)

proxy = rds.DatabaseProxy(self, "Proxy",
    proxy_target=rds.ProxyTarget.from_cluster(cluster),
    secrets=[cluster.secret],
    vpc=vpc
)

role = iam.Role(self, "DBProxyRole", assumed_by=iam.AccountPrincipal(self.account))
proxy.grant_connect(role, "admin")

Note: In addition to the setup above, a database user will need to be created to support IAM auth. See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html for setup instructions.

To specify the details of authentication used by a proxy to log in as a specific database user use the clientPasswordAuthType property:

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    writer=rds.ClusterInstance.provisioned("writer"),
    vpc=vpc
)

proxy = rds.DatabaseProxy(self, "Proxy",
    proxy_target=rds.ProxyTarget.from_cluster(cluster),
    secrets=[cluster.secret],
    vpc=vpc,
    client_password_auth_type=rds.ClientPasswordAuthType.MYSQL_NATIVE_PASSWORD
)

Cluster

The following example shows granting connection access for an IAM role to an Aurora Cluster.

# vpc: ec2.Vpc

cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    writer=rds.ClusterInstance.provisioned("writer"),
    vpc=vpc
)
role = iam.Role(self, "AppRole", assumed_by=iam.ServicePrincipal("someservice.amazonaws.com"))
cluster.grant_connect(role, "somedbuser")

Note: In addition to the setup above, a database user will need to be created to support IAM auth. See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html for setup instructions.

Kerberos Authentication

You can also authenticate using Kerberos to a database instance using AWS Managed Microsoft AD for authentication; See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/kerberos-authentication.html for more information and a list of supported versions and limitations.

The following example shows enabling domain support for a database instance and creating an IAM role to access Directory Services.

# vpc: ec2.Vpc

role = iam.Role(self, "RDSDirectoryServicesRole",
    assumed_by=iam.CompositePrincipal(
        iam.ServicePrincipal("rds.amazonaws.com"),
        iam.ServicePrincipal("directoryservice.rds.amazonaws.com")),
    managed_policies=[
        iam.ManagedPolicy.from_aws_managed_policy_name("service-role/AmazonRDSDirectoryServiceAccess")
    ]
)
instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_19),
    vpc=vpc,
    domain="d-????????",  # The ID of the domain for the instance to join.
    domain_role=role
)

You can also use the Kerberos authentication for an Aurora database cluster.

# vpc: ec2.Vpc

iam_role = iam.Role(self, "Role",
    assumed_by=iam.CompositePrincipal(
        iam.ServicePrincipal("rds.amazonaws.com"),
        iam.ServicePrincipal("directoryservice.rds.amazonaws.com")),
    managed_policies=[
        iam.ManagedPolicy.from_aws_managed_policy_name("service-role/AmazonRDSDirectoryServiceAccess")
    ]
)

rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora_mysql(version=rds.AuroraMysqlEngineVersion.VER_3_05_1),
    writer=rds.ClusterInstance.provisioned("Instance",
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.BURSTABLE3, ec2.InstanceSize.MEDIUM)
    ),
    vpc=vpc,
    domain="d-????????",  # The ID of the domain for the cluster to join.
    domain_role=iam_role
)

Note: In addition to the setup above, you need to make sure that the database instance or cluster has network connectivity to the domain controllers. This includes enabling cross-VPC traffic if in a different VPC and setting up the appropriate security groups/network ACL to allow traffic between the database instance and domain controllers. Once configured, see https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/kerberos-authentication.html for details on configuring users for each available database engine.

Metrics

Database instances and clusters both expose metrics (cloudwatch.Metric):

# The number of database connections in use (average over 5 minutes)
# instance: rds.DatabaseInstance

# Average CPU utilization over 5 minutes
# cluster: rds.DatabaseCluster

db_connections = instance.metric_database_connections()
cpu_utilization = cluster.metric_cPUUtilization()

# The average amount of time taken per disk I/O operation (average over 1 minute)
read_latency = instance.metric("ReadLatency", statistic="Average", period=Duration.seconds(60))

Enabling S3 integration

Data in S3 buckets can be imported to and exported from certain database engines using SQL queries. To enable this functionality, set the s3ImportBuckets and s3ExportBuckets properties for import and export respectively. When configured, the CDK automatically creates and configures IAM roles as required. Additionally, the s3ImportRole and s3ExportRole properties can be used to set this role directly. Note: To use s3ImportRole and s3ExportRole with Aurora PostgreSQL, you must also enable the S3 import and export features when you create the DatabaseClusterEngine.

You can read more about loading data to (or from) S3 here:

Aurora MySQL - import and export.
Aurora PostgreSQL - import and export.
Microsoft SQL Server - import and export
PostgreSQL - import and export
Oracle - import and export

The following snippet sets up a database cluster with different S3 buckets where the data is imported and exported -

import aws_cdk.aws_s3 as s3

# vpc: ec2.Vpc

import_bucket = s3.Bucket(self, "importbucket")
export_bucket = s3.Bucket(self, "exportbucket")
rds.DatabaseCluster(self, "dbcluster",
    engine=rds.DatabaseClusterEngine.aurora_mysql(
        version=rds.AuroraMysqlEngineVersion.VER_3_03_0
    ),
    writer=rds.ClusterInstance.provisioned("writer"),
    vpc=vpc,
    s3_import_buckets=[import_bucket],
    s3_export_buckets=[export_bucket]
)

Creating a Database Proxy

Amazon RDS Proxy sits between your application and your relational database to efficiently manage connections to the database and improve scalability of the application. Learn more about at Amazon RDS Proxy.

RDS Proxy is supported for MySQL, MariaDB, Postgres, and SQL Server.

The following code configures an RDS Proxy for a DatabaseInstance.

# vpc: ec2.Vpc
# security_group: ec2.SecurityGroup
# secrets: List[secretsmanager.Secret[]]
# db_instance: rds.DatabaseInstance


proxy = db_instance.add_proxy("proxy",
    borrow_timeout=Duration.seconds(30),
    max_connections_percent=50,
    secrets=secrets,
    vpc=vpc
)

Exporting Logs

You can publish database logs to Amazon CloudWatch Logs. With CloudWatch Logs, you can perform real-time analysis of the log data, store the data in highly durable storage, and manage the data with the CloudWatch Logs Agent. This is available for both database instances and clusters; the types of logs available depend on the database type and engine being used.

import aws_cdk.aws_logs as logs
# my_logs_publishing_role: iam.Role
# vpc: ec2.Vpc


# Exporting logs from a cluster
cluster = rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.aurora(
        version=rds.AuroraEngineVersion.VER_1_17_9
    ),
    writer=rds.ClusterInstance.provisioned("writer"),
    vpc=vpc,
    cloudwatch_logs_exports=["error", "general", "slowquery", "audit"],  # Export all available MySQL-based logs
    cloudwatch_logs_retention=logs.RetentionDays.THREE_MONTHS,  # Optional - default is to never expire logs
    cloudwatch_logs_retention_role=my_logs_publishing_role
)

# When 'cloudwatchLogsExports' is set, each export value creates its own log group in DB cluster.
# Specify an export value to access its log group.
error_log_group = cluster.cloudwatch_log_groups["error"]
audit_log_group = cluster.cloudwatch_log_groups.audit

# Exporting logs from an instance
instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.postgres(
        version=rds.PostgresEngineVersion.VER_16_3
    ),
    vpc=vpc,
    cloudwatch_logs_exports=["postgresql"],  # Export the PostgreSQL logs
    cloudwatch_logs_retention=logs.RetentionDays.THREE_MONTHS
)

# When 'cloudwatchLogsExports' is set, each export value creates its own log group in DB instance.
# Specify an export value to access its log group.
postgresql_log_group = instance.cloudwatch_log_groups["postgresql"]

Option Groups

Some DB engines offer additional features that make it easier to manage data and databases, and to provide additional security for your database. Amazon RDS uses option groups to enable and configure these features. An option group can specify features, called options, that are available for a particular Amazon RDS DB instance.

# vpc: ec2.Vpc
# security_group: ec2.SecurityGroup


rds.OptionGroup(self, "Options",
    engine=rds.DatabaseInstanceEngine.oracle_se2(
        version=rds.OracleEngineVersion.VER_19
    ),
    configurations=[rds.OptionConfiguration(
        name="OEM",
        port=5500,
        vpc=vpc,
        security_groups=[security_group]
    )
    ]
)

Parameter Groups

Database parameters specify how the database is configured. For example, database parameters can specify the amount of resources, such as memory, to allocate to a database. You manage your database configuration by associating your DB instances with parameter groups. Amazon RDS defines parameter groups with default settings.

You can create your own parameter group for your cluster or instance and associate it with your database:

# vpc: ec2.Vpc


parameter_group = rds.ParameterGroup(self, "ParameterGroup",
    engine=rds.DatabaseInstanceEngine.sql_server_ee(
        version=rds.SqlServerEngineVersion.VER_11
    ),
    name="my-parameter-group",
    parameters={
        "locks": "100"
    }
)

rds.DatabaseInstance(self, "Database",
    engine=rds.DatabaseInstanceEngine.SQL_SERVER_EE,
    vpc=vpc,
    parameter_group=parameter_group
)

Another way to specify parameters is to use the inline field parameters that creates an RDS parameter group for you. You can use this if you do not want to reuse the parameter group instance for different instances:

# vpc: ec2.Vpc


rds.DatabaseInstance(self, "Database",
    engine=rds.DatabaseInstanceEngine.sql_server_ee(version=rds.SqlServerEngineVersion.VER_11),
    vpc=vpc,
    parameters={
        "locks": "100"
    }
)

You cannot specify a parameter map and a parameter group at the same time.

Serverless v1

Amazon Aurora Serverless v1 is an on-demand, auto-scaling configuration for Amazon Aurora. The database will automatically start up, shut down, and scale capacity up or down based on your application’s needs. It enables you to run your database in the cloud without managing any database instances.

The following example initializes an Aurora Serverless v1 PostgreSql cluster. Aurora Serverless clusters can specify scaling properties which will be used to automatically scale the database cluster seamlessly based on the workload.

# vpc: ec2.Vpc


cluster = rds.ServerlessCluster(self, "AnotherCluster",
    engine=rds.DatabaseClusterEngine.AURORA_POSTGRESQL,
    copy_tags_to_snapshot=True,  # whether to save the cluster tags when creating the snapshot. Default is 'true'
    parameter_group=rds.ParameterGroup.from_parameter_group_name(self, "ParameterGroup", "default.aurora-postgresql11"),
    vpc=vpc,
    scaling=rds.ServerlessScalingOptions(
        auto_pause=Duration.minutes(10),  # default is to pause after 5 minutes of idle time
        min_capacity=rds.AuroraCapacityUnit.ACU_8,  # default is 2 Aurora capacity units (ACUs)
        max_capacity=rds.AuroraCapacityUnit.ACU_32,  # default is 16 Aurora capacity units (ACUs)
        timeout=Duration.seconds(100),  # default is 5 minutes
        timeout_action=rds.TimeoutAction.FORCE_APPLY_CAPACITY_CHANGE
    )
)

Note: The rds.ServerlessCluster class is for Aurora Serverless v1. If you want to use Aurora Serverless v2, use the rds.DatabaseCluster class.

Aurora Serverless v1 Clusters do not support the following features:

Loading data from an Amazon S3 bucket
Saving data to an Amazon S3 bucket
Invoking an AWS Lambda function with an Aurora MySQL native function
Aurora replicas
Backtracking
Multi-master clusters
Database cloning
IAM database cloning
IAM database authentication
Restoring a snapshot from MySQL DB instance
Performance Insights
RDS Proxy

Read more about the limitations of Aurora Serverless v1

Learn more about using Amazon Aurora Serverless v1 by reading the documentation

Use ServerlessClusterFromSnapshot to create a serverless cluster from a snapshot:

# vpc: ec2.Vpc

rds.ServerlessClusterFromSnapshot(self, "Cluster",
    engine=rds.DatabaseClusterEngine.AURORA_MYSQL,
    vpc=vpc,
    snapshot_identifier="mySnapshot"
)

Data API

You can access your Aurora DB cluster using the built-in Data API. The Data API doesn’t require a persistent connection to the DB cluster. Instead, it provides a secure HTTP endpoint and integration with AWS SDKs.

The following example shows granting Data API access to a Lambda function.

# vpc: ec2.Vpc
# fn: lambda.Function
# secret: secretsmanager.Secret


# Create a serverless V1 cluster
serverless_v1_cluster = rds.ServerlessCluster(self, "AnotherCluster",
    engine=rds.DatabaseClusterEngine.AURORA_MYSQL,
    vpc=vpc,  # this parameter is optional for serverless Clusters
    enable_data_api=True
)
serverless_v1_cluster.grant_data_api_access(fn)

# Create an Aurora cluster
cluster = rds.DatabaseCluster(self, "Cluster",
    engine=rds.DatabaseClusterEngine.AURORA_MYSQL,
    vpc=vpc,
    enable_data_api=True
)
cluster.grant_data_api_access(fn)

# Import an Aurora cluster
imported_cluster = rds.DatabaseCluster.from_database_cluster_attributes(self, "ImportedCluster",
    cluster_identifier="clusterIdentifier",
    secret=secret,
    data_api_enabled=True
)
imported_cluster.grant_data_api_access(fn)

Note: To invoke the Data API, the resource will need to read the secret associated with the cluster.

To learn more about using the Data API, see the documentation.

Default VPC

The vpc parameter is optional.

If not provided, the cluster will be created in the default VPC of the account and region. As this VPC is not deployed with AWS CDK, you can’t configure the vpcSubnets, subnetGroup or securityGroups of the Aurora Serverless Cluster. If you want to provide one of vpcSubnets, subnetGroup or securityGroups parameter, please provide a vpc.

Preferred Maintenance Window

When creating an RDS cluster, it is possible to (optionally) specify a preferred maintenance window for the cluster as well as the instances under the cluster. See AWS docs for more information regarding maintenance windows.

The following code snippet shows an example of setting the cluster’s maintenance window to 22:15-22:45 (UTC) on Saturdays, but setting the instances’ maintenance window to 23:15-23:45 on Sundays

# vpc: ec2.Vpc

rds.DatabaseCluster(self, "DatabaseCluster",
    engine=rds.DatabaseClusterEngine.AURORA,
    instance_props=rds.InstanceProps(
        vpc=vpc,
        preferred_maintenance_window="Sun:23:15-Sun:23:45"
    ),
    preferred_maintenance_window="Sat:22:15-Sat:22:45"
)

You can also set the preferred maintenance window via reader and writer props:

# vpc: ec2.Vpc

rds.DatabaseCluster(self, "DatabaseCluster",
    engine=rds.DatabaseClusterEngine.AURORA,
    vpc=vpc,
    writer=rds.ClusterInstance.provisioned("WriterInstance",
        preferred_maintenance_window="Sat:22:15-Sat:22:45"
    ),
    preferred_maintenance_window="Sat:22:15-Sat:22:45"
)

Performance Insights

You can enable Performance Insights for a clustered database or an instance database.

Clustered Database

You can enable Performance Insights at cluster level or instance level.

To enable Performance Insights at the cluster level, set the enablePerformanceInsights property for the DatabaseCluster to true. If you want to specify the detailed settings, you can use the performanceInsightRetention and performanceInsightEncryptionKey properties.

The settings are then applied to all instances in the cluster.

# vpc: ec2.Vpc
# kms_key: kms.Key

rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.AURORA,
    vpc=vpc,
    enable_performance_insights=True,
    performance_insight_retention=rds.PerformanceInsightRetention.LONG_TERM,
    performance_insight_encryption_key=kms_key,
    writer=rds.ClusterInstance.provisioned("Writer",
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.R7G, ec2.InstanceSize.LARGE)
    )
)

To enable Performance Insights at the instance level, set the same properties for each instance of the writer and the readers.

In this way, different settings can be applied to different instances in a cluster.

Note: If Performance Insights is enabled at the cluster level, it is also automatically enabled for each instance. If specified, Performance Insights for each instance require the same retention period and encryption key as the cluster level.

# vpc: ec2.Vpc
# kms_key: kms.Key

rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.AURORA,
    vpc=vpc,
    writer=rds.ClusterInstance.provisioned("Writer",
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.R7G, ec2.InstanceSize.LARGE),
        enable_performance_insights=True,
        performance_insight_retention=rds.PerformanceInsightRetention.LONG_TERM,
        performance_insight_encryption_key=kms_key
    ),
    readers=[
        rds.ClusterInstance.provisioned("Reader",
            instance_type=ec2.InstanceType.of(ec2.InstanceClass.R7G, ec2.InstanceSize.LARGE),
            enable_performance_insights=False
        )
    ]
)

Instance Database

To enable Performance Insights for an instance database, set the enablePerformanceInsights property for the DatabaseInstance to true. If you want to specify the detailed settings, you can use the performanceInsightRetention and performanceInsightEncryptionKey properties.

# vpc: ec2.Vpc
# kms_key: kms.Key

instance = rds.DatabaseInstance(self, "Instance",
    engine=rds.DatabaseInstanceEngine.mysql(version=rds.MysqlEngineVersion.VER_8_0_39),
    instance_type=ec2.InstanceType.of(ec2.InstanceClass.R7G, ec2.InstanceSize.LARGE),
    vpc=vpc,
    enable_performance_insights=True,
    performance_insight_retention=rds.PerformanceInsightRetention.LONG_TERM,
    performance_insight_encryption_key=kms_key
)

Supported Engines

Performance Insights supports a limited number of engines.

To see Amazon RDS DB engines that support Performance Insights, see Amazon RDS DB engine, Region, and instance class support for Performance Insights.

To see Amazon Aurora DB engines that support Performance Insights, see Amazon Aurora DB engine, Region, and instance class support for Performance Insights.

For more information about Performance Insights, see Monitoring DB load with Performance Insights on Amazon RDS.

Database Insights

The standard mode of Database Insights is enabled by default for Aurora databases.

You can enhance the monitoring of your Aurora databases by enabling the advanced mode of Database Insights.

To control Database Insights mode, use the databaseInsightsMode property:

# vpc: ec2.Vpc

rds.DatabaseCluster(self, "Database",
    engine=rds.DatabaseClusterEngine.AURORA,
    vpc=vpc,
    # If you enable the advanced mode of Database Insights,
    # Performance Insights is enabled and you must set the `performanceInsightRetention` to 465(15 months).
    database_insights_mode=rds.DatabaseInsightsMode.ADVANCED,
    performance_insight_retention=rds.PerformanceInsightRetention.MONTHS_15,
    writer=rds.ClusterInstance.provisioned("Writer",
        instance_type=ec2.InstanceType.of(ec2.InstanceClass.R7G, ec2.InstanceSize.LARGE)
    )
)

Note: Database Insights are only supported for Amazon Aurora MySQL and Amazon Aurora PostgreSQL clusters.

Visit CloudWatch Database Insights for more details.

Enhanced Monitoring

With Enhanced Monitoring, you can monitor the operating system of your DB instance in real time.

To enable Enhanced Monitoring for a clustered database, set the monitoringInterval property. This value is applied at instance level to all instances in the cluster by default.

If you want to enable enhanced monitoring at the cluster level, you can set the enableClusterLevelEnhancedMonitoring property to true. Note that you must set monitoringInterval when using enableClusterLevelEnhancedMonitoring

# vpc: ec2.Vpc

# Enable Enhanced Monitoring at instance level to all instances in the cluster
rds.DatabaseCluster(self, "Cluster",
    engine=rds.DatabaseClusterEngine.aurora_postgres(version=rds.AuroraPostgresEngineVersion.VER_16_1),
    writer=rds.ClusterInstance.serverless_v2("writerInstance"),
    vpc=vpc,
    monitoring_interval=Duration.seconds(5)
)

# Enable Enhanced Monitoring at the cluster level
rds.DatabaseCluster(self, "Cluster",
    engine=rds.DatabaseClusterEngine.aurora_postgres(version=rds.AuroraPostgresEngineVersion.VER_16_1),
    writer=rds.ClusterInstance.serverless_v2("writerInstance"),
    vpc=vpc,
    monitoring_interval=Duration.seconds(5),
    enable_cluster_level_enhanced_monitoring=True
)

AWS CDK automatically generate the IAM role for Enhanced Monitoring. If you want to create the IAM role manually, you can use the monitoringRole property.

# vpc: ec2.Vpc
# monitoring_role: iam.Role


rds.DatabaseCluster(self, "Cluster",
    engine=rds.DatabaseClusterEngine.aurora_postgres(version=rds.AuroraPostgresEngineVersion.VER_16_1),
    writer=rds.ClusterInstance.serverless_v2("writerInstance"),
    vpc=vpc,
    monitoring_interval=Duration.seconds(5),
    monitoring_role=monitoring_role
)

Limitless Database Cluster

Amazon Aurora PostgreSQL Limitless Database provides automated horizontal scaling to process millions of write transactions per second and manages petabytes of data while maintaining the simplicity of operating inside a single database.

The following example shows creating an Aurora PostgreSQL Limitless Database cluster:

# vpc: ec2.IVpc


rds.DatabaseCluster(self, "LimitlessDatabaseCluster",
    engine=rds.DatabaseClusterEngine.aurora_postgres(
        version=rds.AuroraPostgresEngineVersion.VER_16_4_LIMITLESS
    ),
    vpc=vpc,
    cluster_scalability_type=rds.ClusterScalabilityType.LIMITLESS,
    # Requires enabling Performance Insights
    enable_performance_insights=True,
    performance_insight_retention=rds.PerformanceInsightRetention.MONTHS_1,
    # Requires enabling Enhanced Monitoring at the cluster level
    monitoring_interval=Duration.minutes(1),
    enable_cluster_level_enhanced_monitoring=True,
    # Requires I/O optimized storage type
    storage_type=rds.DBClusterStorageType.AURORA_IOPT1,
    # Requires exporting the PostgreSQL log to Amazon CloudWatch Logs.
    cloudwatch_logs_exports=["postgresql"]
)