在re:Invent2019年期间和之前，亚马逊发布了超过77项新产品发布和独特功能。AWS Compute Optimizer，一个更有趣的产品在12月3日通过一个博客悄然宣布。AWS Compute Optimizer是AWS不断扩展的本机工具集的新成员，这些工具集中于帮助客户重新获得对云账单的控制。其他本地工具包括AWS Trusted Advisor和amazonec2资源优化建议服务（costexplorer下），该服务于2019年7月发布。在本文中，我们将深入探讨AWS计算优化器、它的功能以及它与AWS现有产品的比较。AWS计算优化器概述ComputeOptimizer是一个基于机器学习（ML）的工具，淘客是啥，它分析EC2实例和自动缩放组的CloudWatch度量，物联网智库，并生成建议，帮助用户为其工作负载选择最佳实例类型。分析的指标默认情况下，ComputeOptimizer将分析从CloudWatch收集的CPU、存储IO和网络IO利用率（所有NIC的入口和出口）。用户可以通过安装和配置CloudWatch代理来启用OS级内存指标。如果没有收集内存，AWS承诺该工具不会减少分配给EC2实例的内存容量。这是对Cost explorer调整大小建议的改进。Amazon建议在CloudWatch上启用详细监视，这将把数据收集增量从5分钟增加到1分钟（注意，CloudWatch上的详细监视将导致额外的费用）。观察期建议将基于最近14天的数据；采样周期不可配置。实例必须运行至少30小时（在某些情况下长达60小时），才能生成建议。建议在您的帐户上选择并启用该服务后的12小时内，对于符合条件的EC2工作负载，第一个建议将显示出来—从那时起，建议将每天刷新并生成。这些建议将利用五个实例系列：M（通用）、C（计算优化）、R（内存优化）、T（具有burstable功能的通用）和X（内存优化，非常适合内存数据库）。任何分配了不受支持的实例类型（如加速计算（P、G和F）或存储优化（D、I和H）的实例都将看不到建议。该服务将分析EC2实例的使用情况，并将实例分类为以下类型之一（使用AWS的语言），并根据需要生成调整大小的建议：配置不足：当实例的至少一个规范（如CPU、内存或网络）不满足工作负载的性能要求时，EC2实例被视为配置不足。过度配置：当实例的至少一个规范（如CPU、内存或网络）可以在满足工作负载的性能要求的情况下减小其大小，并且没有任何规范配置不足时，则认为EC2实例配置过度。优化：当实例的所有规范（如CPU、内存和网络）满足工作负载的性能要求，并且实例没有过度配置时，EC2实例被认为是优化的。优化的EC2实例以最佳的性能和基础设施成本运行您的工作负载。对于优化的资源，计算优化器有时可能会建议新一代实例类型。当这些工具为EC2实例生成建议时，它将向用户提供三个选项供选择。自动缩放组建议将重点放在优化的和未优化的自动缩放组上。建议的执行是手动的。该工具将提供指向受尊重实例页面的直接链接，但用户仍然需要手动停止，选择实例类型，然后再次启动实例。分析引擎据我们目前所知，支持这个新工具的正确调整分析引擎是基于机器学习的。它跨支持的指标分析EC2工作负载的利用率，并使用运行在AWS上的数百万工作负载的见解来提出使用哪个实例大小的建议。图像来源：https://aws.amazon.com/compute-optimizer/Amazon在确定什么是精确优化、未充分利用或过度利用的工作负载时，没有提供关于观察到的峰值权重和平均利用率的详细信息，大数据分析方法，但是需要注意的是，这些可能是不可配置的。最后，还不清楚该工具在生成建议时是否考虑了现有的保留实例或节省计划，或者考虑了在Cost Explorer中提供的待定RI或Savings plan购买建议。这一点很重要，因为在不评估当前RI库存的情况下调整工作负载可能会导致更高的按需收费，尤其是在跨系列调整时。AWS计算优化器与AWS现有产品的比较ComputeOptimizer提供了与AWS的其他工具（即AWS Trusted Advisor和Cost Explorer EC2 rightsizing recommendations）相比的附加功能。所有工具中的共同点是过去14天的不可配置的观察期，以及在调整分析方面缺乏任何用户自定义。当实例的CPU利用率超过阈值时，AWS Trusted Advisor会识别并发送警报，以确定效率机会或性能风险。例如，如果一个实例的CPU利用率为10%或更低，而网络IO在四天或更长时间内为5MB或更低，则它将被标记为未充分利用。如果CPU利用率在4天或更长时间内超过90%，则将标记为过度利用。这些阈值不能修改，用户必须确定要使用的新实例类型。costexplorer下相对较新的EC2 rightsizeing推荐服务也是一个基于阈值的工具。在过去14天内CPU峰值低于1%的任何实例都将被标记为空闲，并建议终止它（假设不需要）。CPU峰值在1%到40%之间的实例将建议减小大小，但在同一实例系列中（例如从m4.xlarge到m4.large）。使用ComputeOptimizer，AWS现在提供跨系列的调整大小建议（在它支持的五种实例类型内）。ComputeOptimizer还将建议扩展到EC2以外的自动缩放组。计算优化器足够了吗？ComputeOptimizer旨在帮助AWS用户为其工作负载选择正确的实例类型。然而，当涉及到选择最佳实例和执行正确调整的"最后一英里"时，责任在于用户。此外，调整规模只是降低云计算成本的几种方法之一，在不考虑其他可用选项的情况下，信息大数据，决不能孤立地进行调整。其他重要的注意事项包括使用保留实例（或新的AWS节省计划）或在不需要时停止实例。毫无疑问，云和应用程序的复杂性正在增加，而客户正在引入越来越多的应用程序。这是一个远远超出人类规模的挑战。利用CloudWatch是一个很好的开始，通过CloudWatch代理或第三方工具收集OS级别的指标甚至更好。然而，最有效的方法是让应用程序驱动资源分配，这是涡轮经济应用程序资源管理的切入点。ComputeOptimizer是一个有用的工具，对于小规模的组织或那些仍在"弄清楚所谓的云"的人来说，它已经足够好了。History认为，本机解决方案的采用率约为30%，并且由于其规模和业务需求，大多数组织将需要更高级的优化功能。Gartner最近发布了一篇名为"AWS、GCP和Microsoft Azure原生成本优化的比较"（ID:G00448108），作者是Brian Adler和Marco Meinardi。尽管这篇文章是在AWS Compute Optimizer发布之前发布的，但它将为组织提供可用工具的详细概述和建议。您应该阅读它来理解本机解决方案提供的深度级别。进入涡轮经济应用程序资源管理Turbonomics使客户能够通过在云中运行的应用程序来实现他们的目标，这就是利用云固有的灵活性和弹性。从成本的角度来看，客户希望确保应用程序在需要时拥有执行所需的精确资源。这不能通过收集监测和预测工具来实现，因为这需要一种系统的方法。以下是一些示例，说明了为什么组织应该使用TurboEconomic来优化其云或内部部署资产：自上而下的应用程序感知方法-涡轮力学的设计首先是为了确保应用程序的性能。Turbonomics提供了多个无代理选项，用于连接、接收应用程序级别的指标，如堆利用率、数据库内存和应用程序响应时间。降低应用程序成本的最佳方法是首先关注应用程序性能。当您在应用程序需要的时候分配它所需的确切资源时，您自然会在不引入性能风险的情况下实现成本降低。就这么简单！您需要可靠的操作，您可以自动化，而不是建议-如前所述，淘客网站，当使用本机云产品时，用户仍然需要决定使用哪种确切的实例类型，确认它满足任何约束条件（例如NIC（ENA）或存储（NVMe）的驱动程序，并考虑对存储和网络的影响）。然后，用户必须在下一个维护窗口中手动执行它们；这是不可持续的或不可扩展的！Turbonomic生成可信任的操作，用户可以（并且应该）在从Turbonomic用户界面执行这些操作之前仔细检查这些操作，并且一旦这些操作舒适、完全自动化，甚至可以与ServiceNow等工具集成，用于审批工作流和审核跟踪。不同的工作量要求