101–110 of 457 posts
Earlier quoted context omitted.
The whole point of a "spending kill switch" is as a backstop when you make a mistake; but if you do it as a "DIY project", what prevents you from making a mistake on it? It has to be a built-in feature.
So what services do you kill? Everything? Including databases and S3?
AWS employs cost obfuscation by design otherwise the default view when you open the console would show you all of your current active services. Not only is that not the case, a single screen to show you all of your current active services doesn't exist. You need to take a deep dive into cost explorer (assuming you have access in corporate land) and try to decipher in what that all means.
I don’t use them for any projects mostly because I already don’t enjoy having to manage AWS at work all the time. I also don’t want to live/work in a world where AWS is my only option so I try and use smaller hosting providers and services like tarsnap.
I don't understand why there isn't at least a setting that says "turn everything off if I hit $x." Then just given people a certain grace period to reactivate or get their data out before it's removed. It wouldn't fix production deployments where you want alarms, not a shutdown, when you hit spending caps, but it would help people on the dev stage to avoid issues like this.
AWS employs cost obfuscation by design otherwise the default view when you open the console would show you all of your current active services. Not only is that not the case, a single screen to show you all of your current active services doesn't exist. You need to take a deep dive into cost explorer (assuming you have access in corporate land) and try to decipher in what that all means.
They definitely need a senior executive to stand up and say, "The Customer wants us to be transparent in billing, fix that now." Then they need to start a team dedicated to finding a good way to let customers halt spending at a given limit with minimal impact on their operations. They already win on UX (okay, okay, it's an opinion ffs), but unlimited liability makes a lot of people very uncomfortable. Those two actio…
I also remember trying to set up SFTP whenever it was first released. It was literally impossible to do what they were advertising (S3-backed SFTP with jailed homes for each user) without writing a manual json config (I never got it to work). I had built my own solution for this exact thing on EC2, using a bash script more or less, and thought the hosted option would be less of a maintenance burden. Needless to say I quickly gave up.
Is there seriously no way in AWS/Azure/GCP to specify "Here's my budget, shut everything down if I exceed $X"? I don't use those platforms much but was always surprised I couldn't find anything like that right off the bat. I'll build cloud stuff if it makes sense at work, but if I'm footing the bill I'll stick to something that can provide an actual upper limit.
IIRC the excuse is that billing is a separate department and they count all the usage dollars way after you done using it, not in realtime. You would still be able to go over your limit and then who should foot the bill? Realtime counting would be too difficult to figure out, our brightest minds are busy figuring out engagement metrics.
It's not that real time counting is difficult, it is that the amount of compute resources and electricity that would be needed to power real time billing at AWS scale would be astronomical. There is a reason why banks and financial institutions generally do batch processing in the off peak hours when electricity is cheaper and there is less demand for the compute resources. Now imagine AWS billing, which is arguably far more difficult in scale and complexity.
I still get bills on the 3rd of each month, followed by a "we can't charge your card" (I removed it when they pulled this shit) followed by a few days later you get the "hey we're gonna suspend your account if you don't pay"
Yeah cool, I only closed the account 2 years ago now, go right ahead and suspend/close/do whatever you've gotta do, I stopped caring.
Funny story: I keep receiving a $0.01 monthly invoice from AWS for a very old account (opened 5+ years ago) I have lost access to. I have no idea why (the invoice doesn't list the services being used) and the associated credit card has expired a long time ago. They requested notarized documents to prove my identity. Obviously I'd rather settle my $6 (+ interest) debt 50 years from now than give hundreds to a notary t…
All states, with exceptions listed below, cap notary charge to $10 at most. Most states are less. These states don't have limits one way or another: Alaska Arkansas Iowa Kansas Kentucky Loisiana Maine Massachusetts Puerto Rico Tennessee Vermont
Lots of companies also gets hacked each month for thousands of dollars because some key to S3 with too many privileges gets leaked. The entire system is completely sinister. The fact that keys pertaining to S3 has anything do with being able to start hundreds of VM's in different parts of the AWS system or do whatever is bad. I've seen companies be ruined by this, and it's in no way obvious how stupid their system is…
> Instead of starting with "no access" then adding atomized access you have to understand this extremely complex "json privilege system". Instead of just programming, this is the only allowed IP, the is the only allowed bucket, this is the only allowed service, ... What would that look like if it’s not going to be a series of access permissions and filters represented as JSON? Security is never a simple checkbox and…
Way to complex only needing to give permission to a single "thing". And much of the naming makes little sense to new yes.
DigitalOceans interface is easier for 90% of people.
But to be honest it's years ago that i worked with AWS, but i remember everything being way more complex than it had to be and i had to use days undestanding their enourmous interface and "usersystem". And as long as this is a problem that pops up again and again, something is very wrong with their system i would say.
If not creating a simpler interface / user system for regular users then at least give some huge warnings that unless you know what you are doing a key with the wrong JSON means access to all funds on the credit card.