多云模型面临着独特的配置管理挑战。当选择一个工具时，企业应该仔细对比云本地和第三方的选项。
当企业选择向云计算迁移时，配置管理并没有消失。事实上，配置管理在云中变得更加重要——尤其是当企业使用多云提供商时，因为它帮助跟踪并控制的软件的变化。
与他们使用本地工具一样，组织使用云配置管理工具来确保对所需交付服务的资源的适当控制。这些工具还可以提供一些信息，关于如何更好地配置资源 ，以及资源之间的关系的信息。
但企业面临着一个重要选择：在公有云中使用本地配置服务，还是使用第三方工具，如Ansible 和CFengine。这一选择并不简单。本地云配置管理工具使得企业变得更加依赖于它的公有云提供商，增加了厂商锁定的风险。例如，当企业使用现两个或更多的公有云时，如AWS和人体中，本地配置工具在这两具平台上的表现可能不会很好。
配置管理选项
来自于第三方和云提供的一些最为常见的云盏管理工具：
第三方：
- Chef
- Puppet
- Terraform
- SmartFrog
- Ansible
提供商自有：
- AWS Config
- Microsoft System Center Configuration Manager
- Google Cloud Platform's autoscaler
- Google Cloud Platform instance groups and managed instance groups
第三方配置工具，无论是否基于云，都可以与多云提供商合作，提供抽象层来移除某些配置复杂性。然而，这些第三方工具在公有云中获得一些能力时，他们也可能会失去一些能力。为了采用最小公分母方法，第三方云配置管理工具要放弃一些本地工具所提供的能力。例如，许多本地工具提供一种功能来实时更新库——存储跟踪资源相关的数据的系统。
第三方工具经常需要你手动执行这类任务，这将浪费时间，并且增加的错误的机率，然而他们可以跨不同的云平台工作。企业需要折衷一下，来平衡本地云服务的工作能力，如AWS中的功能，与从多云本地服务抽象工具的能力。
例如，AWS OpsWorks是使用了Chef的云配置管理服务。Chef提供了一个自动化的平台，把服务配置作为代码看待。组织可以部署这一技术来动态更改他们的软件配置。这一行为通过程序代码完成，不是通过GUI完成的。这允许开发人员根据意愿变更配置，使用API从程序中直接更改。AWS OpsWorks能够自然地与Amazon Elastic Compute Cloud实例合作，但却不能确保与其它提供商，如谷歌或微软 Azure的正常运行。
云配置管理需要跨所有相关平台的高效运行。虽然组织可以使用第三方工具跨不同的云服务，但这些工具不能为每个平台做所有的事，所以有一些需要人工流程琮完成。现在，是好的选择是使用多云配置管理工具，即它成本更高，更复杂。
