This is something I think about a lot. For work, I run a cloud service, and being able to accomodate students (and other cost-sensitive users) like the one in the post is important to me. I've always thought that letting people experiment over the weekend is what leads to people wanting to use something at work (where the real budget is), and I think that supporting those users is how you build a userbase of advocates. Maybe they can't afford (or justify) the enterprise plan quite yet, but they can still be a happy user and cheer on those that can justify the expense.
I've personally found that it can be hard to get the approval to type in your company credit card until you've done enough research to prove that something is going to be worth the money. That leads to a chicken and the egg problem; people won't be confident until they've paid, but they can't gain that confidence until they pay! So you have to get the small "testing" use case perfect, or you'll never have any real customers. (My corollary to this is because AWS already has your company credit card, and you already have "root" or similar because of your role, it sure is easy to build whatever you want there. If AWS provides some service, you can start using it and the cost will be lost in the noise. But if it's not on AWS, then you'll have to produce some justification to use the service before you can start paying for it. I ran into that a lot at my last job; I wanted to buy $5/month services like Sentry but was told no, whereas other people could just create a m4.4xlarge RDS instance for $1000/month and nobody even noticed or cared. People really like being approvers at the time of entering the credit card, rather than at the time of actual cost accrual, and cloud providers really facilitate that. Not sure that's really helping those approvers -- it almost feels a little bit like embezzlement.)
Anyway, ranting aside, here's what we do for the cloud service I work on:
1) We have a free tier. It's really free; you don't even get to enter a credit card. Sign in and start doing your work. (We delete your stuff after 4 hours, though.)
2) For the paid tier, all costs are pay as you go. The instant you click "delete workspace", no more costs accrue. Merely having an account open doesn't accrue any costs for you, and there is no way to create a phantom resource that you can't see in the UI and delete. If you delete everything, billing is over.
One weakness that I'd like to fix is the latency between resource use and when we tell you about it. That takes a few days, so if you are playing with aggressive autoscaling, you don't really know what it's going to cost until your experiment is over. I'd like to collect real-time usage data and just bill based off of that, so that the UI can update you within seconds of your job starting. If it's too much, you can just pull the plug and not be surprised.
The next step is letting people pre-pay, and do what the vast majority of comments on this thread want: kill the compute resources when the budget is exceeded. My thought is that it's hard to ask your customers for money upfront, which is probably where the post-pay model originated. I personally always have reservations about buying 3 year reserved instances from cloud providers, even if it saves a ton of money. "What if we stop using it tomorrow!?" But there is probably a good compromise here: type into the UI what you'd like to pay for autoscaling per month, and once that budget it exceeded, run at the bare minimum "keep the lights on" level. More difficult than the alternative, but certainly possible. And very good for users -- no total outage, no unexpected bill they have no hope of being able to pay. Things are just slower for a while.
Anyway, I don't know what the perfect formula for cloud pricing is -- but it's clear that what AWS has is not quite right, and that we can probably do better. To paraphrase Jeff Bezos ("your margin is my opportunity"), what AWS has consistently done wrong for years is your chance to make it better and get paid for doing so.
I've personally found that it can be hard to get the approval to type in your company credit card until you've done enough research to prove that something is going to be worth the money. That leads to a chicken and the egg problem; people won't be confident until they've paid, but they can't gain that confidence until they pay! So you have to get the small "testing" use case perfect, or you'll never have any real customers. (My corollary to this is because AWS already has your company credit card, and you already have "root" or similar because of your role, it sure is easy to build whatever you want there. If AWS provides some service, you can start using it and the cost will be lost in the noise. But if it's not on AWS, then you'll have to produce some justification to use the service before you can start paying for it. I ran into that a lot at my last job; I wanted to buy $5/month services like Sentry but was told no, whereas other people could just create a m4.4xlarge RDS instance for $1000/month and nobody even noticed or cared. People really like being approvers at the time of entering the credit card, rather than at the time of actual cost accrual, and cloud providers really facilitate that. Not sure that's really helping those approvers -- it almost feels a little bit like embezzlement.)
Anyway, ranting aside, here's what we do for the cloud service I work on:
1) We have a free tier. It's really free; you don't even get to enter a credit card. Sign in and start doing your work. (We delete your stuff after 4 hours, though.)
2) For the paid tier, all costs are pay as you go. The instant you click "delete workspace", no more costs accrue. Merely having an account open doesn't accrue any costs for you, and there is no way to create a phantom resource that you can't see in the UI and delete. If you delete everything, billing is over.
One weakness that I'd like to fix is the latency between resource use and when we tell you about it. That takes a few days, so if you are playing with aggressive autoscaling, you don't really know what it's going to cost until your experiment is over. I'd like to collect real-time usage data and just bill based off of that, so that the UI can update you within seconds of your job starting. If it's too much, you can just pull the plug and not be surprised.
The next step is letting people pre-pay, and do what the vast majority of comments on this thread want: kill the compute resources when the budget is exceeded. My thought is that it's hard to ask your customers for money upfront, which is probably where the post-pay model originated. I personally always have reservations about buying 3 year reserved instances from cloud providers, even if it saves a ton of money. "What if we stop using it tomorrow!?" But there is probably a good compromise here: type into the UI what you'd like to pay for autoscaling per month, and once that budget it exceeded, run at the bare minimum "keep the lights on" level. More difficult than the alternative, but certainly possible. And very good for users -- no total outage, no unexpected bill they have no hope of being able to pay. Things are just slower for a while.
Anyway, I don't know what the perfect formula for cloud pricing is -- but it's clear that what AWS has is not quite right, and that we can probably do better. To paraphrase Jeff Bezos ("your margin is my opportunity"), what AWS has consistently done wrong for years is your chance to make it better and get paid for doing so.