AWS Back Up を使用してEC2インスタンスとAuroraのバックアップを構築した

# 前書き
[AWS Back Up](https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/whatisbackup.html)を活用して、[EC2](https://docs.aws.amazon.com/ja_jp/ec2/?icmpid=docs_homepage_featuredsvcs)と[Aurora](https://docs.aws.amazon.com/ja_jp/rds/?icmpid=docs_homepage_databases)のバックアップ環境を構築しました。本記事では、その具体的な構築手順について解説します。


# AWS Back Upの概要
- `AWS Backup`はAWSのデータを自動で保護する為のサービス
- バックアップの管理やスケジュール設定が簡単に調整可能
- 異なるリージョンやアカウント間でバックアップをコピーできる
- コスト削減のためのライフサイクルポリシーが使える
- タグを活用して特定のリソースだけバックアップ可能
- 監査とレポート機能でデータの追跡と管理が容易

## バックアップボールト
- バックアップデータを安全に保存する為の場所
- ボールト内のデータは[AWS KMS](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/overview.html)で暗号化され、セキュリティが強化されている
- 複数のAWSサービスのバックアップを一元管理できる
- [アクセス制御ポリシー](https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/security-iam-awsmanpol.html)を設定する事で、バックアップへのアクセス制限を細かく設定出来る
- [ボールトロック](https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/vault-lock.html)機能でデータを改ざんや削除から保護出来る

## AWS Backupのボールトロック
- バックアップデータを改ざんや削除から守る為の機能

設定出来る項目は、下記に記載
- ガバナンスモード: 権限を持つユーザーであれば　、ロックを解除する事が可能
- コンプライアンスモード: ロック後、変更・削除の操作が不可能となる。猶予期間中のみロックの解除が可能
- WORM機能: データを一度書き込むと、読み取りのみが可能
- セキュリティ強化: 特権ユーザーでもデータを早期削除できない

# 構築手順
## 基本の構築
- 本記事では、複製先のリージョンに、大阪リージョンを選択している
- 複製先のリージョンにボールトを構築する為、大阪リージョン用の`Terraform`環境を準備している
- 複製先の`Terraform`環境の`provider`ファイルに、複製対象のリージョンを記載している

```providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.81.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-3"
}
```


## ボールとの構築
- 他リージョンにバックアップを行う場合、対象リージョンにもボールトを構築する必要がある
- 下記は、東京リージョン用のボールト
```backup.tf
resource "aws_backup_vault" "backup" {
  name        = "tokyo_vault"
  kms_key_arn = "arn:aws:kms:東京リージョン名:アカウントID:key/東京リージョンのKMS_ID"

  tags = {
    # 任意で設定
  }
}
```

- 下記は、大阪リージョン用のボールト
```backup.tf
# 
resource "aws_backup_vault" "backup" {
  name        = "osaka_vault"
  kms_key_arn = "arn:aws:kms:大阪リージョン名:アカウントID:key/大阪リージョンのKMS_ID"

  tags = {
    # 任意で設定
  }
}
```

## プランの構築
- `copy_action`は、他リージョンにもバックアップを構築する場合のみ必要
```tf
resource "aws_backup_plan" "backup" {
  name = "backup-plan"
  rule {
    rule_name                = # 任意の名前
    target_vault_name        = aws_backup_vault.backup.name
    start_window             = 60
    completion_window        = 360
    enable_continuous_backup = false
    schedule                 = # クーロン方式で設定を行う
    lifecycle {
      cold_storage_after                        = 0
      delete_after                              = 7
      opt_in_to_archive_for_supported_resources = false
    }

    # 大阪リージョに複製
    copy_action {
      destination_vault_arn = "arn:aws:backup::アカウントID:backup-vault:大阪リージョンに作成したボールト名"
      lifecycle {
        cold_storage_after                        = 0
        delete_after                              = 7
        opt_in_to_archive_for_supported_resources = false
      }
    }
  }
}
```

### aws_backup_plan内で使用しているメソッドと説明

| メソッド | 説明 |
| :-: | - |
| start_window | バックアップの開始許容時間を分単位で指定する。今回の設定では、60分以内にバックアップを開始する |
| completion_window | バックアップの完了許容時間を分単位で指定する。今回の設定では、360分以内にバックアップを完了する |
| enable_continuous_backup | 継続的バックアップを有効にするかどうかを指定する。`false`の場合は、スケジュールに基づいたバックアップのみを実行する。`true`に設定する事で、`RDS`や`DynamoDB`など一部のサービスで継続的バックアップを有効にする事が可能 |
| schedule | バックアップのスケジュールをCron形式で指定する |
| cold_storage_after | バックアップデータをコールドストレージに移行するまでの経過日数を指定する。必要に応じて指定日数を増やす事で、頻繁にアクセスするデータをホットストレージで保持する事が可能 |
| delete_after | バックアップデータを削除するまでの日数を指定する。必要に応じて期間を延長する事で、バックアップ保持期間を長く設定する事が可能 |
| opt_in_to_archive_for_supported_resources | 対応リソースのアーカイブオプションを有効化するかを指定する。`false`の場合、アーカイブは無効化される。`true`に設定する事で、アーカイブを有効にし、低コストの長期保存が利用可能 |
| copy_action | バックアップデータを別リージョンや別ボールトに複製するアクションを指定する。他のリージョンやボールトを指定する事が可能 |
| lifecycle（copy_action内） | 複製データのライフサイクルを設定する。元データとは異なるライフサイクルを指定する事が可能。コピー元と異なる設定をする事で、コストや保存要件に合わせた管理が可能 |

## セレクションの構築
- `Back Up`の際に必要なロールがある為、以下の公式ドキュメントを参考にし、事前に構築しておく
    - [Default service role for AWS Backup](https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/iam-service-roles.html#default-service-roles)
    - [Creating the default service role in the console](https://docs.aws.amazon.com/ja_jp/aws-backup/latest/devguide/iam-service-roles.html#creating-default-service-role-console)
```tf
resource "aws_backup_selection" "backup" {
  name          = # 任意の名前
  plan_id       = aws_backup_plan.backup.id
  iam_role_arn  = # Back up用のロールのarnを記載
  # デフォルトのロールを使用する場合は、AWSBackupDefaultServiceRoleのarnを記載する

  # Auroraの場合の記述(複数記述可能)
  resources     = [
    "arn:aws:rds:リージョン:アカウントID:cluster:Auroraのクラスター名",
  ]

  # EC2の場合の記述(複数記述可能)
  resources = [
    "arn:aws:ec2:リージョン:アカウントID:instance/i-0a*************h8",
    "arn:aws:ec2:リージョン:アカウントID:instance/i-ab*************0a"
  ]
}
```

# 参考資料
- [TerraformでAWS Backupを作成して、　EC2の自動バックアップを行う](https://note.com/minato_kame/n/na29e0d98520f)
- [AWS Backup で Amazon EC2 インスタンスをバックアップする構成を Terraform で構築する](https://kakakakakku.hatenablog.com/entry/2023/09/06/201331)

# まとめ
今回は、[DR（ディザスタリカバリー)](https://www.ntt.com/bizon/glossary/e-d/disaster-recovery.html)環境を構築する為にAWS Backupを使用しました。復元方法が簡単で操作も比較的容易な為、何か問題が発生した際に非常に便利な機能だと思います。ただし、`RPO`（目標復旧時点）と`RTO`（目標復旧時間）の間隔を極限まで短くしたい場合には、AWS Backupでは対応が難しい為、その点は課題があると感じました。