多云模型面临着独特的配置管理挑战。当选择一个工具时，企业应该仔细对比云本地和第三方的选项。

当企业选择向云计算迁移时，配置管理并没有消失。事实上，配置管理在云中变得更加重要——尤其是当企业使用多云提供商时，因为它帮助跟踪并控制的软件的变化。

与他们使用本地工具一样，组织使用云配置管理工具来确保对所需交付服务的资源的适当控制。这些工具还可以提供一些信息，关于如何更好地配置资源 ，以及资源之间的关系的信息。

但企业面临着一个重要选择：在公有云中使用本地配置服务，还是使用第三方工具，如Ansible 和CFengine。这一选择并不简单。本地云配置管理工具使得企业变得更加依赖于它的公有云提供商，增加了厂商锁定的风险。例如，当企业使用现两个或更多的公有云时，如AWS和人体中，本地配置工具在这两具平台上的表现可能不会很好。

配置管理选项

来自于第三方和云提供的一些最为常见的云盏管理工具：

第三方：

1. Chef

2. Puppet

3. Terraform

4. SmartFrog

5. Ansible

提供商自有：

1. AWS Config

2. Microsoft System Center Configuration Manager

3. Google Cloud Platform’s autoscaler

4. Google Cloud Platform instance groups and managed instance groups

第三方配置工具，无论是否基于云，都可以与多云提供商合作，提供抽象层来移除某些配置复杂性。然而，这些第三方工具在公有云中获得一些能力时，他们也可能会失去一些能力。为了采用最小公分母方法，第三方云配置管理工具要放弃一些本地工具所提供的能力。例如，许多本地工具提供一种功能来实时更新库——存储跟踪资源相关的数据的系统。

第三方工具经常需要你手动执行这类任务，这将浪费时间，并且增加的错误的机率，然而他们可以跨不同的云平台工作。企业需要折衷一下，来平衡本地云服务的工作能力，如AWS中的功能，与从多云本地服务抽象工具的能力。

例如，AWS OpsWorks是使用了Chef的云配置管理服务。Chef提供了一个自动化的平台，把服务配置作为代码看待。组织可以部署这一技术来动态更改他们的软件配置。这一行为通过程序代码完成，不是通过GUI完成的。这允许开发人员根据意愿变更配置，使用API从程序中直接更改。AWS OpsWorks能够自然地与Amazon Elastic Compute Cloud实例合作，但却不能确保与其它提供商，如谷歌或微软 Azure的正常运行。

云配置管理需要跨所有相关平台的高效运行。虽然组织可以使用第三方工具跨不同的云服务，但这些工具不能为每个平台做所有的事，所以有一些需要人工流程琮完成。现在，是好的选择是使用多云配置管理工具，即它成本更高，更复杂。