Blog anatomy - Cloud services

The following sections will highlight the Cloud Service architecture and management approach behind this site.

Pet resources 🥺

When I was first creating this site, I created the services via the UI.

It was particularly helpful for learning about AWS CloudFront and AWS Lambda@Edge (as opposed to plain AWS Lambda). Due to their distributed nature, these services can be extremely slow to provision (and destroy or change). Working with AWS's Management Console UI was a bit like someone was handholding me through the learning process. I believe that saved me from iterating many more times to get to where I wanted.

In the following diagram you can see the resources that are still manually managed.

And here is, somewhat verbose, legend for the above diagram.

AWS Organisations

The AWS Organisations are delimited by horizontal dashed lines.

The top AWS Organisation is referred to here as "management account". The management account is the organisation created for you automatically when you sign up for an AWS account. This is, most likely, a pet resource for all typical AWS users.

Each of the extra AWS Organisations is using a separate AWS account and ships with a default admin role (called OrganizationAccountAccessRole by default).

Extra large files

My management account contains a bucket for extra large (XL) resources, primarily videos, since some posts embed them. The size is large enough that I do not desire to wait for their upload from a machine outside AWS fast networks.

When a new environment is provisioned, the XL resources bucket from a management account is synchronized directly with the empty bucket in the new environment. It is fast. Even for transfers between buckets in London and Ireland regions, I witness speeds of around quarter of a Gigabit per second.

AWS DNS primer

The top level, management, account also defines a Route53's Hosted Zone which contains little but important config. NS records pointing to separate Hosted Zones in the other environments. That allows for a delegation of the DNS record management to roles within these accounts. At this point there's nothing special setup in these other zones (only default NS and SOA records).

Please note: what's important is that the Hosted Zone in the management account defines NS record for every environment. Such NS record will have the record name set to subdomain name for that environment. NS record's value will be set to a list of nameservers of the hosted zone already present in that environment.

That is it, the rest is all IaC magic.

Here comes the cattle 😊

As mentioned, the components that are new on the diagram are all coded. I am currently using AWS CDK and the provisioning process is described in next post in this series .

Summary

It obviously depends on the requirement, preferences, and other factors, but the model I present here is working really well for me. It is economical, just about flexible enough, reliable, and not too much of a burden maintenance-wise.

It could be slightly cheaper and simpler (or the complexity could be pushed elsewhere). It would mean, however, a sacrifice of flexibility and usability, which is why I don't want to tweak it.

The resources that are manually managed could be managed with IaC, but they require so little maintenance that I didn't have to do any whatsoever for a few years. There is a cost to having a Hosted Zone, but it is a flat $0.50 per month per zone so not exactly breaking the bank, unless you need a lot of environments. If that was the case, I would just move it into IaC.