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.
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.
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.