AWS Route53 Step-by-Step – Redirecting Domains GUI

While I’ve covered this one before with a specific two-step approach to do simple redirect.  This will repeat some of those steps with a new domain pointing to an alternate web site URL.  This is a real use-case example where I’ve bought a new domain that I want redirected to as the target.

Sample source zone: 

Sample target website:

Using Route53 to Redirect to a New URL

My sample domain was registered with Route53.  You can see the registration message here:


A Hosted Zone is created automatically as part of the registration process:


Highlight the radio button and use the Go to Record Sets button.  That lets us create a new entry with the Create Record Set button.  Because we want to redirect the default www zone, let’s create a CNAME record for that and directly assign in the Value field:


We need to redirect the root domain of as well, but we can’t use a CNAME for a root record.  This means we need to create a S3 bucket for the root zone.  Name it after the domain you’re redirecting:


Set up the Static Website Hosting section in the properties window for the S3 bucket, and put the target domain under the Redirect all requests to another host name section:


We may have to exit and reenter the Route53 zone to refresh, so once you’re done with that, set up a new A record, click the Alias radio button to Yes, and click the Alias Target field to trigger the drop down list where you can select the S3 website endpoint that matches the domain root:


Wait for a few minutes.  10-15 minutes will ensure that the TTL for the zone and record are passed and it forces a fresh request to the root domain.

Using the AWS CLI (aka AWS Shell) to Query Route53 Hosted Zones

You will need to install the AWS CLI on your machine, or you can also use my sandbox method to run it inside a VirtualBox VM to save installing in your workstation.

Once configured, we will use the following command to list all of the zones:

aws route53 list-hosted-zones-by-name


You will see all of the available zones come back.  Clearly that is more detail than we want, so let’s add a couple of parameters which will reduce the output to just the zone we want --dns-name (note the trailing dot is important).  That still returns a series of zones, so we also add the --max-items 1 parameter as well:


We can confirm the redirects using the cURL command for both domain names using the cURL command and the -IL parameter to show the HTTP response details:


In our next post, we will be doing some DNS record management using the AWS CLI to emulate the changes we did in the GUI in this article.

Run the AWS Shell Quickly and Easily in a VirtualBox Instance Using Vagrant

Because we like the Martha Stewart pre-baked oven version of things, this is the shortcut to running the AWS CLI without having to dirty up your own local environment.

Why use a Sandbox?

While development entirely using your local machine is handy, there can often be configuration issues, and also conflicts with other development libraries. In my earlier post, you saw how to configure a basic sandbox environment. I’m assuming that you’ve already got the following installed as documented in that post:

  • Git client
  • Vagrant
  • VirtualBox

This is how to deploy and configure the AWS Shell environment using a sandbox server in just a couple of simple steps!

Clone the GitHub Repo

From your command line, you can just run a git clone to get ready with all the Vagrant code:


Next, we change into the directory and we run a vagrant status to confirm that the configuration is ready to run:


We can see that it says not created for the machine, so let’s run vagrant up and get this party started!


Once the process is completed, you will see this message:


What’s in the GitHub Repo to make AWS CLI work?

The basic build of a sandbox machine was documented in my previous post, and the secret sauce for this is really quite easy. The only reason I like this approach is that I have a super simple deployment of a purpose-built machine to test out AWS CLI work. All with two simple statement:

sudo apt-get install -y python-pip sudo pip install aws-shell

Yes, it is just that easy.

Once the machine completes the installation, you are ready to log in to the console and give it a try. We do this by running vagrant ssh awssandbox:


Et voila! You are now ready to start up the AWS shell.

Configuring and Running AWS Shell

The environment is all installed. Now, we need to run our AWS shell which will do some basic configuration at the first launch:


After the console comes up (it takes about 30 seconds to build the autocomplete cache), we have to configure it to use our AWS credentials.

When we start to type the configure command which you will see does an autocomplete:


The three pieces of information you need to configure the AWS shell are your Access Key, your Secret Access Key, and the Region name you are working within. Just like with the web client, you have to choose a default region to explore. That can be changed again at any time by re-running the configure command:


We are all set with our configuration, and you can start typing away on the AWS shell commands. There is an autocomplete function on everything, and you can even scroll up and down when the autocomplete suggestions come up:


For example, we can list the regions by using the ec2 describe regions command that outputs a JSON response of the available regions:


We can also use the ec2 describe instances command to list out any active instances that are in this region under our account:


The output will span a couple of screens in a prompt window, but luckily we can scroll up or down and also copy the content out from the shell to evaluate in a text editor if you so desired.

There are literally hundreds of commands, but the main thing we wanted to see here was how to just get the basic configuration up and running so that you can start exploring.

To exit, you can use F10 or Ctrl-D to go back to the Linux shell prompt.

Now you have your AWS shell environment ready to save and reuse as needed without having to deploy anything on your home environment. Another advantage is that you can snapshot this one, run it on any platform that supports VirtualBox, and not worry about versioning or anything at all with dependencies at the OS level.