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.
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?
Nice! I wonder if this is a preparatory step for future quick/http3 support?
That's great! Any idea what Load balancing algorithm this would use?
We have a need for some stickiness in the load balancer (for example: UDP Packets from a source must be routed to the same instance, at least for a short while)
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.
Apparently if the target is the instance ID this can preserve public source IP and port. That can be a big deal for e.g. bootstrap nodes for P2P networks.
Can be nice for games, QUIC and DNSCrypt.
Curious: How does one generally load balance udp? Drop packets? Slow them down?
With that out of the way ... hope they can add IPv6 support next!
A plug for our (Cloudflare's) product — we support managed load balancing for UDP as well.
- https://blog.cloudflare.com/spectrum-for-udp-ddos-protection...
- https://blog.cloudflare.com/introducing-spectrum-with-load-b...
Sweet. Now add support for multiple ports on a single service[1] and this load balancer might actually become useful.
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