[zsoltkacsandi]

They don't know in advance how much bandwidth will you use, how much traffic will you have, what auto-scaling rule will it trigger, etc. It's not obfuscation, it's billing based on your usage. And as with everything in life, there are tradeoffs.

[eptcyka]

Give me a slider for bandwidth used or a formula where the variables are abstracted away. If a computer can tell me how much I owe, a computer can be made to show how it came to it’s conclusion.

[sillyfluke]

Now explain why they don't have a killswitch for a user defined spending limit.

[simondotau]

IMHO it should be illegal to force consumers to have an infinite spending limit on a post-paid service with consumption charges. If I want to cap my unpaid expenditure at any amount, I should be legally entitled to do so.

[nostrebored]

How many real applications actually want this behavior? AWS is not built around hobbyist needs. It’s built around being a platform to run most shapes of production use cases.

[sillyfluke]

This has been a feature request since AWS was a thing.

>AWS is not built around hobbyist needs

Yes, as if no startup teams are tasked to remain within hard spending targets when they're trying to build a POC with technologies that they are not initially experts in.

[pixl97]

I mean, by the number of people that end up with 100,000 charges in a few hours posting on HN, I'd say a lot more than you're giving it credit for.

[Capricorn2481]

I don't think companies want their bill run up either.

[lukeschlather]

It's very common for companies to have a $1M/year contract that depends on $100k/year in AWS resources. (and maybe they have 3+ such contracts.) They could lose a contract if their account gets shut down for nonpayment, it's hard to say how much of an overage they would prefer to having their account suspended, but AWS is optimized for these kinds of customers where every dollar spent on hosting drives some multiple of revenue.

[zsoltkacsandi]

You can set up cost-based alerts (actual or forecasted) that send notifications via email or SNS. Based on this you can set up automations, such as applying an IAM policy to prevent further resource creation, shut down resources, etc.

[zsoltkacsandi]

Interesting to see that some people assumed there are no kill-switch mechanism, and when it turns out they just did not know about it, the (totally valid and factful) comment gets downvoted because it is against their initial assumption. Not what I would have expected on a professional forum.

[Demiurge]

I do not downvote comments when I disagree, and I think it’s better to explain why I would strongly disagree. Downvoting in this case almost reinforces the notion that the downvoted comment makes such a good point that it causes people to give up on the discourse and just smash the panic downvote button. It’s obvious to me why this is not the case for this comment.

The suggestion to setup some kind of IAM policy to shut things down and stop resource usage is insanely complicated for users who need this kind of feature the most. If I’m learning AWS and just added my CC to it, I am the last person to be qualified to setup this kind of an alert and policy from scratch. This needs to be a single text input in the billing page, like it is for countless spend-as-you-go services. When the limit is hit, the service needs to stop the usage at the customers peril, because that’s what they customer requests.

Hope this helps.

[zsoltkacsandi]

> The suggestion to setup some kind of IAM policy to shut things down and stop resource usage is insanely complicated for users who need this kind of feature the most.

We set this up at my last job like in 10 minutes. Complexity is a matter of perspective, and if your job to do this, you have done this many-many times, and you have ready to use infrastructure as code templates.

Yes, AWS is massive, the documentation is huge and makes things inherently complex, but flexible too. You can define what behavior do you want when you exceed your limits. We can argue whether this is obfuscation or complexity or what, but based on my experience AWS optimizes it's product for enterprise-ish companies, that can afford to have SREs who knows exactly what to do in such cases. That is where they have their own training/certification program. For simple use cases there is AWS Lightsail where pricing is simple and easy to understand.

But even if it would be insanely complicated, that is a reason to downvote? HN used to be better than this kind of "I don't like your comment, let's downvote it".

[mikeyouse]

Sure, but providing estimated costs based on reasonable pricing buckets alongside the options to add the new machine is something that every other vendor manages to do..

[timr]

...and AWS does it too. I can go right into an account and see an estimated cost per hour, and even pre-pay at a fixed discount for longer terms if I want to. They tell me right there what it will cost. They do this for everything that is reasonably a "fixed cost", like CPU time.

They cannot predict what my bandwidth consumption will be, or other such variable costs. For those, they tell you rates.

[Capricorn2481]

No it's pretty bad. They show you the cost after all the resources are set up. Even setting up an ec2 instance, a really basic use case that has a fixed cost based on size, you have to go Google it and find their ec2 pricing table. It would take no space to just put the price per hour in the drop-down as you're picking an instance. But no, they obscure it on purpose.

That's just for ec2. Everything is like this. Super awesome when you're being brought onto a new project and trying to estimate costs for your client. And let's not forget the little tiny things that should cost nothing. A NAT gateway with no redundancy is $30/mo. That's a fun surprise.

[cyberax]

> Even setting up an ec2 instance, a really basic use case that has a fixed cost based on size, you have to go Google it and find their ec2 pricing table

This is the "Comparison Table" from the EC2 launch wizard: https://imgur.com/a/YjFhkzb

The pricing is right there, along with filtering and sorting.

[Capricorn2481]

For the record, my original complaint that ec2 did not have pricing in the dropdown seems to be untrue right now, which is great! For the sake of UX discussion, I want to talk about your picture as if that were the only way to get this info. So let me explain why that's bad.

The main reason is this is only true for ec2 and every other resource has its own slightly different way of getting the cost, making it really easy to miss things like this. But here are the steps we take to get to your image.

- First you click compare instance types, and you're brought to a completely different page with a table.

- By default, there is no column for pricing, but two columns for "storage space" even though most of the instance types have these blank.

- There's nothing that says you can add columns to this page. You eventually figure out it's the gear icon.

- Then you click the gear on the top right to look at column names. You try searching the 44 column names for "price" or "cost" but both of those turn up blank, because there's no fuzzy searching.

- So rather than use the search box, you manually scroll through all 44 column names and find pricing at the bottom of the list.

This is the definition of out of the way. It's hard to imagine why you would default to showing two different storage columns over the pricing column, when half the instances are blank on storage.

Now do FSx, which has no pricing information at all, or any links to pricing information. They have an info tab telling you your backups are incremental, which would make you think they are fairly inexpensive. Not more expensive than the filesystem itself!

[cyberax]

This is simply because AWS UI is not made by one team. Each individual team makes their own UI/UX decisions, and things like pricing info just get forgotten and/or scheduled "for later".

So they just added a default table widget, and they didn't even bother with customizing it. You can enable the context menu for the table's rows, which works and is empty.

I worked at AWS around 6 years ago, and we had a great win with just getting access to a service that provided the full list of available instance types and base prices.

This kind of disjointness is both good and bad. It's good in the sense that individual services stay within reasonable complexity, and usually all the functionality is available through the public APIs because the UI console is just another consumer of these APIs. AWS is also very careful with permissions, internal services try to avoid escalating privileges and try to perform everything using the user-visible access policies.

But it's bad because integration just sucks, and the UI layer is the ultimate example of this. AWS console _is_ really messy.

[cyberax]

And to add to this: AWS teams were also quite focused on avoiding surprise bills for customers. Because surprise bills led to customer support interactions, Sev2/3 tickets that needed investigation, etc.

[tomrod]

Price simulators are fine. They also know the distribution of use. They can do cost plus pricing (many cloud providers do). You're defending deliberately obfuscated pricing when it need not be obfuscated.

[zsoltkacsandi]

> Price simulators are fine.

Yes, as long as you do not have seasonal traffic, auto-scaling, spot instances, burstable instances, saving plans, reserved instances, floor/custom pricing, etc. These are tools to optimize your spendings and spend less if you know what you are doing.

> defending deliberately obfuscated pricing

A bit contradictory that price simulators are fine, but then the pricing is deliberately obfuscated. Then which one?

[mlhpdx]

As I read through these comments I’m thinking about the dynamic range of AWS customers: from my little hobby account to my business account to some hyper-scaler’s account.

I think about the diversity in usage patterns: from generating giant video stream broadcast somebody trying to calculate yet another digit of pi. It’s wild.

Is true, probably, that AWS doesn’t know how much anyone’s use case will cost (even when it’s yet another version of something we’ve seen before). Too many variable.

If only there were some kind of software with a text based, natural language interface that we could ask a question like “how much would it cost to do XYNZ on AWS?”