「EC2と、移行が簡単な基本的なサービス（例えばS3やSES）を使えばいいんだ」 それが全てのインフラなら、そもそもAWSにいるべきじゃないよね。

数十億ドルの企業のために宣伝してる人たちの多さには驚くよね。

他のプロバイダーがもっと安くてサービスもいいのに、なんでAWSを使う必要があるの？

こんにちは、インフラは全然複雑じゃなかったよ。1日で移行できるくらい。入院してて、別の街にいて、家にはパソコンがあって、2FAでロックされてたんだ。木曜日に通知が来て、月曜日の夕方には全てのアクセスが取り消された。数週間、データへの読み取り専用アクセスをお願いしたけど、いつでも確認できるって言ったのに、拒否された。データについて聞けば聞くほど、話を避けられたよ。考えてみて、君が病気だったり、旅行中だったり、時差ボケだったり、祭りに行ってたり、結婚式を挙げてたり…オンラインに戻る頃には、もう遅いんだ。

確かにそうだけど、データを復元できないまま急に消される可能性があるのは怖いよね。それが唯一のコピーだったらなおさら。少なくとも90日間は保持すべきだと思う。私の意見では、6ヶ月から1年くらいが妥当だね。私にとっては、ストレージスペースが支払いを5日遅れたからって車を壊すのと同じことだよ。彼らは実際の所有者に返すべきだったデータを、実質的に盗んで壊したんだ。もちろん、これは私の意見だけど。私が知る限り、実際の法的枠組みはなく、実際の運用はプロバイダー次第だから、そこが信頼できない理由の一つなんだ。

その埋もれた肝心な部分は、（内部の人によると？）あるAWSの社員がすぐに全てを消去しちゃったってことだね（こういう状況では通常、データを保持するのが一般的なのに）。それが、OPが話していたサポートチェーンの中で、無視や隠蔽の連鎖を引き起こしたんだ。

支払い者がアカウントの所有者なの？AWSのデフォルトの立場とは思えないな。彼らの契約はアカウントホルダーと結んでるから、支払い者とは関係ない。俺が君の請求書を払ったからって、君のものの所有権が俺に移るわけじゃない。AWSにとっては、君の請求書は支払われた、それが彼らの関与の全てで、あとは君と俺の間の問題だよ。彼が書いてることが本当なら、彼はアカウントホルダーのままで、バックアップの支払い方法も用意してたはずだ。アカウントホルダーじゃなかったら、そんなことはないだろうし。彼がこの話について完全に正直かどうかはわからないけど、「誰かが支払ったから、彼らが所有者だと決めた」ってのはそういうことじゃないよ。

アカウントの支払いをしてるのは著者じゃなくて、僕なんだ。実際には、アカウントの支払いをしてる人が何千ドルもの請求書を支払わなきゃいけなかったんだ。彼らはAWSのギフトカードを提案して、電子機器を送ってくれるって言って、分割で支払うって。彼らは暗号の崩壊でたくさんのお金を失ったから、数ヶ月間のOSS利用料を支払うっていう解決策を受け入れたんだ。それは、君の家賃を1年間支払うようなものだよ。君は支払わないけど、僕は一度に君の3〜4年分の家賃を支払う必要はない。何が起こったかというと、AWSが君の家に核爆弾を落としたんだ、月の真ん中に…それから後で支払いのことだって言ってきた。最初のメールで支払いのことだって言ってくれたら、僕はリンクを外してバックアップしてたよ。

以前、働いていた会社のCTOに「ソースコードのバックアップは取ってる？」って聞いたら、「いや、githubにあるよ」って言われた。もう何も言えなかったね。

個人的には、弁護士ってクリエイティブだと思う。GitHubアカウントはたくさんの作業活動やNDA違反を示すことができるし。君の「プライベートリポ」は、電話一本でパブリックリポに変わる可能性があるよ。

その通り。テクノロジーの封建領主たちは、いつでも「君の」ものを全部オフにできる。個人用とビジネス用の災害復旧計画を常に持っておくべきだよ。隔離されたバックアップ（同期複製じゃなくて）を含めて、N >= 2の別々のサービスやモダリティに分けてね。いろんな状況に応じて考慮すべきオプションには、 - 異なるアカウント（名前、メール、支払い方法が違う）で異なるオブジェクトストレージクラウド、地理的に異なる可能性もある - Tarsnap（AWSを使ってるけど、他の誰かのアカウント） - MEGA - オンサイトの温かいメディアや冷たいメディア - 地理的に別のコロケーションDRサイト、過度に自慢する「今は100%（他人のSPoFに依存した）クラウドだ」っていうトレンドにもかかわらず - オフサイトの冷たいメディア（自宅やIronMountain）

GitHubでミラーとそうじゃないのをどうやって見分けるの？僕はよくgitを複数のアップストリームにプッシュするように設定してるから、基本的に全てのミラーがプライマリになり得るんだ。これがGitHubのいいところだよね。どのコピーも実質的にはミラーだし、暗号的に検証もされてるから、誰も気づかないうちにミラーが暴走する心配もないんだ。

確かに、規模が大きくなるほど難しくて高くなるけど、ビジネスの継続性を気にするなら必要な出費だよ。個人的には、最近はずっと安くなってるしね。「ライブミラー」まではいかないけど、ここやリアルでも何年も前からこれが一番大事だって言ってる。インフラは再構築できるけど、ユーザーのデータは再構築できないからね。長期間のダウンは悪いけど、場合によっては致命的ではないことも多い。多くのケースで、顧客は残ってくれるよ。（一ヶ月以上ダウンしても、キャンセルが一件もなかったクライアントと仕事してるけど、そのビジネスアプリが顧客にとってどれだけ価値があるかってことだね。）ユーザーのデータを失ったら、もう彼らが残るインセンティブはほとんどない。データを移行しなきゃいけないっていう「粘着性」もなくなるし、新しいデータを預ける信頼も完全に失ってしまう。彼らがあなたの製品に投資した努力をすべて壊してしまったから、再び投資するのに躊躇するだろうね。（それに、もし人のお金を扱っているソフトウェアなら、誰が何を持っているか分からなくなると、存在を脅かす訴訟が起こるかもしれないし。）データの「オフサイト」コピーを保つための障壁は、実はかなり小さいことが多いよ。今すぐデータベースをダンプしてB2に同期するスケジュールジョブを設定するのに、何が必要かな？もしそれが物流的に難しいなら（暗号化について監査人を納得させるとか）、別の法的実体の下で異なる支払い方法を使ったAWSアカウントを設定して、スナップショットやバックアップを同期するのに何が必要かな？人が死ぬようなソフトウェアを扱っていない限り、可用性よりも耐久性を優先すべきだよ。バックアップのバックアップは、18*π AZでのゼロダウンタイムフェイルオーバーを可能にするNティアのWeb-3エンタープライズスケーラブルアーキテクチャよりも重要だから。ケーススタディとして、GCPでのユニスーパーのインシデントを見てみてね: https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...

物理的なストレージ提供者も同じようなミスをよくするよ。間違ったストレージユニットを空にしたり、間違った貸金庫をゴミにしたりね。そういう損害を回収するための民事救済措置は強いかもしれないけど、必ずしもそうとは限らない。

まさにその通りだよね。AWSは自分のデータに対して何をするかについて責任を負わないんだ。AWS自体が、君が自分でやったDB移行の失敗から復旧するためのバックアップを作ってくれるわけじゃないし。君が管理ミスで本番環境を全部消しちゃったとしても、AWSは責任を負えない。でも、AWSは基盤となるインフラには責任がある。君がリンクしたウェブサイトには「ストレージ」がAWSの責任に入るってはっきり書いてあるよね。君の仮想ハードドライブが勝手に消えちゃうなんておかしい！もし彼らが「おっと、ごめん！」で君の全てを吹っ飛ばせるなら、冗長性や信頼性についての話は一体何の意味があるの？それなら、ジョーのディスカウントベースメントホスティングと何が違うの？

新しいアカウントでクラウドインフラを再設定するのに1日以上かかるなら、IaCファーストに投資することを考えた方がいいよ。

著者は「すべての卵を一つのバスケットに入れる」という意味を理解してないね。> 「誰かが『すべての卵を一つのバスケットに入れた』って言う前に、はっきりさせておくけど、俺はそうじゃない。俺は一つのプロバイダーに入れたんだ。弾丸を防げるはずの冗長性があった。それが一つのバスケット。単一障害点だ。『でも、失敗するはずがなかった！』バックアップは「不可能な」失敗に対処するためのものだよ（実際には100%信頼できるものなんてないからね）。

うん、その投稿は読みづらかった。データ損失に苦しむ人たちにはすごく共感するよ。「データを失ったことがない人」と「バックアップを取る人」の二種類の人がいるっていう言葉は、後者だけがその意味を本当に理解してるから、二重に皮肉だよね。でも、IT業界で10年以上の経験がある人たちがここでのリスクを理解していないのは驚きだ。タイムラインを見ると、最初の問題が表面化してからアカウントが削除されるまでに13日かかってる。つまり、何かをするように非常に明確なリマインダーが2週間あって、行動するための2週間もあったってことだよね。（最近BATNAっていう言葉を知ったんだけど、現代のITでは「亀のサービス」が全ての基盤になってるから、この概念がどれだけ適用されるかは驚くべきことだよ。）著者は、自分のパートタイムのシステム管理者を責めることにすごく熱心だけど、システムアーキテクトを責めるべきだと思う。その責任の分配アルゴリズムの魅力は理解できるけど、それでも間違ってる。言い回しとしては、>「でも、彼らが作り出したジレンマはこうだ：ペタバイトのデータがあったらどうする？バックアップのバックアップをどうやって取る？」っていうのは、馬車と馬を逆にしてるよね。もしペタバイトの重要なデータがあって、他のソースから再作成できないなら、心配すべきはデータを安全に保つことだよ。誰かにコピーを保管してもらうためにお金を払っているなら、（少なくとももう一人）別の人にもコピーを保管してもらうためにお金を払うべきだよ。それでも安全だとは言えないけどね。

私：「君はまるで私がピアーズ・モーガンに『10月7日を非難するか？』と聞いて、君が1948年まで遡る歴史的な複雑さで返答しているかのように答えている。」 そうだね…もし私がAWSでチケットを処理しているなら、その手の無礼さは、君のために最小限の努力しかしないことを確実にするよ。週末を全部使って君のデータを救おうとするかもしれないけど…それとも、手順に従って上司に「試みた」と知らせるだけにするかも。

そうそう、記事のどこかでこう言ってるよね：>「私はすべて正しくやった。Vaultの暗号化キーはメインインフラとは別に保存。深層防御。ゼロトラストアーキテクチャ。完璧だ。」って。ほんとにそうなの？すべてを一つのバスケットに入れるのが「深層防御」なの？AWSを完全に信頼するのが「ゼロトラストアーキテクチャ」なの？ここでAWSを擁護するつもりはないけど、彼らはこの件で受けるダメージに見合ったことをしてると思うし、AWSのミスで全てを失った開発者には同情するよ。多くの人が同じことをしてるし、今の僕の雇い主もそうだ。大手銀行で、全てがMicrosoft製品なんだ。Azure、SharePoint、Office、Teams、全部。重要なデータやインフラを一つの外国企業に任せるのは愚かだと思うし、政府が全てのアクセスを要求する国で運営されているのに、みんなそうしてるんだよね。「クラウド」を過信しすぎて、こういうミスに自分をさらしてる。

バックアップは取ってたよ。マルチリージョンで、冗長性もあった。AWSのベストプラクティスをそのまま守ったんだ。ただ、計画してなかった失敗は？AWSが失敗すること。プロバイダーが自分の保持ポリシーに違反して全てを消し去ること。それはバックアップの問題じゃなくて、プロバイダーへの信頼の問題だよね。ローカルコピーを保持しなかった理由は、ハードウェアの故障後にコンピュータをフォーマットしたから。看護師が病院でノートパソコンを落としちゃったんだ。AWSのバックアップがあったから、退院して家に戻るまでの間、新しいOSでスタートしたんだ。6日後に戻ったら、バックアップが消えてた。

うん、なんか怪しいよね。Javaの理論が確認されたとは言ってないよ。ただ、内部の人が後から教えてくれたことなんだ。彼らは--gnu-style形式でドライランフラグが渡されたって言ってたけど、内部ツールは-dryを期待してたんだ。JavaにはネイティブのCLIパーサーがないから、それを無視して実行しちゃったらしい。開発チームはPythonスタイルのCLIに慣れてて、ちゃんとテストされないまま通っちゃったみたい。

MENAは中東/北アフリカのことだね。（調べちゃったけど。）