4.3 Branch Connector & Cloud Connector for Hybrid Clouds

4.3 Branch Connector & Cloud Connector for Hybrid Clouds

Architectural Premise: Traditional multi-cloud networking relies on complex, fragile constructs: AWS Transit Gateways, Azure Virtual WANs, inter-cloud IPsec VPN meshes, centralized Next-Generation Firewall (NGFW) clusters, and intricate BGP route peering. Zscaler Cloud Connector (CC) and Branch Connector (BC) replace this legacy networking sprawl with zero-trust workload connectivity. Deployed as lightweight virtual appliances directly within VPCs, VNets, or branch virtualization clusters, they establish automated, inside-out micro-tunnels to the Zero Trust Exchange, securing Workload-to-Internet (ZIA) and Workload-to-Workload (ZPA) traffic without exposing routable subnets.

---

1. Cloud Connector & Branch Connector Overview

Cloud Connector and Branch Connector are purpose-built virtual appliances delivered as hardened Linux-based images (available as Amazon AMIs, Azure VHDs, GCP Images, and VMware ESXi/KVM OVAs). They act as intelligent edge proxies that combine the capabilities of a ZIA forwarding engine (utilizing Z-Tunnel 2.0 with DTLS/TLS encapsulation) and a ZPA App Connector/Client into a unified, automated software platform.

+-----------------------------------------------------------------------------+
|                  CLOUD & BRANCH CONNECTOR DEPLOYMENT SCOPE                  |
+-----------------------------------------------------------------------------+

  Public Cloud Environments (AWS, Azure, GCP):       On-Premises Branch & Virtualized Edge:
  +-----------------------------------------+        +-----------------------------------+
  |        ZSCALER CLOUD CONNECTOR          |        |      ZSCALER BRANCH CONNECTOR     |
  | * Deployed in VPC / VNet / GCP Project  |        | * Deployed on VMware ESXi / KVM   |
  | * Secures Cloud Workloads (EC2, VMs)   |        | * Secures Branch Servers & LANs   |
  | * Replaces Transit GWs & Cloud Firewalls|        | * Replaces Complex Branch Routers |
  +-----------------------------------------+        +-----------------------------------+
                       \                                  /
                        \                                /
                         v                              v
  +-----------------------------------------------------------------------------+
  |                         ZSCALER ZERO TRUST EXCHANGE                         |
  |     [ ZIA: Workload-to-Internet ]       [ ZPA: Workload-to-Workload ]       |
  +-----------------------------------------------------------------------------+

Key Distinctions: Cloud Connector vs. App Connector vs. Branch Connector

---

2. Workload Traffic Steering: Workload-to-Internet & Workload-to-Workload

Cloud Connector provides intelligent, Layer 7-aware traffic forwarding by separating cloud outbound communications into two fundamental traffic streams:

+-----------------------------------------------------------------------------+
|                   DUAL-PATH WORKLOAD TRAFFIC FORWARDING                     |
+-----------------------------------------------------------------------------+

               +------------------------------------------------+
               | Cloud Workload (EC2 / Azure VM / Kubernetes)   |
               +-----------------------+------------------------+
                                       |
                   Route Table Default (0.0.0.0/0) or Target Subnet
                                       v
               +------------------------------------------------+
               |         Zscaler Cloud Connector (CC)           |
               +-----------------------+------------------------+
                                      / \
           Path A: Workload-to-Internet  Path B: Workload-to-Workload (Private)
          /                               \
         v                                 v
  +-----------------------------+   +-----------------------------+
  | ZIA Public Service Edge     |   | ZPA Public/Private Edge     |
  | * SSL/TLS Deep Inspection   |   | * 1:1 Brokered Connection   |
  | * Advanced Threat Protect   |   | * Microsegmented App Access |
  | * Data Loss Prevention (DLP)|   | * No Transit Gateway Routing|
  | * Cloud Sandbox Inspection  |   | * Overcoming Overlapping IPs|
  +--------------+--------------+   +--------------+--------------+
                 |                                 |
                 v                                 v
       [ Public Internet / SaaS ]         [ Workload in Azure / DC ]

Path A: Workload-to-Internet (ZIA Forwarding)

When a cloud instance (e.g., an AWS EC2 instance updating Linux packages or accessing public SaaS APIs) sends traffic to an external destination:

1. The cloud subnet route table directs 0.0.0.0/0 traffic to the Cloud Connector instance interface.
2. Cloud Connector intercepts the connection, evaluates policy, and encapsulates the payload into a Z-Tunnel 2.0 (DTLS with TLS fallback) tunnel directed to the nearest ZIA Public Service Edge.
3. ZIA applies the full enterprise security stack: Single-Scan Multi-Action (SSMA) engine, SSL Inspection, Cloud Firewall/IPS, DLP, and Cloud Sandbox.
4. Clean traffic is forwarded to the public internet destination.

Path B: Workload-to-Workload / Workload-to-Private App (ZPA Forwarding)

When a workload in AWS needs to communicate with a database in Azure or a mainframe in an on-premises data center:

1. The cloud workload initiates a connection to the destination FQDN or IP address (e.g., db.corp.azure.internal).
2. Cloud Connector intercepts the request, identifies it as a configured ZPA Application Segment, and acts as a ZPA client.
3. It queries the ZPA Central Authority, establishes an authenticated, end-to-end encrypted micro-tunnel through the ZPA Service Edge, which stitches to the ZPA App Connector deployed adjacent to the database.
4. No AWS Transit Gateway, Azure ExpressRoute, or Direct Connect peering is required, and the two clouds can utilize identical, overlapping RFC 1918 IP address spaces without NAT conflicts.

---

3. Zero-Touch Provisioning (ZTP) & Infrastructure as Code

Cloud Connector eliminates manual console provisioning by leveraging automated Zero-Touch Provisioning (ZTP) workflows.

+-----------------------------------------------------------------------------+
|                   ZERO-TOUCH PROVISIONING (ZTP) LIFECYCLE                   |
+-----------------------------------------------------------------------------+

  1. ADMIN CONSOLE: Generate Provisioning URL & Template
     [ ZIA / ZPA Admin Portal ] ---> Create "AWS-US-East-Connector-Group"
                                ---> Generate Provisioning Token & Cloud-Init String

  2. INFRASTRUCTURE AS CODE: Deploy via Terraform / CloudFormation
     [ Terraform Script ] ---> Deploys VPC, Subnets, Route Tables
                          ---> Launches Cloud Connector AMI with user_data = cloud-init

  3. BOOTSTRAP & REGISTRATION: Automatic Cloud Enrollment
     [ Cloud Connector VM Boots ] ---> Reads user_data provisioning token
                                  ---> Initiates Outbound TLS (TCP 443) to Zscaler Central Auth
                                  ---> Validates Token -> Downloads Security Configuration
                                  ---> Registers Health Status -> Begins Processing Traffic

Provisioning Parameters in Cloud-Init Userdata:

When launching a Cloud Connector instance in AWS or Azure, the orchestration script passes a YAML-formatted user_data payload containing:

• zscaler_cc_provisioning_url: The unique cryptographic enrollment URL generated in the Zscaler portal.
• zscaler_cc_provisioning_token: The authentication token binding the virtual appliance to the enterprise tenant and Connector Group.
• zscaler_cc_group_name: The administrative group governing policy and location attributes.

---

4. High Availability (HA) and Cloud Integration Architectures

Enterprise cloud deployments require resilient, multi-AZ active-active high availability.

+-----------------------------------------------------------------------------+
|              AWS GATEWAY LOAD BALANCER (GWLB) ACTIVE-ACTIVE HA              |
+-----------------------------------------------------------------------------+

  Workload Subnet (VPC)
  +-------------------------------------------------------------------------+
  | [ App Instance 1 (AZ-A) ]                     [ App Instance 2 (AZ-B) ] |
  +--------------------+------------------------------------+---------------+
                       |                                    |
                       v                                    v
  +-------------------------------------------------------------------------+
  |                   AWS GATEWAY LOAD BALANCER (GWLB)                      |
  |     * Health checks CC instances via TCP/HTTP probes                    |
  |     * Encapsulates traffic using GENEVE protocol (UDP Port 6081)        |
  +--------------------+------------------------------------+---------------+
                       | (GENEVE)                           | (GENEVE)
                       v                                    v
  +-----------------------------+          +-----------------------------+
  | Cloud Connector 1 (AZ-A)    |          | Cloud Connector 2 (AZ-B)    |
  | [ Active Appliance ]        |          | [ Active Appliance ]        |
  +--------------+--------------+          +--------------+--------------+
                 |                                        |
                 +===================+====================+
                                     |
                                     v (Z-Tunnel 2.0 DTLS/TLS)
                    [ Zscaler Zero Trust Exchange ]

Cloud HA Design Patterns:

• AWS Integration: Cloud Connector integrates directly with AWS Gateway Load Balancer (GWLB) using GENEVE encapsulation (UDP 6081). Workload VPC route tables target the GWLB endpoint (vpce-xxx), which load balances traffic across an autoscaling group of Cloud Connectors in different Availability Zones.
• Azure Integration: Uses Azure Standard Internal Load Balancer (ILB) configured with HA Ports (All Protocols / All Ports), distributing traffic across a Virtual Machine Scale Set (VMSS) of Cloud Connectors. Alternatively, Azure Route Server can peer via BGP with Cloud Connectors for dynamic route injection.
• GCP Integration: Utilizes GCP Internal TCP/UDP Load Balancing with next-hop routing rules directing VPC egress traffic to backend Cloud Connector instances.

---

5. Connector Sizing and Form Factors

Zscaler Cloud and Branch Connectors are available in standardized sizing profiles tailored to throughput requirements:

[!NOTE] Dual-Interface (Dual-Arm) Architecture: Cloud Connector utilizes two distinct network interfaces:

1. Management Interface (eth0): Used for appliance management, DNS resolution, SSH administration, and control plane communication with the Zscaler Central Authority.
2. Service Interface (eth1): Dedicated dataplane interface that receives workload traffic, handles GENEVE/VLAN encapsulation, and establishes Z-Tunnel 2.0 dataplane tunnels to ZIA and ZPA.

---

6. Exam Traps & Real-World Pitfalls

[!WARNING] Exam Trap (Cloud Connector vs App Connector): Do not confuse the functional roles of Cloud Connector and App Connector. An App Connector is strictly an inbound listener that connects authenticated users/workloads to private applications hosted in that datacenter/VPC via ZPA. A Cloud Connector is an outbound gateway deployed to intercept traffic originating from workloads in that VPC and steer it outbound to ZIA (for internet) and ZPA (for private services).

[!IMPORTANT] Overlapping IP Resolution: When connecting multi-cloud VPCs (e.g., AWS VPC with 10.0.0.0/16 and Azure VNet with 10.0.0.0/16), legacy VPN/routing fails due to overlapping CIDRs. Because Cloud Connector and ZPA operate at Layer 7 by resolving application domain names to synthetic IPs and stitching broker micro-tunnels, cross-cloud communication succeeds seamlessly without complex NAT or re-IPing.