The previous article in this series reviewed the BIG-IP and AWS Gateway Load Balancer (GWLB) integration,
in this article we will focus on a deployment pattern that is used to inspect traffic in and out of a VPC using BIG-IP security services and GWLB.
In this scenario we will focus on a single existing VPC with EC2 instances and no BIG-IP security services
Inspect traffic in and out of the VPC, scale the BIG-IP deployment as needed
Considering the requirements and tools available, the deployment pattern will use the following attributes:
Separate the security devices (BIG-IP's) from the workloads they are protecting. The BIG-IP's will be deployed in their own VPC – the Security VPC. We will reference the workload VPC as the 'Consumer' VPC as it consumes security services.
Use Routing tables in the 'consumer' VPC to send all traffic to the security VPC for inspection.
Leverage transparent security services on the BIG-IP for inspection (BIG-IP security features configuration is out of scope for this article)
We can dive into each of the individual tasks:
The Security VPC
Provisioning the 'consumer' VPC network to send traffic through the security VPC
Here, we are deploying the BIG-IP fleet and exposing it using GWLB. Some of the considerations when creating this VPC:
Deploy in the same region as the 'consumer' VPC
Design based on your availability requirements,
Number of availability zones(AZ)
How many BIG-IP's in each AZ
These are the actions we need to take in the provider VPC to inspect all ingress/egress traffic:
Deploy a group of BIG-IP's
Create a GWLB target group and associate the BIG-IP's to it
Create a GWLB and assign the previously created target group to the listener
Create a GWLB endpoint service and associate it with the GWLB
Configure the BIG-IP's to receive traffic over the tunnel and inspect according to the desired policy
Diagram: The security VPC - BIG-IP fleet behind a GWLB, exposed using GWLB service
In the consumer VPC, the BIG-IP group is abstracted by the GWLB and consumes the security services from the provider VPC via a new component: GWLB endpoint. This endpoint acts as bridge between the consumer VPC and the provider VPC. It essentially creates an ENI in one of the consumer's VPC subnet. Please note that a single endpoint belongs to a single availability zone and design accordingly.
Inspecting all ingress traffic requires the use of 'Ingress routing' – an AWS feature that allows sending all ingress traffic from the internet gateway to an ENI or to a GWLB endpoint.
Here are the actions we need to take in the consumer VPC to inspect all ingress/egress traffic:
Create GWLB endpoints in each relevant availability zone that are attached to the 'GWLB endpoint service' from the provider VPC
Change the ingress routing table so that all traffic in each AZ will get routed to the respective GWLB endpoint.
Change the subnets routing tables so that all traffic in each AZ will get routed to the respective GWLB endpoint.
Diagram: Inspecting all ingress/egress in the Security provider VPC
Ingress traffic flow between an external user and an EC2 instance in the consumer VPC:
Egress traffic flow between an EC2 instance in the consumer VPC and an external user:
With this deployment you can protect your AWS VPC using the robust security services offered by the BIG-IP platform and get the following benefits:
Scalability - Deploy as many BIG-IP instances as you need based on performance and availability requirements
Transparent inspection - Inspecting the traffic without any address translation
Optimized compute - all BIG-IP devices are active and processing traffic
Test the deployment yourself - Check out our self-service lab that you can deploy in your own AWS account (Fully automated deployment using Terraform):