EPG vs. ESG for Policy Segmentation in Cisco ACI: A Comprehensive Comparison

Executive Summary: The Strategic Pivot in Cisco ACI Security

The architecture of Cisco Application Centric Infrastructure (ACI) has undergone a significant evolution, moving from a security model primarily defined by Endpoint Groups (EPGs) to a more flexible and scalable one centered on Endpoint Security Groups (ESGs). Introduced in Cisco ACI Release 5.0(1), ESGs represent a profound paradigm shift by decoupling security segmentation from the forwarding logic, which were both contained within an EPG object.

The primary value proposition of this transition lies in its ability to address the inherent complexities and limitations of the EPG-based design. ESGs offer enhanced granularity by defining security zones at the Virtual Routing and Forwarding (VRF) level, allowing them to span multiple Bridge Domains (BDs). This approach simplifies operational management, particularly for complex tasks like inter-VRF route leaking, which becomes a more intuitive and streamlined process. Furthermore, by enabling the consolidation of security policies, ESGs lead to a substantial reduction in the number of contracts required, thereby conserving valuable hardware policy resources (TCAM) in large-scale environments. This post serves as a comprehensive resource for network professionals seeking to leverage these new capabilities to modernize their ACI security posture, optimize brownfield deployments, and fully realize the potential of application-centric network design.

Part 1: ACI’s Foundational Security Model: The Dual Role of EPGs

The EPG as the Original Building Block

An Endpoint Group (EPG) serves as the foundational building block of the Cisco ACI fabric’s policy model. It is defined as a logical collection of endpoints, which can be physical servers, virtual machines, network-attached storage, or other devices, that share similar network and security characteristics. In the original ACI architecture, the EPG was a managed object that was responsible for both forwarding and security logic simultaneously. This dual functionality meant that the EPG defined both the forwarding logic and what security policies would be applied to it.

This design was rooted in the concept of application-centric network management, where network policies are defined in a way that aligns with the requirements of an application, rather than the physical topology. EPGs encapsulate this information and action into localized, manageable pieces, allowing for a policy-driven approach to segmentation. The core premise is that endpoints within the same EPG are trusted and can communicate freely with each other, while communication between different EPGs is implicitly denied unless a specific contract is configured to permit the traffic flow.

EPGs excel in traditional network-centric designs where security segmentation naturally aligns with VLANs and subnets. They provide granular control within a defined BD.

The Crucial Relationship: EPGs, BDs, and VLANs

The forwarding logic of an EPG is inextricably linked to its relationship with other ACI objects. Every EPG must be associated with a single Bridge Domain (BD), which in turn is associated with a single VRF and tenant. The BD provides the Layer 2 forwarding domain and houses the subnet that serves as the Anycast Gateway for all endpoints within that domain. This direct, one-to-one relationship between an EPG and a BD prevents an EPG from spanning multiple Layer 2 domains.

Endpoint classification and mapping to an EPG are fundamentally tied to VLAN bindings. This mapping can be configured in one of two ways:

• Static Path Binding: This method is used for physical equipment, where an EPG is manually bound to a specific physical port and VLAN ID. When a frame tagged with the specified VLAN ID enters the leaf switch, it is automatically mapped to the corresponding EPG, and its policy is enforced.
• Dynamic Binding: This is used in conjunction with virtual machine controllers (VMM domains), such as VMware vCenter. The APIC dynamically selects and binds appropriate VLANs and interfaces to an EPG based on communication with the VMM controller, which significantly reduces the need for manual configuration steps.

This reliance on VLANs for classification is the essence of what is often referred to as a “network-centric” design. In this model, the network is built around traditional concepts, with a one-to-one mapping between VLANs, EPGs, and BDs.

The “TCAM Tax” and Inherent Complexities of EPGs

While EPGs provide a powerful model for segmentation, the inherent design limitations can lead to significant management and scalability challenges in large-scale deployments. An EPG’s dual role as both a forwarding and a security construct means that for every distinct security requirement, a new EPG must be created. In brownfield deployments, where the environment has grown organically over time, this often results in a proliferation of EPG and BD combinations, even when many of them share a common security profile.

This organic growth directly impacts the consumption of hardware resources. Inter-EPG communication is permitted only through the use of contracts. Each contract rule, which defines the allowed communication between two EPGs, consumes a hardware policy entry, typically in the Ternary Content-Addressable Memory (TCAM) on the ACI leaf switches. A large number of EPGs and the resulting increase in contract complexity leads to a higher consumption of these resources, which can become a major scalability and management bottleneck. The management burden is compounded by the need to track and maintain a large number of individual policy objects, which can increase the risk of misconfiguration and operational overhead.

A critical observation is that the EPG, with its reliance on VLANs and a single BD, serves as a deliberate bridge between legacy network design and a modern, policy-driven paradigm. ACI was engineered to meet network engineers at their comfort level—VLAN-based segmentation—before guiding them toward a more abstract, application-centric model. The fact that the first step in many brownfield migrations is to replicate the one-to-one relationship of a network-centric design confirms this. The EPG is not merely a logical object; it is an architectural construct that facilitates a staged transition from a topology-dependent mindset to a software-defined one, which is the essence of ACI.

Part 2: The Paradigm Shift: Introducing Endpoint Security Groups (ESGs)

Breaking the EPG Mold

The introduction of Endpoint Security Groups (ESGs) in ACI version 5.0(1) represented a pivotal moment in the evolution of the ACI security model. The core innovation of the ESG is its ability to decouple security segmentation from forwarding policy. This separation allows for unprecedented flexibility and scalability by addressing the rigid, coupled nature of the EPG design. An ESG is a security construct that defines a security zone independently of any Bridge Domain, meaning it can group endpoints from multiple different BDs and subnets under a single, unified security policy.

This new security boundary is scoped to the VRF. While EPGs were confined to a single BD and, by extension, a single VRF, an ESG’s association with a VRF allows it to operate across all the BDs within that VRF. This provides a much broader and more granular security domain than was possible with EPGs alone. The security posture of ESGs is similar to EPGs: communication is allowed among any endpoints within the same ESG, but inter-ESG communication requires an explicit contract. A key benefit is that ESGs use the same contract constructs that engineers are already familiar with, which simplifies the transition to the new model.

EPGs don’t disappear when you use ESGs; rather, ESGs provide an additional layer of policy abstraction on top of the existing EPG framework.

Endpoint Classification with Advanced Selectors

A significant departure from the EPG’s static, VLAN-based mapping is the ESG’s reliance on a set of dynamic matching criteria, known as selectors, to classify endpoints. These selectors provide a powerful and flexible mechanism to group endpoints based on logical attributes rather than their physical network attachment. The expanded selectors, available since ACI 5.2(1), include:

• IP Selector: This method allows endpoints to be classified into an ESG based on their IPv4 or IPv6 address or subnet. This is particularly useful for routed traffic. A notable limitation, however, is that this selector does not classify MAC addresses, which can result in Layer 2 traffic within the same subnet not being subject to ESG contracts.
• EPG Selector: This crucial feature enables a seamless migration from the EPG model by allowing an entire EPG to be classified into an ESG. All endpoints within the selected EPG become members of the new ESG, allowing contracts to be inherited and simplifying the migration process.
• Tag Selector: The most flexible method, this selector uses policy tags—arbitrary key-value pairs—to classify endpoints. Tags can be applied to various ACI objects, including endpoint IPs, BD subnets, or virtual machine attributes. This enables a metadata-driven approach to policy, where security groups are based on business logic rather than network configuration, such as “all servers with the tag ‘application:web'”.

The shift from the EPG model’s reliance on physical-layer constructs (VLANs and interfaces) to the ESG model’s use of logical attributes (IP addresses, EPG membership, or arbitrary tags) is a profound architectural shift. This change is not merely a feature; it is a fundamental reorientation of the ACI security philosophy. It allows network policies to be defined based on business-relevant attributes, such as “all production web servers” or “all development servers,” rather than being constrained by their physical location or network segment. The use of policy tags, in particular, adds a layer of abstraction that facilitates policy automation at scale, which is essential for a truly software-defined network.

Part 3: A Comprehensive Analysis: EPGs vs. ESGs

The Side-by-Side Comparison

The core differences between EPGs and ESGs highlight why the ESG model offers a more scalable and flexible approach to security segmentation. A side-by-side analysis reveals several key distinctions:

• Scope: EPGs are limited in scope to a single Bridge Domain, while ESGs are scoped to a VRF and can span multiple BDs within that VRF.
• Function: An EPG combines both forwarding and security segmentation, whereas an ESG is solely a security construct, relying on other components for forwarding.
• Endpoint Classification: EPGs classify endpoints based on static or dynamic VLAN bindings to physical or virtual ports. ESGs, by contrast, use a range of dynamic selectors based on attributes like IP, EPG name, or policy tags.
• Contracts: ESG contracts supersede EPG contracts. It is also critical to note that contracts are not supported between an EPG and an ESG except with L3Out external EPGs.

Navigating Interoperability: The Coexistence Model

The introduction of ESGs does not signal the end of EPGs. Instead, it establishes a new, complementary division of labor within the ACI fabric. The EPG retains its foundational role in the forwarding plane, continuing to define endpoint mapping to BDs and VLANs through static and dynamic bindings. The EPG also continues to handle the crucial function of identifying external traffic through the L3Out External EPG.

The ESG, in this new model, assumes responsibility for security configuration, including contract mapping and management. The combined architecture allows for a more logical and streamlined approach, where the foundational forwarding and Layer 2 connectivity are defined by EPGs and BDs, and the security policy is applied on top of this foundation using ESGs.

The most significant benefit of the ESG model is its solution to the “TCAM tax” and management overload experienced in large, organically grown ACI fabrics. In traditional EPG deployments, a large number of EPGs with similar security profiles required the deployment of more contracts, which in turn consumed valuable hardware resources and increased the management burden. The ESG model directly addresses this by allowing administrators to consolidate numerous brownfield EPGs into a single ESG, enabling a single contract to govern their communication. This elegant solution not only conserves TCAM entries but also simplifies the overall policy model, proving that ESG is a strategic tool for scaling ACI deployments.

Part 4: Real-World Applications and Strategic Advantages of ESG Adoption

Simplifying Brownfield Migrations

Migrating a legacy, network-centric environment into a modern ACI fabric presents a significant challenge. Traditional methods often necessitate re-addressing or moving workloads, leading to service disruption. The ESG model offers a strategic, non-disruptive migration path that allows organizations to transition to an application-centric policy model without altering the underlying network constructs.

This phased process begins with the creation of a temporary “catch-all” ESG. By using the EPG Selector, all existing EPGs are classified into this single ESG, effectively enabling a “permit-all” analogue for communication, similar to using vzAny or Preferred Groups. Once this foundation is established, administrators can begin a gradual refinement of security policy by creating new, more specific ESGs and moving endpoints out of the catch-all group. This is achieved using other selectors, such as IP or Tag selectors, without requiring any changes to the endpoints’ VLANs or BDs. This approach simplifies the migration by allowing policy to be built and applied incrementally, while the underlying network remains stable.

A New Approach to Route Leaking

One of the most complex and cumbersome tasks in a traditional EPG-based ACI design is configuring inter-VRF route leaking for shared services or L3Outs. The traditional method requires a multi-step process: the subnet must be configured under the provider EPG with a specific scope of ‘Shared between VRFs’. The contract must then be exported from the provider tenant and imported into the consumer tenant, along with other manual adjustments to the BD scope. This intricate and often confusing process is prone to error and increases operational overhead.

The ESG model offers a much simpler and more intuitive way to set up route leaking by leveraging the decoupling of forwarding and security. With ESGs, the process is streamlined to two primary steps:

1. Forwarding: The subnet to be leaked is configured at the VRF level to establish routing reachability.
2. Security: A contract is attached between the ESGs in the different VRFs to permit the desired communication flow.

This approach eliminates the need to configure subnets under the provider EPG or make complex adjustments to the BD scope, which were mandatory with the traditional method. This is a profound architectural shift, as it moves away from a single, overloaded object (the EPG) towards a more modular, composable design where forwarding is handled by the VRF and policy is managed by the ESG.

Part 5: Implementation and Practical Guidance

Migrating to an ESG-centric security model is a strategic process that should be executed with careful planning to ensure a seamless transition. The following prescriptive steps outline a best-practice approach:

1. Planning and Analysis: The first step is to identify EPGs that share common security requirements and can be logically grouped into a single ESG.
2. Create the Foundation: Define new ESGs and their corresponding contracts in the ACI fabric.
3. Initial Classification: Leverage the EPG selector to classify entire EPGs into the newly created ESGs. This action seamlessly inherits the existing contracts, preventing any service disruption during the initial migration.
4. Fine-tuning Policy: Once the initial classification is complete, more granular selectors, such as IP or Tag selectors, can be applied to create more detailed security zones and refine policy as needed.
5. Clean-up: As the new ESG contracts take precedence over the old ones, the original EPG-level contracts can be removed, simplifying the policy model.

Best Practices and Considerations

• Hardware Compatibility: A critical consideration is hardware compatibility. ESGs are a new feature and are not supported on first-generation ACI hardware.
• Version Dependency: The full suite of ESG features, particularly the expanded selectors, was introduced in ACI versions 5.2(1) and later. It is imperative to ensure that the ACI fabric is running a compatible software release.
• Coexistence Nuances: It is essential to remember that EPGs do not go away. They are still required for VLAN and port mapping and defining the endpoint-to-BD association.
• Addressing L2 Traffic: A limitation of IP-based selectors is that they do not classify MAC addresses. This can result in Layer 2 traffic within the same subnet not being subject to ESG contracts, which may require additional consideration for security policy.
• Multi-Site Limitations: As of ACI 6.0, Multi-Site support is not available for ESGs.

Conclusion: Choosing the Right Path for Policy Segmentation

The evolution of Cisco ACI’s security model from EPGs to ESGs represents a significant maturation of the platform. While EPGs were instrumental in ACI’s original design, their tightly coupled nature presented challenges in large-scale and complex environments. The ESG model directly addresses these limitations by providing a more flexible, scalable, and operationally efficient approach to security.

The ESG’s ability to decouple security policy from forwarding, expand its scope to the VRF level, and leverage dynamic endpoint selectors allows network professionals to align their security posture with business logic in a way that was not previously possible. This shift not only simplifies complex tasks like route leaking and brownfield migrations but also conserves valuable hardware resources.

The decision of whether to primarily utilize EPGs or ESGs hinges on your specific application requirements and design philosophy.

• Embrace EPGs when: Your environment has a strong network-centric design, application boundaries clearly align with subnets, and you need a well-established and mature policy model.
• Adopt ESGs when: You are designing for modern, multi-tier applications that span multiple subnets, and you prioritize simplified policy management, increased flexibility, and a more application-centric security posture.

In this new architectural model, EPGs remain a critical, foundational component for the forwarding plane and endpoint connectivity. However, ESGs are clearly the future of ACI security, providing the necessary abstraction and flexibility to support modern, dynamic data centers. The continued development of new ESG features suggests a clear path for ACI as a leading policy-driven network solution.