It seems likely their policies are a response to the risk that abusers will mine cryptocurrency, then skip out without paying the bill. Register multiple accounts, repeat ad nauseum.
Even requiring a credit card isn't too helpful because cryptocurrency can be cashed out right away, while credit cards transactions can be reversed.
Also, for new accounts which have not been billed yet there is a lot of uncertainty about whether the account was really registered by the cardholder.
This is a nontrivial fraud problem, and the cloud provider response is a first approximation to a solution. I would expect that as they engineer better fraud signals and risk scoring, they'll eventually be able to offer gpus to new accounts.
That's possible, although my understanding is it's more of a capacity planning issue. Indeed, new users can fire up a bunch of much more experience massively multi-core instances and rack up bigger bills than with the GPU instances.
But whatever the reasoning is, the lack of communication of the issue to customers and support staff, and the pointless marketing of a product that new users can't access, is a recipe for frustration.
Funny enough they could solve this problem with cryptocurrency. Small payments are irreversible after about 10 minutes, and 5 digit payments are irreversible after about an hour, at least when Bitcoin is the base.
g2 are the EC2 instances designed for graphics usage; they're typically aimed at GPU encoding rather than machine learning, like what the blog poster is aiming for.
Not to say they couldn't cover either, but the GPU classes used between the two instance types are very different; g2 is GRID based, p2 is using Tesla.
I don't think that the GRID GPUs have RDMA, although not being into machine learning I don't know how important that would be.
The real problem is that the documentation you've linked to (The EC2 FAQ) actually shows that the p2 instances should have a spot limit of 1, but when I check my account, it's actually 0 for all sizes of p2 instances.
It doesn't seem to matter what region I choose, it just doesn't match the FAQ; p2 is on request only.
> The real problem is that the documentation you've linked to (The EC2 FAQ) actually shows that the p2 instances should have a spot limit of 1, but when I check my account, it's actually 0 for all sizes of p2 instances.
Exactly. The lack of (and indeed, plain wrong) communication to customers and support staff is the biggest problem here.
This guy's whining about nothing. The concurrency limits are there for capacity planning and to limit possibility of accidental overuse. Raising a support ticket is all it takes to get the limits raised.
His point is that he runs a MOOC and his students have their own AWS accounts. Since they are students, and do not have established histories at Amazon presumably they aren't able to get these limits increased, and so can't do the labs for the course which require a GPU.
His biggest objection was that this wasn't documented anywhere, and so he's built a course and sold it to students based on the promise of an on-demand GPU for labs, but they can't actually participate since they don't have the history required to get their GPU limit raised above zero.
Once you know the limit is there, you know to request the increase. For my students, this was less than obvious.
Furthermore, decisions as to who were accepted and who rejected were really wacky. For instance, my co-instructor's request (who in her request included a link to the course and her linkedin, and who has a Duke math PhD, worked as a quant, and was a data scientist at Uber) was denied!
Thanks for looking into it. I just added a couple more concerns to the post:
* The totally bizarre responses that requests received. For instance, my co-instructor's request (who in her request included a link to the course and her linkedin, and who has a Duke math PhD, worked as a quant, and was a data scientist at Uber) was denied, whereas some students who provided no justification were accepted, on the same day!
* Why some of our students, who were fully paid-up, suddenly found their access cut off in the middle of the course.
Just wanted to update this thread to lets folks know that AWS reached out and helped us find a solution for our MOOC students. I've updated the post with this information.
28 comments
[ 2.9 ms ] story [ 60.1 ms ] threadEven requiring a credit card isn't too helpful because cryptocurrency can be cashed out right away, while credit cards transactions can be reversed.
Also, for new accounts which have not been billed yet there is a lot of uncertainty about whether the account was really registered by the cardholder.
This is a nontrivial fraud problem, and the cloud provider response is a first approximation to a solution. I would expect that as they engineer better fraud signals and risk scoring, they'll eventually be able to offer gpus to new accounts.
There are a number of currencies specifically designed to be gpu mineable, in an effort to be more "democratic".
Ethereum, Monero, Zcash, Sia off the top of my head, I am pretty confident there are at least a few dozen others as well.
But whatever the reasoning is, the lack of communication of the issue to customers and support staff, and the pointless marketing of a product that new users can't access, is a recipe for frustration.
That said if you have an amazon or an msft account which was billed in the past it's likely to count.
FWIW it only took me about one week to get approved and there was no difficulty in it, I just put in two tickets and that was it.
Do you see something different in EC2 Console? https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reso...
Anyway, the solution to the problem is request a Limit Increase using the relevant form: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reso...
Not to say they couldn't cover either, but the GPU classes used between the two instance types are very different; g2 is GRID based, p2 is using Tesla. I don't think that the GRID GPUs have RDMA, although not being into machine learning I don't know how important that would be.
The real problem is that the documentation you've linked to (The EC2 FAQ) actually shows that the p2 instances should have a spot limit of 1, but when I check my account, it's actually 0 for all sizes of p2 instances.
It doesn't seem to matter what region I choose, it just doesn't match the FAQ; p2 is on request only.
Exactly. The lack of (and indeed, plain wrong) communication to customers and support staff is the biggest problem here.
His biggest objection was that this wasn't documented anywhere, and so he's built a course and sold it to students based on the promise of an on-demand GPU for labs, but they can't actually participate since they don't have the history required to get their GPU limit raised above zero.
At my day job, we also don't have many issues accessing clusters of up to 20 p2 instances.
Furthermore, decisions as to who were accepted and who rejected were really wacky. For instance, my co-instructor's request (who in her request included a link to the course and her linkedin, and who has a Duke math PhD, worked as a quant, and was a data scientist at Uber) was denied!
We have some folks looking through his post and the comments on this thread to help make cases like this a bit clearer. Thanks!
* The totally bizarre responses that requests received. For instance, my co-instructor's request (who in her request included a link to the course and her linkedin, and who has a Duke math PhD, worked as a quant, and was a data scientist at Uber) was denied, whereas some students who provided no justification were accepted, on the same day!
* Why some of our students, who were fully paid-up, suddenly found their access cut off in the middle of the course.