Speaking of Amazon, here's a fresh post from an engineer who just quit
nekrolm.github.io
nekrolm.github.io
I developed a monstrous stress cough, which sometimes made me double over and vomit.
October 17, 2025, was my last day at Amazon Web Services.
I quit, turning down an amazing opportunity to earn at least another ~£100k in Amazon RSUs if I lasted another year.
Some will say: it's long overdue. Others: how can that be?! Just a year, and then they'll promote me and it'll be great, right? And it's FAANG! You could, for example, transfer instead of quitting. After all, Amazon is big!
Amazon is very big. And indeed, stories about inhumane conditions can be 100% true in one part of it and a complete myth in another. I can only speak specifically about AWS, and with the utmost certainty about CloudFront. But there are some characteristics that apply to all of Amazon.
There are many reasons why I decided to leave AWS:
Compensation compared to the market 5-day return to office Endless approvals Desperate attempts to do something well Cancer calls Disappointment with projects Stress And this last reason was decisive.
High success brings high blood pressure Amazon is famous for its Leadership Principles. 16 commandments to follow and incorporate into daily conversations at Amazon on any topic to be successful at the company. It's funny, but when I started working there in 2022, there were 14 commandments. Now there are 16. But that's not the point.
One of the principles is "Success and Scale Bring Broad Responsibility." And here it is, just as a heading, not as an official explanation, but it's perfect for explaining.
I've always considered myself quite resilient to stress. And I thought that, overall, nothing particularly stressful was happening in my work. At least not on a regular basis.
However, being subjected to regular, almost daily twitching in all directions (as they like to say here: receiving shouldertaps), the human nervous system can at some point give way:
During my three years at AWS, I developed a monstrous stress cough, which sometimes made me double over and vomit. For a long time, I couldn't understand the cause of this cough—I went to doctors, spending my entire annual insurance allowance on them. Doctors and tests ruled out respiratory and gastroenterological causes, leaving me with only one—stress. I took a closer look at how my cough correlated with my daily activities. And I noticed that
I hardly cough on weekends I hardly cough on vacation The worst time I felt was after rallies And also when I left the house on my way to the office So what went wrong?
A Generalist Impostor In this section, I'll allow myself to insert those very same Leadership Principles, ironically and like a puzzle. To somehow convey the characteristics of a corporate email
CloudFront is a CDN, a content delivery network, or, simply put, a large distributed cache for your cat photos. And a very successful one. Something like 30% of all internet traffic goes through CloudFront in one way or another. Pretty cool, huh?
In practice, this means that with any change, you have a chance of crashing 30% of the internet. Banks won't be able to show you very important stories. Media services won't show you your neural network feed. Your precious JavaScript for drawing snowflakes in the website's New Year's theme won't load. There's a lot more to it.
Of course, this should never happen. Therefore, there must be well-established processes for review, testing, and gradual rollout of changes, and, most importantly, emergency rollouts. Automatic rollouts are highly desirable.
CloudFront has such processes. But they have some interesting peculiarities. I won't go into detail, but the following describes them very well:
When estimating the cost of a feature, a manager might say, "let's keep rollout aside." Not because everything is so well-established and you can forget about it. But because this rollout will take an indefinite amount of time, from a month to a year or more, and during this entire time, you'll be shaking and praying that, God forbid, something doesn't go wrong and you won't have to rollback, lest you upset our dear users. Customer Obsession is paramount. And some users are so sensitive that they can get upset if they fail to process one request out of a million in a day.
If something goes wrong, writing a correction-of-errors document is not the most pleasant thing at all, as it then has to be demonstrated to a very wide audience of principals and senior managers at L7, L8, and above (the average developer at Amazon is L4 or L5).
Few people need that. Therefore, as they say, we must Think Big and Insist on Highest Standards. So, before every feature, you need to write a document. Even if you don't yet fully understand whether the feature is feasible or how to implement it. Implementation details are a Two-Way Door Decision, so it's not really important.
The document will be reviewed. And it will be reviewed right at the meeting where the document is discussed. After all, few people know about it beforehand.