SecureDynamics Deployment Standards for Zscaler Cloud Connector (Azure, AWS, and GCP)
Deployment standards and delivery expectations for implementing Zscaler Cloud Connector across Azure, AWS, and GCP environments.
🎯 Purpose
This article defines SecureDynamics’ deployment standards and delivery expectations for Zscaler Cloud Connector across Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).
It ensures consistent understanding between Zscaler, customers, and channel partners regarding:
-
The supported deployment methods used by SecureDynamics
-
What prerequisites must be in place before Professional Services engagement
-
How SecureDynamics aligns with Zscaler’s official delivery methodology
-
The boundaries of support once deployment has been completed
🧭 Background
Zscaler Cloud Connector extends the Zscaler Internet Access (ZIA) platform into public cloud environments to provide secure, policy-driven traffic forwarding.
Zscaler officially recommends Terraform-based automation for Cloud Connector deployments in Azure, AWS, and GCP.
Terraform provides the standardization, repeatability, and automation required for large-scale or multi-region environments.
However, some customers operate under strict governance or security policies that restrict the use of third-party Infrastructure-as-Code (IaC) tools. In these cases, SecureDynamics and Zscaler provide alternative methods, while maintaining alignment with Zscaler’s reference architectures.
⚙️ Supported Deployment Methods
|
Deployment Method |
Support Level |
Supported Clouds |
Description |
Common Use Case |
|---|---|---|---|---|
|
Zscaler Official Terraform Template (Preferred) |
✅ Fully Supported |
Azure, AWS, GCP |
Deployment using the official Zscaler Cloud Connector Terraform module from Terraform Registry or the respective cloud marketplace. |
Standard for production and multi-region deployments. |
|
Cloud Provider Console Deployment (Alternative) |
✅ Supported |
Azure Portal, AWS Console, GCP Console |
Manual setup following Zscaler Reference Architecture using provisioning keys or enrollment certificates. |
Used for proof-of-concept or customers who cannot use Terraform. |
|
Customer-Owned IaC (Custom Terraform, CloudFormation, Bicep, etc.) |
⚙️ Advisory Only |
All |
SecureDynamics provides validation and integration assistance but does not author or support custom code. |
Customer-managed environments. |
|
Unverified Automation or Scripting (CLI, PowerShell, etc.) |
🚫 Out of Scope |
All |
Deployment methods not documented or validated by Zscaler. |
Not eligible for PS support. |
🧩 Zscaler and SecureDynamics Alignment
Zscaler defines Terraform as the standard deployment method for Cloud Connector across all major cloud providers.
SecureDynamics follows the same model to ensure consistent deployment quality and full compatibility with Zscaler TAC and PS support workflows.
“Terraform enables consistent, automated, and scalable Cloud Connector deployments across Azure, AWS, and GCP.
Manual console deployment is available for proof-of-concept or restricted governance environments.”
SecureDynamics supports both approaches — but emphasizes Terraform as the preferred, production-ready method.
🧱 Deployment Preparation and Prerequisites
To ensure project success, SecureDynamics requires that Zscaler and the customer provide the following information before Professional Services engagement begins:
-
Cloud Environment Details: Confirm the target cloud platform(s) and associated regions.
-
Deployment Method: Customer’s final decision on Terraform or manual deployment.
-
ZIA Tenant Readiness: Confirm provisioning keys, enrollment certificates, and authentication configurations.
-
Network Architecture: Provide subnet designs, route tables, and any firewall or NSG configurations.
-
Project Scope Confirmation: Zscaler Sales or VAR must specify what is in scope for the engagement, including number of connectors and regions.
Projects that arrive without this information will be paused until readiness items are confirmed.
🔧 Delivery Responsibilities
During delivery, SecureDynamics will:
-
Deploy Cloud Connectors using Zscaler-approved Terraform templates or manual setup processes.
-
Validate communication to the Zscaler cloud and confirm successful registration in the customer’s ZIA tenant.
-
Document deployment details, including connector configuration, IP assignments, and policy linkage.
SecureDynamics will not:
-
Develop or maintain customer-authored Terraform, CloudFormation, or other IaC.
-
Troubleshoot or modify unsupported automation.
-
Replicate product behavior in lab environments to validate undocumented Zscaler functionality.
Any Zscaler product-level or documentation-related issues discovered during delivery will be escalated through Zscaler TAC using the customer’s support entitlement.
💬 Communication to Zscaler Sales and Partner Teams
Deployment Scope and Handoff Expectations
SecureDynamics deploys Zscaler Cloud Connector on Azure, AWS, and GCP using one of two methods:
-
Zscaler’s official Terraform template (preferred)
-
Manual cloud console deployment (alternative)
Any other deployment method—including custom Terraform, CloudFormation, or scripting—is customer-owned and outside the scope of standard PS delivery.
During sales-to-delivery handoff, Zscaler and VAR teams must confirm the deployment model, tenant readiness, and network architecture details. This ensures that all parties are aligned on the expected delivery approach and that SecureDynamics can focus on providing a predictable, high-quality implementation.
🔎 Key Points
-
SecureDynamics and Zscaler are fully aligned on Terraform as the standard deployment model for Cloud Connector across Azure, AWS, and GCP.
-
Manual console deployment is supported as an alternative for proof-of-concept or restricted environments.
-
Clear scoping and readiness validation before project kickoff ensure consistent, on-time delivery.
-
SecureDynamics provides integration and validation support, not custom IaC development or maintenance.
-
Zscaler and VAR teams must confirm scope and prerequisites during the pre-sales phase to avoid delivery delays.