From Colo to Managed to Amazon AWS

What follows is my original post and first look at AWS back in 2009. I never looked back since then:

It’s been over 3 years since we launched our Internet infrastructure. We started with Co-location, stayed on it for 12 months and then looked for ways to save money with hardware support, after all we are in business of software not hardware. Managed hosting was the next logical step and it proved to be very effective at cutting our operational cost by 50%. That was 18 months ago … Our contract with managed hosting vendor was up for renewal and I started to look for ways to further cut our costs of running hardware.

Amazon AWS

I’ve known about Amazon Web Services for a while now, I’ve checked their RMAN backup solutions to Amazon S3 and even tried to convince our corporate to move in that direction, but there was too much red-tape and we put that on hold. Now, faced with a task to cut our cost by at least 50 more percent I figured it’s time to delve into what Amazon AWS was all about.

I signed up for Amazon AWS account and in few minutes was staring at their management console not knowing what to do next. AWS’s pricing model is based on per-use basis, you only pay for what you use and the usage is measured per hour. This model is great for testing thing our without the traditional sign-the-contract first and try later approach deployed throughout the hosting industry today. All I had to do was figure out what it is that I wanted to try. After all there are so many products available on AWS that making any sense of it can be quite challenging.

After reading numerous online articles and AWS’s documentation it became apparent to me that what I wanted to try was Amazon EC2 instances for running my OS, Amazon ELASTIC BLOCK STORE (EBS) Volumes for my persistent resilient storage and Amazon Elastic IPs to cement a routable IP address in case I needed to rebuild an EC2 instance.

Amazon EC2 instance

EC2 instances are the building blocks of Cloud infrastructure. They are deployed using AMIs – (Amazon Machine Images). You can build your own AMI or use one of the supplied AMIs available to you via the AWS Control Panel. Oracle provides number of basic AMIs for Oracle Database, Application Server and APEX. The best part about using Oracle provided AMI is that you get an Oracle Enterprise Linux properly installed and configured. That’s exactly what I did and it worked out great.

Amazon EBS Volumes

EBS Volumes are necessary only if you require a persistent, resilient storage, such as used for databases. It’s because EC2 instance are not persistent, that is if you terminate an EC2 instance and later re-launch it — all of the data and changes that were made on the instance are wiped out. Bouncing an instance is NOT the same as terminating it. Instance changes persist between instance restarts (bounces), terminating instance however is when you tell Amazon that you are no longer willing to pay for it’s usage and thus all resources are reclaimed. And even though when you build an EC2 instance you might not ever want to terminate it, it’s still not a good idea to rely on EC2’s internal storage for database files. EBS Volumes solve this problem by giving you a resilient, persistent storage which you can mount just like any volume to your EC2 instances.

Elastic IPs

Whenever you terminate an EC2 instance (See EBS Volumes above) your routable IP address that’s assigned to your instance changes. This obviously is not acceptable for an Internet based infrastructure. Elastic IPs solve this problem. You can easily assign an Elastic IP to any of your EC2 instances at any time — it does require a reboot of the instance so plan accordingly.

Conclusion

After running a pilot of our infrastructure on Amazon AWS for 2 weeks I realized that we could be saving up to 70% of our current managed hosting costs and soon after terminated our managed hosting contract moving 100% to Amazon AWS.

What’s most amazing about this experience is that to get this astonishing amount of savings, required very little changes to the way we were conducting our operations. In fact, for the most part, these changes were very positive. After all, you are no longer required to be tied into a hard contract for hardware. If your demand for hardware fluctuates (who’s doesn’t?) it’s extremely easy to adjust your needs using Amazon AWS, provided your architecture is properly designed to handle these changes.

Leave a Reply

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