71–80 of 149 posts
That's sure nice, but I'm waiting for AWS to switch to automatic sustained use discounts [0] like GCP offers. [0]: https://cloud.google.com/compute/docs/sustained-use-discount...
I'm waiting for GCP to support preemptible GPU instances. Would love to be able to spend ~50% less on GPU instances when running a batch job that can be stopped and reloaded.
Earlier quoted context omitted.
If you're concerned about cost, AWS is almost never the right place to host to begin with.
Agreed - just check cloud comparison, AWS is rarely at the top: https://www.cloudorado.com/cloud_server_comparison.jsp
Not to mention all the big names missing from that list. For some reason Dimension Data makes the list (and it's woeful, from experience), but there's no Digital Ocean, OVH, Hetzner, etc...
Earlier quoted context omitted.
Wow thanks for sharing this link. Didn't know about this. One thing I noticed though is the pricing seems a bit biased; for example for AWS it recommends an m1.small with 1GB Ram and 20GB of Storage at $35 a month ... However if you used a t2.micro that would give you the same specs for $10.79
Not quite the same, you don't own the whole core on the t2 and will get cpu throttled.
Moving the goalposts here. 'Not owning the whole core' is the default in the cloud.
Earlier quoted context omitted.
If you're concerned about cost, AWS is almost never the right place to host to begin with.
You miss the point. The lifetime of a web request, for example, can be measured in milliseconds. It is now possible, technically anyway, for operating systems to boot, service the request and disappear. There needs to be pricing models that reflect computing models like this.
Earlier quoted context omitted.
Wow thanks for sharing this link. Didn't know about this. One thing I noticed though is the pricing seems a bit biased; for example for AWS it recommends an m1.small with 1GB Ram and 20GB of Storage at $35 a month ... However if you used a t2.micro that would give you the same specs for $10.79
Not quite the same, you don't own the whole core on the t2 and will get cpu throttled.
Odd site.
Earlier quoted context omitted.
I think the useful comparison people are making is the difference between the previous per-hour billing and new per-second billing. Sure, if they can get some mileage comparing per-second to per-minute, great. At the end of the day isn't the increased granularity better?
I think "second vs. minute" might be into "distinction without a difference" territory. Sure, per-second will definitionally help at the margins, but I'm dubious about the amount of money it will actually save. That all being said, it can enable a bunch of interesting things (e.g. more interesting stuff with AWS Lambda), and I look forward to see what per-second billing becomes an enabling technology for .
The important and very real distinction is the change from per-hour to per-second. If you're going to make it more granular (which from per-hour is a good thing), why would AWS stop at per-minute if it's the same or only marginally more difficult to make it per-second, particularly when they have the added benefit of being more granular that GCP? In other words, I don't see the reduction as primarily a marketing move on AWS's part. I'm sure they felt pressure to make it more granular. Stopping at parity doesn't necessarily make sense, nor should they be called out for doing more purely for marketing reasons.
Earlier quoted context omitted.
Which is why reserved instances exist.
The reserved instance pricing model is really poorly implemented. You have to commit to an instance class and a region, and if you need to change you can, but there is some secondary market. When compared to a sustained use model, it is a disaster. Managing all that in a large org is a real pain in the ass.
That's sure nice, but I'm waiting for AWS to switch to automatic sustained use discounts [0] like GCP offers. [0]: https://cloud.google.com/compute/docs/sustained-use-discount...
Earlier quoted context omitted.
I think the useful comparison people are making is the difference between the previous per-hour billing and new per-second billing. Sure, if they can get some mileage comparing per-second to per-minute, great. At the end of the day isn't the increased granularity better?
I think "second vs. minute" might be into "distinction without a difference" territory. Sure, per-second will definitionally help at the margins, but I'm dubious about the amount of money it will actually save. That all being said, it can enable a bunch of interesting things (e.g. more interesting stuff with AWS Lambda), and I look forward to see what per-second billing becomes an enabling technology for .
Earlier quoted context omitted.
I'd be surprised if it'd be that much additional work, if the local SSD options are NVMe -- which is also PCI-e like GPU's.
Wait what, would they expose the raw SSD pci device to your vm? What's stopping you from scraping all the leftover data from the previous customer?