Auto Scaling dynamically adds and removes EC2 instances, while Elastic Load Balancing manages incoming requests by optimally routing traffic so that no one instance is overwhelmed
Auto Scaling helps to automatically increase the number of EC2 instances when the user demand goes up, and decrease the number of EC2 instances when demand goes down
ELB service helps to distribute the incoming web traffic (called the load) automatically among all the running EC2 instances
ELB uses load balancers to monitor traffic and handle requests that come through the Internet.
Using ELB & Auto Scaling
makes it easy to route traffic across a dynamically changing fleet of EC2 instances
load balancer acts as a single point of contact for all incoming traffic to the instances in an Auto Scaling group.
Attaching/Detaching ELB with Auto Scaling Group
Auto Scaling integrates with Elastic Load Balancing and enables to attach one or more load balancers to an existing Auto Scaling group.
ELB registers the EC2 instance using its IP address and routes requests to the primary IP address of the primary interface (eth0) of the instance.
After the ELB is attached, it automatically registers the instances in the group and distributes incoming traffic across the instances
When ELB is detached, it enters the Removing state while deregistering the instances in the group.
If connection draining is enabled, ELB waits for in-flight requests to complete before deregistering the instances.
Instances remain running after they are deregistered from the ELB
Auto Scaling adds instances to the ELB as they are launched, but this can be suspended. Instances launched during the suspension period are not added to load balancer, after resumption, and must be registered manually.
High Availability & Redundancy
Auto Scaling can span across multiple AZs, within the same region
When one AZ becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected AZ
When the unhealthy AZs recovers, Auto Scaling redistributes the traffic across all the healthy AZs
Elastic Load balancer can be setup to distribute incoming requests across EC2 instances in a single AZ or multiple AZs within a region
It is recommended to take advantage of the safety and reliability of geographic redundancy by using Auto Scaling & ELB by spanning Auto Scaling groups across multiple AZs within a region and then setting up ELB to distribute incoming traffic across those AZs.
Incoming traffic is load balanced equally across all the AZs enabled for ELB
Auto Scaling group determines the health state of each instance by periodically checking the results of EC2 instance status checks
Auto Scaling marks the instance as unhealthy and replaces the instance, if the instance fails the EC2 instance status check
ELB also performs health checks on the EC2 instances that are registered with the it for e.g. application is available by pinging and health check page
Auto Scaling, by default, does not replace the instance, if the ELB health check fails
ELB health check with the instances should be used to ensure that traffic is routed only to the healthy instances
After a load balancer is registered with an Auto 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 the Auto Scaling group.
Elastic Load Balancing sends data about the load balancers and EC2 instances to Amazon CloudWatch. CloudWatch collects data about the performance of your resources and presents it as metrics.
After registering one or more load balancers with the Auto Scaling group, Auto Scaling group can be configured to use ELB metrics (such as request latency or request count) to scale the application automatically
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
A company is building a two-tier web application to serve dynamic transaction-based content. The data tier is leveraging an Online Transactional Processing (OLTP) database. What services should you leverage to enable an elastic and scalable web tier?
Elastic Load Balancing, Amazon EC2, and Auto Scaling
Elastic Load Balancing, Amazon RDS with Multi-AZ, and Amazon S3
Amazon RDS with Multi-AZ and Auto Scaling
Amazon EC2, Amazon DynamoDB, and Amazon S3
You have been given a scope to deploy some AWS infrastructure for a large organization. The requirements are that you will have a lot of EC2 instances but may need to add more when the average utilization of your Amazon EC2 fleet is high and conversely remove them when CPU utilization is low. Which AWS services would be best to use to accomplish this?
Amazon CloudFront, Amazon CloudWatch and Elastic Load Balancing
Auto Scaling, Amazon CloudWatch and AWS CloudTrail
Auto Scaling, Amazon CloudWatch and Elastic Load Balancing
Auto Scaling, Amazon CloudWatch and AWS Elastic Beanstalk
A user has configured ELB with Auto Scaling. The user suspended the Auto Scaling AddToLoadBalancer, which adds instances to the load balancer. process for a while. What will happen to the instances launched during the suspension period?
The instances will not be registered with ELB and the user has to manually register when the process is resumed
The instances will be registered with ELB only once the process has resumed
Auto Scaling will not launch the instance during this period due to process suspension
It is not possible to suspend only the AddToLoadBalancer process
You have an Auto Scaling group associated with an Elastic Load Balancer (ELB). You have noticed that instances launched via the Auto Scaling group are being marked unhealthy due to an ELB health check, but these unhealthy instances are not being terminated. What do you need to do to ensure trial instances marked unhealthy by the ELB will be terminated and replaced?
Change the thresholds set on the Auto Scaling group health check
Add an Elastic Load Balancing health check to your Auto Scaling group
Increase the value for the Health check interval set on the Elastic Load Balancer
Change the health check set on the Elastic Load Balancer to use TCP rather than HTTP checks
You are responsible for a web application that consists of an Elastic Load Balancing (ELB) load balancer in front of an Auto Scaling group of Amazon Elastic Compute Cloud (EC2) instances. For a recent deployment of a new version of the application, a new Amazon Machine Image (AMI) was created, and the Auto Scaling group was updated with a new launch configuration that refers to this new AMI. During the deployment, you received complaints from users that the website was responding with errors. All instances passed the ELB health checks. What should you do in order to avoid errors for future deployments? (Choose 2 answer) [PROFESSIONAL]
Add an Elastic Load Balancing health check to the Auto Scaling group. Set a short period for the health checks to operate as soon as possible in order to prevent premature registration of the instance to the load balancer.
Enable EC2 instance CloudWatch alerts to change the launch configuration’s AMI to the previous one. Gradually terminate instances that are using the new AMI.
Set the Elastic Load Balancing health check configuration to target a part of the application that fully tests application health and returns an error if the tests fail.
Create a new launch configuration that refers to the new AMI, and associate it with the group. Double the size of the group, wait for the new instances to become healthy, and reduce back to the original size. If new instances do not become healthy, associate the previous launch configuration.
Increase the Elastic Load Balancing Unhealthy Threshold to a higher value to prevent an unhealthy instance from going into service behind the load balancer.
What is the order of most-to-least rapidly-scaling (fastest to scale first)? A) EC2 + ELB + Auto Scaling B) Lambda C) RDS
B, A, C (Lambda is designed to scale instantly. EC2 + ELB + Auto Scaling require single-digit minutes to scale out. RDS will take at least 15 minutes, and will apply OS patches or any other updates when applied.)
C, B, A
C, A, B
A, C, B
A user has hosted an application on EC2 instances. The EC2 instances are configured with ELB and Auto Scaling. The application server session time out is 2 hours. The user wants to configure connection draining to ensure that all in-flight requests are supported by ELB even though the instance is being deregistered. What time out period should the user specify for connection draining?
1 hour (max allowed is 3600 secs that is close to 2 hours to keep the in flight requests alive)