Live data from Hacker News

New AWS UDP Load Balancing for Network Load Balancer

aws.amazon.com

11–20 of 35 posts

Re: New AWS UDP Load Balancing for Network Load Balancer

#11
post #8

This is big for making services which rely on DNS much easier to roll out in a container environment (ECS, EKS, etc). Traditionally we've had to create custom AMI images, use CloudFormation to keep them running with EIPs, and then have those EIPs be part of runtime configuration for our services.

One "downside" of AWS is we've rolled a lot of custom solutions like this, at significant time/expense, only to have them be made obsolete by eventual native feature support. So we get left with a mixture of legacy systems using the custom solution and newer ones using native support and it makes things more complicated. It's actually a good problem to have in many ways, and basically unavoidable in many circumstances, but an interesting dynamic nonetheless. Reminds me of interstellar wait calculation[0] - do we defer dependent features until there's native support, or forge ahead knowing there's a likelihood of being 'overtaken'?

[0] https://en.m.wikipedia.org/wiki/Interstellar_travel#Wait_cal...

Re: New AWS UDP Load Balancing for Network Load Balancer

#12
post #8

This is big for making services which rely on DNS much easier to roll out in a container environment (ECS, EKS, etc). Traditionally we've had to create custom AMI images, use CloudFormation to keep them running with EIPs, and then have those EIPs be part of runtime configuration for our services.

Can you elaborate a bit on your architecture? I'd love to understand what your use case is.

In most architectures I've seen where containers are involved, the rendezvous point between external clients and containerized services is an external proxy (i.e., a load balancer), and the only DNS lookup required by such clients is of the proxy itself, so no DNS UDP traffic needs to be sent into the cluster. In K8S we call this proxy an "ingress."

Is the situation that you want to expose the cluster's internal DNS to the outside world to avoid having to configure ingress? Or is it something else?

Re: New AWS UDP Load Balancing for Network Load Balancer

#13
post #8

This is big for making services which rely on DNS much easier to roll out in a container environment (ECS, EKS, etc). Traditionally we've had to create custom AMI images, use CloudFormation to keep them running with EIPs, and then have those EIPs be part of runtime configuration for our services.

One "downside" of AWS is we've rolled a lot of custom solutions like this, at significant time/expense, only to have them be made obsolete by eventual native feature support. So we get left with a mixture of legacy systems using the custom solution and newer ones using native support and it makes things more complicated. It's actually a good problem to have in many ways, and basically unavoidable in many circumstance…

Another way to look at it: customers like you, who build custom work arounds to some problem, influence our decision that a particular problem is important enough to be solved.

Re: New AWS UDP Load Balancing for Network Load Balancer

#15
This is a Big Deal because it enables support for QUIC, which is now being standardized as HTTP/3.

To work around the TCP head of line blocking problem (among others) QUIC aises UDP.

QUIC does some incredible patching over legacy decisions in the TCP and IP stack to make things faster, more reliable especially on mobile networks, and more secure.

Here’s a great summary from Fastly on what QUIC means for the Internet: https://www.fastly.com/blog/why-fastly-loves-quic-http3

Re: New AWS UDP Load Balancing for Network Load Balancer

#16
Related - has anyone done much with UDP load balancing on prem?

We're starting to hit performance and HA walls with ingesting Netflows from edge routers - you can only nominate one target, and using Elasticsearch / Logstash there are some hard limits.

Would AWS be appropriating nginx under the hood here?

Re: New AWS UDP Load Balancing for Network Load Balancer

#17
post #8

This is big for making services which rely on DNS much easier to roll out in a container environment (ECS, EKS, etc). Traditionally we've had to create custom AMI images, use CloudFormation to keep them running with EIPs, and then have those EIPs be part of runtime configuration for our services.

Can you elaborate a bit on your architecture? I'd love to understand what your use case is. In most architectures I've seen where containers are involved, the rendezvous point between external clients and containerized services is an external proxy (i.e., a load balancer), and the only DNS lookup required by such clients is of the proxy itself, so no DNS UDP traffic needs to be sent into the cluster. In K8S we call t…

I could see an SRV record style of load balancing being done on containers optimizing that layer by reducing a hop

Re: New AWS UDP Load Balancing for Network Load Balancer

#18
post #8

This is big for making services which rely on DNS much easier to roll out in a container environment (ECS, EKS, etc). Traditionally we've had to create custom AMI images, use CloudFormation to keep them running with EIPs, and then have those EIPs be part of runtime configuration for our services.

Can you elaborate a bit on your architecture? I'd love to understand what your use case is. In most architectures I've seen where containers are involved, the rendezvous point between external clients and containerized services is an external proxy (i.e., a load balancer), and the only DNS lookup required by such clients is of the proxy itself, so no DNS UDP traffic needs to be sent into the cluster. In K8S we call t…

Containers that require custom DNS queries about incoming connections from a non-HTTP service (we're using the NLB for this), using a caching DNS server that isn't publicly accessible.

Re: New AWS UDP Load Balancing for Network Load Balancer

#20
post #13

Earlier quoted context omitted.

One "downside" of AWS is we've rolled a lot of custom solutions like this, at significant time/expense, only to have them be made obsolete by eventual native feature support. So we get left with a mixture of legacy systems using the custom solution and newer ones using native support and it makes things more complicated. It's actually a good problem to have in many ways, and basically unavoidable in many circumstance…

Another way to look at it: customers like you, who build custom work arounds to some problem, influence our decision that a particular problem is important enough to be solved.

Yup, and that's overwhelmingly a good thing! The one thing I will say is that AWS does tend to lean on this attitude a bit too much, IMO, with a tendency to ignore common sense about what people will inevitably need, thus causing the kind of thrash I described when it could have been avoided. It is erring on the right side of delivering vs waiting generally, but the balance could stand to be fine tuned.
Post reply on HN