High Availability Architecture for 3-Tier Application

Answer - A.

An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model.

After the load balancer receives a request, it evaluates the listener rules in priority order to determine which rule to apply and then selects a target from the target group for the rule action.

You can configure listener rules to route requests to different target groups based on the content of the application traffic.

Application Load Balancer supports a round-robin load-balancing algorithm.

Additionally, Application Load Balancer supports a slow start mode with the round-robin algorithm that allows you to add new targets without overwhelming them with a flood of requests.

With the slow start mode, targets warm-up before accepting their fair share of requests based on a ramp-up period that you specify.

Slow start is very useful for applications that depend on cache and need a warm-up period before responding to requests with optimal performance.

It does support HTTP/HTTPS protocols.

Compared to Classic Load Balancers, an Application Load Balancer provides more features such as host-based routing, slow start, etc., which is ideal for web and application traffic load balancing.

The AWS Documentation also mentions independent working of target groups under the Application Load Balancer.

Support for monitoring the health of each service independently, as health checks are defined at the target group level, and many CloudWatch metrics are reported at the target group level.

Attaching a target group to an Auto Scaling group enables you to scale each service dynamically based on demand.

For more information on the Application Load Balancer, please refer to the below URL.

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html

The most preferred option for adding high availability to the Web, Application, and Database tiers of a 3-tier application, while ensuring each tier can be scaled independently, is to create an Application Load Balancer (ALB) and add separate target groups for the Web and Application Tiers.

Option A is the most preferred option because it provides the following advantages:

1. Elasticity: The ALB can automatically distribute traffic to multiple instances in each target group, ensuring that the web and application tiers can scale independently and horizontally as needed.

2. High availability: The ALB automatically detects unhealthy instances and routes traffic to healthy ones, increasing the overall availability of the application.

3. HTTPS support: The ALB can terminate HTTPS traffic, freeing the application instances from the burden of SSL/TLS processing and allowing them to focus on delivering RESTful services.

4. Health checks: The ALB can perform health checks on each instance in each target group, ensuring that only healthy instances receive traffic.

5. Monitoring and logging: The ALB provides detailed metrics and logs for each target group, allowing for easy monitoring and troubleshooting of the application.

Option B is not preferred because it uses a combination of an ALB and a Classic Load Balancer (CLB), which can complicate the architecture and increase the risk of failure.

Option C is not preferred because it uses a single CLB for both the Web and Application Tiers, which can limit scalability and availability.

Option D is not preferred because it uses separate CLBs for the Web and Application Tiers, which can also limit scalability and availability, as well as increase management overhead.

In summary, creating an ALB and adding separate target groups for the Web and Application Tiers is the most preferred option for adding high availability to a 3-tier application while ensuring each tier can be scaled independently.