Most public clouds, including AWS, block multicast. This is due to it's "chatty" nature and the fact they use these types of protocols to provide the cloud to you, the customer. Read more on "Why is Multicast Disabled in the cloud?" on our blog.
Rather than re-architect your applications, you can use VNS3 Overlay Networks to redistribute blocked protocols like UDP Multicast in public cloud.
3 Steps to enable multicast with VNS3 overlay:
The VNS3 Overlay Network traffic moves through the cloud on UDP 1194. All traffic in the Overlay Networks is encrypted (don't worry dynamic compression means most enterprise traffic gets the encryption benefit at zero performance cost) and encapsulated. As a result the cloud provider doesn't block the traffic and VNS3 redistributes as appropriate.
Create an overlay network in 3 basic steps:
Step 1 - Launch and Deploy VNS3 Controller
The VNS3 controller will act as the encrypted switch for all Overlay Network traffic in cloud and as the encrypted router to address spaces available outside the Overlay Network via tunnels (GRE), VPNs (IPsec or SSL/TLS), Routes (VPC/VNET peering, Direct Connect/ExpressRoute), etc. VNS3 is available in the major cloud catalogs (AWS | Azure) or through private account sharing (create a support ticket on this site).
Step 2 - Generate the VNS3 Overlay Network Clientpacks
To deploy the VNS3 Overlay Network, you will use VNS3 to create unique cryptographic X.509 credentials (called clientpacks) which are associated with a specific IP address inside the VNS3 Overlay Network space. This operation is as simple as selecting an Overlay Network address space and click Generate. VNS3 does the heavy lifting (key generation, address burn in, and configuration file creation). What you're left with is a set of files that are ready to be distributed your cloud-based servers.
Step 3 - Connect cloud Servers to the Overlay Network
Clientpacks are then distributed to the cloud-based servers along with a SSL/TLS client (like OpenVPN) that will join the Overlay Network to pass/receive the multicast or broad cast packets. The SSL/TLS client process uses the clientpack to make an encrypted connection to the VNS3 controller. This is similar to how a physical server connects to a switch using a CAT cable but VNS3 makes the connection via software (virtual) instead of hardware. Overlay Network traffic is then passed through the VNS3 encrypted switch.
Finally depending on your use-case you can then use the VNS3 controller to build site-to-site connections to complete a hybrid cloud deployment that leverages multicast and broadcast similar to the diagram below.
Other Notes:
Windows Bug in Route Metrics: Even if the tunneling TAP adapter shows as the lowest route metric Windows may not send the multicast traffic to that adapter. In a command terminal on Windows with Admin privileges execute
route delete 224.0.0.0/4
Then start (or stop/start if already running) the tunneling agent so that its route to multicast gets installed.
Testing - You can use your own application for testing but we also provide some simple python scripts for sending and receiving multicast messages (Sender | Receiver) or get this EXCELLENT utility by Satoru SATOH from Github https://github.com/ssato/misc/blob/master/multicast.py
Network Sniffer - You can use the VNS3 Network Sniffer from the Controller UI as a troubleshooting tool. You can monitor both the public IP network interface and the tun0 Overlay Network interface. See the FAQ on Network Sniffer
Sealed Overlay Network - You can choose to route all server traffic through the Overlay Network per the requirements of your use-case. To route all all client traffic through the VNS3 overlay, see this FAQ guide.
Setup and Configuration Details - Follow the full VNS3 configuration steps in this PDF documentation for more details on creating clientpacks (page 17), peering VNS3 Controllers (page 19), and configuring Windows or Linux clients on the overlay (page 45-58).