Disaster recovery with Amazon managed services, Part 2: Multi-Region/backup and restore

{"value":"In [part I](https://aws.amazon.com/blogs/architecture/disaster-recovery-with-aws-managed-services-part-i-single-region/) of this series, we introduced a disaster recovery (DR) concept that uses managed services through a single AWS Region strategy. In part two, we introduce a multi-Region backup and restore approach. With this approach, you can deploy a DR solution in multiple Regions, but it will be associated with longer [RPO/RTO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html). Using a backup and restore strategy will safeguard applications and data against large-scale events as a cost-effective solution, but will result in longer downtimes and greater loss of data in the event of a disaster as compared to other strategies as shown in Figure 1.\n\n\n\nFigure 1. DR Strategies\n\n\n#### **Implementing the multi-Region/backup and restore strategy**\n\n\nUsing multiple Regions ensures resiliency in the most serious, widespread outages. A secondary Region protects workloads against being unable to run within a given Region, because they are wide and geographically dispersed.\n\n\n#### **Architecture overview**\n\n\nThe application diagram presented in Figures 2.1 and 2.2 refers to an application that processes payment transactions, which was modernized to utilize managed services in the AWS Cloud. In this post, we’ll show you which AWS services it uses and how they work to maintain multi-Region/backup and restore strategy.\n\nThese figures show how to successfully implement the backup and restore strategy and successfully fail over your workload. The following sections list the components of the example application presented in the figures, which works as follows:\n\n- [Amazon Route 53](https://docs.aws.amazon.com/route53/?id=docs_gateway) health checks monitor application endpoints\n- If the Route 53 health check fails, an [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/) alarm prompts an [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/?id=docs_gateway) topic\n- This SNS topic invokes an [AWS Lambda](https://docs.aws.amazon.com/lambda/?id=docs_gateway) function, which will invoke the infrastructure pipeline to initiate cluster provision in the secondary Region.\n\n[](https://d2908q01vomqb2.cloudfront.net/fc074d501302eb2b93e2554793fcaf50b3bf7291/2022/05/17/Figure-2.1.-Multi-Region-backup.png)\n\nFigure 2.1. Multi-Region backup\n\n[](https://d2908q01vomqb2.cloudfront.net/fc074d501302eb2b93e2554793fcaf50b3bf7291/2022/05/17/Figure-2.2.-Multi-Region-restore.png)\n\nFigure 2.2. Multi-Region restore\n\n***Route 53***\n\nRoute 53 health checks monitor the health and performance of your web applications, web servers, and other resources. Health checks are necessary for configuring DNS failover within Route 53. Once an application or resource becomes unhealthy, you’ll need to initiate a manual failover process to create resources in the secondary Region. In our architecture, we use CloudWatch alarms to automate notifications of changes in health status.\n\nPlease check out the [Creating Disaster Recovery Mechanisms Using Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) blog post for additional DR mechanisms using Amazon Route 53.\n\n***Amazon EKS control plane***\n\nAmazon Elastic Kubernetes Service (Amazon EKS) automatically scales control plane instances based on load, automatically detects and replaces unhealthy control plane instances, and restarts them across the Availability Zones within the Region as needed. Because on-demand clusters are provisioned in the secondary Region, AWS also manages the control plane the same way.\n\n***Amazon EKS data plane***\n\n[Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/?id=docs_gateway) automatically scales control plane instances based on load, automatically detects and replaces unhealthy control plane instances, and restarts them across the Availability Zones within the Region as needed. Because on-demand clusters are provisioned in the secondary Region, AWS also manages the control plane the same way.\n\n***Amazon EKS data plane***\n\nIt is a best practice to create worker nodes using [Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling](https://docs.aws.amazon.com/ec2/?id=docs_gateway) groups instead of creating individual EC2 instances and joining them to the cluster. This is because Amazon EC2 Auto Scaling groups automatically replace any terminated or failed nodes, which ensures that the cluster always has the capacity to run your workload.\n\nThe Amazon EKS control plane and data plane will be created on demand in the secondary Region during an outage via Infrastructure-as-a-Code (IaaC) such as [AWS CloudFormation](https://docs.aws.amazon.com/cloudformation/?id=docs_gateway), Terraform, etc. You should pre-stage all networking requirements like virtual private cloud (VPC), subnets, route tables, gateways and deploy the Amazon EKS cluster during an outage in the primary Region.\n\nAs shown in [the Backup and restore your Amazon EKS cluster resources using Velero](https://aws.amazon.com/blogs/containers/backup-and-restore-your-amazon-eks-cluster-resources-using-velero/) blog post, you may use a third-party tool like [Velero](https://velero.io/) for managing snapshots of persistent volumes. These snapshots can be stored in an [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/s3/?id=docs_gateway) bucket in the primary Region, which will be replicated to an S3 bucket in another Region via cross-Region replication.\n\nDuring an outage in the primary Region, you can use the tool in the secondary Region to restore volumes from snapshots in the standby cluster.\n\n***OpenSearch Service***\n\nFor domains running [Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/?id=docs_gateway), OpenSearch Service takes hourly automated snapshots and retains up to 336 for 14 days. These snapshots can only be used for cluster recovery within the same Region as the primary OpenSearch cluster.\n\nYou can use OpenSearch APIs to create a manual snapshot of an OpenSearch cluster, which can be stored in a registered repository like Amazon S3. You can do this manually or create a scheduled Lambda function based on their RPO, which prompts creation of a manual snapshot that will be stored in an S3 bucket. Amazon S3 cross-Region replication will then automatically and asynchronously copy objects across S3 buckets.\n\nYou can restore OpenSearch Service clusters by creating the cluster on demand via CloudFormation and using OpenSearch APIs to restore the snapshot from an S3 bucket.\n\n***Amazon RDS Postgres***\n\n[Amazon Relational Database Service (Amazon RDS)](https://docs.aws.amazon.com/rds/?id=docs_gateway) can copy continuous backups cross-Region. You can configure your Amazon RDS database instance to replicate snapshots and transaction logs to a destination Region of your choice.\n\nIf a continuous backup rule also specifies a cross-account or cross-Region copy, [AWS Backup](https://docs.aws.amazon.com/aws-backup/?id=docs_gateway) takes a snapshot of the continuous backup, copies that snapshot to the destination vault, and then deletes the source snapshot. For continuous backup of Amazon RDS, AWS Backup creates a snapshot every 24 hours and stores transaction logs every 5 minutes in-Region. The Backup Frequency setting only applies to cross-Region backups of these continuous backups. Backup Frequency determines how often AWS Backup:\n\n- Creates a snapshot at that point in time from the existing snapshot plus all transaction logs up to that point\n- Copies snapshots to the other Region(s)\n- Deletes snapshots (because it only was created to be copied)\n\nFor more information, refer to the [Point-in-time recovery and continuous backup for Amazon RDS with AWS Backup](https://aws.amazon.com/blogs/storage/point-in-time-recovery-and-continuous-backup-for-amazon-rds-with-aws-backup/) blog post.\n\n***ElastiCache***\n\nYou can export and import backup and copy API calls for [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/?id=docs_gateway) to develop a snapshot and restore strategy in a secondary Region. You can either prompt a manual backup and copy of that backup to S3 bucket or create a pair of Lambda functions to run at a schedule to meet the RPO requirements. The Lambda functions will prompt a manual backup, which creates a .rdb to an S3 bucket. Amazon S3 cross-Region replication will then handle asynchronous copy of the backup to an S3 bucket in a secondary Region.\n\nYou can use CloudFormation to create an ElastiCache cluster on demand and use CloudFormation properties such as [SnapshotArns and SnapshotName](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html) to point to the desired ElastiCache backup stored in Amazon S3 to seed the cluster in the secondary Region.\n\n***Amazon Redshift***\n\n[Amazon Redshift](https://docs.aws.amazon.com/redshift/?id=docs_gateway) takes automatic, incremental snapshots of your data periodically and saves them to Amazon S3. Additionally, you can take manual snapshots of your data whenever you want.\n\nTo precisely control when snapshots are taken, you can create a snapshot schedule and attach it to one or more clusters. You can also configure [cross-Region snapshot copy](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-snapshots-console.html#snapshot-crossregioncopy-configure), which will automatically copy all your automated and manual snapshots to another Region.\n\nDuring an outage, you can create the Amazon Redshift cluster on demand via CloudFormation and use CloudFormation properties such as [SnapshotIdentifier](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-redshift-cluster.html#cfn-redshift-cluster-snapshotidentifier) to restore the new cluster from that snapshot.\n\n*Note: You can add an additional layer of protection to your backups through [AWS Backup Vault Lock](https://aws.amazon.com/about-aws/whats-new/2021/10/aws-backup-backup-protection-aws-backup-vault-lock/), [S3 Object Lock](https://aws.amazon.com/blogs/storage/protecting-data-with-amazon-s3-object-lock/), and [Encrypted Backups](https://aws.amazon.com/blogs/storage/create-and-share-encrypted-backups-across-accounts-and-regions-using-aws-backup/).*\n\n\n#### **Conclusion**\n\n\nWith greater adoption of managed services within the cloud, there is a need to think of creative ways to implement a cost-effective DR solution. This backup and restore approach offered in this post will lower costs through more lenient RPO/RTO requirements, while providing a solution to utilize AWS managed services.\n\nIn the next post, we will discuss a multi-Region active/active strategy for the same application stack illustrated in this post.\n\n\n#### **Other posts in this series**\n\n\n- [Disaster Recovery with AWS Managed Services, Part I: Single Region](https://aws.amazon.com/blogs/architecture/disaster-recovery-with-aws-managed-services-part-i-single-region/)\n\n\n#### **Related information**\n\n\n- [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)\n\n**Looking for more architecture content?** [AWS Architecture Center](https://aws.amazon.com/architecture/) provides reference architecture diagrams, vetted architecture solutions, [Well-Architected](https://aws.amazon.com/architecture/well-architected/) best practices, patterns, icons, and more!\n\n\n\n\n#### **Dhruv Bakshi**\n\n\nDhruv Bakshi is a Cloud Infrastructure Architect at AWS and possesses a broad range of knowledge across the technology spectrum. Dhruv helps guide AWS customers in building their presence on AWS cloud and has more than a decade experience in various engineer roles. Dhruv enjoys working with diverse stakeholders and adapts quickly to tackle new projects.\n\n\n\n\n#### **Brent Kim**\n\n\nBrent Kim is an Advisory Consultant within the AWS ProServe SDT Advisory group, and has been with AWS for 3 years. He focuses on business enablement and cloud transformation opportunities through the lens of Operational Excellence and preparing customers for cloud readiness. Through Brent's tenure, he has a worked with most teams within AWS, and enjoys collaborating with all stakeholders.","render":"<p>In <a href=\"https://aws.amazon.com/blogs/architecture/disaster-recovery-with-aws-managed-services-part-i-single-region/\" target=\"_blank\">part I</a> of this series, we introduced a disaster recovery (DR) concept that uses managed services through a single AWS Region strategy. In part two, we introduce a multi-Region backup and restore approach. With this approach, you can deploy a DR solution in multiple Regions, but it will be associated with longer <a href=\"https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html\" target=\"_blank\">RPO/RTO</a>. Using a backup and restore strategy will safeguard applications and data against large-scale events as a cost-effective solution, but will result in longer downtimes and greater loss of data in the event of a disaster as compared to other strategies as shown in Figure 1.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/014d6476b57f4d61a725f59715ba9b6c_image.png\" alt=\"image.png\" /></p>\n<p>Figure 1. DR Strategies</p>\n<h4><a id=\"Implementing_the_multiRegionbackup_and_restore_strategy_7\"></a><strong>Implementing the multi-Region/backup and restore strategy</strong></h4>\n<p>Using multiple Regions ensures resiliency in the most serious, widespread outages. A secondary Region protects workloads against being unable to run within a given Region, because they are wide and geographically dispersed.</p>\n<h4><a id=\"Architecture_overview_13\"></a><strong>Architecture overview</strong></h4>\n<p>The application diagram presented in Figures 2.1 and 2.2 refers to an application that processes payment transactions, which was modernized to utilize managed services in the AWS Cloud. In this post, we’ll show you which AWS services it uses and how they work to maintain multi-Region/backup and restore strategy.</p>\n<p>These figures show how to successfully implement the backup and restore strategy and successfully fail over your workload. The following sections list the components of the example application presented in the figures, which works as follows:</p>\n<ul>\n<li><a href=\"https://docs.aws.amazon.com/route53/?id=docs_gateway\" target=\"_blank\">Amazon Route 53</a> health checks monitor application endpoints</li>\n<li>If the Route 53 health check fails, an <a href=\"https://docs.aws.amazon.com/cloudwatch/\" target=\"_blank\">Amazon CloudWatch</a> alarm prompts an <a href=\"https://docs.aws.amazon.com/sns/?id=docs_gateway\" target=\"_blank\">Amazon Simple Notification Service (Amazon SNS)</a> topic</li>\n<li>This SNS topic invokes an <a href=\"https://docs.aws.amazon.com/lambda/?id=docs_gateway\" target=\"_blank\">AWS Lambda</a> function, which will invoke the infrastructure pipeline to initiate cluster provision in the secondary Region.</li>\n</ul>\n<p><a href=\"https://d2908q01vomqb2.cloudfront.net/fc074d501302eb2b93e2554793fcaf50b3bf7291/2022/05/17/Figure-2.1.-Multi-Region-backup.png\" target=\"_blank\"><img src=\"https://dev-media.amazoncloud.cn/9b0a2815eaa64b1481aad4aa6181e2d4_image.png\" alt=\"image.png\" /></a></p>\n<p>Figure 2.1. Multi-Region backup</p>\n<p><a href=\"https://d2908q01vomqb2.cloudfront.net/fc074d501302eb2b93e2554793fcaf50b3bf7291/2022/05/17/Figure-2.2.-Multi-Region-restore.png\" target=\"_blank\"><img src=\"https://dev-media.amazoncloud.cn/4226da8b483445f5b0e821ea017a995f_image.png\" alt=\"image.png\" /></a></p>\n<p>Figure 2.2. Multi-Region restore</p>\n<p><em><strong>Route 53</strong></em></p>\n<p>Route 53 health checks monitor the health and performance of your web applications, web servers, and other resources. Health checks are necessary for configuring DNS failover within Route 53. Once an application or resource becomes unhealthy, you’ll need to initiate a manual failover process to create resources in the secondary Region. In our architecture, we use CloudWatch alarms to automate notifications of changes in health status.</p>\n<p>Please check out the <a href=\"https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/\" target=\"_blank\">Creating Disaster Recovery Mechanisms Using Amazon Route 53</a> blog post for additional DR mechanisms using Amazon Route 53.</p>\n<p><em><strong>Amazon EKS control plane</strong></em></p>\n<p>Amazon Elastic Kubernetes Service (Amazon EKS) automatically scales control plane instances based on load, automatically detects and replaces unhealthy control plane instances, and restarts them across the Availability Zones within the Region as needed. Because on-demand clusters are provisioned in the secondary Region, AWS also manages the control plane the same way.</p>\n<p><em><strong>Amazon EKS data plane</strong></em></p>\n<p><a href=\"https://docs.aws.amazon.com/eks/?id=docs_gateway\" target=\"_blank\">Amazon Elastic Kubernetes Service (Amazon EKS)</a> automatically scales control plane instances based on load, automatically detects and replaces unhealthy control plane instances, and restarts them across the Availability Zones within the Region as needed. Because on-demand clusters are provisioned in the secondary Region, AWS also manages the control plane the same way.</p>\n<p><em><strong>Amazon EKS data plane</strong></em></p>\n<p>It is a best practice to create worker nodes using <a href=\"https://docs.aws.amazon.com/ec2/?id=docs_gateway\" target=\"_blank\">Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling</a> groups instead of creating individual EC2 instances and joining them to the cluster. This is because Amazon EC2 Auto Scaling groups automatically replace any terminated or failed nodes, which ensures that the cluster always has the capacity to run your workload.</p>\n<p>The Amazon EKS control plane and data plane will be created on demand in the secondary Region during an outage via Infrastructure-as-a-Code (IaaC) such as <a href=\"https://docs.aws.amazon.com/cloudformation/?id=docs_gateway\" target=\"_blank\">AWS CloudFormation</a>, Terraform, etc. You should pre-stage all networking requirements like virtual private cloud (VPC), subnets, route tables, gateways and deploy the Amazon EKS cluster during an outage in the primary Region.</p>\n<p>As shown in <a href=\"https://aws.amazon.com/blogs/containers/backup-and-restore-your-amazon-eks-cluster-resources-using-velero/\" target=\"_blank\">the Backup and restore your Amazon EKS cluster resources using Velero</a> blog post, you may use a third-party tool like <a href=\"https://velero.io/\" target=\"_blank\">Velero</a> for managing snapshots of persistent volumes. These snapshots can be stored in an <a href=\"https://docs.aws.amazon.com/s3/?id=docs_gateway\" target=\"_blank\">Amazon Simple Storage Service (Amazon S3)</a> bucket in the primary Region, which will be replicated to an S3 bucket in another Region via cross-Region replication.</p>\n<p>During an outage in the primary Region, you can use the tool in the secondary Region to restore volumes from snapshots in the standby cluster.</p>\n<p><em><strong>OpenSearch Service</strong></em></p>\n<p>For domains running <a href=\"https://docs.aws.amazon.com/opensearch-service/?id=docs_gateway\" target=\"_blank\">Amazon OpenSearch Service</a>, OpenSearch Service takes hourly automated snapshots and retains up to 336 for 14 days. These snapshots can only be used for cluster recovery within the same Region as the primary OpenSearch cluster.</p>\n<p>You can use OpenSearch APIs to create a manual snapshot of an OpenSearch cluster, which can be stored in a registered repository like Amazon S3. You can do this manually or create a scheduled Lambda function based on their RPO, which prompts creation of a manual snapshot that will be stored in an S3 bucket. Amazon S3 cross-Region replication will then automatically and asynchronously copy objects across S3 buckets.</p>\n<p>You can restore OpenSearch Service clusters by creating the cluster on demand via CloudFormation and using OpenSearch APIs to restore the snapshot from an S3 bucket.</p>\n<p><em><strong>Amazon RDS Postgres</strong></em></p>\n<p><a href=\"https://docs.aws.amazon.com/rds/?id=docs_gateway\" target=\"_blank\">Amazon Relational Database Service (Amazon RDS)</a> can copy continuous backups cross-Region. You can configure your Amazon RDS database instance to replicate snapshots and transaction logs to a destination Region of your choice.</p>\n<p>If a continuous backup rule also specifies a cross-account or cross-Region copy, <a href=\"https://docs.aws.amazon.com/aws-backup/?id=docs_gateway\" target=\"_blank\">AWS Backup</a> takes a snapshot of the continuous backup, copies that snapshot to the destination vault, and then deletes the source snapshot. For continuous backup of Amazon RDS, AWS Backup creates a snapshot every 24 hours and stores transaction logs every 5 minutes in-Region. The Backup Frequency setting only applies to cross-Region backups of these continuous backups. Backup Frequency determines how often AWS Backup:</p>\n<ul>\n<li>Creates a snapshot at that point in time from the existing snapshot plus all transaction logs up to that point</li>\n<li>Copies snapshots to the other Region(s)</li>\n<li>Deletes snapshots (because it only was created to be copied)</li>\n</ul>\n<p>For more information, refer to the <a href=\"https://aws.amazon.com/blogs/storage/point-in-time-recovery-and-continuous-backup-for-amazon-rds-with-aws-backup/\" target=\"_blank\">Point-in-time recovery and continuous backup for Amazon RDS with AWS Backup</a> blog post.</p>\n<p><em><strong>ElastiCache</strong></em></p>\n<p>You can export and import backup and copy API calls for <a href=\"https://docs.aws.amazon.com/elasticache/?id=docs_gateway\" target=\"_blank\">Amazon ElastiCache</a> to develop a snapshot and restore strategy in a secondary Region. You can either prompt a manual backup and copy of that backup to S3 bucket or create a pair of Lambda functions to run at a schedule to meet the RPO requirements. The Lambda functions will prompt a manual backup, which creates a .rdb to an S3 bucket. Amazon S3 cross-Region replication will then handle asynchronous copy of the backup to an S3 bucket in a secondary Region.</p>\n<p>You can use CloudFormation to create an ElastiCache cluster on demand and use CloudFormation properties such as <a href=\"https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html\" target=\"_blank\">SnapshotArns and SnapshotName</a> to point to the desired ElastiCache backup stored in Amazon S3 to seed the cluster in the secondary Region.</p>\n<p><em><strong>Amazon Redshift</strong></em></p>\n<p><a href=\"https://docs.aws.amazon.com/redshift/?id=docs_gateway\" target=\"_blank\">Amazon Redshift</a> takes automatic, incremental snapshots of your data periodically and saves them to Amazon S3. Additionally, you can take manual snapshots of your data whenever you want.</p>\n<p>To precisely control when snapshots are taken, you can create a snapshot schedule and attach it to one or more clusters. You can also configure <a href=\"https://docs.aws.amazon.com/redshift/latest/mgmt/managing-snapshots-console.html#snapshot-crossregioncopy-configure\" target=\"_blank\">cross-Region snapshot copy</a>, which will automatically copy all your automated and manual snapshots to another Region.</p>\n<p>During an outage, you can create the Amazon Redshift cluster on demand via CloudFormation and use CloudFormation properties such as <a href=\"https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-redshift-cluster.html#cfn-redshift-cluster-snapshotidentifier\" target=\"_blank\">SnapshotIdentifier</a> to restore the new cluster from that snapshot.</p>\n<p><em>Note: You can add an additional layer of protection to your backups through <a href=\"https://aws.amazon.com/about-aws/whats-new/2021/10/aws-backup-backup-protection-aws-backup-vault-lock/\" target=\"_blank\">AWS Backup Vault Lock</a>, <a href=\"https://aws.amazon.com/blogs/storage/protecting-data-with-amazon-s3-object-lock/\" target=\"_blank\">S3 Object Lock</a>, and <a href=\"https://aws.amazon.com/blogs/storage/create-and-share-encrypted-backups-across-accounts-and-regions-using-aws-backup/\" target=\"_blank\">Encrypted Backups</a>.</em></p>\n<h4><a id=\"Conclusion_93\"></a><strong>Conclusion</strong></h4>\n<p>With greater adoption of managed services within the cloud, there is a need to think of creative ways to implement a cost-effective DR solution. This backup and restore approach offered in this post will lower costs through more lenient RPO/RTO requirements, while providing a solution to utilize AWS managed services.</p>\n<p>In the next post, we will discuss a multi-Region active/active strategy for the same application stack illustrated in this post.</p>\n<h4><a id=\"Other_posts_in_this_series_101\"></a><strong>Other posts in this series</strong></h4>\n<ul>\n<li><a href=\"https://aws.amazon.com/blogs/architecture/disaster-recovery-with-aws-managed-services-part-i-single-region/\" target=\"_blank\">Disaster Recovery with AWS Managed Services, Part I: Single Region</a></li>\n</ul>\n<h4><a id=\"Related_information_107\"></a><strong>Related information</strong></h4>\n<ul>\n<li><a href=\"https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/\" target=\"_blank\">Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery</a></li>\n</ul>\n<p><strong>Looking for more architecture content?</strong> <a href=\"https://aws.amazon.com/architecture/\" target=\"_blank\">AWS Architecture Center</a> provides reference architecture diagrams, vetted architecture solutions, <a href=\"https://aws.amazon.com/architecture/well-architected/\" target=\"_blank\">Well-Architected</a> best practices, patterns, icons, and more!</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/79cd82b396214dd592f61e424248bd80_image.png\" alt=\"image.png\" /></p>\n<h4><a id=\"Dhruv_Bakshi_117\"></a><strong>Dhruv Bakshi</strong></h4>\n<p>Dhruv Bakshi is a Cloud Infrastructure Architect at AWS and possesses a broad range of knowledge across the technology spectrum. Dhruv helps guide AWS customers in building their presence on AWS cloud and has more than a decade experience in various engineer roles. Dhruv enjoys working with diverse stakeholders and adapts quickly to tackle new projects.</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/52456eb6e8db47f9954acb985aa83a92_image.png\" alt=\"image.png\" /></p>\n<h4><a id=\"Brent_Kim_125\"></a><strong>Brent Kim</strong></h4>\n<p>Brent Kim is an Advisory Consultant within the AWS ProServe SDT Advisory group, and has been with AWS for 3 years. He focuses on business enablement and cloud transformation opportunities through the lens of Operational Excellence and preparing customers for cloud readiness. Through Brent’s tenure, he has a worked with most teams within AWS, and enjoys collaborating with all stakeholders.</p>\n"}