What is the “right way” to deploy a simple app/blo

Question

I am new to AWS, did my research but didn't get a good answer, hence asking a simple question.

What I have done so far

• I started a Linux AMI, installed LAMP and deployed my app, which is working fine
• Elastic IP is setup of the AMI
• Domain name is also pointed correctly

So in fact if you http://example-domain-name.com you'll be able to see the app, interact with it...

My question is, am I done now, is my app deployed correctly? As I have heard horror stories, of including AWS AMI crashing etc.

Could you please share your expertise on this.

Answer 1

The best of all possible cases, per your comment on your question, is a highly available, multi-AZ, autoscaling web tier, backed either with a replicating mysql db or, if you can afford it, something like Amazon RDS. Here's an example CloudFormation template that will build more or less what I just described in about two clicks, after you fill out a couple of variables.

It's overkill... I suppose... but if you are concerned about Amazon's myriad failure modes, high availability can be had for a price. That template's default instances (including multi-AZ RDS) come to about $270 a month for 24/7 uptime. If you were really dedicated to your blog, and could guarantee you'd be writing on it for years, you could save a fair bit of money using reserved instances.

That's a lot of money, yes. But it's also less than my monthly car insurance rate in NYC. That says more about my dubious insurer or my driving record than Amazon's prices, but in some personal applications highly available designs might be worth the cost. How much is your time worth to you? How about the blog?

Call that the gold standard, because you have to have a dump truck full of gold to afford it and still eat. What do you lose when you start hemorrhaging pieces?

• AZs: Shoot multi-AZ deployment and you risk an AZ outage. This doesn't happen that often but then again neither do derechos in the DC metro. Don't worry though, if you design around a single AZ, you're in some huge and perhaps unexpected company.

• RDS / replicated MySQL: Lose highly available data solutions and you risk losing your data. This is such a pain to recover from you'd best design with it in mind, even if it's as simple as the occasional EBS snapshot.

• Multiple webservers: Like the MySQL database, if you put your web tier on one machine, you're asking for an outage. You can design around it, if you can afford alternatives. Otherwise you'll want a simple programmatic way to construct your webserver.

• Autoscaling: I don't understand why anyone designs an AWS application without using autoscaling via CloudFormation or the CLI tools, even if the minimum number and maximum number of instances is exactly one. The free tier of AWS pricing includes plenty of CloudWatch metrics to make instance monitoring easy, but of course this depends on...

• Configuration management: The common thread in every AWS design is configuration management. It's the most important component of your deployment process regardless of how many machines you actually deploy. Whether you're using CloudFormation, Chef, Puppet, some other service, or a combination thereof, any time you spend on configuration management now, when the machine construction is still fresh in your mind, will be rewarded later.

Each of these components contributes to your application's stability, and all of them cost money or time. It's just a matter of what you want to spend, and when.

You can get part of the way to the gold-standard with Amazon's free tier. It includes enough hours to run a micro instance, an ELB, and a small RDS instance continuously in a single AZ. It also allows the use of 10 custom CloudWatch metrics at the time of this writing. The free tier is available only to new customers for their first year of use. Were you to combine its offerings with some basic configuration management, you could reasonably run a small blog on AWS in a way that avoids many downtime scenarios.

Answer 2

There is no good way. At a minimum, you need one load-balancer and two app instances. Plus, depending on your application, you will need a fault-tolerant RDS instance and/or S3.

AWS is the wrong solution for a simple app or a blog. You can get much better performance and durability for a significantly lower cost by using a single VPS or dedicated server at another provider. With AWS, you're paying a premium for the ability to quickly scale an application. If you don't need to do that, it's not the right choice. 90% of the people using AWS don't understand this.

Answer 3

It's important to understand that your AWS EC2 server "could" fail at any time... this is "by design"... they are charging you cheap rent on cheap non-redundant commodity hardware... there is no SLA...

So the real questions is: Do you have well documented (ideally scripted) process to QUICKLY rebuild your server from scratch and/or restore it from EBS snapshots?

If the answer to that question is: Yes! Then I would say you have "done it right"...

If not, you might want to spend a little more time understanding the bad things that can happen in AWS land... (again "by design").