The Service Engine Groups provide the Service Engine isolation and thereby provide load-balanced application isolation within a tenant configured on the NSX Advanced Load Balancer.

The NSX Advanced Load Balancer Service Engine are created within a Service Engine Group, which contains the definition of how the Service Engines should be sized, placed, and made highly available. Each NSX-T Cloud connector will have at least one Service Engine Group. The Service Engines may only exist within one group and are never shared between the Service Engine Groups. Load-balanced applications are scoped to a Service Engine Group.

  • The Service Engine Group objects are scoped under the NSX-T Cloud connector objects only.

  • Only Active/ Standby HA Mode is supported for the Basic license tier.

Table 1. Design Decisions for Service Engine Group Design for VMware NSX Advanced Load Balancer for the VMware Cloud Foundation

Decision ID

Design Decision

Design Justification

Design Implication


Create multiple Service Engine Groups as desired to isolate applications.


Some of the criteria for grouping applications in different Service Engine Group(s) could be based on:

  • Multiple line of business

  • Prod v/s non-Prod

  • Different scale and performance requirements

Allows efficient isolation of applications and allows for better capacity planning.

Allows flexibility of life-cycle-management.



Create separate set of Service Engine Groups for each VI workload domain and scope the Service Engine Group to the VI workload domain vCenter server.

  • Applicable where a single Controller cluster serving multiple VI workload domains.

  • If applications need to be shared across VI workload domains, then the Service Engine Group could be scoped to multiple vCenter Servers.

Allows isolation of the Service Engines across VI workload domains.

Enables per VI workload domain life-cycle-management.



Configure Service Engine Group for Active/ Active HA mode.


Legacy Active/ Standby HA mode might be required for certain applications.

Provides optimum resiliency, performance, and utilization.

Certain applications might not work in Active/ Active mode. For instance, applications that require preserving client IP. In such cases, use the Legacy Active/ Standby HA mode.


Enable 'Dedicated dispatcher CPU' on Service Engine Groups that contain the Service Engine VMs of 4 or more vCPUs.


This setting should be enabled on SE Groups that are servicing applications that have high network requirement.

This will enable a dedicated core for packet processing enabling high packet pipeline on the Service Engine VMs.


By default, the packet processing core also processes load balancing flows.




Set 'Placement across the Service Engines' setting to 'distributed'.

This allows for maximum fault tolerance and even utilization of capacity.

Might require more Service Engine VMs as compared to 'compact' placement mode.


Enable CPU and Memory reservation on the Service Engine Group.


The Service Engines are a critical infrastructure component providing load-balancing services to mission critical applications.



Configure a consistent Service Engine Name Prefix that indicates the Service Engine VM for instance, 'avise-xxxx'.


Where ‘xxxx’ could be used as an arbitrary identifier.

This allows efficient grouping and filtering.



Choose the Service Engine Group mode as Legacy HA Active/ Standby if the Controller is set to use basic edition.


NSX Advanced Load Balancer Controller in Basic Edition only supports Legacy HA Active/ Standby mode.

Applications will not be deployed in an Active/ Active fashion, thereby losing out on elastic capacity management.

NSX Advanced Load Balancer Enterprise Edition will allow Active/ Active as well as Legacy Active/ Standby deployments.