Send UDP Multicast from Lambda to EC2

0

I understand that receiving UDP traffic with a Lambda isn't supported. Please don't answer regarding the event driven nature of lambda, etc. I understand that well.

My situation is wanting to send UDP packets to an ASG of EC2 instances, where each instance has joined a multicast group. The VPC is correctly configured for multicast and messages can be exchanged between different ASGs with different multicast groups exactly as I expect.

I've configured a Lambda in the same VPC, with the same subnets. The lambda is able to send UDP packets to any instance directly using unicast IP addresses. However, the packets don't get to the instances when using the multicast IP. Further, it seems that the Reachability Analyzer can't find a path between the Lambda and the multicast IP.

I just want to confirm that I've not misconfigured something and this lack of support for UDP multicast from Lambda to EC2 is indeed the case, and intentional. I ask because it seems like a serious gap in functionality that doesn't seem to have a reasonable rational since the Lambda has an IP in the VPC courtesy of the network interface, and the network interfaces used by EC2 are all working as I'd expect.

Do I need to give up on sending multicast UDP from Lambda?

2 Answers
1

The answer given by the re:Post Agent here is accurate.

In order to use multicast in a VPC you must use a Transit Gateway. This means that traffic from a multicast sender has to cross a Transit Gateway so that it can then send the packets to another VPC where the multicast listeners/subscribers are. Ref: https://docs.aws.amazon.com/vpc/latest/tgw/tgw-multicast-overview.html

At a conceptual level, for the vast majority of networking a Lambda function which has been assigned to a VPC subnet behaves exactly like an EC2 instance on that same subnet. You will find that if you set up an EC2 instance in your VPC that it is also unable to send (or receive for that matter) multicast packets unless Transit Gateway is used.

The other advice about using alternate ways of sending traffic from client (Lambda) to server (EC2) in the answer is also valid.

In your question you haven't said why you want to use multicast. My guess is that you want low-latency transmission for small amounts of data. This is a valid reason to use multicast but within a VPC it comes with the requirement for Transit Gateway. So it might be easier/better/less expensive to use an alternative such as SQS, SNS or even Kinesis.

profile pictureAWS
EXPERT
answered 9 days ago
profile picture
EXPERT
reviewed 8 days ago
  • Why I want to use it isn't relevant. And, as I stated it's working already when the sends are from an EC2 instance (e.g. echo "*" > /dev/udp/239.11.11.11/1111), so of course a TransitGateway and MulticastDomain are already in place. Yet, traffic from Lambda doesn't arrive at instances.

  • No to pile on, but to clarify: With multicast UDP I can send (with low latency, and extremely inexpensively) to an unknown (and dynamically changing) number of instances. This is a basic networking communication capability in use for a very long time, and supported by VPCs since 2020 as far as I can tell.

    The only plausible alternative is SNS, which allows blind casting with a subscription taking the place of the multicast join for the instances. That involves extra latency and cost, as well as an extra dependency on the instances (it's not less expensive, nor easier).

    My problem, and subject of the question "Do I need to give up on sending multicast UDP from Lambda?" is that the documentation is silent on whether or not this should work. The re:Post agent made up content from a source to speculate as to an answer, but is in no way authoritative. Is there any actual documentation that this should not be expected to work?

0

Based on the information available, it appears that sending UDP multicast traffic from Lambda to EC2 instances is not supported, even when the Lambda function is configured in the same VPC and subnets as the EC2 instances.

While Lambda functions can send unicast UDP packets to specific EC2 instances, the ability to send multicast UDP packets is not supported. This limitation seems to be intentional, as the Reachability Analyzer is unable to find a path between the Lambda function and the multicast IP address.

The multicast functionality in AWS is primarily designed to work with EC2 instances and Transit Gateways. Transit Gateways support routing multicast traffic between subnets of attached VPCs and act as multicast routers for instances sending traffic destined for multiple receiving instances. However, this functionality does not extend to Lambda functions.

Given these limitations, it appears that you may need to consider alternative approaches for sending multicast UDP traffic to your EC2 instances. Some possible workarounds could include:

  1. Using an EC2 instance as an intermediary to receive unicast traffic from the Lambda function and then forward it as multicast to the target EC2 instances.

  2. Implementing a different communication pattern, such as using Amazon SNS or SQS to distribute messages to multiple EC2 instances.

  3. If possible, restructuring your application to use EC2 instances instead of Lambda for the components that need to send multicast UDP traffic.

While it may seem like a gap in functionality, it's important to note that Lambda functions are designed with specific use cases in mind, and not all networking capabilities available to EC2 instances are supported in Lambda. If sending multicast UDP from Lambda is a critical requirement for your application, you may need to reconsider your architecture or explore alternative AWS services that better suit your needs.
Sources
Multicast in Amazon VPC Transit Gateways - Amazon VPC

profile picture
answered 9 days ago
profile pictureAWS
EXPERT
reviewed 9 days ago
  • The source identified by Q doesn't mention Lambda in any capacity. Made-up answer.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions