6. We have access logs, and can tell you about your TLS clients! We log things like the cipher suite and protocol version used, which makes it easy to audit if it's safe to disable an old algorithm.
-
Show this thread
-
7. NLB's TLS support can still use TLS to your targets, so you still get TLS traffic all the way to your target. This might seem strange, if you're going to run TLS on your own end anyway, what's the point?
1 reply 0 retweets 6 likesShow this thread -
... well, NLB runs on Amazon VPC. On VPC we encapsulate, authenticate and secure traffic at the packet level. Packets can't be spoofed or MITMd on VPC. Traffic only goes where you send it. That makes it possible to use a self-signed, or even expired, certificate on your end.
1 reply 4 retweets 13 likesShow this thread -
In TLS/SSL, certificates are just about authenticating the server or the client, but since Amazon VPC does that at the packet level, you can offload the problems that comes with certificate management to us.
2 replies 0 retweets 7 likesShow this thread -
8. You can run plaintext too. I wouldn't recommend it, but you can also use NLB TLS as a total TLS/SSL off-loader; you can run plain TCP to your targets and NLB will translate between TLS to/from your clients and TCP to/from you. We *still* preserve the source IP, even then.
2 replies 0 retweets 6 likesShow this thread -
9. If you've been using our Classic Load Balancer as a L4 load balancer with support for TLS, you can now move to NLB!
2 replies 8 retweets 16 likesShow this thread -
That's it from me! You can start using it right now, I've had a test NLB going for a few weeks myself. Super super delighted to get this out there. AMA and let me know if you have any suggestions or questions! EOF.
11 replies 0 retweets 22 likesShow this thread -
Replying to @colmmacc
This might lessen the need to run nlb -> haproxy -> alb, but I'm probably still stuck doing that as long as we've got Elastic Beanstalk needing fixed ips. Correct?
1 reply 0 retweets 1 like -
Replying to @quasi42
I've seen a few customers who run Lambda triggered functions to scrape the IPs for their ELB/ALB/Beanstalk and register them with an NLB as they change.
1 reply 0 retweets 0 likes -
Replying to @colmmacc
Yeah, I've seen that solution in the past. From reading descriptions people were picking up changes at 5 minutes or so and that's way too long for me. The 10s from haproxy dns lookups is really about as long as I can wait.
1 reply 0 retweets 0 likes
Just curious why it's too long? The underlying load balancer in front of beanstalk is always scaled for sudden availability zone failure, so there's quite a bit of slack.
-
-
Replying to @colmmacc
If the config of the ALB changes and it's going to take 5 minutes for my NLB to route to the new ALB ips. (There's a little extra pain because one $customer can't failover on their end if one of my 2 public ips stop responding).I'll still take it for a spin and see if it's ok now
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.