Setting up Amazon Elastic Load Balancing: with email forwarding and redirects

The release time of my weekend project was drawing near. Mobile applications were uploaded to the app stores and we were waiting for an answer from Apple, because the verification on Google Play is quite quick and painless. All the server application code was already written, there was nothing to do, and there was about a week of free time. I thought that it would be nice to get a load balancer in advance so that you do not spend a lot of time setting it up in the future, and besides, setting up after release would surely cause the server to stop serving users for some time. For server hosting, we used Amazon EC2, so the load balancer chose Amazon - Amazon Elastic Load Balancer (ELB).

As it was

The domain was registered with Internet.bs , on ec2 the server was assigned a permanent ip address through elastic ip. Accordingly, the domain registrar had a record of type A (A record), which pointed to this ip. Also, the good registrar provided the opportunity to set up email forwarding, which I gladly took advantage of to receive mail sent to feeback@imyarek.com to my mailbox. The registrar was also able to redirect from one subdomain name to another, which I used to redirect all users from www.namek.com to namerek.com. When moving, I wanted to save all this without installing additional servers and applications, and even more so there was no desire to write additional code.

Relocation: ELB, Route53, and NS Records

The first thing I did was set up ELB. Everything is pretty simple: in EC2, on the Load Balancers tab, click on Create Create Load Balancer and through a convenient dialog we select which server ports will correspond to which ELB ports, configure Health Check (periodically checking the availability of some URL on the ELB server will determine which servers are “alive”, and which ones should not be sent requests, because they do not respond), and we select the servers to which the load will be distributed. All these parameters can then be changed on an already working ELB. By the way, if your web application uses HTTPS, I recommend that you configure it on ELB, and use http on the application servers, this will greatly load your servers. In our case, this allowed us to process several times more requests per second.

Then it was time to bind the domain to ELB, because although ELB was not configured, the server with the application was still used directly. Since ELB has a dynamic ip address, binding it simply with A record will not work. To do this, you will have to use another Amazon service - Route 53. To do this, create a Hosted Zone with our domain name. This will create 2 records - NS and SOA. To bind a domain to the Hosted Zone, you need to create or replace the NS record at the domain registrar with the values ​​from the NS record of the Hosted Zone. Next, you need to specify what our domain will correspond to, for this you need to create an A (A record) record in the Hosted Zone with the alias option selected and select our ELB in the Alias ​​Target drop-down list.



After that, our server again became available at the old address. But he began to respond only to requests to the address without www, and the address with www did not answer at all.

We configure 301 Redirect to a domain without www from a domain with www

You can configure and vice versa, the setting will be completely similar. Why is 301 Redirect and not another A record pointing to the same ELB? From the point of view of search engines, in this case we will have two sites with completely identical content, and search engines do not like to say the least.
Setting up a redirect turned out to be far from as easy as it could be done with our registrar. As a solution on the forums and on Stack Overflow, configure a redirect in Apache or nginx, but these solutions did not suit us, since our application server is Apache Tomcat. I did not want to put another server in front of him - the response time was unpleasant. It was also proposed to write code with the appropriate logic, but did not want to do this at all.
Nevertheless, a solution was found, although it was not at all obvious. To do this, we will need to create an S3 Bucket with the name of the domain from which we want to redirect users. It is important to create it with the domain name, otherwise you won’t be able to bind this bucket to the domain in Route 53 later. In the created bucket, in the Properties menu, select the Static Website Hosting option and the Redirect all requests to another host name option. Enter the domain name to which users will be redirected and save the configuration.



Then, in Route 53 in the Hosted Zone of our domain, create an A record for the domain name with www (or without) with the alias option and indicate our created S3 bucket as alias target.



Well, now our domain is accessible with www and without www and even correctly redirects the user to the option we have chosen.

Email Forwarding

Unfortunately, setting up Email Forwarding with Amazon services will not work, because there is simply no such service. But I found an excellent service ImprovMX , which allowed me to set up email forwarding in just a minute. Instructions for setting up (if you can call it that because it only takes one action) are on the site itself. All you need to do is create an MX record in the Hosted Zone with the following contents:

10 mx1.improvmx.com 
20 mx2.improvmx.com

It remains only to enter the domain name and the mailbox on the site to which letters will be redirected.

Conclusion

What we got as a result: load balancing between our application servers, while maintaining the necessary functionality - redirection to a domain without www from a domain with www and email forwarding. The bonus was an increase in productivity, as well as the ability to quickly increase productivity, simply by adding multiple servers. Thanks for attention.