Disaster recovery planning is a crucial component for any business, ensuring that an organization can effectively respond to a disaster or other emergency that affects its information system. Amazon Redshift offers two primary options for disaster recovery in the event of an Availability Zone failure: Cluster Relocation and Multi-AZ deployment. This article will provide a detailed comparison of these two options, helping you determine the right approach for your DR strategy.
Recovery time objective (RTO) - defines the maximum amount of downtime or interruption that the organization can withstand before its critical systems, applications, or data must be restored and operational following a disruptive event or disaster
Cluster Relocation in Amazon Redshift is a feature that allows you to move your Redshift cluster to a different Availability Zone when there are issues in the current AZ that prevent optimal cluster operation. This process can be carried out without any loss of data or changes to your applications
Multi-AZ deployments of Amazon Redshift data warehouse ensure uninterrupted operations in the event of an unexpected failure within an Availability Zone. This redundancy helps maintain the availability of your Redshift cluster.
Both options offer high availability for your Amazon Redshift cluster, when current Availability Zone experiences an unexpected outage or incident. Depending on your RTO, either of these options will be suitable.
Now, let's compare these two options.
Sr no | Cluster relocation | Multi AZ deployment |
---|
1 | This is Active-Passive configuration : Redshift will automatically fail over to a Redshift cluster to another Availability Zone (AZ) when current Availability Zone has issues | This is a Active-Active Configuration: In this setup, the Amazon Redshift compute resources are deployed across two separate Availability Zones. All of these compute nodes are accessible through a single endpoint. This means that in the event of a complete failure of one Availability Zone, the remaining compute resources in the second Availability Zone will still be available to continue processing workloads without interruption |
2 | Redshift Cluster Relocation is a feature that is currently only available for Redshift clusters deployed in a single AZ configuration | Amazon Redshift allows you to create a cluster with a Multi AZ deployment configuration using the AWS Management Console or the CLI. Additionally, you can convert an existing Multi AZ Redshift cluster to a Single AZ deployment, or vice versa, using the Console or CLI. This flexibility enables you to adjust your cluster's configuration to suit your specific performance and availability requirements |
3 | There is no additional charge for Cross-Relocation Feature | There will be an additional cost to deploy Redshift in a Multi-AZ setup, Exact cost is based on the specific cluster configuration |
4 | In the event of a failover, there is no loss of data | In the event of a AZ outage,there is no loss of data |
5 | The cluster endpoint remains the same as the original cluster, so no application changes are required | The cluster endpoint remains the same as the original cluster, so no application changes are required |
6 | Available only on Ra3 (provisioned) nodes | Available only on Ra3 (provisioned) nodes |
7 | Cluster relocation is a suitable option when the Recovery Time Objective is longer | A Multi AZ deployment is suitable for business-critical workloads that require a Recovery Time Objective in the range of seconds |
8 | With a single AZ deployment, the Redshift Service Level Agreement is 99.9%. | With a Multi AZ deployment, the Redshift Service Level Agreement is 99.99%. |
9 | Monitoring Single AZ deployment - https://docs.aws.amazon.com/redshift/latest/dg/c_intro_system_views.html. It also supports Sys_* views | Monitoring in a Multi-AZ deployment - Only SYS_* views can be utilized for Redshift monitoring and existing STL/SVC views are unavailable. https://docs.aws.amazon.com/redshift/latest/dg/serverless_views-monitoring.html |
10 | Cluster relocation consideration - https://docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-recovery.html#limitations-recovery | Multi AZ consideration - https://docs.aws.amazon.com/redshift/latest/mgmt/overview-multi-az.html#limitations-multi-az |
Additional details
https://aws.amazon.com/blogs/big-data/implement-disaster-recovery-with-amazon-redshift/