TLS Termination for Network Load Balancers might make Classic Load Balancers unnecessary and Amazon WorkLink seems to indicate an even greater focus on the enterprise market.

TLS Termination for NLBs

Since AWS introduced first the Application Load Balancers and then the Network Load Balancers, they have been a bit passive-aggressive about moving people away from what are now called Classic Load Balancers¹. You can see this for example in the Console where they suggest you upgrade your Classic Load Balancers to something new.

Don’t get me wrong here, there are many advantages to the newer types such as faster scaling, so no need to prescale for big events) and the ease with which you can use a single Load Balancer to point at very different backends. However, there was also a limitation². Which is that until the just released TLS Termination for Network Load Balancers, you couldn’t use SSL/TLS termination on any protocol other than HTTPS.

Application Load Balancers only accept traffic on two possible protocols: HTTP and HTTPS³. However, often you might want to use different protocols as well. Usually for communication that is not HTTP based like a communication protocol. The downside with Network Load Balancers, due to their layer 4 nature, was that you couldn’t do TLS termination on them, and therefore you had to manage the certificates on all of your servers or containers.

Here you might say that all of that is a solved problem! You can just use something like LetsEncrypt or even install the certificates manually. And true, you can do that. It also makes it harder than when you only need to manage the certificate in a single place so in those cases it was easier to stick to the Classic Load Balancer.

With this new release this is now no longer needed and it even has some improvements on the Classic Load Balancer⁴. One of these is that anything passed through an NLB, whether it’s TLS terminated or not, still has the same origin header. Which means that your application has direct access to the originating IP of the request, instead of needing to check the added X-Forwarded-For header.

If you want more information on how this is achieved, there is a Twitter thread describing the under the hood parts of this.

My main question now becomes one of time. I believe that this was the main reason to still use a Classic Load Balancer, and if that’s the case I suspect AWS will start being more aggressive about pushing solutions to the newer types. As development on Classic Load Balancers stopped or was deprioritized⁵ several years ago, the newer ones are probably better for AWS as well.

I could be wrong of course, and if you have a use case for Classic Load Balancers that isn’t covered by one of the newer types, I’d love to hear about it.

Amazon WorkLink

Another thing released this week is Amazon WorkLink. From my understanding, this is a bit of a managed VPN solution for mobile devices. You can set it up so that your corporate users can access your network securely without the need to go through a VPN.

How it works is that AWS will render the requested site within a VPC and then forward the rendered result to an app on the user’s mobile device⁶. This is all secure and presumably quite nice⁷, but the more interesting part to me is that this follows so closely to the release of Client VPN.

These are not the only solutions that seem to be aimed mostly at the bigger enterprises and government agencies either. There have been a lot of SLA announcements⁸ lately, and even receiving things like the recent PROTECTED certification in Australia and PCI compliance for EKS all help with boosting their status in this regard.

I’m sure the certifications and compliances would have happened anyway, but it looks to me that AWS has significantly increased their focus on this part of the market recently⁹. Even at re:Invent this was a big focus, including the various hybrid cloud solutions culminating in AWS Outposts.