You have a business-critical two-tier web app currently deployed in two AZs in a single region, using Elastic
Load Balancing and Auto Scaling. The app depends on synchronous replication (very low latency connectivity)
at the database layer. The application needs to remain fully available even if one application AZ goes off-line,
and Auto Scaling cannot launch new instances in the remaining Availability Zones. How can the current
architecture be enhanced to ensure this?
A.
Deploy in two regions using Weighted Round Robin (WRR), with Auto Scaling minimums set for 50 percent
peak load per Region.
B.
Deploy in two regions using Weighted Round Robin (WRR), with Auto Scaling minimums set for 100
percent peak load per region.
C.
Deploy in three Availability Zones, with Auto Scaling minimum set to handle 50 percent peak load per zone.
D.
Deploy in three Availability Zones, with Auto Scaling minimum set to handle 33 percent peak load per zone.
C.
https://acloud.guru/forums/aws-certified-solutions-architect-associate/discussion/-KN-_V7WJkvYXS0ySYZV/questions-want-to-verify-answers
its D if refreced from above link
It’s C – read more carefully through all comments 🙂
I think it’s D, we only have 2 AZs here
oh sorry, it’s C
It’s C because ” fully available ” (100%) is main keyword. if each AZ is at 50% then eventhough one goes down it will be 100%.
Answer is C
hi!
I would vote for D
Deploy in three Availability Zones, with Auto Scaling minimum set to handle 33 percent peak load per zone
reason:
*) you have actually 2 AZs (eu-central-1a, eu-central-1b) and running both with 50% of your full-peak load
*) adding a 3rd AZ (eu-central-1c) you can reduce the load from your existing AZs (eu-central-1a, eu-central-1b) to 33% as well and thus giving you again the possibility to use auto-scaling
*) in case on AZ (eu-central-1a) goes done auto-scaling would then raise capacity on reaming 2 AZs (eu-central-1b, eu-central-1c) to 50%
only point which I’m 100% sure:
in the question it is just mentioned “Auto Scaling cannot launch new instances in the remaining Availability Zones” => there is no root-cause mentioned why Auto Scaling is not working
e.g.:
a) because of Auto Scaling is broken/miss-configured or
b) because Auto Scaling reached an AWS-service-limit
what do you think about this option?
br!
Carl
resource limited.
Good Explanation Carl!
I would go for D.
I can see below comment in below link. Means, Option D is right one.
A. Deploy in three Availability Zones, with Auto Scaling minimum set to handle 33 percent peak load per zone.
https://acloud.guru/forums/aws-certified-solutions-architect-associate/discussion/-KN-_V7WJkvYXS0ySYZV/questions-want-to-verify-answers
But the link says in 3 AZs and 50% each is correct though.
Auto Scaling cannot launch new instances in the remaining Availability Zones.
For people who picked D, what is your answer to the question100?
C
The current configuration is unknown in terms of auto scaling minimums. The DB requires synchronous replication so we can rule out multi region options because of performance impacts. If we assume that capacity(peak load) for the web application is 60 units then
50% capacity over 3 AZ means each AZ can process up 30 units.
az1 = up to 30 units
az2 = up to 30 units
az3 = up to 30 units
If we lose one az1 and the ability to scale out capacity on the remaining AZ we can still handle peak load. 60 units over 2 AZ
vs.
33% capacity over 3 AZ means each AZ can process up 20 units.
az1 = up to 20 units
az2 = up to 20 units
az3 = up to 20 units
If we LOSE az1 AND THE ABILITY TO SCALE out capacity on the remaining AZs the result is a configuration that can only handle 40 units