![[アップデート] AWS Backupで取得したバックアップの保持期間を延長するリーガルホールド機能が追加されました #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022.png)
[アップデート] AWS Backupで取得したバックアップの保持期間を延長するリーガルホールド機能が追加されました #reinvent
あぁ! そのバックアップは削除しないで!
こんにちは、のんピ(@non____97)です。
皆さんは「AWS Backupで取得したバックアップ(復旧ポイント)の保持期間を延長したいな」と思ったことはありますか? 私はあります。
AWS Backupによりバックアップを取得する際に取得するバックアップの保持期間を設定することがほとんどだと思います。バックアップの保持期間を設定することで、指定した期間を経過した後にバックアップが自動で削除されます。私も大好きな機能です。
しかし、トラブルなどでどこからデータに不具合が発生しているのか分からないときは、バックアップを自動で削除されたくない場面もあります。
「バックアッププランで保持期間を延長すれば良いのでは?」と思われるかもしれませんが、バックアッププランで保持期間を延長しても、新しい延長期間が適用されるのは設定変更後に取得したバックアップからです。
たとえば、バックアップルールでバックアップの保持期間を更新しても、更新前に作成されたバックアップの保持期間は変わりません。今後そのルールによって作成されたバックアップには、更新された保持期間が反映されます。
これは困った。
と思っていると、今回のアップデートにより、バックアップの保持期間を延長するリーガルホールドなる機能が追加されました
AWS公式ブログも投稿されていますね。
早速触ってみたので紹介します。
いきなりまとめ
- リーガルホールドとは、AWS Backupで取得したバックアップの保持期間を延長する機能
- リーガルホールドが適用されている間は保持期間のカウントを停止する
- リーガルホールドを解除すると保持期間のカウントが再開する
- バックアップがリーガルホールドされてから解除されるまで、保持期間が経過したバックアップの削除を防ぐ
- ユースケースとして以下がある
- 特定のデータの保存
- 監査対応
- 法的手続き
- 電子情報開示の証拠
- リーガルホールド対象のバックアップを選択する際は以下の操作う
- バックアップボールト or リソースタイプの選択
- バックアップの作成日の範囲選択
- リーガルホールドは1アカウントに最大50件設定可能
- 別リージョンや別アカウントにコピーされたバックアップはリーガルホールドの適用範囲外
検証した限り、リーガルホールド中に有効期限を迎えた復旧ポイントは、リーガルホールドを解除しても削除されない- リーガルホールド中は保持期間のカウントが停止するため、リーガルホールド解除後、残りの保持期間が経過すると削除される
リーガルホールドとは
リーガルホールドとは、AWS Backupで取得したバックアップの保持期間を延長する機能です。
バックアップがリーガルホールドされてから解除されるまで、保持期間が経過したバックアップの削除を防ぎます。
A legal hold is an administrative tool that helps prevent backups from being deleted while under a hold. While the hold is in place, backups under a hold cannot be deleted and lifecycle policies that would alter the backup status (such as transition to a Deleted state) are delayed until the legal hold is removed. A backup can have more than one legal hold.
(以下機械翻訳)
リーガルホールドは、ホールド期間中にバックアップが削除されるのを防ぐための管理ツールです。ホールドが設定されている間、ホールド下のバックアップは削除できず、バックアップの状態を変更するライフサイクルポリシー（削除済み状態への移行など）は、リーガルホールドが解除されるまで延期されます。1つのバックアップに複数のリーガルホールドを設定することができます。
ユースケースとしては、特定のデータの保存や監査対応、法的手続き、電子情報開示の証拠が紹介されています。
Q: What is legal hold?
Legal holds, also known as litigation holds, are used when an organization must retain certain data either for preservation, auditing, or as evidence in legal proceedings and e-Discovery. These holds prevent backups from being deleted, even if their retention period is over, and remain in place until explicitly released.
リーガルホールド対象のバックアップを選択する際は以下の操作を行います。
- バックアップボールト or リソースタイプの選択
- バックアップの作成日の範囲選択
選択したものに当てはまる かつ リーガルホールドを設定したタイミングで作成されているバックアップがリーガルホールドの対象となります。バックアップのステータスがEXPIREDやDELETINGのもの、場合によってはCREATINGのものはリーガルホールドの対象外になります。
When a legal hold is created, it contains only recovery points that have already been created. Backups (recovery points) with a status of EXPIRED or DELETING will not be included in the legal hold. Recovery points (backups) with the status of CREATING may not be included in the legal hold, depending on the time of completion.
(以下機械翻訳)
リーガルホールドが作成されると、すでに作成されているリカバリポイントのみが含まれます。ステータスがEXPIREDまたはDELETINGのバックアップ（リカバリポイント）は、リーガルホールドに含まれません。ステータスがCREATINGのリカバリポイント（バックアップ）は、完了時期によってリーガルホールドに含まれない場合があります。
リーガルホールドは1アカウントに最大50件設定可能のようです。リーガルホールドはスポット的な使い方になるので、細かくリーガルホールドの範囲を分類しなければこの上限にひっかかることは少なそうですが、注意しましょう。
また、リーガルホールドはバックアップがあるリージョン単位で適用されます。別リージョンや別アカウントにコピーされたバックアップはリーガルホールドの適用範囲外になります。
ボールトロックとの違いは?
AWS Backupで取得したバックアップの削除の保護の似たような機能としてボールトロックがありますね。
大きな違いとして以下3点あります。
- ボールトロックの適用範囲はバックアップボールト単位のみ
- リーガルホールドはリソースタイプとバックアップの作成日の範囲選択も可能
- ただし、未来のバックアップに対してリーガルホールドを適用することはできない
- ボールトロックのコンプライアンスモードはrootユーザーであっても解除できない
- リーガルホールドはIAMで権限があれば解除できる
- ボールトロックしていてもバックアップの保持期間が経過したものは削除される
バックアップの手動削除はボールトロックで防ぎ、バックアップの自動削除はリーガルホールドで防ぐイメージですね。
やってみた
検証環境
検証環境は以下の通りです。
以下バックアップボールトに対してEC2インスタンスのオンデマンドバックアップを行います。
- リーガルホールドを行うバックアップボールト
legal-hold - リーガルホールドを行わないバックアップボールト
non-legal-hold - ボールトロックを行うバックアップボールト
vault-lock
検証は以下観点で行います。
- リーガルホールドの設定したバックアップを手動で削除できないこと
- リーガルホールドの設定したバックアップが保持期間が経過しても削除されないこと
- ボールトロックの設定したバックアップは保持期間が経過すると削除されること
- リーガルホールドにより保持期間の延長をしているバックアップに対してリーガルホールドを解除した際に、バックアップが削除されること
なお、AWS BackupはS3のライフサイクルポリシーと異なり、バックアップを作成してから指定した時間が経過した後に削除されます。
バックアップの取得
それはバックアップの取得を行います。
いずれも同じEC2インスタンス、保持期間で異なるのはバックアップボールトのみです。
例としてリーガルホールドを行うバックアップボールトへのバックアップは以下のように行います。
3つのバックアップボールトへのバックアップジョブが完了したことを確認します。
ボールトロックの設定
次にボールトロックの設定をします。
ボールトロックしたいバックアップボールトを選択してボールトロックを作成をクリックします。ボールトロックモードはガバナンスモードです。
確認ウィンドウが表示されるのでテキストボックスに確認と入力して、作成をクリックします。
バックアップボールトがボールトロックされていることを確認します。
ボールトロックが効いているか確認するために、バックアップを削除しようとしてみます。復旧ポイントを選択してアクション-削除をクリックします。するとRecovery points cannot be deleted because this Backup vault has an active vault lock.と盛大に怒られました。確かにボールトロックが効いていますね。
リーガルホールドの設定
次にリーガルホールドの設定を行います。
リーガルホールド-リーガルホールドを追加をクリックします。
リソースのタイプがバックアップボールトで、リーガルホールドをしたいバックアップボールトを選択します。日付範囲今日11/29を選択しました。日本時間の11/29 0:00からリーガルホールドの設定作業をしている11/29 9:31までがリーガルホールドの対象と表示されていますね。リーガルホールドを追加をクリックします。
リーガルホールドの設定がされていることを確認します。リーガルホールド対象のバックアップも分かりますね。
2022/11/29時点ではAWS BackupのAPIにはリーガルホールドの更新なるものは存在しないので、リーガルホールドの範囲やリソースを変更したい場合は、解除して設定し直す必要がありそうです。
1. リーガルホールドの設定したバックアップを手動で削除できないこと
リーガルホールドの設定したバックアップを手動で削除できないことを確認します。
リーガルホールドの対象となっている復旧ポイントを選択してアクション-削除をクリックします。
確認画面が出てきました。もしかして削除できてしまうのでしょうか。臆せず確認をクリックします。
すると、Recovery point arn:aws:ec2:us-east-1::image/ami-0ea3fcaf434d19357 cannot be deleted because it has active legal hold(s).とリーガルホールドにより削除ができないメッセージが表示されました。
リーガルホールドは自動削除だけではなく、手動削除も拒否してくれるようです。
2. リーガルホールドの設定したバックアップが保持期間が経過しても削除されないこと
リーガルホールドの設定したバックアップが保持期間が経過しても削除されないことを確認します。
バックアップを取得した翌日の11/30まで待ちます。
リーガルホールドを設定したバックアップボールトを確認すると、復旧ポイントが残っていました。
復旧ポイントの有効期限を確認すると、11/30 8:29 でした。確認した時刻は11/30 13:51なので、確かにバックアップの保持期間が経過しても削除されないことが確認できました。
なお、CloudTrailを確認しましたが、削除しようとして失敗した形跡はありませんでした。削除処理をブロックするというよりも、AWS Backup側で削除対象として扱わないようにしているようですね。
なお、同じタイミングでバックアップを取得した、リーガルホールドをしていないバックアップボールトのバックアップは削除されていました。
3. ボールトロックの設定したバックアップは保持期間が経過すると削除されること
ボールトロックの設定したバックアップは保持期間が経過すると削除されることを確認します。
バックアップを取得した翌日の11/30まで待ちます。
ボールとロックを設定したバックアップボールトを確認すると、復旧ポイントが削除されていました。
CloudTrailすると、バックアップを作成して24時間経過したタイミングでAMIが削除されていました。
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA6KUFAVPU5WGEA46WE:AWSBackup-AWSBackupDefaultServiceRole",
"arn": "arn:aws:sts::<AWSアカウントID>:assumed-role/AWSBackupDefaultServiceRole/AWSBackup-AWSBackupDefaultServiceRole",
"accountId": "<AWSアカウントID>",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA6KUFAVPU5WGEA46WE",
"arn": "arn:aws:iam::<AWSアカウントID>:role/service-role/AWSBackupDefaultServiceRole",
"accountId": "<AWSアカウントID>",
"userName": "AWSBackupDefaultServiceRole"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2022-11-30T00:45:15Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "backup.amazonaws.com"
},
"eventTime": "2022-11-30T00:45:15Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "DeregisterImage",
"awsRegion": "us-east-1",
"sourceIPAddress": "backup.amazonaws.com",
"userAgent": "backup.amazonaws.com",
"requestParameters": {
"imageId": "ami-070a821b8d84b8a0c"
},
"responseElements": {
"requestId": "38c7af6b-bd20-48a9-90b0-23b2007e6321",
"_return": true
},
"requestID": "38c7af6b-bd20-48a9-90b0-23b2007e6321",
"eventID": "ac61e6c1-4ed8-4e6f-af4f-7315b7721dcf",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "<AWSアカウントID>",
"eventCategory": "Management"
}
このイベントの前にBackupDeletedというイベントが記録されていました。バックアップボールトの名前がvault-lockであることからボールトロックをしたバックアップが削除されたことが分かります。
{
"eventVersion": "1.08",
"userIdentity": {
"accountId": "<AWSアカウントID>",
"invokedBy": "backup.amazonaws.com"
},
"eventTime": "2022-11-30T00:45:16Z",
"eventSource": "backup.amazonaws.com",
"eventName": "BackupDeleted",
"awsRegion": "us-east-1",
"sourceIPAddress": "backup.amazonaws.com",
"userAgent": "backup.amazonaws.com",
"requestParameters": null,
"responseElements": null,
"eventID": "0a02339f-7937-457a-97bf-0ba4df7c7f8d",
"readOnly": false,
"eventType": "AwsServiceEvent",
"managementEvent": true,
"recipientAccountId": "<AWSアカウントID>",
"serviceEventDetails": {
"completionDate": {
"seconds": 1669681587,
"nanos": 353000000
},
"state": "DELETING",
"backupVaultName": "vault-lock",
"backupVaultArn": "arn:aws:backup:us-east-1:<AWSアカウントID>:backup-vault:vault-lock",
"recoveryPointArn": "arn:aws:ec2:us-east-1::image/ami-070a821b8d84b8a0c",
"resourceArn": "arn:aws:ec2:us-east-1:<AWSアカウントID>:instance/i-0635a6b53d755a372",
"creationDate": {
"seconds": 1669681524,
"nanos": 263000000
},
"backupSizeInBytes": 8589934592,
"iamRoleArn": "arn:aws:iam::<AWSアカウントID>:role/service-role/AWSBackupDefaultServiceRole",
"resourceType": "EC2"
},
"eventCategory": "Management"
}
4. リーガルホールドにより保持期間の延長をしているバックアップに対してリーガルホールドを解除した際に、バックアップが削除されること
リーガルホールドにより保持期間の延長をしているバックアップに対してリーガルホールドを解除した際に、バックアップが削除されることを確認します。これが行われないとコンプライアンスモードでボールトロックされているバックアップは永遠に削除されないことになってしまいます。
リーガルホールドを選択してホールドを解除をクリックします。
解除の説明を入力してホールドを削除をクリックします。
確認のウィンドウが表示されます。テキストボックスに確認と入力して確認をクリックします。
ホールドのステータスが開放中になり、ホールドされている復旧ポイントが「リーガルホールドのキャンセルが進行中です」となることを確認します。
2分ほど待つとホールドのステータスが解放済みとなりました。
リーガルホールドをしていたバックアップボールトを確認します。すると復旧ポイントが残ったままでした。
10分ほど待ちましたが削除されません。
有効期限が延長されたのかな? と思いきや変わりありません。
リーガルホールド中に有効期限を迎えた復旧ポイントは、リーガルホールドを解除しても削除されないのかもしれません。
2022/12/1 追記ここから
改めてリーガルホールドした復旧ポイントを確認すると削除されていました。
時間列で復旧ポイントの作成や削除、リーガルホールドの設定、解除を整理すると以下のようになります。
- 復旧ポイント作成 : November 29, 2022, 08:29:44 (UTC+09:00)
- ↓2分7秒後
- リーガルホールド設定 November 29, 2022, 09:31:51 (UTC+09:00)
- ↓29時間20分58秒後
- リーガルホールド解除 November 30, 2022, 14:52:49 (UTC+09:00)
- ↓24時間15分21秒後
- 復旧ポイント削除 : December 01, 2022, 15:08:10 (UTC+09:00)
リーガルホールドを解除してから約24時間後に削除されていることが分かります。
以上のことからリーガルホールドの仕様としては以下だと推測します。
- リーガルホールドが適用されている間は保持期間のカウントを停止する
- リーガルホールドを解除すると保持期間のカウントを再開する
「ライフサイクルポリシーを延期する」とドキュメントには記載されていますが、「ライフサイクルポリシーに従って削除することを延期する」ではなく、「ライフサイクルポリシー自体を延期する」という意味合いなのがミソですね。
なお、「保持期間を1日にしたのであれば、復旧ポイント作成してからリーガルホールドを設定するまでの2分を差し引いた23時58分後に削除されるのでは?」と思われるかもしれませんが、こちらはAWS Backupの仕様です。
以下AWS公式ドキュメントに記載されていますが、AWS Backupで取得したバックアップは指定した保持期間経過後ピッタリに削除されるのではなく、最大数時間ズレが発生します。
たとえば、バックアッププランのライフサイクルをリカバリポイントを 1 年間保持するように設定した場合、AWS Backup は、2022 年 1 月 1 日、または 2021 年 1 月 1 日の数時間以内に、作成した復旧ポイントを自動的に削除します。 (AWS Backupは、パフォーマンスを維持するために、リカバリポイントの有効期限後8時間以内に削除をランダム化します。）
2022/12/1 追記ここまで
バックアップを保全したい時に大活躍間違いなし
AWS Backupで取得したバックアップの保持期間を延長するリーガルホールド機能を紹介しました。
バックアップを保全したい時に大活躍間違いなしですね。ボールトロックとの使い分けを意識しながら使っていきましょう。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[レポート]Amazon Redshiftで生成AIのためのデータ戦略を構築 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
