选择正确的EC2实例族和类型需要考虑多个因素。难怪许多快速进入AWS的组织，没有花时间去充分理解如何为成本和性能设计应用程序，现在却发现预算超支。但是谁又能责怪那些开发团队呢？毕竟，这些天来，无论我走到哪里，都有来自AWS的迹象告诉我要加快构建速度，否则会有人破坏我的商业模式。在这样的压力下，谁有时间等待并考虑选择正确EC2实例的所有因素？并考虑性能和成本是否是当时最重要的。正如我们之前讨论过的，性能和成本考虑是多方面的。在性能方面，应用程序的资源需求包括内存、CPU、网络和磁盘I/O。在成本方面，您需要考虑随需应变与保留实例定价以及现有的RI库存。在我们的6.1版本中，我们对AWS和Azure的垂直缩放操作以及如何基于标签和帐户或基于订阅的视图管理这些操作进行了重大改进。我想更深入地了解awsec2的性能方面，以及我们在扩展决策中添加的维度。当您选择一个EC2实例系列和类型时，您将围绕CPU做出决定：底层硬件的生成（以弹性计算单元（ecu）表示）和核心数量。您还可以选择2GiB到3904GiB的内存容量。Turbonic公司的规模决策，上下，都考虑到了这些维度以及按需定价。在6.1中，我们增加了网络维度，包括总体通信带宽专用网络，EC2实例必须与EBS进行通信。考虑一个持续的I/O密集型工作负载，比如数据库或一个每天运行一次并需要向磁盘写入大量信息的批处理过程。AWS提供EBS优化的模板，其中包含用于这些通信的专用网络信道，以及用于与区域内外的其他服务进行通信的独立网络信道。在非EBS优化的情况下，两种类型的通信都使用相同的网络信道。与EBS卷和EC2实例外部的任何其他服务的通信。见下图。EBS优化针对选定的EC2实例族和类型提供。对于新一代来说，这是免费的，而对于老一代来说，这是一项额外的费用。因此，使用EBS优化并不总是正确的选择。有时它是免费的，有时它会让你付出代价。使用Turbonics的通用抽象模型和分析引擎，我们考虑所有可能的场景。如果I/O吞吐量需要专用通道，我们将扩展到支持它的EC2实例，并根据需要启用EBS优化。如果需求特征支持一个网络通道，我们将在我们的扩展决策中考虑到这一点。正如你现在可能知道的，这些缩放决策从来不是孤立的。它们的基础是考虑到所有的资源需求，并以尽可能低的成本满足它们。包括考虑任何当前或未来的保留实例。但最好的部分是：没有设置阈值，也没有最短的时间来收集数据并为您提供决策。你可以在几分钟内旋转一个涡轮力学实例，你就可以全部准备好了。因此，您不必要求您的开发团队放慢速度并冒着被中断的风险，但您确实需要对您的堆栈进行经济调整，否则可能会给您的财务团队带来头痛或最终用户无法接受的性能。