Networking & Content Delivery
Securing VPCs Egress using IDS/IPS leveraging Transit Gateway
In a typical enterprise network, customers have VPCs across multiple accounts within an AWS Region to segment workloads. This segmentation can take different forms and depends on the company structure, security policy, business functions, and model. The drivers of the segmentation can vary. For example, segmentation could be driven by security and regulatory requirements, costs, or technology.
Different VPCs and applications can have different requirements for reaching out to resources on the internet, such as to download updates or communicate with other internet-based applications. It can be a complex task to meet your business requirements with a secure outbound internet architecture using Independent Software Vendor (ISV) firewalls that is able to perform inline deep packet inspection in AWS.
Security features like security groups and network ACLs help build a layered network defense for your VPC. NAT gateways can be used to access the internet. However, they don’t provide the advanced traffic inspection features that your business might require, such as antivirus, web filtering, and data loss prevention.
To perform inline deep packet inspection, customers typically use ISV firewall solutions in their AWS environment. These security solutions can be hosted in every VPC and account. However, this type of design doesn’t scale well, becomes difficult to manage, and can become costly. Centralizing your security solutions in a VPC and using intra-VPC connectivity helps solve these challenges.
In this post, we show you an architecture that uses AWS Transit Gateway to set up a hub VPC that hosts a centralized security solution. This allows you to inspect internet-bound traffic from different VPCs in a simplified, centralized, and scalable fashion.
Architecture
Transit gateways allow multiple ways to route traffic to and from the VPCs that are running your AWS Marketplace firewalls supporting different modes of configurations.
How to integrate third-party firewall appliances into an AWS environment provides details on the design considerations for possible architectures to attach your VPCs to a transit gateway.
When deploying a firewall solution, we recommend that you deploy it in multiple Availability Zones. Within a zone, you can deploy the firewalls as standalone instances, or configure them as a cluster. The specific implementation details vary by firewall vendor.
When deploying as a cluster, the cluster members synchronize the configuration and firewall state information. This allows for a quicker failover within the same Availability Zone in case of issues with a single member of that cluster.
In this architecture, we have configured the firewall solution as a cluster in each Availability Zone in active-passive mode. In active-passive mode, one firewall actively manages traffic while the other is synchronized and ready to transition to the active state. When a failure occurs, the load distribution among the firewalls doesn’t change as the passive node picks up the traffic from the active firewall. This provides an automated device failover among the cluster.
We then use Border Gateway Protocol (BGP) to fail over across Availability Zones in case both firewalls in a cluster in a specific Availability Zone become unavailable. We selected the active-passive deployment method because it is the common method recommended by firewall vendors when deploying in cloud environments. It allows for quick failover within a single Availability Zone if there are issues with one of the firewall instances.
We demonstrate hosting the Fortinet firewalls from an AWS Security Hub VPC and cluster them in active-passive mode. VPN attachments are created on the active Fortinet firewall from the transit gateway. We’ve decided to use Fortinet because of our previous experience with Fortinet FortiGate. However, the architecture presented in this post can be implemented with any partner firewall vendors listed in Additional Resources section at end of this post.
With this configuration, you achieve high availability of firewalls, simplified manageability, avoidance of over-subscription of the cluster, and optimized cost. All the spoke VPCs are directly attached to the transit gateway.
You can add a black-hole route in the spoke routing table to prevent traffic between spoke VPCs routed through the firewalls, as shown in the following diagram.

Figure 1. An example Transit Gateway deployment connecting 3 VPCs to the Internet through a dedicated Security Hub VPC. The firewalls in the Security Hub VPC use VPN attachments to the Transit Gateway.
Solution overview
The solution design focuses on allowing outbound traffic from the spoke VPCs to the internet, and allowing the return traffic. Communication between spoke VPCs is blocked by the transit gateway using black-hole routes.
Inbound communication from the internet to any of the spoke VPCs through the transit gateway is outside the scope of this post. The default security policy on firewalls denies inbound traffic from the internet to internal resources.
To achieve the objectives, use two route tables on the transit gateway:
- Hub route table: Allows the hub VPC (hosting the security solution) to reach any of the spoke VPCs.
- Spoke route table: Allows spoke VPCs to communicate out to the internet through the hub VPC, but does not allow communication between spoke VPCs.
The solution consists of four parts:
- Creating the Transit Gateway AWS CloudFormation stack. This consists of appropriate routing tables and sharing the transit gateway using AWS RAM.
- Creating transit gateway attachments and configuring the spoke VPCs with appropriate routing.
- Creating the firewall stack. This is done in the hub account in an existing VPC. The firewall configuration includes the required security policies, VPN, BGP, and routing configurations.
- Configure the required route table entries in transit gateway routing tables.
Deployment steps
The transit gateway is shared between different accounts. After it is created, sharing the transit gateway can be done in two ways:
- Automatically with AWS Organizations. Set Enable Sharing with an Organization to True when launching the AWS CloudFormation stack.
- Manually using AWS RAM. Create an AWS RAM share in the hub account by specifying the account IDs for each individual account with which you would like to share the transit gateway.
Create the transit gateway AWS CloudFormation stack
Use the following AWS CloudFormation template.
The template creates the following resources:
- A transit gateway
- Two transit gateway route tables: hub and spoke
- A RAM share resource, if you decide to set Enable Sharing with an Organization to true.
Follow these steps:
- Launch the template using the AWS CloudFormation console.
- Save the transit gateway ID that is created by the stack, and confirm that it’s in the Available state.
Important: If you decide to use the RAM share resource in the stack, make sure to enable sharing with an AWS organization under the master account of the AWS Organization.
Create the transit gateway attachments and configure the spoke VPCs with appropriate routes
Use the following AWS CloudFormation template.
This template creates the following resources:
-
- A VPC as an attachment to the transit gateway
- Updates to the route tables of your private subnets, with a default route pointing to the transit gateway
In each spoke account to connect to the transit gateway, follow these steps:
- Launch the template in the console using AWS CloudFormation.
- Provide the following parameters:
-
- Transit gateway ID
- Spoke VPC ID (a transit gateway attachment is created for this VPC)
- Subnet IDs (choose at least two subnets for the transit gateway attachments)
- Route table IDs (subnet route table IDs that forward their outbound traffic to the transit gateway)
3. Note the transit gateway attachment IDs, and confirm that they are in the Available state.
Create the firewall stack
The Fortinet firewalls are configured in active/passive configuration and hosted from a Security Hub VPC with both public and private subnets. The VPN interface, management interface, and outbound interface are in public subnets and require internet connectivity through the internet gateway. The high availability synchronization (HA-sync) subnets are private (internal only) subnets that are used for heartbeats between the two instances that are HA.
Before you deploy the security solution, complete the following prerequisites:
-
- Create an Elastic IP address and note its allocation ID. This is used as the customer gateway IP address on the master FortiGate firewall for the VPN connection. For more information, see Elastic IP Addresses.
- Create VPN attachments with Elastic IP addresses (created in the previous step) to be associated with the active FortiGate firewall for each Availability Zone from the transit gateway. For more information, see Transit Gateway VPN Attachments.
- Download the VPN configuration for the VPN connections created by navigating to the AWS Site-to-Site VPN connections in the Amazon VPC console.
- Select Fortinet as the vendor, FortiGate 40+ series as the platform, and FortiOS 5.0+ as the software. For more information about creating VPNs, see Site-to-Site VPN Tunnel Options for Your Site-to-Site VPN Connection.
- Confirm that the network ACL of your VPN subnet and the security group associated to the FortiGate firewall allows traffic from the public IP addresses of the transit gateway VPN attachments.
Use the following AWS CloudFormation template.
The template acts on the resources as follows:
- Creates FortiGate instances in a HA pair per Availability Zone.
- Configures the firewall policies that are required.
- Configures VPN and BGP on each of your FortiGate firewalls.
To deploy, follow these steps:
- Launch the following template using AWS CloudFormation in the console.
- Provide the appropriate parameters required to configure the FortiGate firewall. There are five configuration sections:
- VPC
- FortiGate
- Cluster
- VPN
- BGP
VPC configuration
These include the VPC configuration along with the subnet information where the FortiGate firewall is launched.

CloudFormation VPC Settings
FortiGate configuration
These include the private IP addresses for the four interfaces on FortiGate 1 and FortiGate 2.

CloudFormation Active Fortigate Settings

CloudFormation Passive Fortigate Settings
Cluster configuration
The cluster VPN IP address and the cluster outbound IP address are configured on FortiGate firewalls as secondary IP addresses on the VPN and outbound interface appropriately. They are required to achieve high availability (HA).
In the event of failure, these secondary IP addresses are moved to the standby node through API calls initiated from FortiOS on its management interface.
Provide the cluster VPN IP address and cluster outbound IP address for Fortinet.

CloudFormation Fortigate Cluster Settings
VPN configuration
The following parameters are required on FortiGate firewalls to create the VPN connection to the transit gateway:
- Remote gateway IP address: The AWS public IP address for the VPN connection created on the transit gateway.
- Customer gateway IP address: The public IP address (Elastic IP address) to be used on the FortiGate firewall interface terminating the VPN.
- Elastic IP address allocation ID: The ID used for the customer gateway IP address.
- The IPsec pre-shared key.
Enter the values for VPN parameters from the VPN configuration file that you downloaded earlier, based on the following screenshot.

CloudFormation VPN Settings
An example of how you can retrieve BGP parameters from VPN configuration file is provided in the below screenshot.

Downloaded Fortinet VPN Configuration File
BGP configuration
Use the following BGP parameters to create the relationship between the FortiGate firewall and transit gateway:
- Local (customer) Autonomous System Number (ASN)
- Remote AWS ASN
- Local peer IP address
- Remote peer IP address
These parameters can be obtained from the VPN configuration file downloaded earlier.
You can also provide the CIDR for the Security Hub VPC along with the netmask, to be advertised with these VPN attachments to the transit gateway.

CloudFormation BGP Settings
- Note the IDs of instances that are launched by AWS CloudFormation.
- Log in to the FortiGate1 instance using its administrator public IP address and the instance ID as the password. Change the default initial password. By default, the template launches FortiGate1 as active and FortiGate2 as passive.
- Confirm that the FortiGate firewalls have synced their configurations, and that their HA health status is OK.
- Verify that the tunnel interface is up and the CIDRs of the spoke VPCs are learned through BGP on the FortiGate firewalls.
Configure the required route entries in the transit gateway route tables
The last and final step is to configure the transit gateway route tables. This allows VPCs in different spoke accounts to reach the internet through the security solution hosted in the hub account. To do this, create the necessary associations and propagations.
- In the VPC console, in the left navigation pane, choose Transit Gateway Route Tables, Hub Route Table.
- In the bottom pane, choose Associations, and create an association.
- Choose one of the VPN attachments that you created with an active FortiGate instance in the previous section.
- Repeat this process for all the VPN attachments that you have created with other active FortiGate firewalls.
- In the bottom pane, under the same routing table, choose Propagations. Create a propagation route for each spoke VPC attachments.
- In the VPC console, choose Transit Gateway Route Tables, Spoke Route table.
- Create an association, and chose one of the VPC attachments that you created earlier.
- Repeat this process for all remaining VPC attachments that you created.
- Under the same route table, create a propagation route for each VPN attachment.
Summary
In this post, We introduced a solution using AWS Transit Gateway to inspect outbound internet traffic and filter it according to your security policy requirements. You achieved this by creating the following resources:
- A transit gateway that centralizes the communication between spoke VPCs and a Security Hub VPC
- A Security Hub VPC hosting the security appliances that inspect outbound internet traffic
We used Fortinet FortiGate firewalls for traffic inspection. You can deploy similar security solutions from multiple other partners from the AWS Marketplace, such as Palo Alto Networks, Check Point, and Cisco.
Additional Resources
Other ISV Products’ configuration templates can be found here
About the Authors
Shiva Vaidyanathan is a Cloud Infrastructure Architect at AWS. He provides technical guidance, design and lead implementation projects to customers ensuring their success on AWS. Prior to joining AWS, he has worked on several research projects on how to perform secure computing in public cloud infrastructures. He holds a MS in Computer Science from Rutgers University and a MS in Electrical Engineering from New York University.
Abdul Kittana is a Senior Security Architect with the AWS Professional Services. He has been part of AWS for over 2 years, and prior to joining AWS he was a security consultant for various security focused vendors and MSPs for over 12 years. He holds a Bsc in Computer Engineering from Eastern Mediterranean University.
![]() |
Blog: Using AWS Client VPN to securely access AWS and on-premises resources | |
![]() |
Learn about AWS VPN services | |
![]() |
Watch re:Invent 2019: Connectivity to AWS and hybrid AWS network architectures |