Designing High Availability on AWS: Route 53, Load Balancers, and Auto Scaling

# Designing High Availability on AWS: Route 53, Load Balancers, and Auto Scaling

I am currently strengthening my cloud computing knowledge while preparing for the AWS Certified Solutions Architect – Associate (SAA-C03) certification.

One of the concepts that has helped me better understand how AWS works is high availability.

At first, I saw services such as Amazon Route 53, Elastic Load Balancing, and Auto Scaling as separate technologies. However, as I studied them together, I began to understand how each service plays a specific role in an architecture designed to remain available even when failures occur.

In this article, I want to share what I have learned in a simple and practical way.

## What Does High Availability Mean?

A highly available application is designed to continue operating even when part of the infrastructure experiences a failure.

In AWS, this usually means avoiding dependence on a single server or a single Availability Zone.

For example, instead of running an application on only one EC2 instance, we can distribute multiple instances across different Availability Zones.

A simplified architecture could look like this:

User
↓
Amazon Route 53
↓
Application Load Balancer
↓
EC2 in Availability Zone A
EC2 in Availability Zone B

This helps reduce single points of failure.

## Amazon Route 53: Sending Users to the Right Destination

Amazon Route 53 is AWS's DNS service.

One of the most interesting things I learned is that Route 53 can do much more than simply connect a domain name to an address.

AWS provides different routing policies depending on the requirements of the application.

Some of them are:

- Simple Routing
- Weighted Routing
- Latency-Based Routing
- Failover Routing
- Geolocation Routing
- Geoproximity Routing
- Multi-Value Answer Routing

Each routing policy can be used to solve a different type of problem.

For example, with Failover Routing, we can define a primary resource and a secondary resource.

If Route 53 detects through a Health Check that the primary resource is unavailable, it can direct requests to the secondary resource.

This helped me understand that DNS can also be part of a high availability strategy.

## Elastic Load Balancing

Another important component is Elastic Load Balancing.

Its main purpose is to distribute incoming requests across multiple targets.

For example:

Internet
↓
Application Load Balancer
↓
EC2-1
EC2-2
EC2-3

If all users were sent directly to only one EC2 instance, that instance could become a single point of failure.

With a Load Balancer, traffic can be distributed across multiple instances.

During my studies, I have focused mainly on the differences between the Application Load Balancer (ALB) and the Network Load Balancer (NLB).

### Application Load Balancer

The Application Load Balancer operates at the application layer and is especially useful for HTTP and HTTPS traffic.

It also supports advanced routing rules such as:

- Host-based routing
- Path-based routing

For example:

example.com/sales → Target Group A

example.com/support → Target Group B

This allows different requests to be sent to different groups of servers.

### Network Load Balancer

The Network Load Balancer works at the network layer and is designed to handle very large numbers of connections with very low latency.

Understanding the difference between ALB and NLB helped me realize that choosing the correct Load Balancer depends on the requirements of the architecture.

## Target Groups and Health Checks

Another important concept is Target Groups.

Load Balancers do not necessarily send traffic directly to any available server. Instead, resources are organized into Target Groups.

The Load Balancer also performs Health Checks to determine whether the targets are working correctly.

For example:

ALB
↓
Target Group
↓
EC2-A → Healthy
EC2-B → Healthy
EC2-C → Unhealthy

If an instance fails the Health Check, the Load Balancer can temporarily stop sending traffic to it.

This improves the overall availability of the application.

## Auto Scaling

Elastic Load Balancing becomes even more powerful when combined with Amazon EC2 Auto Scaling.

Auto Scaling can automatically increase or decrease the number of EC2 instances depending on demand.

For example:

Normal demand:
2 EC2 instances

Traffic increase:
2 → 4 → 6 EC2 instances

Traffic decrease:
6 → 4 → 2 EC2 instances

New instances can automatically register with the Target Group used by the Load Balancer.

This allows us to build an architecture that is not only highly available, but also scalable.

## Combining the Services

A typical architecture could use:

1. Amazon Route 53 to resolve the domain.
2. An Application Load Balancer to receive incoming requests.
3. A Target Group to organize the instances.
4. Amazon EC2 instances distributed across multiple Availability Zones.
5. Auto Scaling to automatically adjust capacity.
6. Health Checks to detect unhealthy resources.

The flow could look like this:

User
↓
Route 53
↓
Application Load Balancer
↓
Target Group
↓
EC2 - AZ A
EC2 - AZ B
↓
Auto Scaling

For me, understanding how these services work together has been more important than simply memorizing the definition of each service.

## One of the Most Important Lessons

One of the main lessons I have learned while preparing for AWS Solutions Architect – Associate is that many architecture questions are not simply asking you to identify a service.

The real question is often:

"How can I design a solution that continues working when something fails?"

AWS provides different tools to solve this problem.

Route 53 can help decide where users should be directed.

Elastic Load Balancing distributes requests.

Health Checks identify resources that are experiencing problems.

Auto Scaling helps maintain the required capacity.

Multiple Availability Zones help reduce the impact of failures in a specific location.

## Continuing My AWS Learning Journey

This article is part of my learning journey as I continue preparing for the AWS Certified Solutions Architect – Associate certification.

My background is focused on cybersecurity, so I am also interested in understanding how cloud architecture, networking, availability, and security work together.

In future articles, I plan to continue sharing what I learn about services such as Amazon EC2, Amazon VPC, Amazon S3, security, networking, and AWS architecture design.

Thanks for reading.