Aurora location

Overview

info

This Location type uses AWS Aurora PostgreSQL. At this time it is not compatible with the MySQL variant of Aurora.

Aurora storage supports:

• Arbitrary queries and automatic query expansion using joins.

Depot Aurora locations use Aurora Serverless v2 and the PostgreSQL 16.1 engine.

A writer instance and 0 or more reader instances can be configured. (A writer is used for both reads and writes if no dedicated readers are specified). Each instance can be provisioned in dedicated EC2 or Serverless mode, using a shared scaling configuration.

Configuration

Here is an example Aurora Location configuration:

const auroraLocation = depot.Location.Aurora.withCluster(this, "aurora", {
    environment: environment,
    deploymentGroup: true,
    name: "aurora",
    writer: {
        engine: DepotAuroraInstanceType.SERVERLESS
    },
    readers: [
        {
            engine: DepotAuroraInstanceType.PROVISIONED,
            instanceType: aws_ec2.InstanceType.of(aws_ec2.InstanceClass.BURSTABLE3, aws_ec2.InstanceSize.MEDIUM)
        }
    ],
    serverlessCapacity: {
        min: 0.5,
        max: 2
    },
    users: [
        "jeff@example.com",
        "jane@example.com",
    ]
});

info

serverlessCapacity is only required when at least one serverless instance is present.

With each Aurora Location cluster:

• Standard encryption is enabled using the aws/rds managed AWS KMS key.
• A default database named depotpostgres is created.
• Multi AZ is currently not supported.
• Standard 7 day automated backups are enabled.
• Randomised early hours backup and maintenance windows are selected.
• Clusters created using the withCluster method will inherit tags from the defining Stack, with these being passed down to the underlying RDS cluster and DB instances. Additionally, the RDS resources will also receive a 'depot-location-name' and 'depot-location-id' tag with appropriate values.

When working with multiple dependent datasets that use Aurora locations, there is a possibility to either reuse a single Aurora cluster or have a individual ones for each location. Each approach has its own drawbacks:

• Having separate clusters enables scaling control for each.
• Co-locating datasets within the same Aurora cluster makes queries (e.g. GraphQL) faster when joining data from different datasets, because Depot can do SQL-level joins on data within the same cluster. Furthermore, cross-dataset SQL transactions within Aurora requires data to be co-located.

To reuse an existing cluster, either reuse the same Aurora location via fromLocationName (e.g. if no extra configuration changes are necessary):

const locationFromName = Location.Aurora.fromLocationName(stack, "TestLocationFromName", {
    environment: depotEnv,
    name: "auroraByNameReuse"
});

Or use withClusterGroup if a location configuration differs, i.e.

const auroraLocation = Location.Aurora.withClusterGroup(stack, "TestAuroraClusterReuse", {
    environment: depotEnv,
    name: "mylocationReuse",
    clusterGroupName: "mylocation",
    createEntities: false,
    readable: true,
    writable: false,
});

where clusterGroupName matches any existing location with a cluster configuration.

Note that tags will not propagate from the defining stack using the clusterGroupName or fromLocationName methods.

Connectivity

To connect to, and query a Aurora RDS Depot Location, you can use the Depot CLI's connect-bastion command. This command will establish a secure connection to the Aurora RDS instance via AWS SSM, and create a reverse tunnel to your local machine. This allows you to connect your local Postgres client to the remote Aurora RDS instance.

In order to connect, your username (your stage email) should be added to the list of users in the Aurora Location configuration (user property). The CLI will generate a temporary password for you to use to connect to the RDS instance using IAM authentication, and by looking at what your local AWS IAM Role allows.

depot connect-bastion --region eu-west-1 --env env123 --location my-aurora-location --localport 56789 --permission w

More information about using the connect-bastion command can be found here.

Lifecycle

info

On removal of the Aurora Location, the default behavior (currently the only behavior) is to take a snapshot of the cluster before it is removed. The retention policy deletes the resource, but saves a snapshot of its data before deleting, so that it can be re-created later manually if needed.

Performance insights

You can enable the performance insights dashboard by passing the following configuration to your Aurora location:

performanceInsights: {
    enabled: true,
    retention: PerformanceInsightRetention.DEFAULT
}