導入
EBSのスナップショット、RDSの自動バックアップ、DynamoDBのバックアップ……サービスごとに別々の画面で設定していては、いつか取り忘れが出ます。AWS Backupは、そのバックアップを1か所にまとめるサービスです。さらに災害時に備える仕組みまで見ていきましょう。
説明
AWS Backupは、複数のAWSサービスのバックアップを一元管理するサービスです。
- バックアッププランに「毎日2時に取得」「35日間保持」「月次分は1年保持」といったルールを書くと、対象リソースのバックアップが自動で回る。
- 対象は Amazon EBS・Amazon EFS・Amazon FSx・Amazon RDS・Amazon Aurora・Amazon DynamoDB・Amazon S3 など幅広い。タグを付けたリソースを自動で対象に含めることもできる。
- 別リージョン・別アカウントへのコピーに対応。元のリージョンが被災してもバックアップが残る。
- 取得状況をレポートでき、「全部のDBが毎日バックアップされているか」という監査・コンプライアンスの証跡になる。
ここで区別したいのが、バックアップと災害対策（DR／ディザスタリカバリ）です。
| バックアップ | 災害対策（DR） | |
|---|---|---|
| 守りたいもの | 消えた・壊れたデータを戻す | システム全体を別の場所で動かし直す |
| 代表サービス | AWS Backup、各種スナップショット | AWS Elastic Disaster Recovery |
| 復旧までの時間 | 復元の作業時間がかかる | 待機中の環境を起動して切り替える |
AWS Elastic Disaster Recovery（AWS DRS）は、オンプレミスや他のクラウドで動いているサーバーをAWSへ継続的にレプリケーションしておき、障害が起きたら数分でAWS上に起動して切り替える（フェイルオーバーする）サービスです。平常時は安価なストレージにデータを複製しているだけなので、本番の二重構えを常時動かし続けるより費用を抑えられます。
DRの設計では2つの目標値を決めます。
- RPO（目標復旧時点）… どこまでのデータ損失を許せるか。「最大5分前までは戻せる」など。
- RTO（目標復旧時間）… どれだけの時間で復旧させるか。「2時間以内に再開」など。
flowchart LR
Need["守りたいのは？"] --> D1["データを戻したい"]
Need --> D2["システムごと切り替えたい"]
D1 --> B["AWS Backup（一元管理・保持期間・別リージョンへコピー）"]
D2 --> R["AWS Elastic Disaster Recovery（継続レプリケーション→起動）"]
B --> G["RPO / RTO を決めて設計"]
R --> G
具体例
オンラインショップを運営する会社が、監査で「バックアップの取得を証明してください」と言われて困りました。EBSは担当者が手でスナップショットを取り、RDSは自動バックアップ、DynamoDBは未設定——全体像を誰も把握できていませんでした。
そこで AWS Backup に寄せました。
Backup=dailyというタグを付けたリソースを自動的に対象にするバックアッププランを作成- 毎晩2時に取得し、35日間保持。月末分だけ1年保持
- バックアップを大阪リージョンにもコピーして、東京が被災しても残るようにした
- 取得結果をレポートで出力し、監査にはその証跡を提出
さらに、社内の在庫管理システムはまだオンプレミスのサーバーで動いていたため、AWS Elastic Disaster Recovery で常時AWSへ複製しておく構成にしました。地震でデータセンターが使えなくなったときは、複製から数分でAWS上に起動して業務を続けられます（RTO＝2時間、RPO＝5分という目標で合意）。
「取り忘れを防ぐ一元管理＝AWS Backup」「システムごと別の場所で立ち上げ直す＝Elastic Disaster Recovery」と役割が分かれます。
読んでみよう
「複数サービスのバックアップをまとめて管理・別リージョンにコピーしたい → AWS Backup」「サーバーを丸ごと別の場所で再開したい → AWS Elastic Disaster Recovery」。あわせてRPO＝どこまでのデータ損失を許すか、RTO＝どれだけ早く戻すかの2語を押さえておきましょう。