---
title: "3-2-1ルールとは：AWS Backupのクロスリージョン・別アカウントコピーで組む設定例"
url: "https://www.issoh.co.jp/tech/details/19311/"
published: 2026-11-04
updated: 2026-11-04
categories: ["AWS"]
publisher: "株式会社一創"
---

# 3-2-1ルールとは：AWS Backupのクロスリージョン・別アカウントコピーで組む設定例

3-2-1ルールは、大事なデータを3つ持ち、2種類の媒体に置き、そのうち1つを離れた場所に保管するというバックアップの原則です。本記事では、US-CERTの資料に載った原文で定義を確かめ、ランサムウェア対策で広がった3-2-1-1-0との違いを整理します。そのうえで、クラウドでは「媒体」と「離れた場所」を何に読み替えるかを示し、AWS Backupのクロスリージョンコピーとクロスアカウントコピーで3-2-1を組むTerraformの設定例、コピーが失敗する鍵の条件や保持日数の落とし穴までを、2026年11月4日時点の公式ドキュメントに沿って解説します。

## まとめ：3-2-1ルールはAWSでは別リージョンと別アカウントへのコピーで満たす

AWSで3-2-1を満たす最小の形は、本番データ、同じリージョンの復旧ポイント、別リージョンへのコピーの3つです。ここに本番と権限を切り離したバックアップ専用アカウントへのコピーを足すと、ランサムウェアで管理者権限を奪われても残る1つになります。

実装はAWS Backupのバックアッププラン1本に、コピー先を2つ書けば済みます。詰まるのは設定よりも前提です。別アカウントへのコピーには、Organizationsでの有効化、コピー先保管庫のアクセスポリシー、共有できるKMSキーの3つが揃っている必要があります。コピーが動いたら、復元テストで戻せることまで確かめて完成とします。

## 3-2-1ルールの意味：3つのコピー・2種類の媒体・1つの遠隔地保管の定義

数字はそれぞれ、コピーの数、媒体の種類、離れた場所に置く数を指します。原典を見ると、どの数字も特定の障害に備える意図を持っています。

### US-CERTの2012年資料にある3-2-1ルールの原文と3つの数字の意味

米国のUS-CERT向けにカーネギーメロン大学が2012年に作成した[Data Backup Options](https://www.cisa.gov/sites/default/files/publications/data%5Fbackup%5Foptions.pdf)は、3-2-1ルールを次のように書いています。出典の注は、写真家Peter Kroghの著書『The DAM Book』第2版（2009年）です。

- 3：重要なファイルのコピーを3つ持つ（元データ1つとバックアップ2つ）
- 2：種類の違う危険に備えて、2種類の媒体に保存する
- 1：1つは建物の外（オフサイト）に保管する

見落とされやすいのは「3」に元データが含まれる点です。バックアップは2つで足ります。「2」はディスク故障のような媒体固有の壊れ方を、「1」は火災や地震のような拠点ごとの被害を避けるための条件です。

### 3-2-1-1-0ルールとの違い：イミュータブルな1つと復元エラー0の追加

3-2-1が想定していたのは故障と災害で、攻撃者がバックアップを消しにくる事態ではありません。そこでバックアップ製品のVeeamは[3-2-1-1-0ルール](https://www.veeam.com/blog/jp/321-backup-rule.html)を提唱しています。4つ目の「1」は書き換えできない（イミュータブル）か物理的に切り離したコピーを1つ持つこと、「0」は自動の復元検証で復元エラーを0にすることです。

実務では、3-2-1を満たしたうえで「1」と「0」を足す順番が現実的です。消せないコピーの作り方は[イミュータブルバックアップの実装手順と保持期間の決め方](https://www.issoh.co.jp/tech/details/18742/)で扱っています。本記事は配置の原則と、AWSでのコピーの組み方に絞ります。

### クラウドでの読み替え表：「2種類の媒体」と「1つの遠隔地」が指すもの

クラウドではテープや外付けディスクを自分で選びません。媒体の違いは「同時に壊れない単位か」で読み替えるのが実務的です。以下は一創の整理で、AWSが3-2-1の対応を定めているわけではありません。

| 原則の要素  | オンプレミスでの典型 | AWSでの読み替え            | 防げる事態         |
| ------ | ---------- | -------------------- | ------------- |
| 3つのコピー | 本番・NAS・テープ | 本番・東京の復旧ポイント・大阪へのコピー | 単一の削除や破損      |
| 2種類の媒体 | ディスクとテープ   | 本番ストレージと別の保管庫・別キー    | 同じ仕組みの障害の連鎖   |
| 1つは遠隔地 | 別拠点の倉庫     | 別リージョン               | リージョン単位の大規模障害 |
| 追加の1つ  | オフラインのテープ  | 別アカウント＋Vault Lock    | 管理者権限の乗っ取り    |

オンプレミスのNASが混ざる構成では、NAS上のスナップショットを「2つ目」、クラウドへの複製を「遠隔地の1つ」とする組み方が多くなります。NAS側の設定は[NASのランサムウェア対策とスナップショット・世代の設定](https://www.issoh.co.jp/tech/details/19293/)にまとめています。

## AWS Backupの3-2-1構成設計：同一リージョン・別リージョン・別アカウントの3層

AWS Backupは、バックアッププランの1つのルールに複数のコピー先を書けます。製品の基本と対応サービスは[AWS Backupとは](https://www.issoh.co.jp/tech/details/3380/)で解説しています。

### 東京の本番・大阪へのコピー・バックアップ専用アカウントの役割分担

本記事の構成例は、本番アカウントの東京リージョンで日次バックアップを取り、同じアカウントの大阪リージョンと、バックアップ専用アカウントの東京リージョンへそれぞれコピーする形です。

1. 東京の保管庫：日々の誤操作からの復元に使う。保持14日
2. 大阪の保管庫：東京リージョン全体が使えないときの復旧に使う。保持14日
3. バックアップ専用アカウントの保管庫：本番アカウントを乗っ取られたときの最後の砦。保持35日

クロスリージョンとクロスアカウントを別のコピーに分けたのは、失敗したときの原因を切り分けやすくするためです。[クロスリージョンコピーの公式文書](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html)によると、新しいリージョンへの初回はフルコピー、2回目以降は対応サービスなら増分です。コールドストレージ層にあるバックアップはコピーできません。RDSはカスタムのオプショングループを引き継がないため、宛先リージョンに同じグループを先に作っておきます。戻したい時点と停止時間の決め方は[DR対策のRPO・RTOの目安](https://www.issoh.co.jp/column/details/9439/)を参照してください。

### クロスアカウントコピーの前提：Organizations・保管庫ポリシー・KMSキー

[クロスアカウントバックアップの公式文書](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html)が挙げる前提は次のとおりです。

- コピー元とコピー先が同じAWS Organizationsに属している
- Organizationsの管理アカウントで、クロスアカウントバックアップを有効にしている
- コピー先保管庫のアクセスポリシーで`backup:CopyIntoBackupVault`を許可している
- コピー先がデフォルトの保管庫ではない（既定の保管庫のキーは他アカウントと共有できない）
- コピー元の資源を顧客管理キーで暗号化しているなら、そのキーをコピー先アカウントへ共有している

最初の2つが欠けるとジョブはそもそも作れず、後の3つが欠けるとジョブは作られてから失敗します。設定の順番もこの並びどおりに進めると迷いません。

## Terraformで3-2-1のバックアッププランを書く手順とコピー先保管庫の設定例

引数名は[Terraform AWS Providerのaws\_backup\_planの文書](https://github.com/hashicorp/terraform-provider-aws/blob/main/website/docs/r/backup%5Fplan.html.markdown)に沿っています。アカウントIDやOrganizationsのIDは例示の値です。Terraformの初期設定と状態管理は[TerraformでAWSを構築する手順](https://www.issoh.co.jp/tech/details/1900/)にまとめています。

### 管理アカウントとバックアップ専用アカウント側：有効化と保管庫ポリシーの設定例

管理アカウントでは[aws\_backup\_global\_settings](https://github.com/hashicorp/terraform-provider-aws/blob/main/website/docs/r/backup%5Fglobal%5Fsettings.html.markdown)でクロスアカウントバックアップを有効にします。バックアップ専用アカウントでは、顧客管理キーで暗号化した保管庫を作り、組織内からのコピーだけを許可します。

```
# 管理アカウント：組織でクロスアカウントバックアップを有効化
resource "aws_backup_global_settings" "org" {
  global_settings = {
    "isCrossAccountBackupEnabled" = "true"
  }
}

# バックアップ専用アカウント（例: 222222222222）の東京リージョン
resource "aws_kms_key" "copy" {
  description         = "3-2-1 copy vault key"
  enable_key_rotation = true
}

resource "aws_backup_vault" "copy" {
  name        = "org-321-copy-vault"
  kms_key_arn = aws_kms_key.copy.arn
}

data "aws_iam_policy_document" "allow_org_copy" {
  statement {
    effect    = "Allow"
    actions   = ["backup:CopyIntoBackupVault"]
    resources = ["*"]
    principals {
      type        = "AWS"
      identifiers = ["*"]
    }
    condition {
      test     = "StringEquals"
      variable = "aws:PrincipalOrgID"
      values   = ["o-a1b2c3d4e5"]
    }
  }
}

resource "aws_backup_vault_policy" "copy" {
  backup_vault_name = aws_backup_vault.copy.name
  policy            = data.aws_iam_policy_document.allow_org_copy.json
}
```

許可する操作は`backup:CopyIntoBackupVault`だけに絞ります。公式文書でも、これ以外のクロスアカウント操作は拒否されるとの記載です。この保管庫にVault Lockを掛ければ、3-2-1-1-0の「書き換えできない1つ」も同時に満たせます。

### 本番アカウント側：2つのcopy\_actionで大阪と別アカウントへ送る設定例

本番アカウントでは、東京と大阪に保管庫を作り、1つのルールに`copy_action`を2つ書きます。大阪側はプロバイダーの別名で作ります。

```
provider "aws" {
  region = "ap-northeast-1"
}

provider "aws" {
  alias  = "osaka"
  region = "ap-northeast-3"
}

resource "aws_backup_vault" "tokyo" {
  name        = "prod-tokyo-vault"
  kms_key_arn = var.tokyo_kms_key_arn
}

resource "aws_backup_vault" "osaka" {
  provider    = aws.osaka
  name        = "prod-osaka-vault"
  kms_key_arn = var.osaka_kms_key_arn
}

resource "aws_backup_plan" "rule_321" {
  name = "plan-3-2-1"

  rule {
    rule_name         = "daily"
    target_vault_name = aws_backup_vault.tokyo.name
    schedule          = "cron(0 17 * * ? *)" # 毎日 02:00 JST

    lifecycle {
      delete_after = 14
    }

    # 遠隔地の1つ：同じアカウントの大阪リージョン
    copy_action {
      destination_vault_arn = aws_backup_vault.osaka.arn
      lifecycle {
        delete_after = 14
      }
    }

    # 追加の1つ：バックアップ専用アカウントの保管庫
    copy_action {
      destination_vault_arn = "arn:aws:backup:ap-northeast-1:222222222222:backup-vault:org-321-copy-vault"
      lifecycle {
        delete_after = 35
      }
    }
  }
}
```

対象の資源を選ぶ`aws_backup_selection`とIAMロールは、この設定例では省略した部分です。独自のIAMロールを使う場合、`backup:CopyFromBackupVault`と`backup:CopyIntoBackupVault`の2つを明示的に許可しないと別アカウントへのコピーが失敗します。AWS管理ポリシーの`AWSBackupServiceRolePolicyForBackup`には両方が含まれています。

### コピージョブの成否をCLIで確かめる：失敗ジョブの抽出と宛先の復旧ポイント

プランを適用した翌日に、コピーが両方の宛先へ届いたかを確かめます。コンソールのジョブ画面でも見られますが、CLIなら失敗だけを抽出できます。

```
# 本番アカウント：11月1日以降に失敗したコピージョブと理由を一覧する
aws backup list-copy-jobs --by-state FAILED \
  --by-created-after 2026-11-01T00:00:00Z \
  --query "CopyJobs[].{Arn:ResourceArn,Dest:DestinationBackupVaultArn,Msg:StatusMessage}"

# バックアップ専用アカウント：宛先の保管庫に復旧ポイントが届いているか
aws backup list-recovery-points-by-backup-vault \
  --backup-vault-name org-321-copy-vault --profile backup-account
```

注意したいのは、別アカウントのバックアップから本番アカウントへ直接は復元できない点です。公式文書の手順では、復旧ポイントを復元したいアカウントへコピーし直してから復元します。この2段の手順を[AWS Backupの復元テスト](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html)と合わせて月1回は通しておくと、3-2-1-1-0の「0」を記録で示せます。

## 3-2-1を満たしたつもりで戻せない落とし穴：鍵・保持日数・PITRの制約

コピーが「完了」になっていても、戻せる保証にはなりません。AWS Backupで起きやすい抜けは次の3つです。

### AWS管理キーで暗号化したRDSやEBSを別アカウントへコピーできない条件

[暗号化の公式文書](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)によると、AWS Backupが完全には管理しない資源（RDS・Aurora・EBS・EC2など）は、元の資源の暗号化をそのまま引き継ぎます。AWS管理キー（`aws/rds`など）のキーポリシーは変更できず、別アカウントと共有できません。そのため、AWS管理キーで暗号化したRDSは、そのままでは別アカウントへコピーできない仕組みです。

新しく作るデータベースは、最初から顧客管理キーで暗号化しておきます。既存の資源は、顧客管理キーで暗号化し直したスナップショットからの作り直しになり、停止時間を伴う作業が必要です。3-2-1を後付けで検討するときは、まずここを棚卸しします。

### コピーの保持日数は1週間以上：短いと毎回フルコピーになる理由

[コピーの公式文書](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-a-copy.html)は、コピーの保持日数を少なくとも1週間にするよう勧めています。宛先の保管庫に復旧ポイントが1つも残っていない状態で次のコピーが走ると、増分ではなくフルコピーになるためです。大きなデータベースでは、フルコピーが数時間かかって次のコピーと重なり、ジョブが待ち状態のまま積み上がります。

保持日数は料金にも直結する条件です。コピーの料金は宛先の保管料金に加え、リージョン間のデータ転送料金がかかります。単価は[AWS Backupの料金ページ](https://aws.amazon.com/backup/pricing/)でリソース種別ごとに確かめます。コールドストレージへ移す設定にする場合、削除までの日数は移行日数より90日以上長くしなければなりません。

### 継続バックアップのコピーはスナップショットになりPITRで戻せない点

RDSやS3の継続バックアップは、任意の時点に戻せるポイントインタイムリカバリ（PITR）が使えます。ところが別リージョンや別アカウントへコピーすると、そのコピーは定期のスナップショットとして扱われ、PITRは使えません。

つまり、遠隔地のコピーで戻せるのはコピーを取った時点までです。日次のコピーなら最大で約1日分のデータを失う前提で、業務側と合意しておきます。それより細かい時点が要るシステムは、データベース自体のレプリケーションを別に組む必要があります。

## 3-2-1ルールの導入判断：AWSだけで足りる条件とオンプレ併用が要る場面

判断の軸は、本番がどこで動いているかと、失ってよいデータの時間幅です。

### AWS内で完結させてよい条件：本番がAWS上で日次の時点まで戻せば足りる

本番のデータベースやファイルがAWS上にあり、遠隔地のコピーは日次の時点まで戻せれば足りるなら、本記事の構成をそのまま採用してよい条件がそろっています。AWSのリージョンとアカウントで媒体と場所を分ければ、テープ装置や別拠点を新たに持つ必要はありません。

逆に、検証環境やインフラのコードから数時間で作り直せるサーバーにまで3層のコピーを掛けるのは過剰です。対象はタグで絞り、作り直せないデータだけを選びます。方式ごとの容量と世代数の考え方は[システムバックアップとは](https://www.issoh.co.jp/column/details/13448/)で整理しています。

### AWSだけでは足りない場面：オンプレ混在とAWS担当が社内にいない体制

オンプレミスのファイルサーバーや基幹システムが残っている構成では、AWS Backupだけでは3-2-1になりません。社内のNASやバックアップサーバーからクラウドへ複製する経路を別に設計する必要があります。もう1つは体制の問題です。Organizationsの管理アカウント、KMSキーのポリシー、別アカウントからの復元手順は、担当者が1人しかいないと手順書ごと失われがちです。

一創では[AWS・Google Cloud・Azureのインフラ構築](https://www.issoh.co.jp/service/system/aws/)として、既存のバックアップ構成の棚卸しから、別リージョン・別アカウントへのコピーの設計とTerraform化、復元テストの運用までを受けています。

## 3-2-1ルールのよくある質問：個人PC・NAS・クラウドストレージの扱い

3-2-1ルールを自社の環境に当てはめるときに出やすい質問に答えます。

### 3-2-1ルールは個人のPCや小規模な事務所にも当てはまりますか？

当てはまります。原典のUS-CERTの資料も、対象は家庭の利用者から企業までです。小規模な事務所なら、PC本体の元データ、社内の外付けディスクかNAS、クラウドストレージの3つで構成する形です。外付けディスクは普段は外しておくと、ランサムウェアに一緒に暗号化される危険を下げられます。PCとサーバーの具体的な手順は[バックアップのやり方](https://www.issoh.co.jp/column/details/13583/)で解説しています。

### NASとクラウドストレージの組み合わせで3-2-1ルールを満たせますか？

満たせます。本番のPCやサーバー、社内のNAS、クラウドの3つで、媒体と場所の条件がそろうためです。ただしNASの管理者アカウントとクラウドの認証情報が同じ人の同じパスワードなら、乗っ取られたときに両方を消されます。クラウド側は別の認証情報と多要素認証で守り、可能ならObject Lockのような削除できない設定を掛けます。

### Google DriveやOneDriveの同期は3つ目のコピーに数えられますか？

同期だけでは数えにくいのが実情です。同期は元のファイルの変更をそのまま反映するため、暗号化や削除も数分でクラウド側に届きます。各サービスの版の履歴やごみ箱で戻せる期間はありますが、管理者の操作で消せる点は変わりません。同期とは別に、世代を持つバックアップを取って初めて3つ目のコピーとして扱えます。

### 3-2-1ルールとイミュータブルバックアップはどう関係しますか？

3-2-1ルールはコピーの数と置き場所の原則で、消されないことまでは求めていません。イミュータブルバックアップは、そのうち1つを保持期間中は誰も消せない状態にする手段です。3-2-1-1-0の4つ目の「1」がこれにあたります。具体的な設定はS3 Object LockやAWS Backup Vault Lockで行い、手順は[イミュータブルバックアップとは](https://www.issoh.co.jp/tech/details/18742/)にまとめています。

### AWS Backupのクロスリージョンコピーにはどんな費用がかかりますか？

かかるのは、宛先リージョンでの保管料金と、リージョン間のデータ転送料金の2つです。初回はフルコピーなので転送量が大きく、2回目以降は対応サービスなら差分だけになります。宛先にも元と同じ世代数が積み上がるため、保管料金はコピー先の数だけ増える計算です。単価はリージョンとリソース種別で違うため、公式の料金ページで東京と大阪の値を確かめてから保持日数を決めます。

## 関連記事

- [イミュータブルバックアップとは：S3 Object Lock・Vault Lockの実装手順と保持期間の決め方](https://www.issoh.co.jp/tech/details/18742/)：3-2-1-1-0の「消せない1つ」を作る設定を扱っています。
- [AWS Backupとは？対応サービス・東京の料金とバックアッププラン作成・復元手順](https://www.issoh.co.jp/tech/details/3380/)：本記事の前提となるAWS Backupの基本と料金を確認できます。
- [NASのランサムウェア対策：SMB共有が暗号化される経路とスナップショット・世代の設定](https://www.issoh.co.jp/tech/details/19293/)：オンプレミスのNASを3-2-1に組み込むときの設定です。
- [DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方](https://www.issoh.co.jp/column/details/9439/)：別リージョンへのコピーをどの水準で持つかの判断材料になります。
- [システムバックアップとは？フル・差分・増分の違いと取得手順](https://www.issoh.co.jp/column/details/13448/)：世代数と容量の見積もりに使う方式の違いを整理しています。

---

出典: [3-2-1ルールとは：AWS Backupのクロスリージョン・別アカウントコピーで組む設定例](<https://www.issoh.co.jp/tech/details/19311/>)（株式会社一創）