"Billing alerts" are a joke, give us hard spend limits. Then offer a way to set those limits during onboarding. Building a business on blank cheques and accidental spends is shady. It's also a large barrier to adoption. The more times devs see reports like, "I tried [random 20-minute tutorial] and woke up to a bill for my life's savings and luckily support waived the fee this one time but next time they're coming for…
Hard spend limits are an anti-feature for enterprise customers, who are the core customer of AWS. Almost no level of accidental spend is worth creating downtime or data loss in a critical application. Even having the option of a hard spend limit would be hazardous, because accounting teams might push the use of such tools, and thereby risk data loss incidents when problems happen. Hard spend limits might make sense f…
Make "unlimited spend" an opt-in. That way users who have explicitly chosen this and agreed to the terms can't then complain to support to try and get the bill waived.
Every official AWS guide is designed to make you use as many AWS services as possible, which increases the risk of spend. You have to be extremely critical of anything they recommend (GUI defaults, CLI tools, guides, recommended architectures etc). There's a reason there are very well paid positions in companies to guide colleagues on how to use AWS cost-effectively and with lower risk.
Exactly. And for small scale deployments or tests, the most expensive parts are almost always the ancillary things or the newfangled services they recommend in lieu of something simpler.
Hard spend limits are an anti-feature for enterprise customers, who are the core customer of AWS. Almost no level of accidental spend is worth creating downtime or data loss in a critical application. Even having the option of a hard spend limit would be hazardous, because accounting teams might push the use of such tools, and thereby risk data loss incidents when problems happen. Hard spend limits might make sense f…
Is every problem you see so insurmountable? In the olden days if we spotted a customer ringing up a colossal bill, we would tell them. These huge Amazon bills are fast but still multiple days. They can trivially use rolling-projection windows to know when an account is having a massive spike. They could use this foresight to call the customer , ensure they're informed, give them the choice about how to continue. This…
AWS provides forecasted spend and other alerts. People just don't use them and then complain.
"Billing alerts" are a joke, give us hard spend limits. Then offer a way to set those limits during onboarding. Building a business on blank cheques and accidental spends is shady. It's also a large barrier to adoption. The more times devs see reports like, "I tried [random 20-minute tutorial] and woke up to a bill for my life's savings and luckily support waived the fee this one time but next time they're coming for…
I dont't think it is a meaningful barrier to adoption, at AWS's scale anymore.
AWS's growth doesn't come from courting small random devs working on side projects.
This is the reason I use AWS wrappers (render.com/fly.io) for small projects.
It may be more expensive but you can't pop the free tier/selected machine.
> I've been putting off digging into AWS for years now In my opinion people end up in these billing situations because they don't actually "dig in" to AWS. They make their pricing easily accessible, and while it's not always easy to understand, it is relatively easy to test as most costs scale nearly linearly. > the rational fear of waking up to massive charges. Stay away from the "wrapper" services. AWS Amplify, or…
Pretty ironic that you're actually listing more things why I would not use AWS at all. You mention: "stay away from", "ensure that you", "reasonable caching", "bandwidth is the only real nightmare" are all huge red flags.
I thought the point of deploying to the cloud using higher level services was so that I could worry about my app and stop worrying about the minutia of managing load balancers or database servers.
Instead of interesting technical challenges I now get to worry about the minutia of Amazon's billing system. Neat! Where do I sign?
I've been putting off digging into AWS for years now, and it's because of stories like these. There really should be a standardized training course that requires no credit card info and lets people experiment for free. Instead they have some pencil pushers calculating that they can milk thousands here and there from "user mistakes" that can't be easily disputed, if at all. I'm sure I'm not the only person who's been…
It is very unusual for AWS not to issue refunds in situations like this, so I don't think it's a function of them finding an edge to milk thousands from user mistakes. More likely they've found that issuing refunds is less onerous than it would be to provide accurate and cheap tutorials. Perhaps that does not excuse the behaviour but AWS reversed a $600 charge I incurred using AWS Textract where the charges were comp…
I very recently had a run away SageMaker issue that wasn't refunded. Wasn't much, only $50, but they said no.
Let's say 25% of people dont argue with customer service for a chargeback. Best run company in the world /s
It's a Tim foil hat pet conspiracy that I have, but I strongly believe that part important of the business model (or revenue share) is from people making mistakes or forgetting resources; more or less like gym subscriptions where the gym owners are more than happy to sell the [maximum_amount_of _people + 40%] knowing that the absenteeism will give the revenue offset that sustain part of the business.
I believe you are right, but no tin foil hat theory needed just sound pricing strategy. Eg. factor in underutilization but also refunds. For a flat rate, a price point at 70% of total value of included volume still is better bottom line if you set included volume high enough that the average usage is 50%, yet it still feels more generous and less risky from customer point of view. OTOH very granular unit pricing lets everyone underestimate total costs and complicates comparison with competing offers, „bread and butter“ product prices mask more uncommon ones, etc. In IT underutilization is high, also on own infra, that’s something cloud vendors (and hardware and software vendors) can rely on. Paying for it at least incentivizes to improve utilization, autoscaling is better, sometimes the cloud vendor does it for you, sometimes you have to donitnyourself. In IT laziness is rampant, time is often seen as more valuable than cash out. Also someting the vendors can rely on. I‘ve seen a howto for Azure for a scalable LLM API Gateway. It cost me almost 2 hours to get an estimate for min costs - with default values it would have cost almost 10k per month, I could size it down to less than 1k. A simple loadbalanced reverse proxy on vms cost less than 400. Be especially cautious when everyone is in a hurry. The pre-made solutions may try to cash in on that. Over all: Pricing and pricing models are part of the product properties you buy, and looking for and dealing with psychological pricing strategies and tactics is part of doing business.
It's not just AWS. I think there are only two types of cloud providers: The ones like AWS and DigitalOcean that shift the risk to the customer and the ones that offer shady "unlimited" and "unmetered" plans. Neither is what I want. I wish there was a provider with clear and documented limits to allow proper capacity planning while at the same time shifting all the availability risk to the customer but taking on the f…
It seems that automatic billing is something that cloud providers invented. For example, home Internet providers or mobile providers usually use prepaid plans, where they simply stop the service once you ran out of money (but you can connect your card account if you trust them). So you cannot get charged arbitrary amount for home Internet, and for mobile unless you travel.
Landline phone companies were always usage-based billing where you could run up huge bills by, say, making an international phone call for an hour.
"Billing alerts" are a joke, give us hard spend limits. Then offer a way to set those limits during onboarding. Building a business on blank cheques and accidental spends is shady. It's also a large barrier to adoption. The more times devs see reports like, "I tried [random 20-minute tutorial] and woke up to a bill for my life's savings and luckily support waived the fee this one time but next time they're coming for…
Hard spend limits are an anti-feature for enterprise customers, who are the core customer of AWS. Almost no level of accidental spend is worth creating downtime or data loss in a critical application. Even having the option of a hard spend limit would be hazardous, because accounting teams might push the use of such tools, and thereby risk data loss incidents when problems happen. Hard spend limits might make sense f…
> Even having the option of a hard spend limit would be hazardous, because accounting teams might push the use of such tools
Tell me you're Shadow IT without telling me you're Shadow IT.
I know legitimizing shadow IT is still the value proposition of AWS to a lot of organizations. But it sucks if that's the reason the rest of us can't get an optional feature.