A retail company is operating its ecommerce application on AWS. The application runs on Amazon EC2 instances behind an Application Load Balancer…

The most efficient and least operationally intensive solution is to leverage the existing Amazon CloudFront distribution. This can be achieved by using CloudFront's native custom error page functionality.

The process involves two main steps:

1. First, a custom error page (e.g., an HTML file) must be created and made publicly accessible. The standard, low-cost method for this is to upload the file to an Amazon S3 bucket and configure the bucket for static website hosting (Option A).

2. Second, the CloudFront distribution must be configured to intercept the specific 502 Bad Gateway HTTP status code when it is returned by the origin (the ALB). Instead of passing the error to the user, CloudFront will fetch and serve the custom error page from the S3 bucket (Option E).

This approach is ideal because it handles errors on a per-request basis, does not impact healthy traffic, and is a simple configuration change with minimal overhead.

B. Create an Amazon CloudWatch alarm to invoke an AWS Lambda function...

This is overly complex and disruptive. Modifying ALB rules via Lambda is a slow, stateful change that would redirect all users, not just the one who received the error.

C. Modify the existing Amazon Route 53 records by adding health checks...

Route 53 DNS failover is designed for endpoint failures, not for intermittent, per-request application errors. The ALB endpoint itself is likely healthy, so health checks would not fail.

D. Create an Amazon CloudWatch alarm to invoke an AWS Lambda function...

Similar to option B, this is an inappropriate use of Lambda and ALB rule modification. It is not designed for real-time, per-request error handling and has high operational overhead.

---

1. Amazon CloudFront Developer Guide - Serving custom error pages: This document explicitly describes the required functionality. It states

"You can have CloudFront return a custom error page when your origin server returns an HTTP 4xx or 5xx status code to CloudFront... Instead of returning the object

CloudFront can return a custom error page that you provide." This supports using CloudFront to handle the 502 error (Option E).

Source: AWS Documentation

Amazon CloudFront Developer Guide

"Configuring custom error responses".

2. Amazon S3 User Guide - Hosting a static website using Amazon S3: This guide details the process of configuring an S3 bucket to serve static content like HTML pages over HTTP

which is the standard prerequisite for serving a custom error page via CloudFront. This supports the creation and hosting of the error page (Option A).

Source: AWS Documentation

Amazon S3 User Guide

"Hosting a static website using Amazon S3".

3. Amazon Route 53 Developer Guide - Configuring DNS failover: This document explains that DNS failover works by routing traffic away from an unhealthy resource based on the status of a health check. This mechanism is not suitable for transient

per-request errors where the endpoint itself remains healthy and available. This confirms why Option C is incorrect.

Source: AWS Documentation

Amazon Route 53 Developer Guide

"Concepts

" section "Health checks and DNS failover".