• Skip to primary navigation
  • Skip to main content
Last Week in AWS Logo
Master your cloud costs
  • About
    • Community
    • Contact
  • Blog
  • Newsletter
  • Podcasts
    • Last Week in AWS Podcast
    • Screaming in the Cloud
    • Nominate a Guest
  • Merch
  • Resources
    • AWS Network Map
Public speaker at Business Conference.
11.18.2020

What I Don’t Get about the AWS Gateway Load Balancer

By Corey Quinn
AWS recently launched the AWS Gateway Load Balancer. Technically, it’s a way of preserving original network traffic/ensuring flow symmetry—or, in other words, “dropping a bunch of instances in-line without having to teach…
FacebookXLinkedInReddit
Home Blog What I Don’t Get about the AWS Gateway Load Balancer
Prev
Next

AWS recently launched the AWS Gateway Load Balancer.

Technically, it’s a way of preserving original network traffic/ensuring flow symmetry—or, in other words, “dropping a bunch of instances in-line without having to teach them all about AWS networking.”

This is a great feature!

What’s not so great is that the launch article highlights how good this is for embedding partner appliances into your VPCs.

The examples in the blog post talk about firewalls, intrusion detection systems, SSL intercept devices, deep packet inspection systems, and more. Even the console launch page for these things talks explicitly about “third-party appliances.”

What’s wrong with that?

The trouble I have with that framing is that an entire outmoded series of vendors suddenly have new life breathed into them.

If we were still doing in-person conferences, the RSA expo hall would be full of dancing vendors in the aisles. You’d think some of these folks were getting acquired based on the level of rejoicing amongst their sales teams.

Shoving a bunch of third-party appliances into your VPC configuration is generally a bad idea.

In fact, I’ll take it a step further and state as a strawman argument that “cloud-native” means that you don’t use third-party appliances in your cloud architectures—an assertion that nobody will have any problems with whatsoever.

There’s history here

For the longest time, it was hard to intelligently get an in-line appliance working in a modern AWS environment.

Vendors complained. But the reasoning behind it was simple: The networking architectures of cloud environments and data center environments weren’t 100% congruent. Every attempt to remedy this had the unfortunate side effect of making your cloud environment look an awful lot like your crappy data center environment while introducing a host of problems.

For instance, if you have a proxy server that all of your instances talk to in order to speak to the outside world, and that proxy server goes down (I know—cloud instances can go away! Commence pearl clutching!), suddenly those instances aren’t going to be able to communicate until the proxy server comes back up. Appliance vendors were then basically forced into using auto scaling groups, misusing load balancers, and tempting fate with other suboptimal mitigations.

That was crappy for everyone—and it created a useful amount of friction that indicated that you were doing something that probably wasn’t a best practice.

A breath of fresh air

There’s a silver lining here that makes this service freaking awesome. But to see it, you have to cut through the marketing with a knife.

View everything AWS says publicly about the Gateway Load Balancer as a sponsored ad by all of their legacy networking partners and disregard it. A (very!) careful reading of the documentation indicates that you aren’t required to go cross-account with these devices, and that there’s no requirement that the appliances actually be third party.

And that opens up the world.

Now you can write a bunch of internal tools that don’t require selling your soul to giant networking vendors. You can leverage an open source project or two and see what percentage of your traffic is encrypted or—based upon SNI headers—what hosts are most popular.

By not having to spend incredible amounts of effort to set up the routing and failover bits yourself, AWS has done a tremendous amount of heavy lifting for you.

What distinction am I drawing?

I want to be very clear that I have a visceral negative reaction to third-party networking vendors. Historically, they viewed the cloud as an enemy, were very slow to embrace it, and every solution they offered in the space was oriented much more around preserving legacy lines of business than expanding new capabilities.

That said, there are legitimate use cases for these technologies—particularly in regulated environments.

In any case, this is a net win across the board for everyone.

I just want to make it very, very clear that you don’t need to start paying third-party vendors to do AWS networking properly—and I really wish the Gateway Load Balancer documentation and examples reflected that more effectively.

Corey Quinn Headshot
by Corey Quinn

Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure.

More Posts from Corey

Back to the Blog

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

By Corey Quinn

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […]

Read Moreabout Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

Reading Observability Tools? That’s a Robot’s Job

By Corey Quinn

Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […]

Read Moreabout Reading Observability Tools? That’s a Robot’s Job

S3 Is Not a Filesystem (But Now There’s One In Front of It)

By Corey Quinn

I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […]

Read Moreabout S3 Is Not a Filesystem (But Now There’s One In Front of It)
Billie Holding Mail Email Subscribe Icon

Get the newsletter!

Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark.

You’re faced with tough questions about cloud costs. You should have confident answers.
Get in touch.
  • Newsletter
  • Podcasts
  • Blog
  • Merch
  • About
  • Contact
  • Disclosures
Billie Footer
footprint-orange
© 2026 L9 Labs, Inc. All Rights Reserved.
Terms of Service Privacy Policy Cookie Policy