Railway 8 時間全停止 — Google Cloud の「誤アカウント停止」が露呈したクラウドのキルスイッチ

クラウド上にアプリを展開する開発者向け PaaS「Railway」が、日本時間 2026 年 5 月 20 日朝から約 8 時間にわたり全面ダウンした。ダッシュボード・API・データベース・コンピュート基盤が軒並み停止し、ピーク時には全リージョンのワークロードが到達不能になった。原因はサイバー攻撃でも自社のバグでもない。基盤である Google Cloud が Railway の本番アカウントを誤って一時停止した ことだった。

8 時間の経緯 #

アカウント自体は 10 分ほどで戻ったのに、完全復旧までは 8 時間かかった。一度落とされた分散システムは、止まった速さでは立ち上がらない。

なぜ「全停止」まで広がったのか #

Railway のネットワーク制御プレーンが Google Cloud に依存していたため、アカウント停止でエッジプロキシが経路判断を行えなくなった。結果として、Google Cloud 上にないはずの Railway Metal や AWS のワークロードまで連鎖的に到達不能 になった。利用者から見れば「Railway を信頼し、Railway が Google Cloud を信頼する」という推移的な信頼の鎖の、一番奥の一輪が外れただけで全体が崩れたことになる。

可用性も「セキュリティ」である #

セキュリティを機密性・完全性・可用性(CIA)で捉えると、今回失われたのは可用性だ。見逃せないのは、攻撃者が一人もいないという点である。クラウド事業者は規約違反の自動検知や不正対策として、テナントのアカウントを一方的に止める「キルスイッチ」を握っている。それが誤作動すれば、利用者にとっては自社基盤に対する DoS と変わらない。しかも個人や中小には、即座に異議を通すルートがほとんど用意されていない。

Railway は再発防止として Google Cloud 単一依存の解消と、AWS・自社基盤 Railway Metal への高可用性データベース分散を表明した。教訓は明快だ。インフラのリスク評価では「攻撃されたら」だけでなく「契約相手に止められたら」を必ず想定し、復旧の速度を他者の判断に握らせない設計にしておく必要がある。