# Internetwork traffic privacy MemoryDB uses the following techniques to secure your data and protect it from unauthorized access: + **[MemoryDB and Amazon VPC](vpcs.md)** explains the type of security group you need for your installation. + **[MemoryDB API and interface VPC endpoints (AWS PrivateLink)](memorydb-privatelink.md)** allows you to establish a private connection between your VPC and MemoryDB API endpoints. + **[Identity and access management in MemoryDB](iam.md)** for granting and limiting actions of users, groups, and roles. # MemoryDB and Amazon VPC The Amazon Virtual Private Cloud (Amazon VPC) service defines a virtual network that closely resembles a traditional data center. When you configure a virtual private cloud (VPC) with Amazon VPC, you can select its IP address range, create subnets, and configure route tables, network gateways, and security settings. You can also add a cluster to the virtual network, and control access to the cluster by using Amazon VPC security groups. This section explains how to manually configure a MemoryDB cluster in a VPC. This information is intended for users who want a deeper understanding of how MemoryDB and Amazon VPC work together. **Topics** + [Understanding MemoryDB and VPCs](vpcs.mdb.md) + [Access Patterns for Accessing a MemoryDB Cluster in an Amazon VPC](memorydb-vpc-accessing.md) + [Creating a Virtual Private Cloud (VPC)](VPCs.creatingVPC.md) # Understanding MemoryDB and VPCs MemoryDB is fully integrated with Amazon VPC. For MemoryDB users, this means the following: + MemoryDB always launches your cluster in a VPC. + If you're new to AWS, a default VPC will be created for you automatically. + If you have a default VPC and don't specify a subnet when you launch a cluster, the cluster launches into your default Amazon VPC. For more information, see [Detecting Your Supported Platforms and Whether You Have a Default VPC](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#detecting-platform). With Amazon VPC, you can create a virtual network in the AWS Cloud that closely resembles a traditional data center. You can configure your VPC, including selecting its IP address range, creating subnets, and configuring route tables, network gateways, and security settings. MemoryDB manages software upgrades, patching, failure detection, and recovery. ## Overview of MemoryDB in a VPC + A VPC is an isolated portion of the AWS Cloud that is assigned its own block of IP addresses. + An internet gateway connects your VPC directly to the internet and provides access to other AWS resources such as Amazon Simple Storage Service (Amazon S3) that are running outside your VPC. + An Amazon VPC subnet is a segment of the IP address range of a VPC where you can isolate AWS resources according to your security and operational needs. + An Amazon VPC security group controls inbound and outbound traffic for your MemoryDB clusters and Amazon EC2 instances. + You can launch a MemoryDB cluster in the subnet. The nodes have private IP addresses from the subnet's range of addresses. + You can also launch Amazon EC2 instances in the subnet. Each Amazon EC2 instance has a private IP address from the subnet's range of addresses. The Amazon EC2 instance can connect to any node in the same subnet. + For an Amazon EC2 instance in your VPC to be reachable from the internet, you need to assign a static, public address called a Elastic IP address to the instance. ## Prerequisites To create a MemoryDB cluster within a VPC, your VPC must meet the following requirements: + Your VPC must allow nondedicated Amazon EC2 instances. You cannot use MemoryDB in a VPC that is configured for dedicated instance tenancy. + A subnet group must be defined for your VPC. MemoryDB uses that subnet group to select a subnet and IP addresses within that subnet to associate with your nodes. + A security group must be defined for your VPC, or you can use the default provided. + CIDR blocks for each subnet must be large enough to provide spare IP addresses for MemoryDB to use during maintenance activities. ## Routing and security You can configure routing in your VPC to control where traffic flows (for example, to the internet gateway or virtual private gateway). With an internet gateway, your VPC has direct access to other AWS resources that are not running in your VPC. If you choose to have only a virtual private gateway with a connection to your organization's local network, you can route your internet-bound traffic over the VPN and use local security policies and firewall to control egress. In that case, you incur additional bandwidth charges when you access AWS resources over the internet. You can use Amazon VPC security groups to help secure the MemoryDB clusters and Amazon EC2 instances in your Amazon VPC. Security groups act like a firewall at the instance level, not the subnet level. **Note** We strongly recommend that you use DNS names to connect to your nodes, as the underlying IP address can change over time. ## Amazon VPC documentation Amazon VPC has its own set of documentation to describe how to create and use your Amazon VPC. The following table shows where to find information in the Amazon VPC guides. | Description | Documentation | | --- | --- | | How to get started using Amazon VPC | [Getting started with Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) | | How to use Amazon VPC through the AWS Management Console | [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/) | | Complete descriptions of all the Amazon VPC commands | [Amazon EC2 Command Line Reference](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/) (the Amazon VPC commands are found in the Amazon EC2 reference) | | Complete descriptions of the Amazon VPC API operations, data types, and errors | [Amazon EC2 API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/) (the Amazon VPC API operations are found in the Amazon EC2 reference) | | Information for the network administrator who needs to configure the gateway at your end of an optional IPsec VPN connection | [What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) | For more detailed information about Amazon Virtual Private Cloud, see [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/). # Access Patterns for Accessing a MemoryDB Cluster in an Amazon VPC MemoryDB supports the following scenarios for accessing a cluster in an Amazon VPC: **Contents** + [Accessing a MemoryDB Cluster when it and the Amazon EC2 Instance are in the Same Amazon VPC](#memorydb-vpc-accessing-same-vpc) + [Accessing a MemoryDB Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs](#memorydb-vpc-accessing-different-vpc) + [In Different Amazon VPCs in the Same Region](#memorydb-vpc-accessing-different-vpc-same-region) + [Using Transit Gateway](#memorydb-vpc-accessing-using-transit-gateway) + [In Different Amazon VPCs in Different Regions](#memorydb-vpc-accessing-different-vpc-different-region) + [Using Transit VPC](#memorydb-vpc-accessing-different-vpc-different-region-using-transit-vpc) + [Accessing a MemoryDB Cluster from an Application Running in a Customer's Data Center](#memorydb-vpc-accessing-data-center) + [Using VPN Connectivity](#memorydb-vpc-accessing-data-center-vpn) + [Using Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect) ## Accessing a MemoryDB Cluster when it and the Amazon EC2 Instance are in the Same Amazon VPC The most common use case is when an application deployed on an EC2 instance needs to connect to a cluster in the same VPC. The simplest way to manage access between EC2 instances and clusters in the same VPC is to do the following: 1. Create a VPC security group for your cluster. This security group can be used to restrict access to the clusters. For example, you can create a custom rule for this security group that allows TCP access using the port you assigned to the cluster when you created it and an IP address you will use to access the cluster. The default port for MemoryDB clusters is `6379`. 1. Create a VPC security group for your EC2 instances (web and application servers). This security group can, if needed, allow access to the EC2 instance from the Internet via the VPC's routing table. For example, you can set rules on this security group to allow TCP access to the EC2 instance over port 22. 1. Create custom rules in the security group for your cluster that allow connections from the security group you created for your EC2 instances. This would allow any member of the security group to access the clusters. **To create a rule in a VPC security group that allows connections from another security group** 1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com/vpc). 1. In the left navigation pane, choose **Security Groups**. 1. Select or create a security group that you will use for your clusters. Under **Inbound Rules**, select **Edit Inbound Rules** and then select **Add Rule**. This security group will allow access to members of another security group. 1. From **Type** choose **Custom TCP Rule**. 1. For **Port Range**, specify the port you used when you created your cluster. The default port for MemoryDB clusters is `6379`. 1. In the **Source** box, start typing the ID of the security group. From the list select the security group you will use for your Amazon EC2 instances. 1. Choose **Save** when you finish. ## Accessing a MemoryDB Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs When your cluster is in a different VPC from the EC2 instance you are using to access it, there are several ways to access the cluster. If the cluster and EC2 instance are in different VPCs but in the same region, you can use VPC peering. If the cluster and the EC2 instance are in different regions, you can create VPN connectivity between regions. **Topics** + [In Different Amazon VPCs in the Same Region](#memorydb-vpc-accessing-different-vpc-same-region) + [In Different Amazon VPCs in Different Regions](#memorydb-vpc-accessing-different-vpc-different-region)   ### Accessing a MemoryDB Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs in the Same Region *Cluster accessed by an Amazon EC2 instance in a different Amazon VPC within the same Region - VPC Peering Connection* A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IP addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own Amazon VPCs, or with an Amazon VPC in another AWS account within a single region. To learn more about Amazon VPC peering, see the [VPC documentation](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html). **To access a cluster in a different Amazon VPC over peering** 1. Make sure that the two VPCs do not have an overlapping IP range or you will not be able to peer them. 1. Peer the two VPCs. For more information, see [Creating and Accepting an Amazon VPC Peering Connection](http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/create-vpc-peering-connection.html). 1. Update your routing table. For more information, see [Updating Your Route Tables for a VPC Peering Connection](http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html) 1. Modify the Security Group of your MemoryDB cluster to allow inbound connection from the Application security group in the peered VPC. For more information, see [Reference Peer VPC Security Groups](http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-security-groups.html). Accessing a cluster over a peering connection will incur additional data transfer costs.   #### Using Transit Gateway A transit gateway enables you to attach VPCs and VPN connections in the same AWS Region and route traffic between them. A transit gateway works across AWS accounts, and you can use AWS Resource Access Manager to share your transit gateway with other accounts. After you share a transit gateway with another AWS account, the account owner can attach their VPCs to your transit gateway. A user from either account can delete the attachment at any time. You can enable multicast on a transit gateway, and then create a transit gateway multicast domain that allows multicast traffic to be sent from your multicast source to multicast group members over VPC attachments that you associate with the domain. You can also create a peering connection attachment between transit gateways in different AWS Regions. This enables you to route traffic between the transit gateways' attachments across different Regions. For more information, see [Transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html). ### Accessing a MemoryDB Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs in Different Regions #### Using Transit VPC An alternative to using VPC peering, another common strategy for connecting multiple, geographically disperse VPCs and remote networks is to create a transit VPC that serves as a global network transit center. A transit VPC simplifies network management and minimizes the number of connections required to connect multiple VPCs and remote networks. This design can save time and effort and also reduce costs, as it is implemented virtually without the traditional expense of establishing a physical presence in a colocation transit hub or deploying physical network gear. *Connecting across different VPCs in different regions* Once the Transit Amazon VPC is established, an application deployed in a “spoke” VPC in one region can connect to a MemoryDB cluster in a “spoke” VPC within another region. **To access a cluster in a different VPC within a different AWS Region** 1. Deploy a Transit VPC Solution. For more information, see, [AWSTransit Gateway](https://aws.amazon.com/transit-gateway/). 1. Update the VPC routing tables in the App and VPCs to route traffic through the VGW (Virtual Private Gateway) and the VPN Appliance. In case of Dynamic Routing with Border Gateway Protocol (BGP) your routes may be automatically propagated. 1. Modify the Security Group of your MemoryDB cluster to allow inbound connection from the Application instances IP range. Note that you will not be able to reference the application server Security Group in this scenario. Accessing a cluster across regions will introduce networking latencies and additional cross-region data transfer costs. ## Accessing a MemoryDB Cluster from an Application Running in a Customer's Data Center Another possible scenario is a Hybrid architecture where clients or applications in the customer’s data center may need to access a MemoryDB Cluster in the VPC. This scenario is also supported providing there is connectivity between the customers’ VPC and the data center either through VPN or Direct Connect. **Topics** + [Using VPN Connectivity](#memorydb-vpc-accessing-data-center-vpn) + [Using Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect)   ### Accessing a MemoryDB Cluster from an Application Running in a Customer's Data Center Using VPN Connectivity *Connecting to MemoryDB from your data center via a VPN* **To access a cluster in a VPC from on-prem application over VPN connection** 1. Establish VPN Connectivity by adding a hardware Virtual Private Gateway to your VPC. For more information, see [Adding a Hardware Virtual Private Gateway to Your VPC](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html). 1. Update the VPC routing table for the subnet where your MemoryDB cluster is deployed to allow traffic from your on-premises application server. In case of Dynamic Routing with BGP your routes may be automatically propagated. 1. Modify the Security Group of your MemoryDB cluster to allow inbound connection from the on-premises application servers. Accessing a cluster over a VPN connection will introduce networking latencies and additional data transfer costs.   ### Accessing a MemoryDB Cluster from an Application Running in a Customer's Data Center Using Direct Connect *Connecting to MemoryDB from your data center via Direct Connect* **To access a MemoryDB cluster from an application running in your network using Direct Connect** 1. Establish Direct Connect connectivity. For more information, see, [Getting Started with AWS Direct Connect](http://docs.aws.amazon.com/directconnect/latest/UserGuide/getting_started.html). 1. Modify the Security Group of your MemoryDB cluster to allow inbound connection from the on-premises application servers. Accessing a cluster over DX connection may introduce networking latencies and additional data transfer charges. # Creating a Virtual Private Cloud (VPC) In this example, you create a virtual private cloud (VPC) based on the Amazon VPC service with a private subnet for each Availability Zone. ## Creating a VPC (Console) **To create a MemoryDB cluster inside an Amazon Virtual Private Cloud** 1. Sign in to the AWS Management Console, and open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the VPC dashboard, choose **Create VPC**. 1. Under **Resources** to create, choose **VPC and more**. 1. Under **Number of Availability Zones (AZs)**, choose the number of Availability Zones you want to launch your subnets in. 1. Under **Number of public subnets**, choose the number of public subnets you want to add to your VPC. 1. Under **Number of private subnets**, choose the number of private subnets you want to add to your VPC. **Tip** Make a note of your subnet identifiers, and which are public and private. You will need this information later when you launch your clusters and add an Amazon EC2 instance to your Amazon VPC. 1. Create an Amazon VPC security group. You will use this group for your cluster and your Amazon EC2 instance. 1. In the left navigation pane of the AWS Management Console, choose **Security Groups**. 1. Choose **Create Security Group**. 1. Enter a name and a description for your security group in the corresponding boxes. For **VPC**, choose the identifier for your VPC. 1. When the settings are as you want them, choose **Yes, Create**. 1. Define a network ingress rule for your security group. This rule will allow you to connect to your Amazon EC2 instance using Secure Shell (SSH). 1. In the left navigation pane, choose **Security Groups**. 1. Find your security group in the list, and then choose it. 1. Under **Security Group**, choose the **Inbound** tab. In the **Create a new rule** box, choose **SSH**, and then choose **Add Rule**. Set the following values for your new inbound rule to allow HTTP access: + Type: HTTP + Source: 0.0.0.0/0 1. Set the following values for your new inbound rule to allow HTTP access: + Type: HTTP + Source: 0.0.0.0/0 Choose **Apply Rule Changes**. Now you are ready to create a [ subnet group](https://docs.aws.amazon.com/memorydb/latest/devguide/subnetgroups.html) and [create a cluster](https://docs.aws.amazon.com/memorydb/latest/devguide/getting-started.createcluster.html) in your VPC. # Subnets and subnet groups A *subnet group* is a collection of subnets (typically private) that you can designate for your clusters running in an Amazon Virtual Private Cloud (VPC) environment. When you create a cluster in an Amazon VPC, you can specify a subnet group or use the default one provided. MemoryDB uses that subnet group to choose a subnet and IP addresses within that subnet to associate with your nodes. This section covers how to create and leverage subnets and subnet groups to manage access to your MemoryDB resources. For more information about subnet group usage in an Amazon VPC environment, see [Step 3: Authorize access to the cluster](getting-started.md#getting-started.authorizeaccess). **Supported MemoryDB AZ IDs** | Region Name/Region | Supported AZ IDs | | --- | --- | | US East (Ohio) Region `us-east-2` | `use2-az1, use2-az2, use2-az3` | | US East (N. Virginia) Region `us-east-1` | `use1-az1, use1-az2, use1-az4, use1-az5, use1-az6` | | US West (N. California) Region `us-west-1` | `usw1-az1, usw1-az2, usw1-az3` | | US West (Oregon) Region `us-west-2` | `usw2-az1, usw2-az2, usw2-az3, usw2-az4` | | Canada (Central) Region `ca-central-1` | `cac1-az1, cac1-az2, cac1-az4` | | Asia Pacific (Hong Kong) Region `ap-east-1` | `ape1-az1, ape1-az2, ape1-az3` | | Asia Pacific (Mumbai) Region `ap-south-1` | `aps1-az1, aps1-az2, aps1-az3` | | Asia Pacific (Tokyo) Region `ap-northeast-1` | `apne1-az1, apne1-az2, apne1-az4` | | Asia Pacific (Seoul) Region `ap-northeast-2` | `apne2-az1, apne2-az2, apne2-az3` | | Asia Pacific (Singapore) Region `ap-southeast-1` | `apse1-az1, apse1-az2, apse1-az3` | | Asia Pacific (Sydney) Region `ap-southeast-2` | apse2-az1, apse2-az2, apse2-az3 | | Europe (Frankfurt) Region `eu-central-1` | `euc1-az1, euc1-az2, euc1-az3` | | Europe (Ireland) Region `eu-west-1` | `euw1-az1, euw1-az2, euw1-az3` | | Europe (London) Region `eu-west-2` | `euw2-az1, euw2-az2, euw2-az3` | | EU (Paris) Region `eu-west-3` | `euw3-az1, euw3-az2, euw3-az3` | | Europe (Stockholm) Region `eu-north-1` | `eun1-az1, eun1-az2, eun1-az3 ` | | Europe (Milan) Region `eu-south-1` | `eus1-az1, eus1-az2, eus1-az3 ` | | South America (São Paulo) Region `sa-east-1` | `sae1-az1, sae1-az2, sae1-az3` | | China (Beijing) Region `cn-north-1` | `cnn1-az1, cnn1-az2` | | China (Ningxia) Region `cn-northwest-1` | `cnw1-az1, cnw1-az2, cnw1-az3` | | `us-gov-east-1` | `usge1-az1, usge1-az2, usge1-az3` | | `us-gov-west-1` | `usgw1-az1, usgw1-az2, usgw1-az3` | | Europe (Spain) Region `eu-south-2` | `eus2-az1, eus2-az2, eus2-az3` | **Topics** + [MemoryDB and IPV6](subnetgroups.ipv6.md) + [Creating a subnet group](subnetgroups.creating.md) + [Updating a subnet group](subnetgroups.modifying.md) + [Viewing subnet group details](subnetgroups.Viewing.md) + [Deleting a subnet group](subnetgroups.deleting.md) # MemoryDB and IPV6 You can create new dual stack and ipv6-only clusters with both Valkey and Redis OSS engines, by providing subnet groups with dual stack and ipv6-only subnets. You cannot change the network type for an existing cluster. With this functionality you can: + Create ipv4-only and dual stack clusters on dual stack subnets. + Create ipv6-only clusters on ipv6-only subnets. + Create new subnet groups to support ipv4-only, dual stack, and ipv6-only subnets. + Modify existing subnet groups to include additional subnets from the underlying VPC. + Modify existing subnets in subnet groups + Add IPv6 only subnets to subnet groups configured for IPv6 + Add IPv4 or dual stack subnets to subnet groups configured for IPv4 and dual stack support + Discover all the nodes in the cluster with ipv4 OR ipv6 addresses, through engine discovery commands for dual stack and ipv6 clusters. These discovery commands include `redis_info`, `redis_cluster`, and similar. + Discover the ipv4 and ipv6 addresses of all the nodes in the cluster, through DNS discovery commands for dual stack and ipv6 clusters. # Creating a subnet group When you create a new subnet group, note the number of available IP addresses. If the subnet has very few free IP addresses, you might be constrained as to how many more nodes you can add to the cluster. To resolve this issue, you can assign one or more subnets to a subnet group so that you have a sufficient number of IP addresses in your cluster's Availability Zone. After that, you can add more nodes to your cluster. The following procedures show you how to create a subnet group called `mysubnetgroup` (console), the AWS CLI, and the MemoryDB API. ## Creating a subnet group (Console) The following procedure shows how to create a subnet group (console). **To create a subnet group (Console)** 1. Sign in to the AWS Management Console, and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. In the left navigation pane, choose **Subnet Groups**. 1. Choose **Create Subnet Group**. 1. In the **Create Subnet Group** page, do the following: 1. In the **Name** box, type a name for your subnet group. Cluster naming constraints are as follows: + Must contain 1–40 alphanumeric characters or hyphens. + Must begin with a letter. + Can't contain two consecutive hyphens. + Can't end with a hyphen. 1. In the **Description** box, type a description for your subnet group. 1. In the **VPC ID** box, choose the Amazon VPC that you created. If you have not created one, choose the **Create VPC** button and follow the steps to create one. 1. In **Selected subnets**, choose the Availability Zone and ID of your private subnet, and then choose **Choose**. 1. For **Tags**, you can optionally apply tags to search and filter your subnets or track your AWS costs. 1. When all the settings are as you want them, choose **Create**. 1. In the confirmation message that appears, choose **Close**. Your new subnet group appears in the **Subnet Groups** list of the MemoryDB console. At the bottom of the window you can choose the subnet group to see details, such as all of the subnets associated with this group. ## Creating a subnet group (AWS CLI) At a command prompt, use the command `create-subnet-group` to create a subnet group. For Linux, macOS, or Unix: ``` aws memorydb create-subnet-group \ --subnet-group-name mysubnetgroup \ --description "Testing" \ --subnet-ids subnet-53df9c3a ``` For Windows: ``` aws memorydb create-subnet-group ^ --subnet-group-name mysubnetgroup ^ --description "Testing" ^ --subnet-ids subnet-53df9c3a ``` This command should produce output similar to the following: ``` { "SubnetGroup": { "Subnets": [ { "Identifier": "subnet-53df9c3a", "AvailabilityZone": { "Name": "us-east-1a" } } ], "VpcId": "vpc-3cfaef47", "Name": "mysubnetgroup", "ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup", "Description": "Testing" } } ``` For more information, see the AWS CLI topic [create-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-subnet-group.html). ## Creating a subnet group (MemoryDB API) Using the MemoryDB API, call `CreateSubnetGroup` with the following parameters: + `SubnetGroupName=``mysubnetgroup` + `Description=``Testing` + `SubnetIds.member.1=``subnet-53df9c3a` # Updating a subnet group You can update a subnet group's description, or modify the list of subnet IDs associated with the subnet group. You cannot delete a subnet ID from a subnet group if a cluster is currently using that subnet. The following procedures show you how to update a subnet group. ## Updating subnet groups (Console) **To update a subnet group** 1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. In the left navigation pane, choose **Subnet Groups**. 1. In the list of subnet groups, choose the one you want to modify. 1. **Name**, **VPCId** and **Description** fields are not modifiable. 1. In the **Selected subnets** section click **Manage** to make any changes to the Availability Zones you need for the subnets. To save your changes, choose **Save**. ## Updating subnet groups (AWS CLI) At a command prompt, use the command `update-subnet-group` to update a subnet group. For Linux, macOS, or Unix: ``` aws memorydb update-subnet-group \ --subnet-group-name mysubnetgroup \ --description "New description" \ --subnet-ids "subnet-42df9c3a" "subnet-48fc21a9" ``` For Windows: ``` aws memorydb update-subnet-group ^ --subnet-group-name mysubnetgroup ^ --description "New description" ^ --subnet-ids "subnet-42df9c3a" "subnet-48fc21a9" ``` This command should produce output similar to the following: ``` { "SubnetGroup": { "VpcId": "vpc-73cd3c17", "Description": "New description", "Subnets": [ { "Identifier": "subnet-42dcf93a", "AvailabilityZone": { "Name": "us-east-1a" } }, { "Identifier": "subnet-48fc12a9", "AvailabilityZone": { "Name": "us-east-1a" } } ], "Name": "mysubnetgroup", "ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup", } } ``` For more information, see the AWS CLI topic [update-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html). ## Updating subnet groups (MemoryDB API) Using the MemoryDB API, call `UpdateSubnetGroup` with the following parameters: + `SubnetGroupName=``mysubnetgroup` + Any other parameters whose values you want to change. This example uses `Description=``New%20description` to change the description of the subnet group. **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateSubnetGroup &Description=New%20description &SubnetGroupName=mysubnetgroup &SubnetIds.member.1=subnet-42df9c3a &SubnetIds.member.2=subnet-48fc21a9 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20141201T220302Z &Version=2014-12-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20141201T220302Z &X-Amz-Expires=20141201T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` **Note** When you create a new subnet group, take note the number of available IP addresses. If the subnet has very few free IP addresses, you might be constrained as to how many more nodes you can add to the cluster. To resolve this issue, you can assign one or more subnets to a subnet group so that you have a sufficient number of IP addresses in your cluster's Availability Zone. After that, you can add more nodes to your cluster. # Viewing subnet group details The following procedures show you how to view details a subnet group. ## Viewing details of subnet groups (console) **To view details of a subnet group (Console)** 1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. In the left navigation pane, choose **Subnet Groups**. 1. On the **Subnet groups** page, choose the subnet group under **Name** or enter the subnet group's name in the search bar. 1. On the **Subnet groups** page, choose the subnet group under **Name** or enter the subnet group's name in the search bar. 1. Under **Subnet group settings** you can view the name,description, VPC ID and Amazon Resource Name (ARN) of the subnet group. 1. Under **Subnets** you can view the Availability Zones, Subnet IDs and CIDR blocks of the subnet group 1. Under **Tags** you can view any tags associated with the subnet group. ## Viewing subnet groups details (AWS CLI) At a command prompt, use the command `describe-subnet-groups` to view a specified subnet group's details. For Linux, macOS, or Unix: ``` aws memorydb describe-subnet-groups \ --subnet-group-name mysubnetgroup ``` For Windows: ``` aws memorydb describe-subnet-groups ^ --subnet-group-name mysubnetgroup ``` This command should produce output similar to the following: ``` {   "subnetgroups": [     {       "Subnets": [         {           "Identifier": "subnet-060cae3464095de6e",            "AvailabilityZone": {             "Name": "us-east-1a"           }         },          {           "Identifier": "subnet-049d11d4aa78700c3",            "AvailabilityZone": {             "Name": "us-east-1c"           }         },          {           "Identifier": "subnet-0389d4c4157c1edb4",            "AvailabilityZone": {             "Name": "us-east-1d"           }         }       ],        "VpcId": "vpc-036a8150d4300bcf2",        "Name": "mysubnetgroup",        "ARN": "arn:aws:memorydb:us-east-1:53791xzzz7620:subnetgroup/mysubnetgroup",        "Description": "test"     }   ] } ``` To view details on all subnet groups, use the same command but without specifying a subnet group name. ``` aws memorydb describe-subnet-groups ``` For more information, see the AWS CLI topic [describe-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html). ## Viewing subnet groups (MemoryDB API) Using the MemoryDB API, call `DescribeSubnetGroups` with the following parameters: `SubnetGroupName=``mysubnetgroup` **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateSubnetGroup &Description=New%20description &SubnetGroupName=mysubnetgroup &SubnetIds.member.1=subnet-42df9c3a &SubnetIds.member.2=subnet-48fc21a9 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20211801T220302Z &Version=2021-01-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20210801T220302Z &X-Amz-Expires=20210801T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` # Deleting a subnet group If you decide that you no longer need your subnet group, you can delete it. You cannot delete a subnet group if it is currently in use by a cluster. You also cannot delete a subnet group on a cluster with Multi-AZ enabled if doing so leaves that cluster with fewer than two subnets. You must first uncheck **Multi-AZ** and then delete the subnet. The following procedures show you how to delete a subnet group. ## Deleting a subnet group (Console) **To delete a subnet group** 1. Sign in to the AWS Management Console and open the MemoryDB console at [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. In the left navigation pane, choose **Subnet Groups**. 1. In the list of subnet groups, choose the one you want to delete, choose **Actions** and then choose **Delete**. **Note** You cannot delete a default subnet group or one that is associated with any clusters. 1. The **Delete Subnet Groups** confirmation screen will appear. 1. To delete the subnet group, enter `delete` in the confirmation text box. To keep the subnet group, choose **Cancel**. ## Deleting a subnet group (AWS CLI) Using the AWS CLI, call the command **delete-subnet-group** with the following parameter: + `--subnet-group-name` *mysubnetgroup* For Linux, macOS, or Unix: ``` aws memorydb delete-subnet-group \ --subnet-group-name mysubnetgroup ``` For Windows: ``` aws memorydb delete-subnet-group ^ --subnet-group-name mysubnetgroup ``` For more information, see the AWS CLI topic [delete-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-subnet-group.html). ## Deleting a subnet group (MemoryDB API) Using the MemoryDB API, call `DeleteSubnetGroup` with the following parameter: + `SubnetGroupName=mysubnetgroup` **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=DeleteSubnetGroup &SubnetGroupName=mysubnetgroup &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20210801T220302Z &Version=2021-01-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20210801T220302Z &X-Amz-Expires=20210801T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` This command produces no output. For more information, see the MemoryDB API topic [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html). # MemoryDB API and interface VPC endpoints (AWS PrivateLink) You can establish a private connection between your VPC and Amazon MemoryDB API endpoints by creating an *interface VPC endpoint*. Interface endpoints are powered by [AWS PrivateLink](https://aws.amazon.com/privatelink). AWS PrivateLink allows you to privately access MemoryDB API operations without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Instances in your VPC don't need public IP addresses to communicate with MemoryDB API endpoints. Your instances also don't need public IP addresses to use any of the available MemoryDB API operations. Traffic between your VPC and MemoryDB doesn't leave the Amazon network. Each interface endpoint is represented by one or more elastic network interfaces in your subnets. For more information on elastic network interfaces, see [Elastic network interfaces](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) in the *Amazon EC2 User Guide*. + For more information about VPC endpoints, see [Interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) in the *Amazon VPC User Guide*. + For more information about MemoryDB API operations, see [MemoryDB API operations](https://docs.aws.amazon.com/memorydb/latest/APIReference/Welcome.html). After you create an interface VPC endpoint, if you enable [private DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) hostnames for the endpoint, the default MemoryDB endpoint (https://memorydb.*Region*.amazonaws.com) resolves to your VPC endpoint. If you do not enable private DNS hostnames, Amazon VPC provides a DNS endpoint name that you can use in the following format: ``` VPC_Endpoint_ID.memorydb.Region.vpce.amazonaws.com ``` For more information, see [Interface VPC Endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) in the *Amazon VPC User Guide*. MemoryDB supports making calls to all of its [API Actions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html) inside your VPC. **Note** Private DNS hostnames can be enabled for only one VPC endpoint in the VPC. If you want to create an additional VPC endpoint then private DNS hostname should be disabled for it. ## Considerations for VPC endpoints Before you set up an interface VPC endpoint for MemoryDB API endpoints, ensure that you review [Interface endpoint properties and limitations](https://docs.aws.amazon.com/vpc/latest/privatelink/endpoint-services-overview.html) in the *Amazon VPC User Guide*. All MemoryDB API operations that are relevant to managing MemoryDB resources are available from your VPC using AWS PrivateLink. VPC endpoint policies are supported for MemoryDB API endpoints. By default, full access to MemoryDB API operations is allowed through the endpoint. For more information, see [Controlling access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) in the *Amazon VPC User Guide*. ### Creating an interface VPC endpoint for the MemoryDB API You can create a VPC endpoint for the MemoryDB API using either the Amazon VPC console or the AWS CLI. For more information, see [Creating an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) in the *Amazon VPC User Guide*. After you create an interface VPC endpoint, you can enable private DNS host names for the endpoint. When you do, the default MemoryDB endpoint (https://memorydb.*Region*.amazonaws.com) resolves to your VPC endpoint. For more information, see [Accessing a service through an interface endpoint](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) in the *Amazon VPC User Guide*. ### Creating a VPC endpoint policy for the Amazon MemoryDB API You can attach an endpoint policy to your VPC endpoint that controls access to the MemoryDB API. The policy specifies the following: + The principal that can perform actions. + The actions that can be performed. + The resources on which actions can be performed. For more information, see [Controlling access to services with VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) in the *Amazon VPC User Guide*. **Example VPC endpoint policy for MemoryDB API actions** The following is an example of an endpoint policy for the MemoryDB API. When attached to an endpoint, this policy grants access to the listed MemoryDB API actions for all principals on all resources. ``` { "Statement": [{ "Principal": "*", "Effect": "Allow", "Action": [ "memorydb:CreateCluster", "memorydb:UpdateCluster", "memorydb:CreateSnapshot" ], "Resource": "*" }] } ``` **Example VPC endpoint policy that denies all access from a specified AWS account** The following VPC endpoint policy denies AWS account *123456789012* all access to resources using the endpoint. The policy allows all actions from other accounts. ``` { "Statement": [{ "Action": "*", "Effect": "Allow", "Resource": "*", "Principal": "*" }, { "Action": "*", "Effect": "Deny", "Resource": "*", "Principal": { "AWS": [ "123456789012" ] } } ] } ``` # Common Vulnerabilities and Exposures (CVE): Security vulnerabilities addressed in MemoryDB Common Vulnerabilities and Exposures (CVE) is a list of entries for publicly known cybersecurity vulnerabilities. Each entry is a link that contains an identification number, a description, and at least one public reference. You can find on this page a list of security vulnerabilities that have been addressed in MemoryDB. We recommend that you always upgrade to the latest MemoryDB versions to be protected against known vulnerabilities. MemoryDB exposes the PATCH component. PATCH versions are for backwards-compatible bug fixes, security fixes, and non-functional changes. You can use the following table to verify whether a particular version of MemoryDB includes a fix for a specific security vulnerability. If your MemoryDB cache is pending service update, it may be vulnerable to one of the security vulnerabilities listed below. We recommend that you apply the service update. For more information on the supported MemoryDB engine versions and how to upgrade, see [Engine versions](engine-versions.md). **Note** If a CVE is addressed in an MemoryDB version, it means it is also addressed in the newer versions. An asterisk (\$1) in the following table indicates you must have the latest service update applied for the MemoryDB cluster running the version specified in order to address the security vulnerability. For more information on how to verify you have the latest service update applied for the MemoryDB version your cluster is running on, see [Managing the service updates](managing-updates.md). | MemoryDB version | CVEs Addressed | | --- | --- | | Valkey 7.3 and all previous versions of Valkey Redis OSS 7.1 and all previous versions of Redis OSS | [CVE-2025-49844](https://www.cve.org/CVERecord?id=CVE-2025-49844)\$1, [CVE-2025-46817](https://www.cve.org/CVERecord?id=CVE-2025-46817)\$1, [CVE-2025-46818](https://www.cve.org/CVERecord?id=CVE-2025-46818)\$1, [CVE-2025-46819](https://www.cve.org/CVERecord?id=CVE-2025-46819)\$1 | | Valkey 7.2 and 7.3 | [CVE-2025-21607](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21607)\$1, [CVE-2025-21605](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605)\$1, [CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449)\$1, [CVE-2024-31227](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227)\$1, [CVE-2024-31228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31228)\$1 | | Valkey 7.2.7 | [CVE-2024-51741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-51741) | | Redis OSS 7.1 and 6.2 | [CVE-2025-21605](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605)\$1, [CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449)\$1, [CVE-2024-31227](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227)\$1, [CVE-2024-31228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31228)\$1, [CVE-2023-41056](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056) | | Redis OSS 7.0.7 | [CVE-2023-41056](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056)\$1 | | Redis OSS 6.2.7 | [CVE-2024-46981](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-46981) | | Redis OSS 6.2.6 | [CVE-2022-24834](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24834)\$1, [CVE-2022-35977](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35977)\$1, [CVE-2022-36021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36021)\$1, [CVE-2023-22458](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22458), [CVE-2023-25155](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25155), [CVE-2023-28856](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28856) [CVE-2023-45145](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45145): Note that this CVE has been addressed in Redis OSS 6.2 and 7.0 but not in Redis OSS 7.1. | | Redis OSS 6.0.5 | [CVE-2022-24735](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24735)\$1, [CVE-2022-24736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24736)\$1 |