High Availability practice questions

Manually add more Aurora Replicas during peak hours.

Why it fails: Manual intervention is inefficient and prone to human error, often resulting in delayed responses to traffic spikes. While adding replicas increases read capacity, doing so manually does not provide the elasticity required for unpredictable workloads. This approach leads to either performance bottlenecks during sudden surges or wasted costs when traffic levels drop.

Increase the instance size of the primary Aurora instance.

Why it fails: Scaling up the primary instance increases the overall cost and may cause downtime during the modification process. While a larger instance provides more resources, it does not specifically address the need for distributed read capacity. Using multiple read replicas is a more effective strategy for handling high-volume read traffic than vertical scaling alone.

Use Amazon SQS to buffer incoming read requests.

Why it fails: Amazon SQS is a message queuing service intended for asynchronous processing and decoupling components, not for caching or buffering synchronous database read requests. Implementing SQS for read traffic would introduce significant latency and architectural complexity. It is not a suitable solution for improving the performance of a real-time, read-heavy relational database application.

Use EBS Snapshots to back up the database every 5 minutes.

Why it fails: While snapshots are important for disaster recovery, they do not provide high availability or low-latency reads. Restoring from a snapshot is a manual process that takes time, and taking snapshots every 5 minutes would create significant performance overhead on the database. It is not a replacement for the automated failover provided by Multi-AZ.

Enable Enhanced Monitoring with a 1-second granularity.

Why it fails: Enhanced Monitoring provides detailed metrics about the OS and processes running on the RDS instance. While helpful for troubleshooting performance issues, it does not contribute to the resilience of the database or provide any mechanisms for surviving an Availability Zone failure. It is a monitoring tool rather than an architectural availability feature.

Implement a Network Load Balancer in front of the RDS instance.

Why it fails: Network Load Balancers are used to distribute traffic to EC2 instances or IP addresses, but they are not typically used in front of Amazon RDS. RDS handles its own DNS-based failover for Multi-AZ. Adding an NLB would introduce unnecessary complexity and is not a standard or recommended practice for managing RDS database connections.

Configure Amazon S3 Intelligent-Tiering to automatically move infrequently accessed video assets to lower-cost storage tiers.

Why it fails: S3 Intelligent-Tiering optimizes storage costs by moving objects between access tiers based on access patterns, but it does not provide data protection mechanisms against accidental deletion, malicious overwrites, or complete regional service interruptions.

Attach a resource-based bucket policy that explicitly denies all delete object requests from any IAM user except the root account.

Why it fails: Denying delete requests via bucket policy prevents standard data maintenance and lifecycle operations, and relying solely on root account privileges violates AWS security best practices regarding least privilege access control for daily operational tasks.

Enable S3 Object Lock in governance mode with a fixed retention period of 30 days for all uploaded video files.

Why it fails: S3 Object Lock governance mode prevents users from changing or deleting object versions, but it can be bypassed by users with specific administrative permissions unless compliance mode is used, and it does not provide multi-region disaster recovery capabilities.

Deploy all tiers in a single public subnet in one AZ.

Why it fails: Deploying all tiers in a single subnet and AZ creates a single point of failure and exposes every component to the internet. This violates basic security and resiliency principles, as a single failure or a compromised web server could easily expose the entire application stack to external threats.

Put everything in a public subnet and use Security Groups for isolation.

Why it fails: While Security Groups provide firewalling, the network architecture is still vulnerable to single-AZ failure. Furthermore, public subnets are inherently less secure than private subnets. Best practices dictate using subnets as a primary boundary for isolation and distributing resources across multiple AZs for high availability and resilience.

Use a single private subnet for both tiers and a NAT Gateway in the same subnet.

Why it fails: A single private subnet lacks AZ redundancy. If that AZ goes down, the entire application fails. Additionally, placing both tiers in the same subnet prevents proper architectural separation, meaning that a breach in the web tier could easily propagate to the application tier, lacking adequate layered defense-in-depth.

Scale up the primary RDS instance to a larger instance class with more RAM.

Why it fails: Scaling up the primary instance is a vertical scaling strategy that increases the cost of the entire database 24/7. Since the write activity is low, paying for a larger instance just to handle peak read traffic is inefficient compared to using Read Replicas, which can be scaled more granularly.

Switch the database to Amazon RDS for SQL Server to take advantage of License Inclusion.

Why it fails: Switching to SQL Server from MySQL would likely increase costs due to licensing fees and architectural changes. MySQL is an open-source engine with no licensing costs. Moving to a commercial engine would be counterproductive for a project specifically focused on reducing the overall cost of the database layer.

Enable Multi-AZ for all Read Replicas to ensure high availability.

Why it fails: Enabling Multi-AZ on Read Replicas doubles the cost of each replica because AWS provisions a standby instance. While this improves availability, it is often unnecessary for read-only traffic that can be rerouted if a replica fails, making it a poor choice for a strategy focused strictly on cost reduction.

Configure the Application Load Balancer to use stickiness with a duration-based cookie.

Why it fails: Duration-based cookies rely on the specific instance remaining healthy. If the instance is terminated by the Auto Scaling group during a scale-in event, the session data stored in memory is permanently lost, and the user will be forced to re-authenticate, providing no true state protection.

Store the session state in an Amazon S3 bucket with versioning enabled.

Why it fails: Amazon S3 is designed for object storage and introduces significant latency for session-based read/write operations compared to in-memory stores. Using S3 for high-frequency session updates is inefficient and performance-prohibitive for web applications requiring low-latency access to user state information.

Replicate the session data across all EC2 instances using a broadcast script.

Why it fails: Broadcasting session data across instances creates a synchronization bottleneck and increases network overhead significantly. This approach is not scalable, prone to race conditions, and does not handle the dynamic nature of an Auto Scaling group effectively as new instances would require full state replication.

Configure the Application Load Balancer to use source IP stickiness.

Why it fails: Source IP stickiness ties a client to a specific backend instance. If that instance fails or the Auto Scaling group terminates it, the session state is lost. This approach creates a dependency on individual instance health, violating the principle of designing stateless, resilient application tiers.

Use Amazon EBS multi-attach to share session files across instances.

Why it fails: EBS volumes can only be attached to instances within the same Availability Zone. If the AZ fails, the data becomes inaccessible, creating a single point of failure. Furthermore, file-based locking mechanisms are inefficient and prone to corruption in high-concurrency environments compared to dedicated caching services.

Replicate session files using a cron job across all web instances.

Why it fails: Replicating files via cron jobs introduces significant latency and synchronization challenges. As the number of instances grows, the overhead of maintaining consistency becomes unmanageable and error-prone. This design lacks the robustness and sub-millisecond performance required for modern, scalable, and resilient cloud-native web applications.

Configure RDS Read Replicas and manually promote them during an outage.

Why it fails: Read Replicas are designed for scaling read traffic rather than providing high availability. Promoting a replica manually requires human intervention and configuration changes, which increases the recovery time objective. Additionally, because replication is asynchronous, there is a risk of data loss if the primary instance fails before data is synchronized to the replica.

Deploy a Single-AZ RDS instance and use AWS Backup for hourly snapshots.

Why it fails: Single-AZ deployments are susceptible to outages if the specific Availability Zone fails. While snapshots provide a way to restore data, the restoration process is manual and time-consuming, leading to high downtime. This approach does not meet the requirement for automatic failover and high availability during maintenance or infrastructure failures.

Host a MySQL database on an Amazon EC2 instance with an EBS volume.

Why it fails: Running a database on a single EC2 instance introduces a single point of failure. Achieving high availability would require the architect to manually configure complex clustering software, replication, and failover scripts. This approach represents a high operational burden and does not leverage the managed high availability features provided by Amazon RDS.

Support for multi-threaded execution.

Why it fails: Redis is primarily a single-threaded engine for command execution, although recent versions have introduced some background threading for I/O. Memcached is typically the choice for multi-threaded performance, but it lacks the complex data structures and high availability features like Multi-AZ and replication required in this scenario.

Automatic data compression at the cache level.

Why it fails: Amazon ElastiCache does not provide native automatic data compression at the service level. Compression is typically handled by the application code before the data is sent to the cache. Relying on the cache for compression would introduce unnecessary latency and CPU overhead on the cache nodes.

Use of UDP protocol for low-latency writes.

Why it fails: Redis uses the TCP protocol to ensure reliable delivery of data and commands. While UDP can be faster in some networking contexts, it is not supported by ElastiCache for Redis because reliability and data integrity are paramount for a persistent data store and caching engine.

Deploy all EC2 instances in a single Availability Zone and configure an AWS Auto Scaling group with a maximum capacity of one.

Why it fails: Placing all instances inside a single Availability Zone creates a single point of failure. If that specific data center experiences a power outage or hardware failure, the entire application becomes completely inaccessible, violating basic resilience principles.

Provision EC2 instances in multiple AWS Regions and use Route 53 with a latency routing policy.

Why it fails: Multi-Region deployment with Route 53 latency routing does not keep the Application Load Balancer serving through an Availability Zone outage, since each Region's load balancer still spans its own zones and failover is DNS-based. It is tempting because Regions do survive wider failures, but the requirement is AZ-level resilience.

Use a single EC2 instance of a larger size to handle peak traffic loads without scaling.

Why it fails: A single larger instance still runs in one Availability Zone, so an AZ outage takes the application offline entirely and the load balancer has no healthy target. It is tempting because vertical scaling avoids the operational work of distributing instances, but it provides no redundancy across zones.

Configure a Read Replica in the same Availability Zone.

Why it fails: Placing a Read Replica in the same Availability Zone as the primary database does not improve resilience against AZ-level failures. For true disaster recovery and high availability, read replicas should be placed in different Availability Zones or even different AWS Regions to survive localized physical infrastructure outages or network issues.

Set the storage type to General Purpose SSD (gp2) only.

Why it fails: The storage type choice (gp2, gp3, or io1) affects performance and throughput but does not inherently provide high availability or durability. While SSDs offer better performance than magnetic storage, they do not replicate data across zones or prevent database downtime in the event of an infrastructure failure or primary node crash.

Disable the deletion protection feature for all instances.

Why it fails: Disabling deletion protection increases the risk of accidental resource termination, which is the opposite of a resilient architecture. Deletion protection should be enabled for production databases to prevent human error from resulting in data loss, as it requires an additional step to modify the instance before it can be deleted.

Store application state files on a single Amazon EBS General Purpose SSD attached to the primary EC2 instance.

Why it fails: Amazon EBS volumes are tied to a specific Availability Zone and cannot span multiple zones natively. Relying on a single EBS volume creates a single point of failure that will cause data loss or downtime if that Availability Zone experiences an outage.

Configure an Amazon Route 53 latency-based routing policy to direct user traffic directly to EC2 instances in each zone.

Why it fails: Route 53 latency-based routing optimizes performance globally across regions rather than managing intra-region Availability Zone failover. An Application Load Balancer should be used in front of EC2 instances for localized traffic distribution and health checking.

Pin all payment processing worker threads to a single static EC2 instance to simplify debugging and transaction logging.

Why it fails: Pinning all workload threads to a single EC2 instance eliminates fault tolerance and introduces a severe single point of failure. If that instance or its underlying host fails, the entire payment processing capability will experience an outage.

Configure an Amazon SQS queue in front of the EC2 instances to offload computational tasks asynchronously.

Why it fails: Asynchronous queueing decouples request submission from processing but does not shorten the several-minute bootstrap delay that leaves new instances unable to serve traffic, so 504s persist. It tempts because SQS genuinely absorbs spikes for workloads that tolerate deferred results, which this synchronous web application does not.

Switch the load balancer from an Application Load Balancer to a Network Load Balancer for faster TCP packet routing.

Why it fails: A Network Load Balancer forwards TCP without terminating HTTP, so it cannot generate or mitigate 504 Gateway Timeouts, and it does nothing about slow instance bootstrap. It tempts because NLB reduces latency for extreme-throughput or non-HTTP workloads, which is the actual reason to choose it.

Decrease the Auto Scaling group health check grace period to zero so failing instances are replaced immediately.

Why it fails: A zero grace period makes Auto Scaling terminate instances mid-bootstrap before they register as healthy, causing replacement loops rather than fixing the timeout. It tempts because shortening grace periods genuinely helps when health checks are misconfigured and instances are wrongly marked unhealthy.

Spread Placement Groups.

Why it fails: Spread Placement Groups are designed for high availability by placing instances on distinct physical hardware to minimize the impact of correlated failures. They do not provide the low-latency network performance required by CPU-bound, tightly coupled applications. Instead, they increase the physical distance between instances to improve fault tolerance.

Auto Scaling groups across multiple Availability Zones.

Why it fails: Scaling across multiple Availability Zones increases fault tolerance, but it also introduces network latency between instances residing in different zones. For applications requiring sub-millisecond latency, spreading instances across multiple AZs is counterproductive. These applications generally require a single, high-performance network fabric provided by a Cluster Placement Group.

Dedicated Hosts with physical CPU pinning.

Why it fails: Dedicated Hosts allow for license compliance and physical hardware control, but they do not automatically provide a low-latency network fabric between multiple instances. While they offer performance isolation, the network communication between them still relies on the standard VPC network stack, unlike the optimized performance of Cluster Placement Groups.

Deploy all instances in one AZ and use a Route 53 failover policy to a secondary region.

Why it fails: Relying on a single AZ creates a single point of failure within the region, violating high availability requirements. While multi-region failover provides disaster recovery, it does not address the need for low-latency, resilient local traffic distribution between AZs as requested by the architectural design scope.

Use an Auto Scaling group with a single AZ and enable Cross-Zone Load Balancing on the ALB.

Why it fails: Cross-zone load balancing distributes traffic across instances in multiple AZs, but if the single AZ fails, the entire application becomes unavailable. Resilience requires distributing instances across multiple physically separate AZs to ensure that infrastructure failures in one location do not impact the overall application availability.

Use a Network Load Balancer (NLB) with static IP addresses for each instance in one AZ.

Why it fails: Static IP addressing provides reachability but does not provide fault tolerance if the AZ housing the instances suffers a failure. Resilience is achieved by decoupling the traffic entry point from specific compute locations, allowing the architecture to survive the loss of an entire data center facility.