A walkthrough of the Amazon DynamoDB Accelerator console – Part 2

Amazon DynamoDB provides scalability and performance where response times are measured in single-digit milliseconds. For use cases requiring response times in microseconds, DynamoDB Accelerator (DAX) is the service that helps deliver that. DAX is a managed cache that is API compatible with DynamoDB  providing fast in-memory performance for demanding applications like real-time gaming, bidding, weather analysis and trading. With DAX, users save cost by efficiently provisioning read capacity units and experience increased throughput as response times of eventually-consistent read workloads is reduced to microseconds.

In this blog post, the focus will be on using the web-based DynamoDB console to enable DAX with just a few clicks. Over the course of this walkthrough, you will gain a better understanding of the DAX core components like clusters, nodes, subnet groups, parameter groups, and events.

A detailed walkthrough of DynamoDB Accelerator section of the DynamoDB console

You can refer to Part 1 of this blog post for setting up DynamoDB. This walkthrough assumes that you have accessed the DynamoDB console at least once and will provide a step-by-step walkthrough of all the features available on the DynamoDB DAX section of the console and how you can access them from thereon.

After your first visit to the DynamoDB DAX console, you always start on the Dashboard page of the console. The dashboard provides details about your DAX components, recent alerts triggered by Amazon CloudWatch alarms, DAX service health, and other information about the DynamoDB Accelerator.

As numbered in the preceding screenshot, the sections of the dashboard include:

Clusters

DAX runs within an Amazon VPC and unless specified, the DAX cluster will run within a default VPC. This means that DAX cluster is not accessible over the Internet.

 At a high level, a DAX cluster consists of one or more nodes where one node serves as the ‘primary’ and additional nodes (if present) serve as read replicas for the cluster. A DAX cluster can support up to ten nodes per cluster (the primary node, plus a maximum of nine read replicas).

At runtime, the DAX client directs all of the application’s DynamoDB API requests to the DAX cluster.  While the application and DAX client can be configured on various compute platforms that can be accessed in a VPC like Lambda, for this example, an Amazon EC2 instance is launched into the VPC, and then the application (with the DAX client) is deployed on the EC2 instance. The application accesses DAX by specifying an endpoint for the DAX cluster. The DAX client works with the cluster endpoint to perform intelligent load-balancing and routing, so that incoming requests are evenly distributed across all the nodes in the cluster. Thus, it is very simple to implement DAX as one endpoint can handle all traffic.

When you use GetItem with the DAX client, the request reaches DAX and if DAX can process one of these API requests directly via its cache (cache hit), it does so within microseconds; otherwise i.e. if the item is not available in the  cache (cache miss), it passes the request to DynamoDB. DynamoDB returns the requested item, and DAX stores it in the item cache. Finally, the DAX cluster returns the item to the application. Also, if the DAX cluster contains more than one node, the item is replicated to all of the other nodes in the cluster. This is possible because DAX is a write-through caching service specifically designed to simplify the process of adding a cache to Amazon DynamoDB tables.

Creating the cluster

To create a DAX cluster:

1. From the Clusters page in the DAX section of the DynamoDB console, choose Create cluster.

2. On the Create DynamoDB Accelerator (DAX) cluster page, I enter the Cluster name and then select the node type, cluster size, encryption option, IAM role, subnet group and security group for my DAX cluster.

For this walkthrough, I enter DAX-console for Cluster name and select the following for the remaining components:

• Node type: I use the default selection of dax.r4.xlarge as the node type for my cluster. Every node within a cluster is of the same node type i.e. it is a full replica and it maintains a single replica of the cached data. You can scale your DAX cluster in one of the two ways:
  • By adding nodes to the cluster. This will increase the overall read throughput of the cluster.
  • By using a larger node type. Larger node types provide more capacity and can increase throughput. (Note that you must create a new cluster with the new node type.)
• Cluster size: I use the default selection of 3 node(s). A cluster consists of one primary node, and up to nine read replicas, which means you can have either a single-node or a multi-node cluster.
  It is recommended for production usage to have a multi-node DAX cluster i.e. with 3 nodes (one primary and two read replicas), where each node is placed in different Availability Zone so that High Availability is guaranteed especially if any of the Availability Zones were to experience an outage. You can add or delete nodes even on a running DAX cluster as well.
• Encryption: I leave the default settings to use Enable Encryption. DAX encryption at rest provides an additional data protection layer by securing data from unauthorized access to the underlying storage.
  You cannot enable or disable encryption at rest after a cluster has been created. A cluster must be re-created to enable encryption at rest if it was not enabled at creation.

• IAM role: When a DAX cluster is created, it must be associated with an IAM role which defines the DynamoDB actions that the DAX Cluster can perform on behalf of the users who interact with it i.e. users/application will inherit the permissions of the DAX cluster’s IAM policy when they access the DAX cluster. I choose to Create new, and enter the following information:
  • IAM role name – I leave it to use the default name DAXtoDynamoDB. A new IAM role with this name will be created, and the DAX cluster will assume this role at runtime.
  • IAM role policy – I choose Read/Write and an IAM policy name field pops up along with the Target DynamoDB table. This policy will allow the DAX cluster to perform read and write operations in DynamoDB. However, in a production environment the IAM policy should be scoped for security least privileges best practices.
  • IAM policy name – I leave it to use the default name DAXtoDynamoDBPolicy for an IAM policy. Now, a new IAM policy with this name will be created, and attached to the IAM role.
  • Target DynamoDB table – I leave the option to select All tables that have been created in DynamoDB. This means that the DAX cluster will cache requests for all DynamoDB tables created in that account.

• Subnet group— It is a collection of one or more subnets within your VPC. When a DAX cluster is created, the nodes will be deployed to the subnets within the subnet group. You can use an existing subnet group you have created. As I don’t have any, I choose to Create new, and enter the following information:
  • Name – I enter my-subnet-group as a short name for the subnet group.
  • Description – I enter DAX subnet group as a description for the subnet group.
  • VPC ID – I select the Default VPC to be used for the subnet group.
  • Subnets – I select 3 subnets for the subnet group. You can choose one or more subnets from the list. These subnets can be modified even after the creation of the cluster.
    Note: The subnets are distributed among multiple Availability Zones. If you plan to create a multi-node DAX cluster (a primary node and one or more read replicas), it is recommended that you choose multiple subnet IDs, so that DAX can deploy the cluster nodes into multiple Availability Zones.
• Security Groups – I leave the option to use default security group.

• Cluster Settings – I leave the cluster settings to Use default settings. Default settings provide the fastest way to get started with your cluster and these settings can be modified either now or after the DAX cluster has been created. You can edit the DAX cluster settings after its creation by replacing the current parameter group in use with a custom one.

Alternatively, if you choose to customize DAX cluster settings while the DAX cluster is being created, you will need to deselect Use default settings. You will then be allowed to modify the following settings:

Here is a brief description on what the various fields mean:

• Cluster Description: Here you can provide a short description of your DAX cluster
• Availability zones: This field allows you to either select the Availability zones for each of the nodes in your cluster or you can select No Preference which will allow for even distribution of the nodes in your cluster across the available Availability zones.
  For maximum fault tolerance, you should deploy read replicas in separate Availability Zones. This configuration ensures that your DAX cluster can continue to function, even if an entire Availability Zone should become unavailable.
• Parameter group: A parameter group is a named set of parameters that you can apply to a cluster, thereby guaranteeing exactly similar configuration for all of the nodes in that cluster. Parameter groups are used to manage runtime settings for DAX clusters. DAX has several parameters that you can use to optimize performance (such as defining a TTL policy for cached data). You can either select an existing parameter group or opt to Create new. With the latter option, you can define the following parameters to be applied to all nodes in your cluster:
  • Parameter group name: This is a mandatory field.
  • Description: You can add an optional description for your parameter group.
  • Query TTL: DAX maintains a query cache to store the results from Query and Scan operations.
  • Item TTL: DAX maintains an item cache to store the results from GetItem and BatchGetItem operations.
    Both the query and item cache have a time-to-live setting (TTL), which is 5 minutes or 300 seconds by default. These fields are optional and you can choose to specify a custom TTL. If left blank, a default TTL of 5 minutes is used. Currently, there is no upper limit to the TTLs you can specify for DAX.

To make updates appear instantly, you can set the Query/Item TTL to 0 i.e. disable it using a custom parameter group through AWS CLI as the AWS Console will throw the below error message. The downside of this setting is that DAX will never refresh a value based on TTL and query/scan operations will no longer be cached.

• Maintenance Window: Every cluster has a weekly maintenance window during which any system changes are applied. If you don’t specify a preferred maintenance window while creating or modifying a cache cluster, DAX assigns a 60-minute maintenance window on a randomly selected day of the week from an 8-hour block of time per region. To learn more about the time blocks for each region, see Maintenance Window.
  For this example, I have selected a 60-minute long weekly maintenance window scheduled for Sunday’s at 12:00 am UTC.
  Topic for SNS Notification: You can choose from the following options to be either notified or not of these scheduled maintenance events:
  • Disable notification,
  • Create a new SNS topic,
  • Add SNS topic ARN, or,
  • Use an existing SNS topic

3. When the settings are as you want them, choose Launch cluster.
4. You can now see the dax-console table that I’ve created on the Clusters page of the DAX console, as shown in the following screenshot. The DAX cluster will be listed with a status of Creating.
   
5. Creating the cluster will take several minutes. When the cluster is ready, its status changes to Available.
   As you can see in the below screenshot, the DAX cluster now has a dedicated cluster endpoint with 3 nodes of node type ‘dax.r4.large’ spread over 3 availability zones.
   

Each tab on the Clusters page includes information about the cluster. The Overview section of the DAX cluster dax-console lists all parameters we configured earlier like cluster name and description, node type, cluster size, parameter group with Query and Item TTLs, subnet group enlisting security groups, Availability Zones and VPCs, maintenance windows and cluster’s availability and encryption status. Additionally, few parameters get assigned to a DAX cluster upon its creation which are highlighted below:

1. Cluster Endpoint: A cluster endpoint is assigned to every DAX cluster for use by your application/DAX client. The endpoint masks the addition and deletion of the nodes in the cluster and therefor, your application/DAX client does not care about the host names and port numbers of individual nodes in the cluster.
   A point to note here is that the DAX cluster endpoint is only accessible within the VPC that the DAX cluster is created in i.e. vpc-75bffe11 in this case and cannot be accessed via the Internet.
2. Cluster ARN.: A cluster Amazon Resource Identifier (ARN) is assigned to every DAX cluster which can be used in an IAM policy to define permissions for DAX API actions.
3. IAM service role ARN: This ARN is for the IAM service role created earlier which determine DynamoDB resources and API actions that the user can access via the DAX Cluster.

Editing the cluster

You can choose to edit a running DAX cluster. Currently, you can edit the cluster description, Parameter group, Maintenance window and Topic for SNS notification settings of a DAX cluster. I’ll walk you through the process of editing a DAX cluster for the example I created in this walkthrough:

1. Select the desired DAX cluster that needs modification and choose Edit as the Action on the Clusters page of the console.
2. A pop-up window asks you to select and enter the settings you would like to modify.
3. Choose Save to add the desired changes to the cluster.

Clusters tabs

Let’s look at the tabs on the Clusters page of the DynamoDB console:

Overview tab

The Overview tab (see the preceding screenshot) includes configuration details of the DAX cluster like the Cluster name, endpoint and ARN, number of nodes and the node type, parameter and subnet groups, maintenance window and other crucial information needed to identify a DAX cluster.

Nodes tab

In this section, you can add, delete or reboot a node. As explained earlier in the blog post, a node is the smallest building block of a DAX cluster. A DAX cluster can be scaled by the addition or deletion of nodes and this is the section where this manual scaling can be performed.

Rebooting a node: For a single-node cluster, rebooting the node will restart the DAX process and take the node temporarily offline. However, this will not affect the contents of the cache. For a multi-node cluster, rebooting the node will take the node temporarily offline until it is rebooted and re-synced with one of its peers to bring its cache up-to-date.

Adding a node: While adding a node to an existing DAX cluster, you have the option to select the number of new nodes to be added i.e. from 1-7 in my example and Availability zone(s) for each of them. These nodes will serve as Read Replicas for your DAX cluster.

Metrics tab

You can monitor DAX using Amazon CloudWatch, which collects and processes raw data from DAX into readable, near real-time metrics. These statistics are recorded for a period of two weeks. By default, DAX metric data is sent to CloudWatch automatically. You can alternatively view your DAX cluster metrics in the CloudWatch console using the DAX namespace.

When you create the DAX Cluster, a number of metrics are created so you can monitor DAX cluster. Some of the key metrics to gauge the performance of a DAX cluster are:

CPU Utilization: The percentage of CPU utilization of the node or cluster.

Item Cache Hits: The number of successful item lookups based on its primary key.

Item Cache Misses: The number of unsuccessful item lookups based on its primary key.

Query Cache Hits: The number of successful query result lookups based on query parameters.

Query Cache Misses: The number of unsuccessful query result lookups based on query parameters.

Query Request Count: The number of Scan requests handled by the instance.

Failed request count (total): Total number of requests that resulted in an error reported by the instance.

Error request count (customer errors): Total number of requests that resulted in a user error reported by the instance.

Fault request count (service errors): Total number of requests that resulted in an internal error reported by the instance.

Total request Count: Total number of requests submitted to the cluster.

DatabaseSize: The amount of storage allocated for storing objects in Dax.

Increase in cache misses/CPU utilization/total request count does have a negative impact on cluster performance. In such situations, you can scale the DAX cluster horizontally based on a threshold configured for the CloudWatch metric/s. This will help increase the overall read throughput of the cluster. Alternatively, you can create a new DAX cluster which uses a larger node type as that will enable the cluster to store more data in memory, reducing cache misses and improving overall application performance.

Alarms tab

Like with any other CloudWatch metrics, you can create Amazon CloudWatch alarms for DAX related metrics that sends an Amazon SNS message when the alarm changes state. You can create, edit and/or delete alarms from the Alarms tab of the DAX console. Alerting is useful in scenarios when a node is added or removed from a cluster during scaling activities and/or when there is an issue with the DAX cluster related but not limited to its performance, cluster timeouts etc..

Tags tab

Most services in AWS, including DynamoDB, support tagging as a feature which provides the ability to label resources with user-defined names. Tags can be assigned to DAX clusters, allowing for quick identification of all of your AWS resources that have the same tag, or can be helpful to categorize your AWS bills by the tags you assign.

Subnet groups

This section of the DAX console performs similarly to when a subnet group is created while creating a DAX cluster.

While subnet groups cannot be attached/replaced to a running DAX cluster, you have the option to Create subnet group in this section of the console. While creating a DAX cluster, you can then opt for using an existing subnet group.

While you can modify an existing subnet group of a running DAX cluster using the Edit action or Delete a subnet group, you will receive an error message if the DAX cluster’s nodes are still associate with any of subnets of the subnet group. Also, you cannot delete a subnet group if it is associated with any DAX clusters.

Parameter groups

This section of the DAX console also performs similarly to when a parameter group is created while creating a DAX cluster.

You have an option to Create parameter group in this section of the console that can be attached/replaced to a running DAX cluster. You can either opt for using an existing parameter group while creating a DAX cluster or use it on a running DAX cluster. If you have multiple DAX clusters which make use of Item/Query TTL values based on caching needs, you can opt for using different parameter groups.

You can also modify the settings of a parameter group i.e. name, Item and Query TTL values using the Edit action or Delete a parameter group. You cannot delete a parameter group if it is associated with any DAX clusters.

Events

DAX records significant events within your clusters, such as a failure to add a node, success in adding a node, or changes to security groups. By monitoring key events, you can know the current state of your clusters and, depending upon the event, be able to take corrective action. You can access these events using the Events section of DAX console. You can also request that notifications be sent to a specific Amazon SNS topic, so that you will know immediately when an event occurs in your DAX cluster.

Deleting the cluster

If you are no longer using a DAX cluster, you should delete it to avoid being charged for unused resources. I’ll walk you through the process of deleting a DAX cluster by deleting the example I created in this walkthrough:

1. Select the desired DAX cluster to be deleted and choose Delete as the Action on the Clusters page of the console.
2. A pop-up window asks you to confirm your choice: Delete all CloudWatch alarms for this cluster (chosen by default).
3. Choose Delete to complete the deletion of the cluster.

Conclusion

In this blog post, I walked through the DynamoDB Accelerator section of the DynamoDB console explaining DAX’s key components/features along the way like Subnet/Parameter groups, Query/Item cache, TTLs, DAX scaling, CloudWatch monitoring and alerting among other things and how they can be configured using the console. I also provided an example of how to create a cluster, edit the cluster, and then delete the cluster on the console. New Users will gain better understanding of the AWS console when exploring DAX as a service.

At the time of writing this blog post, DAX is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), South America (São Paulo), EU (Ireland), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), and Asia Pacific (Mumbai) Regions.

About the Author

Ishita Mehta-Desai is a technical account manager at AWS. She enjoys providing technical guidance to customers and exploring new places.