Amazon AWS Website deployment Part 1

I will briefly describe the tools and idea behind using the Amazon AWS for Web deployments to it’s full extent without overdoing it. This is the first Step of at least three I am going to write down for reference and critic. I have not read any books on the subject, having worked as both server engineer in data centers and 3 tier coder I had accumulated a fair share of failures and ideas of what could have been done right. It was just plain hindsight behind doing things the way I did. I used AWS documentation for most of my work as I do now with Openshift.

Parts 1. Architecture (Infrastructure requirements) 2. Tools - Platforms, tools, scripts and programs 3. Building, Testing and Automating

This is the simplest form of web deployment that is scalable, fault tolerant and very redundant as well as stable. Below is an architecture of the basic AWS IaaS building blocks we need. Here I use Amazon RDS for MySQL as it takes care of a lot of headaches involved with maintaining a MySQL server with backups and failover.

[caption id="" align=“aligncenter” width=“982”] Amazon AWS WEB deployment, highly scalable and redundant[/caption]

I currently have at least 3 deployments in production between one to three years and can maintain an up time of 99.9x% despite occasional DOS attacks and several Database migrations.

For PHP5 backed applications:

App Servers - These EC2 Instances can be just plain web servers with Nginx + PHP-FPM and your source code. All static files, all user data (uploaded files , avatars pictures, comments etc) that can change should not be here on local drives. They should be in S3 or other locations that can be shared by any EC2 Instance. Note: Amazon Sales will tell you to use huge EBS drives and copy files over etc. I do not understand their reasoning for this. All App servers I have are Instance Store Machine Images which contain source code/executables only. While boot time is slightly longer (as claimed by AWS sales) I see no significant difference. I also found EBS backed instances are more prone to failures, reboots, corruption and cost more. A badly configured EBS backed instance can leave behind unused EBS volumes like bird shit.

WARNING: NEVER USE NFS TO SHARE FILES BETWEEN AUTOSCALED SERVERS. IN FACT NEVER USE NFS… period.

RDS: Always use Multi-AZ. Try to keep to one DB only for best performance , now you know why programmers used table prefixes. Do not use anything less than a small instance on production. WARNING FOR MYSQL RDS USERS: NEVER USE MYISAM Tables. INFACT , ONLY USE INNODB unless you have a damn good reason to not use InnoDB. Activate Snapshots to atleast 5 days. They are very useful when someone accidentally deletes your database , muti AZ will not save you, it will happily delete your failover copy. Yes it happens in real life! If ou want to make your own homegrown backup server , go ahead but leave snapshots on. They are the fastest recovery mechanism and is virtually hands free.

I think the rest is self explanatory for now. Unless there are questions then I can update the post.

In Part 2, I will cover the tools like memcache, syslog, configuring an AMI with startup scripts, automating stuff.