{"id":2567,"date":"2023-02-12T23:33:29","date_gmt":"2023-02-12T23:33:29","guid":{"rendered":"https:\/\/www.antpace.com\/blog\/?p=2567"},"modified":"2025-08-25T18:03:11","modified_gmt":"2025-08-25T18:03:11","slug":"redirecting-traffic-from-ec2-public-dns-to-a-domain-name","status":"publish","type":"post","link":"https:\/\/www.antpace.com\/blog\/redirecting-traffic-from-ec2-public-dns-to-a-domain-name\/","title":{"rendered":"Redirecting Traffic from EC2 Public DNS to a Domain Name"},"content":{"rendered":"

I searched Google for my own website, and noticed that some results were returning with my EC2 instance’s public hostname: http:\/\/ec2-18-191-145-67.us-east-2.compute.amazonaws.com\/<\/em> – That’s a bad look for branding, and I figured it couldn’t be good for SEO. I fixed it by adding a new rewrite condition to my apache server’s httpd.conf<\/strong> file. The server runs on a Linux 2 image, and I found that file in this directory: \/etc\/httpd\/conf\/<\/strong>.<\/p>\n

Initial Configuration<\/h2>\n

I already had a Virtual Host block that listens on port 80, responsible for making sure all traffic going through my domain name goes to the https:\/\/www.antpace.com<\/strong>. I just had to add the public DNS to the ServerAlias statement and add an additional RewriteCond statement:<\/p>\n

\n<VirtualHost *:80>\n    DocumentRoot \"\/var\/www\/html\"\n    ServerName \"antpace.com\"\n    ServerAlias \"www.antpace.com\" \"ec2-18-191-145-67.us-east-2.compute.amazonaws.com\"\n    RewriteEngine on\n    RewriteCond %{HTTP_HOST} ^ec2-18-191-145-67.us-east-2.compute.amazonaws.com$ [OR]\n    RewriteCond %{SERVER_NAME} =antpace.com [OR]\n    RewriteCond %{SERVER_NAME} =www.antpace.com\n    RewriteRule ^ https:\/\/www.antpace.com%{REQUEST_URI} [END,NE,R=permanent]\n<\/VirtualHost>\n<\/pre>\n
Handling SSL Traffic<\/h2>\n
After restarting the server, I did another search, and saw some pages still returning with the SSL encrypted address https<\/strong>:\/\/ec2-18-191-145-67.us-east-2.compute.amazonaws.com\/<\/em>.<\/p>\n
\"SERP\"<\/p>\n
To handle traffic going there, I needed to add another Virtual Host block that would listen on port 443. You’ll notice that I had to reference my SSL certificates that were installed via Let’s Encrypt<\/a>.<\/p>\n
<VirtualHost *:443>\n    DocumentRoot \"\/var\/www\/html\"\n    ServerName \"antpace.com\"\n    ServerAlias \"www.antpace.com\" \"ec2-18-191-145-67.us-east-2.compute.amazonaws.com\"\n\n    SSLEngine on\n    SSLCertificateFile \/etc\/letsencrypt\/live\/antpace.com\/fullchain.pem\n    SSLCertificateKeyFile \/etc\/letsencrypt\/live\/antpace.com\/privkey.pem\n    SSLCertificateChainFile \/etc\/letsencrypt\/live\/antpace.com\/chain.pem\n\n    RewriteEngine on\n    RewriteCond %{HTTP_HOST} ^ec2-18-191-145-67.us-east-2.compute.amazonaws.com$ [OR]\n    RewriteCond %{HTTP_HOST} ^antpace.com$ [OR]\n    RewriteCond %{HTTP_HOST} ^www.antpace.com$\n    RewriteRule ^ https:\/\/www.antpace.com%{REQUEST_URI} [END,NE,R=permanent]\n<\/VirtualHost>\n<\/pre>\n
Unfortunately, adding this block broke the site temporarily. It resulted in a redirect loop, in tandem with the previous block. I tried to adjust them both, resulting in the following:<\/p>\n
<VirtualHost *:80>\n    DocumentRoot \"\/var\/www\/html\"\n    ServerName \"antpace.com\"\n    ServerAlias \"www.antpace.com\" \"ec2-18-191-145-67.us-east-2.compute.amazonaws.com\"\n\n    RewriteEngine on\n    # Redirect all HTTP traffic to HTTPS\n    RewriteCond %{HTTPS} off\n    RewriteRule ^ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]\n<\/VirtualHost>\n\n<VirtualHost *:443>\n    DocumentRoot \"\/var\/www\/html\"\n    ServerName \"antpace.com\"\n    ServerAlias \"www.antpace.com\" \"ec2-18-191-145-67.us-east-2.compute.amazonaws.com\"\n\n    SSLEngine on\n    SSLCertificateFile \/etc\/letsencrypt\/live\/antpace.com\/fullchain.pem\n    SSLCertificateKeyFile \/etc\/letsencrypt\/live\/antpace.com\/privkey.pem\n    SSLCertificateChainFile \/etc\/letsencrypt\/live\/antpace.com\/chain.pem\n\n    RewriteEngine on\n    # Redirect all non-preferred hostnames to the preferred hostname\n    RewriteCond %{HTTP_HOST} ^ec2-18-191-145-67.us-east-2.compute.amazonaws.com [NC,OR]\n    RewriteCond %{HTTP_HOST} ^antpace.com [NC]\n    RewriteRule ^ https:\/\/www.antpace.com%{REQUEST_URI} [L,R=301]\n<\/VirtualHost>\n<\/pre>\n
Although this configuration resolved the redirect loop, it failed to address the original issue. I discovered that my system had a separate configuration file for SSL traffic: \/etc\/httpd\/conf.d\/ssl.conf<\/code>. I added the redirect rule and certificate references to the 443 Virtual Host block within this file, but the redirect issue persisted.<\/p>\n
Diagnosing the Issue<\/h2>\n
Executing sudo apachectl -S<\/code> revealed a conflicting Virtual Host on port 443 in httpd-le-ssl.conf<\/code>. I moved the rewrite rules to this file, yet the redirect remained elusive. Suspecting a browser cache issue, I verified the redirect using curl<\/code>:<\/p>\n
\"301<\/p>\n
The 301 Moved Permanently<\/code> response confirmed the redirect to https:\/\/www.antpace.com<\/code>. Since the redirection works when tested with curl -k<\/code> but not in a browser, the issue likely stems from the browser not accepting the SSL certificate due to the mismatch. Browsers are more strict with SSL certificate validation than curl -k<\/code>.<\/p>\n
I attempted to add the public host name as a subject alternative name (SAN) in my existing SSL certificate, but Let’s Encrypt refuses to issue certificates for EC2 hostnames. This restriction is due to Let’s Encrypt’s policy to prevent abuse. To circumvent this, I generated a self-signed certificate:<\/p>\n
sudo mkdir<\/span> -p \/etc\/ssl\/private\nsudo mkdir<\/span> -p \/etc\/ssl\/certs\nsudo chmod 700 \/etc\/ssl\/private\nsudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout \/etc\/ssl\/private\/ec2-selfsigned.key -out \/etc\/ssl\/certs\/ec2-selfsigned.crt\n<\/pre>\n
Final Configuration<\/h3>\n
I created a new Apache configuration file for the EC2 redirection and ensured no conflicts with existing configurations:<\/p>\n
sudo nano \/etc\/httpd\/conf.d\/ec2-redirect.conf\n<\/pre>\n
Here’s the contents:<\/p>\n
<IfModule mod_ssl.c>\n<VirtualHost *:443>\n    DocumentRoot \"\/var\/www\/html\"\n    ServerName \"ec2-18-191-145-67.us-east-2.compute.amazonaws.com\"\n\n    SSLEngine on\n    SSLCertificateFile \/etc\/ssl\/certs\/ec2-selfsigned.crt\n    SSLCertificateKeyFile \/etc\/ssl\/private\/ec2-selfsigned.key\n\n    RewriteEngine on\n    # Redirect EC2 URL to the preferred domain\n    RewriteRule ^ https:\/\/www.antpace.com%{REQUEST_URI} [L,R=301]\n<\/VirtualHost>\n<\/IfModule>\n<\/pre>\n
\n
<\/div>\n<\/div>\n
Upon restarting Apache, the 301 redirect functioned correctly in the browser, albeit with an initial security warning due to the self-signed certificate. Accepting the certificate led me to the desired URL. This project underscored the importance of meticulous configuration and validation in managing web traffic and ensuring optimal SEO performance.<\/p>\n
Pro-tip:\u00a0<\/strong>Each time I had to edit any of these sever configuration files, I did so from the command line using the Nano text editor. I learned along the way that I could select multiple lines of text by pressing “Ctrl + Shift + 6”, pressing the arrows to expand the selection, and then “Ctrl + K” to remove content.<\/p>\n
Alternative Approaches<\/h3>\n
To stop this problem from arising, even to begin with, we can take an alternative approach. It is possible, when creating a new EC2 instance, to disable the auto-assign public IP address in the network settings.\u00a0This will launch the instance without a public IP address.<\/p>\n","protected":false},"excerpt":{"rendered":"
I searched Google for my own website, and noticed that some results were returning with my EC2 instance’s public hostname: http:\/\/ec2-18-191-145-67.us-east-2.compute.amazonaws.com\/ – That’s a bad look for branding, and I figured it couldn’t be good for SEO. I fixed it by adding a new rewrite condition to my apache server’s httpd.conf file. The server runs … <\/p>\n
Continue reading “Redirecting Traffic from EC2 Public DNS to a Domain Name”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":3261,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[8,77,114],"class_list":["post-2567","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development","tag-apache","tag-linux","tag-seo"],"_links":{"self":[{"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/posts\/2567","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/comments?post=2567"}],"version-history":[{"count":1,"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/posts\/2567\/revisions"}],"predecessor-version":[{"id":3262,"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/posts\/2567\/revisions\/3262"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/media\/3261"}],"wp:attachment":[{"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/media?parent=2567"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/categories?post=2567"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.antpace.com\/blog\/wp-json\/wp\/v2\/tags?post=2567"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}