*计算*

*Amazon Elastic Compute Cloud (Amazon EC2) ，*在云中可提供可调大小的计算容量。几分钟就可完成启动实例。具备快速创建计算资源的能力对于DR非常重要。

*Amazon Machine Images (AMIs) ，*合理配置好适应于自己业务的AMIs，包括操作系统、应用程序等等，可作为DR过程的一部分，对于快速恢复业务至关重要。

*可用区，*前面提到过，每个区域都有多个可用区供使用。将自己的业务分部在不同可用区，这样可避免或者减轻单可用区故障造成的影响。

*网络*

当您处理灾难时，经常需要切换至灾备站点，这就可能必须修改网络设置。 AWS提供了多种服务和功能，使您可以管理和修改网络设置。

*Amazon Route 53，*是一种高度可用且可扩展的域名系统（DNS）Web服务。支持多种策略在DR时可自动、手动切换业务只灾备站点，快速恢复业务。具体的功能和配置方式不是本文的重点，就不过多展开了。

*弹性IP地址（EIP），*可解绑和重新绑定EIP至其他实例为DR提供更灵活的方式。

*Elastic Load Balancing，*可自动在多个Amazon EC2实例之间分配传入的应用程序流量，结合使多可用区使用，DR好帮手。

*Amazon VPC，*允许您在AWS中创建您自己私有的、完全隔离的网络，可以VPC启动AWS资源，并可以完全控制虚拟网络环境。也可以从公司的数据中心和VPC之间创建VPN连接，并使用AWS作为公司数据中心的扩展，建立DR计划，当灾难发生时，可利用此快速恢复公司数据中心的业务。

*Amazon Direct Connect，*可以轻松设置从您的位置到AWS的专用网络连接。在许多情况下，这可以降低您的网络成本，增加带宽吞吐量，并提供比基于Internet的连接稳定的工作体验。这个的选择就要看实际的业务需要了。

*数据库*

*Amazon Relational Database Service（Amazon RDS），*使您可以轻松地在云中设置，操作和扩展关系数据库。您可以在DR的准备阶段使用Amazon RDS将关键数据保存在已运行的数据库中，也可以在恢复阶段使用Amazon RDS来运行生产数据库。另外RDS还支持多可用区部署和只读副本，利用这些特性可进一步增加数据库的可用性。

*Amazon DynamoDB，*是一种完全托管的 NoSQL 数据库服务，Amazon DynamoDB 可自动将表的数据和流量分布到足够多的服务器中，以处理客户指定的请求容量和数据存储量，同时保持一致的性能和高效的访问。同样的，Amazon DynamoDB可自动复制数据到多个可用区，从而提供内置的高可用性和数据持久性。

您还可以在DR准备阶段将其用于将数据复制到其他区域的DynamoDB或Amazon S3。在DR的恢复阶段，只需单击一次或API调用，您就可以在几分钟内无缝扩展。

*Amazon Redshift，*是一种快速，完全托管的PB级数据仓库服务。您可以在DR准备阶段使用Amazon Redshift对数据仓库进行快照，以便在同一区域内持久存储在Amazon S3中或复制到另一个区域。在DR的恢复阶段，您可以快速将数据仓库还原到同一区域或其他AWS区域内。

*部署编排工具*

Amazon EC2可使用部署自动化和启动后软件安装/配置过程和工具，这在DR恢复阶段非常有用，可以自动且快速的创建您所需的EC2。

*AWS CloudFormation，*为开发人员和系统管理员提供了一种简单的方法来创建相关AWS资源的集合，并以有序和可预测的方式进行配置。您可以根据需要为环境创建模板并部署相关的资源集合（称为堆栈）。

*AWS Elastic Beanstalk，*是一种易于使用的服务，用于部署和扩展使用Java，.NET，PHP，Node.js，Python，Ruby和Docker开发的Web应用程序和服务。您可以部署应用程序代码，而AWS Elastic Beanstalk将为您的应用程序配置操作环境。

*AWS OpsWorks，*是一种应用程序管理服务，可以轻松部署和运行各种类型和规模的应用程序。 AWS OpsWorks具有自动主机替换功能，因此在实例发生故障时，它将自动替换。您可以在的DR准备阶段使用AWS OpsWorks来模拟您的环境，并且可以在DR恢复阶段将其与AWS CloudFormation结合使用。您可以从支持定义的RTO的存储配置中快速配置新堆栈。

以上，介绍了一些灾难恢复（DR）相关的AWS功能和服务，有效的利用这些功能和特性，能够最大化的支持DR方案的完整性和灵活性，且在灾难发生后的DR恢复阶段，能够快速恢复您的业务，将灾难的影响降到最低。

(待续)

*S3 Glacier ，*为数据的存档和备份提供了极低成本的存储。可结合S3的生命周期管理功能，将一定时间周期的S3存储的对象归档至S3 Glacier。

*Amazon EBS ，*EBS卷可独立于EC2的生命周期而存在，在DR恢复期间可以很容易的将EBS数据卷挂载到其他EC2上快速恢复业务；另外EBS提供了创建卷时间点快照功能，存储在S3中，可针对这些功能规划DR方案。

*AWS Storage Gateway，*可将本地软件设备与基于云的存储连接起来，在企业本地IT环境和AWS的基础设施之间提供无缝、安全的集成。您的应用程序可以使用 NFS、SMB、iSCSI 等标准存储协议通过虚拟机或硬件网关设备连接到该服务。

AWS Storage Gateway，支持三种不同类型的配置：

* Gateway-cached volumes ，主要数据存储在S3，并在本地保留经常访问的数据，保持对经常访问的数据低延迟的访问。

* Gateway-stored volumes ，如果您需要在本地低延迟的访问所有数据，您可以配置Gateway在本地存储主要数据，在异步备份此数据的时间点快照到S3。

* Gateway-virtual tape library (gateway-VTL) ，使用网关VTL，您可以拥有几乎无限的虚拟磁带集合。您可以将每个虚拟磁带存储在Amazon S3支持的虚拟磁带库（VTL）或Amazon Glacier支持的虚拟磁带架（VTS）中。虚拟磁带库公开了行业标准iSCSI接口，为您的备份应用程序提供对虚拟磁带的在线访问。

(待续)

这部分简单介绍下与灾难恢复（DR）相关的AWS功能和服务，计划分3-4篇完成。

无论是将AWS资源作为主业务节点，还是灾备资源节点，都需要熟悉AWS功能和服务，大部分AWS的服务都有DR的特性和功能，只有掌握才有可能设计出良好的DR架构，当灾难发生时，才有可能将公司的业务影响降到最低。

拿AWS可用区举个例子，AWS同一个区域有多个可用区，如果您不清楚同一区域的可用区特性，非要把公司业务只放到一个可用区里，然后万一可用区发生故障当然会影响了这个可用区的全部业务。如果熟悉AWS，就不会发生这种低级失误，会设计成多可用区架构，所以在故障发生前还能做很多事情去避免或降低对业务的影响。

*区域*

*AWS全球有多个区域*，所以除了要选择部署您的业务的区域，还应该未您的DR站点选择适合的区域。灾难发生时DR站点要派上用场时发现之前所选的区域不合适的话就比较尴尬了。

*存储*

*Amazon S3* ，高度可用的存储架构，对象冗余存储在一个区域的多个设施的多个设备上，还有一些稍微进阶的功能，用起来的话，可以对数据最一步的保护啦，比如：

1. 做好存储在S3上的静态数据加密，用IAM和存储桶策略进一步的保障数据安全；

2. 可以开启S3的版本控制，保存对象的多个版本；

3. 开启S3跨区域复制，进一步保障数据；

以上这些都是能够进一步保障S3上对象的功能。

之前在网上看了几个案例，关于AWS某区域S3故障出现不可用时，影响了客户对S3的访问，从而导致了公司业务的不可用，客户只能焦急的等待，或者稍微多做了些的同学在其他云备份了数据，去找其他云的备份拷贝到AWS恢复业务，但是：

如果在规划架构时，就了解S3是区域性的服务，开启了上面提到的S3的跨区域复制功能，这样出现同样问题的时候就能很快的在S3复制目的区域获得S3上的公司的业务数据，利用AWS服务快速恢复业务，所以还是那句话，会用和用好可能中间有一定的距离。

(待续)

灾难恢复，是针对灾难的准备和恢复。任何对公司的业务的连续性或财务状况产生负面影响的事件都可以被称为灾难。这包括硬件、软件故障，网络中断，电力故障，数据中心的物理状况损坏如火灾和洪水，人为操作失误或其他重大事件。

在传统的数据中心环境中，要做灾备，灾难恢复，无非就是复制基础/网络架构，确保在灾难发生的时候能够提供备用容量。这样在大部分正常的情况下，会造成资源的过度准备，未充分利用而造成浪费。

在AWS，可以随时按需扩展所需的架构，且可按实际使用付费（这句话真是听了太多次了），AWS还提供了在DR事件期间可快速更改和优化资源的灵活性，从而也可以节省成本。

上面提到的节省成本，虽然是优势之一，确不是在本文的所述重点，后面计划将要从：

1. DR所涉及到的重要基础概念如RTO、RPO等

2. 在使用AWS时，AWS提供和DR最相关的资源，服务的摘要

3. AWS中四种DR场景

4. 改善您的DR计划

(待续)