An Architect's vision

A single Group can launch only same type of EC2 instance.  A single Group can launch only one type of AMI AMI's need to be present in the same region, rather same zone We can not used this group to scale RDS instance If we keep ELB as one level higher than Auto Scaling Group, when Scale Down happens, the process instructs ELB to remove EC2 instance from ELB group first.  Should be cautious about using Elastic IP with Auto Scaling Group. It may not be a cost effective option.  Max # of Launch configuration per AWS account is 100. 

We must not consider Auto Scaling for Database Tier. It may not be applicable. It needs distributed architecture ; might be suitable for certain NoSQL DBs. Needs a test case prior to take decision for Production.  For very small EC2 instance we must not consider Auto Scaling. Rather a bit lager EC2 instance can fix the issue.  For very frequent changes, EC2 auto scaling may not be right choice. e.g: Cricket match update. Need to plan for CDN. 

Application Tier Web Tier, Dispatchers Load Balancing

No. Adding an existing EC2 instance to a new Auto Scaling Group is not currently supported.

Step 1:  Need to edit  /etc/ssh/sshd_config and Step 2:  set PasswordAuthentication to yes. Step 3:  sudo /etc/init.d/sshd reload sudo service /etc/init.d/sshd restart

Checked the Note section while attaching EBS volume to EC2 instance. Got the following note. Note: Newer linux kernels may rename your devices to /dev/xvdf through /dev/xvdp internally, even when the device name entered here (and shown in the details) is /dev/sdf through /dev/sdp. Step 1:  # cat /proc/partitions major minor  #blocks  name  202       65    6291456 xvde1  202      144    1048576 xvdj Step 2:  # mkfs.ext3 /dev/xvdj and it's done.