- 今回の AWS US-EAST-1 リージョン障害 は、単なる技術的不具合ではなく、中核人材の流出 による組織的な弱体化の兆候だと分析されている
- 障害の原因は依然として古典的な DNS 問題 であり、DynamoDB API エンドポイントのエラー によって他のサービスが連鎖的に停止した
- 過去の システム障害パターンを記憶していたベテランエンジニアたちが退職 したことで、問題の特定と復旧の速度が著しく遅くなった状況が明らかになった
- Amazon 内部の 大規模な人員削減と高い「惜しまれる離職率（69〜81%）」 が複合的に作用し、AWS の運用安定性が揺らいでいる
- これは 技術の老朽化ではなく人の不在 による危機であり、AWS の「一度の事故」ではなく 継続的な信頼崩壊の前兆 と解釈される
DNS 障害とサービス停止
- 長年システム管理者の間で使われてきた "It's always DNS" という冗談のように、多くのサービス障害の中心には常に DNS 問題 がある
- 2025年10月20日 12:11AM(PDT)、US-EAST-1 リージョンで AWS サービスのエラー率が急増 したとの報告
- 1:26AM、DynamoDB エンドポイント へのリクエスト失敗が本格化
- 2:01AM、DynamoDB API エンドポイントの DNS Resolution エラー が原因と確認され、多数の依存サービスが 連鎖障害 に陥った
- DynamoDB は AWS インフラの基盤サービス であり、そのリージョンのサービスが崩れるとインターネット全体に影響が及ぶ
- 銀行、ゲーム、SNS、政府サービス、Amazon.com のショッピングなどで大規模な障害が発生
- 問題の認識から原因の究明まで 75分を要し、これは AWS の「模範的な復旧速度」という伝統から見ても異例に遅い対応だった
- 障害認知から原因特定までにかなり時間がかかったのは、透明性の欠如というより経験不足 に起因すると分析されている
- ステータスページにはこの間 「正常稼働中」 というメッセージだけが表示され、コミュニティの批判 を受けた
「予言」の実現: 退職者たちの警告
- 従来の AWS は、リージョン1つで障害が起きるだけでも大きな話題になるほど 高度なインフラ運用能力 を誇っていたが、複雑性が高く、過去と似た問題が繰り返される ほど現場経験の重要性は増す
- AWS の元エンジニア Justin Garrison は、2023年の退職時に「大規模イベント(LSE)が増えている」と警告した
- 彼は「2024年に重大障害が発生する」と予測しており、今回の事態はそれを裏付けた形だ
- AWS 内で 上級技術者たちの連続的な退職 が続き、
数十年かけて蓄積された tribal knowledge（内部経験にもとづく知識） も同時に失われた状況だ
- DNS 障害のように 単に技術的原因を知っている人よりも、
「このシステムが過去に似た問題を起こしたことがあったか」を記憶している人材が必要になる
- しかし、その記憶を持つ人たちは RTO（出社復帰方針）への反発と人員削減 によって会社を去った
人材流出の証拠
- 2022〜2025年の間に 27,000人以上の Amazon 従業員が削減 され、
部門別比率は非公開だが AWS も直接的な打撃を受けたとみられる
- 内部文書によれば 「惜しまれる離職率」が 69〜81% に達し、
これは「会社が引き留めたかった人材」が退職したことを意味する
- Return to Office（出社命令） による不満が爆発し、
熟練したベテランエンジニアたちが大量に退職した状況が多数報告されている
- 結果として AWS は 経験の浅い低コストのチーム へと再編され、
複雑なインフラを運用する能力が徐々に弱まっている
構造的問題: 「Frugality」の変質
- かつて Amazon の中核価値だった Frugality（倹約） は、
「少ない資源で効率を最大化する」 という哲学だった
- しかし最近では、「ほとんど資源がない状態ですべてをこなす」 という意味へと変質した
- 人員削減によって基本的なメンテナンスすら難しい水準に達している
- これは「技術が古いから」ではなく、「保守する人が新しいから」 生じた問題だ
今後の見通し
- 市場は今回の障害を単発のものとして受け止めるだろうが、問題の構造は続いている
- 経験ある人材が去り、システムの複雑性は増し、
「次の事故」 の可能性がますます高まる循環構造が形成されている
- AWS は今回の出来事を 「孤立した単一障害」 として発表する可能性が高いが、
内部の空白が蓄積すれば 類似の大規模障害が繰り返されるリスク は大きい
- 「chickens are coming home to roost」 という表現のように、
技術より人的資本の喪失こそが AWS 最大のリスク として浮上している
8件のコメント
人の住むところは、みんな同じですね..
どの市場でも通用する話ですね。
IT技術のノウハウは、熟練した溶接工のノウハウと同じように扱うべきなのだと思います。
少し前に読んだ文章の中で、
Amazonではシニアエンジニアレベル2からその次に進むのが本当に難しい、という話を思い出します。なんとなく。
ああいう残念な形での退職のようなことが、その層で特に多く起きているのではないかと思います。
逆に上の立場では、「あれだけ大量に切ったのに、これくらいで収拾がつくものなんだ……」と思うのかもしれませんね。
韓国では、エンジニアはある程度の段階まで行くとみんなマネージャーになってしまって途切れてしまうし...
アメリカでは、効率化という名目のもとでシニアをみんな切ってしまうのが問題だし...
本当に簡単ではないですね...
multi-az まではやっていましたが……リージョン単位の障害への備えもしておくべきなんでしょうか……
そのコストが損失コストより本当に大きいのかも考慮すべきだと思います。
Hacker Newsの意見
エンジニア社員と倉庫労働者の両方を見ていると、このまま社員を解雇し続ければ、かつてこの会社で働いていた人たちまで完全にいなくなる日も遠くない気がする。
何十万人ものH-1Bエンジニア候補者や何千万人もの不法移民の倉庫労働者がいたとしても、これほど大きな企業が急速に大量解雇を進めれば、結局は人的資源が尽きるしかない。
この状況を見ると、Robot Chickenのスター・ウォーズのパロディ回を思い出す。そこでは帝国軍の将校たちが、ダース・ベイダーにフォースチョークされるふりをして死んだように見せ、ライトセーバーで斬られないよう逃げ出し、その後で別の名前で戻ってくる。Amazonはそれ以上だ。誰も戻りたいと思わない。
https://www.youtube.com/watch?v=fFihTRIxCkg
正直に言って、まともに実力のあるエンジニアでAmazonに二度と戻りたがる人は見たことがない。
倉庫には本当にそんなに不法移民が多いのか？ Amazonは本人確認や書類確認をかなり厳密にやっていると理解しているし、たまに身元詐称があることはあっても、それが多いとは思えない。
解雇だけが問題ではなく、Amazonが全面的なRTOを実施した直後に、リクルーターからのメール爆撃を大量に受けたのを覚えている。
H-1Bであるというだけで、エンジニアとしての実力に対する先入観を持つ空気があるようだ。
以前の私はH-1Bで働いていて、今はインドに戻って自分のビジネスを運営している。Amazon出身だ。厳しい職場だったが、90年代半ば当時はストックオプションがあったので働く価値はあった。
ここにいるかなりの人たちより自分のほうがコーディングは上手い自信がある。少なくとも私の周囲では、H-1B出身者に本当に優秀な人が多かった。
先入観を持たず、実力を直接評価すべきだ。競争相手を過小評価すれば、結局は自分が損をする。
今こそ社員を守り、彼らがよい仕事をできるよう最高のツールを提供する未来こそが答えだ。
開発ツールは毎日進化しており、当面は人員削減を進めることもできるだろうが、効果はすぐには出ない。
将来の成長と組織の持続可能性を犠牲にして現在をしのいでいるようなものだ。思い込んだからといってダウンサイジングがうまくいくわけではない。
実際にはこの戦略はうまく機能しているように見える。ジュニアプリンシパルエンジニアの4分の1を解雇しても株価は上がり、その後に大規模障害が起きたときも株価はむしろまた上がった。少なくとも今のところ、彼らの戦略は回っているように見える。
もはや昔の「新興」ビッグテック企業も、IBMのような老いた大企業の時代に入りつつある。
離職率が悪いことを知らないのではなく、そもそも組織設計の段階から社員全体を平均的な水準に均して、互いに置き換え可能な人的リソースにしてしまう方向なのだと思う。
今では、単に実力が突出していることさえ「カウボーイ文化」とみなされる始末だ。
実際の障害対応が始まった時点が米国西海岸の始業時間と一致しているのは、かなり怪しく感じられた。
その前の更新は「監視中、緩和作業を進行中」というだけで、具体的な情報はなかった。
私の理解では、復旧はシアトル時間で午前4時ごろだったと思う。業務開始は普通9時なので、もしかするとニューヨーク基準では午前6時ごろに始まったのかもしれない。
今朝Redditで読んだ投稿が、今になってより意味深く感じられる。
AWSは今でも自分が最も好むクラウドで、とても効率よく使っている。
私も一度くらいはAWSで働いてみたいと思ったことがあるが、いくつかの懸念が解消されたと確信できない限り、考え込んでしまう。
候補者となる管理職が、こうした過程ですら候補者を守れないなら、もっと深刻な企業文化の問題でも守れないのではないかという懸念。
最近のFAANG全体に当てはまる考えとして、本来は実力のある人たちが行きたがる場所だという認識を、継続的に新しく植え付ける必要がある。
Metaは主により高い報酬とオープンソース・オープンハードウェアの公開などでブランディングしてきたし、Googleは技術的優位と温かい企業文化を強調してきた（いわゆる新卒育成文化で、今では形式的だが）。
AWSにもすでに誇れる技術人材は多く、彼らをうまく惹きつけ維持することに投資しつつ、業界に対してそうしたイメージを積極的に発信する必要があると思う。
スタートアップでもまったく同じことを見たことがある。
買収後には中核人材が株式のベストで去ったり、大企業が別の人をその席に座らせるため追い出したりすることが多い。
技術を本当に理解している人たちは皆去り、結局は保守不能なめちゃくちゃなコードベースだけが残って、誰も直せない問題が生じる。
El Regが事態の本質を的確に突いてくれるところがとても気に入っている。
記事を書いたのがCorey Quinnだと、AWS関連でたくさん記事を書いてきた人だと、今さら気づいた。
書き手たちがウィットと個性をしっかり生かして文章を書く点も好きだ。
この人たちは、何が起きても本質をちゃんと突いてくる。
「問題が発生してから75分で、原因を特定のサービスエンドポイントにまで絞り込んだ」
それはそんなに時間がかかったことなのだろうか？ 自分はWeb開発ではないが、75分でどこに問題があるのか突き止めたなら、かなり速いように感じる。
以前ファームウェアエンジニアとして働いていたときは、どこで壊れたかを見つけるのに何週間もかかることがよくあった。
実際に問題発生頻度が0.01%で、相関もなく、リトライすると消えるような問題なら、本当に何週間もかかることはある。
ただ、そういうものは普通それほど高優先度の事案ではなく、本当に緊急の事故は再現性があり、1時間前までは正常だったものが突然壊れるケースだ。
一般に、適切に設計された事業中核システムであれば、診断に75分以上かかることはない。もちろん、修正にはそれ以上かかることがある。
現実にそんな理想的なシステムがよくあるとは言えないが。
普通の会社なら75分は長くないかもしれない。だが、世界最大のクラウドでインターネットの大部分が麻痺したのなら話は別だ。
実際には公式告知では「まだ調査中」と書いていても、内部ではそれより早く原因を推定していた可能性もある。
更新を急いで出すとユーザーに不要な誤解を与えることがあるので、慎重であるのは正しい。
私の考えでは、75分ならどんな重大障害の診断としてもほぼ最高レベルの速さだ。
Amazonは業界最高水準のインフラを持つことで知られている。
他の企業も皆Amazonのインフラを使っているのだから、SRE級の人材がこうした事故を本当に素早く突き止めることを期待してしまう。
組織内で失われつつある経験知やノウハウこそ、単にExcelのシートに書き込むことさえ難しい、本当に重要な価値だ。
組織が本物の実力者や長期在籍の専門家よりも、自分自身のブランドを育てる人や見せかけの採用を優先し、実際にシステムを理解している技術コア人材が押しのけられ始める。
こうした不均衡がAWSのような規模にまで達すると、LinkedInのセレブやチェックリスト型のDEI人事が本物のビルダーを圧倒し、実行品質、責任感、技術的完成度が徐々に弱まっていく。
今はAndy Jassyのリーダーシップが機能していないことが少しずつ明らかになっている段階であり、遠からずウォール街が交代を正式に要求するかもしれない。
The Registerが尊敬される報道機関だという話を聞くと、実際には彼らはそう呼ばれたがっていない気がする。