# Security in MemoryDB
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security of the cloud and security in the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to MemoryDB, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations
This documentation helps you understand how to apply the shared responsibility model when using MemoryDB. It shows you how to configure MemoryDB to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your MemoryDB resources.
**Topics**
+ [Data protection](data-protection.md)
+ [Identity and access management](iam.md)
+ [Logging and monitoring](monitoring-overview.md)
+ [Compliance validation](memorydb-compliance.md)
+ [Infrastructure security](infrastructure-security.md)
+ [Internetwork traffic privacy](Security.traffic.md)
+ [Service updates](service-updates.md)
# Data protection in MemoryDB
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in . As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
# Data security in MemoryDB
To help keep your data secure, MemoryDB and Amazon EC2 provide mechanisms to guard against unauthorized access of your data on the server.
MemoryDB also provides encryption features for data on clusters:
+ In-transit encryption encrypts your data whenever it is moving from one place to another, such as between nodes in your cluster or between your cluster and your application.
+ At-rest encryption encrypts the transaction log and your on-disk data during snapshot operations.
You can also use [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md) to control user access to your clusters.
**Topics**
+ [Data security in MemoryDB](encryption.md)
+ [At-Rest Encryption in MemoryDB](at-rest-encryption.md)
+ [In-transit encryption (TLS) in MemoryDB](in-transit-encryption.md)
+ [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md)
+ [Authenticating with IAM](auth-iam.md)
# At-Rest Encryption in MemoryDB
To help keep your data secure, MemoryDB and Amazon S3 provide different ways to restrict access to data in your clusters. For more information, see [MemoryDB and Amazon VPC](vpcs.md) and [Identity and access management in MemoryDB](iam.md).
MemoryDB at-rest encryption is always enabled to increase data security by encrypting persistent data. It encrypts the following aspects:
+ Data in the transaction log
+ Disk during sync, snapshot and swap operations
+ Snapshots stored in Amazon S3
MemoryDB offers default (service managed) encryption at rest, as well as ability to use your own symmetric customer managed customer root keys in [AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
Data stored on SSDs (solid-state drives) in data-tiering enabled clusters is always encrypted by default.
For information on encryption in transit, see [In-transit encryption (TLS) in MemoryDB](in-transit-encryption.md)
**Topics**
+ [Using Customer Managed Keys from AWS KMS](#using-customer-managed-keys-for-memorydb-security)
+ [See Also](#at-rest-encryption-see-also)
## Using Customer Managed Keys from AWS KMS
MemoryDB supports symmetric customer managed root keys (KMS key) for encryption at rest. Customer-managed KMS keys are encryption keys that you create, own and manage in your AWS account. For more information, see [Customer Root Keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) in the *AWS Key Management Service Developer Guide*. The keys must be created in AWS KMS before they can be used with MemoryDB.
To learn how to create AWS KMS root keys, see [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*.
MemoryDB allows you to integrate with AWS KMS. For more information, see [Using Grants](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the *AWS Key Management Service Developer Guide*. No customer action is needed to enable MemoryDB integration with AWS KMS.
The `kms:ViaService` condition key limits use of an AWS KMS key to requests from specified AWS services. To use `kms:ViaService` with MemoryDB, include both ViaService names in the condition key value: `memorydb.amazon_region.amazonaws.com`. For more information, see [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
You can use [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) to track the requests that MemoryDB sends to AWS Key Management Service on your behalf. All API calls to AWS Key Management Service related to customer managed keys have corresponding CloudTrail logs. You can also see the grants that MemoryDB creates by calling the [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html) KMS API call.
Once a cluster is encrypted using a customer managed key, all snapshots for the cluster are encrypted as follows:
+ Automatic daily snapshots are encrypted using the customer managed key associated with the cluster.
+ Final snapshot created when cluster is deleted, is also encrypted using the customer managed key associated with the cluster.
+ Manually created snapshots are encrypted by default to use the KMS key associated with the cluster. You may override this by choosing another customer managed key.
+ Copying a snapshot defaults to using customer managed key associated with the source snapshot. You may override this by choosing another customer managed key.
**Note**
Customer managed keys cannot be used when exporting snapshots to your selected Amazon S3 bucket. However, all snapshots exported to Amazon S3 are encrypted using [Server side encryption.](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) You may choose to copy the snapshot file to a new S3 object and encrypt using a customer managed KMS key, copy the file to another S3 bucket that is set up with default encryption using a KMS key or change an encryption option in the file itself.
You can also use customer managed keys to encrypt manually-created snapshots that do not use customer managed keys for encryption. With this option, the snapshot file stored in Amazon S3 is encrypted using a KMS key, even though the data is not encrypted on the original cluster.
Restoring from a snapshot allows you to choose from available encryption options, similar to encryption choices available when creating a new cluster.
+ If you delete the key or [disable](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) the key and [revoke grants](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) for the key that you used to encrypt a cluster, the cluster becomes irrecoverable. In other words, it cannot be modified or recovered after a hardware failure. AWS KMS deletes root keys only after a waiting period of at least seven days. After the key is deleted, you can use a different customer managed key to create a snapshot for archival purposes.
+ Automatic key rotation preserves the properties of your AWS KMS root keys, so the rotation has no effect on your ability to access your MemoryDB data. Encrypted MemoryDB clusters don't support manual key rotation, which involves creating a new root key and updating any references to the old key. To learn more, see [Rotating Customer root Keys](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) in the *AWS Key Management Service Developer Guide*.
+ Encrypting a MemoryDB cluster using KMS key requires one grant per cluster. This grant is used throughout the lifespan of the cluster. Additionally, one grant per snapshot is used during snapshot creation. This grant is retired once the snapshot is created.
+ For more information on AWS KMS grants and limits, see [Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) in the *AWS Key Management Service Developer Guide*.
## See Also
+ [In-transit encryption (TLS) in MemoryDB](in-transit-encryption.md)
+ [MemoryDB and Amazon VPC](vpcs.md)
+ [Identity and access management in MemoryDB](iam.md)
# In-transit encryption (TLS) in MemoryDB
To help keep your data secure, MemoryDB and Amazon EC2 provide mechanisms to guard against unauthorized access of your data on the server. By providing in-transit encryption capability, MemoryDB gives you a tool you can use to help protect your data when it is moving from one location to another. For example, you might move data from a primary node to a read replica node within a cluster, or between your cluster and your application.
**Topics**
+ [In-transit encryption overview](#in-transit-encryption-overview)
+ [See also](#in-transit-encryption-see-also)
## In-transit encryption overview
MemoryDB in-transit encryption is a feature that increases the security of your data at its most vulnerable points—when it is in transit from one location to another.
MemoryDB in-transit encryption implements the following features:
+ **Encrypted connections**—both the server and client connections are Transport Layer Security (TLS) encrypted.
+ **Encrypted replication—**data moving between a primary node and replica nodes is encrypted.
+ **Server authentication**—clients can authenticate that they are connecting to the right server.
From 07/20/2023, TLS 1.2 is the minimum supported version for new and existing clusters. Use this [link](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) to learn more about TLS 1.2 at AWS.
For more information on connecting to MemoryDB clusters, see [Connecting to MemoryDB nodes using redis-cli](getting-started.md#connect-tls).
## See also
+ [At-Rest Encryption in MemoryDB](at-rest-encryption.md)
+ [Authenticating Users with Access Control Lists (ACLs)](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB and Amazon VPC](vpcs.md)
+ [Identity and access management in MemoryDB](iam.md)
# Authenticating users with Access Control Lists (ACLs)
You can authenticate users with Access control lists (ACLs).
ACLs enable you to control cluster access by grouping users. These Access control lists are designed as a way to organize access to clusters.
With ACLs, you create users and assign them specific permissions by using an access string, as described in the next section. You assign the users to Access control lists aligned with a specific role (administrators, human resources) that are then deployed to one or more MemoryDB clusters. By doing this, you can establish security boundaries between clients using the same MemoryDB cluster or clusters and prevent clients from accessing each other’s data.
ACLs are designed to support the introduction of [ACL](https://valkey.io/docs/topics/acl/) in Redis OSS 6. When you use ACLs with your MemoryDB cluster, there are some limitations:
+ You can't specify passwords in an access string. You set passwords with [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) or [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) calls.
+ For user rights, you pass `on` and `off` as a part of the access string. If neither is specified in the access string, the user is assigned `off` and doesn't have access rights to the cluster.
+ You can't use forbidden commands. If you specify a forbidden command, an exception will be thrown. For a list of those commands, see [Restricted commands](restrictedcommands.md).
+ You can't use the `reset` command as a part of an access string. You specify passwords with API parameters, and MemoryDB manages passwords. Thus, you can't use `reset` because it would remove all passwords for a user.
+ Redis OSS 6 introduces the [ACL LIST](https://valkey.io/commands/acl-list) command. This command returns a list of users along with the ACL rules applied to each user. MemoryDB supports the `ACL LIST` command, but does not include support for password hashes as Redis OSS does. With MemoryDB, you can use the [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) operation to get similar information, including the rules contained within the access string. However, [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) doesn't retrieve a user password.
Other read-only commands supported by MemoryDB include [ACL WHOAMI](https://valkey.io/commands/acl-whoami), [ACL USERS](https://valkey.io/commands/acl-users), and [ACL CAT](https://valkey.io/commands/acl-cat). MemoryDB doesn't support any other write-based ACL commands.
Using ACLs with MemoryDB is described in more detail following.
**Topics**
+ [Specifying Permissions Using an Access String](#access-string)
+ [Vector search capabilities](#access-vss)
+ [Applying ACLs to a cluster for MemoryDB](#rbac-using)
## Specifying Permissions Using an Access String
To specify permissions to a MemoryDB cluster, you create an access string and assign it to a user, using either the AWS CLI or AWS Management Console.
Access strings are defined as a list of space-delimited rules which are applied on the user. They define which commands a user can execute and which keys a user can operate on. In order to execute a command, a user must have access to the command being executed and all keys being accessed by the command. Rules are applied from left to right cumulatively, and a simpler string may be used instead of the one provided if there is redundancies in the string provided.
For information about the syntax of the ACL rules, see [ACL](https://valkey.io/topics/acl).
In the following example, the access string represents an active user with access to all available keys and commands.
`on ~* &* +@all`
The access string syntax is broken down as follows:
+ `on` – The user is an active user.
+ `~*` – Access is given to all available keys.
+ `&*` – Access is given to all pubsub channels.
+ `+@all` – Access is given to all available commands.
The preceding settings are the least restrictive. You can modify these settings to make them more secure.
In the following example, the access string represents a user with access restricted to read access on keys that start with “app::” keyspace
`on ~app::* -@all +@read`
You can refine these permissions further by listing commands the user has access to:
`+command1` – The user's access to commands is limited to *`command1`*.
`+@category` – The user's access is limited to a category of commands.
For information on assigning an access string to a user, see [Creating Users and Access Control Lists with the Console and CLI](#users-management).
If you are migrating an existing workload to MemoryDB, you can retrieve the access string by calling `ACL LIST`, excluding the user and any password hashes.
## Vector search capabilities
For [Vector search](vector-search.md), all search commands belong to the `@search` category and existing categories `@read`, `@write`, `@fast` and `@slow` are updated to include search commands. If a user does not have access to a category, then the user does not have access to any commands within the category. For example, if the user does not have access to `@search`, then the user cannot execute any search related command.
The following table indicates the mapping of search commands to the appropriate categories.
| VSS Commands | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | Y | Y | |
| FT.DROPINDEX | | Y | Y | |
| FT.LIST | Y | | | Y |
| FT.INFO | Y | | Y | |
| FT.SEARCH | Y | | | Y |
| FT.AGGREGATE | Y | | | Y |
| FT.PROFILE | Y | | | Y |
| FT.ALIASADD | | Y | Y | |
| FT.ALIASDEL | | Y | Y | |
| FT.ALIASUPDATE | | Y | Y | |
| FT.\$1ALIASLIST | Y | | | Y |
| FT.EXPLAIN | Y | | Y | |
| FT.EXPLAINCLI | Y | | Y | |
| FT.CONFIG | Y | | Y | |
## Applying ACLs to a cluster for MemoryDB
To use MemoryDB ACLs, you take the following steps:
1. Create one or more users.
1. Create an ACL and add users to the list.
1. Assign the ACL to a cluster.
These steps are described in detail following.
**Topics**
+ [Creating Users and Access Control Lists with the Console and CLI](#users-management)
+ [Managing Access Control Lists with the Console and CLI](#user-groups)
+ [Assigning Access control lists to clusters](#users-groups-to-clusterss)
### Creating Users and Access Control Lists with the Console and CLI
The user information for ACLs users is a user name, and optionally a password and an access string. The access string provides the permission level on keys and commands. The name is unique to the user and is what is passed to the engine.
Make sure that the user permissions you provide make sense with the intended purpose of the ACL. For example, if you create an ACL called `Administrators`, any user you add to that group should have its access string set to full access to keys and commands. For users in an `e-commerce` ACL, you might set their access strings to read-only access.
MemoryDB automatically configures a default user per account with a user name `"default"`. It will not be associated with any cluster unless explicity added to an ACL. You can't modify or delete this user. This user is intended for compatibility with the default behavior of previous Redis OSS versions and has an access string that permits it to call all commands and access all keys.
An immutable “open-access” ACL will be created for every account which contains the default user. This is the only ACL the default user can be a member of. When you create a cluster, you must select an ACL to associate with the cluster. While you do have the option to apply the "open-access" ACL with the default user, we highly recommend creating an ACL with users that have permissions restricted to their business needs.
Clusters that do not have TLS enabled must use the "open-access" ACL to provide open authentication.
ACLs can be created with no users. An empty ACL would have no access to a cluster and can only be associated with TLS-enabled clusters.
When creating a user, you can set up to two passwords. When you modify a password, any existing connections to clusters are maintained.
In particular, be aware of these user password constraints when using ACLs for MemoryDB:
+ Passwords must be 16–128 printable characters.
+ The following nonalphanumeric characters are not allowed: `,` `""` `/` `@`.
#### Managing Users with the Console and CLI
##### Creating a user (Console)
**To create users on the 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. On the left navigation pane, choose **Users**.
1. Choose **Create user**
1. On the **Create user** page, enter a **Name**.
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. Under **Passwords**, you can enter up to two passwords.
1. Under **Access string**, enter an access string. The access string sets the permission level for what keys and commands the user is allowed.
1. For **Tags**, you can optionally apply tags to search and filter your users or track your AWS costs.
1. Choose **Create**.
##### Creating a user using the AWS CLI
**To create a user by using the CLI**
+ Use the [create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html) command to create a user.
For Linux, macOS, or Unix:
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
For Windows:
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### Modifying a user (Console)
**To modify users on the 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. On the left navigation pane, choose **Users**.
1. Choose the radio button next to the user you want to modify and then choose **Actions**->**Modify**
1. If you want to modify a password, choose the **Modify passwords** radio button. Note that if you have two passwords, you must enter both when modifying one of them.
1. If you are updating the access string, enter the new one.
1. Choose **Modify**.
##### Modifying a user using AWS CLI
**To modify a user by using the CLI**
1. Use the [update-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html) command to modify a user.
1. When a user is modified, the Access control lists associated with the user are updated, along with any clusters associated with the ACL. All existing connections are maintained. The following are examples.
For Linux, macOS, or Unix:
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
For Windows:
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### Viewing user details (Console)
**To view user details on the 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. On the left navigation pane, choose **Users**.
1. Choose the user under **User name** or use the search box to find the user.
1. Under **User settings** you can review the user's access string, password count, status and Amazon Resource Name (ARN).
1. Under **Access control lists (ACL)** you can review the ACL the user belongs to.
1. Under **Tags** you can review any tags associated with the user.
##### Viewing user details using the AWS CLI
Use the [describe-users](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html) command to view details of a user.
```
aws memorydb describe-users \
--user-name my-user-name
```
##### Deleting a user (Console)
**To delete users on the 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. On the left navigation pane, choose **Users**.
1. Choose the radio button next to the user you want to modify and then choose **Actions**->**Delete**
1. To confirm, enter `delete` in the confirmation text box and then choose **Delete**.
1. To cancel, choose **Cancel**.
##### Deleting a user using the AWS CLI
**To delete a user by using the CLI**
+ Use the [delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) command to delete a user.
The account is deleted and removed from any Access control lists to which it belongs. The following is an example.
For Linux, macOS, or Unix:
```
aws memorydb delete-user \
--user-name user-name-2
```
For Windows:
```
aws memorydb delete-user ^
--user-name user-name-2
```
### Managing Access Control Lists with the Console and CLI
You can create Access control lists to organize and control access of users to one or more clusters, as shown following.
Use the following procedure to manage Access control lists using the console.
#### Creating an Access Control List (ACL) (Console)
**To create an Access control list using the 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. On left navigation pane, choose **Access control lists (ACL)**.
1. Choose **Create ACL**.
1. On the **Create access control list (ACL)** page, enter an ACL name.
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. Under **Selected users** do one of the following:
1. Create a new user by choosing **Create user**
1. Add users by choosing **Manage** and then selecting users from the **Manage users** dialog and then selecting **Choose**.
1. For **Tags**, you can optionally apply tags to search and filter your ACLs or track your AWS costs.
1. Choose **Create**.
#### Creating an Access Control List (ACL) using the AWS CLI
Use the following procedures to create an Access control list using the CLI.
**To create a new ACL and add a user by using the CLI**
+ Use the [create-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html) command to create an ACL.
For Linux, macOS, or Unix:
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
For Windows:
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### Modifying an Access Control List (ACL) (console)
**To modify an Access control lists using the 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. On left navigation pane, choose **Access control lists (ACL)**.
1. Choose the ACL you wish to modify and then choose **Modify**
1. On the **Modify** page, under **Selected users** do one of the following:
1. Create a new user by choosing **Create user** to add to the ACL.
1. Add or remove users by choosing **Manage** and then selecting or de-selecting users from the **Manage users** dialog and then selecting **Choose**.
1. On the **Create access control list (ACL)** page, enter an ACL name.
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. Under **Selected users** do one of the following:
1. Create a new user by choosing **Create user**
1. Add users by choosing **Manage** and then selecting users from the **Manage users** dialog and then selecting **Choose**.
1. Choose **Modify** to save your changes or **Cancel** to discard them.
#### Modifying an Access Control List (ACL) using the AWS CLI
**To modify a ACL by adding new users or removing current members by using the CLI**
+ Use the [update-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html) command to modfy an ACL.
For Linux, macOS, or Unix:
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
For Windows:
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**Note**
Any open connections belonging to a user removed from an ACL are ended by this command.
#### Viewing Access Control List (ACL) details (Console)
**To view ACL details on the 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. On the left navigation pane, choose **Access control lists (ACL)**.
1. Choose the ACL under **ACL name** or use the search box to find the ACL.
1. Under **Users** you can review list of users associated with the ACL.
1. Under **Associated clusters** you can review the cluster the ACL belongs to.
1. Under **Tags** you can review any tags associated with the ACL.
#### Viewing Access Control Lists (ACL) using the AWS CLI
Use the [describe-acls](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html) command to view details of an ACL.
```
aws memorydb describe-acls \
--acl-name test-group
```
#### Deleting an Access Control List (ACL) (console)
**To delete Access control lists using the 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. On left navigation pane, choose **Access control lists (ACL)**.
1. Choose the ACL you wish to modify and then choose **Delete**
1. On the **Delete** page, enter `delete` in the confirmation box and choose **Delete** or **Cancel** to avoid deleting the ACL.
The ACL itself, not the users belonging to the group, is deleted.
#### Deleting an Access Control List (ACL) using the AWS CLI
**To delete an ACL by using the CLI**
+ Use the [delete-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html) command to delete an ACL.
For Linux, macOS, or Unix:
```
aws memorydb delete-acl /
--acl-name
```
For Windows:
```
aws memorydb delete-acl ^
--acl-name
```
The preceding examples return the following response.
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### Assigning Access control lists to clusters
After you have created an ACL and added users, the final step in implementing ACLs is assigning the ACL to a cluster.
#### Assigning Access control lists to clusters Using the Console
To add an ACL to a cluster using the AWS Management Console, see [Creating a MemoryDB cluster](getting-started.md#clusters.create).
#### Assigning Access control lists to clusters Using the AWS CLI
The following AWS CLI operation creates a cluster with encryption in transit (TLS) enabled and the **acl-name** parameter with the value `my-acl-name`. Replace the subnet group `subnet-group` with a subnet group that exists.
**Key Parameters**
+ **--engine-version** – Must be 6.2.
+ **--tls-enabled** – Used for authentication and for associating an ACL.
+ **--acl-name** – This value provides Access control lists comprised of users with specified access permissions for the cluster.
For Linux, macOS, or Unix:
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
For Windows:
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
The following AWS CLI operation modifies a cluster with encryption in transit (TLS) enabled and the **acl-name** parameter with the value `new-acl-2`.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# Authenticating with IAM
**Topics**
+ [Overview](#auth-iam-overview)
+ [Limitations](#auth-iam-limits)
+ [Setup](#auth-iam-setup)
+ [Connecting](#auth-iam-Connecting)
## Overview
With IAM Authentication you can authenticate a connection to MemoryDB using AWS IAM identities, when your cluster is configured to use Valkey or Redis OSS version 7 or above. This allows you to strengthen your security model and simplify many administrative security tasks. With IAM Authentication you can configure fine-grained access control for each individual MemoryDB cluster and MemoryDB user and follow least-privilege permissions principles. IAM Authentication for MemoryDB works by providing a short-lived IAM authentication token instead of a long-lived MemoryDB user password in the `AUTH` or `HELLO` command. For more information about the IAM authentication token, refer to the [Signature Version 4 signing process](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) in the the AWS General Reference Guide and the code example below.
You can use IAM identities and their associated policies to further restrict Valkey or Redis OSS access. You can also grant access to users from their federated Identity providers directly to MemoryDB clusters.
To use AWS IAM with MemoryDB, you first need to create a MemoryDB user with authentication mode set to IAM, then you can create or reuse an IAM identity. The IAM identity needs an associated policy to grant the `memorydb:Connect` action to the MemoryDB cluster and MemoryDB user. Once configured, you can create an IAM authentication token using the AWS credentials of the IAM user or role. Finally you need to provide the short-lived IAM authentication token as a password in your Valkey or Redis OSS client when connecting to your MemoryDB cluster node. A client with support for credentials provider can auto-generate the temporary credentials automatically for each new connection. MemoryDB will perform IAM authentication for connection requests of IAM-enabled MemoryDB users and will validate the connection requests with IAM.
## Limitations
When using IAM authentication, the following limitations apply:
+ IAM authentication is available when using Valkey or Redis OSS engine version 7.0 or above.
+ The IAM authentication token is valid for 15 minutes. For long-lived connections, we recommend using a Redis OSS client that supports a credentials provider interface.
+ An IAM authenticated connection to MemoryDB will automatically be disconnected after 12 hours. The connection can be prolonged for 12 hours by sending an `AUTH` or `HELLO` command with a new IAM authentication token.
+ IAM authentication is not supported in `MULTI EXEC` commands.
+ Currently, IAM authentication doesn't support all global condition context keys. For more information about global condition context keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the IAM User Guide.
## Setup
To setup IAM authentication:
1. Create a cluster
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
1. Create an IAM trust policy document, as shown below, for your role that allows your account to assume the new role. Save the policy to a file named *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Create an IAM policy document, as shown below. Save the policy to a file named *policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. Create an IAM role.
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Create the IAM policy.
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. Attach the IAM policy to the role.
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. Create a new IAM-enabled user.
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. Create an ACL and attach the user.
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-01
```
## Connecting
**Connect with token as password**
You first need to generate the short-lived IAM authentication token using an [AWS SigV4 pre-signed request](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). After that you provide the IAM authentication token as a password when connecting to a MemoryDB cluster, as shown in the example below.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request and signed it using the AWS credentials.
// The pre-signed request URL is used as an IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Below is the definition for `IAMAuthTokenRequest`.
```
public class IAMAuthTokenRequest {
private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET;
private static final String REQUEST_PROTOCOL = "http://";
private static final String PARAM_ACTION = "Action";
private static final String PARAM_USER = "User";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException {
Request request = getSignableRequest();
sign(request, credentials);
return new URIBuilder(request.getEndpoint())
.addParameters(toNamedValuePair(request.getParameters()))
.build()
.toString()
.replace(REQUEST_PROTOCOL, "");
}
private Request getSignableRequest() {
Request request = new DefaultRequest<>(SERVICE_NAME);
request.setHttpMethod(REQUEST_METHOD);
request.setEndpoint(getRequestUri());
request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME));
request.addParameters(PARAM_USER, Collections.singletonList(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
private void sign(SignableRequest request, AWSCredentials credentials) {
AWS4Signer signer = new AWS4Signer();
signer.setRegionName(region);
signer.setServiceName(SERVICE_NAME);
DateTime dateTime = DateTime.now();
dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS));
signer.presignRequest(request, credentials, dateTime.toDate());
}
private static List toNamedValuePair(Map> in) {
return in.entrySet().stream()
.map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0)))
.collect(Collectors.toList());
}
}
```
**Connect with credentials provider**
The code below shows how to authenticate with MemoryDB using the IAM authentication credentials provider.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request. Once this request is signed it can be used as an
// IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Below is an example of a Lettuce cluster client that wraps the IAMAuthTokenRequest in a credentials provider to auto-generate temporary credentials when needed.
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
IAMAuthTokenRequest iamAuthTokenRequest,
AWSCredentialsProvider awsCredentialsProvider) {
this.userName = userName;
this.awsCredentialsProvider = awsCredentialsProvider;
this.iamAuthTokenRequest = iamAuthTokenRequest;
this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS);
}
@Override
public Mono resolveCredentials() {
return Mono.just(RedisCredentials.just(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```
# Identity and access management in MemoryDB
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use MemoryDB resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [Audience](#security_iam_audience)
+ [Authenticating with identities](#security_iam_authentication)
+ [Managing access using policies](#security_iam_access-manage)
+ [How MemoryDB works with IAM](security_iam_service-with-iam.md)
+ [Identity-based policy examples for MemoryDB](security_iam_id-based-policy-examples.md)
+ [Troubleshooting MemoryDB identity and access](security_iam_troubleshoot.md)
+ [Access control](#iam.accesscontrol)
+ [Overview of managing access permissions to your MemoryDB resources](iam.overview.md)
## Audience
How you use AWS Identity and Access Management (IAM) differs based on your role:
+ **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshooting MemoryDB identity and access](security_iam_troubleshoot.md))
+ **Service administrator** - determine user access and submit permission requests (see [How MemoryDB works with IAM](security_iam_service-with-iam.md))
+ **IAM administrator** - write policies to manage access (see [Identity-based policy examples for MemoryDB](security_iam_id-based-policy-examples.md))
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.
For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.
### AWS account root user
When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*.
### Federated identity
As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials.
A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials.
For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.
### IAM users and groups
An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.
### IAM roles
An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.
IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
## Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.
By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.
### Resource-based policies
Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy.
Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy.
### Other policy types
AWS supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.
### Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
# How MemoryDB works with IAM
Before you use IAM to manage access to MemoryDB, learn what IAM features are available to use with MemoryDB.
**IAM features you can use with MemoryDB**
| IAM feature | MemoryDB support |
| --- | --- |
| [Identity-based policies](#security_iam_service-with-iam-id-based-policies) | Yes |
| [Resource-based policies](#security_iam_service-with-iam-resource-based-policies) | No |
| [Policy actions](#security_iam_service-with-iam-id-based-policies-actions) | Yes |
| [Policy resources](#security_iam_service-with-iam-id-based-policies-resources) | Yes |
| [Policy condition keys](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Yes |
| [ACLs](#security_iam_service-with-iam-acls) | Yes |
| [ABAC (tags in policies)](#security_iam_service-with-iam-tags) | Yes |
| [Temporary credentials](#security_iam_service-with-iam-roles-tempcreds) | Yes |
| [Principal permissions](#security_iam_service-with-iam-principal-permissions) | Yes |
| [Service roles](#security_iam_service-with-iam-roles-service) | Yes |
| [Service-linked roles](#security_iam_service-with-iam-roles-service-linked) | Yes |
To get a high-level view of how MemoryDB and other AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Identity-based policies for MemoryDB
**Supports identity-based policies:** Yes
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
### Identity-based policy examples for MemoryDB
To view examples of MemoryDB identity-based policies, see [Identity-based policy examples for MemoryDB](security_iam_id-based-policy-examples.md).
## Resource-based policies within MemoryDB
**Supports resource-based policies:** No
Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.
To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
## Policy actions for MemoryDB
**Supports policy actions:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.
To see a list of MemoryDB actions, see [Actions Defined by MemoryDB ](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) in the *Service Authorization Reference*.
Policy actions in MemoryDB use the following prefix before the action:
```
MemoryDB
```
To specify multiple actions in a single statement, separate them with commas.
```
"Action": [
"MemoryDB:action1",
"MemoryDB:action2"
]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "MemoryDB:Describe*"
```
To view examples of MemoryDB identity-based policies, see [Identity-based policy examples for MemoryDB](security_iam_id-based-policy-examples.md).
## Policy resources for MemoryDB
**Supports policy resources:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.
```
"Resource": "*"
```
To see a list of MemoryDB resource types and their ARNs, see [Resources Defined by MemoryDB ](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions Defined by MemoryDB ](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions).
To view examples of MemoryDB identity-based policies, see [Identity-based policy examples for MemoryDB](security_iam_id-based-policy-examples.md).
## Policy condition keys for MemoryDB
**Supports service-specific policy condition keys:** Yes
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
To view examples of MemoryDB identity-based policies, see [Identity-based policy examples for MemoryDB](security_iam_id-based-policy-examples.md).
### Using condition keys
You can specify conditions that determine how an IAM policy takes effect. In MemoryDB, you can use the `Condition` element of a JSON policy to compare keys in the request context with key values that you specify in your policy. For more information, see [IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html).
To see a list of MemoryDB condition keys, see [Condition Keys for MemoryDB ](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys) in the *Service Authorization Reference*.
For a list of global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
#### Specifying Conditions: Using Condition Keys
To implement fine-grained control, you can write an IAM permissions policy that specifies conditions to control a set of individual parameters on certain requests. You can then apply the policy to IAM users, groups, or roles that you create using the IAM console.
To apply a condition, you add the condition information to the IAM policy statement. For example, to disallow the creation of any MemoryDB cluster with TLS disabled, you can specify the following condition in your policy statement.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "false"
}
}
}
]
}
```
------
For more information on tagging, see [Tagging your MemoryDB resources](tagging-resources.md).
For more information on using policy condition operators, see [MemoryDB API permissions: Actions, resources, and conditions reference](iam.APIReference.md).
#### Example Policies: Using Conditions for Fine-Grained Parameter Control
This section shows example policies for implementing fine-grained access control on the previously listed MemoryDB parameters.
1. **memorydb:TLSEnabled** — Specify that clusters will be created only with TLS enabled.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"arn:aws:memorydb:*:*:parametergroup/*",
"arn:aws:memorydb:*:*:subnetgroup/*",
"arn:aws:memorydb:*:*:acl/*"
]
},
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "true"
}
}
}
]
}
```
------
1. **memorydb:UserAuthenticationMode:** — Specify that the users can be created with a specific type authentication mode (IAM for example).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:Createuser"
],
"Resource": [
"arn:aws:memorydb:*:*:user/*"
],
"Condition": {
"StringEquals": {
"memorydb:UserAuthenticationMode": "iam"
}
}
}
]
}
```
------
In cases where you are setting ‘Deny’ based policies, it is recommended to use the [StringEqualsIgnoreCase](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String) operator to avoid all calls with a specific user authentication mode type irrespective of the case.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateUser"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"memorydb:UserAuthenticationMode": "password"
}
}
}
]
}
```
------
## Access control lists (ACLs) in MemoryDB
**Supports ACLs:** Yes
Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.
## Attribute-based access control (ABAC) with MemoryDB
**Supports ABAC (tags in policies):** Yes
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.
To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.
If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.
For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.
## Using Temporary credentials with MemoryDB
**Supports temporary credentials:** Yes
Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
## Cross-service principal permissions for MemoryDB
**Supports forward access sessions (FAS):** Yes
Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Service roles for MemoryDB
**Supports service roles:** Yes
A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
**Warning**
Changing the permissions for a service role might break MemoryDB functionality. Edit service roles only when MemoryDB provides guidance to do so.
## Service-linked roles for MemoryDB
**Supports service-linked roles:** Yes
A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.
For details about creating or managing service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Find a service in the table that includes a `Yes` in the **Service-linked role** column. Choose the **Yes** link to view the service-linked role documentation for that service.
# Identity-based policy examples for MemoryDB
By default, users and roles don't have permission to create or modify MemoryDB resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies.
To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*.
For details about actions and resource types defined by MemoryDB, including the format of the ARNs for each of the resource types, see [Actions, Resources, and Condition Keys for MemoryDB ](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html) in the *Service Authorization Reference*.
**Topics**
+ [Policy best practices](#security_iam_service-with-iam-policy-best-practices)
+ [Using the MemoryDB console](#security_iam_id-based-policy-examples-console)
+ [Allow users to view their own permissions](#security_iam_id-based-policy-examples-view-own-permissions)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete MemoryDB resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
## Using the MemoryDB console
To access the MemoryDB console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the MemoryDB resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.
You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform.
To ensure that users and roles can still use the MemoryDB console, also attach the MemoryDB `ConsoleAccess` or `ReadOnly` AWS managed policy to the entities. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*.
## Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Troubleshooting MemoryDB identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with MemoryDB and IAM.
**Topics**
+ [I am not authorized to perform an action in MemoryDB](#security_iam_troubleshoot-no-permissions)
+ [I am not authorized to perform iam:PassRole](#security_iam_troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my MemoryDB resources](#security_iam_troubleshoot-cross-account-access)
## I am not authorized to perform an action in MemoryDB
If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password.
The following example error occurs when the `mateojackson` user tries to use the console to view details about a fictional `my-example-widget` resource but does not have the fictional `MemoryDB:GetWidget` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: MemoryDB:GetWidget on resource: my-example-widget
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-widget` resource using the `MemoryDB:GetWidget` action.
## I am not authorized to perform iam:PassRole
If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to MemoryDB.
Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in MemoryDB. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I want to allow people outside of my AWS account to access my MemoryDB resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether MemoryDB supports these features, see [How MemoryDB works with IAM](security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
## Access control
You can have valid credentials to authenticate your requests, but unless you have permissions you cannot create or access MemoryDB resources. For example, you must have permissions to create a MemoryDB cluster.
The following sections describe how to manage permissions for MemoryDB. We recommend that you read the overview first.
+ [Overview of managing access permissions to your MemoryDB resources](iam.overview.md)
+ [Using identity-based policies (IAM policies) for MemoryDB](iam.identitybasedpolicies.md)
# Overview of managing access permissions to your MemoryDB resources
Every AWS resource is owned by an AWS account, and permissions to create or access a resource are governed by permissions policies. An account administrator can attach permissions policies to IAM identities (that is, users, groups, and roles). In addition, MemoryDB also supports attaching permissions policies to resources.
**Note**
An *account administrator* (or administrator user) is a user with administrator privileges. For more information, see [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.
To provide access, add permissions to your users, groups, or roles:
+ Users and groups in AWS IAM Identity Center:
Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*.
+ Users managed in IAM through an identity provider:
Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*.
+ IAM users:
+ Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*.
+ (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*.
**Topics**
+ [MemoryDB resources and operations](#iam.overview.resourcesandoperations)
+ [Understanding resource ownership](#access-control-resource-ownership)
+ [Managing access to resources](#iam.overview.managingaccess)
+ [Using identity-based policies (IAM policies) for MemoryDB](iam.identitybasedpolicies.md)
+ [Resource-level permissions](iam.resourcelevelpermissions.md)
+ [Using Service-Linked Roles for MemoryDB](using-service-linked-roles.md)
+ [AWS managed policies for MemoryDB](security-iam-awsmanpol.md)
+ [MemoryDB API permissions: Actions, resources, and conditions reference](iam.APIReference.md)
## MemoryDB resources and operations
In MemoryDB, the primary resource is a *cluster*.
These resources have unique Amazon Resource Names (ARNs) associated with them as shown following.
**Note**
For resource-level permissions to be effective, the resource name on the ARN string should be lower case.
****
| Resource type | ARN format |
| --- | --- |
| User | arn:aws:memorydb:*us-east-1:123456789012*:user/user1 |
| Access Control List (ACL) | arn:aws:memorydb:*us-east-1:123456789012*:acl/myacl |
| Cluster | arn:aws:memorydb:*us-east-1:123456789012*:cluster/my-cluster |
| Snapshot | arn:aws:memorydb:*us-east-1:123456789012*:snapshot/my-snapshot |
| Parameter group | arn:aws:memorydb:*us-east-1:123456789012*:parametergroup/my-parameter-group |
| Subnet group | arn:aws:memorydb:*us-east-1:123456789012*:subnetgroup/my-subnet-group |
MemoryDB provides a set of operations to work with MemoryDB resources. For a list of available operations, see MemoryDB [Actions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html).
## Understanding resource ownership
A *resource owner* is the AWS account that created the resource. That is, the resource owner is the AWS account of the principal entity that authenticates the request that creates the resource. A *principal entity* can be the root account, an IAM user, or an IAM role. The following examples illustrate how this works:
+ Suppose that you use the root account credentials of your AWS account to create a cluster. In this case, your AWS account is the owner of the resource. In MemoryDB, the resource is the cluster.
+ Suppose that you create an IAM user in your AWS account and grant permissions to create a cluster to that user. In this case, the user can create a cluster. However, your AWS account, to which the user belongs, owns the cluster resource.
+ Suppose that you create an IAM role in your AWS account with permissions to create a cluster. In this case, anyone who can assume the role can create a cluster. Your AWS account, to which the role belongs, owns the cluster resource.
## Managing access to resources
A *permissions policy* describes who has access to what. The following section explains the available options for creating permissions policies.
**Note**
This section discusses using IAM in the context of MemoryDB. It doesn't provide detailed information about the IAM service. For complete IAM documentation, see [What Is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide*. For information about IAM policy syntax and descriptions, see [AWS IAM Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.
Policies attached to an IAM identity are referred to as *identity-based* policies (IAM policies). Policies attached to a resource are referred to as *resource-based* policies.
**Topics**
+ [Identity-based policies (IAM policies)](#iam.overview.managingaccess.identitybasedpolicies)
+ [Specifying policy elements: Actions, effects, resources, and principals](#iam.overview.policyelements)
+ [Specifying conditions in a policy](#iam.specifyconditions)
### Identity-based policies (IAM policies)
You can attach policies to IAM identities. For example, you can do the following:
+ **Attach a permissions policy to a user or a group in your account** – An account administrator can use a permissions policy that is associated with a particular user to grant permissions. In this case, the permissions are for that user to create a MemoryDB resource, such as a cluster, parameter group, or security group.
+ **Attach a permissions policy to a role (grant cross-account permissions)** – You can attach an identity-based permissions policy to an IAM role to grant cross-account permissions. For example, the administrator in Account A can create a role to grant cross-account permissions to another AWS account (for example, Account B) or an AWS service as follows:
1. Account A administrator creates an IAM role and attaches a permissions policy to the role that grants permissions on resources in Account A.
1. Account A administrator attaches a trust policy to the role identifying Account B as the principal who can assume the role.
1. Account B administrator can then delegate permissions to assume the role to any users in Account B. Doing this allows users in Account B to create or access resources in Account A. In some cases, you might want to grant an AWS service permissions to assume the role. To support this approach, the principal in the trust policy can also be an AWS service principal.
For more information about using IAM to delegate permissions, see [Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) in the *IAM User Guide*.
The following is an example policy that allows a user to perform the `DescribeClusters` action for your AWS account. MemoryDB also supports identifying specific resources using the resource ARNs for API actions. (This approach is also referred to as resource-level permissions).
For more information about using identity-based policies with MemoryDB, see [Using identity-based policies (IAM policies) for MemoryDB](iam.identitybasedpolicies.md). For more information about users, groups, roles, and permissions, see [Identities (Users, Groups, and Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*.
### Specifying policy elements: Actions, effects, resources, and principals
For each MemoryDB resource (see [MemoryDB resources and operations](#iam.overview.resourcesandoperations)), the service defines a set of API operations (see [Actions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)). To grant permissions for these API operations, MemoryDB defines a set of actions that you can specify in a policy. For example, for the MemoryDB cluster resource, the following actions are defined: `CreateCluster`, `DeleteCluster`, and `DescribeClusters`. Performing an API operation can require permissions for more than one action.
The following are the most basic policy elements:
+ **Resource** – In a policy, you use an Amazon Resource Name (ARN) to identify the resource to which the policy applies. For more information, see [MemoryDB resources and operations](#iam.overview.resourcesandoperations).
+ **Action** – You use action keywords to identify resource operations that you want to allow or deny. For example, depending on the specified `Effect`, the `memorydb:CreateCluster` permission allows or denies the user permissions to perform the MemoryDB `CreateCluster` operation.
+ **Effect** – You specify the effect when the user requests the specific action—this can be either allow or deny. If you don't explicitly grant access to (allow) a resource, access is implicitly denied. You can also explicitly deny access to a resource. For example, you might do this to make sure that a user can't access a resource, even if a different policy grants access.
+ **Principal** – In identity-based policies (IAM policies), the user that the policy is attached to is the implicit principal. For resource-based policies, you specify the user, account, service, or other entity that you want to receive permissions (applies to resource-based policies only).
To learn more about IAM policy syntax and descriptions, see [AWS IAM Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.
For a table showing all of the MemoryDB API actions, see [MemoryDB API permissions: Actions, resources, and conditions reference](iam.APIReference.md).
### Specifying conditions in a policy
When you grant permissions, you can use the IAM policy language to specify the conditions when a policy should take effect. For example, you might want a policy to be applied only after a specific date. For more information about specifying conditions in a policy language, see [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) in the *IAM User Guide*.
# Using identity-based policies (IAM policies) for MemoryDB
This topic provides examples of identity-based policies in which an account administrator can attach permissions policies to IAM identities (that is, users, groups, and roles).
**Important**
We recommend that you first read the topics that explain the basic concepts and options to manage access to MemoryDB resources. For more information, see [Overview of managing access permissions to your MemoryDB resources](iam.overview.md).
The sections in this topic cover the following:
+ [Permissions required to use the MemoryDB console](#iam.identitybasedpolicies.minconpolicies)
+ [AWS-managed (predefined) policies for MemoryDB](security-iam-awsmanpol.md#iam.identitybasedpolicies.predefinedpolicies)
+ [Customer-managed policy examples](#iam.identitybasedpolicies.customermanagedpolicies)
The following shows an example of a permissions policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowClusterPermissions",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:DescribeClusters",
"memorydb:UpdateCluster"],
"Resource": "*"
},
{
"Sid": "AllowUserToPassRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
}
]
}
```
------
The policy has two statements:
+ The first statement grants permissions for the MemoryDB actions (`memorydb:CreateCluster`, `memorydb:DescribeClusters`, and `memorydb:UpdateCluster`) on any cluster owned by the account.
+ The second statement grants permissions for the IAM action (`iam:PassRole`) on the IAM role name specified at the end of the `Resource` value.
The policy doesn't specify the `Principal` element because in an identity-based policy you don't specify the principal who gets the permission. When you attach policy to a user, the user is the implicit principal. When you attach a permissions policy to an IAM role, the principal identified in the role's trust policy gets the permissions.
For a table showing all of the MemoryDB API actions and the resources that they apply to, see [MemoryDB API permissions: Actions, resources, and conditions reference](iam.APIReference.md).
## Permissions required to use the MemoryDB console
The permissions reference table lists the MemoryDB API operations and shows the required permissions for each operation. For more information about MemoryDB API operations, see [MemoryDB API permissions: Actions, resources, and conditions reference](iam.APIReference.md).
To use the MemoryDB console, first grant permissions for additional actions as shown in the following permissions policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "MinPermsForMemDBConsole",
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeVpcs",
"ec2:DescribeAccountAttributes",
"ec2:DescribeSecurityGroups",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"s3:ListAllMyBuckets",
"sns:ListTopics",
"sns:ListSubscriptions" ],
"Resource": "*"
}
]
}
```
------
The MemoryDB console needs these additional permissions for the following reasons:
+ Permissions for the MemoryDB actions enable the console to display MemoryDB resources in the account.
+ The console needs permissions for the `ec2` actions to query Amazon EC2 so it can display Availability Zones, VPCs, security groups, and account attributes.
+ The permissions for `cloudwatch` actions enable the console to retrieve Amazon CloudWatch metrics and alarms, and display them in the console.
+ The permissions for `sns` actions enable the console to retrieve Amazon Simple Notification Service (Amazon SNS) topics and subscriptions, and display them in the console.
## Customer-managed policy examples
If you are not using a default policy and choose to use a custom-managed policy, ensure one of two things. Either you should have permissions to call `iam:createServiceLinkedRole` (for more information, see [Example 4: Allow a user to call IAM CreateServiceLinkedRole API](#create-service-linked-role-policy)). Or you should have created a MemoryDB service-linked role.
When combined with the minimum permissions needed to use the MemoryDB console, the example policies in this section grant additional permissions. The examples are also relevant to the AWS SDKs and the AWS CLI. For more information about what permissions are needed to use the MemoryDB console, see [Permissions required to use the MemoryDB console](#iam.identitybasedpolicies.minconpolicies).
For instructions on setting up IAM users and groups, see [Creating Your First IAM User and Administrators Group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) in the *IAM User Guide*.
**Important**
Always test your IAM policies thoroughly before using them in production. Some MemoryDB actions that appear simple can require other actions to support them when you are using the MemoryDB console. For example, `memorydb:CreateCluster` grants permissions to create MemoryDB clusters. However, to perform this operation, the MemoryDB console uses a number of `Describe` and `List` actions to populate console lists.
**Topics**
+ [Example 1: Allow a user read-only access to MemoryDB resources](#example-allow-list-current-memorydb-resources)
+ [Example 2: Allow a user to perform common MemoryDB system administrator tasks](#example-allow-specific-memorydb-actions)
+ [Example 3: Allow a user to access all MemoryDB API actions](#allow-unrestricted-access)
+ [Example 4: Allow a user to call IAM CreateServiceLinkedRole API](#create-service-linked-role-policy)
### Example 1: Allow a user read-only access to MemoryDB resources
The following policy grants permissions for MemoryDB actions that allow a user to list resources. Typically, you attach this type of permissions policy to a managers group.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MemDBUnrestricted",
"Effect":"Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"],
"Resource":"*"
}
]
}
```
------
### Example 2: Allow a user to perform common MemoryDB system administrator tasks
Common system administrator tasks include modifying clusters, parameters, and parameter groups. A system administrator may also want to get information about the MemoryDB events. The following policy grants a user permissions to perform MemoryDB actions for these common system administrator tasks. Typically, you attach this type of permissions policy to the system administrators group.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MDBAllowSpecific",
"Effect": "Allow",
"Action": [
"memorydb:UpdateCluster",
"memorydb:DescribeClusters",
"memorydb:DescribeEvents",
"memorydb:UpdateParameterGroup",
"memorydb:DescribeParameterGroups",
"memorydb:DescribeParameters",
"memorydb:ResetParameterGroup"
],
"Resource": "*"
}
]
}
```
------
### Example 3: Allow a user to access all MemoryDB API actions
The following policy allows a user to access all MemoryDB actions. We recommend that you grant this type of permissions policy only to an administrator user.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MDBAllowAll",
"Effect":"Allow",
"Action":[
"memorydb:*" ],
"Resource":"*"
}
]
}
```
------
### Example 4: Allow a user to call IAM CreateServiceLinkedRole API
The following policy allows user to call the IAM `CreateServiceLinkedRole` API. We recommend that you grant this type of permissions policy to the user who invokes mutative MemoryDB operations.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CreateSLRAllows",
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:AWSServiceName":"memorydb.amazonaws.com"
}
}
}
]
}
```
------
# Resource-level permissions
You can restrict the scope of permissions by specifying resources in an IAM policy. Many AWS CLI API actions support a resource type that varies depending on the behavior of the action. Every IAM policy statement grants permission to an action that's performed on a resource. When the action doesn't act on a named resource, or when you grant permission to perform the action on all resources, the value of the resource in the policy is a wildcard (\$1). For many API actions, you can restrict the resources that a user can modify by specifying the Amazon Resource Name (ARN) of a resource, or an ARN pattern that matches multiple resources. To restrict permissions by resource, specify the resource by ARN.
**MemoryDB Resource ARN Format**
**Note**
For resource-level permissions to be effective, the resource name in the ARN string should be lowercase.
+ User – arn:aws:memorydb:*us-east-1:123456789012*:user/user1
+ ACL – arn:aws:memorydb:*us-east-1:123456789012*:acl/my-acl
+ Cluster – arn:aws:memorydb:*us-east-1:123456789012*:cluster/my-cluster
+ Snapshot – arn:aws:memorydb:*us-east-1:123456789012*:snapshot/my-snapshot
+ Parameter group – arn:aws:memorydb:*us-east-1:123456789012*:parametergroup/my-parameter-group
+ Subnet group – arn:aws:memorydb:*us-east-1:123456789012*:subnetgroup/my-subnet-group
**Topics**
+ [Example 1: Allow a user full access to specific MemoryDB resource types](#example-allow-list-current-memorydb-resources-resource)
+ [Example 2: Deny a user access to a cluster.](#example-allow-specific-memorydb-actions-resource)
## Example 1: Allow a user full access to specific MemoryDB resource types
The following policy explicitly allows the specified `account-id` full access to all resources of type subnet group, security group and cluster.
```
{
"Sid": "Example1",
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:subnetgroup/*",
"arn:aws:memorydb:us-east-1:account-id:securitygroup/*",
"arn:aws:memorydb:us-east-1:account-id:cluster/*"
]
}
```
## Example 2: Deny a user access to a cluster.
The following example explicitly denies the specified `account-id` access to a particular cluster.
```
{
"Sid": "Example2",
"Effect": "Deny",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:cluster/name"
]
}
```
# Using Service-Linked Roles for MemoryDB
MemoryDB uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to an AWS service, such as MemoryDB. MemoryDB service-linked roles are predefined by MemoryDB. They include all the permissions that the service requires to call AWS services on behalf of your clusters.
A service-linked role makes setting up MemoryDB easier because you don’t have to manually add the necessary permissions. The roles already exist within your AWS account but are linked to MemoryDB use cases and have predefined permissions. Only MemoryDB can assume these roles, and only these roles can use the predefined permissions policy. You can delete the roles only after first deleting their related resources. This protects your MemoryDB resources because you can't inadvertently remove necessary permissions to access the resources.
For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
**Contents**
+ [Service-Linked Role Permissions](#service-linked-role-permissions)
+ [Creating a Service-Linked Role (IAM)](#create-service-linked-role-iam)
+ [Using the IAM Console](#create-service-linked-role-iam-console)
+ [Using the IAM CLI](#create-service-linked-role-iam-cli)
+ [Using the IAM API](#create-service-linked-role-iam-api)
+ [Editing a Service-Linked Role Description](#edit-service-linked-role)
+ [Using the IAM Console](#edit-service-linked-role-iam-console)
+ [Using the IAM CLI](#edit-service-linked-role-iam-cli)
+ [Using the IAM API](#edit-service-linked-role-iam-api)
+ [Deleting a Service-Linked Role for MemoryDB](#delete-service-linked-role)
+ [Cleaning Up a Service-Linked Role](#service-linked-role-review-before-delete)
+ [Deleting a Service-Linked Role (IAM Console)](#delete-service-linked-role-iam-console)
+ [Deleting a Service-Linked Role (IAM CLI)](#delete-service-linked-role-iam-cli)
+ [Deleting a Service-Linked Role (IAM API)](#delete-service-linked-role-iam-api)
## Service-Linked Role Permissions for MemoryDB
MemoryDB uses the service-linked role named **AWSServiceRoleForMemoryDB** – This policy allows MemoryDB to manage AWS resources on your behalf as necessary for managing your clusters.
The AWSServiceRoleForMemoryDB service-linked role permissions policy allows MemoryDB to complete the following actions on the specified resources:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
For more information, see [AWS managed policy: MemoryDBServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-memorydbServiceRolePolicy).
**To allow an IAM entity to create AWSServiceRoleForMemoryDB service-linked roles**
Add the following policy statement to the permissions for that IAM entity:
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWSServiceName": "memorydb.amazonaws.com"}}
}
```
**To allow an IAM entity to delete AWSServiceRoleForMemoryDB service-linked roles**
Add the following policy statement to the permissions for that IAM entity:
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWSServiceName": "memorydb.amazonaws.com"}}
}
```
Alternatively, you can use an AWS managed policy to provide full access to MemoryDB.
## Creating a Service-Linked Role (IAM)
You can create a service-linked role using the IAM console, CLI, or API.
### Creating a Service-Linked Role (IAM Console)
You can use the IAM console to create a service-linked role.
**To create a service-linked role (console)**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane of the IAM console, choose **Roles**. Then choose **Create new role**.
1. Under **Select type of trusted entity** choose **AWS Service**.
1. Under **Or select a service to view its use cases**, choose **MemoryDB**.
1. Choose **Next: Permissions**.
1. Under **Policy name**, note that the `MemoryDBServiceRolePolicy` is required for this role. Choose **Next:Tags**.
1. Note that tags are not supported for Service-Linked roles. Choose **Next:Review**.
1. (Optional) For **Role description**, edit the description for the new service-linked role.
1. Review the role and then choose **Create role**.
### Creating a Service-Linked Role (IAM CLI)
You can use IAM operations from the AWS Command Line Interface to create a service-linked role. This role can include the trust policy and inline policies that the service needs to assume the role.
**To create a service-linked role (CLI)**
Use the following operation:
```
$ aws iam [create-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) --aws-service-name memorydb.amazonaws.com
```
### Creating a Service-Linked Role (IAM API)
You can use the IAM API to create a service-linked role. This role can contain the trust policy and inline policies that the service needs to assume the role.
**To create a service-linked role (API)**
Use the [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API call. In the request, specify a service name of `memorydb.amazonaws.com`.
## Editing the Description of a Service-Linked Role for MemoryDB
MemoryDB does not allow you to edit the AWSServiceRoleForMemoryDB service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM.
### Editing a Service-Linked Role Description (IAM Console)
You can use the IAM console to edit a service-linked role description.
**To edit the description of a service-linked role (console)**
1. In the left navigation pane of the IAM console, choose **Roles**.
1. Choose the name of the role to modify.
1. To the far right of **Role description**, choose **Edit**.
1. Enter a new description in the box and choose **Save**.
### Editing a Service-Linked Role Description (IAM CLI)
You can use IAM operations from the AWS Command Line Interface to edit a service-linked role description.
**To change the description of a service-linked role (CLI)**
1. (Optional) To view the current description for a role, use the AWS CLI for IAM operation `[get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)`.
**Example**
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name AWSServiceRoleForMemoryDB
```
Use the role name, not the ARN, to refer to roles with the CLI operations. For example, if a role has the following ARN: `arn:aws:iam::123456789012:role/myrole`, refer to the role as **myrole**.
1. To update a service-linked role's description, use the AWS CLI for IAM operation `[update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)`.
For Linux, macOS, or Unix:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) \
--role-name AWSServiceRoleForMemoryDB \
--description "new description"
```
For Windows:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ^
--role-name AWSServiceRoleForMemoryDB ^
--description "new description"
```
### Editing a Service-Linked Role Description (IAM API)
You can use the IAM API to edit a service-linked role description.
**To change the description of a service-linked role (API)**
1. (Optional) To view the current description for a role, use the IAM API operation [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&AUTHPARAMS
```
1. To update a role's description, use the IAM API operation [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&Description="New description"
```
## Deleting a Service-Linked Role for MemoryDB
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can delete it.
MemoryDB does not delete the service-linked role for you.
### Cleaning Up a Service-Linked Role
Before you can use IAM to delete a service-linked role, first confirm that the role has no resources (clusters) associated with it.
**To check whether the service-linked role has an active session in the IAM console**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane of the IAM console, choose **Roles**. Then choose the name (not the check box) of the AWSServiceRoleForMemoryDB role.
1. On the **Summary** page for the selected role, choose the **Access Advisor** tab.
1. On the **Access Advisor** tab, review recent activity for the service-linked role.
**To delete MemoryDB resources that require AWSServiceRoleForMemoryDB (console)**
+ To delete a cluster, see the following:
+ [Using the AWS Management Console](getting-started.md#clusters.deleteclusters.viewdetails)
+ [Using the AWS CLI](getting-started.md#clusters.delete.cli)
+ [Using the MemoryDB API](getting-started.md#clusters.delete.api)
### Deleting a Service-Linked Role (IAM Console)
You can use the IAM console to delete a service-linked role.
**To delete a service-linked role (console)**
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. In the left navigation pane of the IAM console, choose **Roles**. Then select the check box next to the role name that you want to delete, not the name or row itself.
1. For **Role actions** at the top of the page, choose **Delete role**.
1. In the confirmation page, review the service last accessed data, which shows when each of the selected roles last accessed an AWS service. This helps you to confirm whether the role is currently active. If you want to proceed, choose **Yes, Delete** to submit the service-linked role for deletion.
1. Watch the IAM console notifications to monitor the progress of the service-linked role deletion. Because the IAM service-linked role deletion is asynchronous, after you submit the role for deletion, the deletion task can succeed or fail. If the task fails, you can choose **View details** or **View Resources** from the notifications to learn why the deletion failed.
### Deleting a Service-Linked Role (IAM CLI)
You can use IAM operations from the AWS Command Line Interface to delete a service-linked role.
**To delete a service-linked role (CLI)**
1. If you don't know the name of the service-linked role that you want to delete, enter the following command. This command lists the roles and their Amazon Resource Names (ARNs) in your account.
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name role-name
```
Use the role name, not the ARN, to refer to roles with the CLI operations. For example, if a role has the ARN `arn:aws:iam::123456789012:role/myrole`, you refer to the role as **myrole**.
1. Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request. That request can be denied if these conditions are not met. You must capture the `deletion-task-id` from the response to check the status of the deletion task. Enter the following to submit a service-linked role deletion request.
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) --role-name role-name
```
1. Enter the following to check the status of the deletion task.
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) --deletion-task-id deletion-task-id
```
The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot.
### Deleting a Service-Linked Role (IAM API)
You can use the IAM API to delete a service-linked role.
**To delete a service-linked role (API)**
1. To submit a deletion request for a service-linked roll, call [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). In the request, specify a role name.
Because a service-linked role cannot be deleted if it is being used or has associated resources, you must submit a deletion request. That request can be denied if these conditions are not met. You must capture the `DeletionTaskId` from the response to check the status of the deletion task.
1. To check the status of the deletion, call [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). In the request, specify the `DeletionTaskId`.
The status of the deletion task can be `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, or `FAILED`. If the deletion fails, the call returns the reason that it failed so that you can troubleshoot.
# AWS managed policies for MemoryDB
To add permissions to users, groups, and roles, it is easier to use AWS managed policies than to write policies yourself. It takes time and expertise to [create IAM customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) that provide your team with only the permissions they need. To get started quickly, you can use our AWS managed policies. These policies cover common use cases and are available in your AWS account. For more information about AWS managed policies, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
AWS services maintain and update AWS managed policies. You can't change the permissions in AWS managed policies. Services occasionally add additional permissions to an AWS managed policy to support new features. This type of update affects all identities (users, groups, and roles) where the policy is attached. Services are most likely to update an AWS managed policy when a new feature is launched or when new operations become available. Services do not remove permissions from an AWS managed policy, so policy updates won't break your existing permissions.
Additionally, AWS supports managed policies for job functions that span multiple services. For example, the **ReadOnlyAccess** AWS managed policy provides read-only access to all AWS services and resources. When a service launches a new feature, AWS adds read-only permissions for new operations and resources. For a list and descriptions of job function policies, see [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
## AWS managed policy: MemoryDBServiceRolePolicy
You cannot attach the MemoryDBServiceRolePolicy AWS managed policy to identities in your account. This policy is part of the AWS MemoryDB service-linked role. This role allows the service to manage network interfaces and security groups in your account.
MemoryDB uses the permissions in this policy to manage EC2 security groups and network interfaces. This is required to manage MemoryDB clusters.
**Permissions details**
This policy includes the following permissions.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
## AWS-managed (predefined) policies for MemoryDB
AWS addresses many common use cases by providing standalone IAM policies that are created and administered by AWS. Managed policies grant necessary permissions for common use cases so you can avoid having to investigate what permissions are needed. For more information, see [AWS Managed Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
The following AWS managed policies, which you can attach to users in your account, are specific to MemoryDB:
### AmazonMemoryDBReadOnlyAccess
You can attach the `AmazonMemoryDBReadOnlyAccess` policy to your IAM identities. This policy grants administrative permissions that allow read-only access to all MemoryDB resources.
**AmazonMemoryDBReadOnlyAccess** - Grants read-only access to MemoryDB resources.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"
],
"Resource": "*"
}]
}
```
------
### AmazonMemoryDBFullAccess
You can attach the `AmazonMemoryDBFullAccess` policy to your IAM identities. This policy grants administrative permissions that allow full access to all MemoryDB resources.
**AmazonMemoryDBFullAccess** - Grants full access to MemoryDB resources.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws-cn:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
You can also create your own custom IAM policies to allow permissions for MemoryDB API actions. You can attach these custom policies to the IAM users or groups that require those permissions.
## MemoryDB updates to AWS managed policies
View details about updates to AWS managed policies for MemoryDB since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the MemoryDB Document history page.
| Change | Description | Date |
| --- | --- | --- |
| [AWS managed policy: MemoryDBServiceRolePolicy](#security-iam-awsmanpol-memorydbServiceRolePolicy) – Adding policy | MemoryDBServiceRolePolicy added the permission for memorydb:ReplicateMultiRegionClusterData. This permission will allow the service-linked role to replicate data for MemoryDB multi-Region clusters. | 12/01/2024 |
| [AmazonMemoryDBFullAccess](#iam.identitybasedpolicies.predefinedpolicies-fullaccess) – Adding policy | MemoryDB added new permissions to describe and list supported resources. These permissions are required for MemoryDB to query all of the supported resources in an account. | 10/07/2021 |
| [AmazonMemoryDBReadOnlyAccess](#iam.identitybasedpolicies.predefinedpolicies-readonly) – Adding policy | MemoryDB added new permissions to describe and list supported resources. These permissions are required for MemoryDB to create account-based applications by querying all of the supported resources in an account. | 10/07/2021 |
| MemoryDB started tracking changes | Service launch | 8/19/2021 |
# MemoryDB API permissions: Actions, resources, and conditions reference
When you set up [access control](iam.md#iam.accesscontrol) and write permissions policies to attach to an IAM policy (either identity-based or resource-based), use the following table as a reference. The table lists each MemoryDB API operation and the corresponding actions for which you can grant permissions to perform the action. You specify the actions in the policy's `Action` field, and you specify a resource value in the policy's `Resource` field. Unless indicated otherwise, the resource is required. Some fields include both a required resource and optional resources. When there is no resource ARN, the resource in the policy is a wildcard (\$1).
**Note**
To specify an action, use the `memorydb:` prefix followed by the API operation name (for example, `memorydb:DescribeClusters`).
Use the scroll bars to see the rest of the table.
**MemoryDB API and required permissions for actions**
| MemoryDB API operations | Required permissions (API actions) | Resources |
| --- | --- | --- |
| [BatchUpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_BatchUpdateCluster.html) | `memorydb:BatchUpdateCluster` | Cluster |
| [CopySnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CopySnapshot.html) | `memorydb:CopySnapshot` `memorydb:TagResource` `s3:GetBucketLocation` `s3:ListAllMyBuckets` | Snapshot (Source, Target) \$1 \$1 |
| [CreateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateCluster.html) | `memorydb:CreateCluster` `memorydb:TagResource` `s3:GetObject` If you use the `SnapshotArns` parameter, each member of the `SnapshotArns` list requires its own `s3:GetObject` permission with the `s3` ARN as its resource. | Parameter group. (Optional) cluster, snapshot, security group Ids and subnet group `arn:aws:s3:::my_bucket/snapshot1.rdb` Where *my\$1bucket*/*snapshot1* is an S3 bucket and snapshot that you want to create the cluster from. |
| [CreateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateParameterGroup.html) | `memorydb:CreateParameterGroup` `memorydb:TagResource` | Parameter group |
| [CreateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSubnetGroup.html) | `memorydb:CreateSubnetGroup` `memorydb:TagResource` | Subnet group | \$1 |
| [CreateSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSnapshot.html) | `memorydb:CreateSnapshot` `memorydb:TagResource` | Snapshot, cluster |
| [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) | `memorydb:CreateUser` `memorydb:TagResource` | User |
| [CreateACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateACL.html) | `memorydb:CreateACL` `memorydb:TagResource` | Access Control List (ACL) |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | Cluster |
| [DeleteCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteCluster.html) | `memorydb:DeleteCluster` | Cluster. (Optional) Snapshot |
| [DeleteParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteParameterGroup.html) | `memorydb:DeleteParameterGroup` | Parameter group |
| [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) | `memorydb:DeleteSubnetGroup` | Subnet group |
| [DeleteSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSnapshot.html) | `memorydb:DeleteSnapshot` | Snapshot |
| [DeleteUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteUser.html) | `memorydb:DeleteUser` | User |
| [DeleteACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteACL.html) | `memorydb:DeleteACL` | ACL |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeEngineVersions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEngineVersions.html) | `memorydb:DescribeEngineVersions` | No Resource ARN: \$1 |
| [DescribeParameterGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameterGroups.html) | `memorydb:DescribeParameterGroups` | Parameter group |
| [DescribeParameters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameters.html) | `memorydb:DescribeParameters` | Parameter group |
| [DescribeSubnetGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSubnetGroups.html) | `memorydb:DescribeSubnetGroups` | Subnet group | \$1 |
| [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) | `memorydb:DescribeEvents` | No Resource ARN: \$1 |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeServiceUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html) | `memorydb:DescribeServiceUpdates` | No Resource ARN: \$1 |
| [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html) | `memorydb:DescribeSnapshots` | Snapshot |
| [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) | `memorydb:DescribeUsers` | User |
| [DescribeACLs](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeACLs.html) | `memorydb:DescribeACLs` | ACLs |
| [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) | `memorydb:ListAllowedNodeTypeUpdates` | Cluster |
| [ListTags](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListTags.html) | `memorydb:ListTags` | (Optional) cluster, snapshot |
| [UpdateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateParameterGroup.html) | `memorydb:UpdateParameterGroup` | Parameter group |
| [UpdateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateSubnetGroup.html) | `memorydb:UpdateSubnetGroup` | Subnet group |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | cluster. (Optional) Parameter group, Security group |
| [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) | `memorydb:UpdateUser` | User |
| [UpdateACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateACL.html) | `memorydb:UpdateACL` | ACL |
| [UntagResource](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UntagResource.html) | `memorydb:UntagResource` | (Optional) Cluster, snapshot |
| [ResetParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ResetParameterGroup.html) | `memorydb:ResetParameterGroup` | Parameter group |
| [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) | `memorydb:FailoverShard` | cluster, shard |
# Logging and monitoring
Monitoring is an important part of maintaining the reliability, availability, and performance of MemoryDB and your other AWS solutions. AWS provides the following monitoring tools to watch MemoryDB, report when something is wrong, and take automatic actions when appropriate:
+ *Amazon CloudWatch* monitors your AWS resources and the applications you run on AWS in real time. You can collect and track metrics, create customized dashboards, and set alarms that notify you or take actions when a specified metric reaches a threshold that you specify. For example, you can have CloudWatch track CPU usage or other metrics of your Amazon EC2 instances and automatically launch new instances when needed. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ *Amazon CloudWatch Logs* enables you to monitor, store, and access your log files from Amazon EC2 instances, CloudTrail, and other sources. CloudWatch Logs can monitor information in the log files and notify you when certain thresholds are met. You can also archive your log data in highly durable storage. For more information, see the [Amazon CloudWatch Logs User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ *AWS CloudTrail* captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Monitoring MemoryDB with Amazon CloudWatch
You can monitor MemoryDB using CloudWatch, which collects raw data and processes it into readable, near real-time metrics. These statistics are kept for 15 months, so that you can access historical information and gain a better perspective on how your web application or service is performing. You can also set alarms that watch for certain thresholds, and send notifications or take actions when those thresholds are met. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
The following sections list the metrics and dimensions for MemoryDB.
**Topics**
+ [Host-Level Metrics](metrics.HostLevel.md)
+ [Metrics for MemoryDB](metrics.memorydb.md)
+ [Which Metrics Should I Monitor?](metrics.whichshouldimonitor.md)
+ [Choosing Metric Statistics and Periods](metrics.ChoosingStatisticsAndPeriods.md)
+ [Monitoring CloudWatch metrics](cloudwatchmetrics.md)
# Host-Level Metrics
The `AWS/MemoryDB` namespace includes the following host-level metrics for individual nodes.
**See Also**
+ [Metrics for MemoryDB](metrics.memorydb.md)
| Metric | Description | Unit |
| --- | --- | --- |
| CPUUtilization | The percentage of CPU utilization for the entire host. Because Valkey and Redis OSS are single-threaded, we recommend you monitor EngineCPUUtilization metric for nodes with 4 or more vCPUs. | Percent |
| FreeableMemory | The amount of free memory available on the host. This number is derived from the memory in RAM and buffers that the OS reports as freeable. | Bytes |
| NetworkBytesIn | The number of bytes the host has read from the network. | Bytes |
| NetworkBytesOut | The number of bytes sent out on all network interfaces by the instance. | Bytes |
| NetworkPacketsIn | The number of packets received on all network interfaces by the instance. This metric identifies the volume of incoming traffic in terms of the number of packets on a single instance. | Count |
| NetworkPacketsOut | The number of packets sent out on all network interfaces by the instance. This metric identifies the volume of outgoing traffic in terms of the number of packets on a single instance. | Count |
| NetworkBandwidthInAllowanceExceeded | The number of packets shaped because the inbound aggregate bandwidth exceeded the maximum for the instance. | Count |
| NetworkConntrackAllowanceExceeded | The number of packets shaped because connection tracking exceeded the maximum for the instance and new connections could not be established. This can result in packet loss for traffic to or from the instance. | Count |
| NetworkBandwidthOutAllowanceExceeded | The number of packets shaped because the outbound aggregate bandwidth exceeded the maximum for the instance. | Count |
| NetworkPacketsPerSecondAllowanceExceeded | The number of packets shaped because the bidirectional packets per second exceeded the maximum for the instance. | Count |
| NetworkMaxBytesIn | The maximum per second burst of received bytes within each minute. | Bytes |
| NetworkMaxBytesOut | The maximum per second burst of transmitted bytes within each minute. | Bytes |
| NetworkMaxPacketsIn | The maximum per second burst of received packets within each minute. | Count |
| NetworkMaxPacketsOut | The maximum per second burst of transmitted packets within each minute. | Count |
| SwapUsage | The amount of swap used on the host. | Bytes |
# Metrics for MemoryDB
The `AWS/MemoryDB` namespace includes the following metrics.
With the exception of `ReplicationLag`, `EngineCPUUtilization`, `SuccessfulWriteRequestLatency`, and `SuccessfulReadRequestLatency`, these metrics are derived from the Valkey and Redis OSS **info** command. Each metric is calculated at the node level.
For complete documentation of the **INFO** command, see [INFO](http://valkey.io/commands/info).
**See also:**
+ [Host-Level Metrics](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html)
The following are aggregations of certain kinds of commands, derived from **info commandstats**. The commandstats section provides statistics based on the command type, including the number of calls.
For a full list of available commands, see [commands](https://valkey.io/commands).
| Metric | Description | Unit |
| --- | --- | --- |
| EvalBasedCmds | The total number of commands for eval-based commands. This is derived from the commandstats statistic by summing eval and evalsha. | Count |
| GeoSpatialBasedCmds | The total number of commands for geospatial-based commands. This is derived from the commandstats statistic. It's derived by summing all of the geo type of commands: geoadd, geodist, geohash, geopos, georadius, and georadiusbymember. | Count |
| GetTypeCmds | The total number of read-only type commands. This is derived from the commandstats statistic by summing all of the read-only type commands (get, hget, scard, lrange, and so on.) | Count |
| HashBasedCmds | The total number of commands that are hash-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more hashes (hget, hkeys, hvals, hdel, and so on). | Count |
| HyperLogLogBasedCmds | The total number of HyperLogLog-based commands. This is derived from the commandstats statistic by summing all of the pf type of commands (pfadd, pfcount, pfmerge, and so on.). | Count |
| JsonBasedCmds | The total number of commands that are JSON-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more JSON document objects. | Count |
| KeyBasedCmds | The total number of commands that are key-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more keys across multiple data structures (del, expire, rename, and so on.). | Count |
| ListBasedCmds | The total number of commands that are list-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more lists (lindex, lrange, lpush, ltrim, and so on). | Count |
| PubSubBasedCmds | The total number of commands for pub/sub functionality. This is derived from the commandstats statistics by summing all of the commands used for pub/sub functionality: psubscribe, publish, pubsub, punsubscribe, subscribe, and unsubscribe. | Count |
| SearchBasedCmds | The total number of secondary index and search commands, including both read and write commands. This is derived from the commandstats statistic by summing all search commands that act upon secondary indexes. | Count |
| SearchBasedGetCmds | Total number of secondary index and search read-only commands. This is derived from the commandstats statistic by summing all secondary index and search get commands. | Count |
| SearchBasedSetCmds | Total number of secondary index and search write commands. This is derived from the commandstats statistic by summing all secondary index and search set commands. | Count |
| SearchNumberOfIndexes | Total number of indexes. | Count |
| SearchNumberOfIndexedKeys | Total number of indexed keys | Count |
| SearchTotalIndexSize | Memory (bytes) used by all the indexes. | Bytes |
| SetBasedCmds | The total number of commands that are set-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more sets (scard, sdiff, sadd, sunion, and so on). | Count |
| SetTypeCmds | The total number of write types of commands. This is derived from the commandstats statistic by summing all of the mutative types of commands that operate on data (set, hset, sadd, lpop, and so on.) | Count |
| SortedSetBasedCmds | The total number of commands that are sorted set-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more sorted sets (zcount, zrange, zrank, zadd, and so on). | Count |
| StringBasedCmds | The total number of commands that are string-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more strings (strlen, setex, setrange, and so on). | Count |
| StreamBasedCmds | The total number of commands that are stream-based. This is derived from the commandstats statistic by summing all of the commands that act upon one or more streams data types (xrange, xlen, xadd, xdel, and so on). | Count |
# Which Metrics Should I Monitor?
The following CloudWatch metrics offer good insight into MemoryDB performance. In most cases, we recommend that you set CloudWatch alarms for these metrics so that you can take corrective action before performance issues occur.
**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [EngineCPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [Memory](#metrics-memory)
+ [Network](#metrics-network)
+ [Latency](#metrics-latency)
+ [Replication](#metrics-replication)
## CPUUtilization
This is a host-level metric reported as a percentage. For more information, see [Host-Level Metrics](metrics.HostLevel.md).
For smaller node types with 2vCPUs or less, use the `CPUUtilization ` metric to monitor your workload.
Generally speaking, we suggest you set your threshold at 90% of your available CPU. Because Valkey and Redis OSS are single-threaded, the actual threshold value should be calculated as a fraction of the node's total capacity. For example, suppose you are using a node type that has two cores. In this case, the threshold for CPUUtilization would be 90/2, or 45%. To find the number of cores (vCPUs) your node type has, see [MemoryDB Pricing](https://aws.amazon.com/memorydb/pricing/?p=ps).
You will need to determine your own threshold, based on the number of cores in the node that you are using. If you exceed this threshold, and your main workload is from read requests, scale your cluster out by adding read replicas. If the main workload is from write requests, we recommend that you add more shards to distribute the write workload across more primary nodes.
**Tip**
Instead of using the Host-Level metric `CPUUtilization`, you might be able to use the metric `EngineCPUUtilization`, which reports the percentage of usage on the Valkey or Redis OSS engine core. To see if this metric is available on your nodes and for more information, see [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
For larger node types with 4vCPUs or more, you may want to use the `EngineCPUUtilization` metric, which reports the percentage of usage on the Valkey or Redis OSS engine core. To see if this metric is available on your nodes and for more information, see [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## EngineCPUUtilization
For larger node types with 4vCPUs or more, you may want to use the `EngineCPUUtilization` metric, which reports the percentage of usage on the Valkey or Redis OSS engine core. To see if this metric is available on your nodes and for more information, see [Metrics for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## SwapUsage
This is a host-level metric reported in bytes. For more information, see [Host-Level Metrics](metrics.HostLevel.md).
If either the `FreeableMemory` CloudWatch metric is close to 0 (i.e., below 100MB), or the `SwapUsage` metric is greater than the `FreeableMemory` metric, then a node could be under memory pressure.
## Evictions
This is a engine metric. We recommend that you determine your own alarm threshold for this metric based on your application needs.
## CurrConnections
This is a engine metric. We recommend that you determine your own alarm threshold for this metric based on your application needs.
An increasing number of *CurrConnections* might indicate a problem with your application; you will need to investigate the application behavior to address this issue.
## Memory
Memory is a core aspect of Valkey and of Redis OSS. Understanding the memory utilization of your cluster is necessary to avoid data loss and accommodate future growth of your dataset. Statistics about the memory utilization of a node are available in the memory section of the [INFO](https://valkey.io/commands/info) command.
## Network
One of the determining factors for the network bandwidth capacity of your cluster is the node type you have selected. For more information about the network capacity of your node, see [Amazon MemoryDB pricing](https://aws.amazon.com/memorydb/pricing/).
## Latency
The latency metrics `SuccessfulWriteRequestLatency` and `SuccessfulReadRequestLatency` measure the total time that MemoryDB for the Valkey engine takes to respond to a request.
**Note**
Inflated values for `SuccessfulWriteRequestLatency` and `SuccessfulReadRequestLatency` metrics may occur when using Valkey pipelining with CLIENT REPLY enabled on the Valkey client. Valkey pipelining is a technique for improving performance by issuing multiple commands at once, without waiting for the response to each individual command. To avoid inflated values, we recommend configuring your Redis client to pipeline commands with [CLIENT REPLY OFF](https://valkey.io/commands/client-reply/).
## Replication
The volume of data being replicated is visible via the `ReplicationBytes` metric. You can monitor `MaxReplicationThroughput` against the replication capacity throughput. It is recommended to add more shards when reaching the maximum replication capacity throughput.
`ReplicationDelayedWriteCommands` can also indicate if the workload is exceeding the maximum replication capacity throughput. For more information about replication in MemoryDB, see [Understanding MemoryDB replication](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)
# Choosing Metric Statistics and Periods
While CloudWatch will allow you to choose any statistic and period for each metric, not all combinations will be useful. For example, the Average, Minimum, and Maximum statistics for CPUUtilization are useful, but the Sum statistic is not.
All MemoryDB samples are published for a 60 second duration for each individual node. For any 60 second period, a node metric will only contain a single sample.
# Monitoring CloudWatch metrics
MemoryDB and CloudWatch are integrated so you can gather a variety of metrics. You can monitor these metrics using CloudWatch.
**Note**
The following examples require the CloudWatch command line tools. For more information about CloudWatch and to download the developer tools, see the [ CloudWatch product page](https://aws.amazon.com/cloudwatch).
The following procedures show you how to use CloudWatch to gather storage space statistics for an cluster for the past hour.
**Note**
The `StartTime` and `EndTime` values supplied in the examples following are for illustrative purposes. Make sure to substitute appropriate start and end time values for your nodes.
For information on MemoryDB limits, see [AWS service limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb) for MemoryDB.
## Monitoring CloudWatch metrics (Console)
**To gather CPU utilization statistics for a cluster**
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. Select the nodes you want to view metrics for.
**Note**
Selecting more than 20 nodes disables viewing metrics on the console.
1. On the ** Clusters** page of the AWS Management Console, click the name of one or more clusters.
The detail page for the cluster appears.
1. Click the **Nodes** tab at the top of the window.
1. On the **Nodes** tab of the detail window, select the nodes that you want to view metrics for.
A list of available CloudWatch Metrics appears at the bottom of the console window.
1. Click on the **CPU Utilization** metric.
The CloudWatch console will open, displaying your selected metrics. You can use the **Statistic** and **Period** drop-down list boxes and **Time Range** tab to change the metrics being displayed.
## Monitoring CloudWatch metrics using the CloudWatch CLI
**To gather CPU utilization statistics for a cluster**
+ Use the CloudWatch command **aws cloudwatch get-metric-statistics** with the following parameters (note that the start and end times are shown as examples only; you will need to substitute your own appropriate start and end times):
For Linux, macOS, or Unix:
```
1. aws cloudwatch get-metric-statistics CPUUtilization \
2. --dimensions=ClusterName=mycluster,NodeId=0002" \
3. --statistics=Average \
4. --namespace="AWS/MemoryDB" \
5. --start-time 2013-07-05T00:00:00 \
6. --end-time 2013-07-06T00:00:00 \
7. --period=60
```
For Windows:
```
1. mon-get-stats CPUUtilization ^
2. --dimensions=ClusterName=mycluster,NodeId=0002" ^
3. --statistics=Average ^
4. --namespace="AWS/MemoryDB" ^
5. --start-time 2013-07-05T00:00:00 ^
6. --end-time 2013-07-06T00:00:00 ^
7. --period=60
```
## Monitoring CloudWatch metrics using the CloudWatch API
**To gather CPU utilization statistics for a cluster**
+ Call the CloudWatch API `GetMetricStatistics` with the following parameters (note that the start and end times are shown as examples only; you will need to substitute your own appropriate start and end times):
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/MemoryDB`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=ClusterName=mycluster,NodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?SignatureVersion=4
3. &Action=GetMetricStatistics
4. &Version=2014-12-01
5. &StartTime=2013-07-16T00:00:00
6. &EndTime=2013-07-16T00:02:00
7. &Period=60
8. &Statistics.member.1=Average
9. &Dimensions.member.1="ClusterName=mycluster"
10. &Dimensions.member.2="NodeId=0002"
11. &Namespace=Amazon/memorydb
12. &MeasureName=CPUUtilization
13. &Timestamp=2013-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```
# Monitoring MemoryDB events
When significant events happen for a cluster, MemoryDB sends notification to a specific Amazon SNS topic. Examples include a failure to add a node, success in adding a node, the modification of a security group, and others. By monitoring for key events, you can know the current state of your clusters and, depending upon the event, be able to take corrective action.
**Topics**
+ [Managing MemoryDB Amazon SNS notifications](mdbevents.sns.md)
+ [Viewing MemoryDB events](mdbevents.viewing.md)
+ [Event Notifications and Amazon SNS](memorydbsns.md)
# Managing MemoryDB Amazon SNS notifications
You can configure MemoryDB to send notifications for important cluster events using Amazon Simple Notification Service (Amazon SNS). In these examples, you will configure a cluster with the Amazon Resource Name (ARN) of an Amazon SNS topic to receive notifications.
**Note**
This topic assumes that you've signed up for Amazon SNS and have set up and subscribed to an Amazon SNS topic. For information on how to do this, see the [Amazon Simple Notification Service Developer Guide](https://docs.aws.amazon.com/sns/latest/dg/).
## Adding an Amazon SNS topic
The following sections show you how to add an Amazon SNS topic using the AWS Console, the AWS CLI, or the MemoryDB API.
### Adding an Amazon SNS topic (Console)
The following procedure shows you how to add an Amazon SNS topic for a cluster.
**Note**
This process can also be used to modify the Amazon SNS topic.
**To add or modify an Amazon SNS topic for a cluster (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 ** Clusters**, choose the cluster for which you want to add or modify an Amazon SNS topic ARN.
1. Choose **Modify**.
1. In **Modify Cluster** under **Topic for SNS Notification**, choose the SNS topic you want to add, or choose **Manual ARN input** and type the ARN of the Amazon SNS topic.
1. Choose **Modify**.
### Adding an Amazon SNS topic (AWS CLI)
To add or modify an Amazon SNS topic for a cluster, use the AWS CLI command `update-cluster`.
The following code example adds an Amazon SNS topic arn to *my-cluster*.
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
For more information, see [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) .
### Adding an Amazon SNS topic (MemoryDB API)
To add or update an Amazon SNS topic for a cluster, call the `UpdateCluster` action with the following parameters:
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
To add or update an Amazon SNS topic for a cluster, call the `UpdateCluster` action.
For more information, see [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Enabling and disabling Amazon SNS notifications
You can turn notifications on or off for a cluster. The following procedures show you how to disable Amazon SNS notifications.
### Enabling and disabling Amazon SNS notifications (Console)
**To disable Amazon SNS notifications using the AWS Management 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. Choose the radio button to the left of the cluster you want to modify notification for.
1. Choose **Modify**.
1. In **Modify Cluster** under **Topic for SNS Notification**, choose *Disable Notifications*.
1. Choose **Modify**.
### Enabling and disabling Amazon SNS notifications (AWS CLI)
To disable Amazon SNS notifications, use the command `update-cluster` with the following parameters:
For Linux, macOS, or Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
For Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Enabling and disabling Amazon SNS notifications (MemoryDB API)
To disable Amazon SNS notifications, call the `UpdateCluster` action with the following parameters:
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
This call returns output similar to the following:
**Example**
```
1. https://memory-db.us-east-1.amazonaws.com/
2. ?Action=UpdateCluster
3. &ClusterName=my-cluster
4. &SnsTopicStatus=inactive
5. &Version=2021-01-01
6. &SignatureVersion=4
7. &SignatureMethod=HmacSHA256
8. &Timestamp=20210801T220302Z
9. &X-Amz-Algorithm=Amazon4-HMAC-SHA256
10. &X-Amz-Date=20210801T220302Z
11. &X-Amz-SignedHeaders=Host
12. &X-Amz-Expires=20210801T220302Z
13. &X-Amz-Credential=
14. &X-Amz-Signature=
```
# Viewing MemoryDB events
MemoryDB logs events that relate to your clusters, security groups, and parameter groups. This information includes the date and time of the event, the source name and source type of the event, and a description of the event. You can easily retrieve events from the log using the MemoryDB console, the AWS CLI `describe-events` command, or the MemoryDB API action `DescribeEvents`.
The following procedures show you how to view all MemoryDB events for the past 24 hours (1440 minutes).
## Viewing MemoryDB events (Console)
The following procedure displays events using the MemoryDB console.
**To view events using the MemoryDB 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 **Events**.
The *Events* screen appears listing all available events. Each row of the list represents one event and displays the event source, the event type (such as cluster, parameter-group, acl, security-group or subnet group), the GMT time of the event, and the description of the event.
Using the **Filter** you can specify whether you want to see all events, or just events of a specific type in the event list.
## Viewing MemoryDB events (AWS CLI)
To generate a list of MemoryDB events using the AWS CLI, use the command `describe-events`. You can use optional parameters to control the type of events listed, the time frame of the events listed, the maximum number of events to list, and more.
The following code lists up to 40 cluster events.
```
aws memorydb describe-events --source-type cluster --max-results 40
```
The following code lists all events for the past 24 hours (1440 minutes).
```
aws memorydb describe-events --duration 1440
```
The output from the `describe-events` command looks something like this.
```
{
"Events": [
{
"Date": "2021-03-29T22:17:37.781Z",
"Message": "Added node 0001 in Availability Zone us-east-1a",
"SourceName": "memorydb01",
"SourceType": "cluster"
},
{
"Date": "2021-03-29T22:17:37.769Z",
"Message": "cluster created",
"SourceName": "memorydb01",
"SourceType": "cluster"
}
]
}
```
For more information, such as available parameters and permitted parameter values, see [https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html).
## Viewing MemoryDB events (MemoryDB API)
To generate a list of MemoryDB events using the MemoryDB API, use the `DescribeEvents` action. You can use optional parameters to control the type of events listed, the time frame of the events listed, the maximum number of events to list, and more.
The following code lists the 40 most recent -cluster events.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&MaxResults=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
The following code lists the cluster events for the past 24 hours (1440 minutes).
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
The above actions should produce output similar to the following.
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
For more information, such as available parameters and permitted parameter values, see [https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html).
# Event Notifications and Amazon SNS
MemoryDB can publish messages using Amazon Simple Notification Service (SNS) when significant events happen on a cluster. This feature can be used to refresh the server-lists on client machines connected to individual node endpoints of a cluster.
**Note**
For more information on Amazon Simple Notification Service (SNS), including information on pricing and links to the Amazon SNS documentation, see the [Amazon SNS product page](https://aws.amazon.com/sns).
Notifications are published to a specified Amazon SNS *topic*. The following are requirements for notifications:
+ Only one topic can be configured for MemoryDB notifications.
+ The AWS account that owns the Amazon SNS topic must be the same account that owns the cluster on which notifications are enabled.
## MemoryDB Events
The following MemoryDB events trigger Amazon SNS notifications:
| Event Name | Message | Description |
| --- | --- | --- |
| MemoryDB:AddNodeComplete | "Modified number of nodes from %d to %d" | A node has been added to the cluster and is ready for use. |
| MemoryDB:AddNodeFailed due to insufficient free IP addresses | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | A node could not be added because there are not enough available IP addresses. |
| MemoryDB:ClusterParametersChanged | "Updated parameter group for the cluster" In case of create, also send `"Updated to use a ParameterGroup %s"` | One or more cluster parameters have been changed. |
| MemoryDB:ClusterProvisioningComplete | "Cluster created." | The provisioning of a cluster is completed, and the nodes in the cluster are ready to use. |
| MemoryDB:ClusterProvisioningFailed due to incompatible network state | "Failed to create cluster due to incompatible network state. %s" | An attempt was made to launch a new cluster into a nonexistent virtual private cloud (VPC). |
| MemoryDB:ClusterRestoreFailed | "Restore from %s failed for node %s. %s" | MemoryDB was unable to populate the cluster with snapshot data. This could be due to a nonexistent snapshot file in Amazon S3, or incorrect permissions on that file. If you describe the cluster, the status will be `restore-failed`. You will need to delete the cluster and start over. For more information, see [Seeding a new cluster with an externally created snapshot](snapshots-seeding-redis.md). |
| MemoryDB:ClusterScalingComplete | `"Succeeded applying modification to node type to %s."` | Scale up for cluster completed successfully. |
| MemoryDB:ClusterScalingFailed | `"Failed applying modification to node type to %s."` | Scale-up operation on cluster failed. |
| MemoryDB:NodeReplaceStarted | "Recovering node %s" | MemoryDB has detected that the host running a node is degraded or unreachable and has started replacing the node. The DNS entry for the replaced node is not changed. In most instances, you do not need to refresh the server-list for your clients when this event occurs. However, some client libraries may stop using the node even after MemoryDB has replaced the node; in this case, the application should refresh the server-list when this event occurs. |
| MemoryDB:NodeReplaceComplete | "Finished recovery for node %s" | MemoryDB has detected that the host running a node is degraded or unreachable and has completed replacing the node. The DNS entry for the replaced node is not changed. In most instances, you do not need to refresh the server-list for your clients when this event occurs. However, some client libraries may stop using the node even after MemoryDB has replaced the node; in this case, the application should refresh the server-list when this event occurs. |
| MemoryDB:CreateClusterComplete | "Cluster created" | The cluster was successfully created. |
| MemoryDB:CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." and "Deleting all nodes belonging to this cluster." | The cluster was not created. |
| MemoryDB:DeleteClusterComplete | "Cluster deleted." | The deletion of a cluster and all associated nodes has completed. |
| MemoryDB:FailoverComplete | `"Failover to replica node %s completed"` | Failover over to a replica node was successful. |
| MemoryDB:NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | A node in your cluster that was scheduled for replacement is no longer scheduled for replacement. |
| MemoryDB:NodeReplacementRescheduled | "The replacement in maintenance window for node %s has been re-scheduled from previous start time: %s, previous end time: %s to new start time: %s, new end time: %s" | A node in your cluster previously scheduled for replacement has been rescheduled for replacement during the new window described in the notification. For information on what actions you can take, see [Replacing nodes](nodes.nodereplacement.md). |
| MemoryDB:NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | A node in your cluster is scheduled for replacement during the window described in the notification. For information on what actions you can take, see [Replacing nodes](nodes.nodereplacement.md). |
| MemoryDB:RemoveNodeComplete | "Removed node %s" | A node has been removed from the cluster. |
| MemoryDB:SnapshotComplete | "Snapshot %s succeeded for node %s" | A snapshot has completed successfully. |
| MemoryDB:SnapshotFailed | "Snapshot %s failed for node %s" | A snapshot has failed. See the cluster’s events for more a detailed cause. If you describe the snapshot, see [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html), the status will be `failed`. |
# Logging MemoryDB API calls with AWS CloudTrail
MemoryDB is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in MemoryDB. CloudTrail captures all API calls for MemoryDB as events, including calls from the MemoryDB console and from code calls to the MemoryDB API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for MemoryDB. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to MemoryDB, the IP address from which the request was made, who made the request, when it was made, and additional details.
To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## MemoryDB information in CloudTrail
CloudTrail is enabled on your AWS account when you create the account. When activity occurs in MemoryDB, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
For an ongoing record of events in your AWS account, including events for MemoryDB, create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all regions. The trail logs events from all regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following:
+ [Overview for Creating a Trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Supported Services and Integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS Notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Receiving CloudTrail Log Files from Multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail Log Files from Multiple Accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
All MemoryDB actions are logged by CloudTrail. For example, calls to the `CreateCluster`, `DescribeClusters` and `UpdateCluster` actions generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
+ Whether the request was made with root or IAM user credentials.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.
For more information, see the [CloudTrail userIdentity Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Understanding MemoryDB log file entries
A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files are not an ordered stack trace of the public API calls, so they do not appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the `CreateCluster` action.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T17:56:46Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"nodeType": "db.r6g.large",
"subnetGroupName": "memorydb-subnet-group",
"aCLName": "open-access"
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "creating",
"numberOfShards": 1,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"enginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "09:00-10:00",
"aCLName": "open-access",
"dataTiering": "false",
"autoMinorVersionUpgrade": true
}
},
"requestID": "506fc951-9ae2-42bb-872c-98028dc8ed11",
"eventID": "2ecf3dc3-c931-4df0-a2b3-be90b596697e",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
The following example shows a CloudTrail log entry that demonstrates the `DescribeClusters` action. Note that for all MemoryDB Describe and List calls (`Describe*` and `List*`), the `responseElements` section is removed and appears as `null`.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T18:39:51Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "DescribeClusters",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.describe-clusters",
"requestParameters": {
"maxResults": 50,
"showShardDetails": true
},
"responseElements": null,
"requestID": "5e831993-52bb-494d-9bba-338a117c2389",
"eventID": "32a3dc0a-31c8-4218-b889-1a6310b7dd50",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
The following example shows a CloudTrail log entry that records an `UpdateCluster` action.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:23:20Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "UpdateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.update-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"snapshotWindow": "04:00-05:00",
"shardConfiguration": {
"shardCount": 2
}
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "updating",
"numberOfShards": 2,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"address": "clustercfg.memorydb-cluster.cde8da.memorydb.us-east-1.amazonaws.com",
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "04:00-05:00",
"autoMinorVersionUpgrade": true,
"DataTiering": "false"
}
},
"requestID": "dad021ce-d161-4365-8085-574133afab54",
"eventID": "e0120f85-ab7e-4ad4-ae78-43ba15dee3d8",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
The following example shows a CloudTrail log entry that demonstrates the `CreateUser` action. Note that for MemoryDB calls that contain sensitive data, that data will be redacted in the corresponding CloudTrail event as shown in the `requestParameters` section below.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:56:13Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-user",
"requestParameters": {
"userName": "memorydb-user",
"authenticationMode": {
"type": "password",
"passwords": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
]
},
"accessString": "~* &* -@all +@read"
},
"responseElements": {
"user": {
"name": "memorydb-user",
"status": "active",
"accessString": "off ~* &* -@all +@read",
"aCLNames": [],
"minimumEngineVersion": "6.2",
"authentication": {
"type": "password",
"passwordCount": 1
},
"aRN": "arn:aws:memorydb:us-east-1:123456789012:user/memorydb-user"
}
},
"requestID": "ae288b5e-80ab-4ff8-989a-5ee5c67cd193",
"eventID": "ed096e3e-16f1-4a23-866c-0baa6ec769f6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
# Compliance validation for MemoryDB
Third-party auditors assess the security and compliance of MemoryDB as part of multiple AWS compliance programs. This includes:
+ Payment Card Industry Data Security Standard (PCI DSS). For more information, see [PCI DSS.](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)
+ Health Insurance Portability and Accountability Act Business Associate Agreement (HIPAA BAA). For more information, see [HIPAA Compliance](https://aws.amazon.com/compliance/hipaa-compliance).
+ System and Organization Controls (SOC) 1, 2, and 3. For more information, see [SOC](https://aws.amazon.com/compliance/soc-faqs).
+ Federal Risk and Authorization Management Program (FedRAMP) Moderate. For more information, see [FedRAMP](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/).
+ ISO/IEC 27001:2013, 27017:2015, 27018:2019, and ISO/IEC 9001:2015. For more information, see [AWS ISO and CSA STAR certifications and services](https://aws.amazon.com/compliance/iso-certified/).
For a list of AWS services in scope of specific compliance programs, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using MemoryDB is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance:
+ [Security and Compliance Quick Start Guides](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS.
+ [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location.
+ [Evaluating Resources with Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) in the *AWS Config Developer Guide* – AWS Config assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) – This AWS service helps you continuously audit your AWS usage to simplify how you manage risk and compliance with regulations and industry standards.
# Infrastructure security in MemoryDB
As a managed service, MemoryDB is protected by the AWS global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) whitepaper.
You use AWS published API calls to access MemoryDB through the network. Clients must support Transport Layer Security (TLS) 1.2 or later. We recommend TLS 1.3 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes.
Additionally, requests must be signed using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests.
# 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 |
# Service updates in MemoryDB
MemoryDB automatically monitors your fleet of clusters and nodes to apply service updates as they become available. Typically, you set up a predefined maintenance window so that MemoryDB can apply these updates. However, in some cases you might find this approach too rigid and likely to constrain your business flows.
With [Service updates in MemoryDB](#service-updates), you control when and which updates are applied. You can also monitor the progress of these updates to your selected MemoryDB cluster in real time.
# Managing the service updates
MemoryDB service updates are released on a regular basis. If you have one or more qualifying clusters for those service updates, you receive notifications through email, SNS, the Personal Health Dashboard (PHD), and Amazon CloudWatch events when the updates are released. The updates are also displayed on the **Service Updates** page on the MemoryDB console. By using this dashboard, you can view all the service updates and their status for your MemoryDB fleet.
You control when to apply an update before an auto-update starts. We strongly recommend that you apply any updates of type **security-update** as soon as possible to ensure that your MemoryDB are always up-to-date with current security patches.
The following sections explore these options in detail.
**Topics**
+ [Amazon MemoryDB Managed maintenance and service updates overview](#managing-updates-maintenance)
## Amazon MemoryDB Managed maintenance and service updates overview
We frequently upgrade our MemoryDB fleet, with patches and upgrades being applied to instances seamlessly. We do this in one of the two ways:
1. Continuous managed maintenance.
1. Service updates.
These maintenance and service updates are required to apply upgrades that strengthen security, reliability, and operational performance.
Continuous managed maintenance happens from time to time and directly in your maintenance windows without requiring any action from your end. It's important to note that maintenance windows are mandatory for all customers, and you don't have the option to opt out. We strongly recommend avoiding any critical or important activities during these established maintenance windows. Additionally, please be aware that critical updates cannot be skipped to ensure the security and optimal performance of the system.
Service updates give you flexibility to apply them on your own. They are timed and may be moved into the maintenance window to be applied by us after their due date lapses.
You can manage updates by applying them at your earliest convenience or by replacing nodes, as updates are automatically applied on replacement. There will be no update activity during incoming maintenance windows if the updates have been applied to all nodes before them.
### Service updates
[Service updates in MemoryDB](service-updates.md) enable you to apply certain service updates at your discretion. These updates can be of the following types: security patches or minor software updates. These updates help strengthen security, reliability, and operational performance of your clusters.
The value of these service updates is that you can control when to apply the update (e.g., you can delay applying service updates when there is an important business event that requires 24x7 availability of MemoryDB clusters).
If you have one or more qualifying clusters for those service updates, you receive notifications through email, the [Amazon SNS](mdbevents.sns.md), the [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html), and [Amazon CloudWatch Events](monitoring-cloudwatch.md) events when the updates are released. The updates are also displayed on the **Service Updates** page on the MemoryDB console. By using this dashboard, you can view all the service updates and their status for your MemoryDB fleet.
You control when to apply an update before an auto-update starts. We strongly recommend that you apply any updates of type security-update as soon as possible to ensure that your MemoryDB are always up-to-date with current security patches.
Your cluster may be part of different service updates. Most of the updates do not require you to apply them separately. Applying one update to your cluster will mark the other updates as completed wherever applicable. You may need to apply multiple updates to the same cluster separately if the status does not change to “completed” automatically.
#### Service updates impact and downtime
When you or Amazon MemoryDB applies a service update to one or more MemoryDB clusters, the update is applied to no more than one node at a time within each shard until all selected clusters are updated. The nodes being updated will experience downtime of few seconds, while the rest of the cluster will continue to serve traffic.
+ There will be no change in the cluster configuration.
+ You will see a delay in your CloudWatch metrics that catch up as soon as possible.
**How does a node replacement impact my application?** - For MemoryDB nodes, the replacement process is designed to guarantee durability and availability. For single node MemoryDB clusters, MemoryDB dynamically spins up a replica, restores data from our durability components, and then fails over to it. For replication groups consisting of multiple nodes, MemoryDB replaces the existing replicas and syncs data from our durability components to the new replicas. MemoryDB is only Multi-AZ when there are more than 1 node so in this scenario, replacing the primary triggers a failover to a read replica. The planned node replacements complete while the cluster serves incoming write requests. If there is only one node, MemoryDB replaces the primary and then syncs the data from our durability components. The primary node is unavailable during this time, leading to longer write interruption.
**What best practices should I follow for a smooth replacement experience and minimize data loss?** - In MemoryDB, data is highly durable, and data loss is not expected even in single node implementations. It is however recommended to implement Multi-AZ and backup strategies to minimize chances of loss in the unlikely event of failure. For a smooth replacement experience, we try to replace just enough nodes from the same cluster at a time to keep the cluster stable. You can provision primary and read replicas in different availability zones by enabling Multi-AZ. In this case, when a node is replaced, the primary role will failover to a replica in the shard. This shard will now serve traffic, and the data will be restored from its durability components. If your configuration includes only one primary and one single replica per shard, we recommend adding additional replicas prior to the patching. This will prevent reduced availability during the patching process. We recommend scheduling the replacement during a period with low incoming write traffic.
**What client configuration best practices should I follow to minimize application interruption during maintenance?** - In MemoryDB, the cluster mode configuration is always enabled, which provides the best availability during managed or unmanaged operations. The individual node endpoints of the replica nodes can be used for all the read operations. In MemoryDB, auto-failover is always enabled in the cluster, meaning the primary node may change. Therefore, the application should confirm the role of the node and update all the read endpoints to ensure that you aren't causing a major load on the primary. Similarly, avoid overloading the replicas with read requests during maintenance windows. One way to achieve this is to ensure that you have at least two read replicas to avoid any read interruption during maintenance.
It's important to test client applications to confirm that they comply with the Redis/Valkey Cluster protocol, and requests can be redirected across nodes properly. It is advisable to implement back-off and retry strategies to avoid overloading MemoryDB nodes during maintenance and replacement activities.
**Rescheduling** - You can defer the service update by changing the [maintenance window](maintenance-window.md). The scheduled update will only be applied to the cluster if the scheduled date matches the cluster's maintenance window. Once you change the maintenance window and the scheduled date has passed, the service update will be rescheduled to the newly specified window in the following weeks. You will receive a new notification one week before the new date has been reached.
Security at AWS is a shared responsibility. We strongly recommend that you apply the update at the earliest.
**Opting out of service updates ** - You can determine if you can opt out of a service update by verifying the value of “Auto-update start date” attribute. If the value of “Auto-update start date” attribute of a service update is set, MemoryDB will schedule the service update to any remaining clusters for the upcoming maintenance window, and it is not possible to opt out. Still, if you apply the service update to the remaining clusters prior to the maintenance window, MemoryDB will not reapply the service update during the maintenance window. For more information, see [Applying the service updates](applying-updates.md).
**Why can’t the service updates be directly applied by MemoryDB during maintenance windows?** - Please note that the purpose of service updates is to give you flexibility on when to apply them. Clusters that are not participating in the MemoryDB-supported [compliance](memorydb-compliance.md) programs can choose to not apply these updates, or apply them at a reduced frequency throughout the year. It is recommended however to apply the updates to remain compliant with regulations. This is true only when the value of “Auto-update start date” attribute of a service update is not present. For more information, see [Compliance validation for MemoryDB](memorydb-compliance.md).
**How are updates applied in the maintenance window different from the service updates?** - Updates applied via continuous managed maintenance are directly scheduled in your maintenance windows without any action needed from your side. Service updates are timed and give you control on when you want to apply by the “Auto-update start date”. If they are still not applied by then, MemoryDB may schedule these updates in your maintenance window.
### Continuous Managed Maintenance Updates
These updates are mandatory and applied directly in your maintenance windows without any action needed from your side. These updates are separate than those offered by service updates.
#### Continuous maintenance impact and downtime
**How long does a node replacement take?** - A replacement typically completes within 30 minutes. The replacement may take longer in certain instance configurations and traffic patterns.
**How does a node replacement impact my application?** - Continuous Managed Maintenance Updates are applied in the same way as “Service updates”, through node replacement. Please refer to the Service updates impact and downtime section above for details.
**How do I manage node replacements on my own?** - You have the option to manage these replacements yourself at any time before the scheduled node replacement window. If you choose to manage the replacement yourself, you can take various actions depending on your use case.
+ [Replace a node in cluster with one or more shards](nodes.nodereplacement.md): You can either use [backup and restore](snapshots-restoring.md) or scale-out followed by a scale-in to [replace the nodes](cluster-resharding-online.md).
+ [Change your maintenance window](maintenance-window.md): Also, you can change your cluster’s maintenance window. For changing your maintenance window to a more convenient time later, you can use [UpdateCluster API](clusters.modify.md), [update-cluster CLI](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) or click on [Modify](clusters.modify.md) in the MemoryDB Management Console. Once you change your maintenance window, MemoryDB will schedule your node for maintenance during the newly specified window.
To see how this works in practice, let's say it's currently Thursday 11/09 at 1500 and the next maintenance window is Friday, 11/10, at 1700. Here are 3 scenarios:
+ You change your maintenance window to Friday at 1600 (after the current date time and before the next scheduled maintenance window). The node will be replaced on Friday, 11/10, at 1600.
+ You change your maintenance window to Saturday at 1600 (after the current date time and after the next scheduled maintenance window). The node will be replaced on Saturday, 11/11, at 1600.
+ You change your maintenance window to Wednesday at 1600 (earlier in the week than the current date time). The node will be replaced next Wednesday, 11/15, at 1600.
For more information, see [Managing maintenance](maintenance-window.md).
Please note that the nodes in different clusters from different regions can be replaced at the same time providing that your maintenance window for these clusters is configured to be the same.
**How do I find out about upcoming scheduled replacements?** - You should get health notification on the AWS health Dashboard. Also you can find the status of different services upgrades with DescribeServiceUpdates API. Please note that we put all the efforts to proactively notify customers about foreseeable replacements. However, in exceptional cases like unpredictable failures, there may be unannounced replacements.
**Can I change the scheduled maintenance at a more suitable time?** - Yes, you can defer the scheduled maintenance to a more suitable time by changing the [maintenance window](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html).
**Why are you doing these node replacements?** - These replacements are needed to apply mandatory software updates to your underlying host. The updates help strengthen our security, reliability, and operational performance.
**Do these replacements affect my nodes in Multiple Availability Zones and clusters from different regions at the same time?** - Replacements can run in multiple Availability Zones or regions in parallel, depending on the maintenance window for clusters.
# Applying the service updates
You can start applying the service updates to your fleet from the time that the updates have an **available** status. Service updates are cumulative. In other words, any updates that you haven't applied yet are included with your latest update.
If a service update has auto-update enabled, you can choose to not take any action when it becomes available. MemoryDB will schedule to apply the update during your clusters' maintenance window after the **Auto-update start date**. You will receive related notifications for each stage of the update.
**Note**
You can apply only those service updates that have an **available** or **scheduled** status.
For more information about reviewing and applying any service-specific updates to applicable MemoryDB clusters, see [Applying the service updates using the console](#applying-updates-console-APIReferenceconsole).
When a new service update is available for one or more of your MemoryDB clusters, you can use the MemoryDB console, API, or AWS CLI to apply the update. The following sections explain the options that you can use to apply updates.
## Applying the service updates using the console
To view the list of available service updates, along with other information, go to the **Service Updates** page in the 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. On the navigation pane, choose **Service Updates**.
Under **Service update details** you can view the following:
+ **Service update name**: The unique name of the service update
+ **Update description**: Detailed information about the service update
+ **Auto-update start date**: If this attribute is set, MemoryDB will start scheduling your clusters to be auto-updated in the appropriate maintenance windows after this date. You will receive notifications in advance on the exact scheduled maintenance window, which might not be the immediate one after the **Auto-update start date**. You can still apply the update to your clusters any time you choose. If the attribute is not set, the service update is not auto-update enabled and MemoryDB will not update your clusters automatically.
In the **Cluster update status** section, you can view a list of clusters where the service update has not been applied or has just been applied recently. For each cluster, you can view the following:
+ **Cluster name**: The name of the cluster
+ **Nodes updated:** The ratio of individual nodes within a specific cluster that were updated or remain available for the specific service update.
+ **Update Type**: The type of the service update, which is one of **security-update** or **engine-update**
+ **Status**: The status of the service update on the cluster, which is one of the following:
+ *available*: The update is available for the requisite cluster.
+ *in-progres*: The update is being applied to this cluster.
+ *scheduled*: The update date has been scheduled.
+ *complete*: The update has been successfully applied. Cluster with a complete status will be displayed for 7 days after its completion.
If you chose any or all of the clusters with the **available** or **scheduled** status, and then chose **Apply now**, the update will start being applied on those clusters.
## Applying the service updates using the AWS CLI
After you receive notification that service updates are available, you can inspect and apply them using the AWS CLI:
+ To retrieve a description of the service updates that are available, run the following command:
`aws memorydb describe-service-updates --status available`
For more information, see [describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html).
+ To apply a service update on a list of clusters, run the following command:
`aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`
For more information, see [batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html).