Configuring an IPv6 Website in AWS
In this blog, we’ll walk through the steps of configuring an IPv6-enabled website in AWS using the web interface. But before we get started…
Why You Need an IPv6-enabled Website in the First Place
The number of IPv6-enabled users has increased dramatically in recent years. Here in the US, the number of IPv6 users measured as a percentage of all Internet users and traffic has quadrupled from 10 to just under 40 percent in just over three years (Fig. 1).
Fig. 1 – US IPv6 Traffic to Google over IPv6
With an overall US population of 325 million and Internet penetration at 70%, this means that there are 91 million IPv6 users in the US alone.
The primary reason for this growth is due to service providers in the US who have embraced and adopted IPv6. They have come to recognize such adoption as a critical part of their overall strategy to remain competitive (Fig. 2 & 3).
Fig. 2 – T-Mobile IPv6 Traffic: 94%
Fig. 3 – Verizon IPv6 Traffic: 86%
A similar trend is observable globally (Fig. 4).
Fig. 4 – Global Internet Traffic to Google over IPv6: 24%
The other main reason for the increase in IPv6 users and resulting traffic levels is IPv6-enabled content. The largest content providers such as Google, YouTube, Netflix, Facebook, and LinkedIn are all accessible over IPv6. Some of the largest SaaS providers like Microsoft Office 365 and Google’s GSuite are IPv6 enabled, too. Meanwhile, CDNs like Akamai and Cloudflare make it easy for their subscribers to enable IPv6 for their websites. In fact, IPv6 is enabled for nearly all of Cloudflare’s subscribers.
To learn more about overall IPv6 adoption trends, please download the 2018 IPv6 Adoption Report from HexaBuild.
While none of this will come as news to the regular perusers of this blog, the relatively quick pace of this increase has left many otherwise knowledgeable and well-informed IT personnel unaware of this fundamental shift in the composition of the Internet traffic.
As a result, they’re also probably unaware that by not having their web content IPv6-enabled they’re running the risk of 91 million (and growing) IPv6 users suffering from performance issues accessing their IPv4-only content. This can happen because content requests over IPv6 must be translated to IPv4 at some point. Depending on how and where this translation is done, user experience can be negatively impacted. It’s also been demonstrated that content requests fulfilled entirely over IPv6 can perform better than ones fulfilled exclusively over IPv4.
By IPv6-enabling web content, these potential threats to performance and user experience can be reduced or eliminated (with the added possibility of a performance dividend for any of the 91 million IPv6-enabled users).
If you’re already using a CDN, your content may already be IPv6-enabled or you may need to issue a simple request or setting change to enable it.
Alternatively, if you use (or plan to use) AWS to host any web content, you might be curious as to how to IPv6-enable that content. The remainder of this blog will demonstrate how to create a simple IPv6-enabled website in AWS.
Starting with an AWS IPv4 Website
We’ll begin our process of configuring an IPv6-enabled website in AWS with one we’ve already configured for IPv4. There are a lot of readily available and thorough instructions on how to set up an IPv4 website in AWS. Therefore, we won’t go into all that background information here.
While AWS supports many website platforms such as LAMP, Windows Server, and Ruby on Rails, we’ll focus instead on building a basic static website using S3 (Fig. 5).
According to AWS, static websites support serving HTML, images, video, JavaScript, and files to visitors but don’t use application code. They’re perfect for sites that don’t require a lot of content modification such as basic marketing or even personal websites. They don’t cost much or need much administration and are reliable and scalable.
Fig. 5 – AWS Static Website using S3
A basic static website in AWS using S3 takes only a few minutes to set up. In our examples we are using the AWS management console to perform these configurations, but we could also automate this with scripts. I created a publicly-reachable S3 bucket (Fig. 6), configured a simple index.html and uploaded it (along with a Team ARIN graphic) (Fig. 7). Then I modified the parameters for the S3 bucket and enabled static website hosting, retaining index.html as the default index file (Fig. 8). Done. (Fig. 9). Now when we browse to the AWS regional public URL of the S3 bucket we see the page and the ARIN graphic.
Fig 6 – Bucket created.
Fig 7 – Uploaded index.html and graphic.
Fig 8 – Enabled static website hosting.
Fig 9 – IPv4-only AWS website accomplished.
Enabling IPv6 on an AWS S3 Static Website Using Cloudfront and Route 53
Now that our IPv4 website is up and running in AWS, let’s make it available over IPv6. This requires three steps:
- Configure a hosted domain in Route 53 (the AWS DNS service)
- Configure the site to be distributed using CloudFront (the AWS CDN)
- Create a record set in Route 53 with A and AAAA records pointing to the Cloudfront distribution
I’ll admit that this order of operations wasn’t intuitively obvious to me the first time I configured an AWS static website for IPv6. My initial assumption was that following the configuration of the hosted domain, I would simply point a AAAA record at the static website. But S3 static websites cannot be accessed directly over IPv6 at this time (though plain S3 buckets can be).
As a workaround, you have to make the website available using Amazon’s CDN CloudFront, which replicates the static website content from our S3 bucket and serves it from AWS cloud edge locations that are dual-stacked and can deliver it over IPv4 or IPv6. (Full disclosure: While the content itself is delivered over IPv6, the back-end origin fetch to the S3 bucket is performed over IPv4.) Then you can proceed to the final step of adding A and AAAA records to point at the CloudFront distribution of the site.
Configure a hosted domain in Route 53
The first step is to configure our static website to use a custom domain with Amazon’s DNS service Route 53. Using Route 53, I registered the domain ipv6enabled.net to use for this purpose for a modest sum of money. The next step is to create a hosted zone in Route 53 (Fig. 10 and 11).
Fig. 10 – Creating a hosted zone in Route 53
Fig. 11 – Hosted zone created
Configuring CloudFront to Distribute our Site
The next step is to configure CloudFront to distribute our site. Select “Create Distribution” (Fig. 12) then choose Web as the delivery method (Fig. 13).
Fig. 12 – Create a CloudFront distribution
Fig. 13 – Select the delivery method (web)
The next screen shows us the various options for creating our distribution. Most of these we leave as the defaults but in the Origin Domain Name dropdown menu we do need to select the S3 bucket where our static website resides (Fig. 14) and also input the Default Root Object (in this case index.html) (Fig. 15). Notice that you don’t need to check the Enable IPv6 box as it’s checked for you; i.e., enabled by default! Nice job AWS CloudFront!
Fig. 14 – Select the S3 bucket in the Origin Domain Name dropdown menu
Fig. 15 – Enter the default root object – often, “index.html” (and notice IPv6, enabled by default!)
Of course, keeping costs low is a basic value proposition of AWS, so we can choose a Price Class based on how broad and thus, high-performing, we want the distribution of our site to be. Recall that, as with any CDN, the more edge locations our content is replicated in, the faster the content can potentially be delivered to the end users. In our case, we’ll chose the cheapest option by selecting Use Only U.S., Canada and Europe (Fig. 16).
Fig. 16 – Select Price Class (i.e., the breadth and resulting performance of the distribution)
Next, we can enter a CNAME for our site distribution (Fig. 17). In this case, we’ll use www.ipv6enabled.net. Note that we haven’t yet set up an alias for this but will do so in Route 53 in our final step.
Fig. 17 – Input the site’s CNAME
Once we click Create Distribution, the AWS Flying Monkeys™ will stream forth to distribute the site to its network of selected edge locations (based on the Price Class we chose). Once this process is completed, the Status on the CloudFront Distributions page will change from In Progress to Deployed (Fig. 18). Then we can proceed to our final configuration step.
Fig. 18 – CloudFront Distribution Status Deployed
Now that our CloudFront distribution is configured we’ll need to create a record set in Route 53 with A and AAAA records pointing to our new CloudFront distribution.
Creating A and AAAA Record Sets in Route 53
The last step is to create a record set in Route 53 with A and AAAA records pointing to the CloudFront distribution. Returning to Route 53 we select our hosted zone and click on Create Record Set (Fig. 19 and 20).
(As a side note, if you’re running Infoblox vNIOS in AWS, you can synchronize DNS data from Amazon Route 53 to NIOS. This provides for visualization of DNS data across both on-premise networks and hybrid clouds.)
Fig. 19 – Select the Hosted Zone
Fig. 20 – Create a Record Set
Next, we enter the name of the subdomain we want to configure an alias for. In our case, that’s plain old “www.” Then we select the Type (we’ll do one for A then repeat this step for a AAAA). We then select “Yes” for whether or not it’s an alias. Finally, the Alias Target provides a dropdown list from which we select our CloudFront distribution (Fig. 21).
Fig. 21 – Configuring the Name and selecting the Alias Target
Once we click on Create to create the record, we’ll repeat the exact same process but select a AAAA record type instead. Once we’ve done that both of our records now appear in the hosted zone (Fig. 22).
Fig. 22 – A and AAAA records pointing to the CloudFront Distribution of our S3 Static Website
Now we can test to see if our website is reachable (Fig. 23).
Fig. 23 – It’s Alive (and reachable over IPv6)!
Finally, we can verify that the website is reachable over IPv6 by turning off IPv4 on the device we’re accessing the site with (assuming the device is dual-stacked and can reach the IPv6 Internet).
If you don’t have IPv6 locally configured you can use a site like http://ipv6-test.com/validate.php to validate that a website is IPv6-enabled (Fig. 24 and 25).
Fig. 24 – Externally validating a website is IPv6-enabled
Fig. 25 – Success!
That’s it! As you can see, setting up a basic IPv6-enabled website using AWS is actually pretty simple and takes very little time. Try configuring one and let me know how it goes in the comments!
Tom Coffeen (@ipv6tom) is a co-founder of HexaBuild, an IPv6 consulting and IPv6 training company. Tom is the author of IPv6 Address Planning on O’Reilly Media. You can follow HexaBuild on Twitter and LinkedIn.
