Amazon MemoryDB Multi-Region is now generally available

Providing highly available applications while maintaining low latency reads and writes across AWS Regions is a common challenge faced by many customers. Accessing data from different Regions can cause a delay of hundreds of milliseconds compared to microseconds within the same Region. The necessity for developers to create complex custom solutions for data replication and conflict resolution can lead to increased operational workload and potential errors. Beyond multi-Region replication, these customers have to implement manual database failover procedures and provide data consistency and recovery to deliver highly available applications and data durability.

Today, Amazon Web Services (AWS) announced the general availability of Amazon MemoryDB Multi-Region, a fully managed, active-active, multi-Region database that you can use to build applications with up to 99.999 percent availability, microsecond read, and single-digit millisecond write latencies across multiple AWS Regions. MemoryDB Multi-Region is available for Valkey, which is a Redis Open Source Software (OSS) drop-in replacement stewarded by Linux Foundation. This new feature builds upon the existing benefits of Amazon MemoryDB, such as multi-AZ durability and high throughput across multiple AWS Regions, and addresses these common challenges faced by many customers.

In this post, we discuss the benefits of MemoryDB Multi-Region and demonstrate how to get started with it using the AWS Management Console and the AWS Command Line Interface (AWS CLI).

Benefits of MemoryDB Multi-Region

MemoryDB Multi-Region provides the following benefits to customers:

  • High availability and disaster recovery – With MemoryDB Multi-Region, you can build applications with up to 99.999 percent availability. It also makes sure that if an application is unable to connect to MemoryDB in a local Region, the application can connect to MemoryDB from another AWS Regional endpoint with full read and write access to the data. When the application reconnects to the original MemoryDB Regional endpoint, MemoryDB Multi-Region will automatically synchronize data across all AWS Regions.
  • Microsecond read and single-digit millisecond write latency for multi-Region distributed applications – MemoryDB Multi-Region offers active-active replication, so you can serve both reads and writes locally from the Regions closest to your customers with microsecond read and single-digit millisecond write latency at any scale. It automatically replicates data asynchronously between AWS Regions with data typically propagated in less than one second.
  • Adhere to compliance and regulatory requirements where data needs to reside in a specific geography – There are compliance and regulatory requirements under which data needs to be within a geographic location. MemoryDB Multi-Region can help you meet these requirements as it allows customers to choose which region they want their data to reside.

Getting started with Amazon MemoryDB Multi-Region

Setting up MemoryDB Multi-Region is straightforward and can be accomplished through the AWS Management Console, AWS SDK, or AWS CLI.

Getting started with MemoryDB Multi-Region using the console

To set up your MemoryDB Multi-Region cluster using the console, complete the following steps:

On the MemoryDB console, choose Clusters in the navigation pane, choose Create cluster, select Multi-Region cluster for Cluster type, and Create new cluster for the Cluster creation method.

started with console

You can select the Node type and number of shards based on your workload requirement when you set up your Multi-Region cluster.

Create the Regional cluster within your Multi-Region cluster with the appropriate cluster settings.

You can add a second Regional cluster to your Multi-Region cluster by choosing Add AWS region after the Multi-Region cluster and the first Regional cluster are set up.

When the cluster creation workflow finishes successfully, you can observe that there are two Regional clusters within the Multi-Region cluster.

Here are the steps to get started using the AWS CLI

To begin, create a new MemoryDB Multi-Region cluster:

aws memorydb create-multi-region-cluster \
--multi-region-cluster-name-suffix testmrrlp \
--description "testdescription" \
--node-type db.r7g.xlarge \
--region us-east-1

Next, create a Regional cluster in the Multi-Region cluster:

aws memorydb create-cluster \
--cluster-name testmrrlp-member1 \
--multi-region-cluster-name ldgnf-testmrrlp \
--node-type db.r7g.xlarge \
--num-replicas-per-shard 1 \
--snapshot-retention-limit 10 \
--acl-name open-access \
--region us-east-1

After verifying the successful creation of the first cluster, create the second cluster in a different Region:

aws memorydb create-cluster \
--cluster-name testmrrlp-member2 \
--multi-region-cluster-name ldgnf-testmrrlp \
--node-type db.r7g.xlarge \
--num-replicas-per-shard 1 \
--snapshot-retention-limit 10 \
--acl-name open-access \
--region eu-central-1

Check the status of the Multi-Region cluster:

aws memorydb describe-multi-region-clusters \
--multi-region-cluster-name ldgnf-testmrrlp \
--region us-east-1 \
--show-member-cluster-details

Now available

Amazon MemoryDB Multi-Region is available for Valkey and in the following AWS Regions: US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Mumbai, Seoul, Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland, London).

To learn more, visit the MemoryDB features page and documentation. For pricing, refer to Amazon MemoryDB pricing.

Betty


Blog Article: Here

  • Related Posts

    OpenAI’s latest o1 model now available in GitHub Copilot and GitHub Models

    The December 17 release of OpenAI’s o1 model is now available in GitHub Copilot and GitHub Models, bringing advanced coding capabilities to your workflows.

    The post OpenAI’s latest o1 model now available in GitHub Copilot and GitHub Models appeared first on The GitHub Blog.

    Inside the research: How GitHub Copilot impacts the nature of work for open source maintainers

    An interview with economic researchers analyzing the causal effect of GitHub Copilot on how open source maintainers work.

    The post Inside the research: How GitHub Copilot impacts the nature of work for open source maintainers appeared first on The GitHub Blog.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You Missed

    Announcing CodeQL Community Packs

    60 of our biggest AI announcements in 2024

    60 of our biggest AI announcements in 2024

    Our remedies proposal in DOJ’s search distribution case

    Our remedies proposal in DOJ’s search distribution case

    How Chrome’s Autofill can drive more conversions at checkout

    How Chrome’s Autofill can drive more conversions at checkout

    The latest AI news we announced in December

    The latest AI news we announced in December

    OpenAI’s latest o1 model now available in GitHub Copilot and GitHub Models

    OpenAI’s latest o1 model now available in GitHub Copilot and GitHub Models