High Availability practice questions

Deploying the application across multiple Availability Zones.

Why it fails: Multi-AZ deployment addresses high availability within one Region, not disaster recovery across Regions. It is tempting because it protects against a single Availability Zone failure, which is the correct resilience choice for uptime requirements, but a Region-wide disaster still takes the whole application offline.

Using larger instance sizes for better performance.

Why it fails: Instance sizing affects performance and cost, not recovery objectives or failover capability. It is tempting because right-sizing is a genuine design consideration, and larger instances would be the correct answer to a question about handling peak compute load rather than disaster recovery.

Store session state in Amazon DynamoDB

Why it fails: DynamoDB is a key-value store, not a session cache; it adds per-request latency and cost compared with ElastiCache, and the ALB cannot route by session ID. It is tempting because DynamoDB offers durable, highly available storage, and would suit persistent user profile or order data rather than ephemeral session state.

Store session state on the local instance store of each EC2 instance

Why it fails: Instance store is ephemeral and tied to one EC2 instance, so sessions vanish on stop or replacement and are invisible to other instances behind the ALB. It is tempting for its low latency and zero cost, and would be correct for scratch data or temporary caches that can be regenerated.

Store session state in Amazon S3

Why it fails: S3 offers no low-latency atomic read-modify-write for concurrent session updates, and the ALB cannot route requests by session ID. It is tempting because S3 is durable, highly available and cheap, and would be correct for storing static assets, logs or backups rather than live session state.

Amazon FSx for Windows File Server

Why it fails: FSx for Windows File Server provides SMB shares with Active Directory integration, which suits Windows workloads needing NTFS permissions and DFS. This Linux-style upload workload needs a POSIX shared file system mountable concurrently across Availability Zones, which FSx for Windows does not deliver.

Amazon S3 with S3 File Gateway

Why it fails: S3 File Gateway presents a cached NFS or SMB interface backed by S3 objects, designed for on-premises file-to-object tiering rather than EC2-native concurrent POSIX access. The workload needs a shared file system directly mountable by many EC2 instances across Availability Zones.

Amazon EBS with Multi-Attach enabled

Why it fails: EBS Multi-Attach permits a single io1 or io2 volume to attach to instances in one Availability Zone only, using a cluster-aware file system, so it cannot span AZs or scale concurrently. It suits clustered databases needing shared block access, not general upload storage.

Use Amazon Aurora (MySQL-compatible) with Multi-AZ.

Why it fails: Aurora is MySQL- and PostgreSQL-compatible and cannot run Oracle schemas or PL/SQL, so the existing database would need rewriting. Aurora Multi-AZ is genuinely highly available with automated failover, making it correct only when the engine is MySQL or PostgreSQL, not Oracle.

Use Amazon RDS for Oracle with a Read Replica in another AZ.

Why it fails: An RDS for Oracle Read Replica is asynchronous and read-only; it provides no automated failover, so promotion is manual and data loss is possible. Read Replicas serve read scaling. Multi-AZ Oracle, which maintains a synchronous standby with automatic failover, is the correct choice here.

Deploy Oracle on EC2 in two Availability Zones and use asynchronous replication.

Why it fails: Oracle on EC2 with asynchronous replication leaves failover entirely to custom scripting, so recovery is manual and recent transactions may be lost. EC2 hosting suits engine versions or options RDS cannot offer. RDS for Oracle Multi-AZ provides the synchronous standby and automated failover the scenario demands.

Amazon ElastiCache

Why it fails: ElastiCache is an in-memory cache store, not a relational database, so it cannot satisfy the relational and failover requirements. It is tempting because it is fully managed and highly available; it would be the right choice for offloading read traffic or session storage in front of a database.

Amazon DynamoDB

Why it fails: DynamoDB is a NoSQL key-value store, so it does not provide a relational schema or SQL engine. It is tempting because it is fully managed, multi-AZ by default and scales automatically; it would be correct for high-throughput key-value or document workloads, not relational ones.

Amazon RDS Single-AZ

Why it fails: Single-AZ RDS runs one Availability Zone with no standby, so a zone failure causes downtime and no automated failover occurs. It is tempting because RDS is the correct fully managed relational engine; Multi-AZ deployments, not Single-AZ, provide the synchronous standby and automatic failover the scenario demands.

Use Amazon ElastiCache for Memcached as the primary database.

Why it fails: ElastiCache for Memcached is an in-memory cache, not a relational engine, so it cannot store the application's relational data or provide durable storage. It tempts because caching offloads read-heavy traffic and absorbs spikes, but it belongs in front of a database, not as the primary datastore.

Deploy Amazon RDS in a Multi-AZ configuration without read replicas.

Why it fails: Multi-AZ provides synchronous standby failover for availability, but the standby cannot serve reads, so read-heavy load is not distributed and sudden traffic spikes are not absorbed. It tempts because Multi-AZ satisfies the high-availability requirement, yet read scaling demands read replicas.

Deploy Amazon RDS in a single Availability Zone with a large instance size.

Why it fails: A single Availability Zone offers no failover, so an AZ outage takes the database down, failing the high-availability requirement regardless of instance size. It tempts because a large instance handles heavier load, but vertical scaling cannot address read distribution or AZ-level resilience.

Use Amazon Kinesis Data Streams with enhanced fan-out.

Why it fails: Kinesis Data Streams is a proprietary streaming service, not Kafka; it cannot host existing Kafka topics, producers or consumers without rewriting them. It is tempting because it offers managed streaming with high throughput, and would be correct for new applications built natively on Kinesis rather than migrated Kafka clusters.

Use Amazon SQS FIFO queues with message deduplication.

Why it fails: SQS FIFO is a queue, not a publish-subscribe streaming platform; it lacks Kafka topics, partitions and consumer groups, so 100 Kafka topics cannot map onto it. It is tempting because it is fully managed and offers deduplication, and would be correct for decoupling point-to-point messaging workloads, not Kafka migration.

Deploy Apache Kafka on Amazon EC2 with Spot Instances and EBS volumes.

Why it fails: Self-managed Kafka on EC2 with Spot Instances reintroduces patching, broker scaling and rebalancing overhead, and Spot interruptions threaten availability. It is tempting because it gives full control over broker configuration, and would be correct when specific Kafka versions or plugins are unsupported by Amazon MSK.

Use a single EC2 instance in one AZ and a standby instance in another AZ

Why it fails: A single instance with a standby in another AZ provides no automatic failover; recovery requires manual intervention or a script, so instance failure is not handled automatically. It is tempting because cross-AZ standby is a recognised DR pattern, and would be correct for cost-sensitive workloads tolerating manual recovery, not automatic HA.

Use AWS Elastic Beanstalk with a single instance environment

Why it fails: A single-instance Elastic Beanstalk environment runs one EC2 instance with no load balancer or Auto Scaling group, so an instance failure is not automatically recovered. It is tempting because Beanstalk handles deployment and platform configuration, and would be correct for development or low-traffic environments, not production HA.

Use AWS CloudFormation to launch a single instance in each AZ

Why it fails: CloudFormation launches the instances once but does not monitor or replace them; a failed instance stays failed until the stack is updated or re-run. It is tempting because CloudFormation gives repeatable, versioned infrastructure provisioning, and would be correct for standardised deployments, not for automatic instance recovery.

Increase the allocated storage of the DB instance.

Why it fails: Increasing allocated storage raises capacity and baseline IOPS ceilings, but does not reduce the volume of read operations hitting the instance, so slow queries persist. It suits running out of free space or hitting a throughput limit, not consistently high ReadIOPS from read-heavy query patterns.

Enable Multi-AZ deployment for the DB instance.

Why it fails: Multi-AZ maintains a synchronous standby that cannot serve read traffic, so ReadIOPS on the primary stays unchanged; failover capability, not read scaling, is its purpose. It would be the right choice for high-availability or disaster-recovery requirements, not for offloading slow read queries.

Migrate the database to Amazon Aurora with PostgreSQL compatibility.

Why it fails: Migrating to Aurora requires significant migration effort and application cutover, violating the minimal-operational-overhead requirement, and does not itself add read capacity. Aurora is the right choice when you need its distributed storage, replicas, or serverless scaling as part of a broader redesign.

AWS Global Accelerator

Why it fails: Global Accelerator routes client traffic over the AWS global network to regional endpoints; it does not distribute TCP connections across multiple EC2 instances as a load balancer. It is tempting because it handles non-HTTP TCP traffic, but it is designed for improving global client latency and failover, not for spreading connections across a target group.

Classic Load Balancer (CLB)

Why it fails: The Classic Load Balancer supports TCP listeners on arbitrary ports, but it operates at the connection level without the target-group, health-check and cross-zone features of the current Network Load Balancer, and AWS positions it for legacy EC2-Classic architectures. It is tempting because it does handle non-HTTP TCP, but it is intended for existing legacy deployments rather than new designs.

Application Load Balancer (ALB)

Why it fails: The Application Load Balancer operates at layer 7 and requires HTTP or HTTPS listeners, so it cannot forward the proprietary binary protocol on TCP port 4444. It is tempting because it is the default modern ELB choice for web workloads, but it is designed for HTTP-based routing, not for arbitrary TCP traffic.

Use multiple EC2 instances behind an Application Load Balancer with sticky sessions.

Why it fails: Using multiple EC2 instances behind an ALB with sticky sessions still ties state to individual instances. If an instance fails, its sessions are lost, and scaling requires rebalancing sessions. This does not achieve true HA or scalability for state.

Lift and shift to a single Amazon EC2 instance with an EBS volume.

Why it fails: A single EC2 instance with one EBS volume remains a single point of failure and cannot scale horizontally, so the availability and scalability goals go unmet. It is tempting as the quickest lift-and-shift, and would suit a workload needing minimal change with no HA or scaling requirement.

Use an EC2 Auto Scaling group with lifecycle hooks to persist state to EBS snapshots.

Why it fails: Auto Scaling lifecycle hooks manage instance launch and termination, but EBS snapshots cannot serve as shared live state for a stateful application across instances. This approach suits stateless fleets needing graceful deregistration, not persistent per-node data.

Amazon RDS Single-AZ deployment with automated backups

Why it fails: Single-AZ deployment places the database in one Availability Zone, so no automatic failover to a second AZ occurs; automated backups restore data but do not provide multi-AZ high availability. It suits dev/test or cost-sensitive workloads tolerating downtime, not production systems needing minimal-downtime failover.

Amazon DynamoDB with global tables

Why it fails: DynamoDB is a NoSQL key-value store, so it cannot satisfy the stem's relational database requirement; global tables replicate across Regions, not Availability Zones. It would be correct for multi-Region, low-latency NoSQL workloads needing active-active replication, not relational multi-AZ failover.

Amazon RDS Read Replica

Why it fails: A Read Replica serves read scaling and can be promoted manually, but promotion is not automatic failover and introduces downtime; it also uses asynchronous replication. It would suit offloading read-heavy reporting traffic, not the stem's requirement for automatic multi-AZ failover with minimal downtime.

Amazon S3

Why it fails: Amazon S3 is object storage, not a key-value store, and is not optimized for low-latency reads and writes for small objects, especially for frequent access patterns.

Amazon ElastiCache for Memcached

Why it fails: ElastiCache for Memcached is an in-memory cache, so data is volatile and can be evicted or lost on node failure, breaching the durability the preferences require. It suits ephemeral session or cache workloads where loss is tolerable.

Amazon RDS for PostgreSQL

Why it fails: Amazon RDS for PostgreSQL stores data in relational tables with fixed schemas, not key-value pairs, and its provisioned instances cannot match DynamoDB's single-digit-millisecond latency at any scale. It would be the right choice for transactional workloads needing joins, ACID compliance across multiple tables, or complex SQL queries — not simple, highly available key-value preference lookups.

Amazon RDS Single-AZ deployment

Why it fails: A Single-AZ deployment runs one instance in one Availability Zone with no standby, so an AZ failure causes downtime and no automatic failover occurs. It is tempting as the cheapest RDS option, and it is the correct choice when high availability is explicitly not required.

Amazon RDS with Read Replicas

Why it fails: Read Replicas serve read traffic and require manual promotion; they provide no automatic failover of the primary database. Multi-AZ standby does. Read Replicas are tempting because they improve availability for read-heavy workloads, but that is scaling, not automatic failover within a single region.

Amazon RDS cross-region replication

Why it fails: Cross-region replication copies data to a different region and provides no automatic failover within one region, so it cannot satisfy the single-region availability requirement. It is tempting because it does deliver disaster recovery and read scaling, which is the correct choice when the requirement spans multiple regions.

Increase the CPU and memory for all ECS tasks.

Why it fails: Scaling CPU and memory masks the symptom without revealing which task, dependency or request pattern causes the spikes; the stem asks for diagnosis, not remediation. It is tempting because Fargate task sizing is the usual lever for sustained high utilisation, and would be right if metrics showed a persistent, uniform CPU ceiling rather than intermittent, patternless spikes.

Set up CloudWatch Synthetics canaries to monitor the endpoints.

Why it fails: Synthetics canaries measure endpoint availability and latency from outside, revealing that spikes occur but not which task or dependency causes them. Canaries suit proactive uptime and SLA monitoring; correlating CPU spikes to specific tasks needs Container Insights or X-Ray tracing instead.

Use CloudWatch Logs Insights to analyze application logs for errors.

Why it fails: Application logs capture errors and exceptions, not the CPU contention or task-level resource behaviour producing the latency spikes, so no causal signal appears. Logs Insights is genuinely useful for tracing stack traces and request failures, and would be the right tool if the spikes correlated with logged errors rather than raw CPU saturation.

Use AWS Lambda functions for each microservice, triggered by API Gateway.

Why it fails: Lambda's cold starts and per-invocation execution model introduce variable latency that conflicts with strict latency requirements, and API Gateway adds another hop. It tempts because Lambda minimises operational overhead, making it the right choice when latency is tolerant and traffic is sporadic.

Deploy each microservice on Amazon EC2 instances in an Auto Scaling group across AZs.

Why it fails: Running each microservice on EC2 Auto Scaling groups spreads instances across AZs, but you still patch, scale and monitor every service's fleet yourself, so operational overhead stays high. EC2 suits lift-and-shift workloads needing OS-level control; here the stem's low-overhead requirement points to a managed compute service instead.

Use Amazon EKS with worker nodes on EC2, and deploy microservices as Kubernetes pods.

Why it fails: EKS requires managing Kubernetes control-plane integrations, node groups, upgrades and scaling policies, which adds operational overhead the scenario seeks to minimise. It tempts because Kubernetes suits complex microservice estates, but only when that orchestration control justifies the operational burden.

Deploy EC2 instances in a single AZ with an Auto Scaling group.

Why it fails: A single Availability Zone gives no AZ-level redundancy, so an AZ failure takes the application tier down regardless of the Auto Scaling group. Auto Scaling is tempting because it maintains instance count and replaces unhealthy instances, but it operates within whichever AZs are configured, and one AZ cannot satisfy the two-AZ requirement.

Deploy EC2 instances in two AZs behind a Network Load Balancer (NLB).

Why it fails: An NLB operates at layer 4 and cannot evaluate HTTP host or path rules, and the stem already specifies an Application Load Balancer for the application tier. NLB is tempting for high-throughput or static-IP TCP workloads, but replacing the ALB does not address the two-AZ requirement the architecture must meet.

Use Amazon Route 53 weighted routing to distribute traffic to instances in two AZs.

Why it fails: Route 53 weighted routing splits traffic by configured proportions, not by health-checked failover across AZs, and it bypasses the ALB entirely. It is tempting because it distributes traffic across endpoints, but weighted records suit gradual traffic shifting or A/B testing, not maintaining application-tier availability when an AZ fails.

Replatform the application to use AWS Elastic Beanstalk and Amazon DynamoDB.

Why it fails: DynamoDB is a NoSQL key-value store, so the legacy relational schema and SQL queries would require rewriting application code, contradicting the minimal-change requirement. Replatforming suits swapping a self-managed engine for a managed equivalent, such as moving to Amazon RDS for the same database engine.

Refactor the application to use a microservices architecture with Amazon Aurora.

Why it fails: Microservices with Aurora demands decomposing the monolith and rewriting database access, directly violating the minimal-code-change constraint. Refactoring is the correct strategy when the business needs new capabilities and is willing to invest in redesign, not when a legacy database must remain largely untouched.

Retire the application and replace it with a SaaS solution.

Why it fails: Retiring and replacing with SaaS discards the application entirely, so no migration of the legacy database occurs and scalability or high-availability gains are irrelevant. Retire is appropriate only when an application is no longer needed and a commercial SaaS product already covers the business function.

Deploy web and application servers on EC2 instances in an Auto Scaling group in one AZ. Use Amazon Route 53 latency-based routing to another region.

Why it fails: A single-AZ Auto Scaling group leaves the application unavailable if that AZ fails, and cross-region latency routing does not restore the failed AZ's capacity. Multi-AZ Auto Scaling groups with an Application Load Balancer and Multi-AZ RDS deliver the required availability with minimal operational overhead.

Deploy web, application, and database on a single large EC2 instance in one AZ. Take snapshots every hour.

Why it fails: One EC2 instance is a single point of failure, and hourly snapshots only enable recovery after an outage, not continuous availability across Availability Zones. Multi-AZ Auto Scaling groups behind an Application Load Balancer with Multi-AZ RDS meet the availability and low-effort requirements.

Deploy web and application servers on EC2 instances in two AZs with Elastic IP addresses. Use Amazon Route 53 with health checks to route traffic.

Why it fails: Elastic IP addresses are tied to individual instances, so instance failure requires manual reattachment, and Route 53 health checks alone cannot replace failed capacity. An Auto Scaling group spanning two AZs behind an Application Load Balancer with Multi-AZ RDS provides automatic failover with less administration.

Amazon S3 with S3 File Gateway to present as a file system.

Why it fails: S3 File Gateway presents S3 objects over NFS, but it caches on-premises or on EC2 and does not deliver the low-latency shared file system with native IAM file-level authorisation required across Availability Zones. It suits hybrid access to S3 data, not a multi-AZ shared NFS workload.

Amazon EBS with a Provisioned IOPS volume type, mounted on multiple instances using a cluster file system.

Why it fails: EBS volumes attach to a single EC2 instance in one Availability Zone; a cluster file system layered on top does not provide the multi-AZ NFS access or IAM-based file system authorisation the scenario demands. It is tempting for low-latency block storage on one instance, where Provisioned IOPS would be the right fit.

Amazon FSx for Lustre with a persistent deployment type.

Why it fails: FSx for Lustre is a high-performance parallel file system for HPC and machine learning workloads, and its persistent deployment type does not provide the multi-AZ durability the stem requires. Amazon EFS offers NFS across Availability Zones with IAM-based file system policies. Lustre would suit scratch processing or compute-intensive analytics.