A few friends of mine and myself are running a office share type of place, quite nice, I’d say. Plenty of parking space, free coffee, tea and table tennis, and people seem to like it

We had a landing page in WordPress, since, although all of us are in IT, we suck at design, so creating something on our own was out of the question. WP itself was not the problem, of course. It does an excellent job in providing a solid base with a healthy ecosystem of plugins and themes

Problem arose when we moved from a hosted instance of a cloud provider to a dedicated WP “all-around hosting solution” from a large web hosting company – and we haven’t been carefully reading the small print

Story was quite awesome when we initially transfered our WP site. Neat price of just 12 bucks for a year and no one had to regularly patch underlying Debian, Nginx, MySQL – it was all part of the pitch. However, after twelve months passed, we received a new yearly bill that was closer to 90 bucks!

It’s not a big deal, we tend to earn some money from the business, but this thing was a 7x price increase, for no extra benefit. Therefore, it was irritating and unfair, so we decided to move our landing page away from this tyranny and redo it in the same time

For the task of rebuilding the page, we used a free tool called Mobirise and patched up a fine single page in a few hours. A few pictures here and there, pricing model with benefits of different tiers, location and other ways of reaching us, all sprinkled with a parallax or two, since everyone seems to like these today

Site was responsive and easily packed in a tar.gz for distribution, and now back on a regular VM instance in the cloud. Although we were now paying about a 70% of dedicated WP hosting price for the cloud VM, and had to do all the maintenance on our own, we were more than satisfied in moving away from the vultures

From there, we decided to go one step further and transfer everything to Amazon S3, and below is the brief outline of how to achieve that in a quick fashion

Up and away

We’re using quickstart-website bootstrap from AWS in order to speed up content upload, but we’re not relying on CloudFront or Route 53 which go alond with. Latter is related to DNS setup, while most rely on their domain provider, and the CF part is about enabling HTTPS over S3 and distributing content geographically. In case of our office share business, neither was needed, but if you require any of above, use URL from CloudFront as your domain’s CNAME and enjoy

We’ll be creating a separate user for hosting as a good practice to distinguish projects, users and permissions. Uploading website content will be next, followed up with disabling automatically created CloudFront distribution(s). Bucket replication with permissions, policies, and Static website hosting setup follows and last step is simply pointing your domain to S3 bucket via a CNAME and happily reloading

IAM

• Go to console.aws.amazon.com/iam
  • Make a note of IAM users sign-in link, for logging with non-root account
• Create user
  • Check Programmatic access and AWS Management Console access
  • Set a password and uncheck Require password reset
• Attach policies
  • Add AmazonS3FullAccess and CloudFrontFullAccess

Write down Access key ID and Secret access key, since latter won’t be available for retrieval afterwards

Host a static website

• Login with new user and go to console.aws.amazon.com/quickstart-website

• Select Your website

  • Upload your entire site in ZIP

We’re neatly skipping separate file upload to S3 which requires more time to setup via AWS CLI

Disable CloudFront

• Go to console.aws.amazon.com/cloudfront

• Disable and delete distributions

  • If reduntant distributions have been created, select one and choose delete
  • Perform Disable action on the remaining (or single one) and follow that up with deletion

Disabling might take time, keep track of it’s status

Replicate bucket

• Go to console.aws.amazon.com/s3
  • Select your new, automatically created bucket
• Mark all objects and select Copy

• Create a new bucket with identical name as your website
  • Select original bucket to copy settings from
  • Enable read for Object{s, permissions} for Everyone in Manage public permissions
  • Paste objects with More / Paste

If you want to cover both {,www.} – create other bucket and enable Redirect requests to original one

Bucket propagation

• From same, newest bucket, select Static website hosting from Properties
  • Choose Use this bucket to host a website and set index (index.html in most cases)
  • Note the Endpoint link in the first line

• Select Bucket Policy from Permissions tab
  • Create policy to allow object get, per AWS reference

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

Update Resource with your bucket / domain name

Note that buket policy Versions cannot be arbitrary, but predefined values

CNAME the endpoint

• Update DNS record within your domain provider
  • Set retrieved endpoint as a CNAME record
  • (Optionally) add {,www.} as another

Takeaways

Distributed web-based storage is good, read the small prints and stay in school