Adrian Cantrill’s SAA-C02 study course, 50 minutes: HA & Scaling section: Gateway Load Balancers
Gateway Load Balancers
The focus of today’s lesson was on Gateway Load Balancers. It was explained that these are a new addition to the load balancer family and are designed for very specific use cases.
To begin the discussion around Gateway Load Balancers, we discussed scenarios where we would want to use one. More specifically, we looked at a scenario where there was an application server located in a public subnet communicating with the public internet. It was explained that there was no type of inspection-based security appliance, something which could check data for any exploits in order to protect the application server.
Because we were dealing with an important application, we could add a security appliance which would be a transparent security device. It would sit in the flow of traffic, inbound and outbound, transparently reviewing traffic as it enters the application from the public internet, so protecting the application against any known exploits and then filtering any traffic on the way back out, protecting any traffic from any information leakage.
It was explained that this works well assuming that we don’t really have to think about scaling, but there would be issues when we wanted to grow or shrink our application. AWS pushes the concept of elasticity where applications can grow and shrink based on increasing and decreasing load on a system. When you need to deal with a number of growing and shrinking application instances and where this growth is extreme, you would need an appropriate number of security appliances, and this can be complex and prone to failures.
Also, this solution is tightly coupled where the application and security instances are tied together; the failure of one could impact the other. It doesn’t scale well, even in a single application environment. It’s even more complex if you’re trying to build multi-tenant applications. It’s this type of situation where you need to use some kind of security appliance at scale and have flexibility around network architecture when you might choose to use a gateway load balancer.
After this we looked at gateway load balancers specifically. It was explained that a gateway load balancer is a product that AWS has developed to help you run and scale third party security appliances, things such as firewalls, intrusion detection systems, intrusion prevention systems, even data analysis tools. You might use these to perform inbound and outbound transparent traffic inspection or protection.
It was explained that while AWS has many great networking products, there are still many businesses who use third party security and networking products. If this is the case, the business would need to use a third-party appliance, and to do this at scale a gateway load balancer would be needed.
We then looked at gateway load balancers from a high level. There are two major components:
1. GWLB endpoints, which run from VPC endpoints, where traffic you want to monitor, filter or control originates from, or is destined to. GWLB endpoints are much like interface endpoints within VPC’s, but with some key improvements, mentioned below.
2. The GWLB itself, which load balances packets across multiple backend instances, normal EC2 instances running security software. In order for this type of architecture to work, the GWLB needs to forward packets without any alteration.
The security appliance needs to review packets as they’re sent or as they’re received. These packeets have source and destination IP addresses, which might be ok on the original network but which might not work on the network where the security appliances are hosted from.
GWLB’s use a protocol called GENEVE, which is a tunneling protocol. A tunnel is created between the GWLB and the backend instances to the security appliances, packets are encapsulated and sent through the tunnel to the appliances.
Let’s say we had a laptop accessing the aforementioned application server. Traffic leaves the source laptop and moves into a VPC through an internet gateway and arrives at a gateway load balancer endpoint. The gateway load balancer endpoint is like a normal VPC interface endpoint with one major difference: it can be added to a route table as the next hop, which allows it to be part of traffic flows controlled by that route table. Traffic via a route table is directed at this endpoint and then the traffic flows through to a GWLB.
GWLB are layer three and four devices similar in many ways to a network load balancer, but they integrate with GWLB endpoints, and it encapsulates all traffic between it and the targets using the GENEVE protocol. This means that packets are unaltered, they have the same source IP, destination IP, source port, destination port, and contents as when they were created and sent. This allows the security appliance to scan the packets, review them for any security issues, block them as required, perform analysis, or adjust them as needed. When finished, the packets are returned over the same tunnel, encapsulated back to the load balancer, where the GENEVE encapsulation is removed, and then the packets move back to the GWLB endpoint and through to the intended destination.
The benefits to this architecture are that GWLB will load balance across security appliances, so it is possible to horizontally scale. The GWLB manages flow stickiness, so one flow of data will always use one appliance, and this is useful because it allows that appliance to monitor the state of flows through a system; it provides abstraction.
This allows for the use of multiple security appliances, to provide resilience. If one fails, then packets are just moved over to another available security appliance. In this way, it’s much like other load balancers within AWS.
CloudMastermind 