Zscaler Advent Calendar 2025

東西AWS/Azure 4つの環境へのZscalerのデプロイガイド（Terraform/Cloud Connector編）

Last updated at 2025-12-26Posted at 2025-12-26

AWSやAzure上にZscalerをデプロイする背景

このガイドでは、AWSやAzureとZscalerクラウドを接続するために、Cloud Connectorを中心にしたシステム全体の通信を確保する手順について解説します。Cloud Connectorは、ネットワークトラフィックを効率的に処理し、ZscalerクラウドとZPA、Zscaler Client Connector間の双方向通信を可能にする重要な要素です。
ここでは、東西リージョン間の接続性という利用例に限定するのではなく、企業が必要とする検証環境や本格的な運用環境を構築する方法の説明を目的としています。特に、自動化ツールであるTerraformを活用し、複雑な手動作業を省略して簡単かつ効率的な設定を実現する方法を紹介します。

ゼットスケーラーの水本です。プロフェッショナルサービスのコンサルタントをしています
この記事はZscaler Advent Calendar 2025のAdvent Calendar 2025の14日目向けに作成しました。特にZscalerのプロフェッショナルサービスで働く中、日々の業務を行いながら迅速に構成を整える必要がある状況で、Terraformによる自動化は大きな助けとなりました。
このガイドではすべての手順を網羅できているわけではないですが、ツールの力を借りて、セキュアなシステム構築を効率的に進めてみてください。
Professional Service チームではコンサルタントを募集しています。興味のある方は水本までDMお待ちしてます

これらの方法として、Cloud Connectorのセットアップを自動化する手順についても触れていきます。例えば、AWSやAzure上でネットワークを構成する際、VPCやVNetをはじめとして、その中に作成するサブネットやルーティング設定、あるいはZPAやZIAで必要となるDNSルールを正しく設定することが重要になります。これらの設定については、普段からクラウドやZscalerの操作に慣れていない方でも簡単に始められるよう、再利用可能なテンプレートのサンプルを用意しています。これにより、複雑な構成を素早く展開できる仕組みを理解し、ラボ環境として、本番環境としても簡単に応用できるようになるでしょう。

ガイドの内容は、技術に詳しいエンジニアだけでなく、設定作業を効率的に進めたい初心者にも適しています。Terraformを利用することで、最低限設定で変更の必要な要素が明確になり、過去に行った操作の反復や削除、設定エラーの防止が可能となるため、検証環境を素早く作成し、テストや本番環境への移行をスムーズに行うことができます。
ここで利用するZscaler公式のテンプレートは、ネットワーク構成の厳密性と設定の一貫性を保証するために作成されており、初心者にも活用しやすい内容にしています。

ガイドの概要

このガイドでは、Terraformやスクリプトを活用してAWSやAzureにCloud Connectorを展開する方法をざっと解説します。本構成は、Zscalerクラウド—特にZIAやZPA—との連携が求められるネットワーク環境を構築するのに最適です。Cloud Connectorは、多くの利用シナリオに対応可能な柔軟な通信プラットフォームであり、クライアントとクラウド間の通信だけでなく、各クラウド事業者のネットワーク内部の通信を効率化する役割を果たします。

そもそもTerraformを利用する理由についてですが、これは設定の効率化と正確性を確保する上で非常に重要だからです。例えば、手作業でネットワーク構成を行うことも可能ではありますが、複雑で煩雑な作業が増えれば増えるほど、エラーが発生するリスクも高くなります。実際、VNetとCloud ConnectorのサービスIPを含めたルーティングの指定一つ誤るだけで疎通はできません。

その点、Terraformのような自動化ツールは以下のような利点を提供します。

まず、すべての設定ファイルがコード化されるため、同じ設定を変更なく適用することが簡単になります。これにより、一貫性を保ちながら複数のクラウド環境で同じ設定を使うことができます。

また、設定テンプレートがパラメータ化されているため、ユーザーのニーズに応じて簡単に拡張やカスタマイズが可能です。さらに、Terraformの構成を利用すれば、高可用性のアーキテクチャを構築する際に必要となるクラウド側のロードバランサーの導入や、テスト用ワークロードのデプロイメントを同時に自動化することも可能です。

このように検証環境ではリソースの迅速な削除と再展開が簡単になり、本番環境では高速かつ正確な運用が実現できます。手作業によるエラーを防ぐためにも、これらの自動化ツールは非常に有用です。この仕組みは、技術的な経験に依存せずデプロイするだけなら誰もが始められるように構成されています。

前提条件

この記事を進める前に必要となる準備についていつか示します。これらは、Cloud Connectorを適切に展開するために必要な条件やリソースであり、事前に確認しておくことで後の作業をスムーズに進めることができます。

Zscalerの前提

まず、Zscalerに関連する設定について説明します。Cloud Connectorは、ZIA（Zscaler Internet Access）とZPA（Zscaler Private Access）の機能を活用してセキュリティの拡張と通信を効率化するものです。そのため、環境上でこれらのライセンスおよびサービスが有効化されていることが前提となります。さらに、Cloud and Branch Connectorの管理を事前にプロビジョニングし、クラウドAPI用の管理者APIアカウントを作成する必要があります。このアカウントにはAPI操作に必要な特定の権限が付与されている必要があり、この手順を飛ばしてしまうと後の設定作業で問題が発生します。
また、Cloud Connectorを使用するには、有効なAPIキーを取得しておくことが必須となります。このAPIキーは、セキュアなストレージ（たとえばAWS Secrets ManagerやAzure Key Vaultなど）に安全に保管し、後でTerraform構成に組み込むことが推奨されます。

クラウド環境の前提

次に、クラウド環境に関する条件について触れていきます。AWSではある一定の管理者権限を持つアカウントが必要であり、これが済んでいない場合、デプロイメント時にエラーが発生する可能性があるため、事前に確認するよう注意してください。その上でSecrets ManagerにAPI用のユーザ名、パスワードを保存します。Azureの場合も基本的には同様です。Azure Key Vaultを利用して、Zscaler関連情報をセキュアに保存し、必要に応じてアクセス権限を設定します。
このプロセスは複雑に思えるかもしれませんが、3つの項目を保存し必要に応じ各リージョンにリプリケーションするだけなのでヘルプに沿って進めれば比較的簡単に構成を完了できます。

Terraformの前提

最後に、Terraformクライアントの要件についてです。Terraform自体は非常に軽量なツールですが、実行環境の整備が必要です。端末にはLinuxまたはMacOSが推奨されており、必要なコマンドラインツール（bashやcurl、grep、jqなど）がインストール済みである必要があります。これらのツールはシステムによって標準搭載されていることもありますが、未インストールの場合はパッケージマネージャー（例: aptコマンドまたはHomebrew）を使用してインストールしてください。

今回のモジュールでは、「zsec」というTerraformラッパースクリプトを使うことで設定作業を簡単に進められます。
手動で設定を行う場合はTerraformが利用できるので慣れた方はこちらが便利です。

クラウド側の前提とネットワーク構成

Cloud Connectorを展開する際には、ネットワーク構成の設計を慎重に行う必要があります。本番環境では、AWSやAzureなどのクラウド環境間、さらにオンプレミスのネットワークとの接続性を確保することが重要です。ネットワークの疎通性は、システム全体の動作を制御する上での基本的な要件となるため、これを適切に設計することが成功の鍵となります。

たとえば、クラウド環境間での接続を確立するには、IPSec VPNやAWS Direct Connect、Azure ExpressRouteなどの接続方法を検討する必要があります。これらはいずれも安全かつ高速な接続を実現する方法ですが、利用するサービスによって設定プロセスが異なるため、自分の環境に適した方法を選択してください。

ここではクラウド環境間接続については一旦置いておいて、それぞれ個別のネットワークを割り当てるよう構成します。

・Azure（東）- 10.140.0.0/16
・Azure（西）- 10.142.0.0/16
・AWS（東）- 10.154.0.0/16
・AWS（西）- 10.156.0.0/16

リソース設計に関しては、事前に必要なリソース数を見積もり、それに応じた仮想ネットワーク（VPC/VNet）やサブネット、ルーティングテーブルの構成を行うことが必要です。さらに、実際の接続テストを行う際には、Cloud Connector専用のサブネットを特定し、自動化されたルーティングポリシーで効率的なトラフィック転送を設定します。また、DNSリゾルバーの構成も非常に重要です。Zscaler ZPAでは、名前解決が正しく行われないと期待する動作が実現できません。そのため、各クラウドネットワーク内で正しいDNS設定を維持することが求められます。

今回のガイドでは簡易な形でNATゲートウェイやを用いセキュリティグループなどの疎通はBYOオプションは（既存のものやUIやaws ec2やiamなど）を使わず今回のツールが行うため一旦おいておく形になりますが、Zscalerのクラウド環境（例: zscalerthree.net, private.zscaler.com, zpatwo.netなど）との通信を確保することは、ZPAやZIAのサービスが動作する上で必要不可欠な基盤であり、疎通が確立されない場合、セキュアなトラフィック転送や認証処理、ZPAの動作や機能に支障が生じます。適切に接続性を確認し、クラウドへのトラフィックを効率的にNATやルーティングすることは、疎通性のテストやリソース間の通信の最適化を確実に行う必要があります。

最後に、システムの信頼性を向上させるために、高可用性（HA）構成を設計に組み込むことを確認します。ここでは構成によりツールでデフォルト2つの複数のAZ（Availability Zone）間でリソースを分散させることで、障害が発生してもシステムは迅速に切り替えられるようなテストができます。具体的には、各AZ用のElastic IPやCloud Connectorには本番環境など必要となる負荷分散のためのロードバランサーを配置し、アクセス集中時でも安定したパフォーマンスを維持できるようにデプロイできます。ただ、リソース数に関する制限にも注意してください。例えば、VPCやElastic IPの数が各リージョンの最大設定数などを満たしているかどうかを確認する必要があります。

ここではAWS環境をCloud Connector 1台構成、Azure環境をALBを用いたCloud Connector複数台の環境で構成し、必要なモニタリング方法などを検証できるようにします。

AWS上へのCloud Connectorのデプロイ

Cloud ConnectorをAWS上でデプロイする場合、VMのサイズや通過する通信を確認し、サイジング含めた構成の選択と、それに基づくリソースの準備を確実にします。ここでは、AWS環境にCloud ConnectorをデプロイしてZscalerクラウドと連携し、ZPAやZIAなどのサービスで必要な通信環境を提供する方法について詳しく解説します。この作業を通じて、ワークロードのテストなどを通じてトラフィックの効率的な転送を見極め、転送ポリシーやIPアドレス、DNS範囲を追加することでZscaler Client Connectorとの双方向の通信など機能面のテストが可能な構成を構築します。

Starter Deployment Template with ZPAを使用した展開の概要

AWS環境でCloud Connectorをデプロイする際には、"Starter Deployment Template with ZPA"の利用をまず行ってみます。このテンプレートは、新規の仮想プライベートクラウド（VPC）内にCloud Connectorを展開すると同時に、ZPAで必要となるDNSリゾルバー機能を実現するRoute 53のエンドポイントといった付加機能もついでに設定してくれるものです。このテンプレートの利用によって、VPCや各コンポーネントの多くの手動設定を最小限に抑えることができるため、特に初心者の方や短い時間で環境を準備したい方には非常におすすめです。

まず、テンプレートを利用するためのAWS環境について、以下のような条件が満たされている必要があります。

AWS環境の必須条件

AWSアカウントの準備:
利用するAWSアカウントには、VPCやEC2など必要なすべてのリソースを作成する権限（管理者権限）が付与されている必要があります。この権限がないと、Terraform経由でリソース作成時に権限エラーが発生する可能性があるため、事前に確認してください。

EC2のリソース確認:
Cloud Connectorで使用されるリソースや仮想マシンサイズについて確認しておきます。同様に、Amazon Linux 2を利用するワークロードをデプロイする場合や追加でWindowsをデプロイして試験を行うような場合も確認しておきます。
Cloud Connectorインスタンスのタイプ指定例 - terraform.tfvars

## 6. Cloud Connector AWS EC2 Instance size selection. Uncomment ccvm_instance_type line with desired vm size to change.
##    (Default: m6i.large)

ccvm_instance_type                         = "t3.medium"
#ccvm_instance_type                         = "m5n.large"
#ccvm_instance_type                         = "c5a.large"
#ccvm_instance_type                         = "m6i.large"
#ccvm_instance_type                         = "c6i.large"
#ccvm_instance_type                         = "c6in.large"

APIキーの設定:
Terraformによる自動化を行うには、AWS CLI（コマンドラインインターフェース）またはスクリプト時に対話式で必要な認証情報を入力する必要があります。これにはアクセスキーID（AWS_ACCESS_KEY_ID）とシークレットアクセスキー（AWS_SECRET_ACCESS_KEY）の設定が必要です。
AWS Secrets Managerの活用:
Cloud ConnectorのAPI認証情報（例えば、Zscalerから取得したAPIキー）がAWS Secrets Managerに安全に保存されていること。これにより、Terraformのスクリプトから動的にアクセスできる設定が可能になります。

以上のように、事前に正しい環境が整備されることで、テンプレートを使った展開プロセスをスムーズに進めることができます。

Terraformセットアップと実行手順

これまでに環境の事前準備ができたら、Terraformを使ってCloud Connectorと関連リソースをAWS上にデプロイします。このデプロイは、Terraformコードを使ってすべてを自動化することで、複雑な設定やヒューマンエラーを防ぐ仕組みとなっています。

Terraformのダウンロードと初期化：
Terraformを公式サイトからダウンロードし、システムにインストールします。MacOSXではHomeBrewなどを使用すると良いでしょう。その後、Cloud ConnectorのTerraformモジュールをクローンして、必要なコードを取得します。モジュールの公式リポジトリは以下の通りです。
- AWS用モジュール https://github.com/zscaler/terraform-aws-cloud-connector-modules.git
  Gitで以下のようにクローンします：
```
git clone https://github.com/zscaler/terraform-aws-cloud-connector-modules.git
cd terraform-aws-cloud-connector-modules
```

Terraform変数ファイルの確認:
examples以下に含まれるテンプレートからどのテンプレートにするかを選択しておきます。

標準展開 (Auto Scalingなし)	高度な展開 (Auto Scaling)
1. プレ導入テンプレート (base)	1. プレ導入テンプレート (base, base_cc_gwlb_asg)
2. スターター展開テンプレート (base_1cc)	2. Auto Scalingとゲートウェイロードバランサー(GWLB)付きスターター展開テンプレート (base_cc_gwlb_asg)
3. ゲートウェイロードバランサー (GWLB)付きのアドオンテンプレート (省略可) (base_cc_gwlb)	3. ZPA付きアドオンテンプレート (省略可) (base_cc_gwlb_asg_zpa)
4. ZPA付きアドオンテンプレート (省略可) (base_1cc_zpa)	4. 高可用性のクラスタ構成のテンプレート (cc_ha)

また各テンプレート内に、Terraform用の設定ファイル（variables.tfやmain.tfと）があるので確認してみながら、Cloud Connectorのインスタンス構成やネットワーク情報、IAMロールの設定を想定します。直接terraform.tfvarsを定義する場合はterraformコマンドを使用したTerraformの手動のデプロイを行います。例えば、以下のような設定ファイルを作成します。認証情報（APIキー、ユーザー名、パスワード）をAWS Secrets Managerに安全に保存し、Cloud Connector用の有効なプロビジョニングURLを生成し、この情報を利用します。

 cc_vm_prov_url                             = "connector.zscalertwo.net/api/v1/provUrl?name=PSXX4zscc"
 secret_name                                =  "ZS/CC/credentials/PSXX4zscc"
 http_probe_port                            = 50000
 name_prefix                                = "PSXX4zsccw"
 aws_region                                 = "ap-northeast-1"
 ccvm_instance_type                         = "t3.medium"
 cc_instance_size                           = "small"
 az_count                                   = 2
 cc_count                                   = 2
 vpc_cidr                                   = "10.154.0.0/16"
 workload_count                             = 2
 domain_names = {
   appseg1 = "zscaler.com"
   appseg2 = "sakura.ne.jp"
 }

初期化とデプロイ実施：
このスクリプトセットには、完全自動化されたデプロイメント用のコードが含まれており、「Greenfield」と呼ばれる新規環境の展開や、「Brownfield」と呼ばれる既存環境への統合のどちらにも対応しています。
zsec upコマンドを実行し、対話式のプロンプトに従ってデプロイテンプレートの選択とAWSのクレデンシャル情報を入力します。

% ./zsec up
1) greenfield - Recommended for isolated test/POV deployments. Creates new network infrastructure, test workloads, and a public bastion host
2) brownfield - Recommended for prod deployments. Bring-your-own existing network infrastructure customizations + no workload/bastion creation
Select desired deployment: 1
Greenfield deployment selected...
**Caution** These deployments include test workloads and publicly accessible bastion hosts and are intended primarily for lab/test environments

1) Deploy 1 Cloud Connector in a new VPC
2) Deploy 1 Cloud Connector in a new VPC with Route 53 rules for ZPA
3) Deploy multiple Cloud Connectors + Gateway Load Balancer in a new VPC
4) Deploy multiple Cloud Connectors + Gateway Load Balancer in a new VPC with Route 53 rules for ZPA
5) Deploy Auto Scaling Cloud Connectors + Gateway Load Balancer in a new VPC
6) Deploy Auto Scaling Cloud Connectors + Gateway Load Balancer in a new VPC with Route 53 rules for ZPA
7) Deploy a new VPC - No Cloud Connector resources
Select desired deployment type: 2
Deployment type base_1cc_zpa selected...
Discovering processor architecture...
Detecting OS...
OS is MacOS_arm64
Creating a local bin directory if not present...
Updating .zsecrc with dtype of base_1cc_zpa
Checking Cloud Connector provisioning info

つづいてCloud Connectorのインスタンスサイズ、EC2のタイプ、管理画面から取得したプロビジョニングURL、LBのプローブポート、デプロイするリージョンを確認します:

1) small
2) medium
3) large
Select desired Cloud Connector Instance Size: 1
Cloud Connector size: small
1) m6i.large - Recommended
2) m5n.large
3) c6i.large
4) c6in.large
5) t3.medium - Not recommended for production use
Select AWS EC2 instance type for small Cloud Connector: 5
CC EC2 type: t3.medium
Enter CC Provisioning URL: connector.zscalertwo.net/api/v1/provUrl?name=PSXX4zscc
Enter AWS Secrets Manager Secret Name from Secrets Manager: ZS/CC/credentials/PSXX4zscc
Enter CC service HTTP health probe port number. Valid input = 80 or any number between 1024-65535 [Default=50000]: 
Valid HTTP probe port input of 50000
base_1cc_zpa will deploy one Cloud Connector in ap-northeast-3
base_1cc_zpa will deploy resources in one Availability Zone subnet in ap-northeast-3
Enable EBS volume encryption? (yes/no) Recommendation is yes: no
EBS encryption will be disabled
How many Domain/FQDN application segments to add to Route 53 Resolver Rule? 2
2 domains to enter...
Enter a single ZPA Domain/FQDN: zscaler.jp
Enter a single ZPA Domain/FQDN: zscaler.net
Enable IAM permissions for cloud workload tagging? (yes/no): yes
SQS/SNS IAM Policies will be enabled for Cloud Connector Instance Profiles
By default, an outbound Security Group rule is configured enabling Zscaler remote support access. Would you like to disable this rule creation? [Default=no]: 
Outbound rule permitting TCP/12002 access to 199.168.148.101/32 will be created
Updating .zsecrc with dtype of base_1cc_zpa

または対話式ではなく手動の設定でTerraformを初期化 (terraform init) し、実際にデプロイを実行します。

base_cc_gwlb_zpa % terraform apply                         
module.workload.data.local_sensitive_file.zscaler_root_cert: Reading...
module.workload.data.local_sensitive_file.zscaler_root_cert: Read complete after 0s [id=fc68908984818e8c03d8e6749a0badb7fdf01fd3]
module.cc_iam.data.aws_iam_policy_document.cc_metrics_policy_document: Reading...

出力結果（設定リソースの確認）：
デプロイが完了すると、Terraformによって作成されたリソースの情報が出力されます。この情報には、Cloud ConnectorのインスタンスIDやパブリックIP、サブネット情報、ロードバランサー情報などが含まれます。この内容は後の構成確認やトラブルシューティングにおいて役立つため、保管してください。
例えば、出力されるサンプルデータは以下のようになります：
```
Login Instructions & Resource Attributes

CLOUD CONNECTOR Details/Commands:
SSH to CLOUD CONNECTOR
ssh -F ssh_config ccvm-0

CLOUD CONNECTOR Management IPs:
ccvm-0 = 10.154.200.196

CLOUD CONNECTOR Instance IDs:
i-0e946574ddeea7896

CLOUD CONNECTOR Forwarding/Service IPs:
10.154.200.222

CLOUD CONNECTOR Forwarding/Service ENIs:
eni-0bbb48f25220e54a7

CLOUD CONNECTOR AZs:
ap-northeast-1a
...
VPC:         
vpc-05bc97e1e9fb7aaf3

Zscaler Subnet IDs:
subnet-09346be19866b2dee
...
```
VPCやEC2の確認：
Cloud ConnectorやWorkload、Bastionのインスタンスが起動していることを確認します。
Cloud Connectorの監視：
Cloud and Branch Connectorの管理画面から稼働状況を確認するためにCloud Connectorの監視メニューから地理的マッピングと合わせて稼働状況を確認します。

Azure上へのCloud Connector＋LB＋ZPAのデプロイ

次に、Azure環境上でCloud Connectorをデプロイする手順について解説します。Azureの場合、特にService Principalの利用やAzure Key Vaultなど、AWSとは異なるクラウドサービスが登場しますが、基本の構成手順に沿って進めることで、安全かつ効率的な展開を行えます。
Azureでは、ロードバランサー（LB）を含めた構成のCloud Connectorデプロイを行います。この設計は、スケーラビリティの実現や、ネットワークやサービスの冗長性を確保する場合にも非常に有用です。AzureでもAWS同様、Zscaler公式のTerraformスクリプトを活用して効率よく環境を整えることができます。

Azureの初期設定と作業概要

Azure上にCloud Connectorをデプロイする際には、最初に必要なサブスクリプション情報を持つIDでのアクセスを行い、やAzure固有の設定情報を定義する必要があります。Azureのサービスプリンシパルの作成からKey Vaultの活用、ロール管理やVMイメージの承諾まで、準備段階での適切な取り組みを行います。

Azure Key Vaultの設定

AzureのKey Vaultの設定では、ロールベースのアクセス制御を利用することが推奨されています。この制御方法を選択すると、リソースのアクセス管理が効率化され、安全性が確保されます。初めに、Key Vaultのアクセス構成では、Azureリソースマネージャーをリソースアクセスの方法として設定する必要があります。
その後、リソースを分類するためにタグを付け、すべての準備が整った段階でKey Vaultの作成を実行します。作成が完了すると、Key Vaultの概要ページでは、展開の状況やリンクが表示され、そのリソースに直接移動できるようになります。

Key Vaultのリソースが作成された後、そのアクセス制御を構成します。マネージドアイデンティティに必要な権限を付与するために、アクセス制御設定ページでロール割り当てを実施します。この段階で、Key Vaultシークレットユーザーというロールを追加し、適切な権限が付与されるよう設定します。さらに、Cloud Connectorのマネージドアイデンティティを選択し、それをKey Vaultシークレットユーザーとして登録します。このプロセスでは、マネージドアイデンティティとKey Vaultの連携を確立するため、事前に作成したリソースが正しく紐付けられることを確認します。

Azure Key Vaultは、Zscaler Cloud Connectorで使用する認証情報をセキュアに保管するためのツールです。Key Vaultに保存するシークレットを作成します。アクセス制御の構成が完了すると、Key Vaultの設定内容を確認し、Cloud Connectorからの接続が行えるよう準備しAzure環境内でのデプロイが可能な状態にします。
以下の情報を保存するアカウント情報として事前に構成します：

Zscaler Cloud Connector用のプロビジョニングURL（Zscalerポータルから生成可能）
API Key、ユーザー名、およびパスワード

これらの情報はKey Vaultに保存し、Cloud Connector展開時に安全に利用できるようにします。

次に、Azure用Terraformモジュールを使った展開手順について解説します。こちらはAWSと同様のプロセスをたどります。

Terraformのセットアップとモジュールの準備

Azure環境でCloud ConnectorをデプロイするためのTerraformは、公式モジュールを利用したコードをベースに構成されています。このモジュールを使用することで、必要なリソースが自動的に作成され、Zscaler環境と効率的に連動するネットワークインフラを構築することが可能です。

まず、Azure用の公式Terraformモジュールを準備します。それに加えて、Azure環境のリソース構成を定義するための変数ファイルを作成する必要があります。

Terraformモジュールの取得:
Terraformモジュールを取得するには、公式のGitHubリポジトリからクローンします。
```
git clone https://github.com/zscaler/terraform-azurerm-cloud-connector-modules.git
cd terraform-azurerm-cloud-connector-modules
```
このリポジトリ内には、標準的なセットアップを容易に実行できるサンプルコードがあります。特に"examples"フォルダ内に格納されているすぐに利用可能なサンプルスクリプトは、テンプレートとしてカスタマイズを始める際に有用です。

Terraform変数ファイルの編集:
tarrraform.tfvarsファイルを開き、Azure環境で使用するためのサブスクリプションID、Resource Group名、場所（リージョン名）、VNetおよびそのサブネット情報を記述します。また、Key VaultのURLや認証情報も明記してください。

  env_subscription_id                        = "88ad672d-0da6-44d2-ac3e-xxxxxxxxxxx"
  cc_vm_prov_url                             = "connector.zscalertwo.net/api/v1/provUrl?name=Azure_CloudConnector_Template"
  azure_vault_url                            =  "https://xxxx-zs2-kv.vault.azure.net/"
  http_probe_port                            = 50000
  managed_identity_subscription_id           = "88ad672d-0da6-44d2-ac3e-xxxxxxxxx"
  cc_vm_managed_identity_name                = "PSXX-ZS2-UAMI"
  cc_vm_managed_identity_rg                  = "PSXX-ZS2-RG"
  name_prefix                                = "PSXX-ZS2"
  arm_location                               = "japaneast"
  ccvm_instance_type                         = "Standard_D2s_v3"
  cc_count                                   = 2

例えばALBの構成はmain.tfファイル内に設定例として記載されていますので参考になります：

################################################################################
# 7. Create Azure Load Balancer in CC VNet with all Backend Pools, Rules, and
#    Health Probes
################################################################################
# Azure Load Balancer Module variables
module "cc_lb" {  
  source                = "../../modules/terraform-zscc-lb-azure"
  name_prefix           = var.name_prefix
  resource_tag          = random_string.suffix.result
  global_tags           = local.global_tags
  resource_group        = module.network.resource_group_name
  location              = var.arm_location
  subnet_id             = module.network.cc_subnet_ids[0]
  http_probe_port       = var.http_probe_port
  load_distribution     = var.load_distribution
  zones_enabled         = var.zones_enabled
  zones                 = var.zones
  health_check_interval = var.health_check_interval
  probe_threshold       = var.probe_threshold
  number_of_probes      = var.number_of_probes
}

結果的には下記のようなデプロイ結果となります（LBのバックエンドプールにCloud Connector 2VMのサービスIPが指定されている）

この設定ファイルを使用することで、Terraformは自動的に指定されたAzure環境に接続し、必要なリソースを作成します。

デプロイ

Terraformの設定を確認し必要に応じ記述した後、Azure上にVnetやCloud Connectorをデプロイします。
デプロイが成功すると、Terraformが作成したリソースの情報が画面に出力されます。これには、デプロイされたCloud ConnectorのパブリックIPやプライベートIP、ロードバランサーのバックエンドプール構成、仮想ネットワークのアドレス範囲などが含まれます。この出力を活用して、AzureポータルやCLIでリソースの状態を確認することができます。

Azure環境の構成細部と確認

Azure上では、AWSとは若干異なるリソース構成が必要になるため、それぞれのリソースの役割を理解することが重要です。上記を通して下記のネットワーク構成の細部を確認ください。

Azure VNetおよびサブネットの設定が正しく行われていること
- 仮想ネットワーク（VNet）のルーティングテーブルが定義され、期待される通信が行われること
- Cloud ConnectorのサービスIPに向けた通信が対象とされていること
- ZIAやZPA用の通信がルーティングされ、セキュリティグループの定義やその他の通信の扱いについて定義されること
デプロイに使用するロードバランサーのフロントエンド/バックエンド設定を構成するための十分な権限が付与されていること

仮想ネットワーク（VNet）の確認：
デプロイ後、Azure Portalで作成した仮想ネットワーク（VNet）を確認しましょう。

Cloud Connectorが配置されたサブネットが正しく構成されている場合、ポータル上でそのサブネットやアドレス空間が視覚的に確認できます。
ロードバランサーの構成の確認：
Terraformを使用することで、Zscalerクラウドと連携するロードバランサーが自動的に作成されます。このロードバランサーは、Cloud Connector用のバックエンドプールを構成するための重要な役割を果たします。Azure Portalからバックエンドプールやフロントエンド構成を確認し、リクエストが正しくリダイレクトされていることを確認する必要があります。
Cloud Connectorの設定と動作確認：
Cloud Connectorについて、デプロイが完了、仮想マシンが起動し設定は適用済であれば通信要件である宛先への疎通はできていそうかを確認します。Zscaler管理コンソール上からはCloud Connectorの準備状況や確認を行います。この場合はALBのステータスなども合わせて確認しておきます。
通信確認とテスト：
配置が完了したCloud Connectorを経由して行われる通信をテストします。前提となるルーティングやNATゲートウェイを確認したり、トラフィック転送のルールの動作、
例えば、想定されたURLやネットワークトラフィックがZscalerクラウドに適切に転送され、ZPAやZIAの設定が意図通り動作しているかを確認します。

ログを確認する場合はLogs / Branch & Cloud Connectors / Session Insights / Logs
より確認可能です。セッションログフィルタでClient Destination IPとClient Source IPを指定したり、
Infrastracture > Connectors > Cloud > Managementで「運用ステータス」が「非アクティブ」か「アクティブ」かを確認します。「非アクティブ」のものではCloud Connector仮想マシンの稼働状況を確認し、アクティブになるようします。

まとめ

ここでは、AWSとAzure環境を東西にデプロイすると同時にCloud Connectorも加えてTerraformを使って効率的にデプロイするための手順について、詳細に解説しました。自動化テンプレートを活用することで、複雑な設定を一度に実行できるだけでなく、プロセス自体を再現可能で拡張性の高いものにすることができます。このガイドを参考に、クラウド環境で高いセキュリティと接続性を実現し、Zscalerとの統合を成功させてください。BYOのネットワーク構成との連携や、WAN側の設計を置き換えることも考えられるでしょう。

さらに、構成が完了したら、環境が正しく動作していることを継続的に観察し、変更や改善点の適用をTerraformコード上で管理することを推奨します。こうすることで、インフラ構成の透明性が確保され、チーム内の他のメンバーとも簡単に設定を共有できるようになります。

Terraformを活用したCloud Connectorのデプロイは、初心者でも障壁なく行えるように設計されています。App Connectorの配置もTerraformにより自動化可能です。この記事をもとにZscalerのゼロトラスト対応のAWSやAzure上でのネットワーク環境構築や設計検討をスムーズに進めていただければ幸いです！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

東西AWS/Azure 4つの環境へのZscalerのデプロイガイド（Terraform/Cloud Connector編 ）