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 Balancers1. 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 limitation2. 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 HTTPS3. 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 Balancer4. 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 deprioritized5 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.
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 device6. This is all secure and presumably quite nice7, 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 announcements8 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 recently9. Even at re:Invent this was a big focus, including the various hybrid cloud solutions culminating in AWS Outposts.
- Originally these were named Elastic Load Balancers, but that has since become the term in use for all the different types. [return]
- Not counting it being more complex to configure. [return]
- In the original version, I incorrectly mentioned that this was limited to ports 80 and 443 as well. As @aneesh pointed out in the comments, this was wrong. [return]
- And even Application Load Balancer for that matter. [return]
- I have no information this is the case, but based on the lack of changes it seems logical. [return]
- iOS 12 only for now, soon they’ll add modern Android support. [return]
- Or as nice as a first version of something like this can be. [return]
- I count 10 so far in 2019. [return]
- Remember, just because it gets announced now doesn’t mean it hasn’t been in development for a long time. [return]
Read more like this:
- Week 43, 2019 - CloudWatch Anomaly Detection; Some AWS Container Updates
- Week 39, 2019 - Step Functions Dynamic Parallelism; S3 Same-Region Replication
- Week 38, 2019 - Amazon QLDB; Flow Logs Meta-Data
- Week 37, 2019 - Lambda Shared ENIs; EKS IAM Roles
- Week 34, 2019 - App Mesh Routing; Nested Step Functions; CodeBuild Runtimes
Or always get the latest by subscribing through RSS, Twitter, or email!