TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Cloud pricing comparison: AWS vs. Azure vs. Google Cloud in 2021

31 点作者 BlackPlot超过 3 年前

12 条评论

gunapologist99超过 3 年前
&gt; Compute is what makes your cloud bill so high.<p>This is simply flat-out not true for 90% of non-AI workloads, both on the startup and enterprise side, and this makes me question the entire article.<p>With compute, you generally have a lot of wiggle room and levers you can pull to optimize your pricing. Even with storage, you can do things like bulk loading, caching, etc to reduce transaction counts.<p>But, with traffic (not just including egress, but also inter-VPC&#x2F;region traffic)? You&#x27;re just kinda stuck! or at least until better dramatically compression comes along which doesn&#x27;t spike things on the compute&#x2F;memory side of things.<p>In general, compared to other hosting providers, these three (AWS, Azure, GCP) have insanely expensive traffic costs -- <i>an order of magnitude higher than their smaller competition</i>! To make matters worse, egress negotiations are taken off the table before you even get started when discussing enterprise discounts.<p>Be careful when getting started using Activate etc startup funds... that money disappears insanely fast.
cbushko超过 3 年前
Their pricing for GCP is way off. If you were looking for an instance with 32 GiB of RAM, you do not have to buy one with 40 CPU. There are other options such as:<p>&gt; n2-highmem-4 4 32GB $0.262028<p>Which turns out to be the cheapest price and that is not even preemptible which is $0.06356
评论 #28317037 未加载
评论 #28317142 未加载
评论 #28317090 未加载
评论 #28317314 未加载
cbushko超过 3 年前
The only datapoint I can give is that moving from AWS to GCP reduced our bill by 2&#x2F;3rds. That isn&#x27;t a 1 to 1 comparison though as we did a re-platforming at the same time.<p>Moving from AWS ECS to GCP Kubernetes was probably the biggest money saver. It reduced the amount of compute needed by a huge amount. Being able to safely use pre-emptive VMs in Kubernetes is also leads to huge savings.<p>I am sure that if we used Kubernetes in AWS it would have had a similar cost reduction.
评论 #28317403 未加载
评论 #28317087 未加载
maxdo超过 3 年前
the article is incorrect for memory, google cloud allows you to create custom configurations. e.g. 1 cpu and 100 gb of memory. That itself allows us to cut the cost 10% just because predefined instances doesn&#x27;t match our memory and cpu footprint.
theevilsharpie超过 3 年前
A snippet from the blog post:<p>&gt; This chart shows CPU operation in AWS (t2.2xlarge with 8 virtual cores) at different times after several idle CPU periods. Would you expect such unpredictable CPU behavior within a single cloud provider?<p>&gt; [image showing extremely bursty CPU performance]<p>In AWS EC2, the T-series are burstable instances types that have a low base performance, and use a credit system to offer bursts above that baseline. In exchange for this credit limit, T-series instances are less expensive than instances with consistent CPU performance.<p>They are marketed for use cases where applications often sit idle, and work well in that case. Pointing out erratic performance in a benchmark as a problem (a problem with all of EC2, at that!) is incorrect -- the machine is working exactly as its advertised to work.<p>See here for more info: <a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;AWSEC2&#x2F;latest&#x2F;UserGuide&#x2F;burstable-performance-instances.html" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;AWSEC2&#x2F;latest&#x2F;UserGuide&#x2F;burstabl...</a><p>Edit: I see later on in the article they talk about burstable instances and their performance impact (so why make such a novice mistake!?). However, Google Cloud&#x27;s E2 instance series is price-competitive with AWS&#x27;s burstable T-series, and doesn&#x27;t have complexities and pitfalls associated with bursting. That wasn&#x27;t mentioned, despite this article literally being a comparison between what the platforms have to offer in terms of compute.
stornetn超过 3 年前
The title for this feels really broad.<p>Cloud providers offer so many products with so many nuances that I&#x27;d posit it&#x27;s practically impossible to do a satisfying pricing comparison that&#x27;s even halfway comprehensive. That&#x27;s not the fault of the author, certainly, but the title makes it come off as something far more comprehensive than it actually is, and as a result comes across as disingenuous.
theevilsharpie超过 3 年前
FYI to the blog author, the image showing the machine CPU and RAM configuration incorrectly uses Azure&#x27;s names for the Google Cloud VMs.
评论 #28316929 未加载
starfallg超过 3 年前
&gt;Let’s take a look at the biggest cost driver: compute &gt;Compute is what makes your cloud bill so high. This isn’t to say that other services don’t contribute to it at all. Storage can get quite expensive and moving data around might result in high egress costs.<p>I don&#x27;t know what to say here. Compute is probably costly for cast.ai because they use a lot of it, but for many applications storage and egress is as much if not more than compute. It&#x27;s all down to the application.<p>Compute is also the easiest to optimize in terms of cost, and egress the hardest.
评论 #28317488 未加载
whoevercares超过 3 年前
We probably should do a comparison of the customer service between them as well. The AWS support, TAM and engineering team almost provide white glove experience for troubleshooting, feature request etc. (might be biased for since we spend big)<p>It’s interesting to compare The retailer vs technology DNA on this front
评论 #28317152 未加载
carterschonwald超过 3 年前
The tables in the article won’t resize for mobile device browsers. Or at least on safari ios
jonatron超过 3 年前
Anyone else looked found relatively reasonable instance pricing on cloud, but then calculated the bandwidth would bankrupt the company?
908B64B197超过 3 年前
Is GCP even profitable? How long until it joins the 5 previous chat apps in the Google Graveyard?<p><a href="https:&#x2F;&#x2F;killedbygoogle.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;killedbygoogle.com&#x2F;</a>