If you are experienced with enabling anti-malware scanning on MWG whether signature based, or the emulation based gateway anti-malware, you know that the anti-malware scanning significantly reduces the overall req/sec capacity of the appliances (physical or virtual). This makes sense because to do thorough anti-malware screening takes a lot of cycles. An appliance with SSL scanning on that is not scanning for anti-malware can typically handle 3x or more of the number of requests that it can handle when SSL scanning is on and all content that can be scanned is being scanned. While best practice is to have SSL scanning on for all but a few selected trusted categories or sites and all downloads that can be scanned, are scanned with Gateway Anti-Malware, this can result in assigning many more dedicated resources to your web gateways just to handle redundancy and short term peaks. These resources will be under-utilized at all other times.
The level of resources (appliances and VMs) required to handle peaks can be dramatically reduced by monitoring the CPU load and either offloading or bursting anti-malware to the Web Gateway Cloud Service (requires WPS, SWE, or CSS licenses for all users) as described below. Or by simply blocking or bypassing anti-malware for select sites as described Load Aware Web Gateway Anti-malware Scanning and Blocking Saves Resources and Money.
If you have a license for Web Gateway Cloud Service for all your users you can dramatically reduce the resources you need to purchase and maintain. The trick is to intelligently use the load awareness feature of the MWG. When CPU loading is high, you can temporarily reduce the load by using the cloud as a next hop proxy for all cycles. CPULoad is a statistics counter value that can be used in a rule criteria. Your next hop proxy selections should be based on the location of the MWGs. You will need to configure IP authentication for the public IPs that will be seen as the source for the traffic from the MWGs. An example ruleset is attached (recommended placement is after URL Filtering but before any DLP or Anti-malware rulesets) and looks like this (note you do not enable this ruleset in the cloud):
Ruleset updated 11/6/2017 to include passing authentication to the cloud. Note that the Load Aware Burst to Ruleset should be placed after the SSL Scanning ruleset if SSL Scanning is enabled. Use of the authentication passing rules requires a companion ruleset that is enabled in the cloud and placed after the SSL scanning rules. As the authentication is passed in headers, authentication based rules will only work in the cloud for HTTPS sites that are scanned. Also important to note that you must add the MWG CA to your list of accepted CAs in certificate verification because the on-premise web gateway will need to accept the cert that is rewritten by WGCS.
And here is the ruleset that is used in the cloud to utilize the headers added by MWG