Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't think any of these requirements are necessary. A basic "if I reach my bill limit, turn off things that are billing" toggle would suffice for 80%+ of users, especially with better billing controls/per-team billing accounts. I think you run into more problems/user frustrations with a tenuous conditional-shut-off approach.

My tinfoil hat is that a lot of cloud billing is accidental, probably from "lab environments", and they don't want to provide a way to budget/limit these.



What if my bug was saving, like, way more data to the cloud than I expected, and suddenly having a big bill for the hard drive space my data is using up just sitting there? It would be a pretty dumb bug, but hey, you never know, right? In that case they have to choose to either delete my data or keep charging me, so I guess there isn’t an easy zero-cost “stop” option.


The whole post is about this accidental billing situation.


I mean, those S3 objects, those backups, those databases, are billing.

“Turning them off” means deleting them.


It doesn't have to be though?

The provider could reject further access to them (reads / writes) once the limit is reached. The cost of actually keeping objects as "cold" storage has a natural cap per billing cycle since those are billed based on time.


Sounds good to me, that's what offsite backups are for (if the data is even necessary)




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

Search: