# What is MemoryDB
Amazon MemoryDB is a durable, in-memory database service that delivers ultra-fast performance. It is purpose-built for modern applications with microservices architectures.
Amazon MemoryDB is compatible with the popular open source data stores Valkey and Redis OSS, enabling you to quickly build applications using the same flexible and friendly data structures, APIs, and commands that they already use. With MemoryDB, all of your data is stored in memory, which enables you to achieve microsecond read and single-digit millisecond write latency and high throughput. MemoryDB also stores data durably across multiple Availability Zones (AZs) using a Multi-AZ transactional log to enable fast failover, database recovery, and node restarts.
Delivering both in-memory performance and Multi-AZ durability, MemoryDB can be used as a high-performance primary database for your microservices applications, eliminating the need to separately manage both a cache and durable database.
**Topics**
+ [Features of MemoryDB](servicename-feature-overview.md)
+ [MemoryDB core components](components.md)
+ [Related services](related-services-choose-between-memorydb-and-redis.md)
+ [Choosing Regions and Availability Zones](regionsandazs.md)
+ [Accessing MemoryDB](nodes-connecting.md)
+ [MemoryDB security](memorydb-security.md)
# Features of MemoryDB
Amazon MemoryDB is a durable, in-memory database service that delivers ultra-fast performance. Features of MemoryDB include:
+ Strong consistency for primary nodes and guaranteed eventual consistency for replica nodes. For more information, see [Consistency](consistency.md).
+ Microsecond read and single-digit millisecond write latencies with up to 160 million TPS per cluster.
+ Flexible and friendly Valkey and Redis OSS data structures and APIs. Easily build new applications or migrate existing Valkey-based and Redis OSS-based applications with almost no modification.
+ Data durability using a Multi-AZ transactional log providing fast database recovery and restart.
+ Multi-AZ availability with automatic failover, and detection of and recovery from node failures.
+ Easily scale horizontally by adding and removing nodes or vertically by moving to larger or smaller node types. You can scale write throughput by adding shards and scale read throughput by adding replicas.
+ Read-after-write consistency for primary nodes and guaranteed eventual consistency for replica nodes.
+ MemoryDB supports encryption in transit, encryption at rest and authentication of users via [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md).
+ Automatic snapshots in Amazon S3 with retention for up to 35 days.
+ Support for up to 500 nodes and more than 100 TB of storage per cluster (with 1 replica per shard).
+ Encryption in-transit with TLS and encryption at-rest with AWS KMS keys.
+ User authentication and authorization with Valkey and Redis OSS [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md).
+ Support for AWS Graviton2 instance types.
+ Integration with other AWS services such as CloudWatch, Amazon VPC, CloudTrail, and Amazon SNS for monitoring, security, and notifications.
+ Fully-managed software patching and upgrades.
+ AWS Identity and Access Management (IAM) integration and tag-based access control for management APIs.
# MemoryDB core components
Following, you can find an overview of the major components of a MemoryDB deployment.
**Topics**
+ [Clusters](#whatis.clusters)
+ [Nodes](#whatis.components.nodes)
+ [Shards](#whatis.components.Shards)
+ [Parameter groups](#whatis.components.parametergroups)
+ [Subnet Groups](#whatis.components.subnetgroups)
+ [Access Control Lists](#whatis.components.acls)
+ [Users](#whatis.components.user)
## Clusters
A cluster is a collection of one or more nodes serving a single dataset. A MemoryDB dataset is partitioned into shards, and each shard has a primary node and up to 5 optional replica nodes. A primary node serves read and write requests, while a replica only serves read requests. A primary node can failover to a replica node, promoting that replica to the new primary node for that shard. MemoryDB runs Valkey or Redis OSS as its database engine, and when you create a cluster, you specify the engine version for your cluster. You can create and modify a cluster using the AWS CLI, the MemoryDB API, or the AWS Management Console.
Each MemoryDB cluster runs a Valkey or Redis OSS engine version. Each engine version has its own supported features. Additionally, each engine version has a set of parameters in a parameter group that control the behavior of the clusters that it manages.
The computation and memory capacity of a cluster is determined by its node type. You can select the node type that best meets your needs. If your needs change over time, you can change node types. For information, see [Supported node types](nodes.supportedtypes.md).
**Note**
For pricing information on MemoryDB node types, see [MemoryDB pricing](https://aws.amazon.com/memorydb/pricing/).
You run a cluster on a virtual private cloud (VPC) using the Amazon Virtual Private Cloud (Amazon VPC) service. When you use a VPC, you have control over your virtual networking environment. You can choose your own IP address range, create subnets, and configure routing and access control lists. MemoryDB manages snapshots, software patching, automatic failure detection, and recovery. There's no additional cost to run your cluster in a VPC. For more information on using Amazon VPC with MemoryDB, see [MemoryDB and Amazon VPC](vpcs.md).
Many MemoryDB operations are targeted at clusters:
+ Creating a cluster
+ Modifying a cluster
+ Taking snapshots of a cluster
+ Deleting a cluster
+ Viewing the elements in a cluster
+ Adding or removing cost allocation tags to and from a cluster
For more detailed information, see the following related topics:
+ [Managing clusters](clusters.md) and [Managing nodes](nodes.md)
Information about clusters, nodes, and related operations.
+ [Resilience in MemoryDB](disaster-recovery-resiliency.md)
Information about improving the fault tolerance of your clusters.
## Nodes
A *node* is the smallest building block of a MemoryDB deployment and runs using an Amazon EC2 instance. Each node runs the engine version that was chosen when you created your cluster. A node belongs to a shard which belongs to a cluster.
Each node runs an instance of the engine at the version chosen when you created your cluster. If necessary, you can scale the nodes in a cluster up or down to a different type. For more information, see [Scaling](scaling.md).
Every node within a cluster is the same node type. Multiple types of nodes are supported, each with varying amounts of memory. For a list of supported node types, see [Supported node types](nodes.supportedtypes.md).
For more information on nodes, see [Managing nodes](nodes.md).
## Shards
A shard is a grouping of one to 6 nodes, with one serving as the primary write node and the other 5 serving as read replicas. A MemoryDB cluster always has at least one shard.
MemoryDB clusters can have up to 500 shards, with your data partitioned across the shards. For example, you can choose to configure a 500 node cluster that ranges between 83 shards (one primary and 5 replicas per shard) and 500 shards (single primary and no replicas). Make sure there are enough available IP addresses to accommodate the increase. Common pitfalls include the subnets in the subnet group have too small a CIDR range or the subnets are shared and heavily used by other clusters.
A *multiple node shard* implements replication by having one read/write primary node and 1–5 replica nodes. For more information, see [Understanding MemoryDB replication](replication.md).
For more information on shards, see [Working with shards](shards.md).
## Parameter groups
Parameter groups are an easy way to manage runtime settings for the engine on your cluster. Parameters are used to control memory usage, item sizes, and more. A MemoryDB parameter group is a named collection of engine-specific parameters that you can apply to a cluster, and all of the nodes in that cluster are configured in exactly the same way.
For more detailed information on MemoryDB parameter groups, see [Configuring engine parameters using parameter groups](parametergroups.md).
## 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.
For more detailed information on MemoryDB subnet groups, see [Subnets and subnet groups](subnetgroups.md).
## Access Control Lists
An Access control list is a collection of one or more users. Access strings follow the [ACL rules](https://valkey.io/topics/acl) to authorize user access to Valkey or Redis OSS commands and data.
For more detailed information on MemoryDB Access Control Lists, see [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md).
## Users
A user has a user name and password, and is used to access data and issue commands on your MemoryDB cluster. A user is a member of an Access Control List (ACL), which you can use to determine permissions for that user on MemoryDB clusters. For more information, see [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md)
# Related services
[ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/whatis.html)
When deciding whether to use MemoryDB or ElastiCache consider the following comparisons:
+ MemoryDB is a durable, in-memory database for workloads that require an ultra-fast, primary database. You should consider using MemoryDB if your workload requires a durable database that provides ultra-fast performance (microsecond read and single-digit millisecond write latency). MemoryDB may also be a good fit for your use case if you want to build an application using Valkey or Redis OSS data structures and APIs with a primary, durable database. Finally, you should consider using MemoryDB to simplify your application architecture and lower costs by replacing usage of a database with a cache for durability and performance.
+ ElastiCache is a service that is commonly used to cache data from other databases and data stores using Valkey and Redis OSS. You should consider ElastiCache for caching workloads where you want to accelerate data access with your existing primary database or data store (microsecond read and write performance). You should also consider ElastiCache for use cases where you want to use the Valkey or Redis OSS data structures and APIs to access data stored in a primary database or data store.
# Choosing Regions and Availability Zones
AWS Cloud computing resources are housed in highly available data center facilities. To provide additional scalability and reliability, these data center facilities are located in different physical locations. These locations are categorized by *regions* and *Availability Zones*.
AWS Regions are large and widely dispersed into separate geographic locations. Availability Zones are distinct locations within an AWS Region that are engineered to be isolated from failures in other Availability Zones. They provide inexpensive, low-latency network connectivity to other Availability Zones in the same AWS Region.
**Important**
Each region is completely independent. Any MemoryDB activity you initiate (for example, creating clusters) runs only in your current default region.
To create or work with a cluster in a specific region, use the corresponding regional service endpoint. For service endpoints, see [MemoryDB Multi-Region](multi-region.md).
With MemoryDB Multi-Region, you can improve both availability and resiliency while also benefiting from low latency local reads and writes for Multi-Region applications. For information on working with MemoryDB Multi-Region, see [Supported Regions & endpoints](#supportedregions).
## Locating your nodes
Any cluster that has at least one replica must be spread across AZs. The only way you can locate everything within a single AZ is with a cluster comprised of single-node shards.
By locating the nodes in different AZs, MemoryDB eliminates the chance that a failure, such as a power outage, in one AZ will cause loss of availability.
+ [Creating a MemoryDB cluster](getting-started.md#clusters.create)
+ [Modifying a MemoryDB cluster](clusters.modify.md)
## Supported Regions & endpoints
MemoryDB is available in multiple AWS Regions. This means that you can launch MemoryDB clusters in locations that meet your requirements. For example, you can launch in the AWS Region closest to your customers, or launch in a particular AWS Region to meet certain legal requirements. In addition, as MemoryDB expands availability to a new AWS Region, MemoryDB supports the two most recent `MAJOR.MINOR` versions at that time for the new Region. For more information on MemoryDB versions, see [Engine versions](engine-versions.md).
By default, the AWS SDKs, AWS CLI, MemoryDB API, and MemoryDB console reference the US-East (N. Virginia) Region. As MemoryDB expands availability to new regions, new endpoints for these regions are also available to use in your HTTP requests, the AWS SDKs, AWS CLI, and the console.
Each Region is designed to be completely isolated from the other Regions. Within each region are multiple Availability Zones (AZ). By launching your nodes in different AZs you achieve the greatest possible fault tolerance. For more information on regions and Availability Zones, see [Choosing Regions and Availability Zones](#regionsandazs) at the beginning of this topic.
**Regions where MemoryDB is supported**
| Region Name/Region | Endpoint | Protocol |
| --- | --- | --- |
| US East (Ohio) Region `us-east-2` | `memory-db.us-east-2.amazonaws.com` | HTTPS |
| US East (N. Virginia) Region `us-east-1` | `memory-db.us-east-1.amazonaws.com` | HTTPS |
| US West (N. California) Region `us-west-1` | `memory-db.us-west-1.amazonaws.com` | HTTPS |
| US West (Oregon) Region `us-west-2` | `memory-db.us-west-2.amazonaws.com` | HTTPS |
| Canada (Central) Region `ca-central-1` | `memory-db.ca-central-1.amazonaws.com` | HTTPS |
| Asia Pacific (Hong Kong) Region `ap-east-1` | `memory-db.ap-eastl-1.amazonaws.com` | HTTPS |
| Asia Pacific (Mumbai) Region `ap-south-1` | `memory-db.ap-south-1.amazonaws.com` | HTTPS |
| Asia Pacific (Tokyo) Region `ap-northeast-1` | `memory-db.ap-northeast-1.amazonaws.com` | HTTPS |
| Asia Pacific (Seoul) Region `ap-northeast-2` | `memory-db.ap-northeast-2.amazonaws.com` | HTTPS |
| Asia Pacific (Singapore) Region `ap-southeast-1` | `memory-db.ap-southeast-1.amazonaws.com` | HTTPS |
| Asia Pacific (Sydney) Region `ap-southeast-2` | `memory-db.ap-southeast-2.amazonaws.com` | HTTPS |
| Europe (Frankfurt) Region `eu-central-1` | `memory-db.eu-central-1.amazonaws.com` | HTTPS |
| Europe (Ireland) Region `eu-west-1` | `memory-db.eu-west-1.amazonaws.com` | HTTPS |
| Europe (London) Region `eu-west-2` | `memory-db.eu-west-2.amazonaws.com` | HTTPS |
| EU (Paris) Region `eu-west-3` | `memory-db.eu-west-3.amazonaws.com` | HTTPS |
| Europe (Stockholm) Region `eu-north-1` | `memory-db.eu-north-1.amazonaws.com` | HTTPS |
| Europe (Milan) Region `eu-south-1` | `memory-db.eu-south-1.amazonaws.com` | HTTPS |
| Europe (Spain) Region `eu-south-2` | `memory-db.eu-south-2.amazonaws.com` | HTTPS |
| South America (São Paulo) Region `sa-east-1` | `memory-db.sa-east-1.amazonaws.com` | HTTPS |
| China (Beijing) Region `cn-north-1` | `memory-db---cn-north-1.amazonaws.com.rproxy.goskope.com.cn` | HTTPS |
| China (Ningxia) Region `cn-northwest-1` | `memory-db---cn-northwest-1.amazonaws.com.rproxy.goskope.com.cn` | HTTPS |
For a table of AWS products and services by region, see [Products and services by Region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
For a table of supported Availability Zones within Regions, see [Subnets and subnet groups](subnetgroups.md).
# Accessing MemoryDB
Each MemoryDB cluster endpoint contains an address and a port. This cluster endpoint supports the Valkey and Redis OSS Cluster protocol to allow clients to discover the specific roles, ip addresses and slots for each node in the cluster. When a primary node fails and a replica is promoted in its place, you can connect to cluster endpoint to discover the new primary using the Valkey or Redis OSS Cluster protocol.
You need to connect to the cluster endpoint to discover node endpoints using **cluster nodes** or **cluster slots** command. After discovering the right node for a key, you can connect directly to the node for read/write requests. A Valkey or Redis OSS client can use the cluster endpoint to automatically connect to the correct node.
To troubleshoot specific nodes in a cluster, you can also use node-specific endpoints, but these are not necessary for normal usage.
To find a cluster's endpoint, see the following:
+ [Finding the Endpoint for a MemoryDB Cluster (AWS CLI)](endpoints.md#endpoints.find.cli)
+ [Finding the Endpoint for a MemoryDB Cluster (MemoryDB API)](endpoints.md#endpoints.find.api)
For connecting to nodes or clusters, see [Connecting to MemoryDB nodes using redis-cli](getting-started.md#connect-tls).
# MemoryDB security
Security for MemoryDB is managed at three levels:
+ To control who can perform management actions on MemoryDB clusters and nodes, you use AWS Identity and Access Management (IAM). When you connect to AWS using IAM credentials, your AWS account must have IAM policies that grant the permissions required to perform operations. For more information, see [Identity and access management in MemoryDB](iam.md)
+ To control access levels to clusters, you create users with specified permissions and assign them to the Access Control Lists (ACL). The ACL, in turn, is then associated with one or more clusters. For more information, see [Authenticating users with Access Control Lists (ACLs)](clusters.acls.md).
+ MemoryDB clusters must be created in a virtual private cloud (VPC) based on the Amazon VPC service. To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the node for MemoryDB clusters in a VPC, you use a VPC security group. You can make these endpoint and port connections using Transport Layer Security (TLS)/Secure Sockets Layer (SSL). In addition, firewall rules at your company can control whether devices running at your company can open connections to a MemoryDB cluster. For more information on VPCs, see [MemoryDB and Amazon VPC](vpcs.md).
For information about configuring security, see [Security in MemoryDB](security.md).