A Practical Framework for Cisco ACI Security Policy Design.

Choosing the right combination of EPG Contracts, vzAny, Preferred Groups, and ESGs to build scalable Cisco ACI security policies.

The mistake almost everyone makes is treating this as a single choice. You read about ESGs, decide they are the modern way, and rebuild everything as ESGs. Or vzAny looks elegant, so it becomes the answer to your problem. In production, ACI security policy is never one construct, it is a stack of layers, and the real design skill is deciding what belongs at each layer. Pick the layers well and the fabric stays readable for a long time and three engineers later.

This article assumes you already know what contracts, EPGs, vzAny and ESGs are. It is about when each one earns its place and what it quietly costs you.

Stop choosing constructs. Start choosing layers.

Every ACI security design, however large, resolves into layers. They are not alternatives, they coexist in the same VRF at the same time.

●      Baseline layer — the default posture of the VRF. What happens to traffic nobody wrote a specific rule for. This is where vzAny and Preferred Groups live.

●      Classification layer — how endpoints are mapped to a security group in the first place. This is the EPG versus ESG, and it is really a question about whether your security boundary follows your network plumbing or your application.

●      Exception layer — the specific allow, redirect or deny rules that sit on top of the baseline. Plain contracts with filters, including PBR redirect as a contract action.

Once you see it this way, the questions stop competing. vzAny gives you a VRF-wide baseline; ESGs decide how endpoints are classified into that baseline; contracts carve the exceptions. A real design uses all three. The decision tree at the end of this article is built on these layers, not on a forced either/or.

The four constructs. Use, cost, and what will surprise you.

1. EPG-to-EPG contracts, the honest default

Reach for this first.If your security boundaries line up with your EPGs and you have a manageable number of relationships, explicit EPG to EPG contracts are the most readable thing you can build. Anyone can open the tenant and see exactly who talks to whom.

What surprises you: a full mesh of EPGs grows fast. 20 EPGs isn't 20 contracts, it's much higher number. Each one programs zoning-rules on every leaf where those EPGs live, so the TCAM cost climbs just as quickly. Plan for the TCAM budget up front, not after it breaks.

2. vzAny, the VRF-wide baseline

Use it when you are repeating yourself across a whole VRF. A permit-IP baseline for an open zone, a single logging contract, or one common service (DNS, NTP, monitoring) that every EPG consumes, vzAny collapses "every EPG to every EPG" into a couple of rules regardless of how many EPGs you add later. That is genuine simplification, not just fewer clicks.

What surprises you: Whatever you attach, a filter, a redirect, a deny, lands on every EPG in the VRF, so the blast radius is the entire VRF, not one relationship!

●      The common default filter includes ARP and other non-IP traffic. Put a redirect (PBR) on a vzAny subject with that filter and you will redirect ARP and glean traffic to a service node. Endpoints stop resolving, and the outage looks nothing like a policy problem. On vzAny, always use an explicit IP-only filter.

●      Permit-any plus PBR is a loaded gun. A VRF-wide permit-any baseline can send far more traffic through the service device than you intended.

3. Preferred Groups, the allow-list club

A narrow tool. A Preferred Group lets a set of EPGs talk freely without any contracts between them, while anything outside the group still needs explicit contracts.

What surprises you: it is all or nothing inside the group, no granularity, no per-pair control, no filters between members. The moment one member needs to be isolated, you are unwinding the group. Only one preferred group per VRF.

4. ESGs, decoupling security from the network

The common description "group several EPGs into one", undersells them and is slightly wrong. An ESG does not only group EPGs, it classifies endpoints directly, using selectors: tag, IP, MAC, subnet, or an EPG selector. The point is that your security grouping is no longer tied to the bridge domain, the VLAN, or the port. You can build an "App-Tier" security group whose members are endpoints scattered across several BDs, selected by a tag, and write one contract for it.

That is the real reason to move to ESGs: when your security boundary is defined by the application, not by where the wire lands. Tag-based selectors are what make ESGs "application-centric" in a way EPGs never were.

And no, ESGs do not replace EPGs, here is why that matters. EPGs remain the networking construct: the VLAN/encap binding, the domain association, the actual classification of a port or VLAN into the fabric. ESGs sit on top for security classification only. You keep your EPGs for plumbing and add ESGs for policy.

What surprises you: ESGs are VRF-scoped.

Example. Where the numbers actually go.

Take a VRF with 20 EPGs that all need to reach a shared services EPG, and a handful that need to reach each other. Model it three ways.

●      Full EPG mesh: if you naively allow any to any with explicit contracts, that is a lot of contracts, each programming rules in both directions, on the order of many policy-CAM entries per leaf once filters are counted.

●      Shared service via vzAny: one vzAny provided contract for the shared service collapses "every EPG consumes DNS/NTP/monitoring" into a single relationship. Twenty consumers, one rule set, and it stays one rule set at 200 EPGs.

●      Application tiers via ESGs: if the real boundary is Web / App / DB, three ESGs with tag selectors give you three groups and a handful of contracts, regardless of how many EPGs or BDs those endpoints actually live in.

Same security outcome, three very different hardware footprints. The "framework" is nothing more than choosing the model that expresses your intent in the fewest, most durable rules and then checking it against the policy-CAM budget of the specific leaves involved.

The hard parts people leave out

A construct choice is only half of security design. These are the settings that decide whether the policy you drew actually behaves the way you think.

●      Contract scope. Application Profile, VRF (context), Tenant, or Global. A contract only takes effect between EPGs within its scope. The classic silent failure is a Tenant scoped contract expected to work across VRFs, it never programs, and nothing obvious tells you why.

●      Enforcement direction. Ingress versus egress policy enforcement changes where the fabric applies the rule, and it matters most for L3Out traffic.

●      Filter direction and reverse ports. A filter is directional. "Apply Both Directions" plus "Reverse Filter Ports" is what makes return traffic work for stateless filters. Get this wrong and one direction passes while the other is dropped, the single most common "it half-works" contract bug.

●      TCAM / policy-CAM economics. Bidirectional contract reuse and filter compression reduce the entry count; per-leaf budget is finite and differs by hardware generation. Watch it in the APIC Capacity Dashboard, not after a fault.

●      PBR is a contract action, not a separate world. Redirect obeys the same scope, direction and filter rules as permit and deny, including the ARP/non-IP filter trap. Everything above applies to your service-insertion design too.

Operational reality. Prove it, don't assume it!

Design on a whiteboard, verify on the leaf. The value of any of these constructs is only real if you can see what the fabric actually programmed. The resolved policy lives in the zoning-rules, and every design decision above shows up there as concrete entries you can count and match.

See the resolved policy for a VRF.

Confirm a specific rule is being hit (redirect/deny/permit).

Watch the hardware budget before it bites.

When a flow is denied and "the contract is right," it is almost always one of the hard parts above, scope, direction, or a filter that does not match what you think it matches. The zoning-rule table, and the priority of the rule that actually wins, will tell you in under a minute. That habit, reading the programmed policy instead of trusting the intended policy is the difference between designing ACI security and hoping it works.

The framework, in one place

●      Start at the baseline: does the whole VRF share a default posture? If yes, vzAny?

●      Choose the classification: does your security boundary follow the network (EPG) or the application (ESG)? Tag-based ESGs when it follows the app, keep EPGs for the plumbing either way.

●      Carve the exceptions: specific contracts and PBR redirect on top of the baseline, with the scope, direction and filters set deliberately.

●      Cost it, then verify it: check the relationship count and the policy-CAM budget before you build, and read the zoning-rules after.

Simplicity still wins, but simplicity is a per-layer decision, not a favourite construct.

The engineer who inherits your fabric will not thank you for using the newest feature. They will thank you for a design where the intent is obvious in the tenant and provable on the leaf.