Petabytes.

Crazy.

Anyways, starting July 1, new pricing for bandwidth goes into effect:

New data transfer price for US-Standard, US-West and Europe regions (effective July 1, 2011)

• $0.000 – first 1 GB / month data transfer out

• $0.120 per GB – up to 10 TB / month data transfer out (10 TB total)
• $0.090 per GB – next 40 TB / month data transfer out (50TB total)
• $0.070 per GB – next 100 TB / month data transfer out (150 TB total)
• $0.050 per GB – next 350 TB / month data transfer out (500 TB total)
• Contact us – next 524 TB / month data transfer out (1PB total)
• Contact us – next 4 PB / month data transfer out (5PB total)
• Contact us – data transfer out / month over 5 PB

According to Amazon, if you were moving 10TB in and 10TB out a month, your bill just went down 50%. Not bad.

CloudFront prices are also going down. For more specifics, visit the AWS Data Transfer Pricing Update detail page.

There are free services, such as uStream and Justin.tv, but the quality they offer can be erratic and, if you are using one of the free tiers of service, your content will have pre-roll and/or pop-up ads. This is annoying.

In a perfect world, we’d all have our own Flash media streaming setups we could push a button and start using. I don’t know about you, but I don’t have the time to manage all that stuff.

Enter Amazon, naturally.

They’ve announced today a new service and framework to get up and running doing live Flash media streaming. They’ve combined several of their services, including DNS, servers on demand and their content delivery network to offer an interesting on-demand Flash streaming rig.

The actual setup looks like this, but don’t be scared by all the pieces.

With their CloudFormation service, much of the work of setup only needs to be done once. Instances can be created from that template as needed.

Let’s look at costs for this type of setup. According to Amazon, they say this about costs:

In addition to the $5.00 monthly subscription fee for Flash Media Server on Amazon EC2, you pay for only for the AWS resources you consume.

Let’s examine those costs for a moment. After the $5 monthly charge, you’ll pay $0.44 USD for a server in Virginia that can support 100 simultaneous connections. Prices go up from there. Streaming to 1,000 users would run you $1.30 USD per hour. Prices are higher in Asia and Japan.

The big unknown here is bandwidth usage. I’m having a hard time trying to estimate the amount of bandwidth needed for an event, such as graduation. 20GB? 50GB? 100GB? If you have a number you’ve seen in the past, let me know so I can correct the numbers.

Let’s use 100 as our basis here – that bandwidth would cost you $15.00 USD.

So let’s say you are streaming two hours of Commencement. That would be:

• Flash: $5
• 1000 streams at $1.30 per hour: $2.50
• 100GB of Bandwidth: $15.00

Under $25 for a platform you have full control over? That’s not too shabby.

Let’s compare that to some other services out there:

uStream offers ad-free streams, and you can get 100 hours for $99 per month. 4,000 ad-free hours per month will run you $500 a month. LiveStream.com offers 3,000 ad-free hours and HD quality for $350 per month.

Looks like an interesting offering from Amazon. As we start to plan our graduation streaming, it will definitely be in the mix. If you’d like to read a tutorial from Amazon on live Flash streaming, you can check it out here.

New prices for everything but CloudFront look like this now:

While it doesn’t sound like a lot, if you are serving out a ton of files from S3, you should see some pretty decent savings. Let’s say you serve out 250GB in a month. Your bill just for outgoing bandwidth would drop from $42.50 to $37.50. Not bad, and the more you serve the more you would save.

You can learn more about the new pricing and more specific CloudFront details over the Amazon Web Services blog.

Matt Cutts, a software engineer and an eloquent corporate spokesman for Google, spoke at PubCon earlier this month and later gave a video interview to Web Pro News, in which he said that the speed at which web pages are available might become a factor in SEO moving into 2010.

While Google hasn’t officially said this is going to happen, having as fast a website as possible is a very good thing, for your users and for you.

So, let’s look at a few ways you can improve the speed of your site.

1. Compression

Most, if not all, of the major web servers available today offer some sort of compression. What that means is they serve out the content to your browser in a certain way, much like a ZIP file, that your browser can read and deflate very quickly. Smaller files sent = faster site.

Now, how you set up compression differs by what web server you are using and what platform your server is.

In PHP, it can be as easy as adding one line of code to your site. Like this:


<?php
ob_start("ob_gzhandler");
?>


If you’re using Apache and only serving out HTML, you should look into the mod_gzip apache plugin. It compresses text files on the fly. Here are some instructions for IIS, though there are also commercial plug-ins you can buy to achieve the same result.

Sometimes you may not have access to the actual server or root access to install some of these services. No worries – some CMS and blogging systems offer plug-ins to achieve some of these things.

I’m a WordPress nut, so on all of the installs I run, one of the first things I always install is WP Super Cache, created by Donncha O Caoimh. This plugin will cache pages of your site for super fast loading, it will compress HTML, if enabled. This plugin also works in MU, and I’ll blogging that later.

Not sure its worth it? Check for yourself. There are many sites on the web that test your site and see if you are compressing data. Here’s one that quick and easy to use. For this site, by using compression I’m saving almost 75% in terms of the amount of data sent. Faster sends = faster site loads for users.

2. Cut Down On Stuff

Compression is great, but if you site is pulling in a million assets, widgets from third-party sites, and three or four Javascript libraries, it won’t make any difference. If you can, cut down on the number of calls, minify your javascript libraries and determine something like that Facebook fan box is absolutely critical to a page.

I think we’re all a bit guilty in the broadband era of not worrying about how much our page weights are. It’s worth looking at, especially as more and more web surfing is done on mobile devices.

Want to see how much stuff your code is calling for? Check out Firebug for Firefox or use Safari’s built-in Web Inspector. You may be surprised what you see.

3. CDN

Serving some of your static content (images, CSS, js) from a content delivery network will increase the speed of your site. These assets don’t change very often, so why not let a very fast network serve them out.

There are a ton of options out there, from very expensive to not so expensive, but the two I’d recommend are Amazon S3/Cloudfront and Rackspace’s Cloud Files.

Those two are inexpensive, easy to use and very fast. The few bucks a month you’ll pay are well worth it.

4. Semantically Strong Code

Last but not least, if you write clean, good code, your site will load very faster.

If your code is a mess, or god forbid, you’re still using a layout method like tables, your site is going to take longer to come down the pipe and also render out for the user.

Are there easy things I’m missing? Leave a comment and let me know.

Last year, they announced their Cloudfront product, which is a content delivery network that sits on top of S3. S3 is pretty fast, but Cloudfront, for extra cost, is even faster, especially internationally. I blogged about CloudFront here last year, and have used it for several projects at my institution.

The challenge was getting up and running with Cloudfront. There just wasn’t an easy way, other then API calls or a browser add-on like S3Fox, to designate content that one wanted served from Cloudfront.

As of yesterday, Amazon has added Cloudfront tools to their great management console. Now, you can easily create new Cloudfront distributions and manage them from one central location. It’s a great addition, and one I think will help increase the usage of this nice product.

You can read more about this on Amazon’s Web Services Blog.

Today, they launched their CloudFront delivery network. It’s a full blown content delivery network that will serve your content from across the country (and world). Similar to their other offerings, you only pay for what you use.

This is interesting because it makes content delivery now a commodity instead of an expensive proposition. We all want to get our content, especially videos, to our customers (see: perspective students) as quickly as possible. For some smaller schools, we don’t have the budget to sign up with one of the large content delivery networks.

Here’s a bit from the CloudFront website:

Amazon CloudFront has a simple, web services interface that lets you get started in minutes. In Amazon CloudFront, your objects are organized into distributions. A distribution specifies the location of the original version of your objects. A distribution has a unique CloudFront.net domain name (e.g. abc123.cloudfront.net) that you can use to reference your objects through the network of edge locations. If you wish, you can also map your own domain name (e.g. images.example.com) to your distribution.

Using a network of edge locations around the world, Amazon CloudFront caches copies of your content close to end users, lowering latency when they download your objects. The service also gives you the high, sustained data transfer rates needed to deliver large popular objects to end users at scale.

Prices are pretty similar to S3, with US and EU locations costing $0.17 per GB transfer for the first 10TB. Hong Kong and Japan servers have slightly higher prices.

You can learn more about CloudFront at the AWS blog. Amazon CTO Werner Vogels has more here, as does RightScale.

I’m going to try it out and I’ll report back.