131–140 of 170 posts
But couldn't Google/Amazon simply pretend they have real-time bill capping, and then simply swallow the costs incurred by any delays?
Doesn't seem like rocket science, probably won't cost much, and might bring in new kinds of business (a lot of businesses won't allow most employees to sign an effectively blank check)
My understanding is that this is a difficult problem to solve "perfectly" due to lag between incurring a cost and recording the cost. I believe GCP currently has the best feature for this. You can set both billing alerts as well as caps. However, I also believe that it can take up to 24 hours between incurring a cost and it showing up on your billing report. So even on GCP (which is the most forward-thinking cloud se…
That is an argument for why these overages occur. It isn't an argument for why customers should eat that cost rather than Amazon. In fact Amazon is in a much better position than customers to absorb those costs. Sure, they'd have to increase rates slightly to cover it. But it would give customers peace of mind. And if the costs become exorbitant, Amazon is in a better position to improve their own systems to reduce t…
How is this going to be implemented? When it reach the cap, all your service stop working? This is incredibly user hostile. If you want some warning when utilization is high, it can be relatively easy to setup with AWS's existing feature, but you need to do some configuration/tweaking on your own.
> When it reach the cap, all your service stop working? That exactly what I would like to have. Services stop and I get time to review what's happened without any stress that my bank account will be emptied.
Having a killer switch that could make one's AWS account stop would be a risk for big customers, I would predict, if it is misconfigured, maybe even intentionally. A better solution for them would be alerts, and get things right afterwards.
Earlier quoted context omitted.
> When it reach the cap, all your service stop working? That exactly what I would like to have. Services stop and I get time to review what's happened without any stress that my bank account will be emptied.
AWS has both big/small customers, I would say those two have very different priorities when it comes to SLA. Having a killer switch that could make one's AWS account stop would be a risk for big customers, I would predict, if it is misconfigured, maybe even intentionally. A better solution for them would be alerts, and get things right afterwards.
My understanding is that this is a difficult problem to solve "perfectly" due to lag between incurring a cost and recording the cost. I believe GCP currently has the best feature for this. You can set both billing alerts as well as caps. However, I also believe that it can take up to 24 hours between incurring a cost and it showing up on your billing report. So even on GCP (which is the most forward-thinking cloud se…
but Azure has a cap? if MSFT can do it, what is preventing GCP or Amazon to do the same. and it takes GCP a day to report billing to consumer. they can monitor the data earlier than that, and stop the services early
i looked into this a year ago and there was no such thing available (there is https://docs.microsoft.com/en-us/azure/cost-management-billi... but that is not really a spending limit, it's more like in some cases you get credits from microsoft and when you have spent all the credits they stop things for you). i mean a system where you pay monthly what you consumed, and you can set a limit, and the provider guarantees that you do not have to pay more than the limit.
but maybe i overlooked something, so if you know more about this, please tell.
btw. fly.io has a kind-of spending-limit, you can preload some credit into the account and when that is spent you are relatively safe ( https://community.fly.io/t/can-i-set-a-billing-limit-per-mon... )
It hasn't been implemented because it is nonsensical. So you hit your limit. Is all your storage deleted? You can't receive an alert because that costs something (even if it's a fraction of a cent) to send. Are your domains forfeit? Audit logs destroyed? There's no reasonable way to implement this. Billing alerts are the best you can do on this problem and I think it would be a good faith move for AWS to enable some…
> There's no reasonable way to implement this. Oh, really? Azure wants to have a word with you ... Yes, currently they don't enable this for subscriptions with commitment plans or with pay-as-you-go pricing, but it is not because it is not possible or feasible, as you argue - the technical infrastructure in the form of spending limits, spending budgets and quotas is there [1-3] and is available for select plans [4].…
Earlier quoted context omitted.
That is an argument for why these overages occur. It isn't an argument for why customers should eat that cost rather than Amazon. In fact Amazon is in a much better position than customers to absorb those costs. Sure, they'd have to increase rates slightly to cover it. But it would give customers peace of mind. And if the costs become exorbitant, Amazon is in a better position to improve their own systems to reduce t…
I would argue that AWS does not have a "Customer Obsession", and that's exactly why it's Amazon's most profitable business (by far) and the underwriter of all of Bezos's ambitions.
AWS does indeed obsess about the customer. Every step along the chain there is someone there advocating for the customer. There are mechanisms to keep the customer in mind even for the developers who actually code the service and don't talk to customers on a daily basis.
I've had many, many service team members shadow me as I worked their service's tickets. This is explicitly so they can see in real time customer pain-points. If a customer has a question about a unique use case, the service team will proactively reach out to support engineers to set up a call to discuss the use case further. There are monthly (or twice-monthly) meetings between support service owners (i.e. those people in support who 'own' a service) and service teams to identify the top issues customers are having with the service. AWS is constantly looking for ways to better assist customers, make support less difficult for customers, increase self-service options for customers, etc.
I'm really, really curious where the basis behind your argument. Because from everything I've seen and been a part of, it's simply untrue.
Earlier quoted context omitted.
> AWS has to think of everyone. Sure. That's why you make it optional. And configurable in a way But at a very basic idea, blocking new services from being started and throttling of existing ones would go a long way in helping. A very long way.
You can implement this on top of budget actions today: https://aws.amazon.com/blogs/aws-cost-management/get-started...
None have the engineering capacity to figure out how to cap the spending on each one of the individual services, each with their unique and special API.
You're arguing that Amazon can't afford the difficult engineering of spending caps, but the very customers that need spending caps because their budgets are so constrained are so well moneyed that they should all individually be able to invent a solution, engineer it, and manage it?
Earlier quoted context omitted.
I would argue that AWS does not have a "Customer Obsession", and that's exactly why it's Amazon's most profitable business (by far) and the underwriter of all of Bezos's ambitions.
Disclosure: AWS employee. Support specifically. There are good things about my employer. There are bad things about my employer. AWS does indeed obsess about the customer. Every step along the chain there is someone there advocating for the customer. There are mechanisms to keep the customer in mind even for the developers who actually code the service and don't talk to customers on a daily basis. I've had many, many…
Do Google/Azure have this?
Not sure about Google, but Azure has it with some subscription types but not all. I have an Azure subscription that gets some free monthly credits. When I go over the limit on that subscription, everything freezes until I sort it out.