Question : A customer has a web application that uses cookie Based sessions to track logged in users It Is deployed on AWS using ELB and Auto Scaling The customer observes that when load increases. Auto Scaling launches new Instances but the load on the easting Instances does not decrease, causing all existing users to have a sluggish experience. Which two answer choices independently describe a behavior that could be the cause of the sluggish user experience?
Choose 2 answers A. ELB's normal behavior sends requests from the same user to the same backend instance B. ELB's behavior when sticky sessions are enabled causes ELB to send requests in the same session to the same backend instance C. A faulty browser is not honoring the TTL of the ELB DNS name. D. The web application uses long polling such as comet or websockets. Thereby keeping a connection open to a web server for a long time
Explanation: Each ELB machine can pass through client connections to any of the EC2 instances in the ELB pool within a single availability zone. According to user reports in other forum posts, clients from a single IP address will tend to be connected to the same back-end instance. According to AWS ELB does round-robin among the least-busy back-end instances, keeping track of approximately how many connections (or requests) are active at each instance but without monitoring CPU or anything else on the instances. It is likely that earlier versions of ELB exhibited some stickiness, but today the only way to ensure stickiness is to use the Sticky Sessions feature.
the load balancer routing the same client to the same application server. And that's why they're so important: If the load balancer supports sticky sessions then you don't need to modify your application to remember client session context ELB supports two ways of managing the stickiness' duration: either by specifying the duration explicitly, or by indicating that the stickiness expiration should follow the expiration of the application server's own session cookie.
Long-polling comet solutions. With the 60-second idle timeout, you have to change your application to poll more often than every 60 seconds. For some apps, polling every 5 minutes would be better, but with ELB you have to bring that down to something less than 60 seconds. Definitely not optimal.
Question : What would happen to an RDS (Relational Database Service) multi-Availability Zone deployment of the primary DB instance fails? 1. The IP of the primary DB instance is switched to the standby DB instance 2. The RDS (Relational Database Service) DB instance reboots 3. Access Mostly Uused Products by 50000+ Subscribers 4. The canonical name record (CNAME) is changed from primary to standby
Explanation: It is really easy to benefit from the enhanced availability and data durability provided by a DB Instance deployment that spans multiple Availability Zones. All you need to do is supply one additional parameter to the CreateDBInstance function and Amazon RDS will take care of the rest.
To be more specific, when you launch a DB Instance with the Multi-AZ parameter set to true, Amazon RDS will create a primary in one Availability Zone, and a hot standby in a second Availability Zone in the same Region. Data written to the primary will be synchronously replicated to the standby. If the primary fails, the standby becomes the primary and a new standby is created automatically. Amazon RDS automatically detects failure and takes care of all of this for you. The entire failover process takes approximately about three minutes. In addition, existing standard DB Instance deployments can be converted to Multi-AZ deployments by changing the Multi-AZ parameter to true with the ModifyDBInstance function (a hot standby will be created for your current primary).
When automatic failover occurs, your application can remain unaware of what's happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. Your MySQL client library should be able to close and reopen the connection in the event of a failover. If your application needs to know that a failover has occurred, you can use the function to check for the appropriate event.
If you have set up an Amazon RDS DB Instance as a Multi-AZ deployment, automated backups are taken from the standby to enhance DB Instance availability (by avoiding I/O suspension on the primary). The standby also plays an important role in patching and DB Instance scaling. In order to minimize downtime during planned maintenance, patches are installed on the standby and then an automatic failover makes the standby into the new primary. Similarly, scaling to a larger DB Instance type takes place on the standby, followed by an automatic failover.
Multi-AZ deployments also offer enhanced data protection and reliability in unlikely failure modes. For example, in the unlikely event a storage volume backing a Multi-AZ DB Instance fails, you are not required to initiate a Point-in-Time restore to the LatestRestorableTime (typically five minutes prior the failure). Instead, Amazon RDS will simply detect that failure and promote the hot standby where all database updates are intact.
Question : How can the domain's zone apex for example "myzoneapexdomain.com" be pointed towards an Elastic Load Balancer?
Correct Answer : Get Lastest Questions and Answer : Route 53 offers 'Alias' records (a Route 53-specific virtual record). Alias records are used to map resource record sets in your hosted zone to Elastic Load Balancing load balancers, CloudFront distributions, or S3 buckets that are configured as websites. Alias records work like a CNAME record in that you can map one DNS name (example.com) to another 'target' DNS name (elb1234.elb.amazonaws.com). They differ from a CNAME record in that they are not visible to resolvers. Resolvers only see the A record and the resulting IP address of the target record.
Alias resource record sets can save you time because Amazon Route 53 automatically recognizes changes in the resource record sets that the alias resource record set refers to. For example, suppose an alias resource record set for example.com points to an ELB load balancer at lb1-1234.us-east-1.elb.amazonaws.com. If the IP address of the load balancer changes, Amazon Route 53 will automatically reflect those changes in DNS answers for example.com without any changes to the hosted zone that contains resource record sets for example.com.