AWS cost optimization tactics

Imagine working on a product and you finally released it to the public. Things are going great for you, then your budget got out of control and you have to tame the spending. Below are a few tactics you can utilize to curb the costs.

Cronjobs -> ECS Tasks on Fargate

Cronjobs mean you need to have an EC2 (vm) running all day and night. Even if your cronjobs only get triggered for an hour late at night, you still need to setup a vm start/stop schedule (read: more setup effort), in which you have to make sure that it starts before your cron schedules, and shuts down after your cronjobs run successfully. It's a lot of time logistics involved, and if the time window the EC2 stays up is too tight some of your jobs might not run.

ECS tasks is a way for you to fire up container-based jobs, it only charges you for the amount of time the tasks take to complete. You don't need to provision a vm, because ECS on fargate is serverless. You can even make it cheaper by using fargate spot! (But don't forget to setup retries because sometimes a spot job could fail due to unavailable spot capacity).

ECS on Fargate -> ECS on EC2

If your workloads are very predictable - i.e. predictable spikes, you might want to consider using EC2-backed ECS. This is because in lieu of using fargate for compute backend (which has a higher price-point per compute-second), you can provision EC2 yourself as ECS backend. You can make it even cheaper by buying reserved instance.

For Not-Always-On Workloads

You have a few approaches here. You can use ECS on fargate and setup a schedule for workload activation/deactivation. Let's say if your workload needs to be active during work hours, but is idle at night, this would work perfectly.

Alternatively, if it's a very small workload - let's say half a dozen functions, it could be converted into Lambdas, which has an added benefit that it can scale to zero. This means it only charges you when it receives incoming requests.

Bonus: What's up with using EC2

If you want to get something up and running real quick, EC2 is a fine solution. It's what everyone is familiar with, same steps as when you were to work on your local workstation.

However, at certain point in time, you would eventually run out of disk space - and you have to set up a disk monitoring and cleanup job.

Additionally, you have to perform OS upgrades as well, and things might go wrong, but you'll never know until you perform the upgrade. Yes, this sounds like Russian roulette.

And the worst of all is there's no clean way for you to read your workloads' logs without SSH-ing into the vm. Or you have to forward your logs to an external service, but then you have to set it up, which is more work.