Database | Amazon ElastiCache for Redis Flashcards

Question

What happens to read replicas if failover occurs? Read Replica Amazon ElastiCache for Redis | Database

Answer 1

In the event of a failover, any associated and available read replicas should automatically resume replication once failover has completed (acquiring updates from the newly promoted read replica).

Answer 2

Creating a read replica of another read replica is not supported.

Answer 3

No, this is not supported. Instead, you may snapshot your ElastiCache for Redis node (you may select the primary or any of the read-replicas). You can then use the snapshot to seed a new ElastiCache for Redis primary.

Answer 4

Updates to a primary node will automatically be replicated to any associated read replicas. However, with Redis’s asynchronous replication technology, a read replica can fall behind its primary cache node for a variety of reasons. Typical reasons include: Write I/O volume to the primary cache node exceeds the rate at which changes can be applied to the read replica Network partitions or latency between the primary cache node and a read replica Read replicas are subject to the strengths and weaknesses of Redis replication. If you are using read replicas, you should be aware of the potential for lag between a read replica and its primary cache node, or "inconsistency". You can monitor such lag potentially occuring via the "Replication Lag" CloudWatch metric, accessible through both the ElastiCache console and API, as well as those of the CloudWatch service.

Answer 5

You can use the standard DescribeCacheClusters API to return a list of all the cache clusters you have deployed (including read replicas), or simply click on the "Redis" tab of the Amazon ElastiCache Management Console. Amazon ElastiCache monitors the replication status of your read replicas and updates the Replication State field to Error if replication stops for any reason. You can review the details of the associated error thrown by the Redis engine by viewing the Replication Error field and take an appropriate action to recover from it. You can learn more about troubleshooting replication issues in the Troubleshooting a Read Replica problem section of the Amazon ElastiCache User Guide. If a replication error is fixed, the Replication State changes to Replicating. Amazon ElastiCache allows you to gain visibility into how far a read replica has fallen behind its primary through the Amazon CloudWatch metric ("Replica Lag") available via the AWS Management Console or Amazon CloudWatch APIs.

Answer 6

As discussed in the previous questions, "inconsistency" or lag between a read replica and its primary node is common with Redis asynchronous replication. If an existing read replica has fallen too far behind to meet your requirements, you can reboot it. Keep in mind that replica lag may naturally grow and shrink over time, depending on your primary node’s steady-state usage pattern.

Answer 7

You can easily delete a read replica with a few clicks of the AWS Management Console or by passing its cache cluster identifier to the DeleteCacheCluster API. If you want to delete the read replica in addition to the primary cache node, you must use the DeleteReplicationGroup API or AWS Management Console.

Answer 8

A read replica is billed as a standard node and at the same rates. Just like a standard node, the rate per "Node hour" for a read replica is determined by the node class of the read replica – please see Amazon ElastiCache detail page for up-to-date pricing. You are not charged for the data transfer incurred in replicating data between your primary cache node and read replica. Billing for a read replica begins as soon as the read replica has been successfully created (i.e. when status is listed as "active"). The read replica will continue being billed at standard Amazon ElastiCache cache node hour rates until you issue a command to delete it.

Answer 9

Initiated failover is supported by Amazon ElastiCache so that you can resume operations as quickly as possible. When failing over, Amazon ElastiCache simply flips the DNS record for your node to point at the read replica, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement cache node connection retry at the application layer. Start-to-finish, failover typically completes within three to six minutes.

Answer 10

No. Your read replica may only be provisioned in the same or different Availability Zone of the same Region as your cache node primary.

Answer 11

Yes, you can gain visibility into the location of the current primary by using the AWS Management Console or DescribeCacheClusters API. After failover, my primary is now located in a different Availability Zone than my other AWS resources (e.g. EC2 instances).

Answer 12

Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same Region. In addition, you may want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone failure.

Answer 13

An ElastiCache for Redis shard consists of a primary and up to five read replicas. Redis asynchronously replicates the data from the primary to the read replicas. During certain types of planned maintenance, or in the unlikely event of ElastiCache node failure or Availability Zone failure, Amazon ElastiCache will automatically detect the failure of a primary, select a read replica, and promote it to become the new primary. ElastiCache also propagates the DNS changes of the promoted read replica, so if your application is writing to the primary node endpoint, no endpoint change will be needed.

Answer 14

The main benefits of running your ElastiCache for Redis in Multi-AZ mode are enhanced availability and smaller need for administration. If an ElastiCache for Redis primary node failure occurs, the impact on your ability to read/write to the primary is limited to the time it takes for automatic failover to complete. When Multi-AZ is enabled, ElastiCache node failover is automatic and requires no administration. You no longer need to monitor your Redis nodes and manually initiate a recovery in the event of a primary node disruption.

Answer 15

You can use Multi-AZ if you are using ElastiCache for Redis and have a shard consisting of a primary node and one or more read replicas. If the primary node fails, ElastiCache will automatically detect the failure, select one from the available read replicas, and promote it to become the new primary. When cluster\_mode parameter is disabled, ElastiCache will propagate the DNS changes of the promoted replica so that your application can keep writing to the primary endpoint. For cluster\_mode enabled, ElastiCache will update the node map of the cluster. ElastiCache will also spin up a new node to replace the promoted read replica in the same Availability Zone of the failed primary. In case the primary failed due to temporary Availability Zone disruption, the new replica will be launched once that Availability Zone has recovered.

Answer 16

Yes. Note that placing both the primary and the replica(s) in the same Availability Zone will not make your ElastiCache for Redis replication group resilient to an Availability Zone disruption.

Answer 17

Amazon ElastiCache will failover to a read replica in the event of any of the following: Loss of availability in primary’s Availability Zone Loss of network connectivity to primary Compute unit failure on primary

Answer 18

Using Redis replication in conjunction with Multi-AZ provides increased availability and fault tolerance. Such deployments are a natural fit for use in production environments. When running ElastiCache for Redis Cluster with cluster mode enabled, if your shards have one or more read replicas, Multi-AZ will automatically be enabled.

Answer 19

You can create an ElastiCache for Redis primary and read replicas by clicking "Create" on the ElastiCache Management Console. You can also do so by calling the CreateReplicationGroup API. For existing clusters (Redis 2.8.6, 2.8.19, 2.8.21, 2.8.22, 2.8.23, 2.8.24 and 3.2.4 with cluster\_mode=disabled), you can enable Multi-AZ by choosing a cluster and clicking Modify on the ElastiCache Management Console or by using the ModifyReplicationGroup API. Switching a replication group to Multi-AZ is not disruptive to your Redis data and does not interfere your nodes' ability to serve requests.

Answer 20

If there are more than one read replicas, the read replica with the smallest asynchronous replication lag to the primary will be promoted.

Answer 21

Multi-AZ is free of charge. You only pay for the ElastiCache nodes that you use.

Answer 22

ElastiCache currently uses the Redis engine’s native, asynchronous replication and is subject to its strengths and limitations. In particular, when a read replica connects to a primary for the first time, or if the primary changes, the read replica does a full synchronization of the data from the primary, imposing load on itself and the primary. For additional details regarding Redis replication please see here.

Answer 23

All available node types in ElastiCache support Multi-AZ with one exception. When using Redis 2.8.x or Redis 3.x with cluster\_mode=disabled, T2 family doesn’t support Multi-AZ.

Answer 24

Yes, Amazon ElastiCache will create an event to inform you that automatic failover occurred. You can use the DescribeEvents API to return information about events related to your ElastiCache node, or click the Events section of the ElastiCache Management Console.

Answer 25

Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same region. You may consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone disruption.

Answer 26

For more information about Multi-AZ, see ElastiCache documentation.

Answer 27

Yes. If you have the "Multi-AZ" feature enabled on a cluster or replication group with one or more read replicas, you can trigger a failover. ElastiCache will respond in the same way as a real failure scenario – by detecting the failure, promoting the most up-to-date read replica to become the new primary, and then replacing the failed primary, attaching it as a new read replica in place of the one promoted. For more details on testing failover, please see documentation.

Answer 28

Backup and Restore is a feature that allows customers to create snapshots of their ElastiCache for Redis clusters. ElastiCache stores the snapshots, allowing users to subsequently use them to restore Redis clusters.

Answer 29

A snapshot is a copy of your entire Redis cluster at a specific moment.

Answer 30

Creating snapshots can be useful in case of data loss caused by node failure, as well as the unlikely event of a hardware failure. Another common reason to use backups is for archiving purposes. Snapshots are stored in Amazon S3, which is a durable storage, meaning that even a power failure won’t erase your data.

Answer 31

You can use snapshots to warm start an ElastiCache for Redis cluster with preloaded data.

Answer 32

When a backup is initiated, ElastiCache will take a snapshot of a specified Redis cluster that can later be used for recovery or archiving. You can initiate a backup anytime you choose or set a recurring daily backup with retention period of up to 35 days. When you choose a snapshot to restore, a new ElastiCache for Redis cluster will be created and populated with the snapshot’s data. This way you can create multiple ElastiCache for Redis clusters from a specified snapshot. Currently, ElastiCache uses Redis’ native mechanism to create and store an RDB file as the snapshot.

Answer 33

The snapshots are stored in S3.

Answer 34

You can select to use the Backup and Restore feature through the AWS Management Console, through the ElastiCache APIs (CreateCacheCluster, ModifyCacheCluster and ModifyReplicationGroup API’s) and CLI. You can deactivate and reactivate the feature anytime you choose.

Answer 35

Backup and Restore creates snapshots on a cluster basis. Users can specify which ElastiCache for Redis cluster to backup through the AWS Management Console, CLI or through the CreateSnapshot API. In a Replication Group, you can choose to backup the primary or any of the read-replica clusters. We recommend users enable backup on one of the read-replicas, mitigating any latency effect on the Redis primary.

Answer 36

No, snapshots are available only for ElastiCache for Redis.

Answer 37

Through the AWS Management Console, CLI or APIs you can specify when to start a single backup or a recurring backup. Users are able to: Take a snapshot right now (through "Backup" console button in the "Redis" tab, or CreateSnapshot API) Set up an automatic daily backup. The backup will take place during your preferred backup window. You can set that up through Creating/Modifying cluster via console or the CreateCacheCluster, ModifyCacheCluster or ModifyReplicationGroup API’s.

Answer 38

The preferred backup window is the user-defined period of time during which your ElastiCache for Redis cluster backup will start. This is helpful if you want to backup at a certain time of day or to refrain from backups during a particularly high-utilization period.

Answer 39

While taking a snapshot, you may encounter increased latencies for a brief period at the node. Snapshots use Redis’s built-in BGSAVE and are subject to its strengths and limitations. In particular, the Redis process forks and the parent continues to serve requests while the child saves the data on disk and then exits. The forking increases the memory usage for the duration of the snapshot generation. When this memory usage exceeds that of the available memory of the node, swapping can get triggered, further slowing down the node. For this reason, we recommend generating snapshots on one of the read replicas (instead of the primary). Also, we suggest setting the reserved-memory parameter to minimize swap usage. See here for more details.

Answer 40

Yes. Creating a snapshot from a read replica is the best way to backup your data while minimizing performance impact.

Answer 41

Backup and Restore feature is available in all regions where ElastiCache service is available.

Answer 42

Yes. You can export your ElastiCache for Redis snapshots to an authorized S3 bucket in the same region as your cluster. For more details on exporting snapshots and setting the required permissions, please refer to this.

Answer 43

Yes. You must first copy your snapshot into an authorized S3 bucket of your choice in the same region and then use the S3 PUT object- Copy API to copy it to a bucket in another region. For more details on copying S3 objects, please see this.

Answer 44

Yes. You must first copy your snapshot into an authorized S3 bucket of your choice in the same region and then grant cross-account bucket permissions to the other account. For more details on S3 cross-account permissions, please see this. Finally, specify the S3 location of your RDB file during cluster creation through the Launch Cache Cluster Wizard in the console or through the CreateCacheCluster API.

Answer 45

Amazon ElastiCache provides storage space for one snapshot free of charge for each active ElastiCache for Redis cluster. Additional storage will be charged based on the space used by the snapshots with $0.085/GB every month (same price in all regions). Data transfer for using the snapshots is free of charge.

Answer 46

Retention period is the time span during which the automatic snapshots are retained. For example, if a retention period is set for 5, a snapshot that was taken today will be retained for 5 days before being deleted. You can choose to copy one or more automatic snapshots to store them as manual so that they won’t be deleted after the retention period is over.

Answer 47

You can use the AWS Management Console or ModifyCluster API to manage the period of time your automated backups are retained by modifying the RetentionPeriod parameter. If you desire to turn off automated backups altogether, you can do so by setting the retention period to 0 (not recommended).

Answer 48

When you delete an ElastiCache for Redis cluster, your manual snapshots are retained. You will also have an option to create a final snapshot before the cluster is deleted. Automatic snapshots are not retained.

Answer 49

All ElastiCache for Redis instance node types besides t1.micro and t2 family support backup and restore: Current Generation Nodes: cache. m3.medium cache. m3.large cache. m3.xlarge cache. m3.2xlarge cache. m4.large cache. m4.xlarge cache. m4.2xlarge cache. m4.4xlarge cache. m4.10xlarge cache. r3.large cache. r3.xlarge cache. r3.2xlarge cache. r3.4xlarge cache. r3.8xlarge cache. r4.large cache. r4.xlarge cache. r4.2xlarge cache. r4.4xlarge cache. r4.8xlarge cache. r4.16xlarge Previous Generation Nodes: cache. m1.small cache. m1.medium cache. m1.large cache. m1.xlarge cache. m2.xlarge cache. m2.2xlarge cache. m2.4xlarge cache. c1.xlarge

Answer 50

Yes. You can specify the S3 location of your RDB file during cluster creation through the "Create Cluster" Wizard in the console or through the CreateCacheCluster API.

Answer 51

ElastiCache for Redis Cluster allows customers to create and run managed Redis Clusters with multiple shards. It is compatible with open source Redis 3.2 and comes with a number of enhancements for a more stable and robust experience (see the "enhanced engine" section below for additional details on these enhancements).

Answer 52

There are three main scenarios for running a scale out Redis environment. First, if the total memory size of your Redis data exceeds or is projected to exceed the memory capacity of a single VM. Second, if the write throughput of your application to Redis exceeds the capacity of a single VM. Third, if you would like to spread the data across multiple shards so that any potential issue that comes up with a single node will have a smaller impact on the overall Redis environment.

Answer 53

Amazon ElastiCache provides a fully managed distributed in-memory Redis environment, from provisioning server resources to installing the engine software and applying any configuration parameters you choose. It uses enhancements to the Redis engine developed by Amazon, which results in a more robust and stable experience (see "enhanced engine" section for more details). Once your Redis environment is up and running, the service automates common administrative tasks such as failure detection and recovery, backups and software patching. It also provides a robust Multi-AZ solution with automatic failover. In case of a failure of one or more primary nodes in your cluster, Amazon ElastiCache will automatically detect the failure and respond by promoting the most up to date replica to primary. This process is automated and does not mandate any manual work on your behalf. Amazon ElastiCache also provides detailed monitoring metrics associated with your ElastiCache nodes, enabling you to diagnose and respond to issues very quickly.

Answer 54

Yes, Amazon ElastiCache for Redis Cluster is compatible with open source Redis 3.2. You can use the open source Redis Cluster clients to access scale-out clusters on ElastiCache for Redis.

Answer 55

Currently you cannot modify the number of shards in a cluster once it’s created.

Answer 56

If you are using Redis 3.2 with cluster\_mode parameter disabled, you can simply choose the node or cluster you wish to upgrade and modify the engine version. ElastiCache will provision a Redis 3.2.4 cluster and migrate your data to it, while maintaining the endpoint. If you are using Redis 3.2 with cluster\_mode enabled, you can migrate to Redis Cluster by first creating a snapshot of your data using the backup and restore feature. Then, select the created snapshot and click on "Restore Snapshot" to create a Redis 3.2 cluster using the snapshotted data. Finally, update the new endpoint in your client. Note that to use Redis 3.2 in cluster mode you would need to switch to a Redis Cluster client.

Answer 57

No. Amazon ElastiCache for Redis provides the flexibility of clustered and non-clustered configuration at the same price. Customers can now enjoy enhanced engine functionality within Amazon ElastiCache for Redis and use full feature support for clustered configuration and scalability at the same price.

Answer 58

Each shard of an ElastiCache for Redis cluster consists of a primary and up to five read replicas. Redis asynchronously replicates the data from the primary to the read replicas. During certain types of planned maintenance, or in the unlikely event of ElastiCache node failure or Availability Zone failure, Amazon ElastiCache will automatically detect the failure of a primary, select a read-replica, and promote it to become the new primary. ElastiCache for Redis Cluster provides enhancements and management for Redis 3.x environments. When running an unmanaged Redis environment, in a case of primary node failure, the cluster relies on a majority of masters to determine and execute a failover. If such majority doesn’t exist, the cluster will go into failed state, rejecting any further reads and writes. This could lead to major availability impact on the application, as well as requiring human intervention to manually salvage the cluster. ElastiCache for Redis Multi-AZ capability is built to handle any failover case for Redis Cluster with robustness and efficiency.

Answer 59

Redis 3.x works with intelligent clients that store a node map with all the cluster nodes’ endpoints. During a failover, the client updates the node map with the IP endpoint for the new primary. This provides up to 4x faster failover time than with ElastiCache for Redis 2.8.x.

Answer 60

You can use Multi-AZ if you are using an ElastiCache for Redis Cluster with each shard having 1 or more read-replicas. If a primary node of a shard fails, ElastiCache will automatically detect the failure, select one of the available read-replicas, and promote it to become the new primary. The Redis 3.x client will update the promoted replica as primary, no application change is required. ElastiCache will also spin up a new node to replace the promoted read-replica in the same Availability Zone of the failed primary. In case the primary failed due to a temporary Availability Zone failure, the new replica will be launched once that Availability Zone has recovered.

Answer 61

An ElastiCache for Redis Cluster backup is a series of snapshots of the cluster’s shards, stored together to keep a copy of your entire Redis data around a certain time frame.

Answer 62

Since a non-clustered ElastiCache for Redis environment has a single primary node, a backup is a single file which contains a copy of the Redis data. ElastiCache for Redis Cluster can have one or more shards, thus a backup might contain multiple files.

Answer 63

You cannot manually specify a node to backup within each shard. When initiating a backup, ElastiCache will automatically select the most up-to-date read replica in each shard and take a snapshot of its data.

Answer 64

When a backup is initiated, ElastiCache will take a backup of a specified cluster; that backup can later be used for recovery or archiving. The backup will include a copy of each of the cluster’s shards, thus a full backup contains a series of files. You can initiate a backup anytime you choose or set a recurring daily backup with retention period of up to 35 days. When you choose a backup to restore, a new ElastiCache for Redis cluster will be created and populated with the backup’s data. Also, you can use this feature for an easy migration path to a managed Redis Cluster experience on ElastiCache. If you are running self-managed Redis on EC2, you can take RDB snapshots or your existing workloads (both Redis Cluster and single-shard Redis) and store them in S3. Then simply provide them as input for creating a sharded Redis Cluster on ElastiCache, and the desired number of shards. ElastiCache will do the rest. Currently, ElastiCache uses Redis’ native mechanism to create and store an RDB file for each shard as the backup.

Answer 65

When you initiate a backup, ElastiCache will trigger backups of all of the shards of your cluster at the same time. In rare cases there might be a need to retake a snapshot of one or more nodes that did not complete successfully the first time. ElastiCache does that automatically and no user intervention is required. But in such a case, while each individual snapshot is a point-in-time representation of the node it was taken from, not all the cluster’s snapshots would be taken at the same time.

Answer 66

Through the AWS Management Console, CLI or APIs you can specify when to start a single backup or a recurring backup. Users are able to: Take a backup right now (through "Create Snapshot" console button or CreateSnapshot API) Set up an automatic daily backup. The backup will take place during your preferred backup window. You can set that up through Creating/Modifying cluster via console or the CreateReplicationGroup and ModifyReplicationGroup API’s.

Answer 67

Yes. You can specify the S3 location of your RDB files during cluster creation through the Create Cluster Wizard in the console or through the CreateReplicationGroup API. ElastiCache will automatically parse the Redis key-space of the RDB snapshot and redistribute it among the shards of the new cluster.

Answer 68

The engine within ElastiCache for Redis is fully compatible with open source Redis but also comes with enhancements that improve robustness and stability. Some of the enhancements are: More usable memory: You can now safely allocate more memory for your application without risking increased swap usage during syncs and snapshots. Improved synchronization: More robust synchronization under heavy load and when recovering from network disconnections. Additionally, syncs are faster as both the primary and replicas no longer use the disk for this operation. Smoother failovers: In the event of a failover, your shard now recovers faster as replicas no longer flush their data to do a full re-sync with the primary.

Answer 69

To use the enhanced engine from the Amazon ElastiCache management console, just select an engine compatible with Redis engine version 2.8.22 or higher when creating a cluster. From that point on you will be using the enhanced engine. You can also use the enhanced engine through the ElastiCache API or AWS CLI by specifying the engine version when running the CreateCacheCluster API.

Answer 70

No. The enhanced engine is fully compatible with open-source Redis, thus you can enjoy its improved robustness and stability without the need to make any changes to your application code.

Answer 71

There is no additional charge for using the enhanced engine. As always, you will only be charged for the nodes you use.

Answer 72

Amazon ElastiCache for Redis provides the ability to add and remove shards from a running cluster. You can dynamically scale-out or scale-in your Redis cluster workloads to adapt to changes in demand. ElastiCache will resize the cluster by adding or removing shards and redistributing hash slots uniformly across the new shard configuration, all while the cluster continues to stay online and serve requests.

Answer 73

The ability to dynamically scale-out and scale-in a cluster can help you manage application variability and meet oscillating demands. You can right-size your clusters by adding or removing shards to scale performance and in-memory capacity. The feature eliminates the need to overprovision clusters based on peak demand, helps improve efficiency, and reduces cost.

Answer 74

Online Cluster Resizing is available with Redis engine version 3.2.10. To reshard your cluster, select the cluster and specify whether you want to add or remove shards. When you resize the cluster to scale-out, ElastiCache adds shards and migrates slots from existing shards to new shards, in a way such that the slots are uniformly distributed (by count) across shards. Similarly, when resizing the cluster to scale-in, ElastiCache migrates slots to the remaining shards to uniformly distribute the slots and deletes specified shards.

Answer 75

The time taken to resize a cluster depends on multiple factors, such as number of slots that need to be migrated across shards, size of data and incoming request rate on the cluster. However, the workflow is optimized to parallelize slot migration, which improves the time taken as you add more shards to scale out the cluster.

Answer 76

Yes, the cluster continues to stay online and serve incoming requests, while resharding is in progress. However, snapshotting a cluster while resharding is not supported to prevent increased load on the cluster.

Answer 77

While Online Cluster Resizing provides the benefits to scale out/in with zero downtime, it is a compute-intensive operation and can increase the latency of your client connection. To reduce the load on the cluster during the operation, we recommend that you follow the best practices (described in the documentation).

Answer 78

You can track the progress of the operation by watching the status of the cluster, shards and nodes. During the operation, the cluster, shards and nodes will stay in "modifying" status. Similarly, when shards are being created, deleted or participating in slot migration, the individual shard status will reflect these statuses to show progress. Additionally, the status of end-to-end operation can also be tracked using the progress indicator for the resharding operation, which indicates percentage completed and provides insight into the remaining time for the operation. Lastly, event messages indicate the progress by describing actions being taken (shard creation, slot migration, etc.) during this operation.

Answer 79

The rebalance operation can be used to redistribute slots amongst existing shards to achieve a uniform distribution. This is useful when a cluster is created with manually specified uneven slot distribution or a scale-out/in operation leaves the cluster with uneven distribution. Assuming the slots are identical in their memory and I/O requirements, uniform slot distribution by count is an easy way to load balance across shards.

Answer 80

When new nodes are added to scale-out a cluster, the nodes carry the same set of tags that are common across all existing nodes. Additionally, users can modify tags on all nodes and continue to use tagging as before.

Answer 81

No. The enhanced slot distribution used in cluster resizing workflow is compliant with Redis cluster client behavior and does not require any application changes. ElastiCache retains cluster endpoints, enabling you to continue using existing clients without any changes.

Answer 82

There is no additional charge for using the enhanced Redis engine. As always, you will only be charged for the nodes you use.

Answer 83

The encryption in-transit feature enables you to encrypt all communications between clients and Redis server as well as between the Redis servers (primary and read replica nodes).

Answer 84

Encryption at-rest allows for encryption of data during backups and restore - data backed up and restored on disk and via Amazon S3 is encrypted.

Answer 85

Encryption in-transit, encryption at-rest, and Redis AUTH are all opt-in features. At the time of Redis cluster creation via the console or command line interface, you can specify if you want to enable encryption and Redis AUTH and can proceed to provide an authentication token for communication with the Redis cluster. Once the cluster is setup with encryption enabled, ElastiCache seamlessly manages certificate expiration and renewal without requiring any additional action from the application. Additionally, the Redis clients need to support TLS to avail of the encrypted in-transit traffic.

Answer 86

No. Encryption in-transit requires clients to support TLS. Most of the popular Redis clients (such as Lettuce, Predis, go-Redis) provide support for TLS with some configuration settings. You have to make sure that your Redis client of choice is configured to support TLS and continue to use ElastiCache for Redis as before.

Answer 87

No. Encryption in-transit and encryption at-rest support is only available for new clusters and is not supported on existing ElastiCache for Redis clusters. ElastiCache for Redis version 3.2.6 is the initial version that supports these features.

Answer 88

No. ElastiCache manages certification expiration and renewal behind the scene. No user action is necessary for ongoing certificate maintenance.

Answer 89

No. Currently, ElastiCache does not provide the ability for you to use your certificates. ElastiCache manages certificates transparently for you.

Answer 90

All current generation instances are supported for encryption in transit and encryption at rest.

Answer 91

There are no additional costs for using encryption.

Answer 92

Yes, Amazon ElastiCache for Redis is a HIPAA Eligible Service and has been added to the AWS Business Associate Addendum (BAA). This means you can use ElastiCache for Redis to help you process, maintain, and store protected health information (PHI) and power healthcare applications.

Answer 93

If you have an executed Business Associate Agreement (BAA) with AWS, you can use ElastiCache for Redis to build HIPAA-compliant applications. If you do not have a BAA or have other questions about using AWS for your HIPAA-compliant applications, contact us for more information. See Architecting for HIPAA Security and Compliance on Amazon Web Services for information about how to configure Amazon HIPAA Eligible Services to store, process, and transmit PHI.

Answer 94

ElastiCache for Redis supports compliance programs such as SOC 1, SOC 2, SOC 3, ISO, MTCS, C5 and HIPAA. See AWS Services in Scope by Compliance Program for current list of supported complaince programs.