Corey Quinn writes a newsletter and blog on AWS and cloud costs, mixing sarcasm with practical analysis of cloud services.
Commenters say it is both hilarious and useful, praise Quinn's humor, and note he runs a consultancy that lowers AWS bills.
> I really would love if folks talking about volatile AWS prices would actually give examples.
There was never any mention of "volatile" pricing. Egregious? Yes. Volatile? No. There's a significant difference of meaning with those words.
Here's a perfect example [0] by Corey Quinn.
> So inform us of the uncertainty with AWS.
I didn't mention "uncertainty with AWS". I mentioned that there is no more certainty with AWS than with any other major cloud provider with respect to your statement about public companies who "eventually succumb like every company before them to the realities of reporting growth". And then for some reason you pivoted to your own, personal, AWS bill from there. I'm not exactly following the logic.
> Cloudflare has secret pricing - that's the really annoying thing.
At this point I'm not sure if your comment is even serious. First of all, please elaborate on "secret pricing". Sounds like serious charges we should all be aware of. Maybe it's with the article from 2019 on The Register about domain pricing? That's not exactly in the context of this thread, but please enlighten the masses.
> Seriously, put a porn site up online with cloudflare and see how far "free" gets you.
I'd charge you with the same ask on AWS. You seem to imply the "free" tier, on AWS, will provide proper capabilities to host an adult content site. I have strong doubts about this. The logic of this argument is ill conceived at best. Or is your logic just that…
A funny story (well, funny because it didn't happen to me) was chronicled on a recent episode of Corey Quinn's "Whiteboard Confessions" -- https://www.lastweekinaws.com/podcast/aws-morning-brief/whiteboard-confessional-click-here-to-break-production/ -- where Slackbot's auto URL unfurling feature "clicked" an SNS alert unsubscribe link when a tech posted the a report including that link into a slack channel. If nobody lost their job over this triggering a SEV-1 alert I'm sure they had a laugh about it later.
Another issue with auto-unfurling links or generating previews of URLs is the potential for stalking. If I'm hunting my ex and I know their cell phone number AND that they have an iPhone I can simply send a link to a website and let iOS generate the preview... which then pings the URL of the website which I set up and I can now run geo-IP resolution and narrow down where my ex is (and maybe I follow up with a well-crafted PDF exploit when I'm ready to narrow down even more on an area).
While systemvoltage was a bit brusque in how the complaint was worded above, these "friendly and helpful" features of Slack, SMS, and other apps can have devastating unforeseen consequences. I question the value of having to opt out of these features instead of making them opt-in instead.
Since you work at Google, you should be well aware of the deprecations. You don't need evidence of their existence, you just don't see it as a problem. Which you are free to do, since it's not a problem for you, it's just a problem for GCP clients, many of whose complaints you seem to be dismissing as not being "data".
GCP doesn't seem to provide a full list of deprecations, but the list for just one service[1] is pretty terrifying when you consider that your app might depend on two or three dozen services, and a deprecation in just one of them forces you to rewrite perfectly good code. A cursory search reveals a number of reports of being repeatedly bitten by deprecations[2][3][4], so no one should be mislead by the dismissals here. [2] has a good cautionary tale of a forced "upgrade" leading to potentially much greater cost.
[1] https://cloud.google.com/appengine/docs/deprecations
[2] https://nilsnh.no/2019/11/09/managing-the-google-cloud-platform-on-deprecation-notices-and-pricing-policies/
[3] https://www.slideshare.net/async_io/lessons-learned-from-building-a-rest-api-on-google-app-engine
[4] https://www.lastweekinaws.com/podcast/aws-morning-brief/whiteboard-confessional-google-s-deprecation-policy/
Some down votes on this one, maybe from the Amazon crew, that it's a fact that by far they have the best Cloud and also:
- Amazon is consistently the top user of the H-1B visa program:
"Which companies secured the most H-1B visas in 2024?" - https://www.hindustantimes.com/world-news/us-news/which-companies-secured-the-most-h-1b-visas-in-2024-heres-a-list-101743134698060.html
- They pay below market rate so they can't have the same hiring power:
"AWS Compensation Explained" - https://www.lastweekinaws.com/blog/aws-compensation-explained/
"The AWS goal is to pay you roughly 50% to 65% of what “the market” will pay you, based upon a variety of sources plus some work with Excel."
- And everybody has seen their disaster execution on AI for the last four years.
"Amazon CEO Andy Jassy unleashed a meticulous 8-minute defense of AWS’ standing in the AI arms race amid investor stock freakout" - https://fortune.com/2025/07/31/amazon-aws-ai-andy-jassy-earnings-defense/
There's an episode of Screaming in the Cloud[0] that touches on this. They particularly call out Amazon for their comparatively low carbon-neutral benchmarks, but everyone seems to be a culprit in this. Seeing Amazon's record on green energy usage is particularly frustrating given that they just secured the naming rights to a new Seattle stadium and chose the moniker "Climate Pledge Arena". Not a great look, Jeff.
0: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/the-cloud-climate-change-with-paul-johnston/
1: https://www.forbes.com/sites/kensilverstein/2020/07/06/amazons-climate-pledge-arena-brings-the-climate-cause-down-to-earth/#696ed0d31ba5
Sure but I'm still wrapped around your library no? So if your "Process Kafka events" decorator in Python doesn't quite do what I need to, I'm forced to grab the Kafka library, write my code and then learn to build my own container since I assume you were handling the build part. Finally, figure out which 17 ways to run containers on AWS (https://www.lastweekinaws.com/blog/the-17-ways-to-run-containers-on-aws/) is proper for me and away I go?
That's my SRE recommendation of "These serverless are a trap, it's quick to get going but you can quickly get locked into a bad place."