HOME/技術記事/Aurora MySQLのバックアップは本当に今の設定で安全か考える

Aurora MySQLのバックアップは本当に今の設定で安全か考える

2026/7/24 13:512026/7/31 20:50

メディア統括本部サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。

#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。

本記事は、Aurora MySQLの安全なバックアップ設計についてまとめている記事になります

なにかの役に立てば幸いです。

本当にAurora MySQLバックアップは安全か Aurora MySQLのバックアップ手段を整理する 1. 自動バックアップ（ネイティブ機能）と PITR 2. 手動スナップショット 3. AWS Backup 脅威モデルを 2 つに分けて考える【脅威A】誤操作・アプリ不具合【脅威B】AWS アカウント侵害・ランサム脅威Bのアカウント侵害に備える仕組み具体的な構成コストの注意点コストのイメージ例リストア訓練終わりに参考リンク

本当にAurora MySQLバックアップは安全か

みなさんAurora MySQLのバックアップ機能を使われているかと思いますが、

「もし AWS アカウントそのものが侵害されて、本番アカウント内のリソースを削除できる状態になったら、そのバックアップは生き残るか？」

という状況を想定した場合、ネイティブのバックアップ機能では心許ないのではないでしょうか。

この記事では、Aurora のバックアップ手段を整理し、どうすればデータ破壊から本当に守り切れるのかをまとめました。

先に結論

⚠️

バックアップを 別アカウント にコピーして、本番アカウントの侵害から切り離す

コピー先を AWS Backup Vault Lock のコンプライアンスモード にして、root でも消せない不変領域にする

Aurora MySQLのバックアップ手段を整理する

Aurora MySQLのバックアップには、性質の異なる手段が混在しています。

1. 自動バックアップ（ネイティブ機能）と PITR

Aurora がストレージ層で継続的に取っている自動バックアップです。ここから PITR（任意の秒単位の時点への復元） ができます。

強み

秒単位のきめ細かい復元ができる。増分ベースなので課金が安い。運用の手間がない

弱み

保持期間に上限がある（Aurora では最長 35 日）。復元データは Aurora クラスタと同じ AWSアカウント内にしか存在しない。

2. 手動スナップショット

任意のタイミングで取る明示的なスナップショットです。

手動で削除しない限り残りますが、これも デフォルトでは同一アカウント内に置かれる点は自動バックアップと同じです。

3. AWS Backup

RDS/Aurora を含む各種リソースのバックアップを一元管理するマネージドサービスです。

ネイティブ機能にはない以下の3つの機能を有しています。

クロスアカウントコピー

バックアップを別の AWS アカウントの Vault に複製できる

クロスリージョンコピー

別リージョンにも複製できる

Vault Lock

保管領域に対して「保持期間内は削除・短縮できない」というロックをかけられる

脅威モデルを 2 つに分けて考える

バックアップ設計で一番大事なのは、「何から守るのか」を分けて考えることです。

データが失われるシナリオは大きく2系統あります。

【脅威A】誤操作・アプリ不具合

をなしで流した、マイグレーションをミスった、アプリのバグで不正なデータを書き込んだなど。単にデータの中身が壊れたケースです。

これにはPITRを使うことで壊れる直前の時点にピンポイントで戻せます。

【脅威B】AWS アカウント侵害・ランサム

攻撃者が本番アカウントの認証情報を奪い、管理者権限を握ったケースです。この場合攻撃者は稼働中のDBデータだけではなく、バックアップのデータを削除することも可能になります。

自動バックアップ → クラスタごと削除されれば道連れで消える

手動スナップショット → APIで削除可能

同一アカウントの Backup Vault → 権限があれば削除可能

脅威	具体例	有効な守り
A 誤操作・不具合	WHEREなしDELETE、マイグレーション失敗	PITR（同一アカウントでよい）
B 侵害・ランサム	認証情報漏洩、管理者権限の奪取	別アカウントの不変バックアップ

つまり バックアップが本番と同じアカウントにある限り、アカウント侵害に対しては無力になってしまいます。

脅威Bのアカウント侵害に備える仕組み

別アカウントへのクロスアカウントコピー

AWS Backupで本番アカウントのバックアップを取り、それを バックアップ専用の別アカウント のVaultにコピーします。

このバックアップ専用アカウントを 本番運用者が普段触らない、権限を強く絞ったアカウントにします。

本番アカウントが丸ごと侵害されても、別アカウントの認証情報まで同時に奪われていなければ、そこにあるバックアップは生き残ります。

Vault Lock コンプライアンスモード

ただ別アカウントにコピーしただけでは、「両方のアカウントの権限を奪われたら？」という懸念が残ります。

そこで Vault Lock をかけます。Vault Lock には 2 つのモードがあります。

モード	挙動	位置づけ
ガバナンスモード	特権 IAM を持つプリンシパルなら、ロックの変更・バックアップの削除が可能	検証・移行期間向け
コンプライアンスモード	クールオフ期間の経過後は、AWS の root ユーザーを含め誰も保持期間内の削除・短縮ができない	本番の最終防衛線

コンプライアンスモードにすると、保持期間が満了するまでは 本当に誰も消せなくなります。

攻撃者が両アカウントの管理者権限を握っても、root でログインしても、コンプライアンスモードでロックされた保持期間内のバックアップは削除できません。

強力な反面、コンプライアンスモードは自分自身の設定ミスも同じ強度でロックインします。 「保持期間を間違えて長くしすぎた」「不要なデータをロックしてしまった」という場合でも、保持期間が切れるまで取り消せません。

まずはガバナンスモードで動作検証などを行い、あとでコンプライアンスモードに切り替えましょう。

具体的な構成

以上を踏まえると、実運用では次のように分ける設計になります。

本番環境用AWSアカウントではネイティブのPITRバックアップ機能に加えて、AWS Backupでアカウント内のVaultにスナップショットを保持します。

さらにそれをバックアップ用のAWSアカウントのVault Lockにコピーする設計となっています。

コストの注意点

Aurora MySQLのバックアップのコスト計算は少し複雑です。

手段	課金特性	備考
Aurora PITR	増分データ量にのみ課金	増分課金なので安い。保持を上限（35 日）まで延ばして、切り戻し可能期間を最大化してよい
AWS Backupフルバックアップ	世代（スナップショット）ごとに DB ストレージ相当が課金	世代を増やすほどリニアに費用が増える。

PITR は増分課金なので、上限まで延ばすコスト効率が良いです

AWS Backupのフルバックアップは世代ごとにフルサイズ課金 になります。DB が大きいほど費用インパクトが大きいので、「何世代持てば十分か」を運用実績ベースで見直す前提を最初から持っておくとよいです。まずは必要十分な世代数で始め、後から調整します。

ただし前述のとおりコンプライアンスモードでは保持期間を後から短縮できない点に注意です。

コストのイメージ例

https://aws.amazon.com/jp/rds/aurora/pricing/
https://aws.amazon.com/jp/backup/pricing/

東京リージョンでの試算

データ種別	データ量	かかる料金単価
対象クラスタのDBボリュームサイズ	3000GB	Amazon Auroraクラスタースナップショットウォームストレージ - 論理エアギャップボールト: USD 0.0265/GB-月
対象クラスタの1日のデータ変更量	50GB/day	バックアップストレージコスト: USD 0.023 per GB-month

ネイティブバックアップの料金は、クラスタに対する1日のデータ変更量にたいして請求されます。

1日50GBのデータ量が変更されている場合、以下の料金となります。

意外と高くはないなという印象です。

しかし、AWS Backupによるクロスアカウントコピーをおこなう場合コストが急増します。

クラスタボリュームサイズが3000GBで、日次のバックアップコピーを31日分残す場合、

以下のような試算になります。

毎日,3000GBのフルサイズのコストが31日分積み上がっていく計算になります。

このあたり料金が複雑ですので、よく確認するようにしましょう。

今回の試算には含めていませんが、別アカウントの別リージョンへコピーを行う場合は転送料金が別途かかる点にも注意が必要です。