DynamoDB Dax Demo

• AWS account with permissions to create DAX clusters, IAM roles/policies, and VPC/subnet/security-group resources.
• A VPC with at least one subnet in each Availability Zone you plan to use.
• Applications or compute (EC2, ECS, EKS, Lambda in VPC) able to reach the DAX endpoint on the required port.

• Amazon DynamoDB Documentation
• Amazon DAX Documentation

​

Step-by-step cluster creation

1. Open the DynamoDB console, choose Clusters, then Create cluster.
   Enter a cluster name — this example uses cluster1.
2. Choose a DAX node type (instance family and size). DAX supports families tuned for different workloads:

   Instance family	Use case
   T (burstable)	Cost-effective for light or variable workloads with occasional CPU bursts.
   R (memory-optimized)	Higher memory and sustained performance for heavier caching needs.

   Select the instance size that fits your memory and CPU requirements. For demos or cost-sensitive tests, dax.t2.small (one vCPU) is a common choice.
3. Select the number of nodes. Recommendations:
   • Development/testing: single-node clusters are possible for quick trials (console will warn).
   • Production: use a multi-node cluster (AWS recommends a minimum of three nodes) to ensure availability and replication.
4. Create or pick a subnet group for DAX. Provide a name (for example, DAX subnet group), choose the VPC to deploy into (the default VPC can be used for demos), and add the subnets that will host cluster nodes.

5. Configure security groups and network access. Make sure inbound rules allow clients to reach the DAX cluster on the DAX port:
   • Port 8111 for DAX client traffic (TLS-enabled clients still use port 8111).
   • If you perform any management or custom networking that references different ports, document and open them only as required.

6. Availability Zones (AZs): choose whether AWS should select AZs automatically (recommended for even distribution) or choose specific AZs manually to meet locality or compliance requirements.
7. IAM role and policies:
   • Create a service-linked role for DAX and attach an IAM policy that grants DAX access to DynamoDB tables.
   • Decide scope:
     • Read-write access when DAX should handle both reads and writes.
     • Read-only access when DAX is used strictly for caching reads.
   • For security, scope policies to only the required table ARNs rather than granting access to all tables.

• Encryption at rest (protects data stored on DAX nodes).
• Encryption in transit (TLS between client and DAX). Note: clients still connect on port 8111 when TLS is enabled.

8. Parameter group: choose the default parameter group or create a custom one. Parameter groups control runtime settings such as:
   • Item TTL (how long an item remains in the DAX cache).
   • Query TTL (how long query results are cached).

9. Maintenance window: choose “No preference” or specify a preferred maintenance window for DAX patches and upgrades to minimize disruption.
10. Review all settings and click Create cluster.

• Cluster endpoint (use this in your DAX-enabled SDK client configuration so requests route through DAX).
• Cluster ARN and node list.

const AmazonDaxClient = require('amazon-dax-client');
const AWS = require('aws-sdk');

const dax = new AmazonDaxClient({endpoints: ['cluster1.abc123.clustercfg.dax.us-east-1.amazonaws.com:8111']});
const docClient = new AWS.DynamoDB.DocumentClient({service: dax});

// Use docClient as you would a normal DocumentClient; requests are routed through DAX

​

Monitoring, events, and settings

• Tune node sizes.
• Adjust TTLs and parameter-group settings.
• Detect cache effectiveness (hit/miss ratio).

​

Quick reference: recommended settings

​

Cleanup and cost control