Web application maintenance strategies: Options to display a custom error page

Context: As organizations increasingly rely on web applications for critical business operations, managing scheduled maintenance windows effectively becomes crucial. As technical advisors working with various AWS customers, we have observed common patterns and requirements around implementing maintenance pages. This article explores different approaches to handle scheduled maintenance windows while ensuring a professional user experience.

Understanding Customer Needs

Through numerous customer interactions, we have identified three primary needs that drive maintenance page implementation strategies:

User Experience Management: Organizations need to communicate maintenance activities professionally to their users. This goes beyond simply taking applications offline – it's about maintaining brand consistency and providing clear communication even during downtimes.

Operational Autonomy: Infrastructure teams and Cloud Centers of Excellence (CCoE) increasingly need to empower application teams with self-service capabilities for maintenance windows. This delegation of control helps reduce operational bottlenecks while maintaining governance.

Implementation Flexibility: Organizations require solutions that support both manual and automated approaches to maintenance page management, allowing teams to choose the most appropriate method for their specific use cases.

Technical Requirements: A Progressive Approach

When implementing maintenance pages, requirements typically follow a progression of complexity:

Approach 1: Basic Implementation

• Simple HTML maintenance page
• Basic text communication
• Flexible hosting options without domain constraints
• Minimal setup and configuration

Approach 2: Enhanced User Experience

• Rich content including CSS, JavaScript, and images
• Corporate branding requirements
• Specific domain name requirements (corporate FQDN)
• HTTP support

Approach 3: Enterprise Grade

• HTTPS support with custom SSL certificates
• Enhanced security requirements
• Integration with existing security controls
• Corporate compliance considerations

Let's explore implementation approaches based on common web application architectures.

Implementation Options

Approach 1:

The web application is accessible through an Application Load Balancer (ALB). The ALB listens for HTTP traffic on port 80 and routes requests to Amazon Elastic Compute Cloud (EC2) instances that run the application's business logic. The custom error response is configured as return fixed response option in the ALB listener rule. This rule will have a lower priority than the web application rule priority. ALB listener rules follow a priority-based execution system, where rules with lower numeric values have higher priority. To control traffic flow:

• Set the lowest numeric priority for the web application rule during normal operation
• Set the lowest numeric priority for the maintenance page rule during maintenance windows

When the application is in maintenance mode, the following process occurs:

1. The application owner increases the priority of the maintenance page rule (Priority Y) by setting the priority numeric value to be lower than the default rule (Priority X).
2. The application load balancer routes the user traffic to the maintenance page.

To disable the maintenance mode, increase the priority of the Default Rule to be higher than the maintenance page rule.

Figure 1: Web Application exposed to user by application load balancer

Below are the step by step instructions to create a new ALB listener rule to Return fixed response :

1. In the EC2 console, choose Load Balancers and choose the Load Balancer.

2. Choose Listeners and rules, select the Listener (Note: This example uses an HTTP listener for simplicity. In practice, it's strongly recommended to use HTTPS listeners for better security.)

3. Select Manage rules, and choose **Add rule **

4. Provide an appropriate recognizable name and click Next

5. Choose Add condition, and provide your traffic routing condition for this rule, then choose Confirm

Note: In this example, condition is set to match all Source IP from the internet.

6. Choose Next.

7. Select Return fixed response.

8. For Response code provide the HTTP code to be returned to the user. In this example, HTTP code 503 is used.

9. Under Content type, select the format of your message

10. Under Response body configure the message to be presented during application maintenance, then choose Next

11. Provide appropriate rule Priority between 1 - 50,000, choose Next and choose Create.

12. The new rule has been deployed successfully.

13. Now you can test the availability of your application www.example.com

Pros and Cons:

1. (+) Users stay on your website's domain while viewing the maintenance page
2. (+) Quick setup of a simple, minimal maintenance page
3. (-) Not suitable for creating sophisticated, visually-rich maintenance pages

Approach 2:

The web application is accessible through an Application Load Balancer (ALB). The ALB listens for HTTP traffic on port 80 and routes requests to Amazon Elastic Compute Cloud (EC2) instances that run the application's business logic. A static maintenance page, along with its CSS and font files, is hosted on Amazon Simple Storage Service (S3) as a static website. To enable maintenance mode, we create a new rule on the ALB's HTTP listener that redirects traffic to this maintenance page. ALB listener rules follow a priority-based execution system, where rules with lower numeric values have higher priority. To control traffic flow:

• Set the lowest numeric priority for the web application rule during normal operation
• Set the lowest numeric priority for the maintenance page rule during maintenance windows

When the application is in maintenance mode, the following process occurs:

1. The application owner increases the priority of the maintenance page rule (Priority Y) by setting the priority numeric value to be lower than the default rule (Priority X).
2. The application load balancer routes the user traffic to the maintenance page.

To disable the maintenance mode, increase the priority of the Default Rule to be higher than the maintenance page rule.

Figure 2

Below are the step by step instructions to create a new ALB listener rule to redirect traffic static website.

1. In the EC2 console, choose Load Balancers and choose the Load Balancer.

2. Choose Listeners and rules, select the Listener (Note: This example uses an HTTP listener for simplicity. In practice, it's strongly recommended to use HTTPS listeners for better security.)

3. Select Manage rules, and choose Add rule

4. Provide an appropriate recognizable name and choose Next

5. Choose Add condition, and provide your traffic routing condition for this rule, then choose Confirm

Note: In this example, condition is set to match all Source IP from the internet.

6. Choose Next.

7. Select Redirect to URL and then select Full URL.

8. Provide the static Maintenance Page URL from S3 Static website hosting and provide the appropriate HTTP code. (Note: In this example, HTTP 302 code has been configured)

9. Choose Next

10. Provide appropriate rule Priority between 1 - 50,000, choose Next and choose Create.

11. The new rule has been deployed successfully.

12. Now you can test the availability of your application www.example.com

Pros and Cons :

• (+)This approach enables seamless traffic redirection without code changes, requiring only ALB listener rule priority adjustments. (Note that implementing this solution requires appropriate ALB configuration permissions.)
• (-) The users gets redirected to a different domain

Automation and Operations

For manual operations to change the ALB rule priority from AWS CLI :

# Example AWS CLI command for ALB rule priority update:

aws elbv2 modify-rule \ --rule-arn arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/my-load-balancer/<aws account number>/<aws account number> \ --priority 1

Approach 3

CloudFront with ALB and secondary origins:

Figure 3

CloudFront exposes the web application to users. The CloudFront distribution has two origins:

1. A load balancer serving the web application
2. A static error page

The error page can be hosted in S3 as a static website, or deployed as an Amplify application as shown in Figure 2.

CloudFront's custom error response handles HTTP errors from the web application origin. The response page path points to the static error page. The CloudFront distribution behavior fetches the custom error page from the second origin.

When the application is in maintenance mode, the following process occurs:

1. The web application is in maintenance mode and returns HTTP error to the ALB
2. The ALB returns the received HTTP error to the CloudFront distribution
3. CloudFront requests the custom error page from the second origin
4. CloudFront displays the error page to the user

This approach maintains the original URL and presents users with an error page automatically when CloudFront receives an HTTP error from the web application origin.

Below are the step by step instructions to implement the custom error page:

1. In CloudFront console, choose on Create distribution
2. Create your first origin to your web application ALB:

Note: Configure the CloudFront distribution settings as per the application and business needs.

3. Select the created CloudFront distribution, go to Origins tab and choose Create origin

4. Under Origin domain, choose the S3 bucket where the custom error pages html has been hosted:

Note: It is recommended to restrict the access to S3 bucket from CloudFront distribution only. This is achieved using origin access control

5. Choose Create origin

6. Select Error pages tab **** and choose Create custom error response

7. Select the HTTP error code that the web application will return when it is under maintenance

8. Under Customize error response select Yes

9. Configure the Response page path to the URI of custom error page in the S3 bucket and Choose Create custom error response

Note: Configure the HTTP Response code based on the business needs

10. Select Behaviors tab and choose Create behavior

11. Under Path pattern configure the path of the custom error page and under Origin and origin groups configure the S3 bucket origin hosting the custom error page

12. Configure the remaining behavior settings as per the business needs and choose Create behavior

The custom error page has been successfully setup. The error page will be automatically displayed when the web application returns the configured HTTP error code, as in step 9.

Pros and cons

• (+) Users stay on your website's domain
• (+) Maintenance mode toggles automatically without manual work
• (+) Supports sophisticated, visually appealing maintenance pages
• (-) Requires initial setup effort

Conclusion

When designing your maintenance page strategy, consider starting with simpler solutions and evolving as requirements grow. The flexibility of AWS services allows for this evolutionary approach while maintaining security and operational efficiency.

Remember that the goal is not just to handle downtimes, but to do so in a way that maintains user trust and operational excellence. A well-implemented maintenance page strategy is an important component of your overall application reliability and user experience management.

For most organizations, a progressive implementation approach works best:

• Start with basic functionality
• Add enhanced features based on needs
• Implement automation as processes mature
• Continuously improve based on feedback

Authors:

Hector Ibarra: With two decades immersed in the ever-evolving tech landscape, Hector is on a mission to catalyze innovation and empower enterprises to thrive in a digital world. His expertise lies in decoding intricate challenges, particularly within manufacturing, finance, and digital realms. As a Principal Solutions Architect, he bridges gaps between vision and reality, guiding organizations across EMEA and America toward transformative journeys, nurturing talent, and driving tangible business results.

Prateek Sethi: As a Senior Technical Account Manager, Prateek excels in architecting and implementing complex distributed systems, particularly transforming operations for global manufacturing and retail organizations. His passion for customer success drives him to nurture long-term partnerships, guiding organizations through their digital transformation journeys while ensuring optimal outcomes. When not solving technical challenges, Prateek enjoys exploring european cities on his motorcycle.