It's more valuable to be in use than to sell it to you. They are very limited on ipv4 space, so the charge is really a penalty for keeping that resource from another customer.
IPv4 allocation limits are still mostly a scare tactic to get people onto v6. I know dozens of people from my webhosting days with /12 and /16 allotments doing nothing that they pay peanuts for. This isn't a unique scenario.
> This isn't a unique scenario.
And this is exactly why we're running out of publically available IPv4 addresses.
Me too. I want protection against my own stupidity, as well as sheer ignorance of the charges. This put me off AWS for years, and I was deeply shocked there was no one-click 'suspend at x$'. For a company that supposedly puts the customer first, this is appalling.
It's difficult to come up with a good model for how a billing ceiling would work in software as a service. A good start would be to fully specify what behavior you desire when an account hits its billing limit. Are you expecting everything to keep working like normal while the cloud provider pays the bill for those resources, or are you expecting the provider to fully shut everything down in a way that prevents the a…
I do suspect that there is a set of circuit breaker actions that could mitigate runaway bills mostly non-destructively. Stop writes to stateful storage. Stop all inbound/outbound data transfers. Terminate EC2 instances (which as you say wold delete data but that would generally be ephemeral data anyway). Halt tasks like EMR.
On the other hand, based on near-universal industry practice, there doesn't seem to be a huge demand for this. I suspect it may be better for everyone concerned to have heavy-duty users control their costs in various ways and for Amazon to refund money when things go haywire without bringing someone's service down.
I'm amused by the model they have in their banner: a bearded, tattooed man wearing what appears to be a .. cape? We've come a long way since the stock photos of 'smiling super-normal people wearing ties, huddled around a computer'.
I'm amused by the model they have in their banner: a bearded, tattooed man wearing what appears to be a .. cape? We've come a long way since the stock photos of 'smiling super-normal people wearing ties, huddled around a computer'.
> CoW backend allows for nearly instant snapshots and clones LOL => A 80GB EBS SSD snapshot takes more than 1 hour. Subsequent snapshots are incremental and will be less slow. > multi server/rack redundancy with EC You can move drive manually after you stop an instance, if that's what you call redundancy. > ability to scale up with provisioned IOPS Nope. You need to unmount, clone the existing EBS volume to a new EBS…
> Subsequent snapshots are incremental and will be less slow. Depends how much they've been written to since last snapshot. Heavy writes and it can be just as slow again.
Hence why I say "less slow" and not faster. There is nothing fast when it comes to EBS volumes :D
100%. I can't stand it. It's unlimited liability for anyone that uses their service with no way to limit it. If you were able to set hard caps, you could have set yours at like $5 or even $0 (free tier) and never run into that. One of my services had a Google BigQuery "budget" set at $100. One of our test machines went haywire and continuously submitted a bunch of jobs. The "budget" turned out only to be an alarm, an…
Yep. I had a personal $400 learning experience with Amazon. They did refund it. My last company had a low-5-figure surprise a few years ago. Some of that could be considered their fault (alerts were sent to someone on vacation), but again, the refusal to allow the option of a "hit a limit, pull the plug" option is what causes this.
Of course, there's also the opposite scenario "So here we were, having the best sales day in our history, and suddenly Amazon pulled the plug on our servers because we went over our authorized limit! We lost 5-figures of sales that day. Sure, they sent us warnings, but the alerts went to someone on vacation... but why wouldn't they let us exceed the limit for a bit before they pull the plug"
This is exactly it. 5-6 years ago (I think), I signed up for an aws account under the "free" or educational or something tier. AWS was newish at the time, and I wanted to learn about it. Via some accidental clicking in the control panel (trying to get an IP address for the instance, I think?) I ended up getting a bill from them for over $100. Which, to me at the time, was a huge amount of money. It put me off of AWS…
100%. I can't stand it. It's unlimited liability for anyone that uses their service with no way to limit it. If you were able to set hard caps, you could have set yours at like $5 or even $0 (free tier) and never run into that. One of my services had a Google BigQuery "budget" set at $100. One of our test machines went haywire and continuously submitted a bunch of jobs. The "budget" turned out only to be an alarm, an…
What are these "various" ways you're talking about? The only overage charge I see is for data transfer. This isn't ideal, I'll grant you, but it's not the same as "various".
DNS, IP Address Reservation, Plan Upgrades, Bandwidth, and so on. We've seen AWS accounts get broken into with stolen tokens, additional VPS's started, VPS upgraded, bandwidth consumed, etc. And while Amazon has been good with refunding the FIRST time, nobody wants to wake up to a 10K bill because your gitignore had a typo. A ceiling or cap may even stop plan upgrades without an email confirmation. That would be huge…
Genuinely curious to hear if that "gitignore had a typo" 10k bill has a story behind it!