
Show HN: Tiny CLI to save AWS costs in dev environments when you're sleeping - aramalipoor
https://www.npmjs.com/package/aws-cost-saver
======
aramalipoor
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](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?

~~~
z3t4
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
How do you test or develop against cloud resources like ECS using a local PC?

~~~
z3t4
I would like to know how and why you use resources like ECS. et.al. There
reason why I do not like to use cloud/serverless is because I find debugging
is much easier on a local computer or a server I have root/metal/hardware
access to. And that serverless have a very slow iteration rate, it can take
minutes just to run a simple test that would be instant locally.

The reason I'm asking is because on my free time I'm developing a cloud IDE
but I'm having trouble understanding the market. I beleave cloud dev services
will be a huge market. But I don't understand how people use it practically in
their dev setup.

~~~
malwrar
I use it (and similar tech) because I don't want to think about individual
boxes at scale, rather instances of an application. Containers + orchestration
allow me to develop and test in the exact same environment my apps will be in
in prod, which allows me to mostly remove the hardware and OS as a variable
that could affect its runtime behavior. They also make it easier to spin up a
local copy of my services' runtime environments for testing, as I need only
describe it in a simple yaml file and spin it up w/ docker-compose in a single
command.

I found at first testing was arduous, but you learn to adapt. In my case, I
increased the amount of debug logs my application throws (can also be useful
to enable in prod when trying to hunt down an issue) and invested time in
creating unit/integration tests that run outside of the container/lambda to
validate specific paths/features. Worst case there's always docker exec and
language-specific debugging when I want to dig in manually.

I'm still pretty skeptical about serverless (I mostly use it for cloud-
specific automation), but as much as people like to shit on Docker it's been
pretty great to use from an ops perspective. I interpret most negativity about
it as curmudgeonly reactions to the admittedly excessive hype in the
technologies, with some fairly pedantic complaints about the (imo minimal)
overhead such technologies incur thrown in as an uninteresting justification.

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

[https://aws.amazon.com/solutions/implementations/instance-
sc...](https://aws.amazon.com/solutions/implementations/instance-scheduler/)

~~~
aramalipoor
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

------
fareesh
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.

~~~
vitalysh
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
Localstack can get you pretty far.

------
weeefun
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...](https://www.sebastianhesse.de/2018/04/22/shut-down-
cloudformation-stack-resources-over-night-using-aws-lambda/)

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

------
iflowfor8hours
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](https://github.com/mlabouardy/komiser))
than to try and standardize yourself. Not shilling, just a tool I like.

------
stekern
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`)

~~~
aramalipoor
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

------
kevin_nisbet
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
Any similar for other cloud services like azure, gcp and especially digital
ocean

------
gbolo
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](https://github.com/gbolo/aws-power-toggle)

------
dabeeeenster
This is awesome - Does it work cross-region?

+1 to add in:

\- Elasticache instances \- Load balancers associated with ECS clusters

------
chromedev
That is what Kind is for.

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

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

------
barkingcat
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
They earn more money by not doing this.

~~~
spockz
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.

