- Newest
- Most votes
- Most comments
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.
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:
-
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.
-
Implementing a different communication pattern, such as using Amazon SNS or SQS to distribute messages to multiple EC2 instances.
-
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
The source identified by Q doesn't mention Lambda in any capacity. Made-up answer.
Relevant content
- asked 2 years ago
- asked 3 years ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 8 months 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?