Much to my chagrin, I find myself making a configuration change that I have high hopes for, but ends up causing more problems than it solves. This is no different from what happened to me a few days ago by making a firewall change on my homelab.
I'm a bit of a strange case in the sense that I greatly prefer setting up and configuring something over actually using it. There's something about the challenge of figuring things out that I just tend to lose myself in. The problem is that I spend a lot of time getting something up and running only to lose interest in it shortly after. I know it seems strange, but what I'm trying to figure out is whether it's time well spent.
A few weeks ago, I was reading an article on Scott Helme's blog about caching Ghost with Nginx. In doing this, I made this blog and a number of other services that I use kick into overdrive, but that whole endeavor is best left for its own article.
As much as I enjoy using AWS, to use it how I would like to use it is just too expensive. Because of this, I've hosted the large majority of my cloud infrastructure on DigitalOcean. This boils down to two reasons — it's a lot easier to use than AWS, and the pricing is predictable.
I haven't written in awhile and that one is on me. I meant to keep this up regularly, but I've been slacking with it to say the least. Who knew that having a family, a full time job and responsibilities would take up so much of my time! I'm going to do my best to update regularly going forward.
Now that I've got that out of the way, the real reason for my post...
Of all the systems I maintain in my homelab, the one I generally look at the least is my NAS. I'm not sure if that would come as a surprise to anyone, but it's become one of my most trusted “set it and forget it” systems.
I meant to get to finishing this up shortly after my last post, but life comes at you fast sometimes. No excuses though, as I've been continuing with my course and should be finished within the next day or two. In the meantime, I still have a bunch of content to write, so let's get to it.
This will be a continuation in the Database series covering the AWS offerings as part of the AWS Solutions Architect: Associate exam. I covered RDS in part 1 and will continue with Aurora in this part.
I finished the database section of the AWS Solutions Architect Associate course a few days ago, and it was by far the most challenging to wrap my head around.
Just to point it out for the record — I am by no means a database guy. I know what they are at a cursory level, but I have no real hands-on experience to speak of with any type of databases.
This will be my attempt to make sense of all the database offerings from AWS.
I'll start by saying I have a very general understanding of DNS. I know it's often dubbed the “internet phone book” and that it translates IP addresses into URLs. I know some of the various DNS record types off the top of my head — A, AAAA, CNAME, MX, TXT — along with how each of them are used, but mostly at a high level.
As a baseline...