> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo Basic Multi AZ Setup Using Instance Deployments

> Guide to launching two EC2 instances in different Availability Zones for basic Multi-AZ high availability, instance verification, and recommendations for load balancing and Auto Scaling

This walkthrough demonstrates a simple Multi-AZ setup by launching two EC2 instances in different Availability Zones within the same AWS region. Deploying instances across multiple AZs increases availability and resilience: if one AZ experiences an outage, the instance in the other AZ can continue serving traffic.

What you'll do

* Launch two EC2 instances (`WebServerA` and `WebServerB`) in different Availability Zones (for example, `us-east-2a` and `us-east-2b`).
* Verify both instances reach healthy status checks.
* Review next steps to make the setup production-ready (load balancing, Auto Scaling, and key management).

1. Open the EC2 console

* From the AWS Management Console search bar, type `EC2` and select the EC2 service to open the dashboard.
* On the dashboard, click “Instances” in the left navigation to proceed.

![A screenshot of the Amazon Web Services EC2 dashboard (US East — Ohio) showing the Resources panel with counts for Instances, Security groups, Elastic IPs, volumes and other EC2 resources. The left sidebar shows EC2 navigation items like Dashboard, Instances and Launch Templates.](https://mintcdn.com/kodekloud-c4ac6d9a/x-CkTJgJqym_5mBk/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Demo-Basic-Multi-AZ-Setup-Using-Instance-Deployments/aws-ec2-dashboard-resources-counts-ohio.jpg?fit=max\&auto=format\&n=x-CkTJgJqym_5mBk\&q=85\&s=512e139cdc3892f5c2274988e77717eb)

2. Launch the first instance (Web Server A)

* Click “Launch instances”.
* In the Name and tags step, give the instance a recognizable name such as `WebServerA` so it’s easy to identify later.

![A screenshot of the AWS EC2 "Launch an instance" console showing the "Name and tags" field with "Web" entered and the "Application and OS Images (Amazon Machine Image)" section below.](https://mintcdn.com/kodekloud-c4ac6d9a/x-CkTJgJqym_5mBk/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Demo-Basic-Multi-AZ-Setup-Using-Instance-Deployments/ec2-launch-instance-name-web-ami.jpg?fit=max\&auto=format\&n=x-CkTJgJqym_5mBk\&q=85\&s=a6e1d5a0b2e6ee1764c62f0d01841fe0)

* For the AMI, use the default Amazon Linux image (commonly free tier eligible).
* Choose an instance type appropriate for your needs; for this demo, select a free-tier eligible type such as `t3.micro` to avoid charges.

![Screenshot of the AWS EC2 "Launch an instance" web console showing the Instance type section with a t3.micro selected and its pricing/details (marked free tier eligible).](https://mintcdn.com/kodekloud-c4ac6d9a/x-CkTJgJqym_5mBk/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Demo-Basic-Multi-AZ-Setup-Using-Instance-Deployments/aws-ec2-instance-t3micro-free-tier.jpg?fit=max\&auto=format\&n=x-CkTJgJqym_5mBk\&q=85\&s=1c3a0b6eff3896d1b7672456e1d5e7e1)

* For Key pair (login) choose “Proceed without a key pair” for this demo to simplify the walkthrough. Do not do this in production—without a key pair you will not be able to SSH into the instance.

Proceeding without a key pair is not recommended for production. Without a key pair you will not be able to SSH into the instance using a private key. Use this option only for demo/testing where direct SSH access is not required.

![A screenshot of the AWS EC2 "Launch an instance" console showing the Key pair (login) section with the option "Proceed without a key pair (Not recommended)" and part of the Network settings.](https://mintcdn.com/kodekloud-c4ac6d9a/x-CkTJgJqym_5mBk/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Demo-Basic-Multi-AZ-Setup-Using-Instance-Deployments/aws-ec2-launch-without-keypair-network.jpg?fit=max\&auto=format\&n=x-CkTJgJqym_5mBk\&q=85\&s=5dd7ec706be84783a66c9983b04eaabe)

* Expand Network settings and click “Edit” to explicitly set the Availability Zone. For this example select `us-east-2a` (the exact AZ names vary by region). Leave other network options at their defaults unless you have specific requirements.
* Click “Launch” to create the instance. The console will start the launch process and show progress.

![A web browser screenshot of the AWS EC2 "Launch an instance" page showing a blue progress bar at 80% for "Launch initiation." Below it is a message asking the user to wait and not close the browser while the instance is launching.](https://mintcdn.com/kodekloud-c4ac6d9a/x-CkTJgJqym_5mBk/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Demo-Basic-Multi-AZ-Setup-Using-Instance-Deployments/aws-ec2-launch-progress-80.jpg?fit=max\&auto=format\&n=x-CkTJgJqym_5mBk\&q=85\&s=ffdd30c00abc9336f386e78169f83556)

3. Launch the second instance (Web Server B) in a different AZ

* Repeat the “Launch instances” flow.
* Name this instance `WebServerB`.
* Use the same AMI and instance type as `WebServerA`.
* For this demo, you may again select “Proceed without a key pair” (see the warning above).
* Under Network settings → Edit, set the Availability Zone to a different one in the same region, for example `us-east-2b`.
* Use the same security group as the first instance (or create a security group that allows only the inbound traffic you need, e.g., port 80 and 22 for SSH in production).
* Launch the instance.

4. Verify both instances

* Return to the Instances view. You should see both `WebServerA` and `WebServerB` listed. They may initially show status checks as “Initializing”; refresh after a short wait.

![A screenshot of the AWS EC2 Instances console. It shows two running t3.micro instances (WebServerA and WebServerB) with status checks listed as "Initializing" in the us-east-2 region.](https://mintcdn.com/kodekloud-c4ac6d9a/x-CkTJgJqym_5mBk/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Demo-Basic-Multi-AZ-Setup-Using-Instance-Deployments/aws-ec2-webservers-initializing-useast2.jpg?fit=max\&auto=format\&n=x-CkTJgJqym_5mBk\&q=85\&s=eb142a3f4b32e45bdcfb3bbd6dced363)

* After initialization completes, both instances should show healthy status checks (for example, `2/2` or `3/3` depending on your account settings).

![A screenshot of the AWS EC2 Instances console listing two running instances (WebServerB and WebServerA) filtered by "Instance state = running." Both are t3.micro instances with 3/3 status checks passed.](https://mintcdn.com/kodekloud-c4ac6d9a/x-CkTJgJqym_5mBk/images/AWS-Certified-DevOps-Engineer-Professional/Domain-3-Resilient-Cloud-Solutions/Demo-Basic-Multi-AZ-Setup-Using-Instance-Deployments/aws-ec2-running-webservera-webserverb.jpg?fit=max\&auto=format\&n=x-CkTJgJqym_5mBk\&q=85\&s=fa617d0cf39d3384370f476cb9663e28)

Quick reference: recommended settings for this demo

| Setting | Demo value | Notes |
| - | - | - |
| Instance names | `WebServerA`, `WebServerB` | Use consistent naming to identify AZ placement easily. |
| AMI | Amazon Linux (default) | Free tier eligible in many accounts. |
| Instance type | `t3.micro` | Choose a free-tier-eligible type if you want to avoid costs. |
| Key pair | Proceed without a key pair (demo only) | Not for production—use a private key for SSH. |
| Availability Zones | `us-east-2a`, `us-east-2b` | Same region, different AZs for redundancy. |
| Security group | Custom group allowing required inbound ports | Restrict access to only what you need (e.g., HTTP/HTTPS). |

Summary and next steps

* You have deployed two EC2 instances in the same region but in different Availability Zones (for example, `us-east-2a` and `us-east-2b`). This basic Multi-AZ placement reduces single-AZ dependency and improves availability.
* To harden and scale this pattern for production:
  * Add an Elastic Load Balancer to distribute traffic across instances and AZs.
  * Configure an Auto Scaling Group (ASG) with subnets spanning multiple AZs to maintain instance count and health across failures.
  * Use proper key pair management, IAM policies, and secure security group rules.
  * Consider using an Amazon Machine Image (AMI) baked with your application and monitoring with CloudWatch.

Deploying instances across multiple Availability Zones is a foundational high-availability pattern. For production, combine this pattern with Elastic Load Balancing, Auto Scaling Groups, proper key management, and monitoring to achieve resilience and operational readiness.

Links and references

* [Amazon EC2 User Guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/)
* [Elastic Load Balancing (ELB) documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/)
* [Amazon EC2 Auto Scaling documentation](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)

> **[Watch Video](https://learn.kodekloud.com/user/courses/aws-certified-devops-engineer-professional/module/614fb8a5-8397-4ea6-9d7c-fe05ebc43d18/lesson/06c696a0-1c3b-4562-b490-6a86934048a0)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.