Control Tower（以降、CT）には AWS Backup を landing zone の機能として有効化するオプションがあります。マルチアカウント環境のデータ保護を一括で整えられる便利な機能だが、実際に検討してみると「これは要件次第で無効のままでいいのでは」と思うところがあったので、考えたことをまとます。
いいところ：マルチアカウントのデータ保護が一発で整う
CT で AWS Backup を有効にすると、対象 OU 配下の各アカウントに以下が自動で展開されます。
- ローカルの backup vault
- バックアッププラン4種（hourly / daily / weekly / monthly）
- バックアップ用の IAM ロール（
aws-controltower-BackupRole）
さらに daily / weekly / monthly のプランには、セントラルアカウントの vault へのクロスアカウントコピーが最初から仕込まれています。
これを自前でやろうとすると、StackSet で vault と IAM ロールを全アカウントに配って、コピー先 vault のアクセスポリシーを書いて、KMS のキーポリシーを整えて……という作業が必要になります。それがコンソールの数クリックで済むうえ、Account Factory で作った新規アカウントにも自動で適用されまます。
別アカウントの vault にコピーが残るということは、元アカウントが侵害されたり、誤ってリソースごと消したりしても復旧できるということで、ランサムウェア対策としての価値も大きい。
しかし、とにかく柔軟性が低い
問題はここから。
日次バックアップの保存期間は35日固定で、変更できない
CT が作る aws-controltower-daily-backup-plan は保持期間が35日になっていて、「そんなにいらないから7日にしたい」と思っても、容易には変更できないの難点。AWSControlTowerExecutionを使えば変更できるが、CT のテンプレートを極力変更しないことが推奨されています。
保持期間の35日は、「うちはそこまでいらない」という組織にとっては単に過剰なだけです。
準備が大変
有効化する前に、自分で用意しなければいけないものがある。
- AWS Backup Administrator アカウント（委任管理者になる）
- Central Backup アカウント（コピー先の vault が作られる）
- マルチリージョンの KMS カスタマー管理キー（クロスアカウントコピー用）
専用アカウントを2つ新規に用意する必要がある、というのが地味に重い。既存のアカウントを流用するにしても、Security OU に置くことになるので構成の見直しが必要です。
KMS キーも「作って終わり」ではなく、キーポリシーを正しく書いて維持し続ける必要がありｍさう。
コストもかかる
かかるコストを分解すると、大きく3つあります。
1. KMS
カスタマー管理キーは1キーあたり月1ドル程度。マルチリージョンキーのレプリカもそれぞれ1キーとしてカウントされます。ガバナンスリージョンが3つでも月数ドルなので、正直これ自体は誤差の範囲。
2. 専用アカウント2つ分のガバナンスコスト
こちらのほうがずっと効いてくる。Backup Administrator と Central Backup の2アカウントは CT のガバナンス下に入るので、全ガバナンスリージョンで Config レコーダーと CloudTrail が回り続けます。
これはバックアップを1本も取っていなくても発生する固定費になります。
3. ストレージの二重持ち
実運用に入ると、これが桁違いに大きい。ローカル vault とセントラル vault で同じデータを2セット、35日分保持することになります。クロスアカウントコピーはストレージ料金が単純に倍になります。る。
とはいえ、有効にしただけでは課金されない
一点フォローしておくと、CT のバックアッププランはタグベースのオプトイン方式になっていいます。
| プラン | 対象タグ |
|---|---|
| hourly | aws-control-tower-backuphourly: true |
| daily | aws-control-tower-backupdaily: true |
| weekly | aws-control-tower-backupweekly: true |
| monthly | aws-control-tower-backupmonthly: true |
このタグを付けたリソースだけがバックアップの対象になるので、有効にしていてもタグを付けなければジョブは1本も走らず、ストレージ課金も発生しない。上の「コスト」のうち3番目は、実際に使い始めてからの話になる。
なお hourly プランだけはセントラル vault へのコピーがないので、「世代管理はしたいがクロスアカウントコピーまでは不要」という場合はこれだけ使うという選択肢もある。
結論
向いているケース
- ランサムウェア対策や内部不正対策として、別アカウントへの論理エアギャップが要件になっている
- 監査で「35日保持」を示す必要がある
- アカウント数が多く、新規アカウントへの自動適用のメリットが大きい
向いていないケース
- 復旧要件が「誤操作からの巻き戻し」レベル
- 保持期間や頻度を自社要件に合わせて細かく調整したい
- 専用アカウント2つを用意する余力がない
自分の場合は後者に近かったので、CT の AWS Backup は有効にせず、Organizations のバックアップポリシーを自分で書く方向に倒すのがよさそうだと考えています。これなら保持期間もコピー先も自由に決められるうえ、OU 単位で適用という自分の決めた範囲でバックアップポリシーを適用できます。