FinOps is a conspiracy by big Ops to make you use more Fin

There's an episode in season 2 of Community where Jeff, while doing his very best not to do anything, gets caught up in a comically layered conspiracy about the risks of trying to do nothing. Now I'm not trying to do nothing but right now I don't have the time to do more than I need to. And the more I can do while not doing (and not paying), the better. This is where my website comes in.

In the act of procuring cloud infrastructure for my website, I've taken some shortcuts and I thought I'd carefully measured the price of those shortcuts and was willing to pay for them. Despite that, when my budget alerts went off a mere 10 days into the month, I was surprised and also kind of annoyed. How can this be?

So for this dev log, I've decided to have a look at my bills and see what we can do.

Oh boy. I don't know why I bothered spending so much time time tinkering my S3 media file hosting solution. That and most of the other costs related to my website server are dwarfed by this huge, honking Load balancer bill!

Load balancer clearly costs more than any other service. However VPC is unusually High too...

So yeah what's all that for just a micro T3 EC2 box quietly running a Django app that no one but me uses? I see 3 chunky bars evoking my ire.

• Load Balancer

• VPC

• EC2 - Compute

Let's address the Load balancer first.

Balance Deez

I don't see myself as a conspiracy person, but there's a reason AWS tells you "the simplest" way to enable https on your server is by attaching a load balancer. You can see it here in their documentation on the Load Balancer pricing page.

Straight out of the gate, we're spending upwards of $18 per month just to keep the load balancer on 24/7. That's not even considering the LCUs (Capacity units) used. $18/month is already too much and I'll need to take action to fix this (the action is me ripping it out like a weed, in case you were wondering).

Next up is the VPC. What's that charge for?

Well, dear reader, much like a decently priced rental in Brisbane City, public addresses on the internet are in short supply (that is, IPv4 addresses). This makes them valuable. Valuable enough that as of February 2024, Amazon has been charging 0.5 cents per hour for the pleasure of using one. Fast-forward to last month, when I asked Elastic Beanstalk to put my website online. It assumed I was a man of vastly more means than I really am and decided that I must want 3 availability zones each with a public IP address.

I was just a poor developer, trying to find a cheap way to host my website. Now look at me, I have a leak in my bank account of exactly 1.5 cents/hour and I get to think to myself, "boy am I glad my website is highly available".

1.5 cents per hour makes Sam a poor boy

Finally EC2 pricing. There's not much to say.

EC2 charges based on the type of EC2 and data transferred in a given time period. Data transfer is negligible at this stage and the EC2 type is T3-micro, the 2nd cheapest on-demand instance AWS offers. However, there are still some neat little FinOps tricks I can explore here.

Yes, FinOps is a real word

First off, the ALB has to go. There's no sense in my using a Load balancer anyway because my website traffic is featherweight. If that ever changes, I'll scale it up myself. For now paying $18 per month for a fancy server to route https traffic to my single node website is farcical. It's doing nothing but serving the SSL certificate which I can get Nginx to do on the instance for free.

While reconfiguring things, we could reduce our VPC costs by switching to IPv6. This would remove all the IPv4 tolls and our only charges will come from traffic (if we ever break out of free tier). Unfortunately, IPv6 presents a lot of it's own challenges. Namely that neither my home broadband service provider nor my mobile service provider support IPv6. The funny part is that even AWS has spotty IPv6 support! The AWS Instance Connect tool that AWS provides to connect to instances through your browser ALSO doesn't actually support IPv6. Why is any of that relevant? Because practically, yes I can configure and populate an IPv6-only VPC and subnets regardless of whether my ISP or Instance Connect supports IPv6. However, I won't be able to reach them for configuring or debugging my instances because I can't SSH in from home. It seems no one can actually handle the protocol that has been getting "adopted" since 2012.

Well okay. I can at least remove the 2 IPv4 addresses that I'm not using. That'll reduce the VPC costs by 1 cent/hour saving me up to $7.44/month (USD btw so that's actually around 14 dollaroos 🦘).

Finally we need to reduce EC2 costs. Savings plans are an option. According to AWS documentation, this would bring the hourly price of my instance down by 22%. However, I've been wanting to try out creating a spot fleet. It's essentially an autoscaling group but the instances are only ever spot instances. I can configure a spot fleet with a desired capacity of only 1 instance. Spot instances can get reclaimed by AWS at any time as other users are willing to pay the on-demand price. However if you have a spot fleet set up, the instance will be replaced automatically (if possible). Looks like this should bring my EC2 instance costs down around by 35%. If my website goes down for a few minutes or hours between spot instances, I'll live.

"...And a very familiar feeling is starting to come over me. I feel like someone is trying to teach me something." - Jeff Winger, Community Episode: Conspiracy Theories and Interior Design

To a seasoned Platform Engineer, I'm sure this is some kindergarten-level course-correction. It's not tricky to point out where I've taken shortcuts. I've done the cloud certification exams, I've heard of these issues before and I've been working in AWS for a few years. That's why I know that these are common problems and where to find the solutions. But I've never actually had to foot the bill for my shortcuts. That's what this little project is for (among other things). Unlike Jeff Winger, I'm here to learn and it's all part of the experience.

Keep an eye out for my next post where I'll go through implementing my cost-saving changes and how much my AWS bill actually changes.