云计算实例在计算能力、内存、存储和对GPU的支持、机器学习和其他专门功能方面具有广泛的应用范围。管理人员应该让应用程序需求决定云计算实例的类型和规模，尤其是因为错误的匹配会导致性能低下和成本高昂的情况。

某些应用程序可能需要更大的云计算实例，这意味着需要高水平计算、存储和其他资源的虚拟机，而其他应用程序可以在资源较少的规模较小实例上运行良好。但并不是每个用户一开始都会使用正确的云计算实例，云计算应用程序的动态特性意味着配对并不总是按计划工作。

可以使用云优化工具和技术来选择正确的云计算实例类型和规模，然后根据需要随时重置和调整它们。

定义应用程序要求

云托管应用程序需要与本地应用程序不同的思维模式。IT经理通常会过度配置本地应用程序，因为以后扩展其他资源是一项挑战。云计算应用程序更容易按需扩展，而需要扩展的特定资源（如计算、内存和存储）因工作负载而异。例如，数据库应用程序需要比网络服务器更多的内存和存储IOPS，这对计算提出了更高的要求。

Enterprise Management Associates管理研究主管Torsten Volk表示，由于企业需要了解应用程序的资源使用模式（最好是一年），因此很难确定云计算实例的规模。

检查云计算供应商的CPU、内存、存储等资源限制。尽管云计算提供商的工具可以帮助确定应用程序的最佳实例类型和设置，但这些供应商几乎没有动力向客户提供复杂的云优化工具，因为过度配置可能是其收入来源。管理人员将需要实现其他技术，以及可能的第三方优化工具，以全面了解情况。

分析指标以推动优化

利用率指标（如CPU、存储、内存和网络容量）可以显示实例的规模是否适合应用程序。例如，大量的请求延迟可能表示实例规模，无法处理当前负载。

云计算咨询机构Candid Partners公司的高级云架构师Beau Bennett表示，“在确定正确的实例规模时，一定要理解峰值是如何影响指标的。”

应该有足够的备用容量来处理使用的峰值，只需要足够长的时间来进行水平扩展。如果单个指标远远高于其他指标（例如，如果内存被完全使用，但CPU和网络容量很低），那么可能是使用不同的实例规模的时候了。

建立监控和调整循环

为确保云计算应用程序有效扩展，需要在指标和操作之间创建反馈循环。监控指标显示高利用率或低利用率时，请对实例规模或类型进行小幅调整。继续监控这些指标，以了解更改如何影响应用程序性能和效率。

强大的持续集成/连续部署（CI/CD）管道，借助基于策略的控制和自动化进行更改，可以帮助云计算管理员调整设置，而不会产生意外后果或冗长的手动流程。Bennett说，基础设施作为代码，资源被模板化并用编程语言编写，也有助于持续的云优化。

性能和利用率指标是云计算提供商的核心产品，或者组织可以转向第三方产品，这些产品提供所使用实例的概述。

使用云成本管理工具

本地成本管理工具（包括Azure成本管理、AWS成本管理和Google权限推荐）可以帮助进行优化，但可能不足以准确估算所有工作负载的需求。例如，Google Rightsizing Recommendations可以根据运行的平均值建议实例规模调整。但是，这种平均利用率信息不足以满足每月或每季度发生一次峰值的Spikey应用程序，或基于特定事件（如黑色星期五）。

Volk警告说，“需要分析重要的工作负载，以将平均使用量和峰值使用量都包括在其云实例规模决定中。”

此外，这些工具可能无法跟踪对应用程序很重要的所有必需资源。例如，Google Rightsizing Recommendations只考虑CPU、内存和存储大小。某些应用程序具有其他限制因素，例如网络IOPS。此外，该工具不考虑某些部署类型，例如Kubernetes集群，这使管理人员可以做出自己的云优化决策。

加载测试不同的实例类型

Volk建议，对不同实例类型和规模的应用程序进行负载测试，以确定预期的平均和突发性能指标。模型负载测试尽可能接近真实的使用模式。例如，峰值负载可能发生在API函数调用期间，同时也可能发生在用户与应用程序图形前端的交互过程中。

集成的第三方系统可能在与云托管应用程序的通信速度方面有要求，这可能使事情变得更复杂。当应用程序共享通用微服务时，集成过程变得更加棘手。跨这些互连的分布式架构进行云优化需要警惕和复杂的建模。

考虑动态实例类型

AWS公司提供了可突发的性能实例，使管理人员可以根据需要动态添加和支付CPU性能。虽然这种服务可以提高云计算性能，但很难知道应用程序只有CPU改进才能扩展，并且不会升级到内存和存储的速度或规模。Volk说，每当依赖实例爆发时，总是进行负载测试。

此外，如果企业在增加的CPU上花费很多，需要查看应用程序的需求，可能是转换为更大实例规模的时候了。

注意容器问题

容器群集可能具有导致比预期更高的网络吞吐量或存储负载的依赖性。关键的罪魁祸首通常是Kubernetes调度策略。“这是一个需要诊断的潜在问题。”Volk说。

如果企业计划启动容器，请考虑云优化评估，而不仅仅是CPU、存储和内存。确定在一段时间内用户可以启动或删除的Kubernetes pod数量是否存在限制，以及对实例上运行的各个容器是否存在规模限制。