Many of our customers’ cloud engineers and architects–but also consultants at Nordcloud supporting them–routinely work with fairly complex cloud environments made of dozens of Amazon Web services (AWS) accounts hosting many solutions.
Some of our customers–and ourselves–joined the 100+ accounts club long ago and, with more workloads migrated to AWS or new solutions built on the platform, challenges posed by the ever-increasing number of projects and potentially growing number of accounts are already a reality and are not going away anytime soon.
In an earlier blog entry of this series about static website hosting on Amazon Web Services I wrote on the few mistakes Taxi 020–or rather Cabonline Technologies–made in handling their website’s infrastructure on AWS and how these mistakes could have been mitigated by leveraging Amazon Simple Storage Service (S3) together with CloudFront.
I also wrote that I would come back to the infrastructure as code for static website hosting topic and elaborate on how it can be achieved with CloudFormation templates and CloudFormation stacks in AWS. Here are ready-to-use templates for three alternatives; from the simpler S3 only solution to the more advanced S3 with CloudFront and Lambda@Edge architecture.
I was web browsing through the different taxi companies operating in Stockholm this morning when I eventually ended up on taxi020.se which responded with an HTTP 404 error. As I read the code and message for that error my search for waiting time at the airport terms and conditions got all of a sudden more interesting.
Taxi 020 merged with Sverigetaxi in 2016 and is now part of the Cabonline Group.
Unless you’ve been living under a rock since… last week, you’d know about the AWS region coming to the Nordics. The new EU (Stockholm) region will be operational in 2018 and will have three availability zones — as of today only the EU (Ireland) region also has three AZs in Europe — located in Katrineholm, Västerås and Eskilstuna.
It has been almost a month since I came back from the fifth edition of re:Invent—the main Amazon Web Services conference held in Las Vegas each year—and I take it upon myself to go ahead and bother you with a take-away post heavily influenced by my personal interest in the Internet of Things and, to a higher degree, smart home technologies.
… will most likely be available all over the interweb within seconds. I will therefore spare you (and me) all the low quality posts and will make the most of the sessions, after hours events and enjoy my first re:Invent instead.
Or maybe I actually will push fresh content to my online notes. Stay tuned.
A few weeks ago I decided it was time to deal with one of my 99 first world problems and simplify how I interact with the connected objects I tend to scatter around the house.
So I wasted a couple of hours searching the interweb - I obviously ended up watching Youtube videos too many times - and found a rather interesting open sourced project to help control these devices but also track their states and automate some: Home Assistant
If you read my previous post you should know that fourteenislands.io is served by a Nginx web server (Docker) running on a Raspberry Pi. But what started as a sandbox environment to host a few static pages is getting busier everyday and I, among other things, needed to host a couple of RESTful web APIs on that Raspberry Pi (on a different domain name).
Hosting a static webiste on a Raspberry Pi (RPi from now on) is quite straight forward. Serving that same website from a Dockerized Nginx HTTP server -on that same RPi- is a bit more interesting. Sure.
But what if the RPi decides to take the day off?
This post is mainly for students who attended one of my Architecting on AWS or System Operations on AWS sessions. It contains instructions, links to templates, tools and scripts to get started with Amazon Route 53 DNS failover between a primary site hosted on a RPi and a secondary site hosted on Amazon S3 & Amazon CloudFront. It is however not an exhaustive list of all the steps required for such a setup: use it at your own risk.
Altitude is a simple widget displaying the current altitude. The widget does not rely on the built-in barometric altimeter but retrieves the altitude from a third party elevation service (such as the Google Elevation API) based on the GPS position.
