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.

One part of their servers on demand product had issues – specifically their Elastic Block Storage product in one of their availability zones. Many servers use it for persistent storage, something the EC2 product doesn’t offer by default. With these volumes being flaky, throwing errors or being office, many sites were in trouble.

The services that we use the most here at John Carroll, the Simple Storage Service (S3) and the Cloudfront content delivery network were not affected, thankfully, so I could enjoy the holiday weekend. I would have liked to play some online games on my PS3, but as you’ll see below, that too was off-line.

So what are some takeaways I see coming out of this outage?

First, don’t put all your eggs in one basket. SmugMug CEO Don MacAskill posted a very detailed blog post about the Amazon outage and how and why his company’s servers there weren’t affected. He says:

All of our services in AWS are spread across multiple Availability Zones (AZs). We’d use 4 if we could, but one of our AZs is capacity constrained, so we’re mostly spread across three. (I say “one of our” because your “us-east-1b” is likely different from my “us-east-1b” – every customer is assigned to different AZs and the names don’t match up). When one AZ has a hiccup, we simple use the other AZs. Often this is a graceful, but there can be hiccups – there are certainly tradeoffs.

Second, if you are going to leverage the cloud for services, and you should, you must have a backup plan or set of protocols for what to do if it hits the fan.

For example, if S3 did go down, our WordPress CMS would be affected, as we store user-uploaded assets in S3. To remedy that, we keep a local copy on our server, so our assets stay available to our site visitors. If S3 goes down, we can make a change to a plugin configuration and our assets will still be available. When S3 comes back online, we’d flip the switch and go back to serving things from the cloud.

Third, have a communication plan ready and keep users updated during the day.

The only spot I was finding out official information on the outage was on the AWS Service Health Dashboard, which is fine, that’s where it should be. In addition, many sites put up their own pages (Quora, Reddit come to mind) saying their were being affected by the outage.

If you have a blog, use it. Same goes for Twitter and Facebook. Amazon, even though the info was hidden, was good with updating exactly what was going on and where they were in the process of getting services back online. For example:

Apr 24, 5:05 AM PDT: As detailed in previous updates, the vast majority of affected EBS volumes have been restored by this point, and we are working through a more time-consuming recovery process for remaining volumes. We have made steady progress on this front over the past few hours. If your volume is among those recently recovered, it should be accessible and usable without additional action.

Good information that’s being updated often is important to help keep customers in the loop. Compare that to Sony, who’s Playstation network has been offline since last Wednesday. Their updates have been nebulous, at best. On April 21, they posted on their official blog:

While we are investigating the cause of the Network outage, we wanted to alert you that it may be a full day or two before we’re able to get the service completely back up and running.

The last update given by the company, on April 23, said this:

We sincerely regret that PlayStation Network and Qriocity services have been suspended, and we are working around the clock to bring them both back online. Our efforts to resolve this matter involve re-building our system to further strengthen our network infrastructure. Though this task is time-consuming, we decided it was worth the time necessary to provide the system with additional security.

We thank you for your patience to date and ask for a little more while we move towards completion of this project. We will continue to give you updates as they become available.

And then, silence. It’s now Monday morning in the US and the service is not online and the current status/ETA for being online hasn’t been updated since Saturday. IGN has more on Sony’s PR response to this outage.

That type of communication wouldn’t work on our campuses. Part of your planning must be a communications plan for who is responsible for keeping a certain audience up to date on the status of services.

My colleagues at Allegheny are doing it right this morning. They had a power outage over the weekend and took to their intranet to update the campus community, on a Sunday.

Am I going to stop using Amazon’s cloud services over this outage? No, definitely not. Is this going to make Amazon improve the service? Yes. Is this a sucky way to do it? Of course.

I’ll be updating this post with feedback from other higher ed web and marketing folks. Andrew Careaga has some interesting thoughts on the outage looking at it through a lens of education.

Where there was previously no good way for people to do forms, registrations and feedback online (except for, ugh, SurveyMonkey), they now create all sorts of forms for our on and off campus audiences and process payments through it as well. It has saved me a ton of work over the last year, and for that I’m grateful. In fact, just last month we used it to do all the fundraising for our campus community radio station. It worked like a charm.

Two things that are cool about Wufoo are that forms you create there are hosted securely and that you can create your own themes and CSS to style your forms to match the look and feel of your institution. One of the ways to do this is to add in your logo to appear at the top of your forms. Ours looks like this:

I’m hosting that image in our account over at Amazon S3. In Wufoo’s theme creator, I listed the image as:

http://webmedia.jcu.edu/images/JCU_logo4.gif

That CNAME points to our S3 bucket. The image worked fine and looked great on our theme.

The only problem with doing it that way is that it makes the form unsecure. Chrome showed me this:

After doing a bit of research, I was glad to see that you can, in fact, serve secure files from Amazon S3. The catch is that you cannot use a CNAME to access your files – you have to use Amazon’s domain name. Instead of using the URL above, to get secure files from S3, you have to structure your URL as so:

https://s3.amazonaws.com/webmedia.jcu.edu/images/JCU_logo4.gif

See, that was easy. Now my images and other files coming from S3 can be secure, if needed. Since the change, the form has been showing as completely secure.

I also host some small websites there. Technically, you could always host static HTML web pages at Amazon, but you were pretty limited in your options. The pages had to be static HTML (no PHP, ASP, etc) and could only be accessed with the direct full URL. For example:

http://web.highedwebtech.com/pages/index.html

If you tried to enter just:

http://web.highedwebtech.com/pages

The user would get an error message that isn’t very user friendly:

A few months ago, Amazon added a feature for hosting sites that would let users see a list of files in a directory, but if something went wrong, you’d still get that nasty error message.

Just this week, Amazon has released the ability for you to define both an index file for your S3 hosted site as well as an error document.

It looks like this:

That makes it much easier to fully host a site at S3. Why would you want to host your site at S3?

For one, you can leverage Amazon’s cheap bandwidth and built-in scalability. If you’re launching a project on your campus, or doing a large scale outreach project for prospective students or alumni, there can often be a large spike of users, especially if there’s a big marketing push. By having the site living at Amazon, you wouldn’t have to worry about Amazon being able to handle the load.

The downside of this type of service is that it just accepts static HTML files. If I upload a PHP document (index.php for example) it just downloads the file, it doesn’t display in the browser. That means if you’re using any type of CMS, you can’t host your site in S3, you’d have to build a server in EC2.

But, it sure would be nice if you could export static files, such as what WP-Super-Cache creates out of a system like WordPress and serve them from S3. That’d be super fast, for reals.

It’s made the job on syncing files across my desktop machines, laptop, iPhone and iPad drop-dead simple. Thanks to sharing a few links with people and doing the recent Dropbox scavenger hunt, I’ve got 4.75GB worth of storage.

I love too that you can share files with other Dropbox users. This has proven to be very valuable, especially in the office (and our senseless 100MB email quota.)

With a new web developer starting to work for me today and a second person working with us from the UK, I immediately thought of Dropbox as a way for us all to collaborate and share files easily and quickly.

Armed with that knowledge, I set up an account for my office (separate from my personal account) and paid $10 for 50GB of storage. It’s probably a bit more than we needed, but better to be safe than sorry.

Once the account was created, I set up a “JCU WEB” folder on my work account, and shared it with my personal Dropbox account. Thinking I had access to that 50GB of space, I put up about 5GB of files, archives and other stuff the team would need.

It turns out that Dropbox counts all that storage against my personal account space, not the 50GB quota of the paid account. There’s not a way that my team can use that 50GB that we’re paying for.

Lame, dudes.

In reading through the Dropbox forums, many users share this frustration. Dropbox has answer, but for many small teams, may be overkill.

They’ve released a product called Dropbox Teams, which for $795 a year, gives 5 users a shared 350GB of file space. They say:

Storage quotas are shared by the team rather than bound to individual accounts. Now you and your team can share one large pool of storage instead of having to manage the storage limitations of individual accounts. Shared folders only take up your team’s storage quota rather than space in each individual account.

That’s exactly what we need, but we don’t need 350GB. We need just the 50GB, or even let us connect to our own Amazon S3 account (that’s where Dropbox keeps everything anyway.)

I think if Dropbox could solve this problem – they’d find a lot of users willing to pay $10-20 a month for a shared pool of storage. I definitely would.

For us, it’s back to the drawing board on how to share project files. Amazon S3? Basecamp?

For the majority of work I do in S3, I use Panic’s excellent FTP-and-then-some client, Transmit. It treats S3′s buckets and objects model more as regular FTP, where you can create folders and drag and drop folders. S3Fox is a Firefox plugin that makes managing your S3 folders a snap and it’s cross-platform. On the Windows side, I’m a fan of Cloudberry S3 Explorer, a free app. I reviewed Cloudberry Explorer last year, you can read it here.

While those clients are nice, you may find yourself in a situation when you need to access S3 and don’t have the tools I mentioned above. Such a sitation happened to me last week. I stopped by the Cleveland Clinic to talk with John Sharp‘s bioinformatics group. Talk about an intimidating group – these were some seriously smart programmers, doctors and database professionals. They were all very nice, to be sure, but, wow. After all, the Cleveland Clinic was recently voted one of the top 4 hospitals in the country.

As I was prepping to talk with that group about the cloud and some of the neat services out there, I wanted to post a few graphs and wanted to add them to my S3 account so they could grab them after the talk. Since I was on the public Cleveland Clinic wireless, I was pretty much limited to web-based services. I didn’t have S3Fox installed on my Macbook, so I logged into Amazon’s new S3 Management Console.

Much like you can manage your servers in Amazon’s console, they’ve added S3 as a service you can manage from the web, making uploading, deleting and sharing files very easy. Since it all happens in the browser, you can access the service from any web connection and quickly do the work you need to do. I posted the photos and an updated version of my Powerpoint presentation (based on the one I gave at EduComm) in S3 and the rest, as they say, was history.

Here are some screenshots from Amazon’s S3 Console.

On their blog, they described VaultPress this way:

The vision of VaultPress is to ensure that blogs and sites under its care are always completely secure, regardless of what happens. Today, this means every bit of content will be safe, from plugins and themes to the smallest comment or post revision, with WordPress-aware, real-time, multi-cloud backups. This is some of the most advanced technology I’ve seen interact with WordPress.

TechCrunch estimates that it will cost $15-25 per month to backup your tables and assets with VaultPress. They’re just opening up the private beta of this service, so expect to hear more from users over the next couple of months. You can sign up for the beta here.

At quick glance, it’s good that WordPress is making it easier to backup installations and I hope the system is easy to setup and maintain. That’s been one of WP’s biggest strengths – it’s ease of use and hopefully that will continue on with VaultPress.

If you don’t want to use VaultPress, there are other ways to backup your WordPress data and assets. Here are a few ideas you can start using today. I use all of them, because I’m paranoid about losing content. This is a good trait to have, especially if you’re using WordPress as a CMS.

WP-DB-Backup

Themes can be re-installed or restored from a backup, but the key piece of data you can’t lose when it comes to WordPress is the MySQL database that runs the whole show. The WP DB Backup plugin will backup your database on a schedule (hourly, daily, weekly, monthly) and the backup file (a gzipped file) can be saved to the server in a location you determine, downloaded on demand or emailed to you. You can specify which tables in the database you want included, which is nice.

I prefer emailing a backup to Gmail (where size isn’t a problem) and archive a few there just in case. The email looks like this and can be easily filtered and labeled.

Automatic WordPress Backup

The Automatic WordPress Backup will grab your entire WP directory, assets, themes and your database and put it in one file and automatically upload that file to your Amazon S3 account. Like the DB plugin, you can specify how often you want your files backed up and what to include (configs, database, themes, plugins and user uploaded content.) This is a nice “set it and forget it” type backup plan. I know that the backups run weekly and go to S3, where I don’t have to worry about it until I need it.

What I like about this is that it will present you, inside the plugin, a quick download link to your backup files. This saves you the step of getting into S3 to grab the file you need.

This is a very cost efficient model, since storage at S3 costs $0.10USD for each gigabyte you store, and WP backups are usually under 5MB, so you’re paying maybe a few cents a month for piece of mind. Well worth it, I think.

The plugin config screen:

What it looks like in S3:

Backup to S3 from the Command Line

This one is not for the faint of heart, or those not comfortable with working in a Linux/Unix command line environment. This script by Eric Nagel grabs your databases (not just WordPress, any of them you want), your web directories and whatever else you want, zips them up (separately) and sends them to S3. You can specify how many previous days of backups you want to keep and the script will delete backups older than x number of days (I usually set this to 5.) If you need to backup files larger than 2GB (a PHP limitation), check out this blog post.

I like this method because once set up and set to run via Cron, you can very easily do nightly backups of your entire web root as well as your databases. While your IT department or hosting company is doing full and incremental backups, getting, say, one database table or file is a pain for you (as well as the IT staff). This method makes that much easier.

This type of backup is absolutely critical in case the entire machine catches fire. This S3 method just backs up the web area, making your life a tad bit easier when it comes time to recover something. Since you can specify more directories and datbases than just WordPress, this method may end up costing you a bit more, but that security is well worth the small cost from Amazon.

Repeat after me: it’s always good to have more than one backup of your data. Always.

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.

We can use third-party apps, browser plugins or even write your own. I haven’t had time to do that, and probably never well, so I rely on third-party applications to make my life easier.

Since I spend the majority of my day on a Mac, I use a combination of S3Fox and Transmit.

When I’m on my netbook, I use S3Fox but on both Mac and PC S3Fox struggles for me at times. I’ve spent some time lately trying out Cloudberry’s S3 Explorer product and so far, so good. It makes managing an S3 installation of any size very manageable.

It looks and behaves very much like FTP, which I think is beneficial for users who are used to working with files that way and may be confused by Amazon’s bucket and file terminology.

I was able to set up my credentials very quickly and within moments was looking at my S3 account.

I was able to browse through my buckets quickly and upload files easily.

One area that I found really shined with Cloudberry Explorer was the ability to easily update and change the ACL, or permissions, of files much easier than I have in S3Fox. S3Fox is very hit and miss and I feel like I have to click on permission boxes over and over until it finally takes. Explorer is much easier to navigate through this.

If you are primarily a PC user working with Amazon S3, I highly recommend you check out Cloudberry S3 Explorer. The best part – did I mention its a free product? Go and download it now and try it out. I think you’ll find it will quickly become a go-to tool for working in S3.

We’ve been using the Cloudfront CDN more and more and Cloudberry Explorer supports it, which is great for a free product.

That’s not the only product they offer. They have a pro level version of the product. It lets you have a number of accounts set up in there and better support options, among other features. The cost of the pro version is just $39.99, but I’ve asked Cloudberry if they’ll let me give away 1 free pro license to a reader of this blog.

All you have to do is enter your name and email in this entry form. We won’t spam or sell your email information. I will pick a winner and give your name and email to Cloudberry so they can send you a license.

Enter our giveaway today. I will draw the winner on November 13.

That red line up there, that’s us pretty much saturating a 100MB connection for the better part of a day. My first thought was “man, that’s going to be expensive.”

Our college is partnering with the Story of Stuff project to host some web video – they serve a large number of videos to people and schools around the world. We merely host the flash video files on a dedicated box with its own bandwidth connection.

But Mike, you say, why aren’t you doing this in Amazon S3. Good question – that was my first thought when we were first approached about this project. With S3, we wouldn’t have to worry about pipes and bursting and all that, we just pay for the traffic but the cost estimates were too expensive for the budget we had for this project. It’s definitely still on the radar.

Sometimes yesterday, radio and TV host Glenn Beck talked about the project on his website here as well as his TV and radio show, and traffic went through the roof. That evening, Lou Dobbs at CNN also talked about it. Those two sent a ton of people over to the project to watch the videos (that we serve.) The system held up pretty well, and apart from some sluggishness late last evening, it’s been pretty good.

So, I’ve spent a large part of today ordering more bandwidth for that server and looking at some Apache modules to help shape the bandwidth. I’ve become pretty handy with mod_bw today. We hadn’t thought a ton about how to handle giant spikes, so the new things I’m trying out today will help us find a good, stable platform to ensure everyone gets to see the content quickly and for us, not too expensively.

If you have any tips or suggestions, let me know.