(Note: this is written by me not acting as an Amazon engineer, but someone trying to be helpful. Don’t confuse what I say with anything official coming out of Amazon! I’m not directly involved with Amazon AWS here at Amazon even though by some quirk Appstore reports up in the same org as AWS. Like I said, I’m not talking as Amazon, just George.)
Yesterday I wrote about WordPress hosting options, today we start to dive into the options and pricing you get from Amazon EC2.
One of the downsides of AWS and EC2 is a sometimes confusing pricing model. The model works great for companies that are deploying their enterprises on it, but for the individual there’s a lot to digest about how it all works and how it affects your bill.
All of this is documented on the EC2 pricing page, although it’s quite wordy and has lots of detail that you’re likely not interested in. (Most civilians aren’t interested in getting anything beyond a small or maybe a medium unless you have some real compute heavy work — that’s not what WordPress is! If you need help with those, ask me and I’ll see if I can get you in contact with an EC2 engineer here at Amazon)
Reservation of instances
There are five types of reservation (or lack of) at EC2. I’ll cover four of them and gloss over the last one. Spot instances are unlikely to be of use to hosting a WordPress blog.
The simplest type of instance is an on-demand instance. There is no up-front cost and you simply pay for what you use. If you want to spin up additional instances, no problem. Once you turn them off you’re off the hook for the cost of the server. This is a good way to try out the service (more on trying out soon) without a long-term commitment.
From here we get to reserved instances. These are divided into light-, medium-, and heavy- utilization reservation. The advantage of a reserved instance is that in exchange for an up-front cost, you get a lower per-hour cost. Another benefit that isn’t as important from a blog hosting scenario is that the server is guaranteed to be there for you to spin up.
While EC2 and “the cloud” can seem like an infinite spigot of compute resources, there’s still hardware that has to be purchased on the backend; the physical manifestation of the cloud is a building full of servers. If you want to spin up a few servers, no problem. If you want to spin up a thousand, you might want to call up Amazon first. When you have a reserved instance, you know that there will be a server there for you.
One gotcha with the heavy-utilization reservation is that it’s no longer really an hourly model. With the heavy instance you’re on the hook for 24 hours a day every day. Even if the server isn’t on you’re still billed for it. Essentially you’re paying for a full server to exist just for you — it’s still your server even if you’re not using it!
I’m only going to gloss over spot instances. This is a way for Amazon to monetize unused capacity. You, as an EC2 user, can bid on capacity. If you’re the highest bid you get the resources — until someone who’s willing to pay more comes along. This is a good thing to use if you want to do some low-priority batch processing. This is particularly bad for a publicly available site like your blog!
You want to take a look at the specs for the instances to make sure it is suitable for your load. For a normal WordPress blog you’d be hard pressed to need anything more than an m1.small. I’m going to show you how to make a t1.micro work for you too!
The t1.micro is another interesting thing by itself. It has two virtual processors, but you’re only allowed to use it in bursts. If you use more than you’re allotted, you can get very heavily throttled. If you don’t have things optimized pretty well, you can quickly fall afoul of this. Don’t worry, by the time you’re done things will be working like a champ!
Other needed things
A few more things will have to be accounted for:
Storage, for the most part, will come courtesy of EBS — Elastic Block Store. You can create a virtual drive and attach it to your server. Behind the scenes this is actually a RAID of some drives. This is pretty cheap at $0.10/GB/month. I would be shocked if you need more than 6-8GB. That’s still less than a dollar. You also get charged by IO to the tune of $0.10/million requests. Don’t worry, a properly configured setup will have minimal IO.
The bandwidth costs come in at $0.12/GB. This has been in my experience a pretty small cost for me. You’re milage may vary if you have a very popular site. You can mitigate this by hosting your big media (like graphics) on some other service like SmugMug.
Backup is technically optional, but I would recommend it. The simplest way is just to store a snapshot of the site in S3. Since this is a backup, we can use the reduced redundancy storage option. $0.068/GB is pretty cheap. You can do this is a couple of ways, but I’ll dive deeper in a future article.
Here’s a cool thing with AWS — if you sign up you get a free year of a boat load of services. For instance, you can spin up a micro instance for free for a year! Try it out!
Excluding the free tier, if you’re running a small WordPress blog on a high-utilization t1.micro instance you can expect to pay around $10-12 a month on average. Once a year you’ll pay a bigger charge for the reservation, but other than that you’ll be pretty well under $6 a month.