Don't forget to create account on our site to get access to more material made only for free registered user.  

AWS Developer Certification : Associate Level AWS Sysops Administrator Certification : Assciate Level   AWS Solution Architect Certification : Associate Level  AWS Solution Architect Certification : Associate Level

1. When you have Auto Scaling enabled it will automatically increase the number of EC2 instances number of request to service increases, and decrease the number of EC2 instances when number of requests reduces.

2. If you have a higher load on your servers, use ELB service which will distribute the incoming web traffic load automatically among all the running EC2 instances in Auto scaling group.

3. Load balancers also help us to monitor the incoming traffic. All the traffic comes via only ELB (single point of contact) for all incoming traffic to the instances in an Auto Scaling group.

5. You can attach more than one ELB to your auto scaling group. Once you attach an ELB to Auto scaling group it will automatically registers the instances from the group and balance the incoming traffic across the instances.

7. ELB uses IP address of the instances to register them and routes requests to the primary IP address of the primary interface (eth0) of the instance.

8. You can also detach the ELB from scaling group, once you detach it will be having Removing state till deregistering of the instances in the group.

9. If connection draining is enabled, ELB waits for in-flight requests to complete before deregistering the instances.

10. Impact of Deregistering ELB on Instances: They will remain in their state like running instance will remain in running state only.

11. Suppose you have suspended Load Balancer and few more instances are added to scaling group , during the load balancer in suspended state instances launched during the suspension period are not added to the load balancer, after resumption we have to manually register them again.

12. Once you create an auto scaling group, you can attach ELB to them and all the instances running in scaling group will be automatically attached to ELB, you can have more than one ELB to group.

13. We can have auto scaling across AZs in single and same region. Similarly if you have attached an ELB to that auto scaling group, then it will also distribute the traffic across Azs.

14. Both the ELB and Scaling group separately check the health status for each instances separately. Scaling group check instance health using the instance status check. If instance is in failed status they will marked as unhealthy. ELB also perform the health status of instances using ping. However, Auto scaling is not depend on status check is done by ELB.

15. ELB does its own health check to make sure that traffic is routed to healthy instances.

16. Once an ELB is registered with a Scaling group, it can be configured to use the results of the ELB health check in addition to the EC2 instance status checks to determine the health of the EC2 instances in your Auto Scaling group.

17. You can also use Cloudwatch monitor matrix to monitor the EC2 instances and scaling group.

18. Once you have registered the ELB with scaling group, Scaling group can be configured to use ELB metrics e.g. such as request latency or request count to scale the application automatically.

19. Using the auto scaling, we can make sure that minimum number of required instances always available. However, we can attach some policy to auto scaling group. Which can help launch and terminate EC2 instances to handle any increase or decrease in demand on your application.

20. Auto Scaling attempts to distribute instances evenly between the Availability Zones that are enabled for your Auto Scaling group. Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances. If the attempt fails, however, Auto Scaling attempts to launch the instances in another Availability Zone until it succeeds

21. Launch Configuration: You can create a template known as launch configuration which has information e.g. AMI, Instance type, their key pairs, security group and block device mapping.

22. Once you created launch configuration, you cannot change it. If you want change please create new one. Also same launch configuration can be attached to multiple scaling group.

23. You have to have following for auto scaling group:

- Launch Configuration, Desired Capacity, Availability Zones or Subnets, Metrics & Health Checks

24. Auto Scaling groups cannot span multiple regions

25. After changing the launch configuration of Auto Scaling group, any new instances are launched using with this new configuration parameters, but existing instances are not affected.

26. While status check of EC2 instance, scaling group finds state other than RUNNING or IMPAIRED it will be considered as unhealthy and will launch new instance as replacement.

27. If you have configured scaling group to use instance status using both instance status as well as status reported by load balancer then it will mark instance as unhealthy if instance status is other than RUNNING /IMPAIRED or reported by ELB as OutOfService. Once is marked unhealthy it will be scheduled to be replaced and will not be automatically recovers its health.

28. When your instance is terminated, any associated Elastic IP addresses are disassociated and are not automatically associated with the new instance. You must associate these Elastic IP addresses with the new instance manually. Similarly, when your instance is terminated, its attached EBS volumes are detached. You must attach these EBS volumes to the new instance manually.

29. Attaching/Detaching of an EC2 instance can be done only if

- Instance is in the running state.

- AMI used to launch the instance must still exist.

- Instance is not a member of another Auto Scaling group.

- Instance is in the same Availability Zone as the Auto Scaling group.

- If the Auto Scaling group is associated with a load balancer, the instance and the load balancer must both be in the same VPC.

30. Scaling based on a schedule allows you to scale your application in response to predictable load changes. For e.g. last day of the month, last day of an financial year

31. Auto Scaling guarantees the order of execution for scheduled actions within the same group, but not for scheduled actions across groups

32. Multiple Scheduled Actions can be specified but should have unique time value and they cannot have overlapping time scheduled which will lead to its rejection

33. Dynamic Scaling: Allows you to scale automatically in response to the changing demand for e.g. scale out in case CPU utilization of the instance goes above 70% and scale in when the CPU utilization goes below 30%

34. Auto Scaling group uses a combination of alarms and policies to determine when the conditions for scaling are met.

35. An Auto Scaling group can have more than one scaling policy attached to it any given time.

36. Each Auto Scaling group would have at least two policies: one to scale your architecture out and another to scale your architecture in.

37. If an Auto Scaling group has multiple policies, there is always a chance that both policies can instruct the Auto Scaling to Scale Out or Scale In at the same time. When these situations occur, Auto Scaling chooses the policy that has the greatest impact on the Auto Scaling group. For e.g. if two policies are triggered at the same time and Policy 1 instructs to scale out the instance by 1 while Policy 2 instructs to scale out the instances by 2, Auto Scaling will use the Policy 2 and scale out the instances by 2 as it has a greater impact

38. Termination policy helps the Auto Scaling to decide which instances it should terminate first when you have Auto Scaling automatically scale in. Auto Scaling specifies a default termination policy and also allows you to create a customized one

39. Instance protection controls whether Auto Scaling can terminate a particular instance or not.

Instance protection can be enabled on an Auto Scaling group or an individual instance as well, at any time

40. Instance protection does not protect for the below cases

·         Manual termination through the Amazon EC2 console, the terminate-instances command, or the Terminate Instances API.

·         Termination if it fails health checks and must be replaced.

·         Spot instances in an Auto Scaling group from interruption.

41. Auto Scaling allows you to put the In-service instance in the Standby state during which the instance is still a part of the Auto Scaling group but does not serve any requests. This can be used to either troubleshoot an instance or update and instance and return the instance back to service

42. If a load balancer is associated with Auto Scaling, the instance is automatically deregistered when the instance is in Standby state and registered again when the instance exits the Standby state.