If you are hosting a ASP.NET App using an AWS Elastic Load Balancer (or Elastic Beanstalk), you may want to redirect all requests to another site, or rewrite all requests to a holding page for some amount of time.
With a ASP.NET applications and AWS there are many ways of doing this, In this post I’m going to look at two options that you may have used when working on a site running “On-Premise” (Note this does not mean these are necessarily the best ways to take your site offline whilst hosting on AWS). “HTTP Redirect” in IIS and App_Offline.htm.
Both of these approaches run into the same problem when using AWS Load Balancers – they cause the Health Check to fail, as they don’t return a 200 status code. This causes the load balancer to remove the instance from the pool available, once all instances are in this state users will start seeing a blank white page as no servers are available to handle the request. One way to solve this problem is to use the URL Rewrite module to achieve the same result instead.
You can use the IIS “HTTP Redirect” feature in IIS to redirect all requests, this will include your Health Check and you can’t specify that this is ignored. Assuming you have the URL Rewrite module installed on your server you can add the following snippet to the system.webServer section of your web.config file. This assumes your health check endpoint is “health-check.aspx” and you are redirecting to “http://holding.somesite.com”.
IIS allows you to take your site offline using an App_Offline.htm file, again this affects all requests so will include your health check. Again the URL rewrite module can be used to achieve the same effect. Assuming you have the URL Rewrite module installed on your server you can add the following snippet to the system.webServer section of your web.config file. This assumes your health check endpoint is “health-check.aspx” and your holding page is “holding.htm”
Nice article and hope you're well! I've added some rewrite rules in to my web.config and tried to deploy it out via AWS. However, I now get an error as follows:
"Error: Config section 'system.webServer/rewrite/rules' already defined. Sections must only appear once per config file."
I'm assuming that is because the beanstalk deployment adds its own 'rewrite' section under system.webserver to the web.config, which then causes a conflict with my rules.
To compound the problem above, I am now also unable to re-deploy the old version, or a new version with the rewrite rules removed, as I just keep getting the same error with each attempt (the error appears to be cached with each deployment somehow). I have, of course, tried to restart the App Server through the AWS console, but it makes no difference. Do you have any ideas on how we can 'inject' rewrite rules into the web.config of the deployed application? Needless to say, all of the above is working well on my local PC.
This article suggests that we can add a 'RoutingRules' section to the website configuration: docs.aws.amazon.com/.../HowDoIWebsiteConfiguration.html. However, adding that breaks the application locally, with the following error:
"The configuration section 'RoutingRules' cannot be read because it is missing a section declaration".
There's also this: docs.aws.amazon.com/.../how-to-page-redirect.html
But because the site is managed through Umbraco, and we don't have physical pages sitting on the web server, we can't do the above.
I'm good thanks! Hope your well too!
Beanstalk shouldn't be adding in any rewrite rules, unless there is something custom going on, the most obvious place for custom logic would be in the .ebextensions folder in the website root, although not sure how easy adding rewrite rules that way would be!
Might be worth downloading the website package the beanstalk is deploying, and seeing what's in the web.config there, possible a rewrite section is being added in elsewhere during the deployment/packaging process?
Hope this helps, let me know how it goes!
Thanks Rhys. Hope things are still going well with you. Turns out that we had a web.config transformation had an xdt:Transform="Insert" on the rewrite section of the web.config, hence why it was being added a second time.
That still doesn't explain why we were unable to re-deploy the old version though (with only one rewrite section in it). It was like it has cached the error, and got itself to a state where it kept displaying it even if there is only one rewrite section in the web.config in the zip file. So that bit is still a mystery. However, we have got around that by rebuilding the application and subsequently deploying, so we're in a good state again now.