Multi-AZ deployment for high availability in AWS - Commands & Configuration

Introduction

Sometimes servers or data centers can fail. Multi-AZ deployment means running your app in multiple places at once to keep it working even if one place stops.

When you want your website to stay online even if one data center has a problem.

When you run a database and want it to keep working if one zone goes down.

When you want faster recovery from failures without manual fixes.

When you want to balance traffic across different locations for better speed.

When you want to meet rules that require your data to be safe and always available.

Config File - main.tf

main.tf

provider "aws" {
  region = "us-east-1"
}

resource "aws_db_instance" "example" {
  allocated_storage    = 20
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = "db.t3.micro"
  name                 = "mydb"
  username             = "admin"
  password             = "StrongPass123!"
  multi_az             = true
  publicly_accessible  = false
  skip_final_snapshot  = true
}

This Terraform file creates a MySQL database instance in AWS.

The key part is multi_az = true, which tells AWS to deploy the database in two availability zones for high availability.

This means if one zone fails, the other keeps the database running.

Commands

This command sets up Terraform in the current folder and downloads the AWS provider plugin needed to create resources.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.60.0...

- Installed hashicorp/aws v4.60.0 (signed by HashiCorp)



Terraform has been successfully initialized!

This command shows what Terraform will create or change before actually doing it. It helps you check your setup.

Terminal

terraform plan

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # aws_db_instance.example will be created

  + resource "aws_db_instance" "example" {

      + allocated_storage    = 20

      + engine               = "mysql"

      + engine_version       = "8.0"

      + instance_class       = "db.t3.micro"

      + multi_az             = true

      + name                 = "mydb"

      + username             = "admin"

      + publicly_accessible  = false

      + skip_final_snapshot  = true

    }



Plan: 1 to add, 0 to change, 0 to destroy.

This command creates the database with Multi-AZ enabled. The flag skips asking for confirmation to speed up the process.

Terminal

terraform apply -auto-approve

Expected Output

aws_db_instance.example: Creating...

aws_db_instance.example: Still creating... [10s elapsed]

aws_db_instance.example: Creation complete after 1m30s [id=mydb]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Skip manual approval to apply changes immediately

This AWS CLI command checks the details of the created database to confirm Multi-AZ is enabled.

Terminal

aws rds describe-db-instances --db-instance-identifier mydb

Expected Output

{

    "DBInstances": [

        {

            "DBInstanceIdentifier": "mydb",

            "MultiAZ": true,

            "DBInstanceStatus": "available",

            "Engine": "mysql",

            "DBInstanceClass": "db.t3.micro"

        }

    ]

}

→

--db-instance-identifier - Specify the exact database instance to describe

Key Concept

If you remember nothing else from this pattern, remember: Multi-AZ means running your app or database in two places at once to keep it working during failures.

Common Mistakes

Not setting multi_az = true in the database configuration

The database will run in only one zone and can fail if that zone goes down.

Always include multi_az = true to enable high availability.

Skipping verification after deployment

You might think Multi-AZ is enabled but it is not, risking downtime.

Use AWS CLI or console to confirm Multi-AZ is active after deployment.

Summary

Write a Terraform file with multi_az = true to create a highly available database.

Run terraform init, plan, and apply to deploy the database.

Verify the Multi-AZ setting using AWS CLI to ensure high availability.

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