everythingpossible - Fotolia

Manage Learn to apply best practices and optimize your operations.

Spoiler alert: Your AWS application isn't that mission-critical

It takes a big developer to admit his app isn't that important. And creating realistic uptime requirements for that not-so-critical app can save money.

That AWS application you've been working on for months may seem like your most important project, but it might not be mission-critical. Recognizing that early on in the test-and-development phase can save you some serious cash.

A developer asked for some help understanding an unexpectedly large monthly Amazon Web Services (AWS) bill he received for a newly developed app. The monthly bill was over $700, which is high for a single developer creating a single (simple) application.

When I dug into the AWS bill, it showed that Relational Database Service (RDS) was the top spend (Figure 1).

Costs in AWS Management Console
Figure 1

Upon further investigation, I noticed the developer was running a second-generation, extra-large, multi-availability zone (AZ) instance, along with multi-AZ provisioned IOPS (Figure 2). If you were running in a large production environment, with large numbers of users and specific response time guarantees, then a large installment like that might make sense. But it doesn't make sense for this AWS application for a number of reasons.

Amazon RDS costs
Figure 2

First, this app is still in development with a very small number of beta testers. They don't need multi-AZ resiliency or the response time of provisioned IOPS. The AWS app also has a small number of users who could easily be handled by a much smaller deployment. I suggested that, and the beta test is now running for about 1/10th the original burn rate.

But there's a deeper lesson here. This AWS application doesn't need such a resilient deployment; it may grow to a volume of users that warrants a powerful RDS configuration, but it won't need high resiliency. For example, email and GPS are two apps that require five nines of availability, but productivity wouldn't come to a screeching halt if an application like SoundCloud had the occasional hiccup.

Always on isn't always necessary

It's a paradox of the cloud -- developers and end users alike think we need constant uptime and that every application we use must be "always on." The reality is, "always on" is expensive and not every app needs that high availability.

Developers of small applications need to think through exactly how available the app needs to be, as many struggle to develop monetization strategies for the app, specifically for free apps. Does the free-service app need a deployment that stays up, even if the entire East Coast goes dark?

Not every service of a hugely successful application requires resiliency. For example, every few days I get an email from LinkedIn that suggests new connections. LinkedIn wants to encourage me to build my network, but neither of us will suffer if it fails to send me the occasional reminder to do so.

If you're running a storefront application, then you want it to be up all the time. But not all cloud-based applications fit that pattern. Nearly any reminder-style app or batch-processing app, as well as almost any type of loyalty program, could be a candidate for running in a lower-cost, less-resilient AWS configuration.

It's important to create realistic uptime requirements for your AWS application so you don't pay for something you don't need. It might be a blow to your ego to realize your app isn't as important as you initially thought, but your bottom line will thank you.

About the author:
Brian Tarbox has been doing mission-critical programming since he created a timing-and-scoring program for the Head of the Connecticut Regatta back in 1981. Though primarily an Amazon Java programmer, Brian is a firm believer that engineers should be polylingual and use the best language for the problem. Brian holds patents in the fields of UX and VideoOnDemand with several more in process. His Log4JFugue open source project won the 2010 Duke's Choice award for the most innovative use of Java; he also won a JavaOne best speaker Rock Star award as well as a Most Innovative Use of Jira award from Atlassian in 2010. Brian has published several dozen technical papers and is a regular speaker at local Meetups.

Dig Deeper on AWS architecture and design

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Excellent points. We often see the same thinking when customers do TCO comparisons between an on premises environment that has very little resiliency to an "always on" model in AWS.
Seems like a great opportunity to educate developers about the on-demand nature of public clouds, and using tools that let them describe their environment as code for automated updates and deployments. 

They have been conditioned to hoard resources up-front, because getting them later was often complicated or outside the budget. 

Now they can keep snapshots in low-cost object (S3 storage) and spin-up new VM (EC2) resources if AZ's fails, then leveraging tools like Chef/Puppet/Ansible/OpsWorks/etc. to spin up blueprints of the environment.