Goals:

• Setup a modern blog about my work in the crypto / trading domain.
• Learn (more about) the WordPress platform & ecosystem.
• Leverage my experience with Amazon / AWS while making use of all the relevant free-tier services.
• Achieve the lowest total cost.

A “recipe” for these goals:

1. Use Namebright.com because they sell .com domains for USD 8.53.

   HOST records management for A, CNAME, MX etc. types, is included as well as a free first-year of domain privacy.

   Alternative to free HOST records management would be to use AWS/Route53 for USD 6/year (minimum) since Rout53 does not have a free-tier.

2. Use MXRoute.com (affiliate) for email/inbox-only hosting with unlimited domains & emails plans starting at ~USD 25/ year: much cheaper than Google.Apps at USD 5/inbox-month.
3. Amazon / AWS hosting & free-tier services: Bitnami’s WordPress AMI on EC2; CloudFront CDN to improve performance for visitors around the globe; S3 storage for WordPress caching & backup; free SSL cert issued by Amazon, to get the cute green lock in the address bar.
4. I like Medium’s style so I selected a free WordPress theme Wilson which I thought would let me deliver my content in a similar way: thank you Anders Norén.

Valuable “cooking” lessons I learned:

• AWS’ SSL certs require domain ownership validation. You can choose to do so via a CNAME entry or by a confirmation email sent to the WHOIS contacts. My first attempt using the CNAME, timed out after 72h and I never understood what went awry. Luckily, the confirmation email showed up immediately and I was validated in mere minutes.
• RTFM: AWS certs for use with CloudFront MUST best requested/issued in the AWS/Virginia region.
• When browsers ask for https sites or are redirected (“forced”) from http-to-https, the browsers “expect” all links/content from the respective site/domain to be also delivered via “https”. Otherwise, we will get a security warning and the browser will “refuse” to display the page due to its mixed security content.
• WordPress serves all its content with fully qualified absolute URLs. Therefore, all content is http only or https only, depending on the protocol defined in the site name configuration.
• I setup CloudFront with the SSL cert and configured it to force http-to-https for all visitors irrespective of the protocol they might have requested. Therefore, CloudFront passes all requests to my EC2/WordPress “origin” also using https. In order for the WordPress to return all pages and their links with https only, I had to setup WordPress to also use https only and respond to CloudFront with the WordPress https & cert. Allowing WordPress to still use http results in mixed security content issues when pages are processed by the clients’ browsers.
• Since CloudFront does not accept https from “self-signed” certs, I had to install a legitimate “Let’s Encrypt” SSL cert specific to my domain, on the EC2/WordPress server. Originally, I hoped to avoid this as I mistakenly assumed that the AWS’ cert on CloudFront would suffice.
• I wanted the AWS’ cert for the entire site. Therefore, I had to configure CloudFront to use my own domain name in the “alternative domains” setting. When I attempted use CF’s default domain in the WordPress CDN/cache settings I got “could not contact origin” errors.
  Btw, CF’s default domain name goes into host/CNAME records (“@” and “*”).

Conclusions & unresolved “mysteries”:

• I was somewhat wrong about https and caching. When I had to setup https on the EC2, I thought that the CDN would not cache any assets. Page performance by GTmetrix and Response/HEADERS indicate that content is being served by the CDN. I have configured an S3 “origin” to offload some assets for caching but I am not sure if CF is using S3 over http or EC3 over https and then caching after decryption.
• My EC2 does have to do more processing than I originally hoped because it must encrypt/decrypt all its communication with CloudFront.
• Domain host records use CNAME pointed at the CloudFront’s domain for my distribution. Without CF I would use A records and point them to the EC2’s ip address. If the dynamic content is always served by the EC2 and never cached by the CF due to https, does that mean that I am wasting an extra network hop between the CDN and EC2?
• If I am “wasting” a hop perhaps the “speed” of the AWS’ network between CF and EC2 makes up for the slowness of the “wild” internet between the browser and EC2?
• I used BackWPup plugin to setup WordPress backup to S3. It seems that the free version has a bug which prevents the plugin from working with S3 buckets in US-Ohio region. Instead, I set it to use the “US-Standard” setting which corresponds to the US-N.Virginia region.
• W3 Total Cache plugin does not “play” well with CloudFront backed by S3. It was pushing all wp-includes and wp-content files to S3 each time it was supposed to push just those that have changed. The consequence was that it quickly spent the entire free-tier provision for S3 operations. After a lot trial-and-error I resolved the issue by switching off the setting that says:
  

  Force over-writing of existing files / If modified files are not always detected and replaced, use this option to over-write them