

# Inline traffic inspection solution options
<a name="solution-options"></a>

The following three sections describe data flows for traffic inspection using third-party firewall appliances in an AWS environment with Gateway Load Balancer and Gateway Load Balancer endpoints:
+ [VPC-to-VPC traffic inspection](vpc-to-vpc-traffic-inspection.md)
+ [VPC-to-on-premises traffic inspection](vpc-on-premises-traffic-inspection.md)
+ [Outbound traffic inspection through a NAT gateway and internet gateway](outbound-traffic-inspection-nat-gateway.md)

The following resources are used in the three options for this solution:
+ Dedicated spoke VPCs for hosting workloads or applications.
+ One VPC for hosting firewall appliances.
+ A dedicated subnet for the Transit Gateway elastic network interface for each Availability Zone in the spoke and appliance VPCs.
+ Appliance mode turned on for the appliance VPC attachment.
+ Dedicated subnets for Gateway Load Balancer endpoints in each Availability Zone.
+ A transit gateway to interconnect the VPCs, in addition to providing on-premises connectivity through the Transit Gateway virtual interface and Direct Connect gateway or with a VPN attachment for AWS Site-to-Site VPN.

# VPC-to-VPC traffic inspection
<a name="vpc-to-vpc-traffic-inspection"></a>

VPC-to-VPC traffic inspection occurs when traffic originates from one VPC and is destined for another VPC. The traffic is redirected to an appliance VPC for traffic inspection before arriving at the destination VPC. The following diagram shows how traffic flows if an Amazon Elastic Compute Cloud (Amazon EC2) instance in `Workload spoke VPC1` needs to communicate with an EC2 instance in `Workload spoke VPC2`.

![\[Architecture diagram of traffic inspection between two spoke VPCs and an appliance VPC\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/images/2-vpc-to-vpc.png)


In this use case, two spoke VPCs host the workload EC2 instances across two Availability Zones and an appliance VPC hosts the third-party firewall appliances for traffic inspection. The VPCs are interconnected using AWS Transit Gateway. The diagram shows the following packet flow when an EC2 instance in `Workload spoke VPC1` in Availability Zone 1 sends a packet to an instance in `Workload spoke VPC2` in Availability Zone 1:

1. The packet from an EC2 instance in `Workload spoke VPC1` in Availability Zone 1 goes to the Transit Gateway elastic network interface in the transit gateway subnet in Availability Zone 1.

1. Based on the default route defined in the VPC route table, the packet lands on the transit gateway. 

1. In the transit gateway, the spoke transit gateway route table is associated with the `Workload spoke VPC1` attachment that determines the next hop.

1. The next hop is the appliance VPC. Because the appliance VPC attachment has appliance mode turned on, the transit gateway determines which Transit Gateway elastic network interface to forward the traffic to, based on the 4-tuples of the IP packet.

1. If Transit Gateway chooses the Transit Gateway elastic network interface in Availability Zone 1 in the `Appliance VPC`, the traffic sticks to Availability Zone 1 for both the request and the response traffic. 

1. The traffic is sent to `Gateway Load Balancer endpoint 1` in Availability Zone 1.

1. The Gateway Load Balancer endpoint is logically connected to Gateway Load Balancer using AWS PrivateLink. The Gateway Load Balancer uses the 4-tuple hash algorithm to pick a firewall appliance for the life of the flow and then forwards the traffic for inspection to that appliance in the `Appliance VPC` in Availability Zone 1. The Gateway Load Balancer creates a GENEVE tunnel between it and the firewall appliance. 

1. The traffic is inspected based on the firewall policy. 

1. After the packet is successfully inspected, the packet is sent back to the Gateway Load Balancer and then to Gateway Load Balancer endpoint in `Appliance VPC` in Availability Zone 1.

1. At the Gateway Load Balancer endpoint, the packet is sent to the transit gateway based on the VPC route table.

1. After the packet arrives at the transit gateway, it examines the route table associated for the `10.2.0.0/16` network, which is the destination network.

1. The packet is sent to the Transit Gateway elastic network interface in `Workload spoke VPC2` in Availability Zone 1 before arriving at the destination EC2 instance. Return traffic follows the same path but in reverse. 

**Note**  
Transit Gateway maintains Availability Zone affinity and uses the same Availability Zone that the original requests was created in. For example, if an EC2 instance in `Workload spoke VPC2` in Availability Zone 2 initiated the request, the packet is forwarded to the Transit Gateway elastic network interface subnet in `Workload spoke VPC2` in Availability Zone 2, lands on the transit gateway, and is then forwarded to the Transit Gateway elastic network interface subnet in Availability Zone 2 in the destination VPC. By turning on appliance mode in the appliance VPC, you can ensure that the flow of symmetry is maintained using the 4-tuple hash for the life of traffic.

# VPC-to-on-premises traffic inspection
<a name="vpc-on-premises-traffic-inspection"></a>

The following diagram shows the traffic flow if an Amazon Elastic Compute Cloud (Amazon EC2) instance in `Workload spoke VPC1` wants to communicate with an on-premises server.

![\[The traffic flow between an Amazon EC2 instance in spoke VPC 1 and an on-premises server\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/images/3-vpc-to-onprem.png)


The diagram shows the following workflow: 

1. A packet from an EC2 instance in `Workload spoke VPC 1` in Availability Zone 1 arrives at the Transit Gateway elastic network interface in Availability Zone 1 in the transit gateway subnet for `Workload spoke VPC 1`. Based on the VPC route table associated to the Transit Gateway elastic network interface subnet, the packet lands on the transit gateway. 

1. In the transit gateway, the `Spoke transit gateway route table` is associated with the `Workload spoke VPC 1` attachment and this determines the next hop.

1. The next hop is the appliance VPC. Based on 4-tuple hash for the life of a flow, the Transit Gateway determines which Transit Gateway elastic network interface to send the traffic to.

1. If Transit Gateway chooses the Transit Gateway elastic network interface in Availability Zone 1, it checks the VPC route table associated to the Transit Gateway elastic network interface subnet in Availability Zone 1 in the appliance VPC. Transit Gateway sends the traffic to the Gateway Load Balancer endpoint in Availability Zone 1.

1. The Gateway Load Balancer endpoint is logically connected to the Gateway Load Balancer through AWS PrivateLink that then forwards the traffic to the firewall appliance for traffic inspection. The Gateway Load Balancer creates a GENEVE tunnel between the Gateway Load Balancer and the firewall appliances.

1. If the traffic is allowed, the packet is sent back to the Gateway Load Balancer and the Gateway Load Balancer endpoint in Availability Zone 1.

1. At the Gateway Load Balancer endpoint, the packet checks the VPC route table and the next hop is the transit gateway.

1. The packet arrives at the transit gateway and performs a lookup on the appliance transit gateway route table that is associated to the appliance VPC attachment for the next hop to the `172.16.0.0/16` network.

1. The packet is then sent to the destination server on premises. The response traffic follows the same path but in reverse. 

# Outbound traffic inspection through a NAT gateway and internet gateway
<a name="outbound-traffic-inspection-nat-gateway"></a>

 The following diagram shows the workflow if you need to inspect outbound traffic originating from a VPC to the internet. 

![\[Inspecting traffic from a VPC to the internet through a NAT gateway and internet gateway.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/images/4-outbound-inspection.png)


The diagram shows the following workflow:

1. The packet from an Amazon Elastic Compute Cloud (Amazon EC2) instance in `Workload spoke VPC1` in Availability Zone 1 arrives at the Transit Gateway elastic network interface in Availability Zone 1. According to the `Workload spoke VPC1` route table that is associated with the source, the packet arrives at the Transit Gateway.

1. In Transit Gateway, the spoke transit gateway route table is associated with the `Workload spoke VPC1` attachment, which determines the next hop.

1. The next hop is the `Appliance VPC`. The Transit Gateway determines which Transit Gateway elastic network interface to send the traffic to based on 4-tuple hash.

1. If Transit Gateway chooses the Transit Gateway elastic network interface in Availability Zone 2, it then checks the VPC route table associated to the Transit Gateway elastic network interface subnet in Availability Zone 2 for the `Appliance VPC` and then sends the traffic to the Gateway Load Balancer endpoint based on the default route.

1. The Gateway Load Balancer endpoint is logically connected to Gateway Load Balancer through AWS PrivateLink , which forwards the traffic to the firewall appliance for traffic inspection. Gateway Load Balancer creates a GENEVE tunnel between it and the firewall appliances.

1. If the traffic is allowed then the packet is sent back to the Gateway Load Balancer and the Gateway Load Balancer endpoint in Availability Zone 1 from where it came from based on metadata attached to the payload.

1. At the Gateway Load Balancer endpoint in Availability Zone 1, the packet checks the VPC route table to determine the next hop.

1. The packet arrives at `NAT gateway 1` and looks at the NAT gateway's route table, with the default route being the internet gateway.

1. The packet is then sent to its destination through the internet gateway. The return traffic follows the same path but in reverse.