Choosing regions and availability zones for ElastiCache
You can provide additional scalability and reliability to your ElastiCache clusters by designating Regions and Availability Zones using the corresponding endpoint.
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 ElastiCache 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 Supported Regions & endpoints.
Regions and Availability Zones
Topics
Availability Zone considerations with Memcached
Distributing your Memcached nodes over multiple Availability Zones within a region helps protect you from the impact of a catastrophic failure, such as a power loss within an Availability Zone.
Serverless Caching
ElastiCache serverless caching creates a highly available cache that spans multiple Availability Zones. You can specify subnets from different availability zones and same VPC as you create your serverless cluster or ElastiCache will choose subnets automatically from your default VPC.
Designing your own ElastiCache (Memcached) cluster
A Memcached cluster can have up to 300 nodes. When you create or add nodes to your Memcached cluster, you can specify a single Availability Zone for all your nodes, allow ElastiCache to choose a single Availability Zone for all your nodes, specify the Availability Zones for each node, or allow ElastiCache to choose an Availability Zone for each node. New nodes can be created in different Availability Zones as you add them to an existing Memcached cluster. Once a cache node is created, its Availability Zone cannot be modified.
If you want a cluster in a single Availability Zone cluster to have its nodes distributed across multiple Availability Zones, ElastiCache can create new nodes in the various Availability Zones. You can then delete some or all of the original cache nodes. We recommend this approach.
To migrate Memcached nodes from a single Availability Zone to multiple availability zones
Modify your cluster by creating new cache nodes in the Availability Zones where you want them. In your request, do the following:
Set
AZMode(CLI:- -az-mode) tocross-az.Set
NumCacheNodes(CLI:- -num-cache-nodes) to the number of currently active cache nodes plus the number of new cache nodes you want to create.Set
NewAvailabilityZones(CLI:- -new-availability-zones) to a list of the zones you want the new cache nodes created in. To let ElastiCache determine the Availability Zone for each new node, don't specify a list.-
Set
ApplyImmediately(CLI:- -apply-immediately) to true.
Note
If you are not using auto discovery, be sure to update your client application with the new cache node endpoints.
Before moving on to the next step, be sure the Memcached nodes are fully created and available.
Modify your cluster by removing the nodes you no longer want in the original Availability Zone. In your request, do the following:
Set
NumCacheNodes(CLI:- -num-cache-nodes) to the number of active cache nodes you want after this modification is applied.Set
CacheNodeIdsToRemove(CLI:- -nodes-to-remove) to a list of the cache nodes you want to remove from the cluster.The number of cache node IDs listed must equal the number of currently active nodes minus the value in
NumCacheNodes.(Optional) Set
ApplyImmediately(CLI:- -apply-immediately) to true.If you don't set
ApplyImmediately(CLI:- -apply-immediately) to true, the node deletions will take place at your next maintenance window.
Locating your nodes
Amazon ElastiCache supports locating all of a cluster's nodes in a single or multiple Availability Zones (AZs). Further, if you elect to locate your nodes in multiple AZs (recommended), ElastiCache enables you to either choose the AZ for each node, or allow ElastiCache to choose them for you.
By locating the nodes in different AZs, you eliminate the chance that a failure, such as a power outage, in one AZ will cause your entire system to fail. Testing has demonstrated that there is no significant latency difference between locating all nodes in one AZ or spreading them across multiple AZs.
You can specify an AZ for each node when you create a cluster or by adding nodes when you modify an existing cluster. For more information, see the following:
Supported Regions & endpoints
Amazon ElastiCache is available in multiple AWS Regions. This means that you can launch ElastiCache 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.
Each Region is designed to be completely isolated from the other Regions. Within each Region are multiple Availability Zones (AZ).
ElastiCache Serverless caches automatically replicate data across multiple availability zones
(except us-west-1, where data is replicated in two availability zones) for high availability.
When designing your own ElastiCache cluster, you can choose to launch your nodes in different AZs to achieve fault tolerance.
For more information on Regions and Availability Zones, see
Choosing regions and availability zones for ElastiCache at the top of this topic.
| Region Name/Region | Endpoint | Protocol |
|---|---|---|
US East (Ohio) Region
|
|
HTTPS |
US East (N. Virginia) Region
|
|
HTTPS |
US West (N. California) Region
|
|
HTTPS |
US West (Oregon) Region
|
|
HTTPS |
Canada (Central) Region
|
|
HTTPS |
Canada (West) Region
|
|
HTTPS |
Asia Pacific (Jakarta)
|
|
HTTPS |
Asia Pacific (Mumbai) Region
|
|
HTTPS |
Asia Pacific (Hyderabad) Region
|
|
HTTPS |
Asia Pacific (Tokyo) Region
|
|
HTTPS |
Asia Pacific (Seoul) Region
|
|
HTTPS |
Asia Pacific (Osaka) Region
|
|
HTTPS |
Asia Pacific (Singapore) Region
|
|
HTTPS |
Asia Pacific (Sydney) Region
|
|
HTTPS |
Europe (Frankfurt) Region
|
|
HTTPS |
Europe (Zurich) Region
|
|
HTTPS |
Europe (Stockholm) Region
|
|
HTTPS |
Middle East (Bahrain) Region
|
|
HTTPS |
Middle East (UAE) Region
|
|
HTTPS |
Europe (Ireland) Region
|
|
HTTPS |
Europe (London) Region
|
|
HTTPS |
EU (Paris) Region
|
|
HTTPS |
Europe (Milan) Region
|
|
HTTPS |
Europe (Spain) Region
|
|
HTTPS |
South America (São Paulo) Region
|
|
HTTPS |
China (Beijing) Region
|
|
HTTPS |
China (Ningxia) Region
|
|
HTTPS |
Asia Pacific (Hong Kong) Region
|
|
HTTPS |
Africa (Cape Town) Region
|
|
HTTPS |
Israel (Tel Aviv) Region
|
|
HTTPS |
|
AWS GovCloud (US-West)
|
elasticache.us-gov-west-1.amazonaws.com |
HTTPS |
|
AWS GovCloud (US-East)
|
elasticache.us-gov-east-1.amazonaws.com |
HTTPS |
For information on using the AWS GovCloud (US) with ElastiCache, see Services in the AWS GovCloud (US) region: ElastiCache. |
||
Some regions support a subset of node types. For a table of supported node types by AWS Region, see Supported node types by AWS Region.
For a table of AWS products and services by region,
see Products and Services by Region
