Skip to content

Grasping AWS Gateway Load Balancer, Comparison with other LBs

Introduction

Gateway Load Balancer (GWLB) is one of the newer kids on the AWS block. Even if you’ve been working with AWS for a while, you might not be too familiar with it – I wasn’t. That’s why I decided to dive in and learn what GWLB is all about. In this post, I’m going to share what I’ve discovered, comparing GWLB to its older siblings – Application Load Balancer (ALB) and Network Load Balancer (NLB). Let’s kick off this journey into the world of AWS load balancers, starting with the Gateway Load Balancer.

Understanding Gateway Load Balancer (GWLB)

Gateway Load Balancer (GWLB) plays by a different set of rules compared to Application Load Balancer (ALB) and Network Load Balancer (NLB). Operating at Layer 3, or the Network Layer, GWLB carries unique characteristics, separating it from its counterparts.

  1. Traffic Transparency: Standing out in the crowd, GWLB’s most notable attribute is its full traffic transparency. Unlike ALB and NLB, which alter the source or destination IP addresses and ports of the traffic they manage, GWLB keeps them intact. It respects the original transport layer and network layer headers. This feature is crucial for specific applications, especially security and network appliances like firewalls and intrusion detection/prevention systems. These systems need access to the raw, unaltered source and destination information.
  2. Support for all IP traffic: GWLB works at the network layer (Layer 3) and is built to deal with all IP traffic. This capability contrasts with ALB, which operates at the application layer (Layer 7) focusing on HTTP/HTTPS traffic, and NLB, which works at the transport layer (Layer 4), dealing with TCP/UDP traffic. The GWLB’s all-inclusive approach to IP traffic gives it a broader spectrum of versatility when routing traffic to virtual appliances.
  3. Management of Third-party Virtual Appliances: Unlike ALB or NLB, which are more generalized, GWLB is purpose-built to handle traffic for third-party virtual appliances. It streamlines the deployment and management of these appliances, treating a pool of virtual appliances as a single endpoint for traffic routing.
  4. End-to-end Connectivity: GWLB maintains end-to-end connectivity, making it an ideal choice for scenarios requiring stateful connections, such as VPNs or VoIP services.

From these unique traits, it’s clear that GWLB is designed with a focus on managing virtual appliances like firewalls, intrusion detection systems (IDS), and intrusion prevention systems (IPS). This makes it a compelling choice for use cases involving third-party or custom-built virtual appliances.

Common use cases for GWLB include:

  • Deploying, scaling, and managing third-party virtual network appliances.
  • Implementing network and security appliances in a transparent, scalable manner.
  • Maintaining end-to-end connectivity for applications that require long-lived connections, such as VoIP or VPN.
  • Scaling out third-party or custom appliances while keeping the traffic distribution transparent and preserving source and destination IP addresses.

GWLB is a specialized tool designed to address specific challenges. It’s not a one-size-fits-all solution, but for certain situations, it’s just the right fit.

Comparison of ALB, NLB, and GWLB

To further understand the differences between these load balancers, let’s have a look at this tabular comparison of their key features.

Application Load Balancer (ALB)Network Load Balancer (NLB)Gateway Load Balancer (GWLB)
LayerLayer 7 (Application)Layer 4 (Transport)Layer 3 (Network)
RoutingHTTP/HTTPS routingTCP/UDP/IP routingTCP/IP routing
Health ChecksYesYesYes
SSL OffloadingYesYes, with TLS terminationNo
Sticky SessionsYes (Cookie-based)Yes (5-tuple-based)Yes (5-tuple-based)
WebSocket SupportYesYesNo (Not specifically supported as it operates at a lower layer than where WebSocket protocol operates)
IP as TargetYesYesYes
Cross-zone Load BalancingYesYesYes
Use CaseModern HTTP and HTTPS applications, microservices architecture, container-based applicationsExtreme performance and static IP for applications, TCP, UDP, and TLS trafficDeploying, scaling, and managing third-party virtual appliances

Each load balancer excels in different scenarios and offers various features. It’s crucial to evaluate the specific needs of your project to select the most appropriate option. Remember, there’s no one-size-fits-all solution in the cloud – only the right tool for the job at hand.

Key Considerations Before Choosing GWLB

When choosing GWLB, some key points to consider are:

  • Traffic transparency and IP traffic handling: GWLB excels in maintaining end-to-end transparency and handling all types of IP traffic, which is crucial for certain operations.
  • Target limitations: GWLB mainly routes traffic to EC2 instances and IP addresses. If your service architecture involves other targets like containers or Lambda functions, ALB or NLB may be a better fit.
  • DevOps tooling: GWLB is not directly integrated with AWS CodePipeline, which is essential for implementing fast and reliable application updates. If you heavily rely on AWS DevOps services for continuous integration and continuous deployment (CI/CD), you might have to create a custom solution or consider ALB or NLB instead.
  • Application layer protocols: If your work requires application layer protocols like HTTP or HTTPS, or features like content-based routing and SSL offloading, an ALB may serve you better.
  • WebSocket support: GWLB does not explicitly support the WebSocket protocol since it operates at a lower layer. If your application requires WebSocket communication, consider using an ALB or NLB instead.

In essence, the best load balancer for you depends on your specific needs and constraints. It’s crucial to identify your requirements and choose the load balancer that best fulfills them.

Conclusion

Reflecting on the unique features of GWLB, it seems that its development was driven by the necessity to handle complex network scenarios, such as deploying and scaling virtual appliances effectively. This emphasis on network layer traffic management, coupled with traffic transparency, highlights a need for specialized solutions in environments that necessitate detailed packet-level scrutiny.

Despite these novel features, it’s somewhat disappointing that GWLB’s integration with other key AWS services, such as CodePipeline, is not as strong as it could be. This limits its plug-and-play use in certain DevOps scenarios, which might necessitate custom workarounds to achieve seamless CI/CD flows.

In conclusion, choosing the right load balancer – be it ALB, NLB, or GWLB – really boils down to understanding your project’s specific requirements. It’s important to conduct a thorough analysis of your network traffic patterns, security considerations, and deployment strategies. GWLB, with its specialized focus, could be the perfect fit for certain use cases. It serves as a reminder that the tools we choose should align with our project needs, and not the other way around.

References

Tags:

8 thoughts on “Grasping AWS Gateway Load Balancer, Comparison with other LBs”

  1. Hello there! This is my first comment here so I just wanted to give a quick shout out and tell you I really enjoy reading your posts. Can you suggest any other blogs/websites/forums that cover the same topics? Thanks a ton!

  2. Hey there! I could have sworn I’ve been to this site before but after reading through some of the post I realized it’s new to me. Anyhow, I’m definitely delighted I found it and I’ll be bookmarking and checking back frequently!

    1. Thank you so much for taking the time to leave a comment. I’m truly delighted to hear that you’re enjoying my posts. Your words are a source of motivation for me to keep creating and sharing content.

      I’m inspired by my work experience, which I try to bring into what I post here. I also have a few go-to sources that I typically check for inspiration and staying up-to-date on relevant topics. I’d like to share these with you in case they might be of interest:

      – LinkedIn Cloud Computing Group: https://www.linkedin.com/groups/1346907/
      – AWS Subreddit: https://www.reddit.com/r/aws/
      – Classmethod AWS Page (Japanese): https://dev.classmethod.jp/tags/aws/

      Even if you don’t speak Japanese, tools like Google Translate can help you benefit from the articles on the Classmethod AWS Page. They are extremely enthusiastic about AWS and provide deep, insightful content.

      Thanks again for your comment and bookmarking my site. I hope you continue to find value in my posts

  3. Its like you read my mind! You seem to know a lot about this, like you wrote the book in it or something. I think that you can do with a few pics to drive the message home a little bit, but instead of that, this is magnificent blog. An excellent read. I will definitely be back.

    1. Thank you for your kind words and valuable feedback! I’m thrilled that you found the content informative and engaging. I agree, visuals can enhance understanding, and I’ll certainly consider incorporating more in future posts. I’m glad you’ll be back!

    1. Thank you for your interest! In response to your question about email updates, I’m setting up an email subscription feature based on your suggestion. I’m currently awaiting approval to use an email subscription plugin. Once it’s operational, I’ll comment here to let you know. I appreciate your engagement and hope you continue to enjoy my posts.

    2. Thank you kindly for your patience. I am pleased to share that our email subscription service is now available. Please visit our website and find the ‘Subscribe’ option in the footer menu to receive updates on new posts. Your continued interest in our content is greatly appreciated.

Leave a Reply

Your email address will not be published. Required fields are marked *

child neve