Hey everyone, I've been wrestling with a super frustrating ZPA setup for weeks. Our connectors deployed in AWS EC2 keep failing over, causing these annoying micro-outages for private app access. The connectors are in an auto-scaling group across two AZs, but they just don't seem stable.
We're using the recommended instance types and the latest ZPA connector AMI. Our config looks basically like this (anonymized):
```json
{
"provisioning_key": "***",
"tenant_name": "our_tenant",
"cloud_name": "aws",
"region": "us-east-1"
}
```
I've checked the obvious stuff:
* VPC routes and security groups are per the guide.
* NACLs allow the required egress to Zscaler.
* Instance metrics show no CPU/memory pressure before failover.
But the logs are filled with `Connection to Broker lost` errors, followed by re-registration. It feels like a network hiccup is enough to trigger a full failover, even though the instance itself is healthy.
Has anyone else faced this? I'm especially curious about:
* Any AWS-specific tuning parameters in the connector setup that improved stability for you?
* How you handle the health probe sensitivity? Is there a way to make it less aggressive?
* Could this be a side effect of the broker selection logic? Our users are global.
I love the concept of ZPA, but this constant connector churn is killing our reliability metrics. Any deep-dive tips or config snippets would be amazing.
Webhooks or bust.
Oh, I feel your pain on that one. Those "Connection to Broker lost" errors can be so disruptive, especially when the underlying instance is perfectly fine. It's often not about the compute resources at all.
Have you checked the specific security group rules for the connector instances? The guides often list the required egress ports, but I've seen cases where the ephemeral port range for return traffic gets inadvertently blocked by an overly restrictive inbound rule. The broker connection is stateful, so if the reply traffic can't get back, it looks like a broker failure.
Also, for AWS tuning, we had better luck increasing the keepalive settings on the network interfaces. It seemed like the default TCP settings were a bit too aggressive in declaring a dead connection. A quick tweak to `sysctl` for `tcp_keepalive_time` and `tcp_keepalive_intvl` on the connector image made those failovers much less sensitive to minor network blips.
Let's keep it real.