Zscaler Cloud Connector Securing AWS / Azure / GCP Workloads with ZIA

💡 The toll booth on the cloud highway

Imagine your AWS Mumbai region is a six-lane expressway. Every EC2 instance is a vehicle wanting to drive out to the public internet for a software update, an API call, or a Slack notification. Without Cloud Connector, every vehicle takes the AWS NAT Gateway — a tunnel that lets traffic out but does zero security inspection. That's how a compromised pod talks to its C2, downloads a coinminer, or exfils customer data.

Cloud Connector is the toll booth between your vehicles and the highway. Every flow is inspected — by the same ZIA policy you use for laptops — and only the legitimate ones get a green light. The trick is doing this transparently: AWS workloads don't reconfigure anything, the routing simply changes so the toll booth becomes the new default gateway.

Why this matters in production (and in interviews)

Indian SI giants and BFSI firms are moving to multi-cloud (TCS landing zones on Azure for clients, Flipkart microservices on AWS Mumbai, Jio analytics on GCP). Cloud security in those workloads is the gap. Cloud Connector closes it. In an interview for a Cloud Security / SecOps role at Wipro, Infosys, or a Big-4 consulting team, expect:

• "Walk me through deploying Cloud Connector in front of a multi-VPC AWS landing zone."
• "EC2s can hit the internet but their HTTPS isn't getting inspected. Where did the route table go wrong?"
• "Why might you choose Cloud Connector over a App Connector — or both?"

What Cloud Connector actually is

Zscaler Cloud Connector (CC) is a VM appliance deployed inside your cloud account, in your VPC/VNet, that takes traffic from cloud workloads and forwards it to ZIA (north-south, internet-bound) and ZPA (when used as a hybrid pattern). Three deployment platforms: AWS, Azure, GCP. Plus on-prem hypervisors (VMware, KVM, Hyper-V) for organisations doing colo or private-cloud egress security.

The four-cousin family: who does what

This is the single most confused topic in Zscaler land. Four products sound similar — Branch Connector, Cloud Connector, App Connector, Service Edge — and they do completely different jobs. Memorise this table; interviewers love to test it.

The AWS GWLB + Transit Gateway pattern (the gold standard)

For multi-VPC AWS landing zones — which is what every serious Indian enterprise runs by now — the canonical pattern is:

1. Create a dedicated Zscaler VPC (sometimes called "security VPC" or "inspection VPC").
2. Deploy Cloud Connectors in private subnets, fronted by an AWS Gateway Load Balancer (GWLB).
3. Create GWLB endpoints in each workload VPC (one per AZ for HA).
4. Attach all VPCs (workload + Zscaler) to a Transit Gateway.
5. Configure route tables so each workload VPC's default route (0.0.0.0/0) goes to its local GWLB endpoint — which transparently sends traffic through CC to ZIA, then back.
6. Configure the Zscaler VPC's TGW route table to send its default to the GWLB VPC endpoint (so even the Zscaler VPC's outbound goes through CC for inspection).

Configuration walkthrough — Terraform-first

Zscaler ships official Terraform modules at github.com/zscaler/terraform-aws-cloud-connector-modules (and equivalents for Azure and GCP). Don't click in the AWS console for production; click only in the lab.

Step 1 — Initialise the Terraform module (AWS)

module "zscaler_cc" {
  source  = "zscaler/cloud-connector-modules/aws"
  version = "~> 1.6"

  name_prefix          = "flipkart-cc-prod-mum"
  aws_region           = "ap-south-1"
  zscaler_cloud        = "zscalerthree.net"
  cc_vm_prov_url       = "https://connector.zscalerthree.net"   # provisioning URL
  cc_callhome_enabled  = true

  # Workload VPCs to attach to TGW
  workload_vpc_ids     = [
    "vpc-0abc111",   # cart
    "vpc-0abc222",   # checkout
    "vpc-0abc333",   # inventory
    # ...
  ]

  # CC sizing + autoscale
  cc_instance_type     = "c6i.xlarge"
  cc_count_min         = 2
  cc_count_max         = 6
  cc_az_count          = 3                # ap-south-1a / b / c

  # Networking
  cc_vpc_cidr          = "10.99.0.0/16"
  cc_subnet_size       = 24

  tags = { owner = "cloud-sec", environment = "prod" }
}

Step 2 — Plan + apply

aditya@laptop:~/flipkart-cc$ terraform init
aditya@laptop:~/flipkart-cc$ terraform plan -out=cc.plan
   Plan: 47 to add, 0 to change, 0 to destroy.

aditya@laptop:~/flipkart-cc$ terraform apply cc.plan
   ...
   Apply complete! Resources: 47 added, 0 changed, 0 destroyed.

   Outputs:
     cc_provisioning_status = "READY"
     gwlb_endpoint_service_name = "com.amazonaws.vpce.ap-south-1.vpce-svc-0123abcd"
     tgw_id                     = "tgw-09abcd1234"
     cc_admin_url               = "https://connector.zscalerthree.net"

Step 3 — Per-workload-VPC route table edit (the magic moment)

OLD:
  Destination       Target
  10.0.0.0/8        local
  0.0.0.0/0         nat-0abc123def   ← AWS NAT Gateway (no inspection)

NEW:
  Destination       Target
  10.0.0.0/8        local
  0.0.0.0/0         vpce-0xy456...   ← local GWLB endpoint
                                       (transparently forwards through CC → ZIA)

That one edit is the entire cutover. Every EC2's outbound HTTPS / DNS / SMTP / API call now flows through ZIA inspection — without any change inside the instance.

The pattern decision tree — Regional Hub vs Isolated VPC

Zscaler publishes two AWS reference patterns. Choose by the workload's isolation requirements.

Verification — "is the cloud actually safer now?"

View 1 — CC admin portal

Dashboard  →  Cloud Connectors  →  flipkart-cc-prod-mum-asg-1a

  Status:                Active ●
  Service Edge:          mum1.sme.zscalerthree.net  (Mumbai)
  Throughput (now):      612 Mbps in / 184 Mbps out
  Sessions (now):        18,420
  AZ:                    ap-south-1a
  Instance type:         c6i.xlarge
  Provisioning:          Terraform (ASG)
  Last health check:     OK · 12 s ago

View 2 — VPC flow logs

# Confirm workload outbound traffic is hitting the GWLB endpoint,
# not the old NAT Gateway
fields @timestamp, srcaddr, dstaddr, action, bytes
| filter srcaddr like /^10\.10\./   # cart VPC CIDR
| filter dstport = 443
| stats sum(bytes) by dstaddr
| sort sum_bytes desc
| limit 20

View 3 — ZIA Insights

Analytics  →  Insights  →  Logs  →  Filter:
  Location = Cloud Connector — flipkart-cc-prod-mum
  Time = Last 1 hour

  → Top destinations:    api.slack.com (32%), api.datadog.com (21%),
                         registry.npmjs.org (14%), api.razorpay.com (9%)
  → Top blocked:         3 (Suspicious cryptominer pool — auto-blocked)
  → DLP events:          0
  → Threats detected:    1 (Suspicious DNS query to fast-flux domain)

Common Mistakes — what blows up in production

Pro tips from the field

End-to-end scenario walkthrough — Karthik's Azure landing zone

Glossary — the words you'll hear on every Cloud Connector call