Ztw 226 readme (#12)

* docs(readme) update ha deprecate

* docs(readme) link update

CHANGELOG.md

@@ -1,5 +1,5 @@
-## 0.1.0 (July 25, 2022) 
-* github release refactor
+## v0.1.0 (December 15, 2022) 
+* github release refactor from Cloud Connector Portal
 * zsec update for terraform support up to 1.1.9 and aws provider 4.7.x
 * zsec updated with mac m1 option for terraform arm64 version download
 * modules renamed for granularity and consistency

README.md

@@ -54,15 +54,21 @@ Use the [**Starter Deployment Template**](examples/base_1cc/) to deploy your Clo
 
 Use the [**Starter Deployment Template with ZPA**](examples/base_1cc_zpa) to deploy your Cloud Connector in a new VPC with ZPA DNS resolver capability.
 
-### **Starter Deployment Template with ZPA and High Availability**
+### **Starter Deployment Template with High Availability (deprecated)**
 
-Use the [**Starter Deployment Template with ZPA and High Availability**](examples/base_2cc) to deploy your Cloud Connector in a new VPC with ZPA DNS resolver capability. This template achieves high availability between two Cloud Connectors and sets up data traffic across multiple TCP connections. 
+Use the [**Starter Deployment Template with High Availability**](examples/base_2cc) to deploy your Cloud Connector in a new VPC with lambda health monitoring for failover. This template achieves high availability between two Cloud Connectors and sets up data traffic across multiple TCP connections.
+
+- **Note** This is only available as reference for legacy users. Zscaler's recommended deployment method is Gateway Load Balancer (GWLB), which distributes traffic across multiple Cloud Connectors and achieves high availability.
+
+### **Starter Deployment Template with ZPA and High Availability (deprecated)**
+
+Use the [**Starter Deployment Template with High Availability**](examples/base_2cc_zpa) to deploy your Cloud Connector in a new VPC with lambda health monitoring for failover and ZPA DNS resolver capability. This template achieves high availability between two Cloud Connectors and sets up data traffic across multiple TCP connections.
+
+- **Note** This is only available as reference for legacy users. Zscaler's recommended deployment method is Gateway Load Balancer (GWLB), which distributes traffic across multiple Cloud Connectors and achieves high availability.
 
 ### **Starter Deployment Template with Gateway Load Balancer (GWLB)**
 
-Use the [**Starter Deployment Template with GWLB**](examples/base_cc_gwlb) to deploy your Cloud Connector in a new VPC and to load balance traffic across multiple
-Cloud Connectors. Zscaler\'s recommended deployment method is Gateway Load Balancer (GWLB). GWLB distributes traffic across multiple Cloud
-Connectors and achieves high availability.
+Use the [**Starter Deployment Template with GWLB**](examples/base_cc_gwlb) to deploy your Cloud Connector in a new VPC and to load balance traffic across multiple Cloud Connectors. Zscaler\'s recommended deployment method is Gateway Load Balancer (GWLB). GWLB distributes traffic across multiple Cloud Connectors and achieves high availability.
 
 ## **Brownfield Deployment**
 
@@ -71,6 +77,5 @@ deployment. They also do not include a bastion or workload hosts deployed. See [
 
 ### **Custom Deployment Template with Gateway Load Balancer (GWLB)**
 
-Use the [**Custom Deployment template with GWLB**](examples/cc_gwlb) to deploy your Cloud Connector in a new or existing VPC and load balance traffic across
-multiple Cloud Connectors. Zscaler\'s recommended deployment method is Gateway Load Balancer (GWLB). GWLB distributes traffic across multiple
-Cloud Connectors and achieves high availability. Optional ZPA/Route53 add-on capabilities.
+Use the [**Custom Deployment template with GWLB**](examples/cc_gwlb) to deploy your Cloud Connector in a new or existing VPC and load balance traffic across multiple Cloud Connectors. Zscaler\'s recommended deployment method is Gateway Load Balancer (GWLB). GWLB distributes traffic across multiple
+Cloud Connectors and achieves high availability. Optional ZPA/Route53 add-on capabilities.

examples/README.md

@@ -47,8 +47,8 @@ base: Creates 1 new VPC with 1 public subnet and 1 private/workload subnet; 1 IG
 1 Bastion Host in the public subnet assigned an Elastic IP and routing to the IGW; generates local key pair .pem file for ssh access
 base_1cc: Base Deployment Type + Creates 1 Cloud Connector private subnet; 1 Cloud Connector VM routing to NAT Gateway; workload private subnet route repointed to service ENI of Cloud Connector
 base_1cc_zpa: Everything from base_1cc Deployment Type + Creates 2 Route 53 subnets routing to service ENI of Cloud Connector; Route 53 outbound resolver endpoint; Route 53 resolver rules for ZPA
-base_2cc: Everything from base_1cc + Creates a second Cloud Connector in a new subnet/AZ w/ Lambda for HA failover of workload route tables
-base_2cc_zpa: Everything from Base_2cc + Creates 2 Route 53 subnets routing to service ENI of Cloud Connector; Route 53 outbound resolver endpoint; Route 53 resolver rules for ZPA
+base_2cc (**deprecated**): Everything from base_1cc + Creates a second Cloud Connector in a new subnet/AZ w/ Lambda for HA failover of workload route tables
+base_2cc_zpa (**deprecated**): Everything from Base_2cc + Creates 2 Route 53 subnets routing to service ENI of Cloud Connector; Route 53 outbound resolver endpoint; Route 53 resolver rules for ZPA
 base_cc_gwlb: Base Deployment Type + Creates 4 Cloud Connectors (2 per subnet/AZ) routing to NAT Gateway; Gateway Load Balancer auto registering service ips to target group with health checks; VPC Endpoint Service; 2 GWLB Endpoints (1 in each Cloud Connector subnet); workload private subnet routes repointed to the GWLBE in their same AZ
 base_cc_gwlb_zpa: Everything from base_cc_gwlb + Creates 2 Route 53 subnets routing to service ENI of Cloud Connector; Route 53 outbound resolver endpoint; Route 53 resolver rules for ZPA
 ```
@@ -74,7 +74,7 @@ Optional: Edit the terraform.tfvars file under your desired deployment type (ie:
 
 ```
 Deployment Type: (cc_ha | cc_gwlb):
-cc_ha: Creates 1 new VPC with 2 public subnets and 2 Cloud Connector private subnets; 1 IGW; 2 NAT Gateways; 2 Cloud Connector VMs (1 per subnet/AZ) routing to the NAT Gateway in their same AZ; generates local key pair .pem file for ssh access; Number of Cloud Connectors and subnets deployed, ability to use existing resources (VPC, subnets, IGW, NAT Gateways), and toggle ZPA/R53 and Lambda HA failover features; generates local key pair .pem file for ssh access
+cc_ha (**deprecated**): Creates 1 new VPC with 2 public subnets and 2 Cloud Connector private subnets; 1 IGW; 2 NAT Gateways; 2 Cloud Connector VMs (1 per subnet/AZ) routing to the NAT Gateway in their same AZ; generates local key pair .pem file for ssh access; Number of Cloud Connectors and subnets deployed, ability to use existing resources (VPC, subnets, IGW, NAT Gateways), and toggle ZPA/R53 and Lambda HA failover features; generates local key pair .pem file for ssh access
 cc_gwlb: All options from cc_ha + replace lambda with Gateway Load Balancer auto registering service ips to target group with health checks; VPC Endpoint Service; 1 GWLB Endpoints per Cloud Connector subnet
 ```
 

examples/base_2cc/README.md

@@ -1,4 +1,6 @@
-# Zscaler "Base_2cc" deployment type
+# Zscaler "Base_2cc" deployment type (deprecated)
+
+- **Note** This is only available as reference for legacy users. Zscaler's recommended deployment method is Gateway Load Balancer (GWLB), which distributes traffic across multiple Cloud Connectors and achieves high availability. Please refer to [**Starter Deployment Template with GWLB**](../base_cc_gwlb).
 
 This deployment type is intended for greenfield/pov/lab purposes. It will deploy a fully functioning sandbox environment in a new VPC with test workload VMs. Full set of resources provisioned listed below, but this will effectively create all network infrastructure dependencies for an AWS environment. Everything from "Base_1cc" deployment type (Creates 1 new VPC with 1 public subnet and 1 private/workload subnet; 1 IGW; 1 NAT Gateway; 1 Centos server workload in the private subnet routing to NAT Gateway; 1 Bastion Host in the public subnet assigned an Elastic IP and routing to the IGW; generates local key pair .pem file for ssh access; Creates 1 Cloud Connector private subnet; 1 Cloud Connector VM routing to NAT Gateway; workload private subnet route repointed to service ENI of Cloud Connector)<br>
 

examples/base_2cc_zpa/README.md

@@ -1,4 +1,6 @@
-# Zscaler "Base_2cc_zpa" deployment type
+# Zscaler "Base_2cc_zpa" deployment type (deprecated)
+
+- **Note** This is only available as reference for legacy users. Zscaler's recommended deployment method is Gateway Load Balancer (GWLB), which distributes traffic across multiple Cloud Connectors and achieves high availability. Please refer to [**Starter Deployment Template with GWLB and ZPA**](../base_cc_gwlb_zpa).
 
 This deployment type is intended for greenfield/pov/lab purposes. It will deploy a fully functioning sandbox environment in a new VPC with test workload VMs. Full set of resources provisioned listed below, but this will effectively create all network infrastructure dependencies for an AWS environment. Everything from "Base_1cc" deployment type (Creates 1 new VPC with 1 public subnet and 1 private/workload subnet; 1 IGW; 1 NAT Gateway; 1 Centos server workload in the private subnet routing to NAT Gateway; 1 Bastion Host in the public subnet assigned an Elastic IP and routing to the IGW; generates local key pair .pem file for ssh access; Creates 1 Cloud Connector private subnet; 1 Cloud Connector VM routing to NAT Gateway; workload private subnet route repointed to service ENI of Cloud Connector; Creates a second Cloud Connector in a new subnet/Availability Zone wwith Lambda configured for HA failover of workload route tables between the two Cloud Connectors)<br>
 

examples/cc_ha/README.md

@@ -1,4 +1,6 @@
-# Zscaler "cc_ha" deployment type
+# Zscaler "cc_ha" deployment type (deprecated)
+
+- **Note** This is only available as reference for legacy users. Zscaler's recommended deployment method is Gateway Load Balancer (GWLB), which distributes traffic across multiple Cloud Connectors and achieves high availability. Please refer to [**Custom Deployment template with GWLB**](../cc_gwlb).
 
 This deployment type is intended for brownfield/production purposes. By default, it will create 1 new VPC with 2 public subnets and 2 Cloud Connector private subnets; 1 IGW; 2 NAT Gateways; 2 Cloud Connector VMs (2 per subnet/AZ) routing to the NAT Gateway in their same AZ; generates local key pair .pem file for ssh access; BYO ability to use existing resources (VPC, subnets, IGW, NAT Gateways), and toggle ZPA/R53 and Lambda HA failover features; generates local key pair .pem file for ssh access; Gateway Load Balancer auto registers service IPs to target group with health checks; VPC Endpoint Service; 2 GWLB Endpoints (1 in each Cloud Connector subnet)<br>
 

modules/terraform-zscc-lambda-aws/README.md

@@ -1,5 +1,7 @@
 # Zscaler Cloud Connector / AWS Lambda Module
 
+- **Note** This is only available as reference for legacy users. Zscaler's recommended deployment method is Gateway Load Balancer (GWLB), which distributes traffic across multiple Cloud Connectors and achieves high availability. Please refer to GWLB modules: [**GWLB**](../terraform-zscc-gwlb-aws) and [**GWLB Endpoint**](../terraform-zscc-gwlbendpoint-aws).
+
 This module creates all the necessary IAM Roles/Polices, Lambda Functions/Permissions, and Cloudwatch Events required for a successful Cloud Connector HA/Lambda deployment. The intent of this module is to provide inputs for a pair of Cloud Connectors as well as private/workload route tables currently forwarding default route traffic to each respectively. Lambda monitors the health status of both Cloud Connectors and automatically updates the workload route tables to forward traffic to the healthy Cloud Connector in the event one goes down.<br> 
 
 *** For production deployments and better scaling/resliency, we highly advise leveraging Gateway Load Balancer (GWLB) rather than this Lambda.