Show HN: EC2 prices per GB of memory(instaguide.io)
instaguide.io
Show HN: EC2 prices per GB of memory
https://instaguide.io/#priceCalc=ram&period=mo
51 comments
Google Cloud maybe is superior in the pricing of compute, but it is actually more expensive on network egress traffic, object storage and block storage.
I recently created a simple tool (http://theprice.cloud/) to compare egress traffic, object storage, and block storage cost among AWS, Google Cloud and Azure. It seems like Googel Cloud is the most expensive one in egress traffic and object storage.
I recently created a simple tool (http://theprice.cloud/) to compare egress traffic, object storage, and block storage cost among AWS, Google Cloud and Azure. It seems like Googel Cloud is the most expensive one in egress traffic and object storage.
Except that Google Cloud cross zone and cross region (US) prices are much less than AWS.
Ingress Free
Egress inner-zone Free
Egress cross-zone in the same region $0.01
Egress cross-region within the US $0.01
They seem pretty comparable to me? Cross-region is $0.02, inner-zone is free, and cross-zone is free or $0.01.
https://aws.amazon.com/ec2/pricing/on-demand/
https://aws.amazon.com/ec2/pricing/on-demand/
I could have sworn AWS prices cross-zone used to be higher maybe this changed recently. Or... I was just wrong. :-)
Don't feel bad, I'd forgotten this one: "Using a public or Elastic IPv4 address => $0.01 per GB". I'm sad we still don't have a proper split horizon DNS to encourage internal IP usage, but I can't imagine charging for it in the same zone.
TL;DR: Starting at - $3.69/GB/mo (US), US$4.11/GB/mo (Ireland),
assuming reserved instances with 1yr All Upfront pricing, not counting the really huge xlarge+SSD instances.
assuming reserved instances with 1yr All Upfront pricing, not counting the really huge xlarge+SSD instances.
Which is its own form of complexity.
All these cloud offerings are priced so complex you can pretty much expect some nasty gotcha unless you spend an inordinate amount of time modeling your workload and traffic patterns.
And if something changes you can do it all over again.
All these cloud offerings are priced so complex you can pretty much expect some nasty gotcha unless you spend an inordinate amount of time modeling your workload and traffic patterns.
And if something changes you can do it all over again.
Our egress pricing (from all sources) is certainly higher because we operate a private backbone rather than just dumping your packets straight onto the internet.
Your site seems to be hugged to death (so I can't see it), but there are lots of gotchas with S3 pricing (like rounding up file sizes with Infrequent Access and Glacier) that in our experience means our customers come out ahead. Glacier and Coldline also aren't really comparable in the sense that GCS always responds within milliseconds. We only economics to discourage frequent access from Coldline, not delays. As above, our egress is more expensive because it's better (we hear you though if your response is "I don't care! Give me cheaper instead, then!").
Disclosure: I work on Google Cloud.
Your site seems to be hugged to death (so I can't see it), but there are lots of gotchas with S3 pricing (like rounding up file sizes with Infrequent Access and Glacier) that in our experience means our customers come out ahead. Glacier and Coldline also aren't really comparable in the sense that GCS always responds within milliseconds. We only economics to discourage frequent access from Coldline, not delays. As above, our egress is more expensive because it's better (we hear you though if your response is "I don't care! Give me cheaper instead, then!").
Disclosure: I work on Google Cloud.
Yes, I totally agree S3 pricing can be complicated with IA, Glacier, RRS, etc.
And it also gets complicated when comparing network egress, when region to region and egress to different parts of the world are taken into consideration. And GCP is actually more complex in the sense because it charges different prices for different egress destinations and AWS in comparison is one price for all of the world.
The most challenging part of making this tool is instead of displaying tons of options and dropdowns, I try to simply enough so that people get a general idea of the cost comparison of three major cloud providers, but not too simple to distort the reality.
And WOW, this is my first time getting "slashdotted". Very surprised to see the enthusiasm. The original "Show HN" is here https://news.ycombinator.com/item?id=14582181, and you are welcomed to continue the discussion there
And it also gets complicated when comparing network egress, when region to region and egress to different parts of the world are taken into consideration. And GCP is actually more complex in the sense because it charges different prices for different egress destinations and AWS in comparison is one price for all of the world.
The most challenging part of making this tool is instead of displaying tons of options and dropdowns, I try to simply enough so that people get a general idea of the cost comparison of three major cloud providers, but not too simple to distort the reality.
And WOW, this is my first time getting "slashdotted". Very surprised to see the enthusiasm. The original "Show HN" is here https://news.ycombinator.com/item?id=14582181, and you are welcomed to continue the discussion there
AWS also has their own backbone. Starting at about 7 min: https://www.youtube.com/watch?v=bqPfQgatMko
Google's backbone is a little bit different. Google Cloud shares this backbone with Youtube, Maps, and the rest. Not only are there DC-to-DC cables, our backbone extends to a vast number of Edge POPS (more than AWS and Azure combined), detailed at [0]. Our DC-to-DC network is pretty great too, allowing things like Spanner to exist (minimizing P in CAP etc) at [1].
Here's what it means for you in practice:
- Google's Load Balancer supports a single global anycast endpoint.
- When your packet tries to hit Google network, it hits the nearest POP, which acts as an on-ramp to the network and traverses only Google network, not touching public.
- Similarly, when data is en route to a customer, Google network will take it all the way to the nearest DC or POP on its private backbone.
- Google by default gives you a global software-defined VPC. No need to create VPN tunnels between zones/regions/etc.
(work at G)
[0] https://peering.google.com/#/infrastructure
[1] https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...
Here's what it means for you in practice:
- Google's Load Balancer supports a single global anycast endpoint.
- When your packet tries to hit Google network, it hits the nearest POP, which acts as an on-ramp to the network and traverses only Google network, not touching public.
- Similarly, when data is en route to a customer, Google network will take it all the way to the nearest DC or POP on its private backbone.
- Google by default gives you a global software-defined VPC. No need to create VPN tunnels between zones/regions/etc.
(work at G)
[0] https://peering.google.com/#/infrastructure
[1] https://cloudplatform.googleblog.com/2017/02/inside-Cloud-Sp...
I work at AWS and I think there's definitely some similarities and differences. We do share our backbone with CloudFront, and hence our video traffic, of which there's quite a lot these days. We also advertise our network ranges broadly, it's our mission to carry the traffic as much as possible ourselves. So those aspects are very similar.
But a genuine difference is that we don't try to operate a global "seamless" network. The reason is that we optimize for the "A" in CAP. Our experience is that at the low-ish level of a network, it can be too easy for outages and availability issues to spread quickly. For example, with global networking then a misconfiguration or error can more easily propagate globally and bring everything down.
Instead, we have autonomous uncoupled regions and it's one of our core principles that faults and errors stay within these regions (or better yet, availability zones). That does mean that partitions can happen, but find that most customers use active-standby configurations (where it makes no real difference) for key data, and we also build the tools that work with partitionable networks at a higher level. For example Route 53 supports multi-region routing and failover, and does it measurably better than simple anycast routing can achieve.
Over time, we're offering more and more multi-region services, such as cross-region replication for data, but the coordination is done at higher levels where we can achieve higher levels of availability in simpler ways, built on top of a more solid foundation.
But a genuine difference is that we don't try to operate a global "seamless" network. The reason is that we optimize for the "A" in CAP. Our experience is that at the low-ish level of a network, it can be too easy for outages and availability issues to spread quickly. For example, with global networking then a misconfiguration or error can more easily propagate globally and bring everything down.
Instead, we have autonomous uncoupled regions and it's one of our core principles that faults and errors stay within these regions (or better yet, availability zones). That does mean that partitions can happen, but find that most customers use active-standby configurations (where it makes no real difference) for key data, and we also build the tools that work with partitionable networks at a higher level. For example Route 53 supports multi-region routing and failover, and does it measurably better than simple anycast routing can achieve.
Over time, we're offering more and more multi-region services, such as cross-region replication for data, but the coordination is done at higher levels where we can achieve higher levels of availability in simpler ways, built on top of a more solid foundation.
Yeah, at least one outage in the last year for us included the paraphrased "anycast is hard". There's definitely an advantage to limited-blast-radius services, but I wouldn't trade GCS's multiregional buckets for S3 CRR (the same applies to Datastore, etc.). We have strict reliability requirements for global services; our perspective is that some customers want regional control for regulatory reasons, and we're happy to meet those requirements. But composing a global or even multi-regional service on an untrusted, lossy network is "crazy".
Again, Disclosure: I work on Google Cloud (and this network existed when I got here!)
Again, Disclosure: I work on Google Cloud (and this network existed when I got here!)
>For example, with global networking then a misconfiguration or error can more easily propagate globally and bring everything down.
This sounds like Nassim Taleb's antifragile meme [1].
If I was running IT for some large enterprise (which I'm not!) then I might replicate services on both AWS and Google Cloud. A bit like Apple try to have more than one supplier for their hardware components.
[1] https://en.wikipedia.org/wiki/Antifragile
This sounds like Nassim Taleb's antifragile meme [1].
If I was running IT for some large enterprise (which I'm not!) then I might replicate services on both AWS and Google Cloud. A bit like Apple try to have more than one supplier for their hardware components.
[1] https://en.wikipedia.org/wiki/Antifragile
You don't always need to have enterprise $$$ to take an antifragile approach though.
I'm mirroring my private Git repositories between Gitlab.com and Bitbucket, which can be done for $0.
I might even end up paying for the bottom end Github.com ($7 per month) and Gitlab ($4 per month) accounts and have three way redundancy.
I'm mirroring my private Git repositories between Gitlab.com and Bitbucket, which can be done for $0.
I might even end up paying for the bottom end Github.com ($7 per month) and Gitlab ($4 per month) accounts and have three way redundancy.
Just in case you can forward this on... AWS EC2 eu-west-2 (London) to GCP Network Loader Balancer is about 12ms round trip for some reason. Most other anycast services located in London are 0.5-2ms round trip.
Just something I noticed recently. :)
Just something I noticed recently. :)
During/After the dot com crash Google purchased a lot of backbone fiber at dirt cheap prices.
The DC-to-DC interconnects google has are extremely robust.
The DC-to-DC interconnects google has are extremely robust.
Though Glacier is hooked to S3 (for obvious reasons) I don't think it's relevant to a discussion of bandwidth egress costs. If you're frequently pulling things out of Glacier then you're using it wrong.
I agree! Most conversations that somehow talk about GCS being more expensive usually are "oh actually, AWS just charges less for egress" (which isn't a non sequitur but is effectively orthogonal). Again, I'd respond directly if the site weren't hugged to death :).
WOW, this is my first time getting "slashdotted". Very surprised to see the enthusiasm. The original "Show HN" is here https://news.ycombinator.com/item?id=14582181, and you are welcomed to continue the discussion there
Lol I'm new, what's getting "slash dotted?"
> When an internet server or item is shut down, canceled, closed or crashes because of the instant popularity from a community.
But if you're wondering what the word comes from, slashdot.org
But if you're wondering what the word comes from, slashdot.org
Came here to post this -- moving our infra from AWS to GCP was the best decision I've ever made.
One thing I would like to add is also the fact that they give you tips on under utilized instances and how much you can save per month. They really go the extra mile to make sure you are paying for what you are truly using and not paying for idling hardware.
I agree. While I think AWS is great, and I will happily use it if that is what my customers want, I think that GCP wins on price.
Having Diane Green in charge of GCP is an indication that developing GCP as a business is a high priority.
Having Diane Green in charge of GCP is an indication that developing GCP as a business is a high priority.
I've built this page since I often just want to pick a spot instance type that gives me biggest bang for the buck. Amazon's own pricing page is still very confusing, and ec2instances.info is great but it is a static website and adding spot prices there is nontrivial.
I've also fixed a few minor things that annoyed me, such as correct sorting by instance type (so that r3.16x goes after r3.4x) and added a mode to display spot savings vs on-demand.
Would appreciate any feedback!
I've also fixed a few minor things that annoyed me, such as correct sorting by instance type (so that r3.16x goes after r3.4x) and added a mode to display spot savings vs on-demand.
Would appreciate any feedback!
This is very useful for me too. Thanks for putting it together!
For me, it would also be nice to see the total price/time unit on the same table as the price/gb.
For me, it would also be nice to see the total price/time unit on the same table as the price/gb.
Best bang for buck is not at amazon.
Right. So the Show HN page says you can barely go below $5 per gigabyte with on-demand pricing. OVH RAM instances consistently cost 1.33 $/GB for a machine with 30, 60, 120 or 240GB of RAM.
If all you need is compute and RAM, then OVH dedicated machines are a great choice; I used them for a long time myself and would again for personal stuff. That said, it's important to remember that focusing on that to the exclusion of turn-key services (RDS has saved clients of mine tens of thousands of dollars in billable hours just by itself) doesn't do you so well once you need more than that.
OVH have a beta RDS-like service. https://www.runabove.com/index.xml
When they have RDS and Redshift and and Athena and SQS and SNS and when they have a fully-functional API that crosses every platform I need to write code against and years of a proven track record of stone-cold simplicity and success, I am sure I will take that into account.
Time is valuable. AWS/GCE/Azure have a huge head start in making us more productive.
Time is valuable. AWS/GCE/Azure have a huge head start in making us more productive.
I havent looked at OVH lately, but are they really a cloud? Do they provide full VPC with central firewall? Dynamic network disk storage that can be mapped to servers?
OVH does have their vRack stuff these days, but it's iffy and clearly intended for dedicated hardware. They have no block storage that I'm aware of.
They do have it: https://www.ovh.com/ca/en/public-cloud/storage/additional-di...
It's OpenStack Cinder.
They also have object storage, Swift: https://www.ovh.com/ca/en/public-cloud/storage/object-storag...
It's OpenStack Cinder.
They also have object storage, Swift: https://www.ovh.com/ca/en/public-cloud/storage/object-storag...
TIL, thanks! Didn't realize OVH was OpenStack--that's a pretty hard no for me, because I've witnessed firsthand the failure conditions there, but I appreciate the correction.
How does EBS work, anyway? Is it some form of NFS with caching under the hood?
It's not NFS, it's a block storage mechanism. NFS presents a file-based interface, EBS is a block/device-based interface. The underlying implementation isn't widely publicized, but if you think about how a block device works on a Unix and the AWS bigger-is-faster model for non-PIOPS EBS, you can probably draw some reasonable inferences.
EBS is some kind of Network Block Device. NFS is another product, https://aws.amazon.com/efs/
IIRC EBS is based on GNBD.
Such rumors have been around for quite a while -- Amazon is not talking -- but their relevant patent https://www.google.com/patents/US8769186 has
> For example, in at least some embodiments, a representative logical local block data storage device may be made available to an executing program via use of GNBD (“Global Network Block Device”) technology.
> For example, in at least some embodiments, a representative logical local block data storage device may be made available to an executing program via use of GNBD (“Global Network Block Device”) technology.
There's also http://ec2instances.info which has RDS pricing as well.
Forgive me for a dumb question from someone who doesn't do cloud computing currently : the units are really $/GB/time period, yes? What is the time period? One hour? day? month?
AWS bills instances hourly; both Azure and Google Cloud bill by the minute (albeit with a minimum of 10 minutes). For data analytics that you want fast turn around time for, this ends up being a big deal: a 30 minute job is literally 2x less expensive than "round up to an hour". This also shows up in auto scaling of services, since a standard business day of traffic obviously only has a fairly short actual peak combined with what is ultimately fairly short term load.
Disclosure: I work on Google Cloud.
Disclosure: I work on Google Cloud.
There's a selector on the toolbar, top right, that let's you choose the time period.
Would be nice to see $/GB at the same time as absolute $
AWS on the other hand... A labyrinth of pricing tables, spot instances, EBS optimized, enhanced networking... Complexity.
[1] - https://cloud.google.com/compute/docs/sustained-use-discount...
[2] - https://cloud.google.com/compute/docs/instances/signing-up-c...
[3] - https://cloudplatform.googleblog.com/2017/05/Compute-Engine-...