Dealing with Multiple Environments in A Single Aurora Instance

Applicable when

• You need to implement a cost-effective RDS usage strategy for your development team.

Non-applicable when

• You want to deploy different environments for different clients.

Implementation

Running an Aurora instance is costly in comparison to other resources (such as S3 buckets) because AWS needs to provision the EC2 instances above certain specification threshold, and they need to be running as long as you want to use the database.

An effective strategy to reduce development costs significantly is to have only one Aurora instance and create as much databases / schemas as environments you need for your development team. We can provision the Aurora instance via CDK instructing Amazon not to delete it when the particular stack gets deleted to avoid affecting the other environments (we can also use a predefined cluster identified for the whole dev team):

 new DatabaseCluster(stack, 'aurora', {
   engine: DatabaseClusterEngine.AURORA_POSTGRESQL,
   clusterIdentifier: clusterName,
   removalPolicy: RemovalPolicy.RETAIN,
   ...
  });

In addition to this, we need check whether the Aurora instance exists to avoid attempting creating a duplicate which will throw an error. To solve this problem we can have a pre deployment script to do this check and pass the parameter to the stack telling us whether we need to create the DB or not:

import { RDS } from 'aws-sdk';

export async function checkAuroraCluster(auroraClusterIdentifier: string):
 Promise<any> {
 const defaultResponse = {};

  try {
   const rds = new RDS();
   const cluster = await rds.describeDBClusters({
     DBClusterIdentifier: auroraClusterIdentifier
   }).promise();

    if (cluster.DBClusters?.length) {
     return {
       // The properties you need for your stacks
     };
   }

    return defaultResponse;
 } catch (e) {
   return defaultResponse;
 }
}

When the response above is not an empty object, this will signal that you only need to import the database in your stack to keep consistency across multiple deployments. To import the cluster you can use the corresponding method depending on the Construct (DatabaseCluster) or CfnResource (CfnDBCluster) you used to create the cluster.

Finally, you need to provide the configuration to your stack resources relying on the Aurora instance to use the corresponding schema / database accordingly such as Glue jobs, connections, etc.