# Ensure DynamoDB Accelerator (DAX) cluster has encryption in transit enabled

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292237572219-ensure-dynamodb-accelerator-dax-cluster-has-encryption-in-transit-enabled
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that every Amazon DynamoDB Accelerator (DAX) cluster has its endpoint encryption type set to TLS. With encryption in transit, all traffic between applications and the DAX cluster is encrypted with Transport Layer Security (TLS), and clients can verify that they are connecting to the genuine cluster.

**Rationale**

Without TLS, requests and responses sent to DAX travel unencrypted inside the network. Anyone able to observe or intercept this traffic can read queries and cached data, tamper with requests and responses, or poison the cache. Enforcing TLS on all DAX endpoints, together with private network access and least privilege IAM permissions, protects the confidentiality and integrity of this traffic.

**Impact**

-   Encrypts all traffic between applications and the DAX cluster
    
-   Protects against interception and tampering with cached data
    
-   Encryption in transit can only be chosen when a cluster is created, so an existing cluster must be replaced by a new one, and applications must connect to the new cluster's TLS endpoint with a DAX client version that supports encryption in transit
    
-   The cache of the new cluster starts empty, which temporarily increases reads from the DynamoDB tables
    

**Default Value**

Encryption in transit is enabled only if it is selected when the DAX cluster is created. The endpoint encryption type cannot be changed on an existing cluster.

**Pre-Requisites**

-   IAM permissions: dax:DescribeClusters, dax:CreateCluster, dax:DeleteCluster and iam:PassRole
    
-   The IAM role that DAX uses to access DynamoDB, and the subnet group and security groups for the new cluster (these can be copied from the existing cluster)
    
-   Application clients updated to a DAX client version that supports TLS
    
-   A planned change window to switch applications to the new cluster endpoint
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon DynamoDB console and select **Clusters** under **DAX**.
    
3.  Select a cluster and check its encryption in transit setting in the cluster details.
    
4.  Repeat for each cluster in each region in use.
    
5.  If encryption in transit is not enabled on any cluster, follow the implementation steps.
    

**CLI:**

Show the endpoint encryption type of all DAX clusters in a region:

aws dax describe-clusters --region <REGION> --query "Clusters\[\].\[ClusterName,ClusterEndpointEncryptionType,SSEDescription.Status,IamRoleArn,SubnetGroup\]" --output table

A cluster fails if ClusterEndpointEncryptionType is not TLS.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon DynamoDB console and select **Clusters** under **DAX**.
    
3.  Choose **Create cluster**.
    
4.  Enter a cluster name and choose the node type and number of nodes (use the values of the existing cluster).
    
5.  Select the same subnet group, security groups and IAM role as the existing cluster.
    
6.  In the encryption settings, turn on encryption in transit (and encryption at rest if required).
    
7.  Complete the wizard to create the cluster and wait until its status is **Available**.
    
8.  Update your applications to use the new cluster's TLS endpoint.
    
9.  When no application uses the old cluster anymore, select it and choose **Delete**.
    
10.  Repeat for each affected cluster in each region in use.
     

**CLI:**

Create a new cluster with encryption in transit enabled:

aws dax create-cluster --region <REGION> --cluster-name <NEW\_CLUSTER\_NAME> --node-type <NODE\_TYPE> --replication-factor <NODE\_COUNT> --iam-role-arn <DAX\_ROLE\_ARN> --subnet-group-name <SUBNET\_GROUP\_NAME> --security-group-ids <SECURITY\_GROUP\_ID> --cluster-endpoint-encryption-type TLS --sse-specification Enabled=true

The --iam-role-arn option is required to create a DAX cluster, so it has been added; encryption at rest is also enabled because it cannot be added later either.

After applications have been moved to the new cluster endpoint, delete the old cluster:

aws dax delete-cluster --region <REGION> --cluster-name <OLD\_CLUSTER\_NAME>

**Backout Plan**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Update your applications to use the endpoint of the original cluster again, as long as it has not been deleted.
    
3.  Open the Amazon DynamoDB console, select **Clusters** under **DAX**, select the new cluster and choose **Delete**.
    

**CLI:**

aws dax delete-cluster --region <REGION> --cluster-name <NEW\_CLUSTER\_NAME>

Note: a deleted DAX cluster cannot be restored. Keep the original cluster until the new cluster is confirmed to work, and remember that rolling back sends DAX traffic unencrypted again.

**Reference**

-   [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAXEncryptionInTransit.html](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAXEncryptionInTransit.html)
    
-   [https://docs.aws.amazon.com/securityhub/latest/userguide/dynamodb-controls.html](https://docs.aws.amazon.com/securityhub/latest/userguide/dynamodb-controls.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/dax/create-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/dax/create-cluster.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.
