Hacker News new | past | comments | ask | show | jobs | submit login

They would legitimately lose a lot of money if they did this now (and I would argue, wouldn't make up for it in market share). Most companies I work with who switch to AWS think it's a 1:1 conversion in terms of cost from a data center and pretty much just "leave AWS on" not realizing that they are not only paying for computing cost but the hidden cost of being able to scale up more instances quickly.



It's really really difficult to be able to turn on and off instances as needed, like turn a test instance on in the morning when developers come in and turn it off in the evening when they leave.


I don't understand. If autoscaling groups are too complicated, just create the instance and stop and start it when you want. You can control permissions via IAM groups and instance tags if you need to be careful. Or you can indirect through a lambda if you need to be super careful.

Good morning! `aws ec2 start-instances --instance-ids i-12345678900`

Good night! `aws ec2 stop-instances --instance-ids i-12345678900`


You can implement this with a simple auto-scaling group or write a small Lambda function which runs at a certain time to start/stop the instance


Autoscaling groups can be scheduled without a lambda function.

http://docs.aws.amazon.com/autoscaling/latest/userguide/sche...


You typically want exactly 0 or 1 instances for testing instances. I don't recall autoscaling groups able to do that.


This is entirely possible. Scheduled actions can make this happen on a schedule (simply schedule desired-capacity=1 when you want it on and desired-capacity=0 when you want it off). Or you can simply run a command to do it on demand.


I have an autoscaling group that goes from 0 to 1 every day for some batch processing. It took a bit of finagling but it's definitely possible.



Tag it with something like shutdown=non-biz-hours, or can even specify a schedule that a lambda function can pick up each minute or hour and parse to stop/start any instance that falls within that window.


Well that works if you're a startup in one timezone with no teams depending on your service. If you work on a larger company, it's quite possible the sun never sets on your project (west coast, east coast, Europe, India, Australia or SE Asia)


If the sun never sets on your project, then you probably don't want to shut it down because you're using it 24x7.

But since a Lambda is a program, you can make the criteria as complex as you like.

Tag it with "shutdown=non-biz-hours", and "timezones=UTC-7,UTC+0,UTC+5:30" and your shutdown script can figure out when it's outside of business hours in all of those timezones and shut it down.


If the sun never sets on your project, why would you want to shut the instance down?


One reason would be that the savings is worth the increased latency. Depends on the situation.


I'd only do this strictly in dev or qa. Remote teams can always spin it back up if they need it on a wider schedule.


This is really easy in Azure, its a built in function of the admin console. I control my dev VMs manually usually but have the cutoff set for a couple of hours after usual quitting time as a backstop.



Yes I still don’t know why this feature isn’t in the AWS Console yet. Even Oracle Cloud of all people has this feature in their Virtual Compute.


It's, just that AWS just has a building blocks.

To implement it use autoscaling group of size of 1. Then change desired to 0 or 1 based on need.


So basically you want to [pause] all the instances.


Which is why reserved instances exist.


The reserved instance pricing model is really poorly implemented. You have to commit to an instance class and a region, and if you need to change you can, but there is some secondary market. When compared to a sustained use model, it is a disaster. Managing all that in a large org is a real pain in the ass.


There are so many options for RI purchases honestly.

Standard vs. Convertible: Convertible allows you to switch between instance families (like c3, m3, m4, i2, r3 etc...) but it requires you to make a 3yr commitment, commit to a specific AZ and doesn't offer the same level of savings you'd get with a 3yr standard, I think it's closer to the savings you'd get with a 1yr Standard RI. Standard RI's come in 1yr or 3yr commitments. You can choose between the default option of the "Regional Benefit" which allows you to apply the RI to any instance that meets the RI criteria in a given region or you can choose the "Capacity Reservation" option which requires you to commit to a specific AZ to guarantee your reservation. That's right, your 'reserved' instance isn't necessarily reserved in the case of an outage unless you commit to a AZ.

One benefit that you get with Standard RI's is that they can be applied to any size instance in the family for which you've purcahsed them. Amazon allows you to convert between nano, micro, small, large, 2xlarge etc. within an Instance Family (t2, c3, m3, r4 etc.) with Standard RI's and they apply these conversions automatically on your bill.

Then you also have to choose how you pay, no-upfront and all monthly (smallest capex), partial upfront/partial monthly or all-upfront (largest capex).

It's frustrating because it's so complex that it makes me hesitate. I never feel like I'm getting the best deal and it just feels like AWS is taking advantage of the market by making pricing impossible to decipher.

Does anyone have any good methods for determining how many RI's to purchase, how often etc?


Have you seen/tried https://stax.io/


Reserved instances are really a cultural hack. It's easy to get open budgets but capex is a different, harder process. Reserving strays into Capex.


Not just region, I think it's per AZ.


It is per region, but you can request a reserved instance be moved between AZs.


I do this with Python+Boto+Jenkins: https://giorgiosironi.github.io/talks/ec2_ci/slides/ Until now we were turning off at the end of the hour (e.g. 2:55:00, 3:55:00) but now we have to change the model a bit.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: