Introducing Zscaler Workload Communications Virtual Machine Scale Sets with Microsoft Azure

Cloud Connectors are typically deployed as part of a security stack on a regional zone basis. Workload route tables are then updated to forward traffic that will be sent to ZIA and/or ZPA to the stack for that region. The security stack, by default is deployed into a single Resource Group, to facilitate ease of resource management.

The security stack if made up of;

• Azure Internal Load Balancer
  • Workloads route traffic to the Load Balancer, and traffic is then forwarded to healthy Cloud Connectors in the backend pool.
• Cloud Connectors
  • The component that securely forwards traffic to the Zscaler Zero Trust Exchange.
• NAT Gateway
  • Deployed in each zone, used for outbound traffic from the Cloud Connectors.

This new capability also adds the following components;

• VM Scale Sets
  • This defines the desired minimum and maximum number of Cloud Connectors per zone. Rules are triggered to scale out and/or in based on performance metrics.
• Azure Function App
  • Health Monitoring Function
    • Responsible for monitoring the health of the running Cloud Connectors across the deployment. Terminating and then replacing instances that have gone unhealthy.
  • Resource Sync Function
    • Ensures that Cloud Connectors in the Zscaler portal match what is running as part of the scale set. If a Cloud Connector is found in the portal, but not in the scale set, this function will perform a cleanup and ensure they are in sync.

Refer to figure1 below.

Figure1: Azure VM Scale Sets with Zscaler Cloud Connector Topology

The entire security stack, including the configuration, depicted in figure 1, is designed to be deployed programmatically via terraform.

Both brownfield and greenfield environments are supported. These terraform modules can be found here, https://github.com/zscaler/terraform-azurerm-cloud-connector-modules/

Let's describe how this new capability works in more detail.

Customers specify(via terraform variables);

• Minimum number of Cloud Connectors per VMSS(default = 2)
• Default number of Cloud Connectors per VMSS (default =2). This value is used if no metrics are published. It's recommended to set this value to be the same as the minimum amount of Cloud Connectors.
• Maximum number of Cloud Connectors per VMSS(default =5).

So if using the defaults, the minimum number of Cloud Connectors per VMSS will be 2, and can scale out to a maximum of 5. These numbers can be tailored, based on the requirements of the customer's environment.

Customers then specify thresholds(again via terraform variables) for scale out and scale in events. This is based on CPU utilization percentage of the Cloud Connectors.

• Scale In threshold(default = 50%)
• Scale out threshold(default = 70%)

With the default settings, if a Cloud Connectors CPU utilization is greater than 70% for 5 minutes, the scale set will automatically deploy an additional Cloud Connector, up to the maximum amount specified (default=5). Cooldown time is 15 minutes by default.

Then for Scale In, when a Cloud Connectors CPU utilization is less than 50% for 5 minutes, Cloud Connector count will be decreased by one, all the way down to the minimum amount(default =2) if required. Cooldown time is 15 minutes by default

See figure 2 for an example of scale out rule, and figure 3 for an example of a scale in rule.

Figure 2: Example Scale Out Rule

Figure3: Example Scale In Rule

There is also an option to configure scheduled VMSS scaling. Which enables customers to define the minimum number of Cloud Connectors for a specified time period.

For example, if high traffic times are Monday to Friday, 9AM to 5PM, customers can specify the number of additional Cloud Connectors to be available during this time. Then return to normal running state , outside of the defined time range.

Public link

Please use the above public link if you want to share this noodl on another website.