はじめに
ここまでの構成例は、オンプレの NAS とクラウドを組み合わせるハイブリッドでした。本記事では、オンプレを持たず、Wasabi と AWS S3 という 2 つのクラウドプロバイダに不変バックアップを分散する、クラウドオンリーの構成例を扱います。狙いは、単一プロバイダの障害（全体障害・アカウント凍結・課金トラブルなど）にも耐えられる、相関障害に強い設計です。
クラウドオンリーは、設計次第で 3-2-1-1-0 を満たせます。ただし「本番データがどこにあるか」と「ローカルの即時復旧層がない分の復旧速度（RTO）」を明確にすることが前提になります。対策全体は『ランサムウェア対策の基本と全体像｜3-2-1-1-0 で守るバックアップ設計』を、設計の考え方は『ファイルサーバーのランサムウェア対策｜不変バックアップ設計の基礎』を、ハイブリッド版は『オンプレ NAS と AWS S3 でランサムウェア対策｜3-2-1-1-0 の構成例（①）』『オンプレ NAS と Wasabi でランサムウェア対策｜低コストな 3-2-1-1-0 構成例（②）』をあわせて参照してください。
- クラウドオンリーで 3-2-1-1-0 を満たす考え方と、本番データの所在の整理
- S3 と Wasabi の 2 プロバイダで相関障害を断つ設計
- 両者を不変化し、アカウントを分離する具体策
- ローカル即時復旧層がないことの RTO・コストへの影響と、向き不向き
結論を先に述べると、クラウドオンリーは「素朴に 1 プロバイダ・1 アカウントへ集約する」と弱い構成になりますが、S3 と Wasabi に分散し、双方を Object Lock で不変化し、アカウントを分離すれば、相関障害に強い 3-2-1-1-0 を構成できます。一方で、手元で素早く戻せるローカル層がないため、大規模復旧の RTO は長くなりやすい点を前提に設計します。
全体構成: クラウドオンリーで 3-2-1-1-0 を満たせるか
本番データの所在を明確にする（ローカル即時復旧層がない前提）
クラウドオンリーでまず決めるべきは、本番データの所在です。オンプレの NAS がない以上、本番はクラウド上のワークロードやファイルサービス（クラウドのファイル共有、サーバー上のデータなど）にあります。この本番に対し、S3 と Wasabi の 2 系統の不変バックアップを持つ、という関係を最初に明確にします。
各層の役割（本番 / S3 不変 / Wasabi 不変）とデータフロー
- 本番データ: クラウド上で日常的に読み書きされる実体
- S3 不変コピー: Object Lock で保護したオフサイトコピー。
- Wasabi 不変コピー: 別プロバイダの Object Lock で保護したオフサイトコピー。
3 つのコピー（本番・S3・Wasabi）、2 つの独立したプロバイダ、いずれもオフサイト、双方が不変、そして復旧テスト（0）という形で 3-2-1-1-0 に対応づけます。
プロバイダ分散の狙い: 相関障害を断つ
「2 メディア」をプロバイダ多様性で解釈する
3-2-1-1-0 の「2 種類のメディア」は、本来「単一の障害要因で全コピーを同時に失わない」ことを意図しています。クラウドオンリーでは、物理メディアの種類ではなく、独立した障害ドメイン（別プロバイダ・別アカウント）として解釈するのが現実的です。S3 と Wasabi は事業者もインフラも異なるため、片方で広域障害やアカウント問題が起きても、もう片方が残ります。
想定する障害
具体的には、プロバイダ全体の障害、アカウントの凍結・停止、課金トラブルによるアクセス不能、特定サービスの systemic な不具合などが想定されます。これらは単一プロバイダ内でリージョンを分けても完全には避けられないため、プロバイダ自体を分けることに意味があります。
不変化と分離の設計
両者を Object Lock で不変化する
S3・Wasabi とも、S3 互換の Object Lock で不変化します。本番や管理アカウントが侵害されても、保持期間中はバックアップを書き換え・削除できない状態を保ちます。
参考: AWS「Amazon S3 Object Lock」
“S3 Object Lock blocks permanent object deletion during a customer-defined retention period”
（S3 Object Lock は、利用者が定めた保持期間中、オブジェクトの完全削除を防ぐ）
https://aws.amazon.com/s3/features/object-lock参考: Wasabi「Immutability: Compliance and Object Lock」
“You can enable object locking only during bucket creation”
（オブジェクトロックはバケット作成時にのみ有効化できる）
https://docs.wasabi.com/docs/immutability-compliance-and-object-locking
保持モードは、検証や運用の柔軟性を残すなら Governance、規制対応など最も堅牢にするなら Compliance を選びます。それぞれの設定手順は、関連記事『AWS S3 Object Lock でランサムウェア対策｜設定手順と注意点』『Wasabi Object Lock でランサムウェア対策｜設定手順とコストの注意点』を参照してください。
アカウント・認証情報の分離（クラウドでは ID 侵害が主戦場）
クラウドオンリーでは、攻撃の主戦場が認証情報・ID の侵害に移ります。鍵を盗まれれば、クラウド上のデータをまとめて操作されかねません。そのため、S3 と Wasabi はそれぞれ独立したアカウント・認証情報で管理し、最小権限と MFA を徹底します。保持期間中はルートでも消せない不変性（Compliance モードなど）を要件に含めると、ID が侵害されても不変コピーは守られます。
一方から他方への複製の組み方
S3 と Wasabi の間にネイティブな相互レプリケーションはありません。実装としては、本番（バックアップ元）から両方のプロバイダへ書き込む形か、コピーツールやバックアップアプリで一方から他方へ複製する形になります。複製先も必ず Object Lock で不変化し、複製の認証情報も分離しておくと、一方が侵害されても波及を抑えられます。
RTO とコストの考え方
ローカル即時復旧層がないことの影響
クラウドオンリーの弱点は、手元で素早く戻せるローカル層がないことです。復旧はクラウドからの取り出しになるため、大容量データの全体復元では時間がかかりやすく、RTO は長くなりがちです。日常的な誤削除の即時復旧を重視する場合は、ハイブリッド（①②）の方が有利です。
egress と最低保管の織り込み
復元時のコストはプロバイダで異なります。S3 は egress（データ転送）に課金されるため、大規模復元では費用がかさみます。Wasabi は egress が無料な一方、90 日の最低保管と月 1 TB の最低課金があります。2 系統を維持する分、保管コストは単一構成より増えるため、保持期間・世代数・どちらを主たる復元元にするかを、コストと RTO の両面で設計することをおすすめします。
どんな組織に向くか（適用判断）
この構成が向くのは、本番がすでにクラウド上にあるクラウドネイティブな組織や、既存のバックアップにプロバイダ分散の冗長性を足したい場合です。逆に、オンプレのファイルサーバーがあり、日常の即時復旧を重視する組織では、ローカル層を持つハイブリッド（①②）の方が RTO とコストのバランスが取りやすくなります。自社の本番の所在と、許容できる復旧時間から逆算して選ぶのが現実的です。
まとめ
Wasabi と S3 を組み合わせるクラウドオンリー構成は、プロバイダ単位の障害に強い不変バックアップを実現できる設計です。鍵は、本番データの所在を明確にし、両者を不変化してアカウントを分離し、ローカル即時復旧層がない分の RTO を前提に組むことにあります。
- クラウドオンリーでも条件付きで 3-2-1-1-0 は満たせる。
- 本番データの所在を明確にして設計する。
- S3 と Wasabi の 2 プロバイダで相関障害を断つ。
- 両者を Object Lock で不変化し、アカウントを分離する。
- 「2 メディア」はプロバイダ多様性として解釈する。
- ローカル即時復旧層がなく RTO は伸びやすい。
- クラウドネイティブや冗長化の追加に向く構成
以上、最後までお読みいただきありがとうございました。
