Stabilizing AWS Costs on UMW Blogs

One of the quiet wins we had in DTLT this semester was moving UMW Blogs to Amazon Web Services. It was essential because this platform was quickly outgrowing the limits of a dedicated server. In fact, if it weren’t for Tim Owens‘s fancy footwork to help us scale the system, it may not have made it. Since the move it has worked beautifully, and we had no major issues the entire academic year.

One of the concerns we had throughout the year, however, was the cost. One of the reasons folks were scared of AWS is the fact that you pay monthly based on usage and resources rather than a fixed cost for a dedicated server. The idea of metered usage of servers, server infrastructure as a pay-per-use utility, is still a foreign concept for most IT units, not less purchasing! The lingering fear was that one month something would go wrong and the costs would skyrocket and our server budget would be eaten up in a month. While that could happen, there are all kinds of billing safeguards that make it fairly difficult.

Screen Shot 2015-07-05 at 1.40.51 PM

What’s interesting it to look back over our first year of usage in terms of costs to get a sense of how the system has become to find a rough monthly average in terms of costs. In the early fall we were running fewer EC2 instances, which meant the price was lower although the site was not nearly as fast. In November Tim rolled out four load balanced EC2 instances, and that was a brave new world. But as you can see from the costs for the EC2 servers in December and January, we had to dial back some of the settings because those two months were more expensive than we had planned. We needed to remain around the sweet spot of $550-$600 a month for this set up to be cheaper than what we were paying for a dedicated server, which was roughly $8500 a year.

Screen Shot 2015-07-05 at 1.41.06 PM

As you can see from February through June, we accomplished that. we averaged about $585 for those 4 months, and we had a completely stable system. The trick to managing AWS is having someone to experiment and mind those use patterns over the first year and tweak and perfect the setup. If we had more resources allocated for UMW Blogs we could certainly spend more, but such an exercise of managing to a budget is probably a good idea with AWS because it forces you to make sure your setup is tight. If it isn’t, you could keep throwing EC2 instances at the problem and spending a lot of money and still have a very fast, but quite expensive, infrastructure. Like anything, it takes good people who are willing to experiment and have an idea of what they are doing—or at least are willing to learn while they are flying!

This entry was posted in AWS and tagged , . Bookmark the permalink.

6 Responses to Stabilizing AWS Costs on UMW Blogs

  1. pat says:

    Is $8500 the cost for a server from a Uni IT department an average?
    It is the most I’ve heard of. Not sure if UK unis are cheaper by default, but I’ve experienced “free” up to £4000

    • Reverend says:


      We contract out for these servers, and they are usually jacked up in terms of price by state vendors. But given UMW Blogs is a beast, and we have over 9000 sites on it and tons of legacy databases. The problem with making WPMu stable is the database setup, and having four spall CPUs loaded balanced is far more effective and easier than one big dedicated CPU, the machine UMW Blogs ran on was pretty beefy. In terms of free up to 4000 pounds, not sure what that means, but it sounds like a real deal. I think we need that system here 🙂

      • pat says:

        In terms of cost, at various unis, I’ve heard of prices of free (Nottingham), 300 pounds (Oxford) to 4000 pounds (London).

        Not sure any could do 8000 blogs, but we ran some big systems on them.

        Wondering how much the unknown cost of scale is a problem both for finance departments and for edtech projects. One reddit link and boom, no budget. Which makes me wonder about heavy caching and static pages as a preference to anything with a DB? DBless systems… not even nosql

        • Reverend says:

          Nothing for free in America :0 As for DBless systems, don;t crazy on me here, I’m not ready for the hard slog back to HTML files, even though I love Geocities 🙂

          • pat says:

            Am thinking most of the DB systems (drupal, WP) almost always fall back on caching for speed.

            So thinking that no DB service is a better performing server? So scale isn’t a worry

            The publishing process is the DB

  2. You’re still looking at a very small price for a very remarkable service. You also have a piece of reliable architecture that is simple to outsource to AWS and get a scalable solution. This means your uni IT can work on the more interesting stuff which is increasingly around integration (preferably loosely coupled) so that all the bits can work together smoothly.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.