当我们的企业开始采用云服务时不仅仅面临的是技术革新，它还很有可能改变原组织的运作方式。当企业由原定期发生的投资IT资源，转变为价格与资源有效利用密切相关时，了解驱动云定价的因素和成本优化策略知识是非常值得的，它将会为我们的企业节省大量的成本支出。

目前虽然有很多企业已经上了云、在用云，但是重视AWS成本优化的企业目前可能并不多。我相信随着后续云计算的不断发展，更多的企业会使用云计算，且会有越来越多的企业和用户开始重视AWS使用成本，开始学习优化AWS的使用成本，我希望我们都是掌握成本优化的先行者，一起学习，一起进步。

好的，下面步入正题，《优化AWS使用成本》系列的第一部分介绍了：

优化AWS使用成本系列（一）思维模式转变与成本分配标签
优化AWS使用成本系列（二）AWS Organizations与成本优化文化建设

我们今天开始第二部分，正确配置实例规模。在使用AWS的过程中，如何正确配置实例大小/规模呢？首先在使用计算资源时，实例大小和规模要和业务匹配；其次，结合不同的业务场景，选择适合的实例的使用方式，这样才能最大化的优化AWS的使用成本。

-第二部分 正确配置实例规模-

–计算选型的一些简单原则–

在实例选型时，基本上的原则是只满足业务容量需求即可，不需要过度的配置，造成成本的浪费，因为实例配置可以随时进行调整，当配置不够时在调整即可。

那如何能够正确配置实例的大小呢，利用Amazon CloudWatch，或者一些类似的监控指标，观察业务利用率，确定缩减规模。

另外呢，如果需求实在太小，可考虑容器，AWS有对应容器的服务。

还有AWS主推的无服务器计算架构，AWS Lambda，不需要购买实例，直接在Lambda上传相应的脚本完成对应的功能，只收取很少的请求和持续时间等费用，省去了大笔实例费用。比如，可以上传一个脚本，功能为当用户上传到S3文件成功时执行对应的操作等等。这块的内容比较多，感兴趣的同学可以重点看下AWS Lambda服务的内容。

–计算实例典型使用方式–

计算资源选型，AWS将实例根据负载类型分为计算/内存/通用/存储/突发性能等等类型，不同实例系列，对应着不同的优化，以及CPU虚拟核心对应内存的比例等等，用户可以根据实际的计算需求进行选择。

以下是一些计算实例典型的使用方式：

对于一些稳定的需求，可以使用RI（预留实例），比如DB、账号服务器等等，这样能享受最高达75%的优惠折扣。

对于一些可变但可预测的需求，比如业务中一些前端WEB服务器，可能根据负载情况所需的服务器数量不同，可以用AUTO SCALING服务，当负载高的时候启用更多的实例来支撑业务负载，当负载下来时自动缩减实例数量达到既满足了业务承载，又节省了成本的目标。

另外对于一些DEV/TEST等内部环境，在不使用的时候可以随时关闭节省成本，因为开着就会计算成本，在需要时在开起来。

对于一些特别临时的需求，可以使用Spot实例，最高可以节省90%的成本，这部分后面在具体讨论。

在本文的最后，我想提供一个通过CloudWatch监控到计算资源浪费后调整实例类型节约成本的一个例子，帮助大家理解本文的主题，正确配置实例的大小/规模：

1. 配置资源时使用的是m4.4xlarge,1.72美元/小时
2. 业务上线后通过cloudwatch等监控指标，发现服务的负载非常低
3. 根据负载情况调整成m4.large实例，价格是0.215美元/小时
4. 再次对性能进行观测，如无异常完成此次调整
5. 最终成本节约87%

Application Discovery是收集和了解您业务所在机房环境，确定存在哪些物理和虚拟服务器及数量，这些服务器上运行的操作系统信息、网络信息以及应用程序的过程。

Application Discovery 的收集的过程可以通过手动方式，但是当您的业务所涉及的服务器数量较多且复杂时会导致效率低、周期长，容易出错。因此建议利用自动发现工具，这些发现工具一般都是通过在服务器上安装Agent（第三方或自行开发），可以自动发现所有应用程序和支持基础架构，通过持续运行自动发现工具来规划如何使数据保持最新状态。

那么一般都支持收集服务器哪些信息呢？可以看下最后面的截图如：网络信息如IP、MAC、系统信息如操作系统版本，以及CPU、内存等硬件信息等，自动发现工具主要用于准确掌控组织资产基础信息，且当业务信息变更时及时发现及时更新。如：自动发现工具收集的记录可以和您组织的CMDB系统基础信息进行比对，当检测到变更或不一致时采取相应的策略，最终确保您掌握的业务信息是准确的等等。

第三方自动发现工具有很多，感兴趣的同学可以自行搜索，当然有研发能力的组织也可以自行进行工具的开发。

AWS也有类似的服务，Application Discovery Service（ADS），主要是用于云迁移，我们在这里不探讨此服务的具体功能，只参考ADS能自动发现的信息，为我们提供一些思路。

ADS应用程序发现工具可以：

• 自动发现数据中心中运行的基础架构和应用程序的清单，并通过持续监视系统来维护清单。
• 帮助确定应用程序如何相互依赖或依赖于底层基础架构。
• 用于分析和规划的操作系统和服务的版本。
• 测量在主机上运行的应用程序和进程，以确定性能基准和优化机会。
• 提供对应用程序和服务器进行分类的方法
• 在使CMDB更新时，自动发现工具可以节省时间和精力。
• 随着项目的进展，使资源信息保持最新是关键，而工具有助于减轻这种痛苦。

以下摘自官方Application Discovery Service的文档，主要参考下ADS可以支持收集发现哪些信息：

AWS Application Discovery Agent

AWS Discovery Agent 是安装在本地服务器和 VM 上用于执行发现和迁移的 AWS 软件。代理将捕获系统配置、系统性能、运行中的进程以及系统之间网络连接的详细信息。代理支持大多数 Linux 和 Windows 操作系统，您可以将其部署在物理本地服务器、Amazon EC2 实例和虚拟机上。

我们继续《优化AWS使用成本》系列的第一部分成本优化基础的剩下内容。

–使用有效的账户结构–

使用有效的账户结构，主要是指整合账户。整合账户这部分主要是针对企业有多个AWS账号的情况，尽早的对组织的账户规划对于成本的优化会非常有帮助。

整合账户是指通过AWS organizations服务进行AWS账户的管理，可以在服务中创建AWS账户也可以将现有账户加入组织，主要功能包括整合账单和账户管理功能：

• 整合账单，可以使用组织的主账户整合和支付所有成员账户。
• 账户管理功能，主账户可以限制成员账户访问AWS服务，进行权限方面的管理（这块不在本主题的讨论范围内，感兴趣单密吧）

与成本相关的主要是整合账单。

整合账户后，除了可以合并计费付费，几个比较容易忽视的对AWS成本优化有很大提升的部分是：

• 首先，不仅仅是合并付费，各成员账户的一些服务使用量也会合并计算，而一些AWS的服务如EC2和S3等服务，会随着用量增加而享受更低的价格，这就是整合账户对于成本优化的帮助之一；
  
• 其次，很重要的一点是，在整合账户的组织中的任何账户，都可以享受其他账户购买的RI小时成本优惠，这就意味着可以规划买一定比例的RI折扣放在主账户，其他账户的EC2等资源就直接享受可能高达75%的折扣。RI是指预留实例，这个在后面会具体介绍。

–使团队设计成本架构–

在业务架构设计初期，最好让熟知成本架构团队参与，在架构设计时就做好成本优化，避免造成资源的浪费，导致业务上线后在进行调整（虽然比传统数据中心方便）。

匹配的这些知识需要靠相关的培训来获得，使团队可以熟悉成本优化，AWS成本相关的服务，建立主动优化的意识等等。

在优化成本的过程中建立可视化过程及目标，定目标，看效果，不断优化不断调整，通过AWS提供服务，如预算工具等等进行跟踪，定期评估，优化。

AWS成本优化知识哪里来？下面的星球啊：）

–分配优化责任–

分配优化责任，就是明确成本的负责人以及目标,很多企业设立专门的云卓越中心负责成本跟踪和优化相关工作。

建立精益成本文化，不断的培训和传播相关知识，在业务各个阶段中选择满足需求的最优资源，以及不断的优化使用成本，让使用者在使用云时形成自然成本优化意识，形成文化。

很多组织在业务快速增长时没有重视成本优化方面的事情，殊不知省到既是赚到，可能关注优化知识几分钟能省下几百万。

整个第一部分结束。

(待续)

*计算*

*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计划

(待续)