Wowza Community

CDN vs Edge Server

I’m looking for information on live steaming using either a CDN or Edge servers.

I have setup the Wowza CDN and tested a live stream and wondering what is the difference between these two options, seems like they do the same thing?

Would an Edge server support client RTMP streaming that the CDN does not?



I found the setup instructions for an Edge server and see that option supports RTMP for clients

So now my question is how do I get Wowza Edge Servers, not able to find that information?

A CDN is a managed service that will automatically scale, typically in a global capacity. An “edge” server is a single server instance (i.e. Linux or Windows) running Wowza Streaming Engine, configured as a live stream repeater. The benefits, as you have discovered, is the ability to use a broader set of features and protocol, on the edge. The challenge is you will be limited by each server’s network capacity, meaning you may need to deploy additional edge servers and use a load balancer to manage geography and capacity across your servers.

Take a look at this tutorial as a starting point:

Configure a live stream repeater in Wowza Streaming Engine -

Thanks Tim,

I did find that tutorial which is how I saw I could use RTMP.

When we live stream we also have 4 - 8 language translations we also stream and are accessed using a separate audio player on the webpage.

RTMP does the best job of keeping the the audio closely in sync with the video.

HLS does not work well for this setup so if I used the CDN option I would only have that available to English users.

We have a worldwide audience so my thought was to have an edge server in Europe and Asia as a start.

It looks like to get an edge server I need to use Amazon, Microsoft, or other cloud based service.

Do you have any knowledge on which edge server options are best?



Hi Kirk,

AWS, Azure, and Google Cloud are likely the most prevalent options, but you can use any cloud provider. You may select any server profile you perfer, where Wowza should have 8-16 Mb of system memory and, as a primary constraint, enough network capacity to maximize the number of client connections. On the network side, use this rule as a guide:

(stream bitrate * max concurrent clients) < server bandwidth

As an example, suppose you’re using AWS/EC2 where you had to server 50-100 clients, per edge server, at approximately 3 Mbps, the m4.large or m4.xlarge instance size will suffice. It’s always a good practice to test, even using the Wowza Load Test Tool, to determine actual capacity, given your unique workflow. If you find the smaller instance does not have enough capacity, you can always increase the instance type, as needed.

Thanks again Tim,

I did look at those options today and the pricing for Amazon looks good (Google was not very clear) but I’m not a Linux user so will need to see if that will work for me.

I have already run the Load Test Tool on the origin server and that was helpful to know the limits, 800 looks comfortable, at 1000 I noticed some slight buffering so will definitely test the edges to determine capacity.

The CDN option might end up being the best option since I would only need the extra capacity for larger live streams (3-4 times a year) and English viewers would be the majority, so the extra cost would be limited to just those events and not a monthly cost when there may be no usage, unless it makes sense to use the edge servers for VOD as well.



You’ll definitely be saving yourself a lot of effort, leveraging a CDN. It’s as easy as turning on a Stream Target, on the origin, to source a CDN implementation. Be sure to take a look at commercial CND options from Wowza - we’d love to have your business.


Yes, I came to that conclusion earlier today after looking over the edge options again, seemed like a lot of effort for the occasional live stream I might need that for.

I do have the Wowza CDN attached to my License and already have that configured so it’s ready when needed, is that the “commercial CDN option” you referred to?


If the speed is too low - this is fraught with the loss of the audience, and in many cases - also profit. One reliable way to solve this problem is to use CDNs.I live in property in Côte d’Azur and I use Wowza CDN and it works perfectly.

Thanks Henrich,

I did come to the conclusion that the Wowza CDN was our best overflow option but only for English viewers, we still need RTMP for those using translation services due to HLS latency affecting the trnalation sync to the video.

Hi Kirk- Yes, a “commercial CDN” would include Wowza CDN. Thank you! -Tim

Hi Tim,

I’m having an issue with Stream Targets. I’m assuming once I create a stream target it’s there to use when I need it.

During my testing I’ve had issues with the stream target not seeing the incoming streams and have not found a way to get them working except to delete and recreate.

This is not the best solution since I then have to update the players with the new link each time.

Is there a way to resolve this or should I only create these right before I start a live stream?




This should all be static - no need to fuss with different URL’s every time.

Let’s troubleshoot your Stream Targets. Please share your end-to-end workflow (source, how you’re ingesting into Wowza, and some detail about your Stream Targets endpoint).


One question before the workflow, I had also tested pushing directly to the Wowza CDN to transcode and stream. If I used the same stream name for that setup as the stream name I used for the source when I created the stream target would that cause a conflict that might be the cause of this issue?

For my source it comes from a video mixer that has different sources available, for testing I’m playing a video from a laptop into the mixer then to a computer via an Osprey capture card.

I use Adobe Encoder on the computer to push the content (single bitrate) to the Wowza server via port 1935.

I have a transcoder setup for the application to create 5 different bitrates and the nDVR is enabled.

I create a stream target for Wowza CDN giving it a unique name, the name of the origin stream and set to multi-bitrate with server set to redundant.

It always works when I setup and test, it’s when I come back later and start up a stream to test that it sometimes fails.

I have been trying many configurations during my testing so it could be just an issue with all the changes I’m making, but I’m done now so I will try streaming each day this week to see if there is still an issue.

We have our first live stream this Saturday but it’s only one day, so if needed having to recreate would not be a big deal, but the following Sunday we start a 7 day live stream so want to make sure I have this sorted out by then.




I do have two different live applications each with a stream target setup.

Yesterday one was working and the other not, I deleted the non-working target and recreated and tested.

I made no changes since yesterday and now have another test running and both stream targets are not working.

I tried disabling just the target and then the stream target option for both and no change.

I setup the targets again and noticed on the cloud page for the target info this comment:

A Connection Code is available if the target uses a video source, such as Wowza Streaming Engine, that is passing a stream or group of transcoded, adaptive bitrate streams through Wowza Streaming Cloud. Wowza Streaming Cloud delivers these streams directly to the stream target without performing any of its own transcoding. Enter the six-digit Connection Code in the administrative interface or dashboard of the encoder when you configure it to send the video source to Wowza Streaming Cloud. The Connection Code can be used once and expires 24 hours after it’s created. To create a new code, click Regenerate Connection Code.

Could this be the issue, that I have to renew the code every 24 hrs or the next time I want to use the CDN target?

I started the live streams today to check the stream target status after 4 days of no activaty and they are both working.

I’m going to assume at this point that the issue was related to all the different test scenarios I was trying.