|
|
|
|
|
by modeless
1800 days ago
|
|
I did this last year for my project, except instead of disabling billing which would nuke everything, I wrote a service that runs every day, looks up my remaining monthly budget and sets the daily quotas on the APIs I use so they can't use more than my budget. (Which wouldn't be necessary if they offered monthly quotas to match the monthly billing period, but they don't.) Then last month I got an email saying "Hey, those quotas you were setting using the API documented to set quotas, those were actually not being enforced the whole time because of undocumented issues with our systems." So basically you can't rely on the documented behavior of these systems, there's no good way to test whether your code is correct or whether your limits will work without actually exceeding your budget for real, and the whole thing is a clusterfuck. When you get a surprise bill you just have to throw yourself at the mercy of whichever first line billing support rep is randomly assigned to your case. Limiting your bill to something less than "potentially infinite" is just a basic fundamental feature that shouldn't require rolling your own bill-monitoring service relying on poorly documented and malfunctioning APIs with no provision for testing. There's no excuse strong enough to explain why the cloud providers can't do something reasonable here. |
|