How to Make Legacy EC2 Applications Fault Tolerant After Migration?
Answer
Correct answer: C — Create an AMI of each legacy server, launch two EC2 instances in separate Availability Zones, and put them behind a Network Load Balancer.
A company is migrating a data center from its on-premises location to AWS. The company has several legacy applications that are hosted on individual virtual servers. Changes to the application designs cannot be made. Each individual virtual server currently runs as its own EC2 instance. A solutions architect needs to ensure that the applications are reliable and fault tolerant after migration to AWS. The applications will run on Amazon EC2 instances. Which solution will meet these requirements?
Community Insight
The test is distinguishing replacement after failure from concurrent multi-AZ redundancy; the trap is treating an Auto Scaling group with min=1 and max=1 as fault tolerant.
Legacy EC2 applications that cannot be redesigned achieve fault tolerance by cloning each server from an AMI and running the copies in separate Availability Zones behind a Network Load Balancer. This page establishes why C, not single-instance Auto Scaling or backup restore, matches the reliability requirement.
The most common wrong pick is A, because Auto Scaling sounds highly available, but max=1 keeps only one running EC2 instance and cannot keep the application serving during an AZ failure.
Community Discussion (24 comments)
crock43
👍 1
Selected: C
Applications are legacy applications whose designs cannot be changed, so we need to improve reliability at the infrastructure level C: AMI → EC2-AZ1 + EC2-AZ2 → Network Load Balancer provides: Fault tolerance: If one AZ or EC2 instance fails, the other can continue serving requests. High availability: Instances are distributed across separate Availability Zones. Load distribution: The Network Load Balancer distributes traffic between the healthy instances. No application redesign: The legacy application remains unchanged.
2422182
👍 1
Selected: C
C is correct Requirements: - Legacy applications (no code changes allowed) - Each app runs on its own EC2 instance today - Must be reliable and fault tolerant - Must stay on EC2 NOT A: Auto Scaling group min=1 max=1 - Still single-instance architecture - No fault tolerance across AZs - Load balancer doesn’t help if only one instance exists
KarlosRC
👍 1
Selected: C
"ensure that the applications are reliable" - we need 2 AZ
ln2718
👍 1
Selected: A
The question is if "fault tolerant" is considered such with an automatic restart in an autoscaling group of 1? Terrible question, but the rest of the question matches.
bora4motion
👍 1
Selected: C
needs to be C for fault tolerant.
Dantecito
👍 1
Selected: C
C is the answerd. A. Changes in application designs are not the same as changes in infrastructure, also is not fault tolerant and an ALB just for one instance? whats the point of that
dfgdsfgfdgreg
👍 1
Selected: C
A has a single point of failure = not fault tolerant
LeonSauveterre
👍 2
Selected: C
A - Creating an AMI of each application instance ensures that the migrated applications are deployed consistently with their existing configurations, yes, but an Auto Scaling group with a minimum and maximum of one provides no redundancy. If the single instance fails, the application becomes unavailable. B - Backup-based disaster recovery does not provide real-time fault tolerance. It introduces downtime during recovery and does not meet the reliability requirement. C - Launching two EC2 instances in separate Availability Zones (AZs) provides high availability. If one AZ experiences an outage, the application remains accessible on the instance in the other AZ. D - "Changes to the application designs cannot be made."
LeonSauveterre
👍 1
I copied this about option A. It's got some valid points, but just for your references. An Application Load Balancer is also not the best fit for all legacy applications, as it operates at the application layer (of 7-layer model) and requires HTTP/HTTPS traffic. So for protocols like FTP, SMTP or other TCP-based customized protocols, an ALB would be unsuitable.
JA2018
👍 2
Selected: C
I will choose Option C for the following reasons: #1 AMI creation: Creating an AMI of each application instance allows for easy replication. #2 Multiple Availability Zones: Launching instances in different Availability Zones provides redundancy in case of regional outages. #3 Network Load Balancer: A Network Load Balancer distributes traffic across the instances, providing high availability by automatically routing requests to a healthy instance if one fails.
daveya
👍 2
What if application is statefull and there's no backup?
zits88
👍 1
Selected: C
I don't see how people can choose A here when it is talking about reliability and the answer only has a maximum of 1. There's nothing about cost effectiveness so there is no reason this one is better. Definitely C.
Cpso
👍 1
we cant change applicaiton logic to be run 2 instance concurrently.
muhammadahmer36
👍 3
Selected: A
A. Create an Auto Scaling group that has a minimum of one and a maximum of one. Create an Amazon Machine Image (AMI) of each application instance. Use the AMI to create EC2 instances in the Auto Scaling group Configure an Application Load Balancer in front of the Auto Scaling group.
EdricHoang
👍 2
Selected: C
Fault tolerance is not High Availability Answer A is HA design, not Fault tolerance
Cpso
👍 1
exam said we can change application logic. 99.9% of single app usually work strange if you run it 2 process concurrently and random each request to them.
Lin878
👍 3
Selected: A
A makes sense. C is possible but manual intervention.
emakid
👍 4
answer is A. Auto Scaling Group: Explanation: Minimum and Maximum of one instance: Ensures that the instance is always running. If the instance fails, Auto Scaling will automatically replace it with a new one, maintaining high availability. Amazon Machine Image (AMI): Captures the current state of the application instance, ensuring that new instances launched by Auto Scaling will have the same configuration. Application Load Balancer (ALB): Load Balancer: Distributes traffic to the instances in the Auto Scaling group, ensuring fault tolerance. Even though there is only one instance, the ALB can help manage incoming traffic and be ready for future scaling if needed. For C: While this provides high availability, it does not address fault tolerance as effectively as the Auto Scaling group approach. Without Auto Scaling, if an instance fails, manual intervention is required to launch new instances.
24b2e9e
👍 3
A makes sense
Nm55569
👍 3
Selected: A
It's either A or B but A is a better option. The application design cannot be changed so we don't know if it can run across 2 servers.
Scheldon
👍 1
Selected: A
Answer A It is possible to set Min and Max to 1 which will automatically bring up server when it will crash. Taking into consideration that we cannot change application design and load-balancing between regions would probably need that (no information if applications are statefull or stateless) i would go for solution in answer A https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html
Vasiliy
👍 14
Selected: A
Autoscaling with max=1 is what is needed to keep only one instance at a time - it will still fail, but it will spawn exactly one instance in case of failure (we are not allowed to change the design of the app) Having single instances in different AZ will not help - if one of the AZs is down, the app will still be affected
sandordini
👍 12
Selected: C
NOT A: Autoscaling with Maximum of 1 EC2 :D NOT B: Hourly backup... RPO 1hr C: AMI, Multi-AZ -> Fault tolerant NOT D: ECS with Fargate, but it needs to run on EC2..
Scheldon
👍 6
You cannot change application and based on the story in the past there was only one server/copy of application running at the same time. So we cannot run more then one copy of any application at once. It is possible to set Min and Max to 1 which will automatically bring up server when it will crash. Taking into consideration that we cannot change application design and load-balancing between regions would probably need that (no information if applications are statefull or stateless) i would go for solution in answer A
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
C is the only option that creates redundant live copies of each unmodified legacy server. Creating an AMI preserves the existing server configuration, and launching two EC2 instances from that AMI in separate Availability Zones means an AZ failure does not take down the application. A Network Load Balancer provides Layer 4 traffic distribution and health checks, which suits legacy workloads that may not be HTTP/HTTPS aware. Because no application redesign is required, this satisfies both reliability and fault tolerance without violating the constraint.Why the Other Options Are Wrong
A uses an Auto Scaling group with minimum 1 and maximum 1, so it maintains only a single running instance; Auto Scaling can replace a failed instance, but that is recovery with a gap, not fault tolerance. B relies on hourly AWS Backup and restore, which leaves an RPO of up to an hour and a lengthy RTO, so the application is unavailable during recovery. D uses Migration Hub Refactor Spaces and ECS/Fargate, which requires breaking the application into components and changing its design; the question also states the applications will run on EC2 instances. Thus A, B, and D either lack concurrent redundancy or violate the no-redesign constraint.Community Comment Notes
Vasiliy argued for A on the idea that max=1 Auto Scaling replaces a failed instance, but that still leaves only one live copy at a time. sandordini's comment, including the fragment "Hourly backup... RPO 1hr", correctly rejects B because backup restore is not fault tolerance. LeonSauveterre and JA2018 both favored C for the AMI plus multi-AZ redundancy and load-balancer availability, which aligns with the requirement.Official Reference
Exam Strategy
Look for the phrase fault tolerant and ask whether the option keeps a second live copy during a failure. If an option only restarts or restores after failure, such as max=1 Auto Scaling or AWS Backup, it is not fault tolerant.
Frequently Asked Questions
Why is Auto Scaling with min=1 and max=1 not fault tolerant for these legacy apps?
It keeps only one running instance at a time, so a failure causes a replacement gap and no concurrent capacity in another AZ. Fault tolerance needs a second live copy.
Why use a Network Load Balancer instead of an Application Load Balancer for the cloned EC2 servers?
NLB is Layer 4 and handles arbitrary TCP/UDP legacy workloads, while ALB is HTTP/HTTPS-specific and may not fit unmodified applications.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →