Option 2: Deploy a centralized virtual appliance with Gateway Load Balancer

Complete the following steps to deploy the ingress and egress traffic routing architecture for Gateway Load Balancer in your AWS environment.

Create the Macro template stack

  1. Log in to your AWS account.
  2. Click this link to create the Macro CloudFormation stack.
  3. Leave any parameters on their default settings, then click Create stack.

Create the Security VPC template stack

  1. Log in to your AWS account.

  2. Click one of the following links to create the Security VPC CloudFormation stack:


    NOTE

    The version you select is dependent on if you created your Cloud One account before or after August 4th, 2021. Learn more.


  3. On the Specify stack details page, enter the following parameters:

    • Availability Zones (AZ): Choose all of the AZs used in your Workload VPC.
    • Security VPC CIDR Block: Enter a VPC CIDR for the Security VPC.
    • SSH Key Pair: Select the name of your SSH key.
    • CloudOne API key: Enter your Trend Micro Cloud One API key. Learn more.
    • Network Security Instance AMI: Enter the latest Network Security AMI ID. Make sure the correct region is selected for the AMI ID. Learn more.
    • Number of instances: Select the number of Network Security instances that you want to create in each AZ.
    • Instance Type: Leave the default setting.
    • Enable Inspection logs: If enabled, NSVA Inspection Logs are published to the CloudWatch log group network_security_logs.
  4. Follow the rest of the steps for the stack options, then click Create stack.

  5. After the stack is created, click Stack details and then click Outputs.

  6. Copy the value for the Gateway Load Balancer Endpoint service name to use when you create the Gateway Load Balancer Endpoint in the Workload VPC.

Configure Workload VPCs

Add the following resources to your Workload VPCs.


NOTE

Repeat the steps in each of these sections for each Workload VPC in your environment.


Cross-account deployments

Note the following information if you want to use a cross-account deployment in your environment.

If you deploy in multiple AWS accounts, the Gateway Load Balancer Endpoint Service in AWS Account A must first be shared with AWS Account B. This allows AWS Account B to create the Gateway Load Balancer endpoint to connect to the service.

When the Gateway Load Balancer Endpoint Service is created using the CloudFormation template, the AcceptanceRequired value is set to false. This indicates that requests from the service consumers to create an endpoint to your service will be automatically accepted. You can enable this setting to be able to accept or reject endpoint requests manually by modifying the endpoint acceptance setting. Learn more.

Refer to Adding and removing permissions for your endpoint service for more detailed information.

Availability Zone mapping

When you deploy in multiple AWS accounts, an AZ in one account does not always map to the same physical location as an AZ with the same name in a different account. Make sure that AZs in different AWS accounts map to the same physical location by using AZ IDs to map AZs across accounts. Learn more.

Create subnet

Create a Gateway Load Balancer Endpoint subnet for each AZ with a Gateway Load Balancer Endpoint. We recommend that you use a small CIDR block, like /28.


NOTE

If you are using cross-account deployment, make sure to select the correct AZ for this subnet for AZ mapping. Learn more.


Create a Gateway Load Balancer Endpoint for each AZ

  1. From the AWS Management Console, navigate to the VPC Dashboard.
  2. Under Virtual Private Cloud, click Endpoints, and then click Create Endpoint.
  3. For Service category, select Find service by name.
  4. Enter the value that you copied for the Gateway Load Balancer Endpoint service name when you created the Security VPC stack.
  5. For VPC, select your Workload VPC and the Gateway Load Balancer Endpoint subnet.
  6. Click Create endpoint.

Create or modify your route tables

Navigate to the VPC Dashboard, and click Route Tables to create new route tables or modify existing route tables.

1. Create the edge association route table

Name tag: Edge association route table

VPC: Workload VPC

Edit routes


NOTE

Add this route for each AZ in your Workload VPC.


Destination Target
<WORKLOAD_SUBNET_CIDR> (for each AZ) Select the Gateway Load Balancer endpoint in the corresponding AZ.

Create edge association

Create an edge association for this route table. Select the edge association route table, and click on the Edge Associations tab. Click Edit edge associations, and under Associated gateways, select the Internet Gateway and any Virtual Private Gateways that you want to inspect from the drop down list.

2. Create the Gateway Load Balancer Endpoint subnet route table

Name tag: Gateway Load Balancer Endpoint subnet route table

VPC: Workload VPC

Edit routes

Destination Target
0.0.0.0/0 Internet Gateway

Create subnet association

Select the Gateway Load Balancer Endpoint subnet route table, click on the Subnet Associations tab, click Edit subnet associations, and select the Gateway Load Balancer Endpoint subnet that you created. Create a subnet association for this route table for each subnet that you created for every AZ.

3. Create the Workload subnet route table

Name tag: Workload subnet route table

VPC: Workload VPC


NOTE

Create this route table for each AZ in your environment.


Edit routes

Destination Target
0.0.0.0/0 Select the Gateway Load Balancer endpoint in the corresponding AZ.

Create subnet association

Select the Workload subnet route table, click on the Subnet Associations tab, click Edit subnet associations, and select the Workload subnet that you created. Create an association for each Workload subnet route table that you create for each AZ.


NOTE

Ensure that you create a route table for each of your public subnets that is not associated with the other public subnets.


High availability overview

This Gateway Load Balancer deployment enables several layers of high availability that provide protection to your environment as well as continuous traffic flow.

Failover high availability distributes traffic equally to any virtual appliance available for inspection in your network. If a virtual appliance stops inspecting traffic, the current connections to that appliance are interrupted, but new connections are sent to the remaining available virtual appliances. Failover high availability is enabled automatically when you deploy Gateway Load Balancer. Cross-zone load balancing adds another layer of functionality by directing traffic between AZs. Learn more.

If for some reason there are no available virtual appliances to inspect traffic, fail open high availability ensures that traffic bypasses the virtual appliance to continue flowing without interruption. Follow these steps to deploy fail open HA.

Cross-zone load balancing

Cross-zone load balancing further ensures that your environment has failover protection by sharing traffic between AZs. Additionally, cross-zone load balancing enables all of the virtual appliances that you deploy across multiple AZs to inspect traffic. This optimizes the use of all of your virtual appliances instead of allowing instances to remain idle until failover high availability is needed. Learn more.


NOTE

Enabling cross-zone load balancing increases the cost generated for regional data transfer between AZs.


The image below shows an example of an environment with cross-zone load balancing. Learn more.


Deploy fail open HA

Fail open HA ensures that network traffic continues to flow by bypassing a failed virtual appliance. Fail open HA makes sure traffic is not interrupted if there are no functional virtual appliances available to inspect traffic. Complete the following sections to enable fail open HA in your environment.

Create the IAM role stack for cross-account deployments

Create the IAM role stack to allow Network Security to bypass inspection across all of your AWS accounts. In order to bypass inspection, Network Security changes routes in the Workload VPCs. If your Workload and Security VPCs are in different AWS accounts, Network Security requires permission to make route changes across these different accounts. Learn more.

Complete the following steps to generate cross-account roles in each of your accounts that include a Workload VPC.

  1. Log in to the AWS account that you used to create the Workload VPCs.
  2. Navigate to the Outputs section of the already deployed Security VPC template stack, and copy the External ID value.
  3. Click this link to create the IAM Role stack in your Workload accounts.
  4. Enter the following information:
    • The external ID that you copied in step 2.
    • Your Security VPC account ID.
  5. Click Create stack.

Create the HA stack

After you have enabled the correct permissions, you can create the stack needed to deploy HA.

  1. Log in to the AWS account that you used to deploy the Security VPC template stack.
  2. Click this link to create the HA stack.
  3. On the Specify stack details page, enter the Security VPC stack name that you already created.
  4. Follow the rest of the steps for the stack options, then click Create stack.

Removing the Security VPC CloudFormation stack

  1. From the AWS management console, navigate to the EC2 dashboard.
  2. Under Auto Scaling, click Auto Scaling Groups.
  3. Select the check box next to your Auto Scaling group. A split pane that shows information about the selected group opens at the bottom of the Auto Scaling groups page.
  4. On the Details tab, change the current settings for minimum, maximum, and desired capacity to 0. The Auto Scaling group status will change to Updating capacity. This will automatically delete the Network Security virtual appliance instances and unregister them from Cloud One.
  5. Verify that the Starting Bypass message in the HA CloudWatch logs appears.
  6. Delete the Gateway Load Balancer Endpoint.
  7. Delete the IAM Role Stack deployed across your AWS Accounts.
  8. Delete the HA stack in your Security VPC AWS account.
  9. After the Updating capacity status clears, delete the CloudFormation stack.