Cloud Consolidation Part One

I recently moved all my cloud workloads back to Amazon Web Services, learn more about my thought process.

Around five or so years ago, I picked up a copy of ‘Amazon Web Services for Dummies’. I was just entering college and while I knew of the cloud, I only started hearing more about cloud computing in my networking modules. Sufficed to say, going from starting to read that book five years ago to today where I work as a Platform Engineer for one of the world’s largest healthcare companies is something else. My experience has expanded to encompass Microsoft Azure, Google Cloud Platform and DigitalOcean. Daily in work, I swap between Azure and GCP depending on where I’m needed. When it came to side projects and previous work I had done before McKesson, I usually used AWS and DO.

Now I’m not looking to kick off a cloud war here. I think every cloud provider has their merits to a certain extent. I also think that when you start reaching the scale of enterprise, multi or hybrid cloud is just inevitable and even beneficial in certain scenarios. My own final year project advocated for so called cloud agnosticism whereby using something like Kubernetes, you could nearly hop from provider to provider as things changed. But I feel that when your talking about your own individual workloads, using multiple providers introduces too many variables for my liking. Primarily for me, this boiled down to managing billing, managing IAM and what I call foundational components.

• Billing – Monitoring costs is naturally a great thing to do. I created a habit years ago of daily checking my AWS bill which has saved my skin once or twice. Even when I was just using DigitalOcean in addition to AWS, I constantly found myself needing to go back and forth to make sure I wasn’t breaking the ceiling I set for myself in terms of monthly spend.
• Managing IAM – Keeping a strong grip on your cloud access keys is always good both personally and in the business. I rotate my keys regularly and try to make sure I never do something silly with them like checking them into Git. I see far too many posts on Reddit when someone posts about an unexpected bill and on investigation you find they put their keys in a public Github repo. I’d rather just be sure I keep tabs on one cloud providers IAM than multiple.
• Foundational Components – Since I used AWS previously, I had my foundation configured there, primarily in terms of networks. Granted, I was a bit generous with my subnet sizes many years ago. But you know, I had my private subnets, my NAT Gateways. So I was very much ready to spin up more workloads in a relatively easy manner, without needing to deep dive in to how networks work on other clouds (personally I hate the concept of Network Tags in GCP Compute Engine, just give me a straight security group on the instance Google). Plus, I tend to always have reserved capacity on AWS for billing purposes, using the type of reservations that will apply to any compute within that instance family still provided me with flexibility if I ever wanted to change something up.

So, what do I go for here? Lets review what my existing footprint was before I decided to consolidate.

AWS – I already had my primary VPC configured, with public and private subnets, NAT Instances, plus a few T3.Smalls running some incidental things like Minecraft servers, VS Code remote machines. DNS and CI/CD was also something that was easily configurable, but both have been superbly handled by CloudFlare and Github Actions respectively for a while now. Billing monitoring was also its most extensive here and generally, I’ve the most years of experience on AWS so I’m more comfortable.

DigitalOcean – DO has maintained my Kubernetes footprint for well over a year. It was my defacto choice when developing my Final Year Project and when my K8s usage was at its highest, it was all running on DO. My footprint eventually scaled down, but I was still running a dev and a prod cluster. The prod cluster was using two of their 15 USD instances in a 2vCPU and 2GB RAM configuration along with one of their load balancers for the clusters Ingress. All in all, no complaints here. A free K8s master plane is a great master plane. But all in all DO is still a more, simple cloud, which is by design. When looking at my planned side projects, I was going to need something a bit more in depth.

Google Cloud Platform – I don’t think I need to explain why GCP was considered. It’s widely accepted I feel that GKE is considered the gold standard in managed Kubernetes. I mean, why wouldn’t it be? Google has been running containers at scale for years, Kubernetes is something that came from Borg which was an internal orchestrator they had for years. Plus, it was free just like DOK8s. At the time of this consideration too, my reservations with AWS were expiring, so I would be in a perfect place to swap providers. I was already learning more about GCP fundamentals in work, why not just make the switch?

But then it happened… GCP announced that they would be introducing charges for the GKE master plane. Honestly, I wasn’t all too surprised although most of the Internet seemed to be shocked. Hobbyists were grabbing their pitch forks while seeming to completely miss the one free zonal cluster per month. Like if it’s a hobby then surely that would be okay? Anyway, I digress.

The new pricing structure meant that your regional GKE cluster would cost you 0.10 USD per hour, or roughly 72 USD per month before VAT. On a personal level, that’s not quite a lot given what you get for it. You could just build one massive GKE cluster and divide your workloads by namespaces rather than separate clusters for each stage of development. So, I was still in a lets go to GCP. But then I remembered something! AWS which had long charged for Elastic Kubernetes Service at 0.20 USD per hour, reduced their charges to 0.10 USD per hour. Meaning, that in terms of cost, EKS and GKE would be the same.

So, if I’m to consolidate my cloud workloads which is mainly going to be done by a Kubernetes cluster move, where do I go now? The new provider that I have to build up from scratch again? Or continue my eternal love affair with AWS and start to use EKS? Inevitably, weighing up my options the burning love for AWS was still strong so I stuck to my guns and built out an EKS cluster. Sufficed to say, the experience was horrible, but that’s a post for another time.

Have my monthly cloud costs gone up? You betcha. Are things possibly even more complex than they were before? Oh God yeah. Have I secured my peace of mind by another factor only having to worry about one cloud provider? Most certainly. I’m still quite happy with my decision. I think that trying to build out everything again on GCP while it’d have been a fun challenge, I much preferred to stick to what I know and get the best of both worlds with my knowledge of AWS being expanded at a personal level and my knowledge of GCP getting expanded at a work level.

This was part one! Check out part two for a more technical overview of what I’m now running on AWS.