Live data from Hacker News

AWS now allows customers to pay for their usage in advance

aws.amazon.com

91–100 of 184 posts

Re: AWS now allows customers to pay for their usage in advance

#91
post #74
post #60

Earlier quoted context omitted.

> Perhaps having separate AWS accounts ... You absolutely must, MUST, MUST be using separate AWS accounts for separate purposes. You can have as many as you’d like and roll up the billing into one actual paying account. This is a win for accountability (roll up dev and easily see the split out for separate environments), but more importantly for security as it limits the blast radius for any one environment. Combined…

It may be a 'must' for security but from a UX perspective it is a horrible experience. Does it make sense for one team to have 10+ AWS accounts per service because 'security'? How about if each team out of 1000s in your company has 10 AWS accounts per service? We run our service in 3 geographic regions and have a separate AWS account for each region and stage despite each account supporting resources in multiple regi…

The UX issue you're describing...can and should be solved with UX.

While security and UX are oftentimes in tension, in this case they don't have to be. It would not be that hard to be signed into multiple accounts and allow you to switch seamlessly between them (allow the tagging of each account, such that you can say, effectively, "show me dev us-east-1" vs "show me us-east-1" vs "show me dev", slicing and dicing between accounts that way). At that point, separating infra across accounts becomes semantically meaningful, and you can slice/dice in whatever way seems best (so you could have a full account for a single service, sure. Or an environment. Or a region. Or a combination of those, only service-Foo in us-east-1 for dev. Whatever level of granularity you want; trading off instead between the security of isolation with the convenience of colocation, which should be the actual UX cost; infra in the us-east-1 account has a harder time communicating with the infra in the us-west-1 account).

Re: AWS now allows customers to pay for their usage in advance

#92
post #84
post #74

Earlier quoted context omitted.

It may be a 'must' for security but from a UX perspective it is a horrible experience. Does it make sense for one team to have 10+ AWS accounts per service because 'security'? How about if each team out of 1000s in your company has 10 AWS accounts per service? We run our service in 3 geographic regions and have a separate AWS account for each region and stage despite each account supporting resources in multiple regi…

I was so happy when I finally got cross-account roles working so I could use a nice drop down and seamlessly switch between my accounts. So cool! Then I learned because they’re saving it all browser-side I had to rebuild the whole menu whenever I first used a new browser or computer? Whaaaat? Of all people, AWS console users have to be highly likely to be using multiple devices/browsers. Having to recreate your own p…

Not to mention that the there is a pretty small limit on how many can show up in the drop down (I don't remember how many) so it isn't very scalable if you follow the recommendations to create a lot of accounts.

Plus you have to look up the account id in order to set it up initially.

Re: AWS now allows customers to pay for their usage in advance

#93
post #77

Earlier quoted context omitted.

Single most obvious customer obsessed (their tenet BTW) feature they could add, but after over a decade of requests, it's seemingly clear they won't. It keeps me from playing with AWS for side projects as well. Their loss.

This is something that everyone seems to ask for (I know I'd love it), but they haven't implemented it. To me that suggests that they _can't_. My guess is that billing lags enough that they can't stick to a price cap, which means that they either have to guarantee the price cap and swallow the difference, which could be exploited by malicious users to get free compute, or they have to say that there's a delay on it w…

When I fill my tank with gas, there's a preauthorization with my credit card before I'm allowed to pump a single drop. It seems like a similar arrangement could be made here w/r to hourly level billing. And it would be a huge improvement over the current situation which scares me away.

Re: AWS now allows customers to pay for their usage in advance

#96

Earlier quoted context omitted.

I've read that some people use a pre-paid credit card with a $1 spending limit when setting up their playground accounts. Seems like a reasonable approach.

You will still owe the incurred charges and AWS can send it to collections.

I do this. I’d much rather have AWS needing to call me to negotiate / collect than having $15k go through my CC as a legit authorized charge.

Re: AWS now allows customers to pay for their usage in advance

#97
post #74

Earlier quoted context omitted.

It may be a 'must' for security but from a UX perspective it is a horrible experience. Does it make sense for one team to have 10+ AWS accounts per service because 'security'? How about if each team out of 1000s in your company has 10 AWS accounts per service? We run our service in 3 geographic regions and have a separate AWS account for each region and stage despite each account supporting resources in multiple regi…

The UX issue you're describing...can and should be solved with UX. While security and UX are oftentimes in tension, in this case they don't have to be. It would not be that hard to be signed into multiple accounts and allow you to switch seamlessly between them (allow the tagging of each account, such that you can say, effectively, "show me dev us-east-1" vs "show me us-east-1" vs "show me dev", slicing and dicing be…

I already set this up. My customers are 5-10 man shops, and they have 5 different AWS Accounts: One for billing, one for Build Infrastructure, one each for Dev/Staging/Prod. Sometimes marketing is treated as a separate product team and their website has it's own staging/prod accounts (No real need for "dev" in that case).

Users login to the Build Infra account and then Assume Role into the others - There's a list of magic links that does the assume role. There's also a list that is added to ~/.aws/config that does the equivalent: They configure one IAM key, and the rest are assumed automatically by the CLI or client libraries (Requires relatively recent client libraries; Java only started supporting this within the last year or two)

Re: AWS now allows customers to pay for their usage in advance

#98
post #15

Does this mean I can set up a static website on S3, pre-pay fir the next hundred years of hosting costs and then pretty much forget about it? Because I would genuinely love to be able to do that.

Yes, but no. You could pre-pay for the next 100 years, but there’s no guarantee you would get 100 years of service. Nothing stopping AWS increasing prices during that period, and you’d be subject to those increases just like everyone else.

Re: AWS now allows customers to pay for their usage in advance

#99
post #84
post #74

Earlier quoted context omitted.

It may be a 'must' for security but from a UX perspective it is a horrible experience. Does it make sense for one team to have 10+ AWS accounts per service because 'security'? How about if each team out of 1000s in your company has 10 AWS accounts per service? We run our service in 3 geographic regions and have a separate AWS account for each region and stage despite each account supporting resources in multiple regi…

I was so happy when I finally got cross-account roles working so I could use a nice drop down and seamlessly switch between my accounts. So cool! Then I learned because they’re saving it all browser-side I had to rebuild the whole menu whenever I first used a new browser or computer? Whaaaat? Of all people, AWS console users have to be highly likely to be using multiple devices/browsers. Having to recreate your own p…

https://addons.mozilla.org/en-US/firefox/addon/aws-extend-sw...

Re: AWS now allows customers to pay for their usage in advance

#100

I really wish you could just designate a group of resources as unimportant, set a billing limit, and let Amazon nuke everything / delete your files / whatever, if you go over the limit. Everytime I try to learn cloud infrastructure stuff I'm terrified of the literally infinite bill that might show up from a typo a month down the line.

I think GCP's official method for doing this is pretty similar to what you describe. You basically create a cloud function that disables billing if your bill goes over a configured limit. It's not perfect, because there's a tiny bit of lag between usage and billing calculation, but you'll only end up with a few dollars over the limit instead of thousands. Truly the nuclear option though.

This official method is so broken that it's embarrassing that they recommend it. It looks like a solution, but it doesn't work.

The "tiny bit of lag" between usage and billing calculation explodes when there's a lot of usage - in my case, a broken job tried resubmitting itself continuously, and the lag increased to 8 hours and $5000 just when I needed the alert the most. My team's response time was 5 minutes... After the 8 hour GCP lag.

Very similar to this guy's story: https://blog.tomilkieway.com/72k-1/

I had to go back and forth with them on email for weeks, and ultimately threaten them with a draft blog post with a lot of graphs and screenshots of their recommendations for them to cancel the bill.

Post reply on HN