AWS Gateway of Load Balancer
Digital equipment such as firewalls, intrusion detection and prevention systems, and deep packet inspection systems can all be deployed, scaled, and managed using Gateway Load Balancers. It integrates a seamless network gateway with traffic distribution when scaling the virtual appliances in response to demand.
The network layer, the third layer of the Open Systems Interconnection (OSI) model, is where a Gateway Load Balancer runs. It listens for all IP packets on all ports and forwards traffic to the listener rule’s defined target group.
Image retrieved from: https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/
It uses a 5-tuple (for TCP/UDP flows) or 3-tuple (for non-TCP/UDP flows) approach to preserve flow stickiness to a given target appliance. The GENEVE protocol is used by the Gateway Load Balancer and its registered virtual appliance instances to share application traffic on port 6081. A maximum transmission unit (MTU) size of 8500 bytes is supported.
Route tables are used to customize traffic to and from a Gateway Load Balancer endpoint. Traffic flows from the service consumer VPC to the service provider VPC’s Gateway Load Balancer, then back to the service consumer VPC via the Gateway Load Balancer endpoint.
A Gateway Load Balancer endpoint is a VPC endpoint that allows virtual appliances in the service provider VPC to communicate with application servers in the service client VPC. The virtual appliances and the Gateway Load Balancer are all deployed in the same VPC. The Gateway Load Balancer has these appliances listed as a target group.
Image retrieved from: https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html
In the service consumer VPC, the application servers are in one subnet (destination subnet), while the Gateway Load Balancer endpoint is in another subnet. All traffic accessing the service consumer VPC through the internet gateway is first inspected at the Gateway Load Balancer endpoint before being routed to the destination subnet.
Traffic bound for the application servers must be routed to the Gateway Load Balancer endpoint via the internet gateway’s route table. The VPC endpoint’s ID is used to specify the Gateway Load Balancer endpoint.
All traffic (0.0.0.0/0) from the application servers must be routed to the Gateway Load Balancer endpoint in the route table for the subnet with the application servers.
Traffic that returns from inspection must be routed to its final destination by the path table for the subnet with the Gateway Load Balancer endpoint. The local path means that traffic originating from the internet enters the application servers. Add an entry that directs all traffic (0.0.0.0/0) to the internet portal for traffic that originates from the application servers.
If you prefer the CLI, the following CLI commands may be used to build a Gate load balancer:
aws elbv2 create-load-balancer — name my-load-balancer — type gateway — subnets provider-subnet-id
aws elbv2 create-target-group — name my-targets — protocol GENEVE — port 6081 — vpc-id provider-vpc-id
aws elbv2 register-targets — target-group-arn targetgroup-arn — targets Id=i-1234567890abcdef0 Id=i-0abcdef1234567890
aws elbv2 create-listener — load-balancer-arn loadbalancer-arn — default-actions Type=forward,TargetGroupArn=targetgroup-arn
aws elbv2 describe-target-health — target-group-arn targetgroup-arn
Since it’s a VPC Flow Logs
transparent layer 3 load balancer and doesn’t end flows, the Gateway Load Balancer doesn’t produce access logs. Access logging on Gateway Load Balancer target appliances such as firewalls, IDS/IPS, and authentication appliances must be enabled in order to collect access logs. VPC flow logs on Gateway Load Balancers can also be allowed. So you can monitor your Gateway load balancer with:
CloudWatch metrics
VPC Flow Logs
CloudTrail logs
Thank You for reading till end!!! 👏🏻
