I believe his point is that you aren't their target customer. It's like walking into a freight distribution center and asking to buy $0.50 worth of chewing gum. Sure, somebody might accommodate you, but complaining about them not doing so doesn't make a lot of sense.
In Amazon's shoes I'm not sure I'd offer a feature like that at all, because someone might set that to be "smart", forget about it as the business grows, and then have a bunch of servers terminated and/or data destroyed right during an excitingly busy period. It would be an extraordinarily bad customer experience. It could be much better for them to do as now and then occasionally credit people who accidentally go over.
> and/or data destroyed right during an excitingly busy period
The idea that service providers destroy data when a cap is reached is just plain weird. Usually your access to the data is simply blocked - then you can pony up some more $$ if you want access to it.
Similarly, it's also weird that people think Amazon doesn't care about 4- and 5-figure accounts. They do. Big accounts bring in money... but so do a lot of small accounts... and there are a hell of a lot more small accounts than big accounts. At my last job our monthly bill was $1-2k, and I'd get regular contacts from the AWS account manager, along with free training days.
I think that the real reason is that AWS is generally not at capacity, and if someone does have a hostile overage event, it's quite short term, and the only money that AWS really loses is from the wattage used by the VMs. There's no extra labour or hardware on their side. Refunding overages is good PR and not all that expensive, as long as it doesn't prevent other paying customers from accessing existing resources.
> The idea that service providers destroy data when a cap is reached is just plain weird.
This fellow is proposing an account that's capped. In AWS-land with by-the-hour servers, that would presumably mean terminating running servers. Servers that have data in RAM. Servers with volatile local disks that get recycled as soon at they're terminated. Maybe you have an idea of how to shut down all of Amazon's 40-odd services with no risk of data loss, but I'm not seeing one.
If they're not going terminate them, then either they're going to keep charging or not. If they keep charging, then it seems like it's more a billing alert plus a service interruption. If they don't charge, then it's more like what they do now, which is waive charges for mistakes, except with a service interruption.
> Similarly, it's also weird that people think Amazon doesn't care about 4- and 5-figure accounts.
I think they do care about them. I'm just saying they won't go out of their way for the $50/month accounts if it means putting serious customers at risk.
You're mixing and matching your incredulity. On the one hand, AWS has 40 services. On the other hand, everything is terminated like an EC2 instance... Which really isn't the case.
So, to begin with, most of their services can either be powered down (with chickenfeed storage costs that they could cover as part of the deal) or are outright free. Most things that you fork over money for in AWS can be disabled with some form of networking block. Have code in Lambda? Well, it doesn't get destroyed, it just gets blocked. Have RDS databases or Elasticache? Block access, and perhaps power them down after X time (which saves them to s3, and block storage for AWS's internal use is very cheap - retail s3 is 3c/GB/month). S3 itself also gets your access cut. SES and SNS just stop processing their queues. Things like VPCs and IAM are free to begin with. The costs of keeping these things running behind a block is trivial compared to the overage charges they already routinely waive.
And then we come to EC2... and the story still isn't 'must be terminated'. EC2 instances can be powered down and ELB access blocked, leaving the config all in place and the instance's drive saved to s3 (which is where AMIs and volume snapshots/unpowered instances live). Yes, you will lose data in RAM, but you just get the account holder to accept that the machines can be shut down by AWS, just like already happens with spot instances. If the client opts in to capped pricing, then they can take that into account and design their system around the sudden downing of the instances.
I certainly didn't say everything is terminated like EC2, so I don't know where you're getting that from.
And it looks like we agree: any attempt on Amazon's part to create something like this would be complicated and would still not remove the risk of data loss. An service interruption is, of course, a certainty.
So as far as I can see, the feature still doesn't make much sense. It's only really useful to people who aren't doing anything in Amazon that matters.
>I believe his point is that you aren't their target customer.
I hear you & understand your argument. They are offering AWS free tier to me for zero USD though, so I don't think my offer of a paid account capped to 200 USD is unreasonable. It is telling though that they won't give free AWS accounts without CC details...
I'm not trying to screw amazon here...I just want a little bit of VM time that I can use to toy around with from a reputable source without signing over the rights to my first-born.
I think small developers are their target customer, as well as big customers. After all, why would the big customer's care about the free tier? Similarly, why open the 'aws pop-up lofts'? https://aws.amazon.com/start-ups/loft/
If you are a big company thinking of using AWS, you probably pay a thousand bucks to send some of your engineers on a course to learn how to use it, or hire a consultant with those skills, you don't shlep down to the pop-up loft for their free 'ask-an-architect' sessions, free coffee and free candy.
It's self-funded startups and folks doing personal projects that those initiatives are aimed at, IMO, and they are the ones who would benefit from this kind of thing. By comparison, Google cloud (or at least appengine) does have billing limits, the daily ones reset each 24 hours, if you hit your billing limit, your instances just don't run until the limits reset.
To be fair though, the AWS customer service are always very quick to allow refunds, for small or large amounts. When I first started, I thought I had switched everything off, but something was still running and I got a couple of bills of around $20 over two months. When I complained, they refunded it, and were very nice about it. The are lots of cases online where they have refunded over $10,000 in fees to people who left their keys on github.
Maybe they figure the refunds are just the cost of doing business? However, I would prefer not to have to rely on the possibility of their post-hoc generosity when I do something equally stupid in future :)
In Amazon's shoes I'm not sure I'd offer a feature like that at all, because someone might set that to be "smart", forget about it as the business grows, and then have a bunch of servers terminated and/or data destroyed right during an excitingly busy period. It would be an extraordinarily bad customer experience. It could be much better for them to do as now and then occasionally credit people who accidentally go over.