Skip to content
Ask AI about this
Help improve this page

DynamoDB Accelerator clusters should be encrypted in transit

DAX clusters sit between your application and DynamoDB, caching frequently read items in memory. Without TLS on the endpoint, data traveling between your application and the DAX cluster moves in plaintext across the network. This exposes cached DynamoDB content, including potentially sensitive attributes, to network-level interception.

Once a DAX cluster is created, you cannot change the encryption-in-transit setting. A cluster deployed without TLS must be destroyed and recreated, which means cache invalidation and potential application downtime. Getting this right at provisioning time eliminates a painful retrofit.

Retrofit consideration

The cluster_endpoint_encryption_type argument on aws_dax_cluster is a ForceNew attribute. Changing it from NONE to TLS destroys and recreates the cluster, which clears the cache and causes downtime for applications relying on DAX.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_dax_cluster.

resource "aws_dax_cluster" "this" {
  cluster_name       = "pfxdax${random_integer.this.id}"
  iam_role_arn       = "arn:aws:iam::123456789012:role/example-role"
  node_type          = "dax.t3.small"
  replication_factor = 1
  subnet_group_name  = "example-dax-subnet-group"

  cluster_endpoint_encryption_type = "TLS"
}

What this control checks

The control validates that aws_dax_cluster has cluster_endpoint_encryption_type set to "TLS". It defaults to "NONE", so any cluster that omits this argument fails. No other value passes. The setting applies to the cluster endpoint and cannot be changed after cluster creation.

Common pitfalls

  • Default value is NONE, not TLS

    The cluster_endpoint_encryption_type argument on aws_dax_cluster defaults to "NONE". Omit it entirely and the cluster deploys without in-transit encryption, failing this control immediately. Always set it explicitly.

  • ForceNew makes retrofitting destructive

    Changing cluster_endpoint_encryption_type from "NONE" to "TLS" on an existing aws_dax_cluster triggers a destroy-and-recreate. Plan for cache warmup time and verify your application handles DAX endpoint changes or uses DNS-based discovery before applying.

  • DAX SDK client must support encryption

    Enabling TLS on the cluster is only half the requirement. Your application also needs a DAX client SDK version that supports encrypted connections. Older SDK versions may fail to connect to a TLS-enabled cluster with no obvious error message.

  • Encryption in transit is separate from encryption at rest

    The server_side_encryption block on aws_dax_cluster controls at-rest encryption. The cluster_endpoint_encryption_type argument controls in-transit encryption. Both must be configured independently; enabling one does not enable the other.

Audit evidence

Config rule evaluation results confirming all DAX clusters have endpoint encryption type set to TLS, or equivalent findings from a CSPM tool scanning the dax:DescribeClusters API response. The ClusterEndpointEncryptionType field should return TLS for every cluster.

Supporting evidence includes the DAX console showing "Encryption in transit: Enabled" on each cluster's details page, along with a current inventory confirming no clusters exist with plaintext endpoints.

Framework-specific interpretation

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: dax_cluster_encryption_in_transit_enabled

  • AWS Config Managed Rule: DAX_TLS_ENDPOINT_ENCRYPTION

  • Checkov Check: CKV_AWS_239

  • Powerpipe Control: aws_compliance.control.dax_cluster_encryption_in_transit_enabled

  • Prowler Check: dynamodb_accelerator_cluster_in_transit_encryption_enabled

  • AWS Security Hub Control: DynamoDB.7

Last reviewed: 2026-03-09