Multi-AZ deployment for high availability in AWS - Step-by-Step Execution

Process Flow - Multi-AZ deployment for high availability

Start Deployment

↓

Select Primary AZ

↓

Deploy Primary Instance

↓

Select Secondary AZ

↓

Deploy Secondary Instance

↓

Configure Sync & Failover

↓

Monitor Health

↓

If Primary Fails?

Yes→Failover to Secondary

↓

Continue Serving

↓

Deployment Complete

This flow shows deploying resources in two separate availability zones to ensure service stays up if one zone fails.

Execution Sample

AWS

Create EC2 in AZ1
Create EC2 in AZ2
Configure Load Balancer
Set Health Checks
Enable Auto Failover

This sequence deploys two instances in different zones, sets up a load balancer, and configures failover for high availability.

Process Table

Step	Action	Resource State	Result
1	Select Primary AZ	Primary AZ set to us-east-1a	Primary AZ chosen
2	Deploy Primary Instance	EC2 instance running in us-east-1a	Primary instance active
3	Select Secondary AZ	Secondary AZ set to us-east-1b	Secondary AZ chosen
4	Deploy Secondary Instance	EC2 instance running in us-east-1b	Secondary instance active
5	Configure Load Balancer	Load Balancer routing to both instances	Traffic balanced
6	Set Health Checks	Health checks monitoring both instances	Monitoring active
7	Enable Auto Failover	Failover configured to secondary instance	Failover ready
8	Primary Instance Fails	Primary instance down	Failover triggers to secondary
9	Secondary Instance Serves Traffic	Secondary instance active	Service continues without downtime
10	Primary Instance Recovers	Primary instance back online	Failback possible
11	Deployment Complete	Both instances running, failover active	High availability ensured

💡 Deployment completes with both instances active and failover configured for high availability.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 7	After Step 9	Final
Primary AZ	unset	us-east-1a	us-east-1a	us-east-1a	us-east-1a	us-east-1a
Secondary AZ	unset	unset	us-east-1b	us-east-1b	us-east-1b	us-east-1b
Primary Instance	not running	running	running	running	down	running
Secondary Instance	not running	not running	running	running	running	running
Load Balancer	not configured	not configured	not configured	configured	configured	configured
Failover Status	disabled	disabled	disabled	enabled	enabled	enabled

Key Moments - 3 Insights

Why do we deploy instances in different AZs instead of the same AZ?

Deploying in different AZs protects against zone failure. Execution table rows 2 and 4 show instances in separate AZs, ensuring if one AZ fails (row 8), the other can serve traffic (row 9).

What triggers the failover to the secondary instance?

Failover triggers when health checks detect the primary instance is down (row 8). This causes traffic to switch to the secondary instance (row 9), maintaining availability.

Can the system switch back to the primary instance after it recovers?

Yes, after the primary instance recovers (row 10), failback can occur to restore the primary as active, as shown in the deployment completion (row 11).

Visual Quiz - 3 Questions

Look at the execution table, at which step is the secondary instance deployed?

A Step 4

B Step 2

C Step 6

D Step 8

💡 Hint

Check the 'Action' column for 'Deploy Secondary Instance' in the execution table.

According to the variable tracker, what is the state of the primary instance after step 9?

A Running

B Down

C Not Running

D Starting

💡 Hint

Look at the 'Primary Instance' row under 'After Step 9' in the variable tracker.

If failover was not enabled at step 7, what would happen at step 8 when the primary instance fails?

A Primary instance would auto-recover immediately

B Traffic would continue to secondary instance

C Service would experience downtime

D Load balancer would shut down

💡 Hint

Refer to the 'Failover Status' variable in the tracker and the failover action in the execution table.

Concept Snapshot

Multi-AZ deployment means placing resources in two separate availability zones.
This protects your service if one zone fails.
Deploy primary and secondary instances in different AZs.
Use a load balancer to route traffic.
Set health checks and enable automatic failover.
This setup keeps your service running without downtime.

Full Transcript

Multi-AZ deployment for high availability involves deploying resources in two different availability zones to protect against zone failure. First, you select a primary AZ and deploy an instance there. Then, you select a secondary AZ and deploy a second instance. A load balancer is configured to route traffic to both instances, and health checks monitor their status. Failover is enabled so that if the primary instance fails, traffic automatically switches to the secondary instance, ensuring continuous service. When the primary recovers, failback can restore it as the active instance. This approach ensures your service remains available even if one AZ goes down.

Practice

1. What is the main benefit of using a Multi-AZ deployment in AWS?

easy

A. It increases availability by replicating resources across multiple zones.

B. It reduces the cost of running resources.

C. It speeds up the deployment process.

D. It automatically scales resources based on traffic.

Solution

1. Step 1: Understand Multi-AZ purpose

   Multi-AZ deployment copies resources to different zones to avoid downtime if one zone fails.

2. Step 2: Identify the main benefit

   This replication increases availability and fault tolerance, not cost reduction or speed.

3. Final Answer:

   It increases availability by replicating resources across multiple zones. -> Option A

4. Quick Check:

   Multi-AZ = High availability [OK]

Hint: Multi-AZ means copies in different zones for uptime [OK]

Common Mistakes:

• Confusing Multi-AZ with cost saving
• Thinking Multi-AZ speeds deployment
• Assuming Multi-AZ auto-scales resources

2. Which of the following is the correct way to enable Multi-AZ deployment in an AWS RDS instance configuration?

easy

A. "multi_az = false"

B. "enable_multi_az = yes"

C. "multi_az = true"

D. "multiAZ = enabled"

Solution

1. Step 1: Review AWS RDS Multi-AZ syntax

   The correct parameter to enable Multi-AZ is multi_az = true.

2. Step 2: Check other options for correctness

   Options A disables Multi-AZ, C and D use incorrect parameter names or values.

3. Final Answer:

   "multi_az = true" -> Option C

4. Quick Check:

   Enable Multi-AZ with multi_az = true [OK]

Hint: Look for exact parameter name and true value [OK]

Common Mistakes:

• Using false instead of true
• Wrong parameter names like enable_multi_az
• Incorrect value formats like yes or enabled

3. Given this AWS CLI command to create an RDS instance with Multi-AZ enabled:

aws rds create-db-instance --db-instance-identifier mydb --engine mysql --allocated-storage 20 --db-instance-class db.t3.micro --multi-az true

What will happen if the primary AZ fails?

medium

A. AWS will automatically failover to the standby instance in another AZ.

B. The database will stop working until manual recovery.

C. The database will scale up resources automatically.

D. The database will delete all data and restart.

Solution

1. Step 1: Understand Multi-AZ failover behavior

   Multi-AZ creates a standby in another zone that AWS switches to automatically if the primary fails.

2. Step 2: Analyze options

   AWS will automatically failover to the standby instance in another AZ. matches this automatic failover. Others describe stopping, scaling, or deleting which are incorrect.

3. Final Answer:

   AWS will automatically failover to the standby instance in another AZ. -> Option A

4. Quick Check:

   Multi-AZ = automatic failover [OK]

Hint: Multi-AZ means automatic failover on AZ failure [OK]

Common Mistakes:

• Thinking manual recovery is needed
• Confusing failover with scaling
• Assuming data loss on failover

4. You configured an RDS instance with multi_az = true but noticed no standby instance is created. What is the most likely cause?

medium

A. You selected a DB instance class that does not support Multi-AZ.

B. You used the wrong database engine.

C. You set allocated storage too low.

D. You forgot to enable automatic backups.

Solution

1. Step 1: Check Multi-AZ requirements

   Automatic backups must be enabled for Multi-AZ standby creation.

2. Step 2: Evaluate other options

   While some instance classes may not support Multi-AZ, the most common cause for no standby is backups not enabled. Storage size and engine choice usually don't prevent standby creation.

3. Final Answer:

   You forgot to enable automatic backups. -> Option D

4. Quick Check:

   Automatic backups required for Multi-AZ standby [OK]

Hint: Enable automatic backups to allow Multi-AZ standby creation [OK]

Common Mistakes:

• Assuming backups are optional for Multi-AZ
• Blaming storage size for standby absence
• Thinking engine type prevents standby

5. You want to design a highly available web application using AWS RDS with Multi-AZ and EC2 instances. Which architecture best ensures minimal downtime during an AZ failure?

hard

A. Deploy EC2 instances in a single AZ with RDS Multi-AZ enabled.

B. Deploy EC2 instances across multiple AZs and enable RDS Multi-AZ.

C. Deploy EC2 instances in multiple AZs but disable RDS Multi-AZ.

D. Deploy EC2 instances and RDS in a single AZ without Multi-AZ.

Solution

1. Step 1: Understand high availability for both compute and database

   To avoid downtime, both EC2 and RDS should be spread across AZs.

2. Step 2: Analyze options

   Deploy EC2 instances across multiple AZs and enable RDS Multi-AZ. deploys EC2 instances in multiple AZs and enables RDS Multi-AZ, ensuring failover for both layers.

3. Step 3: Reject other options

   Configurations with EC2 instances in a single AZ risk downtime if that AZ fails. Configurations with EC2 across multiple AZs but RDS Multi-AZ disabled risk database downtime.

4. Final Answer:

   Deploy EC2 instances across multiple AZs and enable RDS Multi-AZ. -> Option B

5. Quick Check:

   Multi-AZ + multi-AZ EC2 = minimal downtime [OK]

Hint: Spread both EC2 and RDS across AZs for full availability [OK]

Common Mistakes:

• Deploying EC2 in one AZ only
• Disabling RDS Multi-AZ
• Ignoring compute layer availability