KMS on Virtual Appliance

Protecting Data with KMS Encryption

By default, GRAX encrypts data at every step including while at rest in EBS, S3, and ElasticSearch. While AWS defaults are utilized for encryption in most cases (more information on those defaults can be found in the detailed components documentation), some customers may want to bring their own encryption keys to protect their data and unify management of encryption in their own applications. To acheive this, GRAX supports KMS for both S3 and ElasticSearch. KMS can be used for one at a time or both, and can use identical or unique keys between the two services. KMS keys may reside in accounts other than the one hosting GRAX resources.


  • KMS Keys cannot be rotated while assigned to GRAX.
  • Assigned KMS Keys cannot be changed after initial set up.
  • Revokation of KMS Keys will break GRAX and jeopardize data access.

How to Set Up

To utilize KMS functionality, two distinct parameters are set during initial deployment with the ARNs of the KMS keys in question. For more context about deploying GRAX templates, please refer to centralized documentation on Virtual Appliance Deployment.

To prepare a KMS key from another AWS account for use in GRAX, follow the documentation from here to set key access policies. This involves creating a key policy in the key's account to allow access from another AWS account.

For S3, the runtime template will deploy its own IAM policy to grant access within the account hosting GRAX. For ElasticSearch, the user running the template/creating the GRAX resources must have KMS access to that key via an IAM policy.

KMS on S3

To enable KMS for S3, fill in the "S3KMSKeyARN" parameter of the runtime template during initial deployment.

KMS on ElasticSearch

ElasticSearch utilizes a system-managed KMS key by default. To enable a customer-specified key for ElasticSearch, fill in the "ESKMSKeyARN" parameter of the runtime template during intial deployment.

You must utilize the stack policy provided in the Virtual Appliance Github repo in this case to prevent accidental destruction of the ElasticDomain due to key changes. During initial creation of the stack, the stack policy can be added on the page following the parameters as JSON or a file upload. The stack will maintain this policy during its life unless manually changed.

Moving to KMS After Initial Installation

To move to KMS after initial installation of GRAX, contact support at [email protected] or your Customer Success Manager. In many cases, transitioning to KMS may involve recreation of AWS resources and migration of all backed up data. This would incur AWS costs.