Integrate a Wowza Streaming Engine EC2 instance with CloudFront

A CloudFront distribution is an HTTP caching infrastructure that enables you to distribute content by using a worldwide network of edge locations that provide low latency and high data-transfer speeds. Wowza Streaming Engine™ media server software can be used as an HTTP caching origin to an Amazon CloudFront distribution for delivery of video-on-demand (VOD) and live streams by using the Apple HLS, Adobe HDS, Microsoft Smooth Streaming, and MPEG-DASH protocols. This article describes how to configure the streaming applications in your EC2 instance and attach them to a CloudFront distribution.



About Wowza Streaming Engine HTTP caching origin
Configuring HTTP origin applications for CloudFront Updating your applications in the Amazon EC2 instance store
Creating the CloudFront distribution
Publishing a live stream to the HTTP origin
Using the Test Players
Playback from CloudFront distribution
Controlling how long CloudFront caches errors
Deleting the CloudFront distribution

About Wowza Streaming Engine HTTP caching origin

When using Wowza Streaming Engine as an HTTP caching origin:
  • The CloudFront distribution is an HTTP caching infrastructure that pulls HTTP chunks from your Wowza Streaming Engine server HTTP caching origin and caches them. All clients receive the same cached data.
  • Communication with the Wowza Streaming Engine HTTP caching origin is sessionless; session-based communication doesn't work. A single session is created internally for the requested protocol. This session is based on the stream name and it's used for every request for that name. This has the following ramifications:
    • URL query parameters in player requests aren't supported. This includes the wowzaplaystart and wowzaplayduration parameters for VOD playback, the wowzadvrplayliststart and wowzadvrplaylistduration for nDVR playback, and any custom parameters. (This does not include the DVR query parameter that's required for DVR playback.) If query parameters are set, only the parameters that are set when the stream name is initially requested are used. Subsequent changes to these parameters, either from the same player or a different one, are ignored.
    • Session-specific information such as connection counts isn't relevant and, therefore, isn't available.
  • At this time, live streams can't be delivered securely by using CloudFront-signed URLs due to the nature by which player applications generate URL requests for the live stream data. However, progressively downloaded media can be delivered privately by using signed URLs. For more information, see Serving Private Content through Cloudfront.
For HTTP caching to work properly, the following aspects of HTTP streaming behave differently:
  • The Wowza Streaming Engine session identifier (_wXXXXXXXXX) must be removed from all playlist and manifest data. This is done automatically when you enable Wowza Streaming Engine to be an HTTP caching origin. For more information, see Configuring HTTP origin applications for CloudFront.
  • HTTP caching headers must be set to enable content caching.
  • Random identifiers must be added to live media chunk and fragmented URLs. This ensures that caching is unique for each encoder session.

Configuring HTTP origin applications for CloudFront

Configuration in Wowza Streaming Engine Manager

To use your Wowza Streaming Engine EC2 AMI with CloudFront, create a new application whose type is Live HTTP Origin or VOD HTTP Origin. The default settings of the HTTP origin applications will work with CloudFront. To use the default live, vod, and vods3 applications with CloudFront, you have to set HTTPStreamer properties in Application.xml (for more information, see XML configuration).

The following procedure sets up a Live HTTP Origin application in Wowza Streaming Engine Manager (the procedure uses the livehttporigin application setup as an example, and the vodhttporigin application setup is very similar.)
  1. Start Wowza Streaming Engine Manager by opening http://[instance-public-dns]:8088 in a supported web browser. (Chrome is recommended.)
  2. Sign in with the preconfigured administrator account. The user name is wowza and the password is the instance ID of the EC2 AMI. You can find the ID on the Instances page of the Amazon EC2 dashboard.
  3. Click the Applications tab, and then click Add Application in the contents panel.
  4. On the Add Application page, click either Live HTTP Origin (for live streaming) or VOD HTTP Origin (for video on demand streaming). These origin application types are designed for non-Wowza edge caching.

  5. In the New Application dialog box, name your application and click Add.

  6. Click Save to save the application with default values.

    The application is ready to use as an origin to an HTTP caching infrastructure.
Note: As shown in the previous figure, HTTP origin applications support all HTTP streaming playback types by default. They don't support the RTMP and RTSP playback types.
HTTP cache origin properties are automatically enabled and set to default values for each of the selected Playback Types for the application. To change the default application property values, click the Properties tab, and then click HTTP Cache Origin in the Quick Links bar. To configure the default property values and to add custom properties, see the Property reference section in the article "Configure Wowza Streaming Engine as an HTTP caching origin."
Note: Access to the Properties tab is limited to administrators with advanced permissions. For more information, see Manage credentials.

Configure source authentication

To set up authentication for encoders and cameras that publish live streams to Wowza Streaming Engine, complete the following procedure. The source authentication requirement is on by default so you'll have to configure the source's credentials.
  1. In the contents panel, click Source Security, and then click Edit. The Source Security page is displayed.

    • Under RTMP Sources, select Require password authentication.
    • Under RTSP Sources, select Require password authentication.
  2. Click Save, and then restart the application.

  3. Configure the source user name and password to publish to this application:
    1. In the Server contents panel, click Source Authentication, and then click Add Source.

    2. In the Source > [new] page, enter Source User Name and Password information, and then click Add.

XML configuration

To set up Live HTTP Origin or VOD HTTP Origin applications in XML, you must add properties to the [install-dir]/conf/live/Application.xml file in your Amazon EC2 instance storage to configure the application as an HTTP caching origin. You'll have to use this method if you want to modify the installed live, vod, and vods3 applications to use CloudFront caching.

For more information about default property values and to add custom properties, see the Property reference section in the article "Configure Wowza Streaming Engine as an HTTP caching origin."

Note: Modifying XML elements of Application.xml in a text editor is mainly done when using earlier versions of the server software that don't support Streaming Engine Manager. You can still use this method to modify application properties in Wowza Streaming Engine 4.0 and later, for example, to enable the live, vod, and vods3 applications as caching origins for CloudFront. Any supported settings will be displayed in the manager the next time it's started.

Updating your applications in the Amazon EC2 instance store

The following Wowza Streaming Engine applications are included in the Amazon EC2 instance store by default:
  • live - Live streaming.
  • vod - Video-on-demand streaming from local disk.
  • vods3 - VOD streaming from Amazon Simple Storage Service.

If you're going to use the vod application, you'll have to upload media assets to the EC2 instance that's running Wowza Streaming Engine. This requires an FTP connection to the EC2 instance. If you're running Wowza Media Server™ 3.6.4, you must add properties to the Application.xml file for the applications in your Amazon EC2 instance store to configure them as HTTP caching origins that will work with a CloudFront distribution (See XML configuration).

This section describes the process for connecting to an EC2 instance by using FTP and SSH.

Note: Only users with advanced knowledge of Linux commands should use SSH.

Connect using an FTP client

You can use an FTP client to connect to your running Streaming Engine EC2 instance to upload an updated Application.xml file for an application. For convenience, most of the Wowza Streaming Engine folders are symbolically linked to the /home/wowza folder for easy access using FTP.

Wowza Streaming Engine EC2 instances include the vsftpd FTP Server for Linux. A default wowza FTP user account is set up in the system with the password set to the EC2 instance ID (this is done for security reasons).

To get the information that you'll need to connect to your EC2 instance, sign in to the Amazon AWS EC2 Management Console, select the running instance that you want to configure, and note the following values:
  • Instance ID - This value is shown in the Instance column. It always starts with i-.
  • Host - You will typically specify the hostname in the FTP client to connect. This is the Public DNS value on the Description tab.
To connect to the EC2 instance using FTP, do the following:
  1. Review the notes below to make sure that your FTP client can connect, and then set up a client connection to the running EC2 instance. Be sure to specify the following connection values:
    • Host - The EC2 instance Public DNS value.
    • Login/Username - The default FTP username (wowza).
    • Password - The EC2 instance ID.
  2. In your FTP client, navigate to the following remote site: /home/wowza/conf/[application].
  3. Download the Application.xml file to your local computer.
  4. Open the Application.xml file in a text editor, and then add the required properties to the file. See XML configuration.
  5. Use the FTP client to upload the updated Application.xml file to /home/wowza/conf/[application].
  6. Disconnect the FTP client from the EC2 instance.
  7. Reboot the EC2 instance to enable the changes.
  • TCP port 21 must be opened in the Security Groups setting for the EC2 instance so that you can connect to it using FTP.
  • You must configure your FTP client to use the Active Mode connection type. The FTP configuration doesn't support Passive Mode. For more information, consult your FTP client documentation.

Connect using an SSH client

You can use SSH to open a secure session to your Amazon EC2 instance and make configuration changes. Public AMI instances use a public/private key pair to log in instead of a password. The public key half of this pair is embedded in your instance, allowing you to use the private key half to log in securely without a password. You can use the key pair that you created for the region in which your Amazon EC2 instance is running.

To connect to the EC2 instance using SSH, do the following:
  1. Sign in to the Amazon AWS EC2 Management Console, and then select the running instance that you want to configure.
  2. Click Connect at the top of the page.
  3. The Connect to Your Instance dialog box provides instructions for connecting to the instance by using either a standalone SSH client (including PuTTY for Windows) or the browser-based Java SSH Client. Review the instructions provided for the option that you want to use.
  4. When you launch your SSH client, be sure to log in with the username ec2-user.
    Note: When working with Wowza Streaming Engine, it's best to be logged in as the root user. After you log in as the ec2-user, you can switch to the root user by entering the following command in the command window:
    sudo su -
  5. Change directory to the /usr/local/WowzaStreamingEngine/conf/[application] folder, and then add the required properties to the Application.xml file for the application. See Configuring HTTP origin applications for CloudFront for details.
  6. Disconnect the SSH client from the EC2 instance (enter the exit command or press CTRL+D).
  7. Reboot the EC2 instance to enable the changes. 
Note: TCP port 22 must be opened in the Security Groups setting for the EC2 instance so that you can connect to it using SSH.

Creating the CloudFront distribution

This section describes how to create a CloudFront distribution that uses your updated application as an HTTP origin for live streaming.
  1. Sign in to the CloudFront Management console.
  2. Click Create Distribution.
  3. On the Select delivery method page, select the Web delivery method option, and then click Continue.
  4. On the Create distribution page, in Origin Domain Name, enter the Public DNS value for your EC2 instance.
  5. Configure the remaining settings on the Create distribution page, and then click Create Distribution.
    Note: The CloudFront Distribution setup includes the Forward Query Strings option, which enables CloudFront edge locations to include query strings for session-based communication in request URLs that it forwards to the Wowza Streaming Engine HTTP caching origin. Because communication with the Streaming Engine HTTP caching origin is sessionless, query string parameters that are included in forwarded URLs may not work as expected.
  6. The CloudFront distribution may take several minutes to create. You can track creation progress in the Status column for the distribution. The Status value will change from InProgress to Deployed when the distribution is created.
  7. After the distribution is deployed, be sure to note the distribution Domain Name value, which must be included in the playback URLs provided to clients. In the Playback from CloudFront distribution section, you must replace [cloudfront-domain-name] in the sample URLs with this value.

Publishing a live stream to the HTTP origin

You need to encode the live stream captured by your device before you send it to the Wowza Streaming Engine EC2 origin. Wowza Streaming Engine supports integrated publishing for many popular encoders and cameras to simplify live streaming workflows. You can create live application connection settings in Wowza Streaming Engine to enable Wowza GoCoder™, Wowza's encoding app for Apple iOS and Android mobile devices, and other supported encoders and cameras to publish a stream automatically. For more information see Connect live sources.

Wowza Gocoder

To configure Wowza GoCoder to publish a live stream, follow the instructions in Connect the Wowza GoCoder encoding app to Wowza Streaming Engine. If you choose to configure Wowza GoCoder settings manually, be sure to use the following parameters:
Host settings
  1. Sign in to the Amazon AWS EC2 Management Console, and then select the Wowza Streaming Engine origin instance.
  2. In the bottom pane of the EC2 console, click the Description tab.
  3. Copy the value of the Public DNS key for the EC2 instance (for example,, and then paste it into the Server field in the Wowza GoCoder Host settings.
  4. In the Wowza GoCoder Host settings, in the Port field, enter 1935.
Application settings
  1. In the Wowza GoCoder Application settings, in the Application field, enter the application name, for example, live.
  2. In the Stream Name field, enter the stream name, for example, myStream.

RTMP encoder

You can also encode the live stream using other encoders and cameras that support H.264 encoding. The steps for publishing a stream from your encoder or camera to Wowza Streaming Engine vary with your choice of device. For more information, see Connect a live source to Wowza Streaming Engine or review the documentation for your device.

The parameters typically used in RTMP encoders are:
  • Publish URL - For example, rtmp://[instance-public-dns]/live (where [instance-public-dns] is the public domain name of your running instance).
  • Stream Name - For example, myStream.

Using the Test Players

In Wowza Streaming Engine Manager, click Test Players in the upper-right corner of the livehttporigin application page. The Test Players window that opens includes test players that are preconfigured to stream using various streaming protocols.

Each tab in the Test Players window either hosts a test player that you can use to play the live stream or provides instructions for playing the stream. Amazon CloudFront supports only HTTP streaming, so you can't use the Adobe RTMP tab in this case.

For example, to use the Microsoft Smooth Streaming protocol to play a live stream from the CloudFront distribution:
  1. Click the MS Smooth tab.
  2. In the Server text box, enter the distribution Domain Name from the CloudFront Distributions dashboard.
  3. In the Application text box, enter livehttporigin.
  4. In the Stream text box, enter myStream.
  5. Click Start.

The test players are also online on our Video Test Players webpage.

Note: For VOD streaming with your CloudFront distribution, see Streaming video-on-demand content, which describes how to re-stream the sample.mp4 file.

Playback from CloudFront distribution

All HTTP requests made to the [cloudfront-domain-name] are routed to an appropriate CloudFront edge server based on load and geographic location. The CloudFront edge server either serves the requested content from its local cache or it pulls it from the Streaming Engine origin and caches it. Content is cached on CloudFront edge servers as defined by Cache-Control headers that are configured as part of the Wowza Streaming Engine application configuration. All path elements are passed from the CloudFront edge server to the Wowza Streaming Engine origin server.

When using the Apple HLS, Adobe HDS, and Microsoft Smooth Streaming HTTP streaming protocols with CloudFront delivery, the general URL syntax is:
  • Apple HLS - http://[cloudfront-domain-name]/[application]/[appInstance]/[streamName]/playlist.m3u8
  • Adobe HDS - http://[cloudfront-domain-name]/[application]/[appInstance]/[streamName]/manifest.f4m
  • Smooth Streaming - http://[cloudfront-domain-name]/[application]/[appInstance]/[streamName]/Manifest
  • MPEG-DASH - http://[cloudfront-domain-name]/[application]/[appInstance]/[streamName]/manifest.mpd
  • [cloudfront-domain-name] is the CloudFront Domain Name value, which is available to you after you create your CloudFront distribution. You can substitute the Streaming Engine origin domain name value to stream directly from the origin for testing purposes. For more information, see the "Playback" section in Troubleshoot your Wowza Streaming Engine CloudFront configuration.
  • [application] is the application name, livehttporigin or vodhttporigin.
  • [appInstance] is only needed if the [streamName] contains path elements. In most cases, the default appInstance (_definst_) is automatically used when needed.
  • [streamName] is the relative path to the VOD asset or the live stream name.

Streaming live streams

After you've configured a Wowza Streaming Engine livehttporigin application, any live stream that's published to it is available for CloudFront delivery. The stream is available through CloudFront via the following URLs:
  • Apple HLS - http://[cloudfront-domain-name]/livehttporigin/[streamName]/playlist.m3u8
  • Adobe HDS - http://[cloudfront-domain-name]/livehttporigin/[streamName]/manifest.f4m
  • Smooth Streaming - http://[cloudfront-domain-name]/livehttporigin/[streamName]/Manifest
  • MPEG-DASH - http://[cloudfront-domain-name]/livehttporigin/[streamName]/manifest.mpd

Streaming video-on-demand content

Any vodhttporigin application can stream video-on-demand through CloudFront from the default Wowza Streaming Engine content store ([install-dir/content or /usr/local/WowzaStreamingEngine/content). The default Wowza Streaming Engine installation includes a sample file named sample.mp4. You can stream the sample.mp4 file through CloudFront via the following URLs:
  • Apple HLS - http://[cloudfront-domain-name]/vodhttporigin/sample.mp4/playlist.m3u8
  • Adobe HDS - http://[cloudfront-domain-name]/vodhttporigin/sample.mp4/manifest.f4m
  • Smooth Streaming - http://[cloudfront-domain-name]/vodhttporigin/sample.mp4/Manifest
  • MPEG-DASH - http://[cloudfront-domain-name]/vodhttporigin/sample.mp4/manifest.mpd

Streaming content stored on Amazon S3 (vods3)

The default vods3 is not configured as an HTTP caching origin for VOD streaming through CloudFront from the Amazon Simple Storage Service (Amazon S3) content store. To use the vods3 application as an HTTP caching origin with CloudFront, you have to set the httpOriginMode property to on in [install-dir]/conf/vods3/Application.xml. You also have to configure cache-control properties for each HTTP playback type (HTTPStreamer) that you want to use. For more information, see the Property reference section in "Configure Wowza Streaming Engine as an HTTP caching origin."

When using the vods3 application, the [streamName] part of the URL targets Amazon S3 content and has the following structure:


For example, to play the sample.mp4 file that's stored in the Amazon S3 bucket wowzamediasamples at the path videos/, the stream URLs are:

  • Apple HLS - http://[cloudfront-domain-name]/vods3/_definst_/mp4:amazons3/wowzamediasamples/videos/sample.mp4/playlist.m3u8
  • Adobe HDS - http://[cloudfront-domain-name]/vods3/_definst_/mp4:amazons3/wowzamediasamples/videos/sample.mp4/manifest.f4m
  • Smooth Streaming - http://[cloudfront-domain-name]/vods3/_definst_/mp4:amazons3/wowzamediasamples/videos/sample.mp4/Manifest
  • MPEG-DASH - http://[cloudfront-domain-name]/vods3/_definst_/mp4:amazons3/wowzamediasamples/videos/sample.mp4/manifest.mpd
Note: The above file, mp4:amazons3/wowzamediasamples/videos/sample.mp4, is publicly available on Amazon S3 for testing purposes. The full URL to the content is:
It's also possible to re-stream protected Amazon S3 content. To do this, do the following:
  1. Connect to your Wowza Streaming Engine origin by using an SSH client.
  2. Stop the Wowza Streaming Engine service by executing the command:
    sudo service WowzaStreamingEngine stop
  3. Open the /usr/local/WowzaStreamingEngine/conf/MediaCache.xml file in a text editor, and then make the following changes:
    1. Uncomment the awsAccessKeyId and awsSecretAccessKey properties.
    2. Set the above properties to use the credentials for the Amazon S3 bucket that you want to re-stream from.
  4. Start the Streaming Engine service by executing the command:
    sudo service WowzaStreamingEngine start

Controlling how long CloudFront caches errors

By default, when your origin returns an HTTP 4xx or 5xx status code, CloudFront caches the error response for five minutes and then submits the next request for the object to your origin to see if the problem that caused the error is resolved and the requested object is available. This means that if a streams stops and then restarts, it will take CloudFront five minutes to recover. You can change the Error Caching Minimum TTL setting for your CloudFront distribution. This setting specifies the error caching duration for each 4xx and 5xx status code that CloudFront caches. We recommend that you change this setting to 1 second to match the manifest caching duration. For information on how to change this setting, see the Amazon article Configuring Error Response Behavior.

Deleting the CloudFront distribution

See the Amazon article Deleting a Distribution.

More resources