Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping

https://www.npmjs.com/package/aws-cost-saver

by aramalipoor • 6 years ago

119 55 6 years ago

Just published a tiny CLI utility to save some bucks on AWS development environment while I'm not really working.

https://github.com/aramalipoor/aws-cost-saver

The idea is to stop/shutdown any resources (such as EC2 instances, RDS databases, ECS tasks, etc.) when you're done for the day and restore them back up next time you continue.

Currently it's in a very early stage, a hobby side-project :)

Ideally I'm thinking to provide a CloudFormation template or terraform config for example, to provision a scheduled Lambda with predefined "start of work" and "end of work" times and have it automatically do that for you.

I'd like to know if something like this would be useful for you too and what do you think about it?

adamlklein• 6 years ago

This sounds like a good idea!

I had been looking at creating a lamba to check for the existence of pods, services, alternate namespaces etc., as I learn K8s on AWS, to shut down the cluster when I'm not working on it.

aramalipoor9• 6 years ago

Thanks. Shutting down K8S cluster when not using is a really good idea. Maybe one day I play around with AWS's k8s cluster and add the trick to aws-cost-saver.

Pull requests are also welcome if you have time :) the logic must be similar to EC2 or RDS tricks: https://github.com/aramalipoor/aws-cost-saver/blob/master/sr...

WrtCdEvrydy• 6 years ago

This is amazing....

Edit: I wonder if you could put this inside of a lambda with just a role.

aramalipoor9• 6 years ago

Thanks. Agree with you, having it in a Lambda with a scheduled trigger or even manual trigger will be really useful.

redacted3212• 6 years ago

CloudCustodian has offered this for quite some time. We use it at our company in all our accounts.

swyx• 6 years ago

interesting work! i feel like this can't be a new problem. what comparable tools exist for doing this today? its basically just spinning up a staging env while you work and spinning down when you knock off work right? almost like a heroku dyno spinning up for you.

aliswe2• 6 years ago

I would regard it as a fairly new problem actually, the same age as the "developer resources on a per-minute basis" phenomenon.

z3t42• 6 years ago

Im very interested in learning about your work flows, like how does a typical day look like? I do all my work on a local pc and only use servers for production. So im interesting in how/why you use the cloud stack

jen20• 6 years ago

How do you test or develop against cloud resources like ECS using a local PC?

marton78• 6 years ago

Not OP, but in my company we do develop locally, however, merged feature branches are deployed to a AWS environment for testing. The environment is identical to production, but with smaller instances. Betas are deployed to yet another identical environment for QA to approve the changes. All three environments are managed by the same Terraform configuration to ensure they are identical.

aramalipoor9• 6 years ago

It really depends on the company and developers preferences. For our company's case we do have a "dev" AWS environment for a couple of reasons:

1) To avoid having a side-IaC for your dev env (e.g. using docker-compose/local k8s/localstack) which could take same time as your prod-IaC (terraform/CloudFormation) to prepare. Instead of hours preparing/debugging local dev we can work on great features or refactoring some tech-debt in the real code.

2) Since we have many other teams and upstream dependencies it's much easier to deploy on a AWS when testing complicated features. In an ideal world you shouldn't need it but unfortunately it's never ideal world.

3) Local dev solutions could easily end up with "but it worked on my laptop" due to various reasons from Docker host configs, to localstack deviations from real AWS resources, etc.

But at the end of the day you should see what makes more sense for you :) I guess for many people spending time on preparing a great local dev using docker-compose/k8s/swarm/localstack is cheaper than using AWS for dev anyway.

vageli• 6 years ago

Are you aware of cloud custodian out of Capital One? [0] Does this and much, much more (like delete noncompliant security groups, etc).

[0] https://cloudcustodian.io/

1vuio0pswjnm7• 6 years ago

I'm aware that Capital One was found guilty of not properly securing customer information when they started moving it to "the cloud" (AWS). I'm also aware that the person who orchestrated the data breach, by exploiting the bank's AWS (mis)configuration, had been hired by Amazon as a developer. Maybe the bank's IT staff created "cloud custodian" after the incident.

https://www.marketwatch.com/story/capital-one-fined-80-milli...

aramalipoor9• 6 years ago

Thanks for sharing this. Looks like a sophisticated solution, although might be too complex and enterprise-y for what I needed as a sleepy developer, but is definitely worth having a look :)

dabeeeenster• 6 years ago

This is awesome - Does it work cross-region?

+1 to add in:

- Elasticache instances - Load balancers associated with ECS clusters

barkingcat• 6 years ago

I find it price gouging that AWS doesn't already implement this on their own within their pricing structure and that you need a 3rd party tooling to do this.

cybrix• 6 years ago

They earn more money by not doing this.

spockz• 6 years ago

The downside of shutting down the resources is that there may be none available anymore in that sizing or pricing when you want to start them up again. I suppose they also don’t want to risk being liable for that.

bufferoverflow• 6 years ago

If you don't like their prices, why don't you just switch to another provider? Plenty of good clouds. And even more dedicated / VPS servers, if you want truly crazy savings.

aliswe2• 6 years ago

Are you seriously alleging that NOT implementing a "stop resources when I sleep/am not around" feature amounts to price gouging?

pc86• 6 years ago

That's not what price gouging is.

aynsof• 6 years ago

AWS Instance Scheduler is an official AWS Solution: https://aws.amazon.com/solutions/implementations/instance-sc...

It allows you to create automatic start and stop schedules for your Amazon EC2 and Amazon RDS instances. It uses a combination of CloudWatch/Lambda/DynamoDB to check against tagged instances.

gvenkat• 6 years ago

aws has a instance scheduler as a solution that achieves some of this objectives

https://aws.amazon.com/solutions/implementations/instance-sc...

aramalipoor9• 6 years ago

That's a good alternative for EC2 / RDS instances but when it comes to other cases like DynamoDB provisioned throughput or Kinesis shards or ElastiCache it wouldn't help much

60secz• 6 years ago

Because my favorite place for AWS credentials is some random NPM module?

debaserab2• 6 years ago

This works like every other AWS CLI tool - it uses your shells AWS credentials dir or ENV vars

fareesh2• 6 years ago

Is it common to have a dev environment on AWS? I just use it for production and maybe staging. Staging is scheduled to run during office hours.

carnitas• 6 years ago

My company tasked me to mad dash their dev environment to AWS. Why? Because “cloud”, and perceived less risky than moving QA and Prod first.

vitalysh• 6 years ago

I guess depends on the size of the company. How else would you constantly test integrations between different services? Especially if some services can't be easily ran on the laptop.

Also if you add terraform/ansible and all that jazz to the table. Where else? Infra team needs dev/stage as well.

wuunderbar• 6 years ago

Localstack can get you pretty far.

fareesh2• 6 years ago

Yes but in those cases would you really be looking to be Frugal like this? I figured the underlying assumption is that this is a tip for regular folks

ldoughty• 6 years ago

Ops people need a Dev environment to test, especially for Infrastructure as code. With an increased connectivity between developer code and Infrastructure, I prefer my team finds out everything in a development environment that's exactly like staging and prod. That way deployment to staging is proof of the IAC change. There's less risk.

This also lets developers try out new services in the cloud without impacting the staging... (This is on top of a sandbox for research, but integration of research takes time and an environment too)

mcintyre1994• 6 years ago

It’s super useful to be able to spin up a dev environment for doing things like experimenting with the performance impact of different configs. It’d be annoying and potentially disruptive to other team members to do that on staging.

weeefun• 6 years ago

It looks like a nice tool doing it's job well :-) I'd also consider services like provisioned DynamoDB tables or Kinesis streams in this context because there you can also waste lots of money depending on your setup. For example, you could decrease the provisioned read/write capacity for a DynamoDB table or decrease the shards of a Kinesis stream over night. I've discussed these topics in a blog post, in the context of a CloudFormation stack, if anyone's interested: https://www.sebastianhesse.de/2018/04/22/shut-down-cloudform...

aramalipoor9• 6 years ago

Thanks for sharing your experience. Both of them sounds like great ideas, will add them to ToDo right away :)

chromedev• 6 years ago

That is what Kind is for.

stekern• 6 years ago

If you're using IaC and have it set up in a CI/CD pipeline, you could also achieve the same by having a cronjob set a flag outside of work hours, and use conditionals in your IaC based on the value of that flag (e.g., for Terraform `count = var.scale_down ? 0 : 1`)

aramalipoor9• 6 years ago

There were a few reasons why I couldn't use IaC:

1) Using conditionals to achieve this usually makes terraform unmanageable specially if your terraform is complex.

2) Sometimes you'd need to do more complex steps to save some money, for example in case of ElastiCache you'd need to snapshot/delete/create.

3) Using terraform in a Lambda to schedule this was not straightforward (in my current company) so I gave up making it work :D

iflowfor8hours• 6 years ago

Great addition to pile of scripts to take with you on problem solving missions. I have something similar, but written in terraform. WRT AWS cost visibility, I find it is usually faster to spin up and grab most of the relevant information using mlabouardy's [komiser](https://github.com/mlabouardy/komiser) than to try and standardize yourself. Not shilling, just a tool I like.

kevin_nisbet• 6 years ago

While this only works with instances, I usually just cron the shutdown command with a future time. Nice thing is, if working late I give myself a couple hour window to cancel shutdown on any nodes I'm still using.

echo "0 22,0,2,4,6,8,10 * * * /sbin/shutdown +115" > /etc/cron.d/autoshutdown

I'm all for a better tool, just wanted to point out a builtin alternative.

ngcc_hk• 6 years ago

Any similar for other cloud services like azure, gcp and especially digital ocean

gbolo• 6 years ago

looks cool. If anyone is interested, I made something similar a while back (web app instead of cli): https://github.com/gbolo/aws-power-toggle

Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping

Related Stories