In August 2025, I wrote about AWS deleting my 10-year account without warning. Then I wrote about the one human who restored it. Tarus Balog, a 20-year open-source veteran who escalated my case to a Severity 2 ticket, got the CEO’s attention, and proved that even inside a machine the size of AWS, one person could still make a difference.
AWS just fired him.
This is the finale of a trilogy nobody asked for.
On May 23rd, Tarus published “Amazon Web Services - Four Years and Out”. Four years on the Open Source Strategy and Marketing team. Fired. And the part that gutted me:
His proudest accomplishment at AWS? Restoring my account.
Not a product launch. Not a keynote. Not a revenue metric. The thing he was most proud of in four years at one of the biggest companies on the planet was helping one developer in Morocco get his data back.
And senior leadership’s reaction? Indifference. The rank-and-file were inspired. They told him it renewed their faith in the company. Management couldn’t have cared less.
Let me connect the dots:
The man who triggered a CEO-level investigation into AWS’s own dysfunction? Gone within ten months.
I’m not saying there’s a direct line from saving my account to getting fired. I’m saying the system didn’t reward him for it. It didn’t even acknowledge it. And eventually, the system did what systems do. It optimized him away.
Tarus wrote something that crystallizes everything wrong with big tech right now:
“There is this push to use AI to create content which will ultimately be consumed by AI, and we’ve lost the human being in the process.”
He watched colleagues brag about using a single prompt to generate entire conference presentations. He watched the company pivot so hard toward GenAI that basic services like S3, EC2, and RDS, the actual backbone of the internet, became afterthoughts at re:Invent.
Remember what Tarus did for me? He read a blog post. He felt something. He picked up the phone. He escalated beyond what his role required. He was human about it.
That’s not a skill you can automate. It’s also, apparently, not a skill AWS values enough to keep around.
For years, I actually liked AWS. The chaos was the charm. 47 services that do the same thing, each billed separately. It was a playground for people who thrived on complexity.
But in 2024, most of my friends at AWS were let go. When my data was deleted in late July 2025, I started reaching out to them one by one, hoping someone still inside could help.
All gone.
Some switched to farming. Others opened coffee shops. One bakes bread now. That’s the level of abyss we’re talking about. These are people who know they can’t do anything online anymore. Not because they lack the skills. Because their brains were so filled and indoctrinated with complexity that they found decorating a cookie more fulfilling than maintaining 87 files of Kubernetes manifests plus CloudFormation templates plus Terraform state plus whatever abstraction layer Amazon invented that quarter.
When the people who built and operated your cloud would rather knead dough than touch a terminal again, that’s not a career pivot. That’s a trauma response.
Tarus isn’t the first person AWS broke. He’s just the first one who wrote about it on his way out. The rest are scattered across small towns, running businesses that don’t require an IAM policy to open the front door.
Tarus was hired specifically to improve AWS’s standing in open-source communities. His boss called him “non-fungible” during recruitment. Ironic, given Amazon’s philosophy that almost all employees are replaceable commodities. Like EC2 instances. Except EC2 instances keep billing you when the shutdown crashes, unless you contact Support. But Support is AI now. The worst type of AI.
Here’s the thing about open-source credibility: you can’t buy it, you can’t fake it, and you definitely can’t maintain it by firing the people who earned it.
AWS still sponsors conferences. Still runs its open-source credits program, the same one Tarus pointed me toward after saving my account. But the person who embodied what that program was supposed to represent? Fired.
When Tarus questioned how open source survives in a world where state-of-the-art AI models are locked behind vendor APIs, he wasn’t being philosophical. He was describing the exact contradiction that made his own job impossible.
When AWS deleted my account in July 2025, they insisted it was a billing issue. A payer problem. Human error on my end. Nothing to do with automation, nothing to do with AI. Just a mundane administrative mix-up.
Five months later, in December 2025, AWS’s own AI coding agent Kiro autonomously decided to delete and recreate an entire production environment. A 13-hour outage. The AI inherited an engineer’s elevated permissions and bypassed the two-person approval process. It looked at the problem and concluded the optimal solution was to destroy everything and start over.
Sound familiar?
Amazon’s official response? “This brief event was the result of user error, specifically misconfigured access controls, not AI.” And my favorite line: “It was a coincidence that AI tools were involved.”
A coincidence. Like how it was a coincidence that my account got nuked during what an insider described as a proof-of-concept on dormant accounts.
Then in March 2026, AI-assisted code changes caused Amazon to lose 6.3 million orders in a single day. A 99% drop in US order volume for six hours. Amazon responded with a 90-day safety reset across 335 critical systems, mandating dual approvals for AI-assisted deployments.
So let me get this straight:
Three incidents. Three times they said it wasn’t AI. Then a 90-day safety reset for the thing that definitely wasn’t the problem.
When my account was deleted, the insider theory was a -dry vs --dry flag on a Java tool. Maybe it was. Maybe it wasn’t. But the pattern is clear now: AWS has been fighting fires caused by automated systems while insisting to customers that everything is fine, that the smoke is a coincidence, that the matches just happened to be there.
They told me my data deletion was a billing problem. Then their own AI deleted their own infrastructure. Three times.
This is the tokenmaxxing pipeline in action. Generate code nobody reads, nobody reviews. If the build is green, ship. Burn tokens, push to prod, blame humans when it breaks. The AI writes the code, the AI reviews the code, and when the AI deletes production, it was “a coincidence that AI tools were involved.”
At least when a human types --dry instead of -dry, there’s someone to fire. When Kiro decides to nuke an environment, you get a blog post about misconfigured access controls and a promise that no customers complained.
In my second article, I wrote about the formal “Correction of Error” process AWS launched after my incident. The goal: ensure no one else goes through what I went through.
Let’s check the scorecard:
The CoE process was supposed to be about fixing systems. Instead, the system fixed itself by removing the person who exposed the problem.
I want to quote what he said, because it matters:
“All I did was manage to poke the right bear and the support team did the rest of the work (and they were amazing).”
That’s Tarus being humble. Here’s what actually happened: he took a stranger’s blog post, recognized it as a systemic failure, escalated it past every bureaucratic barrier AWS could throw up, and got a CEO involved. The support team was amazing because Tarus forced the issue. Without him, I’d still be getting 5-star review requests from no-reply@amazon.com.
And now AWS has lost him. Not to a competitor. Not to retirement. They actively chose to remove someone whose instinct was to fix things when they broke.
Tarus gained 30 pounds at AWS. His blood pressure climbed. He couldn’t sleep. He called getting fired “actually a relief.”
I know that weight. After my account was deleted, I nearly yanked every gem I maintain from RubyGems. Nearly deleted everything. The only thing that stopped me was knowing it would hurt developers who depend on my work, not AWS.
Tarus carried similar weight. Watching the company he joined to improve slowly abandon everything he believed in. Watching talented colleagues get laid off. Watching “customer obsession” become a slide in a GenAI presentation instead of something anyone actually practiced.
When I wrote that AWS needed more people like Tarus, I meant it as a recommendation. I didn’t expect them to take it as a hit list.
In my second article, I promised Tarus a meal in Morocco. Mint tea, tagine, and a long conversation about keeping humanity in technology.
That offer doesn’t expire, Tarus. It never had an AWS logo on it.
You’re free now. You said you want to go back to open source. The community that you spent 20 years building before AWS is still there. It still knows your name. And unlike AWS, it doesn’t fire people for giving a damn.
Let me be real about what this three-part series documents:
Part 1: A cloud provider deletes a decade of work because of a broken verification process and a Java parameter parsing quirk. Support gaslights the customer for 20 days.
Part 2: One human inside the machine fights the bureaucracy, escalates to the CEO, and restores the account. Hope restored. Faith in humanity renewed.
Part 3: That human gets fired. The systemic issues remain unfixed. The machine continues.
This is the arc of modern tech. The system breaks. A human fixes it despite the system. The system removes the human. Repeat.
In Part 2, I wrote: “My trust isn’t fully restored. What is restored is my faith that even in massive corporations, one person can make a difference.”
I still believe that. But I’ll add a corollary: the difference that person makes is often inversely proportional to how long the corporation keeps them around.
The people who challenge broken systems, who go off-script, who escalate when the template says “close the ticket”. Those people are threats to institutional inertia. They’re expensive. They’re inconvenient. They make leadership answer uncomfortable questions.
And eventually, they get optimized away. Just like a “low-activity” AWS account.
You don’t need me to tell you this, but I will anyway: Tarus Balog was worth more to your reputation than any GenAI keynote. Every developer who read my story and thought “maybe AWS isn’t so bad after all”? That was because of him. Not your PR team. Not your marketing budget. One human being who decided to do the right thing.
You’ll replace him with someone who hits KPIs and doesn’t ask uncomfortable questions. And you’ll wonder why developers keep building exit strategies from your platform.
The cloud isn’t your friend. I said that in Part 1. But sometimes there are friends inside the cloud. The tragedy is what happens to them.
To Tarus: Welcome back to the other side. The open-source world didn’t forget you while you were inside the machine. The mint tea is ready when you are.
To AWS: You had a human circuit breaker. You removed it. Good luck with the next cascade failure.
To everyone else: Keep your backups distributed. Keep your exit strategies current. And if you find a Tarus inside your cloud provider, thank them before the system optimizes them away.
Captain’s Log, Stardate 2026.146 - End Transmission
Captain Seuros, RMNS Atlas Monkey Ruby Engineering Division, Moroccan Royal Naval Service “Per aspera ad astra. But the machine keeps eating its own stars.”
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。