101–110 of 152 posts
I can't help but think that if benign decisions lead to disasters like this in the cloud, how much destruction could robots wreak in the future due to similar benign choices?
Earlier quoted context omitted.
It's not a DDOS becuase it's not distributed and there was no denial of service. And it doesn't work "across the entire interwebs" because the Google bots are rate-limited against most websites. There are some whitelisted sites, like S3, that are not rate-limited. S3 did not go down in this "attack". In fact the app didn't even go down. So the decision not to rate-limit against S3 was sound, since there was no DDOS.
Are you saying Google isn't distributed? In any case, it may not be a denial-of-service, but if you can find someone with an S3 bucket with large files you could maliciously cause them to rack up a huge bandwidth bill using this mechanism. I guess you could say it's a DDOM (Distributed Denial of Money).
kudos to Amazon for running time backward and letting you pull your foot out of the way. I can't help but think that if benign decisions lead to disasters like this in the cloud, how much destruction could robots wreak in the future due to similar benign choices?
Earlier quoted context omitted.
I have a VPS on buyvm which includes 2TB/month for $6. Each extra TB is another $2.50. This is not a special case, you can other providers with very good pricing for data transfer. I don't understand how the difference in bandwidth pricing can be so large. I'm also certain that Amazon doesn't pay as much for bandwidth as the guy from buyvm.
buyvm is overselling their bandwidth to you. Real uplink pricing is not 2 dollars per terabyte. If you actually tried to use say 13 terabytes from a single vm, it would work eithe because of rate limmiting on your uplink or they would cut you off.
+1 For Amazon for kindly reimbursing the overage charge. -1 For Google for creating what is the biggest threat to content providers by enabling easy-to-use DDOS attacks across the entire interwebs. Seriously, is this what we have to look forward to when Google Spreadsheets, and God knows what else, become ever-more popular? Think about all the additional onerus costs that would be incurred by content providers as mor…
Like the author notes, I don't think the problem was with Google. It was no fault of theirs. The reason: It's a fine line between maintaining privacy policies and managing such events. If google were storing/caching these links, there would have been an outcry from those worried about user privacy and stuff. About the by-the-hour downloads, well there again is a trade-off between providing data quickly and doing a la…
Earlier quoted context omitted.
Like the author notes, I don't think the problem was with Google. It was no fault of theirs. The reason: It's a fine line between maintaining privacy policies and managing such events. If google were storing/caching these links, there would have been an outcry from those worried about user privacy and stuff. About the by-the-hour downloads, well there again is a trade-off between providing data quickly and doing a la…
I don't understand the privacy concern - a publicly accessible URL doesn't offer any privacy. It's the same as a transparent proxy.
There have been similar complaints about attempts to aggregate the contents of Hacker News posts, for example.
Reminds me of the email cannon we built on Gmail, not exactly on purpose. We needed a full Gmail account to do some testing on our company's email backup system. At the time that meant 8GB of email. And you couldn't just send a bunch of huge attachments, as it had to be like regular email. So we took a gmail account and signed it up for dozens of active linux related email lists (because they were easy to find). The…
I think I was hoping to produce an "email cannon" similar to yours - an email spammer to be directed at whoever I liked.
Earlier quoted context omitted.
In the end, we are talking about a finite resource, because the Internet can only handle so much data transfer at one time. One way or another, your packets have to travel over physical infrastructure which, just like your home network, has a maximum capacity. Use of this infrastructure costs money; charging by bandwidth should help prevent users from "clogging the tubes" willy-nilly because there is a cost associate…
Except most providers don't charge by time and demand (which would actually make sense), but by a fixed cap or fixed cost per byte. If the problem is congestion as you suggest, surely it would make more sense to charge different amounts based on time of day, length of session, etc? Which would give Amazon more trouble? 1,000 TB spread out over a month, or 1,000 TB spread out over a day? Their current pricing model as…
AWS can actually do a setting for max bandwidth per hour or so & alert early if there is suspicious activity.