Question : You have registered two EBS backed instances with ELB. One of the instances was stopped by CloudWatch and you started back it manually. Will ELB route traffic to the same instance? 1. Yes, provided it has the same instance ID 2. Yes, provided it was not removed from ELB 3. Access Mostly Uused Products by 50000+ Subscribers 4. Yes, provided it is in the same AZ
Correct Answer : Get Lastest Questions and Answer : Explanation: If an EC2 instance is stopped and started again, its IP will change. An instance gets registered with ELB using the IP address. If the IP is changed, ELB will count the instance as unhealthy and will never route traffic back to it. Configuring EC2 Instances for Load Balancing
After you've created your load balancer, you have to register your EC2 instances with the load balancer. Your EC2 instances can be within a single Availability Zone or span multiple Availability Zones within a region. Elastic Load Balancing routinely performs health check on all the registered EC2 instances and automatically distributes all incoming requests to the DNS name of your load balancer across your registered, healthy EC2 instances. For more information on the health check of your EC2 instances, see Health Check.
Make sure to install webserver, such as Apache or Internet Information Services (IIS), on all the EC2 instances you plan to register with your load balancer.
Stop and Start EC2 Instances
The instances are registered with the load balancer using the IP addresses associated with the instances. When an instance is stopped and then started, the IP address associated with your instance changes. This prevents the load balancer from routing traffic to your restarted instance. When you stop and then start your registered EC2 instances, we recommend that you de-register your stopped instance from your load balancer, and then register the restarted instance. Failure to do so may prevent the load balancer from performing health checks and routing the traffic to the restarted instance. For procedures associated with de-registering and then registering your instances with your load balancer, see Deregister and Register EC2 Instances.
Setting Keepalive On Your EC2 Instances
For HTTP and HTTPS listeners, we recommend that you enable the keep-alive option in your EC2 instances. This may be done in your web server settings and/or in the kernel settings for your back-end instance. Keep-alive option will allow the load balancer to re-use connections to your backend for multiple client requests. This reduces the load on your web server and improves the throughput of the load balancer. The keep-alive timeout should be at least 60 seconds to ensure that the load balancer is responsible for closing the connection to your instance. Sticky Sessions
By default, a load balancer routes each request independently to the application instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user's session to a specific application instance. This ensures that all requests coming from the user during the session will be sent to the same application instance.
The key to managing the sticky session is determining how long your load balancer should consistently route the user's request to the same application instance. If your application has its own session cookie, then you can set Elastic Load Balancing to create the session cookie to follow the duration specified by the application's session cookie. If your application does not have its own session cookie, then you can set Elastic Load Balancing to create a session cookie by specifying your own stickiness duration. You can associate stickiness duration for only HTTP/HTTPS load balancer listeners.
Question : When AutoScaling is launching a new instance based on condition, which of the below mentioned policies will it follow? 1. Launch an instance in the AZ with the fewest instances 2. Based on the criteria defined with cross zone Load balancing 3. Access Mostly Uused Products by 50000+ Subscribers 4. Launch an instance which has the highest load distribution
Explanation: Auto Scaling helps you ensure that you have the correct number of EC2 instances available to handle the load for your application. You create collections of EC2 instances, called Auto Scaling groups. You can specify the minimum number of instances in each Auto Scaling group, and Auto Scaling ensures that your group never goes below this size. You can specify the maximum number of instances in each Auto Scaling group, and Auto Scaling ensures that your group never goes above this size. If you specify the desired capacity, either when you create the group or at any time thereafter, Auto Scaling ensures that your group has this many instances. If you specify scaling policies, then Auto Scaling can launch or terminate instances as demand on your application increases or decreases.
For example, the following Auto Scaling group has a minimum size of 1 instance, a desired capacity of 2 instances, and a maximum size of 4 instances. The scaling policies that you define adjust the number of instances, within your minimum and maximum number of instances, based on the criteria that you specify. AutoScaling attempts to distribute instances evenly between the Availability Zones that are enabled for the user's AutoScaling group. Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances
Question : AcmeShell Inc has departments and wants to track the AWS usage of each department. Which of the below mentioned options meets the requirement? 1. Setup IAM groups for each department and track their usage 2. Create separate accounts for each department and track them separately 3. Access Mostly Uused Products by 50000+ Subscribers 4. Create separate accounts for each department, but use consolidated billing for payment and tracking
Central control of users and security credentials-You can control creation, rotation, and revocation of each user's AWS security credentials (such as access keys)
Central control of user access-You can control what data in the AWS system users can access and how they access it
Shared AWS resources-Users can share data for collaborative projects
Permissions based on organizational groups-You can restrict users' AWS access based on their job duties (for example, admin, developer, etc.) or departments. When users move inside the organization, you can easily update their AWS access to reflect the change in their role
Central control of AWS resources-Your organization maintains central control of the AWS data the users create, with no breaks in continuity or lost data as users move around within or leave the organization
Control over resource creation-You can help make sure that users create AWS data only in sanctioned places
Networking controls-You can help make sure that users can access AWS resources only from within the organization's corporate network, using SSL
Single AWS bill-Your organization's AWS account gets a single AWS bill for all your users' AWS activity The cost of an IAM user or groups can never be tracked separately for the purpose of billing. The best solution in this case is to create a separate account for each department and use consolidated billing.