Digital Development
Web Design

The S3 service provided by Amazon Web Services (AWS) is a very useful storage solution. As part of the AWS free usage tier you can get started with Amazon S3 for free. Upon sign-up, new AWS customers receive 5 GB of Amazon S3 standard storage, 20,000 Get Requests, 2,000 Put Requests, and 15GB of data transfer out each month for one year. The following post is a quick guide to setting up static website hosting in the cloud hosted by AWS and focuses on transferring your existing domain hosted from another provider.

Getting Started

Once you've signed up for the free tier on AWS access the S3 management console. Create 2 buckets eg. example.com and www.example.com, these will act as your root directories. Upload all relevant files/folders to each bucket.

Configure bucket permissions

The first step in configuring your buckets is to allow public access via bucket policies and thus make the objects that you want to serve publicly readable. In order to achieve this you need to write a bucket policy that grants everyone s3:GetObject permission. If a user requests an object that does not exist, Amazon S3 returns HTTP response code 404 (Not Found). If the object exists but you have not granted read permission on the object, the website endpoint returns HTTP response code 403 (Access Denied).

To edit a bucket policy through the S3 console simply click on Properties>Permissions>Edit bucket policy.

An example of such a policy can be seen below, note to enter your appropriate bucket name:

{
"Version":"2012-10-17",
"Statement":[{
"Sid":"PublicReadGetObject",
"Effect":"Allow",
"Principal": {
"AWS": "*"
},
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::bucket-name-here/*"]
}]
}

Add CORS configuration

Cross-origin resource sharing (CORS) selectively allows websites/applications to access resources across different buckets/domains. Simply put, the CORS configuration is an XML document with rules identifying the origins that you will allow to access your bucket, the operations (HTTP methods such a GET, POST etc.) supported for each origin, and other operation-specific information. You can add up to 100 rules to the configuration. An example of such a configuration can be seen below.

<CORSConfiguration>
<CORSRule>
<AllowedOrigin>http://www.example.com</AllowedOrigin>
<AllowedMethod>PUT</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>DELETE</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
</CORSRule>
</CORSConfiguration>

Configure bucket for hosting

While in your S3 console, access Properties>Static Website Hosting>Enable website hosting and enter the name of the file within your bucket which will act as your site/app homepage, e.g. index.html. If your permissions have been set correctly you can now enter your endpoint (listed under Properties>Static Website Hosting) into the browser and test if it directs you to the assigned homepage.

Almost there! Finally we need to inform your current hosting provider that we will now be hosting through AWS.

Configure Amazon Route 53 as your DNS provider

In this final stage of setup you need to accomplish the following:

Create a hosted zone on AWS Route 53. Transfer resource record sets from your current DNS provider to AWS Route 53. Update your registrar's name server (NS) records to refer to the Route 53 name servers.

In order to serve content from your S3 buckets to your domain you must use Amazon Route 53 as your DNS provider. Go to Route 53 through your AWS Console and create a hosted zone for your domain. Upon creating a hosted zone, Route 53 automatically creates four name server (NS) records and a start of authority (SOA) record for the zone. The NS records identify the name servers that you give to your registrar or your DNS service so that queries are routed to Route 53 name servers. At this point you will need to access the DNS record sets from the DNS service provider currently servicing the domain. These are likely to include the following:

A (Address) records, which associate a domain name with the IP address of the home page for the domain. Mail server (MX) records. CNAME records, which reroute queries for one domain name to another domain name Other A records, CNAME records, or other supported DNS record types.

Once you've retrieved this information from your current provider, create corresponding resource record sets in the Route 53 hosted zone.

After your changes to Route 53 resource record sets have propagated to the Route 53 DNS servers (can take up to 30mins), update your registrar's name server (NS) records to refer to the Route 53 name servers (these can be found in the Route 53 console). If your current provider has a method to change the TTL settings for their name servers, reset the settings to 900 seconds. This limits the time during which client requests will try to resolve domain names using obsolete name servers. You will need to wait for the duration of the previous TTL for resolvers and clients to stop caching the DNS records with their previous values. A common default setting is 172800 seconds (two days). After the TTL settings expire, you can safely delete the records that are stored at the previous provider and make changes only to Route 53.

You're now set up to host your static website on the cloud using AWS!

My next plan is to transfer a Wordpress site to AWS using their EC2 (Elastic Compute cloud) service and also to set up an Expression Engine site on EC2.

The sky is the limit with the cloud..and the sky is endless, right!