# Creating a DAX cluster
This section walks you through the first-time setup and usage of Amazon DynamoDB Accelerator (DAX) in your default Amazon Virtual Private Cloud (Amazon VPC) environment. You can create your first DAX cluster using either the AWS Command Line Interface (AWS CLI) or the AWS Management Console.
After you create your DAX cluster, you can access it from an Amazon EC2 instance running in the same VPC. You can then use your DAX cluster with an application program. For more information, see [Developing with the DynamoDB Accelerator (DAX) client](DAX.client.md).
**Topics**
+ [Creating an IAM service role for DAX to access DynamoDB](#DAX.create-cluster.iam-permissions)
+ [DAX and IPv6](DAX.create-cluster.DAX_and_IPV6.md)
+ [Creating a DAX cluster using the AWS CLI](DAX.create-cluster.cli.md)
+ [Creating a DAX cluster using the AWS Management Console](DAX.create-cluster.console.md)
## Creating an IAM service role for DAX to access DynamoDB
For your DAX cluster to access DynamoDB tables on your behalf, you must create a *service role*. A service role is an AWS Identity and Access Management (IAM) role that authorizes an AWS service to act on your behalf. The service role allows DAX to access your DynamoDB tables, as if you were accessing those tables yourself. You must create the service role before you can create the DAX cluster.
If you are using the console, the workflow for creating a cluster checks for the presence of a pre-existing DAX service role. If none is found, the console creates a new service role for you. For more information, see [Step 2: Create a DAX cluster using the AWS Management Console](DAX.create-cluster.console.md#DAX.create-cluster.console.create-cluster).
If you are using the AWS CLI, you must specify a DAX service role that you have created previously. Otherwise, you need to create a new service role beforehand. For more information, see [Step 1: Create an IAM service role for DAX to access DynamoDB using the AWS CLI](DAX.create-cluster.cli.md#DAX.create-cluster.cli.create-service-role).
### Permissions required to create a service role
The AWS managed `AdministratorAccess` policy provides all the permissions needed for creating a DAX cluster and a service role. If your user has `AdministratorAccess` attached, no further action is needed.
Otherwise, you must add the following permissions to your IAM policy so that your user can create the service role:
+ `iam:CreateRole`
+ `iam:CreatePolicy`
+ `iam:AttachRolePolicy`
+ `iam:PassRole`
Attach these permissions to the user who is trying to perform the action.
**Note**
The `iam:CreateRole`, `iam:CreatePolicy`, `iam:AttachRolePolicy`, and `iam:PassRole` permissions are not included in the AWS managed policies for DynamoDB. This is by design because these permissions provide the possibility of privilege escalation: That is, a user could use these permissions to create a new administrator policy and then attach that policy to an existing role. For this reason, you (the administrator of your DAX cluster) must explicitly add these permissions to your policy.
### Troubleshooting
If your user policy is missing the `iam:CreateRole`, `iam:CreatePolicy`, and `iam:AttachPolicy` permissions, you will get error messages. The following table lists these messages and describes how to correct the problems.
****
| If you see this error message... | Do the following: |
| --- | --- |
| User: arn:aws:iam::accountID:user/userName is not authorized to perform: iam:CreateRole on resource: arn:aws:iam::accountID:role/service-role/roleName | Add iam:CreateRole to your user policy. |
| User: arn:aws:iam::accountID:user/userName is not authorized to perform: iam:CreatePolicy on resource: policy policyName | Add iam:CreatePolicy to your user policy. |
| User: arn:aws:iam::accountID:user/userName is not authorized to perform: iam:AttachRolePolicy on resource: role daxServiceRole | Add iam:AttachRolePolicy to your user policy. |
For more information about the IAM policies required for DAX cluster administration, see [DAX access control](DAX.access-control.md).
# DAX and IPv6
DynamoDB DAX now supports IPv6 addressing, that allows you to create clusters that operate in IPv4-only, IPv6-only, or dual-stack networking modes. This helps in enhancing networking capabilities to meet evolving infrastructure requirements.
**Network Types:**
You can create clusters with the following network types:
+ IPv4-only
+ IPv6-only
+ Dual-stack (supports both IPv4 and IPv6)
**Key Features:**
With IPv6 support, you can do the following:
+ **Network configuration options:**
+ IPv4-only and dual-stack clusters on `dual_stack subnets`.
+ IPv6-only clusters on IPv6-only subnets.
+ **Subnet group management:**
+ Create subnet groups with IPv4-only, IPv6-only, or dual-stack support
+ Modify existing subnet groups with additional VPC subnets
+ Add IPv6-only subnets to IPv6-configured subnet groups
+ Add IPv4 or dual-stack subnets to IPv4 and dual-stack configured groups
+ **Client configuration:**
+ When making data plane calls, you can set preferred IP protocol for dual\$1stack clusters using:
+ `ip_discovery` parameter in Python SDK
+ `ipDiscovery` parameter in other SDKs
+ Default: IPv4 when protocol preference not specified
Before implementing IPv6 in your DAX clusters, you must consider the following:
+ Network type cannot be changed after cluster creation
+ For dual-stack clusters, the `ip_discovery/ipDiscovery` parameter in the client configuration determines which IP protocol to use (IPv4 or IPv6)
+ Different applications can connect to the same dual-stack cluster using different IP protocols based on their configuration
**Example client configuration**
```
DynamoDbAsyncClient client = ClusterDaxAsyncClient.builder()
.overrideConfiguration(Configuration.builder()
.url(endpoint) // DAX cluster endpoint
.ipDiscovery(ipDiscovery) // IP discovery type (IPv4 or IPv6)
.build())
.build();
```
**Important**
When you use resource-based IAM policies to restrict IP addresses for DynamoDB tables in IPv6-only environments with DAX, you must create an exception for your DAX cluster's IAM role if you block the IPv4 address space (`0.0.0.0/0`). Add an `ArnNotEquals` condition to your policy that specifically allows access for the DAX cluster's IAM role while maintaining IP-based restrictions for other access paths. Without this exception, DAX cannot access your DynamoDB table.
For example:
**Example**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "dynamodb:PutItem",
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MusicCollection",
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/DAXServiceRoleForDynamoDBAccess"
},
"IpAddress": {
"aws:SourceIp": "0.0.0.0/0"
}
}
}
]
}
```
# Creating a DAX cluster using the AWS CLI
This section describes how to create an Amazon DynamoDB Accelerator (DAX) cluster using the AWS Command Line Interface (AWS CLI). If you haven't already done so, you must install and configure the AWS CLI. To do this, see the following instructions in the *AWS Command Line Interface User Guide*:
+ [Installing the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ [Configuring the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)
**Important**
To manage DAX clusters using the AWS CLI, install or upgrade to version 1.11.110 or higher.
All of the AWS CLI examples use the `us-west-2` Region and fictitious account IDs.
**Topics**
+ [Step 1: Create a service role](#DAX.create-cluster.cli.create-service-role)
+ [Step 2: Create a subnet group](#DAX.create-cluster.cli.create-subnet-group)
+ [Step 3: Create a DAX cluster](#DAX.create-cluster.cli.create-cluster)
+ [Step 4: Configure security group inbound rules](#DAX.create-cluster.cli.configure-inbound-rules)
## Step 1: Create an IAM service role for DAX to access DynamoDB using the AWS CLI
Before you can create an Amazon DynamoDB Accelerator (DAX) cluster, you must create a service role for it. A *service role* is an AWS Identity and Access Management (IAM) role that authorizes an AWS service to act on your behalf. The service role allows DAX to access your DynamoDB tables as if you were accessing those tables yourself.
In this step, you create an IAM policy and then attach that policy to an IAM role. This enables you to assign the role to a DAX cluster so that it can perform DynamoDB operations on your behalf.
**To create an IAM service role for DAX**
1. Create a file named `service-trust-relationship.json` with the following contents.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "dax.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
1. Create the service role.
```
aws iam create-role \
--role-name DAXServiceRoleForDynamoDBAccess \
--assume-role-policy-document file://service-trust-relationship.json
```
1. Create a file named `service-role-policy.json` with the following contents.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"dynamodb:DescribeTable",
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:Query",
"dynamodb:Scan",
"dynamodb:BatchGetItem",
"dynamodb:BatchWriteItem",
"dynamodb:ConditionCheckItem"
],
"Effect": "Allow",
"Resource": [
"arn:aws:dynamodb:us-west-2:111122223333:*"
]
}
]
}
```
------
Replace *accountID* with your AWS account ID. To find your AWS account ID, in the upper-right corner of the console, choose your login ID. Your AWS account ID appears in the drop-down menu.
In the Amazon Resource Name (ARN) in the example, *accountID* must be a 12-digit number. Don't use hyphens or any other punctuation.
1. Create an IAM policy for the service role.
```
aws iam create-policy \
--policy-name DAXServicePolicyForDynamoDBAccess \
--policy-document file://service-role-policy.json
```
In the output, note the ARN for the policy that you created, as in the following example.
`arn:aws:iam::123456789012:policy/DAXServicePolicyForDynamoDBAccess`
1. Attach the policy to the service role. Replace *arn* in the following code with the actual role ARN from the previous step.
```
aws iam attach-role-policy \
--role-name DAXServiceRoleForDynamoDBAccess \
--policy-arn arn
```
Next, you specify a subnet group for your default VPC. A *subnet group* is a collection of one or more subnets within your VPC. See [Step 2: Create a subnet group](#DAX.create-cluster.cli.create-subnet-group).
## Step 2: Create a subnet group
Follow this procedure to create a subnet group for your Amazon DynamoDB Accelerator (DAX) cluster using the AWS Command Line Interface (AWS CLI).
**Note**
If you already created a subnet group for your default VPC, you can skip this step.
DAX is designed to run within an Amazon Virtual Private Cloud environment (Amazon VPC). If you created your AWS account after December 4, 2013, you already have a default VPC in each AWS Region. For more information, see [Default VPC and default subnets](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) in the *Amazon VPC User Guide*.
**To create a subnet group**
1. To determine the identifier for your default VPC, enter the following command.
```
aws ec2 describe-vpcs
```
In the output, note the identifier for your default VPC, as in the following example.
`vpc-12345678`
1. Determine the subnet IDs associated with your default VPC. Replace *vpcID* with your actual VPC ID—for example, `vpc-12345678`.
```
aws ec2 describe-subnets \
--filters "Name=vpc-id,Values=vpcID" \
--query "Subnets[*].SubnetId"
```
In the output, note the subnet identifiers—for example, `subnet-11111111`.
1. Create the subnet group. Ensure that you specify at least one subnet ID in the `--subnet-ids` parameter.
```
aws dax create-subnet-group \
--subnet-group-name my-subnet-group \
--subnet-ids subnet-11111111 subnet-22222222 subnet-33333333 subnet-44444444
```
To create the cluster, see [Step 3: Create a DAX cluster using the AWS CLI](#DAX.create-cluster.cli.create-cluster).
## Step 3: Create a DAX cluster using the AWS CLI
Follow this procedure to use the AWS Command Line Interface (AWS CLI) to create an Amazon DynamoDB Accelerator (DAX) cluster in your default Amazon VPC.
**To create a DAX cluster**
1. Get the Amazon Resource Name (ARN) for your service role.
```
aws iam get-role \
--role-name DAXServiceRoleForDynamoDBAccess \
--query "Role.Arn" --output text
```
In the output, note the service role ARN, as in the following example.
`arn:aws:iam::123456789012:role/DAXServiceRoleForDynamoDBAccess`
1. Create the DAX cluster. Replace `roleARN` with the ARN from the previous step.
```
aws dax create-cluster \
--cluster-name mydaxcluster \
--node-type dax.r4.large \
--replication-factor 3 \
--iam-role-arn roleARN \
--subnet-group my-subnet-group \
--sse-specification Enabled=true \
--region us-west-2
```
All of the nodes in the cluster are of type `dax.r4.large` (`--node-type`). There are three nodes (`--replication-factor`)—one primary node and two replicas.
**Note**
Since `sudo` and `grep` are reserved keywords, you cannot create a DAX cluster with these words in the cluster name. For example, `sudo` and `sudocluster` are invalid cluster names.
To view the cluster status, enter the following command.
```
aws dax describe-clusters
```
The status is shown in the output—for example, `"Status": "creating"`.
**Note**
Creating the cluster takes several minutes. When the cluster is ready, its status changes to `available`. In the meantime, proceed to [Step 4: Configure security group inbound rules using the AWS CLI](#DAX.create-cluster.cli.configure-inbound-rules) and follow the instructions there.
## Step 4: Configure security group inbound rules using the AWS CLI
The nodes in your Amazon DynamoDB Accelerator (DAX) cluster use the default security group for your Amazon VPC. For the default security group, you must authorize inbound traffic on TCP port 8111 for unencrypted clusters or port 9111 for encrypted clusters. This allows Amazon EC2 instances in your Amazon VPC to access your DAX cluster.
**Note**
If you launched your DAX cluster with a different security group (other than `default`), you must perform this procedure for that group instead.
**To configure security group inbound rules**
1. To determine the default security group identifier, enter the following command. Replace `vpcID` with your actual VPC ID (from [Step 2: Create a subnet group](#DAX.create-cluster.cli.create-subnet-group)).
```
aws ec2 describe-security-groups \
--filters Name=vpc-id,Values=vpcID Name=group-name,Values=default \
--query "SecurityGroups[*].{GroupName:GroupName,GroupId:GroupId}"
```
In the output, note the security group identifier—for example, `sg-01234567`.
1. Then enter the following. Replace `sgID` with your actual security group identifier. Use port `8111` for unencrypted clusters and `9111` for encrypted clusters.
```
aws ec2 authorize-security-group-ingress \
--group-id sgID --protocol tcp --port 8111
```
# Creating a DAX cluster using the AWS Management Console
This section describes how to create an Amazon DynamoDB Accelerator (DAX) cluster using the AWS Management Console.
**Topics**
+ [Step 1: Create a subnet group](#DAX.create-cluster.console.create-subnet-group)
+ [Step 2: Create a DAX cluster](#DAX.create-cluster.console.create-cluster)
+ [Step 3: Configure security group inbound rules](#DAX.create-cluster.console.configure-inbound-rules)
## Step 1: Create a subnet group using the AWS Management Console
Follow this procedure to create a subnet group for your Amazon DynamoDB Accelerator (DAX) cluster using the AWS Management Console.
**Note**
If you already created a subnet group for your default VPC, you can skip this step.
DAX is designed to run within an Amazon Virtual Private Cloud (Amazon VPC) environment. If you created your AWS account after December 4, 2013, you already have a default VPC in each AWS Region. For more information, see [Default VPC and default subnets](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) in the *Amazon VPC User Guide*.
As part of the creation process for a DAX cluster, you must specify a *subnet group*. A subnet group is a collection of one or more subnets within your VPC. When you create your DAX cluster, the nodes are deployed to the subnets within the subnet group.
**Note**
The VPC having this DAX cluster can contain other resources and even VPC endpoints for the other services except VPC endpoint for ElastiCache and can result in error for the DAX cluster operations.
**To create a subnet group**
1. Open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).
1. In the navigation pane, under **DAX**, choose **Subnet groups**.
1. Choose **Create subnet group**.
1. In the **Create subnet group** window, do the following:
1. **Name**—Enter a short name for the subnet group.
1. **Description**—Enter a description for the subnet group.
1. **VPC ID**—Choose the identifier for your Amazon VPC environment.
1. **Subnets**—Choose one or more subnets from the list.
**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), we recommend that you choose multiple subnet IDs. Then DAX can deploy the cluster nodes into multiple Availability Zones. If an Availability Zone becomes unavailable, DAX automatically fails over to a surviving Availability Zone. Your DAX cluster will continue to function without interruption.
When the settings are as you want them, choose **Create subnet group**.
To create the cluster, see [Step 2: Create a DAX cluster using the AWS Management Console](#DAX.create-cluster.console.create-cluster).
## Step 2: Create a DAX cluster using the AWS Management Console
Follow this procedure to create an Amazon DynamoDB Accelerator (DAX) cluster in your default Amazon VPC.
**To create a DAX cluster**
1. Open the DynamoDB console at [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/).
1. In the navigation pane, under **DAX**, choose **Clusters**.
1. Choose **Create cluster**.
1. In the **Create cluster** window, do the following:
1. **Cluster name**—Enter a short name for your DAX cluster.
**Note**
Since `sudo` and `grep` are reserved keywords, you cannot create a DAX cluster with these words in the cluster name. For example, `sudo` and `sudocluster` are invalid cluster names.
1. **Cluster description**—Enter a description for the cluster.
1. **Node types**—Choose the node type for all of the nodes in the cluster.
1. **Cluster size**—Choose the number of nodes in the cluster. A cluster consists of one primary node and up to nine read replicas.
**Note**
If you want to create a single-node cluster, choose **1**. Your cluster will consist of one primary node.
If you want to create a multi-node cluster, choose a number between **3** (one primary and two read replicas) and **10** (one primary and nine read replicas).
For production usage, we strongly recommend using DAX with at least three nodes, where each node is placed in a different Availability Zone. Three nodes are required for a DAX cluster to be fault-tolerant.
A DAX cluster can be deployed with one or two nodes for development or test workloads. One- and two-node clusters are not fault-tolerant, and we don't recommend using fewer than three nodes for production use. If a one- or two-node cluster encounters software or hardware errors, the cluster can become unavailable or lose cached data.
1. Choose **Next**.
1. **Subnet group**—Select **Choose existing** and choose the subnet group that you created in [Step 1: Create a subnet group using the AWS Management Console](#DAX.create-cluster.console.create-subnet-group).
1. **Access control**—Choose the **default** security group.
1. **Availability Zones (AZ)**—Choose **Automatic**.
1. Choose next.
1. **IAM service role for DynamoDB access**—Choose **Create new**, and enter the following information:
+ **IAM role name**—Enter a name for an IAM role, for example, `DAXServiceRole`. The console creates a new IAM role, and your DAX cluster assumes this role at runtime.
+ Select the box next to **Create policy**.
+ **IAM role policy**—Choose **Read/Write**. This allows the DAX cluster to perform read and write operations in DynamoDB.
+ **New IAM policy name**—This field will populate as you enter the IAM role name. You can also enter a name for an IAM policy, for example, `DAXServicePolicy`. The console creates a new IAM policy and attaches the policy to the IAM role.
+ **Access to DynamoDB tables**—Choose **All tables**.
1. **Encryption**—Choose **Turn on encryption at rest** and **Turn on encryption in transit** For more information, see [DAX encryption at rest](DAXEncryptionAtRest.md) and [DAX encryption in transit](DAXEncryptionInTransit.md).
A separate service role for DAX to access Amazon EC2 is also required. DAX automatically creates this service role for you. For more information, see [Using service-linked roles for DAX](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/using-service-linked-roles.html).
1. When the settings are as you want them, choose **Next**.
1. **Parameter group**—Choose **Choose existing**.
1. **Maintenance window**—Choose **No preference** if you don't have a preference when software upgrades are applied, or choose **Specify time window** and provide the **Weekday**, **Time(UTC)** and **Start within (hours)** options to schedule your maintenance window.
1. **Tags**—Choose **Add new tag** to enter a key/value pair for tagging purposes.
1. Choose **Next**.
On the **Review and create** screen, you can review all of the settings. If you are ready to create the cluster, choose **Create cluster**.
On the **Clusters** screen, your DAX cluster will be listed with a status of **Creating**.
**Note**
Creating the cluster takes several minutes. When the cluster is ready, its status changes to **Available**.
In the meantime, proceed to [Step 3: Configure security group inbound rules using the AWS Management Console](#DAX.create-cluster.console.configure-inbound-rules) and follow the instructions there.
## Step 3: Configure security group inbound rules using the AWS Management Console
Your Amazon DynamoDB Accelerator (DAX) cluster communicates via TCP port 8111 (for unencrypted clusters) or 9111 (for encrypted clusters), so you must authorize inbound traffic on that port. This allows Amazon EC2 instances in your Amazon VPC to access your DAX cluster.
**Note**
If you launched your DAX cluster with a different security group (other than `default`), you must perform this procedure for that group instead.
**To configure security group inbound rules**
1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In the navigation pane, choose **Security Groups**.
1. Choose the **default** security group. On the **Actions** menu, choose **Edit inbound rules**.
1. Choose **Add Rule**, and enter the following information:
+ **Port Range**—Enter **8111** (if your cluster is unencrypted) or **9111** (if your cluster is encrypted).
+ **Source**—Leave this as **Custom**, and choose the search field to the right. A drop-down menu will be displayed. Choose the identifier for your default security group.
1. Choose **Save rules** to save your changes.
1. To update the name in the console, go to the **Name** property and choose the **Edit** option that is displayed.