You can use direct server return to manipulate the Ethernet frames so that packets don't travel back through the load balancer on the way to the parent switch.
That generally requires config on the serving hosts, which wasn't mentioned in the setup. I think I saw a reference to adding hosts with a different port number than the service port as well. For people in EC2-VPC (not classic), all their traffic is going through an Amazon NAT anyway, perhaps this new service is setting up translations there. (Note all the references to VPC, and never a mention of EC2-classic)
Do you have a support POC? I'd reach out to them as they should be able to provide you with a roadmap update. If you're not sure who that is, you can reach out to me at kozlowck at amazon.com.
Is there any intent to add TLS termination? That’s a dealbreaker for us switching from the classic load balancer.
Otherwise this looks really awesome, thanks!
I don't think they can add TLS termination because of the way it's implemented. NLB runs on Layer 4 - the transport layer where TCP/UDP run on. TLS technically runs on top of the transport layer.
That’s kind of the answer I was expecting, just hoping it wasn’t the case. From the marketing material they really want you to move, but not having a solution to offload tls makes it impossible for us. And it worries me to see the CLB getting effectively deprecated with it an alternative
I'm hopeful AWS will follow this up with ACM supporting SSL certs on instances, so you can run a LetsEncrypt equivalent on each instance, providing TLS end to end encryption
that threw me for a bit of a loop as well. This means that responsibility for doing ACL whitelisting at the edge is now moved from the actual edge, to the security groups on the actual servers responding to request, right?
That's do-able and all, but I kind of didn't hate the old paradigm of having an extra layer there.
One way to think of NLB is that it's an Elastic IP address that happens to go to multiple instances or containers, instead of just one. Everything else stays the same.
Yeh, it's easy to use it like that for now. I hope they update it later on though. Seems like an missing feature in their otherwise nice firewall rules setup.
Demo page states "Your browser may keep a connection open for a few seconds and re-use it for a reloaded request. If it does, you'll get the same target", but when I attempted to abuse the power of F5, I was alternated between ice cream and bumblebee.
If you are going to look at it, attempt time - ~04:50 UTC, remote address from 88.119.128.0/20 network
Browsers typically use a few connections to load a page so that it can load faster. Each of those threads has a different source port, and thus may route to a different target.
In Colm's demo, it depends which thread your browser uses when requesting the part including the CSS which decorates the object.
In my Chrome on Mac I see 6 TCP connections to the demo NLB
tcp4 0 0 192.168.100.101.49615 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49614 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49613 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49612 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49611 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49610 54.69.111.179.80 ESTABLISHED
Each of those will be routed to the same target, so it's up to your browser to decide which to use for what.
CloudFormation, CodeDeploy, and ECS all support NLB today :) I used the console to create the simple demo though, so I don't have a template to recreate it. Sorry!
Massive disclaimer: I work on NLB.