AWS Organizationsで全社的にAWS Backupを導入した話

こんにちは。エンジニアリング＆デザインマネジメント室 SREチームの山口です。

今回はタイトルにあるように、AWS Organizations経由でAWS Backupを導入したお話をしたいと思います。

AWS Organizationsとは

AWS Oranaizations(以下、単にOrganizationsと表記)は、大量に保有しているAWSアカウントを組織(OU)という形で一元的に統制、監視など管理するマネージドサービスです。一元的に管理することで、支払いを纏めたり、リザーブドインスタンスの融通が効いたり、シングルサインオンでのログインを提供できたりと様々なメリットがあります。

嬉しいことに、Organizationsは無料で利用可能ですので、かなり気軽に利用できるのではないでしょうか。

AWS Organizations

AWS Backupとは

AWS Backup(以下、単にBackupと表記)は、名前の示すとおり各AWSサービスを必要な形でバックアップ取得することが出来るマネージドサービスです。

ただし、2023年1月時点でバックアップできるAWSサービスがEC2インスタンス、EBSボリューム、S3バケット、Auroraを含むRDSインスタンス(AuroraはRDS Cluster)、DynamoDBテーブル、Neptuneデータベース、DocumentDBデータベース、EFSファイルシステム、FSxファイルシステム、Storage Gatewayボリュームに限られており、ElastiCacheノード、Lambda関数などの主要に使用するAWSサービスのすべて対応しているわけではありません。

当然ながらサービスですので、各リソースでBackupを利用するための料金がかかる事も気にかける必要があります。

AWS Backup

また、BackupはOrganizationsのポリシーの1つであるバックアップポリシーという形で利用が可能です。今回はこの話が中心になってきます。

Organizationsのポリシー

導入した経緯

弊社の環境では、初期段階としてOrganizationsでAWSアカウントが組織下に入って管理されているだけで、当時バックアップのルールも社内には無く各AWSアカウントが独自ルールでBackupが設定されているという状況からスタートしました。

そして、注意深く各AWSアカウントのバックアップ状況を調査したところ、中には各サービスのバックアップ機能のみのバックアップでBackupを使用していないAWSアカウントやBackupを利用していても一部サービスのバックアップに留まっていたり、そもそもバックアップしていないAWSアカウントもありました。

このような状況から「これは折角OrganizationsでAWSアカウントを管理しているのだから社内向けバックアップルールを策定してBackupも集中管理してバックアップを実行していこう」という流れになりました。集中管理とは、Organizationsを通じて各Backupのバックアップをコントロールできるということです。基本設定ではバックアップデータは、各AWSアカウントが持ちます。

ここで言う「社内向けバックアップルール」（括弧内に具体設定例記載）とは、

どのサービスを対象に( AWSサービスの具体的なサービス名: EC2, RDS, DynamoDB)
どういう形式でバックアップを(形式: スナップショット)
どこでバックアップを取り(Backupかサービスのバックアップ機能: EC2,RDS,DynamoDB->Backup, ElastiCache->サービスのバックアップ)
いつバックアップ行うか(バックアップ頻度と実行時間: 毎日、UTC5時)
どの程度保持しておくか(保存期間: 1週間)
Organizationsのバックアップポリシー経由でバックアップする場合、タグ指定(バックアップターゲットタグ名: backup:1)

を決めたものです。

実際の導入

導入に際し、下記からAWS上でどんな操作が必要か順を追って具体的に説明を行っていきます。

実際の導入は、Organizations側AWSアカウント側(管理アカウント)と各AWSアカウント側(メンバーアカウント)での作業が必要です。

管理アカウントの作業

はじめは管理アカウント側の作業から行います。

まずOrganizationsのポリシーの設定の中からバックアップポリシーのステータスを「無効」から「有効」に切り替えます。

バックアップポリシーの有効化

次にバックアップを取りたいAWSアカウント個数分のバックアップポリシーを作成し、AWSアカウント別に設定を後から変更できるように分けます。

バックアップポリシー一覧

バックアップポリシーの中身の設定は、先述した「社内向けバックアップルール」に則って設定しています。
具体的に「バックアップルール」の設定、上から順に

バックアップ頻度
バックアップウィンドウの開始時間
保持期間

次いで「リソースを割り当て」の設定、上から順に

IAMロール
リソースタグキーとタグ値

リソース割り当て

の大きな2つの設定を行います。

1つ注意点として「リソースを割り当て」設定内で「IAMロール」の設定でIAMロール名を指定しますが、これらの設定はメンバーアカウントのBackup側設定を呼び出して実行されるわけなので、指定したIAMロール名が存在していないと権限エラーで正しくバックアップが実行できません。実設定として、

service-role/AWSBackupDefaultServiceRole
AWSBackupDefaultServiceRole

この2つのどちらかで設定することになると思いますが、どちらで設定することになるかはメンバーアカウントのIAMロールの設定次第となるので、予めPath(service-role/)有無を確認しておくと1つ失敗ポイントを減らせると思います。

実際のところ、メンバーアカウント内で独自にBackupを設定したことがある場合は前者のPath付きで作成済みになっていますが、1回もBackup設定したことがない場合は、このIAMロールが存在していないため後者のPath無しの設定も可能です。IAMロールが存在していなくて手動でIAMロールを作成する場合、Path付きで作りたい場合はIAMマネージメントコンソール上では作成できず、AWS CLI(今回なら [ aws iam create-role --path '/service-role/' --role-name AWSBackupDefaultServiceRole ] )で作成することになります。

IAMロールの形さえできれば、このIAMロールに必要な２つのIAMポリシー(管理ポリシー AWSBackupServiceRolePolicyForBackup と AWSBackupServiceRolePolicyForRestores のアタッチ)はIAMマネージメントコンソールで後から操作出来るため、AWS CLIで外側だけを作り、中身はIAMマネージメントコンソールで操作するのが楽だと思います。このIAMロールについて詳しくはこちらを参照して下さい。

「リソースタグキーとタグ値」は、バックアップターゲットとなるAWSリソースタグ名とタグ値の設定で、例えば、

backup: 1

のよう設定します。メンバーアカウントで行うバックアップと違いOrganizationsから行うバックアップはこのターゲットタグが付いているリソースのみがバックアップ対象になるので確実に設定して下さい。

バックアップポリシー最後の設定で対象となるAWSアカウントをアタッチします。

AWSアカウントアタッチ

今度は管理アカウントのBackupの設定です。Backupの「設定」内の3つ「サービスのオプトイン」「Amazon DynamoDB バックアップの高度な機能」「クロスアカウント管理」の設定を以下のように行います。

「サービスのオプトイン」は、バックアップを行いたいサービスのステータスを「有効」にします。
「Amazon DynamoDB バックアップの高度な機能」は、DynamoDBテーブルをバックアップしたい時に「有効」にします。
「クロスアカウント管理」は、Organizationsを通じてBackupを使用・管理したいので「バックアップポリシー」「クロスアカウントモニタリング」「クロスアカウントバックアップ」すべての項目で「有効」にします。

バックアップ設定1
バックアップ設定２

メンバーアカウントの作業

次は実際にバックアップを行うメンバーアカウント側の設定です。設定と言っても実際は管理アカウント側と連携に問題がないかどうかの確認が多いです。

まずは、管理アカウント側で設定した「バックアップポリシーのバックアップルール」内のバックアップを保存および整理するためのコンテナである「バックアップボールト」の新規作成作業です。

バックアップボールト

既存の「Default」を指定していない場合は新規で作成しておく必要があり、今回はDefaultを指定しなかったため、バックアップポリシー内で指定したバックアップボールト名に合わせて新規作成しました。

Defaultを使用せず新規で作成した理由は、Defaultの場合RDSやEBSなどのリソースを暗号化時に使用するKMS 暗号化キーを自分が作成した暗号化キー(CMK)を選択できずAWSが用意したマネージドキーになってしまい暗号化・復号化の処理が上手く行かないからです。

このバックアップボールトのアクセスポリシーが、管理アカウントの組織からのアクセス許可があるか確認します。設定がない場合は、「アクセス許可を追加する」で「組織からバックアップボールトへのアクセスを許可する」で設定をします。

アクセスポリシー

次は、バックアッププランの確認です。管理アカウントからアタッチしたAWSアカウントのバックアップポリシー内のバックアッププランが表示されていることを確認します。メンバーアカウントからは参照のみで編集は行なえません。

バックアッププラン

管理アカウントと同様にメンバーアカウントでもBackupの設定を確認しておきます。ただし、「クロスアカウント管理」だけはOrganizationsで管理されているため、メンバーアカウントからは設定できません。「サービスのオプトイン」は、バックアップを行いたいサービスのステータスを「有効」にします。「Amazon DynamoDB バックアップの高度な機能」は、DynamoDBテーブルをバックアップしたい時に「有効」にします。

最後は、上記「リソースタグキーとタグ値」で設定したタグが、アルファベット大文字小文字の相違無く同一の正しいタグがリソースに付いているか確認します。
一例として、EC2インスタンスにターゲットとなるタグが付いていることを確認しています。

EC2のタグ

他DynamoDBならテーブル、RDSならDBインスタンス、AuroraならDBクラスタ、S3ならバケット、EBSならボリュームを確認することになります。

そして、念の為バックアップポリシーのリソースの割り当て内で設定したIAMロールが正しく存在してるかどうか今一度改めて確認しておきます。

バックアップポリシーIAMロール

各種設定の確認

以上で管理アカウント、メンバーアカウントのバックアップ設定は完了したので、その後指定時間に指定したリソースのバックアップが行われるかどうかを確認します。

バックアップ確認は、管理アカウントBackupのクロスアカウントモニタリングから、各メンバーアカウントBackupのジョブからとどちらからでも確認できます。

ジョブ、クロスアカウントモニタリング

バックアップが実行されてエラーが出ている場合は、そのエラー内容に従い対応します。このジョブ画面にジョブ表示が存在しない場合は、ジョブ実行以前の問題だと思われるので1から設定の見直しをし、設定に誤りがないかどうか確認してみて下さい。よくある設定ミスは

メンバーアカウント側でターゲットタグ自体の設定忘れ、タグ名の大文字小文字の違い
管理アカウント側でバックアップポリシーへAWSアカウントアタッチ忘れ
管理アカウント側Backup設定オプトインでサービス有効になっているが、メンバーアカウントBackup設定オプトインでサービス無効になっているためそのサービスがバックアップ有効でない
- これは、管理アカウント設定がメンバーアカウント設定で上書きされるため
- 管理アカウント側とメンバーアカウント側で設定リージョンが異なる
- バックアップ時間がUTC設定なところをJSTで設定してしまっている

などが考えられるかと思います。改めて確認してみて下さい。

導入してみて

実際にバックアップ導入して運用開始してみるといくつか問題が出てきました。

まず運用中バックアップが意図せず失敗する時があることが判りました。失敗する理由がAWS側にあるため使用する側として対策することが難しいのですが、バックアップ失敗したことを検知する必要があることが出てきました。

そこで設定したのが、Backupの結果を通知する設定です。現状Backupマネージメント画面から設定を行うことができずAWS CLIでのみ設定が行えるようで、予めそれ用にSNSトピック作成しておき

# 通知設定
# aws backup --endpoint-url https://backup.ap-northeast-1.amazonaws.com put-backup-vault-notifications --backup-vault-name backup-vault --sns-topic-arn (sns-topic-arn) --backup-vault-events BACKUP_JOB_FAILED RESTORE_JOB_FAILED BACKUP_JOB_COMPLETED RESTORE_JOB_COMPLETED COPY_JOB_FAILED
# 通知設定確認
# aws backup --endpoint-url https://backup.ap-northeast-1.amazonaws.com get-backup-vault-notifications --backup-vault-name backup-vault

で設定することができました。

しかし、この設定で運用していると正常実行時も通知と不要な通知が来ることも判ったため、SNS設定内の「サブスクリプションフィルターポリシー」でCOMPLETEをフィルタするように設定し、正常時には通知しないように設定することでノイズの無い通知になり解決することが出来ました。

サブスクリプションフィルターポリシー

次はBackup自体は実行されているが、ターゲットタグが付いている対象リソースすべてバックアップ取れているか問題です。ここは難しいことを考えず単純な仕組みで、1日1回必ずバックアップが終了している時間後に定期的に対象リソースのバックアップが存在するかどうかのLambda関数を書き、EventBridgeで定期的にチェックすることで解決しました。

次に問題になったのは、Organizations経由でBackupを実行しているのにメンバーアカウント個別でバックアップボールト・バックアッププランが設定されており、同バックアップ内容で二重でバックアップが実行されていることがあったため、こちらはメンバーアカウントを使用している人に管理アカウント側で同様なバックアップを実行していることを伝え、個別バックアップを停止することで解決しました。

最後は将来的に起こり得る問題でまだ実際には起こってはいない問題で、Organizations経由でバックアップするリソースを特定する手段がターゲットとなるタグのみと、既存のリソースからバックアップを行っていることを知らない人にタグを外されることを懸念しました。

そのため既存タグに付いているタグが外されたことを検知する仕組みをAWS Configルールで検出する仕組みを導入しました。AWS ConfigのAWSマネージド型ルールの中に「required-tags」というルールがあり、こちらのルールを利用して設定しました。

ルールタイプの指定

ただし、リンクしたAWS Config公式ドキュメントの「重要」項目に書いてあるとおり、サポートしているリソースタイプに今回バックアップ対象のRDS DBCluster(Aurora用)が含まれていないことに注意しなければなりません。そのため、今回AWS Configルールとして利用できたリソースタイプは、

DynamoDB::Table
EC2::Instance
RDS::DBInstance

の3つに留まりました。
同様にRDS DBClusterもタグ検知したいので、別途AWS ConfigカスタムLambdaルールでLambda関数(PythonのLambda関数例)を使って検知する仕組みを構築しました。

トリガー

これで、動作としてAWSマネージド型ルールとカスタムLambda関数ルールで同等なものが実現出来たことで懸念を払拭することが出来ました。

導入後やったこと

導入後一番最初直ぐにやったことは、バックアップジョブからきちんと各リソースが復元出来るかどうかの確認です。避難訓練と一緒で、急に復元する必要が出てきた時一度もやったこと無いことをやるのは慌てることが目に見えているので、いざ復元する時が来た時慌てずに復元できるよう慣れておく必要があるからです。各リソースによって復元状態が異なるため、それを確認する意味も込められています。他にも、どの程度復元に時間を要するかも分かりますし。特に、RDS Auroraを復元してもDBClusterだけが復元され、DBClusterにぶら下がるDBInstanceまで復元されない点を知らないと慌てるでしょう。

暫く経って行ったことは、バックアップルールでBCP対策の観点でオプション設定していた「コピーを生成」を無効化したことでした。これはBackup設定しているAWSアカウントとは別のAWSアカウントへもバックアップを取る設定ですが、バックアップ専用の別AWSアカウント(1箇所)へのバックアップが集中して費用が想定以上に膨らんでしまい無効化するという判断をしました。

更に暫く経った後、バックアップ費用が嵩んでいると報告を受け慌ててバックアップジョブを確認したところ、バックアップルールで設定した筈の保存期間が無期限とルールで規定した保存期間以上に保存してために費用が嵩んでいることが発覚しました。そのため、保存期間以上に保存しているジョブを手動で削除し、保存期間内のジョブに対しては保存期間を手動設定しました。バックアップ保存期間が意図せず無期限になって保存されている理由は今になっては分かりませんが、既存設定は無期限になっていないかを確認、今後の設定に関しては保存期間が適切期間になっているか保存時に必ず確認、既存・新規バックアップ費用をバックアップ設定した時点でモニタリング(AWS Budgets)を徹底することで防ぐよう対策を取りました。

まとめ

最後に、まとめです。

社内向けバックアップツールを定めることが出来たお陰で、それに則ってBackupを利用したバックアップ体制を整えることが出来ました。ただし、Backupが完璧なものでないことも判り、それを補う対応を行いました。人的なミスによりバックアップが行えないことも考えなければならないことも説明し、それに対する対応も行いました。

幸いなことにBackupを利用開始してからバックアップが必要になる場面に遭遇していませんが、いつバックアップが必要になるか分からないため常に正しくバックアップが取られ、いつ何時でも利用できる体制を整える必要があるのがバックアップです！

今後の課題は、Organizations連携にアップデートが有ったり、Backupの新規機能追加やアップデートが有ったりしたら評価して導入したりとかでしょうか。

Backupに限った話ではありませんが、AWSは他サービスと連携することで真価を発揮することが多いので、今後どんな連携が出てくるかも楽しみです。