然而，我们也需要明确地启用这些EPG之间的通信，甚至在同一EPG内的主机之间的通信。在我们的一个三层应用程序的例子中，我们可能需要允许流量在一个特定的TCP端口从Web服务器EPG传输到应用程序的EPG，而数据库的流量从应用程序EPG传输到数据库的EPG。我们使用一个被称为合同的概念来实现，一套在EPG之间简单适用的规则，规定了怎样的流量被允许在驻留在这些EPG上的主机之间传输。我们也可以让这里的规定适用于外部设备，如防火墙和负载均衡器。除了思科自己的解决方案，ACI还可以与多家第三方供应商的L4至L7的设备集成，如来自F5、思杰和帕洛阿尔托网络的设备。　　

 

　　一个包含了端点组的三层应用程序，以及适用于它们之间的流量合同的详细视图。

　　然后，我们可以清理和重复每一个租户所需的每一款应用程序，我们在租户定义中定义的一切都将包含在该租户的保护伞之下。我们可以在其他租户之间有重复的子网，重复的VLAN，甚至重复的MAC地址，而不会发生冲突。此外，我们可以让EPG共享相同的子网或超级网络，并仍旧在主机之间执行流量规则。因此，我们的三层应用程序可以有连续IP地址的网络、应用程序和数据库服务器，而我们的流量管理合同仍然适用。

　　租户可能是企业集团，比如在我们的例子中，或客户在主机托管或服务环境，或者只是最适合部署逻辑分组的集合。由于每个租户都是在自己的筒仓内存在，在网络层不会与其他租户重叠。这就是说，有一些特殊领域可用于向多个租户分发共同服务。这些服务可能是DNS、NTP和被所有租户使用的目录服务。

　　所有这些后端配置都是由ACI控制器处理，称为应用策略基础架构控制器(Application Policy Infrastructure Controllers，APICs)。这些都是在一个集群中运行的物理服务器，用于负载平衡和冗余的目的。一般来说，每个ACI fabric您将至少有三个APICs。

　　APICs在数据路径之外，他们不是fabric功能所必需的。如果没有可用的APICs，ACI fabric将继续正常运行，但不能做任何更改。APICs为fabric提供配置，提供管理Web UI，及托管ACI围绕建立的RESTful API。任何一个APICs都可以服务Web UI或API的请求，而其功能与其他控制器相呼应。ACI的配置和状态数据存储在控制器的SQLite并能够跨控制器集群共享。　　

 

　　运行在思科实验室的大型ACI基础设施容量仪表板图。请注意，运营商已经超过其规定的三类限制。

　　ACI fabric使得所有基于上面图表的流量决策保持在fabric本身，无论是在本地端点的叶还是在fabric的剩余部分的脊。针对线上的每个数据包，fabric都会根据这些规则做出将其发送到何处的决策，并以线速执行。这便是ACI如何规避传统的IP子网和VLAN的边界，以及东西走向的流量可以通过合同的配置控制的原因了，即使是在同一个子网中的主机之间。