Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New AWS UDP Load Balancing for Network Load Balancer

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: New AWS UDP Load Balancing for Network Load Balancer

#21

Post by nullwasamistake »

Jedd wrote: post #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?

Lots of people use IPVS but the more efficient modes don't work on AWS. Generally why most that need a LOT of traffic use a cloud provider for regular servers and their own servers in CoLo for heavy stuff.

With how Amazon likes to use OSS in their services I'm pretty sure their UDP load balancer are in fact just using IPVS

Re: New AWS UDP Load Balancing for Network Load Balancer

#22

Post by robohoe »

mark242 wrote: 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.

I wonder if the AWS Route53 VPC resolvers work in that same way for internal VPC DNS resolution.

Re: New AWS UDP Load Balancing for Network Load Balancer

#23

Post by cortesoft »

not_kurt_godel wrote: post #11
mark242 wrote: 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…

Nothing is forcing you to switch from your custom solution to the native support. If you don't switch, you are in the same situation as if they native solution was never invented.

Re: New AWS UDP Load Balancing for Network Load Balancer

#25

Post by celim307 »

zedpm wrote: post #14

This is great news, and something I’ve been requesting for years. I manage an IoT backend based on CoAP, which is typically UDP-based. I’ve looked at Nginx support for UDP, but a managed load balancer is much more appealing.

Same story here, getting NGINX to help even with highest support tiers was a PIA too

Re: New AWS UDP Load Balancing for Network Load Balancer

#26

Post by colmmacc »

nullwasamistake wrote: post #21
Jedd wrote: post #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?

Lots of people use IPVS but the more efficient modes don't work on AWS. Generally why most that need a LOT of traffic use a cloud provider for regular servers and their own servers in CoLo for heavy stuff. With how Amazon likes to use OSS in their services I'm pretty sure their UDP load balancer are in fact just using IPVS

NLB is built on top of AWS HyperPlane, a hybrid system that has components distributed in our Nitro security system, and pseudo-central components that keep flow-tracking state. It's different from IPVS.

Re: New AWS UDP Load Balancing for Network Load Balancer

#28

Post by Jedd »

nullwasamistake wrote: post #21
Jedd wrote: post #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?

Lots of people use IPVS but the more efficient modes don't work on AWS. Generally why most that need a LOT of traffic use a cloud provider for regular servers and their own servers in CoLo for heavy stuff. With how Amazon likes to use OSS in their services I'm pretty sure their UDP load balancer are in fact just using IPVS

Interesting, thanks. Hadn't considered this option before, and will do some more exploring, though I note on the IPVS page they say:

"For scheduling UDP datagrams, IPVS load balancer records UDP datagram scheduling with configurable timeout, and the default UDP timeout is 300 seconds. Before UDP connection timeouts, all UDP datagrams from the same socket (protocol, ip address and port) will be directed to the same server."

I'm hopeful / confident that affinity can be fully de-tuned here, as we're looking at around 5-10k UDP Netflows per second from a given router that need to be distributed to a set of receivers.

Re: New AWS UDP Load Balancing for Network Load Balancer

#29

Post by dnautics »

bboreham wrote: post #27
dnautics wrote: post #24

Curious: How does one generally load balance udp? Drop packets? Slow them down?

It means taking a set of packets sent to one address and spreading them across multiple servers to share out the load.

oh, geez. Thank you. Somehow I was thinking about throttling, not load balancing.

Re: New AWS UDP Load Balancing for Network Load Balancer

#30

Post by y4mi »

cortesoft wrote: post #23
not_kurt_godel wrote: post #11

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…

Nothing is forcing you to switch from your custom solution to the native support. If you don't switch, you are in the same situation as if they native solution was never invented.

Nothing except every new hire that complains having to learn it instead of the native solution.

It's just like the parent said very much a first world problem/ good problem to have, as it's a situation which only exists if you're in a very productive team

Post reply on HN