Time to Live (TTL) of objects on Amazon Cloudfront

Time to live (TTL) is mechanism that limits the lifespan of data in a computer or network. In HTTP, TTL is expressed in the response header as a date and time on which a record expires.

On Amazon Cloudfront, the default TTL is 24 hours. In April 2010, Amazon Cloudfront announced that it will honor shorter TTL’s down to one hour. The HTTP header can be set in the Amazon AWS Management Console.

To refresh a specific file on Amazon Cloudfront, you can use the Invalidation API. The Bucket Explorer has a UI that makes Invalidation pretty easy. Informations about an Amazon CloudFront – PHP Invalidator are availble at the subchild website.

RTMP streaming for Amazon CloudFront

RTMP (Real Time Messaging Protocol) is a web transmission standard which allows a backend server to transfer video, audio and data to the Flash Player. It’s particularly useful for video streaming, since the Flash Player can communicate back to the server about how much video it has consumed, and how much more video the server needs to send. This is a distinct advantage over so-called progressive download video, where a web server simply begins sending bytes out to the video player over standard HTTP until there are no more bytes to send.

In addition to saving bandwidth and allowing better seeking control, RTMP is harder to steal content, allows dynamic bitrate switching and is able to stream live content.

Amazon added RTMP to the CloudFront servers in December 2009 and thus became a real CDN (Content Delivery Network), offering content providers a simple and reliable way to host, format and deliver their video content at high speeds.

CloudFront Streaming is very easy to set up with the JW Player 5.3.

Today a created the first video-distributions on Amazon CloudFront by using the AWS-Console. This process is very straightforward.

The following parameters are used to embed a streaming-videofile in a webpage using a flash-player or the HTML5 <video> tag.

  • videofile = path/filename.ext
  • streamer = rtmp://xxxxxxxxxxxxx.cloudfront.net/cfx/st/
  • provider = rtmp

The suffixes /cfx/st/ at the end of the URL are required to access the streaming-server at the CloudFront server. Videofile extensions can be mp4, flv and webm.

Progressive video download, pseudo streaming and realtime streaming

Last update : January 30, 2013
In the past, audio and video on the Web was primarily a download-and-play technology. You had to first download an entire media file before it could play. Today, streaming technologies allow watching audio and video files almost immediately, while the data is being sent, without having to wait for the whole file to download.

There are three methods of delivering streaming audio and video content over the Web.

The first method uses a standard HTTP server to deliver the audio and video data to a media player. Unlike the download-and-play client, a special streaming client embedded in the webpage starts playing the audio or video while it is downloading, after only a few seconds wait for buffering, the process of collecting the first part of a media file before playing. This streaming method is called progressive media download.

The second method is called pseudostreaming. Pseudostreaming is a protocol that can be installed on regular HTTP servers. It uses a server side script for Flash-to-server communication. The player sends a HTTP request to the server with a start time parameter in the request URL’s query string and the server script responds with the video stream so that its start position corresponds to the requested parameter. This start time parameter is usually named simply start. The video viewer skips the nondownloaded parts of the videos.

Both FLV and MP4 video can be played back with  pseudostreaming. The following scripts or tools are available :

  • The H264 streaming module for Apache, Lighttpd, IIS and NginX.
  • The mod_flv_streaming module for Lighttpd.
  • PHP/ASP scripts such as XmooV PHP.
  • Content delivery networks such as Bitgravity, Edgecast or Limelight.

There is one major advantage to streaming with a Web server rather than with a streaming media server—utilizing existing infrastructure.

The third method uses a separate streaming media server specialized to the audio/video streaming task. A streaming server offers the following advantages :

  • More efficient use of the network bandwidth
  • Better audio and video quality to the user
  • Advanced features like detailed reporting and multi-stream multimedia content
  • Supports large number of users
  • Multiple delivery options
  • Content copyright protection

The following protocols are commonly used by streaming servers :

  • UDP – this protocol provides the most efficient network throughput. The only downside to UDP is that many network administrators close their firewalls to UDP traffic, limiting the potential audience of UDP-based streams
  • TCP – this protocol provides an adequate, though not necessarily efficient, protocol for delivering streaming media content to flow through the firewalls
  • HTTP + TCP – this combination has the benefit of working with all firewalls that let Web traffic through (port 80) and provides much more control (fast forward, rewind, etc) than a standard Web server, but also adds some overhead to the raw TCP stream that decreases scalability.
  • Multicast – this protocol enables hundreds or thousands of users to play a single stream, but will only work on networks with Multicast-enabled routers. Multicast is becoming prevalent on corporate networks, but is still very rare on the Internet

Useful informations and tutorials about streaming are available at the streamingmedia.com website.

In 2009, Amazon CloudFront, the easy-to-use content delivery service, introduced the ability to stream audio and video files. Streaming with Amazon CloudFront is exceptionally easy: with only a few clicks on the AWS Management Console or a simple API call, you’ll be able to stream your content using a world-wide network of edge locations running Adobe’s Flash® Media Server. Like all AWS services, Amazon CloudFront streaming requires no up-front commitments or long-term contracts. There are no additional charges for streaming with Amazon CloudFront; you simply pay normal rates for the data that you transfer using the service.

Amazon CloudFront

update : October 18th, 2011
Amazon CloudFront is a web service for content delivery. It integrates with other Amazon Web Services (mainly Amazon S3) to give developers and businesses an easy way to distribute content to end users with low latency, high data transfer speeds, and no commitments.

Amazon CloudFront delivers the content using a global network of edge locations. Requests for  objects are automatically routed to the nearest edge location, so content is delivered with the best possible performance. Amazon CloudFront works seamlessly with Amazon Simple Storage Service (Amazon S3) which durably stores the original, definitive versions of the files.

In Amazon CloudFront, objects are organized into distributions. A distribution specifies the location of the original version of the objects. A distribution has a unique CloudFront.net domain name  that  can be used to reference an objects through the network of edge locations. It’s also possible to map an own domain name to a distribution.

Amazon CloudFront is

  • fast
  • simple
  • cost-effective
  • elastic
  • reliable
  • global
  • designed for use with other Amazon Web Services

The price depends on the edge location and the volume transferred. The mean price per GB for low volumes is about 0,2$, for high volumes about 0,1$. A simple monthly AWS bill calculator is provided by Amazon. Normal fees will apply for Amazon S3 usage, including “origin fetches” – data transferred from Amazon S3 to edge locations.

The edge locations in Europe are:

  • Amsterdam
  • Dublin
  • Frankfurt
  • London

Amazon CloudFront is designed for delivery of objects that are frequently accessed – “popular” objects. Objects that aren’t accessed frequently are less likely to remain in CloudFront’s edge locations’ caches. Thus, for less popular objects, delivery out of Amazon S3 (rather than from CloudFront) is the better choice. Amazon S3 will provide strong distribution performance for these objects, and serving them directly from Amazon S3 saves the cost of continually copying less popular objects from Amazon S3 to the edge locations in CloudFront.

I activated my Cloudfront account on November 1st, 2010.

A recent tutorial how to install Amazon CloudFront has been posted by Michael Tieso on the website “Art of Travel Blogging”.