Managing DAX clusters

This section addresses some of the common management tasks for Amazon DynamoDB Accelerator (DAX) clusters.

IAM permissions for managing a DAX cluster

When you administer a DAX cluster using the AWS Management Console or the AWS Command Line Interface (AWS CLI), we strongly recommend that you narrow the scope of actions that users can perform. By doing so, you help mitigate risk while following the principle of least privilege.

The following discussion focuses on access control for the DAX management APIs. For more information, see Amazon DynamoDB accelerator in the Amazon DynamoDB API Reference.

For the DAX management APIs, you can't scope API actions to a specific resource. The Resource element must be set to "*". This is different from DAX data plane API operations, such as GetItem, Query, and Scan. Data plane operations are exposed through the DAX client, and those operations can be scoped to specific resources.

To illustrate, consider the following IAM policy document.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dax:*"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
            ]
        }
    ]
}

Suppose that the intent of this policy is to allow DAX management API calls for the cluster DAXCluster01— and only that cluster.

Now suppose that a user issues the following AWS CLI command.

aws dax describe-clusters

This command fails with a Not Authorized exception because the underlying DescribeClusters API call can't be scoped to a specific cluster. Even though the policy is syntactically valid, the command fails because the Resource element must be set to "*". However, if the user runs a program that sends DAX data plane calls (such as GetItem or Query) to DAXCluster01, those calls do succeed. This is because DAX data plane APIs can be scoped to specific resources (in this case, DAXCluster01).

If you want to write a single comprehensive IAM policy to encompass both DAX management APIs and DAX data plane APIs, we suggest that you include two distinct statements in the policy document. One of these statements should address the DAX data plane APIs, while the other statement addresses the DAX management APIs.

The following example policy shows this approach. Note how the DAXDataAPIs statement is scoped to the DAXCluster01 resource, but the resource for DAXManagementAPIs must be "*". The actions shown in each statement are for illustration only. You can customize them as needed for your application.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DAXDataAPIs",
            "Action": [
                "dax:GetItem",
                "dax:BatchGetItem",
                "dax:Query",
                "dax:Scan",
                "dax:PutItem",
                "dax:UpdateItem",
                "dax:DeleteItem",
                "dax:BatchWriteItem"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
            ]},
            {
            "Sid": "DAXManagementAPIs",
            "Action": [
                "dax:CreateParameterGroup",
                "dax:CreateSubnetGroup",
                "dax:DecreaseReplicationFactor",
                "dax:DeleteCluster",
                "dax:DeleteParameterGroup",
                "dax:DeleteSubnetGroup",
                "dax:DescribeClusters",
                "dax:DescribeDefaultParameters",
                "dax:DescribeEvents",
                "dax:DescribeParameterGroups",
                "dax:DescribeParameters",
                "dax:DescribeSubnetGroups",
                "dax:IncreaseReplicationFactor",
                "dax:ListTags",
                "dax:RebootNode",
                "dax:TagResource",
                "dax:UntagResource",
                "dax:UpdateCluster",
                "dax:UpdateParameterGroup",
                "dax:UpdateSubnetGroup"
                ],
            "Effect": "Allow",
            "Resource": [
                "*"
            ]
        }
    ]
}

Scaling a DAX cluster

There are two options available for scaling a DAX cluster. The first option is horizontal scaling, where you add read replicas to the cluster. The second option is vertical scaling, where you select different node types. For advice on how to approach choosing an appropriate cluster size and node type for your application, see DAX cluster sizing guide.

Horizontal scaling

With horizontal scaling, you can improve throughput for read operations by adding more read replicas to the cluster. A single DAX cluster supports up to 10 read replicas, and you can add or remove replicas while the cluster is running.

When you add a new node, you must synchronize the cache data from a peer node. Therefore, the addition time varies based on cache size and your application workload. As a best practice, we recommend that you pre-scale your cluster to meet expected traffic peaks. For information about right-sizing guidelines and monitoring recommendations, see DAX cluster sizing guide.

The following AWS CLI examples show how to increase or decrease the number of nodes. The --new-replication-factor argument specifies the total number of nodes in the cluster. One of the nodes is the primary node, and the other nodes are read replicas.

aws dax increase-replication-factor \
    --cluster-name MyNewCluster  \
    --new-replication-factor 5

aws dax decrease-replication-factor \
    --cluster-name MyNewCluster  \
    --new-replication-factor 3

Vertical scaling

If you have a large working set of data, your application might benefit from using larger node types. Larger nodes can enable the cluster to store more data in memory, reducing cache misses and improving overall application performance of the application. (All of the nodes in a DAX cluster must be of the same type.)

If your DAX cluster has a high rate of write operations or cache misses, your application might also benefit from using larger node types. Write operations and cache misses consume resources on the cluster's primary node. Therefore, using larger node types might increase the performance of the primary node and thereby allow a higher throughput for these types of operations.

You can't modify the node types on a running DAX cluster. Instead, you must create a new cluster with the desired node type. For a list of supported node types, see Nodes.

You can create a new DAX cluster using the AWS Management Console, AWS CloudFormation, the AWS CLI, or the AWS SDK. (For the AWS CLI, use the --node-type parameter to specify the node type.)

Customizing DAX cluster settings

When you create a DAX cluster, the following default settings are used:

For new clusters, you can customize the settings at creation time. To do this in the AWS Management Console, clear Use default settings to modify the following settings:

When a maintenance event occurs, DAX can notify you using Amazon Simple Notification Service (Amazon SNS). To configure notifications, choose an option from the Topic for SNS notification selector. You can create a new Amazon SNS topic, or use an existing topic.

For more information about setting up and subscribing to an Amazon SNS topic, see Getting started with Amazon SNS in the Amazon Simple Notification Service Developer Guide.

Configuring TTL settings

DAX maintains two caches for data that it reads from DynamoDB:

For more information, see Item cache and Query cache.

The default TTL for each of these caches is 5 minutes. If you want to use different TTL settings, you can launch a DAX cluster using a custom parameter group. To do this on the console, choose DAX | Parameter groups in the navigation pane.

You can also perform these tasks using the AWS CLI. The following example shows how to launch a new DAX cluster using a custom parameter group. In this example, the item cache TTL is set to 10 minutes, and the query cache TTL is set to 3 minutes.

You can now launch a new DAX cluster with this parameter group.

aws dax create-cluster \
    --cluster-name MyNewCluster \
    --node-type dax.r3.large \
    --replication-factor 3 \
    --iam-role-arn arn:aws:iam::123456789012:role/DAXServiceRole \
    --parameter-group custom-ttl

Tagging support for DAX

Many AWS services, including DynamoDB, support tagging—the ability to label resources with user-defined names. You can assign tags to DAX clusters, allowing you to quickly identify all of your AWS resources that have the same tag, or to categorize your AWS bills by the tags you assign.

For more information, see Adding tags and labels to resources in DynamoDB.

Using the AWS Management Console

Using the AWS CLI

When you use the AWS CLI to manage DAX cluster tags, you must first determine the Amazon Resource Name (ARN) for the cluster. The following example shows how to determine the ARN for a cluster named MyDAXCluster.

aws dax describe-clusters \
    --cluster-name MyDAXCluster \
    --query "Clusters[*].ClusterArn"

In the output, the ARN will look similar to this: arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

The following example shows how to tag the cluster.

aws dax tag-resource  \
    --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \
    --tags="Key=ClusterUsage,Value=prod"

List all the tags for a cluster.

aws dax list-tags \
    --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

To remove a tag, specify its key.

aws dax untag-resource  \
    --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \
    --tag-keys ClusterUsage

AWS CloudTrail integration

DAX is integrated with AWS CloudTrail, allowing you to audit DAX cluster activities. You can use CloudTrail logs to view all the changes that have been made at the cluster level. You can also see changes to cluster components such as nodes, subnet groups, and parameter groups. For more information, see Logging DynamoDB operations by using AWS CloudTrail.

Deleting a DAX cluster

If you are no longer using a DAX cluster, you should delete it to avoid being charged for unused resources.

You can delete a DAX cluster using the console or the AWS CLI. The following is an example.

aws dax delete-cluster --cluster-name mydaxcluster