This page began as my notes from VMworld 2020. The central idea survived: a perimeter firewall cannot govern all of the lateral traffic moving among applications, infrastructure services, containers, and data platforms. What changed is the architecture around that idea.
NSX-T became VMware NSX, networking moved deeper into the VMware Cloud Foundation operating model, and VCF 9.x introduced Virtual Private Clouds as a more accessible consumption boundary. Advanced lateral-security capabilities now sit within VMware vDefend. The result is no longer just a virtual-networking product. It is a set of private-cloud design choices about isolation, delegation, connectivity, inspection, and day-2 operations.
Updated for September 2026: The guidance below reflects VMware Cloud Foundation 9.1-era networking and security. The original 2020 slides are preserved later on this page for historical context; they are not current product or pricing guidance.
TL;DR: what matters now
- Use a VCF Virtual Private Cloud (VPC) as the logical boundary for a tenant, application portfolio, or operating zone when the VCF 9.x model fits the environment.
- Use distributed firewall policy to control east-west communication close to workloads. Use gateway controls for north-south traffic and services such as NAT, VPN, and centralized inspection where the selected design supports them.
- Build microsegmentation from application dependencies, workload identity, and explicit policy—not from an uncontrolled inventory of IP-address rules.
- Treat IDS/IPS, malware prevention, and other advanced threat controls as licensed, design-dependent services. Confirm the exact edition, release, host mode, and enforcement location before promising coverage.
- Operate networking and security as a lifecycle: ownership, naming and tags, policy review, logging, exceptions, upgrades, rollback, and evidence all matter as much as initial deployment.
Why the 2020 premise still holds
Traditional perimeter controls remain necessary, but they cannot see or efficiently govern every workload-to-workload path. Hairpinning all internal traffic through centralized appliances also creates scale, latency, and failure-domain tradeoffs. Distributed enforcement addresses a different problem: it puts policy close to the workload interface so controls can move with the workload and evaluate lateral traffic without redesigning every physical path.
That does not make a distributed firewall automatically simpler or cheaper. From operating NSX in a global environment, my durable lesson is that software-defined enforcement changes where complexity lives. You gain policy consistency and workload context, but you must invest in application discovery, group design, rule ownership, telemetry, and disciplined change control. A cost claim still needs an environment-specific model that includes licenses, infrastructure, operations, tooling, and migration.
What changed from NSX-T to VCF 9.1
Networking became part of the private-cloud consumption model
VMware’s VCF 9.0 networking guidance describes VPC-ready deployment, tighter integration with vCenter and VCF Automation, and simpler access to isolated network services. The goal is to let infrastructure teams establish provider guardrails while application or tenant teams consume approved subnets and services without opening a ticket for every change.
In VCF 9.1, the VPC model adds more explicit architectural choices. VMware documents distributed and centralized connectivity modes, network services such as switching, routing, IP management, NAT, load balancing, and—on centralized designs—VPN. Network Span can also limit where a VPC subnet is available, aligning virtual network visibility with selected vCenter clusters.
The practical shift is important: NSX remains the network virtualization foundation, but many consumers interact with a VPC abstraction instead of building every Tier-0, Tier-1, segment, and security object directly.
Lateral security became a distinct operating layer
VMware vDefend builds on the NSX distributed enforcement model for microsegmentation and threat prevention. In VCF 9.1, VMware describes delegated lateral-security workflows, distributed firewall enhancements, and IDS/IPS capabilities for VM and Kubernetes-oriented environments.
Do not collapse those capabilities into one checkbox. Distributed firewalling, gateway firewalling, IDS/IPS, malware prevention, and network detection have different traffic paths, prerequisites, scale characteristics, and licensing. Broadcom’s current product-offering matrices should be checked for the exact release and entitlement before the architecture is approved.
Build the architecture in five layers
1. Define the boundary
Start by deciding what deserves an independent policy and failure boundary. A VPC might represent a business unit, regulated environment, application portfolio, development stage, or tenant. Avoid creating one VPC per team merely because the interface makes it easy. Each boundary adds routing, address-management, policy, observability, and ownership work.
For a deeper multi-tenant pattern, see VMware Cloud Foundation Multi-Tenancy: Designing Secure Tenant Neighborhoods.
2. Choose the enforcement point
Use distributed firewall policy for controls that should follow the workload and govern east-west paths. Use gateway firewall policy for traffic crossing a routing or external-connectivity boundary. Some flows need both, but duplicate rules in both places create ambiguity.
Write down which team owns each layer, which logs are authoritative, and where an emergency exception is created and later removed.
3. Model applications, not addresses
Group workloads by durable context such as application, environment, tier, sensitivity, and ownership. IP addresses can still be required for unmanaged or transitional systems, but they should not become the primary identity model when tags or inventory-backed membership are available.
A practical policy hierarchy is:
- platform and infrastructure services;
- shared services such as DNS, time, identity, logging, backup, and monitoring;
- application-to-application dependencies;
- application tiers such as web, API, and database;
- temporary exceptions with an owner and expiration date;
- an explicit default posture.
For implementation detail, continue with End-to-End Microsegmentation in NSX-T 4.2: Design, Policy, and Automation.
4. Select the connectivity model
A distributed VPC design can reduce edge infrastructure and simplify physical connectivity when its service set and VLAN requirements fit. A centralized design is appropriate when the environment needs edge-hosted services, dynamic routing, VPN, or other capabilities tied to that path. The correct answer depends on required services, failure domains, throughput, operational skill, and physical-fabric design.
If the design uses classic Tier-0 and Tier-1 routing, review NSX-T Logical Routing: Tier-0/Tier-1 Routing Design and Failover.
5. Make operations part of the design
Before production, define:
- the source of truth for networks, groups, tags, and policy;
- role separation among platform, network, security, and application teams;
- policy review and recertification intervals;
- logging destinations, retention, and alert ownership;
- backup and recovery for managers and configuration;
- certificate, credential, and patch lifecycle;
- capacity thresholds for managers, hosts, edges, and inspection services;
- a rollback path for routing and firewall changes;
- evidence required for incident review and compliance.
Use Traceflow, port mirroring, flow analytics, logs, and packet capture as complementary tools. This NSX troubleshooting guide shows where Traceflow and port mirroring fit, but production runbooks should also identify escalation ownership and expected evidence for each failure mode.
A practical reference pattern
For a multi-tier application, a defensible starting pattern looks like this:
- The platform team creates the provider connectivity, address pools, VPC guardrails, logging, and mandatory shared-service access.
- The application or tenant team receives delegated control only within its approved boundary.
- New workloads enter a restrictive default posture rather than an unrestricted network.
- Discovery data identifies required flows among web, API, database, identity, DNS, monitoring, backup, and management services.
- Distributed policy permits those documented dependencies using workload context wherever possible.
- Gateway policy controls ingress, egress, NAT, VPN, and shared external services according to the chosen connectivity design.
- IDS/IPS is applied deliberately to the traffic that needs inspection, with performance, signature scope, false positives, and response ownership tested before broad enforcement.
- Every exception has a business owner, reason, approval, and expiration date.
This pattern creates a clean separation between provider controls, tenant autonomy, workload segmentation, and external connectivity. It also gives operations teams a clearer answer when a flow fails: identify the boundary, enforcement point, policy owner, and evidence source before changing rules.
Questions to answer before deployment
- Which VCF and NSX release is the supported target, and what is the upgrade path?
- Which networking and vDefend entitlements are actually licensed?
- Which VPC services require centralized connectivity or edge nodes?
- Which clusters may host each VPC subnet, and should Network Span restrict placement?
- How will existing VLAN, Tier-0/Tier-1, NAT, VPN, load-balancing, and firewall dependencies migrate?
- Who owns tags, groups, service definitions, and exceptions?
- What is the default east-west posture for new workloads?
- Which flows require IDS/IPS, and what throughput and failure behavior were validated?
- How are Kubernetes and VM policies coordinated without creating blind spots or conflicting ownership?
- What operational test proves routing, isolation, logging, failover, and rollback before production?
Migrating an existing NSX-T environment
Do not begin with a version upgrade alone. Begin with an inventory and intent review.
- Record managers, clusters, transport zones, segments, gateways, edge nodes, routing, NAT, VPN, load balancers, security groups, firewall policy, service insertion, integrations, certificates, and automation dependencies.
- Classify each object as required, obsolete, duplicated, unsupported, or awaiting an owner.
- Map the current design to the target VCF VPC and connectivity model. Do not recreate old topology automatically if a simpler supported pattern meets the requirement.
- Replace fragile IP-based membership with governed workload context where practical.
- Test policy realization, application flows, failure behavior, logging, backup, upgrade, and rollback in a representative nonproduction environment.
- Migrate in bounded waves with explicit success and rollback gates.
Broadcom recommends using the NSX reference design, administration, and installation guidance together for an NSX-enabled environment. Release notes, interoperability matrices, validated designs, and the product-offering matrix should be part of the same review—not post-deployment reading.
Historical snapshot: what VMworld 2020 emphasized
The original presentation focused on a growing attack surface, the limitations of centralized appliance hairpinning, distributed firewalling, IDS/IPS, network analysis, and threat research. Those themes explain why lateral security became central to the platform. The slides below are retained as a historical record; product names, packaging, scale, and cost claims must be validated against current Broadcom documentation and commercial terms.
Other VMworld 2020 notes in this archive
- VMware Bringing SASE to SD-WAN
- VMware vRealize Network Insight announcements
- VMware NSX-T Advanced Threat Prevention announcements
- VMware Cloud on AWS announcements
- VMware Cloud Disaster Recovery announcements
- VMware vRealize AI Cloud announcements
- VMware vRealize Cloud Universal
- VMware Cloud on Dell EMC VxRail
The decision to make
NSX matters when it turns network and security policy into an operable part of the private-cloud platform. The architecture succeeds when boundaries are intentional, workload identity is governed, enforcement points are clear, application dependencies are known, and day-2 ownership is designed before production.
The wrong question is whether distributed security can replace every appliance. The useful question is which controls belong close to workloads, which belong at a gateway, which belong in the physical or external security stack, and how the teams responsible for them will operate one coherent policy system.
2 thoughts on “VMware NSX in the Modern Data Center: From NSX-T to VCF 9.1”