Instaclustr has recently released support for provisioning Amazon Web Services based Cassandra clusters with encrypted EBS and encrypted backups. This support brings two big benefits to our customers:

1. By utilising encrypted EBS (plus encrypted backups), customers may be able to meet compliance requirements that mandate encryption of data at rest.
2. Customers always retain control of the “master key” for their data. Should you wish to remove Instaclustr access to your data, you can simply remove the rights for Instaclustr managed systems to access your master key.

You can find more information about AWS’s EBS encryption here: Amazon EBS Encryption. Importantly, AWS claims, and our testing shows, that enabling EBS encryption has negligible, if any, impact on performance.

Using EBS encryption with Instaclustr is easy:

1. Create a new key through AWS and grant permissions to Instaclustr’s AWS account to access it.
2. Register the key through the Encryption Keys tab of the Instaclustr Account page. The registration process will check that permissions are set up properly.
3. Select the key from the drop down box when creating a new cluster or add a data center to an existing cluster. That key will then be used when provisioning EBS volumes and to encrypt the automatic backups our system makes (to S3).

There are detailed, step-by-step instructions for these steps in our help article here: https://www.instaclustr.com/support/documentation/getting-started/setting-up-a-datacenter-with-ebs-encryption/. One note – it’s not possible to change an existing cluster to encrypted EBS in-place. However, you can migrate a cluster to encrypted EBS without downtime by adding a second data center with encryption, cutting your app over to that data center and then decommissioning the existing data center.

I mentioned that one of the advantages of using encrypted EBS is that it gives you the power to securely remove Instaclustr access to your data should you need to (of course, we plan to do a good enough job that you never want to). This power also comes with responsibility – should you remove our access to your key your cluster will stop working (once the cached key expires) and we will not be able to recover data without access to the key. So – make sure you’ve got good procedures in place to manage this access – any issues arising from the change you make to key settings won’t be covered by SLAs.

We think this feature will be of use to many of our customers. If you have any technical questions about this feature or issues getting it set up please contact [email protected]. As always, please feel free to contact me directly at [email protected] should you have any general comments or requests for features.