Centralizing Cloud Security with F5 and AWS Transit Gateway

Today we were fortunate to be a launch partner of AWS for their newly announced Transit Gateway feature, known as TGW.

We've had the opportunity to get our hands on TGW while it's been in private beta, and as a networking vendor up in AWS, we're just as excited about the functionality as AWS (if not more!). TGW will give customers more flexibility, and more control in their cloud routing. This means more opportunity to take advantage of the unique functionality that your F5 devices provides up in AWS.

Working with the AWS team here at f5, we had a pretty enlightening brain storming session focused on what use cases TGW could provide for our customers. Centralized routing will open a lot of doors for our customers, especially when it comes to security.

F5 and TGW Use Cases

One use case that seems to make obvious sense to us is using TGW to enforce complete traffic sanitization through a dedicated security VPC. In the example below, our fictitious enterprise built and populated a VPC with a series of our Advanced WAF VMs in a scale set. We then configured global route rules within our TGW to route all inbound traffic through this VPC, ensuring that this traffic would flow through the AWAF farm before making it on to its final destination, regardless of which AWS region/VPC the VM resided in.

Another use case for our fictitious enterprise would be to use TGW to enforce outbound traffic to flow through a forward proxy, such as F5's Secure Web Gateway, before leaving the AWS cloud. By connecting the on-premises datacenters, headquarters, and branch offices to AWS via Direct Connect or VPN, you now have a truly dynamically scalable outbound security filter for your cloud and on-premises based workloads.

In the next section of this post, I will walk you through setting up a POC environment  utilizing an AWS transit gateway and the F5 Advanced WAF to act as a centralized security enforcement engine as described in the first use case above.

Deploying the POC Environment

Prerequisites for POC

  • Active AWS Account credentials with sufficient permissions to deploy and manage AWS resources
  • AWS Role with sufficient permissions to deploy and manage AWS resources
  • SSH Key pair created/imported into US-East-2, (Ohio) region
  • Environment running with AWS CLI 1.15.70 or later

Let’s Make it Easy

To facilitate a quick and relatively painless process, we created a deployment CFT that will make quick work of the heavy lifting.  Along with ancillary services, ( i.e. route tables, security groups, etc.), the template will deploy the following POC environment into US-East-2 region. The POC, (as shown below) consists of:

  • Two, (2) Application VPCs – Each VPC consists of one subnet that hosts one, (1) Tomcat Certified by Bitnami
  • One, (1) Security VPC – consisting of one subnet hosting one, (1) F5 Advanced WAF (PAYG, 200Mbps)
  • One, (1) Transit Gateway, (TGW) – Application and Security VPCs are attached
  • One, (1) Internet Gateway, (IGW) – Associated to Security VPC

The Deployment process consists of three simple steps

  1. Deploy CFT
  2. Create VPC-2-TGW attachments, (via AWS CLI)
  3. Add route entries to VPCs, (via AWS CLI)

IMPORTANT: The provided template is unsupported and offered entirely “as is” and is by no means intended for production use.  In addition to AWS services this template will deploy three, (3) virtual machines.  Refer to the above links for licensing terms & conditions.  To successfully deploy the CFT, you may first be required to accept the aforementioned terms & conditions.  For ease of use the template deploys a statically configured environment with limited options.  Feel free to clone and modify as desired. 

Deploy the CFT

  1. Copy/clone the POC deployment template from GitHub
  2. Using the AWS console, navigate to the ‘US-East-2, (Ohio)’ region and create a new CloudFormation stack by uploading the template; select ‘Next’ to continue
  3. Provide a stack name and select previously created sshKey; select ‘Next’ to continue
  4. Select ‘Next’ on the next screen to continue
  5. Acknowledge and accept terms; select ‘Create’ to deploy the template

Deployed Resources

Once completed, (approximately 7-10 minutes) you can view the various resources created

VM Instances ( 3 total)

VPCs and Subnets ( 3 total)

Route Tables, ( 2 total)

Transit Gateway

Complete the Deployment - The Outputs Section

To finish setting up the POC environment, you will need to attach the VPCs to the TGW as well as add the appropriate routes to the newly created VPC route tables.  As of this post, these last two steps must be completed via AW CLI*.  Not to worry, the ‘Outputs’ section of the newly deployed CFT, (see below) contains the required commands.


* Refer to https://docs.aws.amazon.com/cli/latest/userguide/installing.html for guidance on connecting to your AWS account.

attachVpcCommandString – The AWS command attaches VPC endpoints to Transit Gateway, (TGW) enabling traffic flow.  The command takes the form – (Ex:   aws --region us-east-2 ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-0bab161c1aae789b5 --vpc-id vpc-0e7d482064b26f759 --subnet-ids subnet-088cbda4b806bceac)

VpcRouteAddCommandString – The AWS command adds route entries to VPCs directing appropriate traffic thru the TGW.  The command takes the form – (Ex:  aws --region us-east-2 ec2 create-route --destination-cidr-block --route-table-id rtb-00e0c121b67c9493d --transit-gateway-id tgw-0bab161c1aae789b5)

Bigip1SSh – To access and work with the F5 Advanced WAF, you will first need to connect to the management interface via SSH, (Ex: ssh -i "glc-key-east2" admin@ Once connected you will need to create a password for the admin user account.

Bigip1MgmtUrl – The management GUI URL, (Ex:

Validating the POC Environment

Now that you have the environment stood up and access to the F5 configured, let’s take a look at the Advanced WAF.

  1. Login to the F5 WAF using the aforementioned Url
  2. From the main page, navigate to ‘Local Traffic’ –> ‘Pools’.  If the attachments and routes were added successfully the existing web pool should have a green status.
  3. Select the pool from the middle pane and click on ‘Members’. Both member servers, (located in ‘ApplicationVpc’ and ‘Application2Vpc’ respectively) should have a green status.  This signifies that the BIG-IP, (located in the ‘SecurityVpc’) is able to communicate and pass traffic across the TGW and back to the web pool members.


Extra Credit

Now that the environment has been deployed and functionality validated, I can continue with publishing and securing my two webservers with the F5 Advanced WAF.  For more information regarding configuring the BIG-IP Web Application Firewall, refer to https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-getting-started-13-1-0.html.

Published Nov 27, 2018
Version 1.0

Was this article helpful?


  • Hi,


    Thanks for sharing info about TGW. I am not AWS pro so I have some questions:


    1. Would it be impossible to create setups described in article without TGW or it will be just much more complicated?
    2. I have issue with understanding this sentence: "We then configured global route rules within our TGW to route all inbound traffic through this VPC, ensuring that this traffic would flow through the AWAF farm before making it on to its final destination, regardless of which AWS region/VPC the VM resided in." - looking at the diagram traffic from Internet has to pass via Security VPC anyway. TGW is located behind Security VPC so routes in TGW are rather assuring that traffic leaving Security VPC will be routed to web server instance in the correct VPC as well (but I am not sure here) that returning traffic from vweb server will pass AWAF on the way back to Internet - or I am completely wrong here?
    3. What is purpose of AWS WAF with F5 rule set (I have some idea what F5 rule set is) - what is protected by AWS WAF in this case - seems that not backend web servers as those are protected by F5 AWAF.



  • not an AWS expert, but i would say :


    1. the workaround to transit gateway is creating a full mesh of VPN peering to interconnect VPCs. While in this example you have only 3 VPCs, it can become much more complex if you have tens of them. Specifically in use case where you to need to communicate between VPCs.
    2. Security VPC describerd here is just a traditional VPC, so you have to make sure that inbound traffic, including traffic from other VPCs and VPNs, to back end servers are going first through the security VPC. The AWS Transit Gateway is fronting any VPC interconnecting to VPNs and Internet.
    3. just a matter of courtesy here :) exposing an AWS WAF here allows easily delegating some security features to app team to manage their app access, while we enforce a more robust and deep security on the F5 A.WAF side on generic features not covered by AWS (L7 DDOS ,Anti Bot ...)
  • Hi,


    Thanks for comments. Seems that I have to educate a lot as not everything is still clear to me :-(




  • The "Forward Proxy" mentioned in the article implies APM and SWG rather than WAF/ASM if I'm not mistaken.