Replace a single web instance with an Auto Scaling group and Aurora read replicas

Design a strategy to meet reliability requirements. Determine a strategy to improve reliability.
Answer Correct answer: B — Run the app in an Auto Scaling group behind a load balancer and use Aurora Replicas for the read-intensive operations.

A company's web application has reliability issues. The application serves customers globally. The application runs on a single Amazon EC2 instance and performs read-intensive operations on an Amazon RDS for MySQL database. During high load, the application becomes unresponsive and requires a manual restart of the EC2 instance. A solutions architect must improve the application's reliability. Which solution will meet this requirement with the LEAST development effort?

  1. Create an Amazon CloudFront distribution. Specify the EC2 instance as the distribution’s origin. Configure a Multi-AZ deployment for the RDS for MySQL database. Use the standby DB instance for the read-intensive operations.
  2. Run the application on EC2 instances that are in an Auto Scaling group. Place the EC2 instances behind an Elastic Load Balancing (ELB) load balancer. Replace the database service with Amazon Aurora. Use Aurora Replicas for the read-intensive operations. Correct Answer
  3. Deploy AWS Global Accelerator. Configure a Multi-AZ deployment for the RDS for MySQL database. Use the standby DB instance for the read-intensive operations.
  4. Migrate the application to AWS Lambda functions. Create read replicas for the RDS for MySQL database. Use the read replicas for the read-intensive operations.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

An Auto Scaling group behind a load balancer removes the single point of failure without any code change, and Aurora Replicas offload the read-intensive queries, so both the availability and the performance failure modes are addressed by configuration rather than development.

A globally served application runs on one EC2 instance and does read-intensive work against RDS for MySQL. It becomes unresponsive under load and needs a manual restart, so reliability must improve with the least development effort.

Adding CloudFront in front of the existing instance. CloudFront only caches and accelerates content delivery, so the underlying single instance remains a single point of failure and the read load against RDS is unchanged, leaving the manual restart requirement unresolved.

Community Discussion (14 comments)

0b43291 👍 1 Selected: B
While the Classic Load Balancer may have limitations compared to the newer Application Load Balancers (ALB) or Network Load Balancers (NLB), it still provides significant benefits over a single EC2 instance architecture. Therefore, if we consider Option B with the assumption that "ELB" refers to the Classic Load Balancer, it would still be a better solution than Option A, which relies on a single EC2 instance as the origin for the CloudFront distribution. Combining an ELB (even the Classic Load Balancer) with an Auto Scaling group and a scalable database solution like Amazon Aurora with read replicas would provide a more reliable and scalable architecture than a single EC2 instance and a Multi-AZ RDS for MySQL database.
0b43291 👍 1
B is all great apart from the ELB instead of an ALB
AzureDP900 👍 1
B is right answer , A sound right but there is no need of cloud front for this use case.
Nandha2021 👍 1
Answer B
blackname 👍 2 Selected: B
Obviously B
Win007 👍 1
D is the answer
titi_r 👍 1 Selected: B
Answer: B.
Fu7ed 👍 3 Selected: B
The answer is B. - Automatically restart using health check when not responding ->>ASG - Global customers and read-intensive >> 'Read Replica' should be available. A: EC2 is still alone C: EC2 is still alone D: It's not a minimum development effort
4555894 👍 1 Selected: D
D. Migrate the application to AWS Lambda functions. Create read replicas for the RDS for MySQL database. Use the read replicas for the read-intensive operations. Here's why the other options require more development effort: A. CloudFront with Multi-AZ RDS: This requires setting up CloudFront and configuring it to point to the EC2 instance. It also requires switching to a Multi-AZ RDS deployment, which might involve downtime. B. Auto Scaling with ELB and Aurora: This requires the most effort. You need to migrate the application to run on multiple EC2 instances managed by Auto Scaling, set up an ELB to distribute traffic, migrate the database to Aurora, and configure Aurora Replicas. C. Global Accelerator with Multi-AZ RDS: Similar to option A, this involves setting up Global Accelerator and requires a Multi-AZ RDS deployment.
tushar321 👍 1
B is correct
noisonnoiton 👍 4 Selected: B
RDS need readable standby instance
federikinho 👍 1 Selected: A
B is obviously correct for LEAST effort
Zas1 👍 1 Selected: C
Customers globally sounds good Global Accelerator More Work develope migrate app to Lambda Amazon Relational Database Service (Amazon RDS) for PostgreSQL and for MySQL now support a new Amazon RDS Multi-AZ deployment option with one primary and two readable STANDBY database (DB) instances across three Availability Zones (AZs). https://pages.awscloud.com/Deep-dive-on-Amazon-RDS-Multi-AZ-with-two-readable-standbys_2022_0408-DAT_OD.html For a standard accelerator, you can add one or more regional resources, such as load balancers or EC2 instances endpoints, https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-get-started.html
devnv 👍 2
B is correct

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Running the application on multiple EC2 instances in an Auto Scaling group behind a load balancer replaces the single instance that requires manual restarts and self-heals when an instance becomes unhealthy, with no application code changes. Replacing RDS for MySQL with Aurora and using Aurora Replicas for the read-intensive work distributes the read load that was saturating the database while preserving the same JDBC interface, which keeps development effort at essentially zero.

Why the Other Options Are Wrong

A and C: CloudFront and Global Accelerator improve content delivery and global latency, but both keep the original single EC2 instance as the origin, so the single point of failure and the manual restart requirement remain. In C there is no compute solution at all. D: Migrating to Lambda requires re-architecting the application around functions and triggers, which is the highest development effort of the options, and RDS for MySQL read replicas still add replication lag for read-heavy access.

Community Comment Notes

The community voted 79 to 1 for B. Commenters agreed that A and C sound plausible but add nothing to the compute availability problem, and one noted the ELB wording is loose but the intent is a load balancer in front of the Auto Scaling group.

Official Reference

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-replicas.html

Related Analysis

A solutions architect is importing a VM from an on-premises

A-Grade

A company requires that all internal application connectivit

S-Grade

A medical company is running a REST API on a set of Amazon E

S-Grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide