High Availability practice questions

A high-frequency trading analytics service runs on several EC2 instances in the same Availability Zone. The application exchanges small messages between nodes and is sensitive to microsecond-level network latency. Which design best meets the requirement?

Trap 1: Place the instances in a spread placement group across multiple…

Spread placement groups are designed to reduce correlated failure risk by separating instances, not to minimize communication latency. Spreading instances across multiple AZs adds network distance and is the opposite of what a latency-sensitive clustered workload wants. The design improves resilience, but it sacrifices the fast intra-node communication the application needs.

Trap 2: Place the instances in a partition placement group within one…

Partition placement groups are useful when you want to isolate groups of instances from each other for resilience at large scale. They do not provide the same tight network proximity as a cluster placement group. For a low-latency analytics cluster, partitioning adds unnecessary separation and is not the best choice for fast node-to-node messaging.

Trap 3: Deploy the instances behind an Application Load Balancer in…

An Application Load Balancer helps distribute client traffic for HTTP and HTTPS applications, but it does not optimize the private network path between EC2 instances. Adding multiple Availability Zones also increases the distance between nodes. That helps availability, but it does not address the workload's requirement for very low inter-instance latency.

A
Place the instances in a cluster placement group in one Availability Zone.
A cluster placement group places instances physically close together within one Availability Zone, which improves network throughput and reduces latency between nodes. That is the right fit for tightly coupled workloads that exchange frequent small messages and need the lowest possible east-west latency. It also keeps the design simple because the application already runs in a single AZ.
B
Place the instances in a spread placement group across multiple Availability Zones.
Why wrong: Spread placement groups are designed to reduce correlated failure risk by separating instances, not to minimize communication latency. Spreading instances across multiple AZs adds network distance and is the opposite of what a latency-sensitive clustered workload wants. The design improves resilience, but it sacrifices the fast intra-node communication the application needs.
C
Place the instances in a partition placement group within one Availability Zone.
Why wrong: Partition placement groups are useful when you want to isolate groups of instances from each other for resilience at large scale. They do not provide the same tight network proximity as a cluster placement group. For a low-latency analytics cluster, partitioning adds unnecessary separation and is not the best choice for fast node-to-node messaging.
D
Deploy the instances behind an Application Load Balancer in multiple Availability Zones.
Why wrong: An Application Load Balancer helps distribute client traffic for HTTP and HTTPS applications, but it does not optimize the private network path between EC2 instances. Adding multiple Availability Zones also increases the distance between nodes. That helps availability, but it does not address the workload's requirement for very low inter-instance latency.

Question 2hardmultiple choice

Based on the exhibit, what change should the team make to achieve the lowest possible network latency for the distributed workload?

Exhibit

Current deployment summary:
- 48 EC2 instances run a tightly coupled simulation engine.
- Instances are spread across us-east-1a and us-east-1b.
- Each worker exchanges small TCP messages every 5-10 ms with all other workers.
- Measured east-west RTT: 4.9 ms average, 17.2 ms p95.
- The application owner states that the workload can run in a single Availability Zone if that improves performance.
- No external clients access the cluster directly.

Trap 1: Place the instances in a spread placement group across multiple…

Spread placement groups are designed to reduce correlated failure risk, not to minimize latency between tightly coupled nodes. Spreading instances across Availability Zones also adds network distance and does not improve east-west communication. This would make the cluster more resilient in some cases, but it works against the stated performance goal.

Trap 2: Add an Application Load Balancer in front of the workers to reduce…

An Application Load Balancer helps distribute client traffic to application targets, but it does not reduce latency between worker nodes that are already talking to each other directly. It would introduce another hop for incoming traffic and does nothing to change physical placement of the instances.

Trap 3: Increase the EC2 instance size while keeping the current multi-AZ…

Larger instances may improve CPU or memory headroom, but they do not solve the core issue shown in the exhibit: network latency between workers. The RTT problem is caused by placement and topology, not lack of compute capacity. Keeping the current AZ spread preserves the latency penalty.

A
Place the instances in a spread placement group across multiple Availability Zones.
Why wrong: Spread placement groups are designed to reduce correlated failure risk, not to minimize latency between tightly coupled nodes. Spreading instances across Availability Zones also adds network distance and does not improve east-west communication. This would make the cluster more resilient in some cases, but it works against the stated performance goal.
B
Move the workload into a cluster placement group in one Availability Zone.
Cluster placement groups place instances physically close together inside one Availability Zone, which is the best AWS option for workloads that need low-latency, high-bandwidth communication between many nodes. The exhibit explicitly says the workload can run in a single AZ if performance improves. That makes cluster placement groups the right fit.
C
Add an Application Load Balancer in front of the workers to reduce inter-node latency.
Why wrong: An Application Load Balancer helps distribute client traffic to application targets, but it does not reduce latency between worker nodes that are already talking to each other directly. It would introduce another hop for incoming traffic and does nothing to change physical placement of the instances.
D
Increase the EC2 instance size while keeping the current multi-AZ layout.
Why wrong: Larger instances may improve CPU or memory headroom, but they do not solve the core issue shown in the exhibit: network latency between workers. The RTT problem is caused by placement and topology, not lack of compute capacity. Keeping the current AZ spread preserves the latency penalty.

Question 3mediummulti select

A solutions architect is designing a highly available and resilient architecture for a critical internal application that processes financial transactions. The application runs on Amazon EC2 instances inside an Auto Scaling group. The database layer uses an Amazon Aurora MySQL cluster. The company requires that if an entire AWS Availability Zone (AZ) fails, the application must remain operational with minimal impact and automatically recover without manual intervention. Which combination of architectural decisions will meet these requirements? (Choose four.)

Trap 1: Deploy the Aurora cluster with a single DB instance to reduce…

Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.

Trap 2: Place the EC2 instances in a single Availability Zone to ensure…

Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.

A
Configure the Auto Scaling group to span at least three Availability Zones in the same AWS Region.
This is a fundamental best practice for high availability and resilience. By distributing EC2 instances across at least three Availability Zones (AZs), the application can withstand an outage in a single AZ without experiencing downtime. Auto Scaling groups automatically launch new instances in healthy AZs if one fails, ensuring continuous application availability and fault tolerance.
B
Deploy the Aurora cluster with a single DB instance to reduce complexity and cost.
Why wrong: Deploying an Aurora cluster with only a single DB instance, even if it's the primary writer, significantly compromises high availability. If that single instance or its underlying Availability Zone experiences an outage, the database will become unavailable, leading to application downtime. While it might reduce immediate cost, it fails to meet the requirement for a highly available and resilient architecture.
C
Configure the Aurora cluster to include at least one Aurora Replica in a different Availability Zone than the primary instance.
This configuration is crucial for database resilience and high availability. An Aurora Replica in a different Availability Zone acts as a failover target, allowing Aurora to automatically promote the replica to primary in case of an outage affecting the original primary instance or its AZ. This multi-AZ deployment minimizes downtime and ensures continuous database operations.
D
Use an Application Load Balancer (ALB) to distribute traffic across EC2 instances in multiple Availability Zones.
An Application Load Balancer (ALB) is essential for distributing incoming application traffic efficiently and for enhancing resilience. By automatically routing requests to healthy EC2 instances across multiple Availability Zones, the ALB ensures that no single instance becomes a bottleneck and that the application remains available even if instances or an entire AZ fail. This provides fault tolerance and improves overall application responsiveness.
E
Place the EC2 instances in a single Availability Zone to ensure data locality with the primary database.
Why wrong: Placing all EC2 instances in a single Availability Zone creates a single point of failure, directly contradicting the goal of a highly available and resilient architecture. While it might offer marginal latency benefits for data locality, the risk of a complete application outage if that specific AZ experiences an issue far outweighs any perceived advantage. High availability mandates distribution across multiple AZs.
F
Set up an Amazon RDS Proxy to manage database connections and provide connection pooling for improved resilience.
Amazon RDS Proxy enhances application resilience by managing and pooling database connections, reducing the overhead on the database instance. In the event of a database failover, RDS Proxy automatically routes connections to the new primary instance, minimizing application disruption and transparently handling connection management. This improves fault tolerance and application stability during database events.

Question 4hardmulti select

Multiple EC2 instances in different Availability Zones need concurrent read/write access to the same shared files. The files are actively modified by several application servers, and low-latency metadata operations matter more than extremely high aggregate throughput. Which two changes should the team make? Select two.

Trap 1: Use a single EBS Multi-Attach volume mounted read/write by all…

EBS Multi-Attach is not a general-purpose multi-AZ shared filesystem for application servers. It has service limitations and is not the correct service for many instances requiring concurrent shared file access across AZs. EFS is the AWS-managed option designed for this use case.

Trap 2: Store the files in S3 and mount them directly through the console…

S3 is object storage, not a native shared filesystem with standard POSIX semantics. It does not provide the same low-latency metadata behavior or filesystem-level concurrent read/write model that application servers expect. This option does not satisfy the workload requirements.

Trap 3: Place the files on instance store volumes so each server has faster…

Instance store is local to a single EC2 instance and is ephemeral. That means each server would have its own isolated copy of the data, which breaks the requirement for a shared filesystem across multiple instances. It also risks data loss if an instance stops or terminates.

A
Use Amazon EFS instead of EBS or S3 for the shared file system.
Amazon EFS is the managed AWS file service built for shared POSIX-style file access from multiple instances. It supports concurrent read/write access from many EC2 hosts and is a better fit than EBS, which is attached to a single instance, or S3, which provides object storage rather than a native shared filesystem. For an application that expects standard filesystem semantics, EFS is the correct storage layer.
B
Create EFS mount targets in every Availability Zone that hosts application instances.
Mount targets in each active Availability Zone provide local network entry points to the file system for instances in that AZ. This improves availability and avoids unnecessary cross-AZ traffic for file access. In a multi-AZ application, placing mount targets wherever the workload runs is the standard design for efficient and resilient EFS connectivity.
C
Use a single EBS Multi-Attach volume mounted read/write by all instances across AZs.
Why wrong: EBS Multi-Attach is not a general-purpose multi-AZ shared filesystem for application servers. It has service limitations and is not the correct service for many instances requiring concurrent shared file access across AZs. EFS is the AWS-managed option designed for this use case.
D
Store the files in S3 and mount them directly through the console as a shared network filesystem.
Why wrong: S3 is object storage, not a native shared filesystem with standard POSIX semantics. It does not provide the same low-latency metadata behavior or filesystem-level concurrent read/write model that application servers expect. This option does not satisfy the workload requirements.
E
Place the files on instance store volumes so each server has faster local access.
Why wrong: Instance store is local to a single EC2 instance and is ephemeral. That means each server would have its own isolated copy of the data, which breaks the requirement for a shared filesystem across multiple instances. It also risks data loss if an instance stops or terminates.

Question 5easymultiple choice

A inventory service exposes a static website from S3 and CloudFront. Users should still receive cached pages if the S3 origin has a short outage. Which feature helps most? The architecture review board prefers a managed AWS-native control.

Trap 1: AWS Backup Vault Lock

Backup Vault Lock protects backups, not CloudFront delivery.

Trap 2: IAM Access Analyzer

Access Analyzer reviews permissions and does not serve cached content.

Trap 3: S3 Select

S3 Select retrieves subsets of object data and does not increase origin outage tolerance.

A
CloudFront caching with appropriate TTLs
CloudFront can serve cached content from edge locations when the origin is temporarily unavailable.
B
AWS Backup Vault Lock
Why wrong: Backup Vault Lock protects backups, not CloudFront delivery.
C
IAM Access Analyzer
Why wrong: Access Analyzer reviews permissions and does not serve cached content.
D
S3 Select
Why wrong: S3 Select retrieves subsets of object data and does not increase origin outage tolerance.

Question 6mediummultiple choice

A claims workflow uses an RDS MySQL database and must remain available during an Availability Zone failure with minimal application changes. What should the architect enable?

Trap 1: S3 Cross-Region Replication

S3 CRR applies to S3 objects, not RDS failover.

Trap 2: EBS snapshots every hour

Snapshots help recovery but do not provide automatic high availability.

Trap 3: Read replicas only

Read replicas improve read scalability and can support DR, but they are not the primary automatic AZ failover feature.

A
S3 Cross-Region Replication
Why wrong: S3 CRR applies to S3 objects, not RDS failover.
B
Multi-AZ deployment for the RDS DB instance
Multi-AZ provides synchronous standby replication and automatic failover within a Region.
C
EBS snapshots every hour
Why wrong: Snapshots help recovery but do not provide automatic high availability.
D
Read replicas only
Why wrong: Read replicas improve read scalability and can support DR, but they are not the primary automatic AZ failover feature.

Question 7easymultiple choice

Based on the exhibit, the database must fail over automatically if the primary Availability Zone goes down. Which solution should the architect choose?

Exhibit

Amazon RDS configuration:
- Engine: MySQL
- Deployment: Single-AZ
- Backup retention: 7 days
- Application connection string: db-prod.cluster-abcdefghijkl.us-east-1.rds.amazonaws.com

Operations note:
- During maintenance, the database endpoint stayed reachable only after a manual restore from snapshot.

Trap 1: Create a read replica in the same Availability Zone as the primary…

A read replica helps with read scaling and some recovery scenarios, but it does not provide automatic failover like a Multi-AZ deployment.

Trap 2: Increase the backup retention period to 35 days.

Longer backups improve recovery options, but they do not provide automatic failover during an outage. Backups are still a restore-based process.

Trap 3: Move the database to an EC2 instance with an attached EBS volume.

Running the database on EC2 adds operational burden and usually reduces managed failover capability compared with RDS Multi-AZ.

A
Create a read replica in the same Availability Zone as the primary database.
Why wrong: A read replica helps with read scaling and some recovery scenarios, but it does not provide automatic failover like a Multi-AZ deployment.
B
Convert the database to a Multi-AZ RDS deployment.
A Multi-AZ RDS deployment keeps a synchronous standby in another Availability Zone and automatically fails over when the primary fails. This matches the requirement for minimal manual intervention and preserves the same database endpoint, so the application does not need connection string changes. It is the standard AWS choice for resilient relational databases.
C
Increase the backup retention period to 35 days.
Why wrong: Longer backups improve recovery options, but they do not provide automatic failover during an outage. Backups are still a restore-based process.
D
Move the database to an EC2 instance with an attached EBS volume.
Why wrong: Running the database on EC2 adds operational burden and usually reduces managed failover capability compared with RDS Multi-AZ.

Question 8hardmulti select

A distributed analytics engine runs 12 EC2 instances in one Availability Zone. The nodes exchange thousands of tiny messages per second and must keep jitter as low as possible. The current design launches the instances across multiple placement groups and uses general-purpose burstable instances. Which two changes will most directly lower east-west network latency and variability? Select two.

Trap 1: Spread the instances across three Availability Zones for better…

Spreading across AZs improves resilience, but it increases network distance and typically adds latency. The scenario is explicitly about minimizing jitter and latency for frequent east-west traffic within one AZ, so multi-AZ spread is the wrong optimization.

Trap 2: Front the nodes with an Application Load Balancer to balance the…

An ALB is for HTTP/HTTPS application traffic, not for direct node-to-node messaging performance. It adds a layer that does not solve the underlying east-west latency issue. The workload needs closer physical placement and better networking, not a web load balancer.

Trap 3: Store the messages on EBS volumes so the nodes avoid network…

EBS is block storage for persistent data, not a low-latency message bus. Writing messages to disk would add storage latency and does not create efficient inter-node communication. It also changes the workload architecture in an unsupported way for this requirement.

A
Move all instances into a cluster placement group.
Cluster placement groups pack instances closely together in a single Availability Zone, which minimizes network distance and improves latency consistency. This is the best placement strategy when the workload is highly chatty and needs very low jitter between nodes. It directly targets east-west performance.
B
Use instance families that provide high network bandwidth and support enhanced networking.
Instance selection matters because network bandwidth and packet processing capability affect latency under heavy inter-node messaging. Choosing network-optimized or otherwise high-bandwidth families with enhanced networking reduces contention and improves message throughput. This complements the placement group choice and improves the cluster’s overall behavior.
C
Spread the instances across three Availability Zones for better fault tolerance.
Why wrong: Spreading across AZs improves resilience, but it increases network distance and typically adds latency. The scenario is explicitly about minimizing jitter and latency for frequent east-west traffic within one AZ, so multi-AZ spread is the wrong optimization.
D
Front the nodes with an Application Load Balancer to balance the internal messages.
Why wrong: An ALB is for HTTP/HTTPS application traffic, not for direct node-to-node messaging performance. It adds a layer that does not solve the underlying east-west latency issue. The workload needs closer physical placement and better networking, not a web load balancer.
E
Store the messages on EBS volumes so the nodes avoid network communication.
Why wrong: EBS is block storage for persistent data, not a low-latency message bus. Writing messages to disk would add storage latency and does not create efficient inter-node communication. It also changes the workload architecture in an unsupported way for this requirement.

Question 9easymultiple choice

Based on the exhibit, which AWS feature should the team use to minimize network latency between EC2 instances that exchange messages very frequently?

Exhibit

Application topology:
- 12 EC2 instances in one Region
- Instances process small jobs and send frequent messages to each other
- Observed inter-node latency: 2.8 ms to 4.1 ms
- Requirement: lowest possible latency between application nodes

Trap 1: Use a spread placement group to maximize instance separation across…

Spread placement groups increase isolation, but they do not optimize for the lowest possible latency between instances.

Trap 2: Use a partition placement group to distribute instances across many…

Partition placement groups are better for reducing correlated hardware failures in large distributed systems, not for minimizing latency between tightly coupled nodes.

Trap 3: Use multiple Auto Scaling groups to spread traffic across more…

More Auto Scaling groups do not reduce latency between the existing instances. This is a placement problem, not a scaling problem.

A
Use a spread placement group to maximize instance separation across hardware.
Why wrong: Spread placement groups increase isolation, but they do not optimize for the lowest possible latency between instances.
B
Use a cluster placement group to place instances close together.
A cluster placement group is designed for workloads that need very low network latency and high packet-per-second performance between instances. The exhibit describes frequent small-message traffic and a need for the lowest possible latency, which makes a cluster placement group the right choice. It keeps instances physically close in the AWS network for faster communication.
C
Use a partition placement group to distribute instances across many partitions.
Why wrong: Partition placement groups are better for reducing correlated hardware failures in large distributed systems, not for minimizing latency between tightly coupled nodes.
D
Use multiple Auto Scaling groups to spread traffic across more subnets.
Why wrong: More Auto Scaling groups do not reduce latency between the existing instances. This is a placement problem, not a scaling problem.

Question 10mediummultiple choice

A media processing service runs ECS tasks in multiple Availability Zones. Each task must read and write the same shared filesystem with low latency because tasks stream intermediate artifacts to other tasks. The team currently mounts an EBS volume per task, and cross-AZ tasks frequently cannot see each other’s files. Which option best resolves the shared filesystem requirement while supporting high-performing access?

Trap 1: Keep using EBS, but attach the same EBS volume to tasks in multiple…

EBS volumes are tied to a specific Availability Zone. Even though multi-attach can allow multiple EC2 instances to attach the same EBS volume concurrently (within constraints), it does not create a cross-AZ shared filesystem. Additionally, EBS multi-attach does not provide an NFS-like shared filesystem semantics for concurrent access from tasks as described.

Trap 2: Use Amazon S3 for the intermediate artifacts and rely on S3 event…

S3 is object storage, not a POSIX-style shared filesystem. Even with event notifications, S3 does not provide the same semantics as mounting a directory and performing frequent low-latency reads/writes as tasks stream artifacts to each other.

Trap 3: Switch to instance store on each task and use SQS messages between…

Instance store is ephemeral and not intended for shared, persistent intermediate artifacts across tasks. SQS is a messaging/coordination layer and does not provide filesystem access, so this approach adds copy/serialization overhead and does not meet the shared low-latency filesystem requirement.

A
Keep using EBS, but attach the same EBS volume to tasks in multiple Availability Zones using EBS multi-attach so all tasks share the filesystem.
Why wrong: EBS volumes are tied to a specific Availability Zone. Even though multi-attach can allow multiple EC2 instances to attach the same EBS volume concurrently (within constraints), it does not create a cross-AZ shared filesystem. Additionally, EBS multi-attach does not provide an NFS-like shared filesystem semantics for concurrent access from tasks as described.
B
Use Amazon EFS with mount targets in each Availability Zone so all tasks mount a common NFS filesystem over the AWS network.
EFS is designed for shared, NFS-like file storage that can be mounted concurrently from compute resources across multiple Availability Zones. By creating mount targets in each AZ used by the ECS tasks, you enable low-latency network access patterns so tasks can read and write the same shared filesystem reliably.
C
Use Amazon S3 for the intermediate artifacts and rely on S3 event notifications to emulate POSIX file operations.
Why wrong: S3 is object storage, not a POSIX-style shared filesystem. Even with event notifications, S3 does not provide the same semantics as mounting a directory and performing frequent low-latency reads/writes as tasks stream artifacts to each other.
D
Switch to instance store on each task and use SQS messages between tasks to copy intermediate artifacts.
Why wrong: Instance store is ephemeral and not intended for shared, persistent intermediate artifacts across tasks. SQS is a messaging/coordination layer and does not provide filesystem access, so this approach adds copy/serialization overhead and does not meet the shared low-latency filesystem requirement.

Question 11hardmultiple choice

A warehouse integration service must use shared file storage across Linux EC2 instances in multiple Availability Zones. The storage must remain available during an AZ failure. Which service should be used? The design must avoid adding custom operational scripts.

Trap 1: S3 mounted as a POSIX file system without a file gateway

S3 is object storage and does not provide native POSIX shared file semantics.

Trap 2: Instance store volumes

Instance store is ephemeral and tied to a single instance.

Trap 3: An EBS volume attached to all instances

A standard EBS volume is zonal and cannot be attached broadly as shared file storage.

A
Amazon EFS with mount targets in multiple Availability Zones
EFS is regional file storage and supports mount targets across AZs.
B
S3 mounted as a POSIX file system without a file gateway
Why wrong: S3 is object storage and does not provide native POSIX shared file semantics.
C
Instance store volumes
Why wrong: Instance store is ephemeral and tied to a single instance.
D
An EBS volume attached to all instances
Why wrong: A standard EBS volume is zonal and cannot be attached broadly as shared file storage.

Question 12mediummulti select

A company is running a production web application on Amazon EC2 instances behind an Application Load Balancer (ALB). The workload has predictable traffic spikes during business hours and low traffic at night. The current architecture uses On-Demand EC2 instances, leading to high costs. The company wants to reduce costs without sacrificing availability or performance. Which three of the following strategies would help achieve this goal? (Choose three.)

Question 13easymultiple choice

A team runs an Amazon NLB in a VPC with targets registered in multiple Availability Zones (AZs). Their bill shows high inter-AZ data transfer charges. They want to reduce unnecessary cross-AZ traffic costs while still maintaining healthy targets per AZ. What change is most likely to reduce inter-AZ charges?

Trap 1: Enable cross-zone load balancing so all targets receive traffic…

Enabling cross-zone generally increases cross-AZ traffic and can raise inter-AZ transfer costs.

Trap 2: Move the NLB to a different Region so traffic is always kept local.

Changing Region does not eliminate inter-AZ traffic within the new Region and can add Region transfer costs.

Trap 3: Replace the NLB with a NAT gateway to reduce data charges between…

NAT gateways affect egress to the internet; they do not control inter-AZ routing for load balancer traffic.

A
Disable cross-zone load balancing on the NLB so each client is routed to targets in the same AZ when possible.
Disabling cross-zone load balancing helps keep traffic within the same AZ, reducing inter-AZ data transfer charges.
B
Enable cross-zone load balancing so all targets receive traffic from every AZ.
Why wrong: Enabling cross-zone generally increases cross-AZ traffic and can raise inter-AZ transfer costs.
C
Move the NLB to a different Region so traffic is always kept local.
Why wrong: Changing Region does not eliminate inter-AZ traffic within the new Region and can add Region transfer costs.
D
Replace the NLB with a NAT gateway to reduce data charges between AZs.
Why wrong: NAT gateways affect egress to the internet; they do not control inter-AZ routing for load balancer traffic.

Question 14mediummatching

A team wants a web application to keep serving traffic if one Availability Zone fails. Match each architecture element to the resilience behavior it provides.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Stop sending requests to unhealthy targets and keep only healthy instances in rotation.

Launch replacement instances in healthy AZs when capacity is lost.

Maintain a synchronous standby in another AZ and fail over automatically.

Allow instances to be replaced without losing user sessions that are stored elsewhere.

Trap 1: Amazon S3: Automatically fails over to a secondary region in case…

Amazon S3 is an object storage service designed for 99.999999999% (11 nines) durability and high availability by storing data redundantly across multiple devices in a minimum of three Availability Zones within a single AWS Region. Therefore, an individual Availability Zone failure does not impact S3's availability or durability. S3 does not automatically fail over to a secondary region in response to an AZ failure; cross-region replication is a separate configuration for disaster recovery, not automatic AZ failover.

Trap 2: AWS CloudFormation: Distributes application load across multiple…

AWS CloudFormation is an Infrastructure as Code (IaC) service that allows users to define and provision AWS infrastructure resources in a declarative way using templates. Its primary function is to automate the deployment and management of resources, such as EC2 instances, databases, and networks. CloudFormation itself does not actively distribute application load or manage traffic across Availability Zones; it merely provisions the resources that perform these functions.

A
Elastic Load Balancer: Distributes incoming traffic across multiple targets in multiple Availability Zones
An Elastic Load Balancer (ELB) is crucial for high availability by distributing incoming application traffic across multiple EC2 instances, containers, or IP addresses. It operates across multiple Availability Zones (AZs) within a region, automatically routing requests only to healthy targets. If an instance or an entire AZ becomes unhealthy, the ELB stops sending traffic to it, ensuring the web application remains accessible to users.
B
Auto Scaling Group: Automatically replaces unhealthy instances and maintains desired capacity across Availability Zones
An Auto Scaling Group (ASG) enhances web application resilience by automatically replacing unhealthy EC2 instances, detected via health checks, and launching new ones. It ensures that the desired number of instances is maintained across specified Availability Zones. If an AZ experiences an outage, the ASG can launch new instances in healthy AZs to compensate, thereby maintaining application capacity and availability.
C
Amazon RDS Multi-AZ: Provides automatic failover to a standby database instance in a different Availability Zone
Amazon RDS Multi-AZ deployments provide high availability and durability for relational databases by synchronously replicating data to a standby instance in a different Availability Zone. In the event of an infrastructure failure, such as an AZ outage or primary database instance failure, RDS automatically fails over to the standby. This process ensures minimal downtime and continuous database operations for the web application.
D
Amazon Route 53: Routes end users to healthy endpoints using DNS health checks and failover
Amazon Route 53, as a highly available and scalable cloud DNS web service, contributes to application resilience by routing end-user requests to healthy endpoints. It uses DNS health checks to monitor the health of resources, such as ELBs or EC2 instances, across different Availability Zones. If an endpoint becomes unhealthy, Route 53 can automatically reroute traffic to a healthy alternative using failover routing policies, ensuring continuous service.
E
Amazon S3: Automatically fails over to a secondary region in case of an Availability Zone failure
Why wrong: Amazon S3 is an object storage service designed for 99.999999999% (11 nines) durability and high availability by storing data redundantly across multiple devices in a minimum of three Availability Zones within a single AWS Region. Therefore, an individual Availability Zone failure does not impact S3's availability or durability. S3 does not automatically fail over to a secondary region in response to an AZ failure; cross-region replication is a separate configuration for disaster recovery, not automatic AZ failover.
F
AWS CloudFormation: Distributes application load across multiple Availability Zones
Why wrong: AWS CloudFormation is an Infrastructure as Code (IaC) service that allows users to define and provision AWS infrastructure resources in a declarative way using templates. Its primary function is to automate the deployment and management of resources, such as EC2 instances, databases, and networks. CloudFormation itself does not actively distribute application load or manage traffic across Availability Zones; it merely provisions the resources that perform these functions.