はじめに

以前にSAAの資格勉強をしていたときにAWS Backupを曖昧にしか理解していなかったので今回実際に使ってみました。

AWS Backupとは

AWS Backupは、簡単に言ってしまえばAWSクラウド上で複数のサービスに分散しているバックアップを一元管理するためのサービスです。

フルマネージド型のバックアップサービスであり、AWS のサービス、クラウド内、およびオンプレミス間で簡単に一元化およびデータ保護を自動化できます。このサービスを使用すると、1 つの場所でバックアップポリシーを設定し、AWS リソースのアクティビティを監視できます。ー公式ドキュメントよりー

その他バックアップサービス

種類	概要
DLM (Data Lifecycle Manager)	・データのライフサイクルを管理するためのサービス。 ・S3バケットやEBSスナップショットやAMIなどのAWSリソースに適用。 ・リソースのライフサイクルを自動的に管理し、コストを削減が可能。 ・スケジュールに基づいてデータを削除することもできます。
AWS Backupとの比較	・この2つはともにバックアップのライフサイクル管理が可能ですが、指定方法が異なります。 DLMはスナップショットを何個残すか指定し、AWS Backupは各スナップショットをどれだけの期間残すか指定。

RDSのバックアップ機能	・データベースインスタンスの完全なスナップショットを作成する自動バックアップ機能。 ・手動でのスナップショット作成や、スナップショットの保持期間なども設定可能。
AWS Backupとの比較	・RDSバックアップは対象がRDSのみになりますが、AWS BackupにRDSのみならず、EC2やEFSなど他サービスも対象。 ・RDSのバックアップは同一のリージョン内にバックアップを取りますが、AWS Backupに関しては異なる複数のリージョンにてバックアップが可能です。

※スナップショットとAMIの違い
スナップショットはディスクのバックアップを行いますが、AMIは構成管理情報＋スナップショットを含めております。
またスナップショットの料金に関してですが例えば７日分スナップショットを作成した場合
→差分がなければスナップショットがいくつあろうが、７日分でも料金は１日分とは変わりません。

今回の目的

実際にAWS Backupを使用してEC2のバックアップを取得しているのかを確認します。
ユースケースとしては誤削除や障害時にEC2が削除されてしまったときにAMI(マシンイメージ)としてのバックアップを作成することによってわざわざEC2の設定を一からし直さなくてもテンプレートとしてEC2を作成することが可能になります。

構成

①EC2を作成。同時にindex.txtファイルを格納。
(→後々、【1】事前に作成したEC2と、【2】AWS Backupにて作成されたAMIより起動したEC2が同様のものか確認するため。)
②AWS Backupの設定項目を行い、対象をEC2に設定。
③マネジメントコンソール上にて実際に対象のEC2のバックアップが取れているかAMIを確認。
④作成したAMIより実際にEC2を起動し、元の格納されているindex.txtファイルを確認する。

構築手順

今回はEC2とAWS Backupの作成のみとシンプルな構成となります。

①事前準備

まずはEC2のバックアップを取ってみるため事前にEC2用のSG(セキュリティグループ)とEC2の作成をします。
今回はテスト用として「kudo-backup-test-EC2」としました。

また今回の検証として実際にAMIから起動したEC2が元のEC2と同様のものが起動できているか確認するため
事前に「hello!」という index.txtファイルを格納します。

そのためEC2のSG上のインバウンドルールには「SSH(MYIP)」のみ許可したものを作成してください。
SG・EC2作成後にSSH接続を行い、下記コマンドにてindex.txtファイルを格納します。

txtファイルの追加

 vi /home/ec2-user/index.txt

hello!
(「hello!」と入力し:wqで保存して終了)

以上にて事前準備は完了です。

②「バックアッププラン」と「バックアップルール」を作成。

続いてバックアッププランを作成していきます。
バックアッププランは「どのように」バックアップするかを定義します。

また同時にバックアップルールを作成していきます。
バックアップルールは「いつ」バックアップを行うかの設定を行います。
また同時にバックアップの頻度、コールドストレージへの移行なども設定できます。
スケジュールの頻度に関しては短時間の検証も兼ねているため毎日にしました。
以下項目の設定になります。

AWSサービスより「AWS Backup」→「バックアッププランを作成」。

設定	項目
バックアッププランのオプション	新しいプランを立てる
バックアッププラン名	kudo-backup-test(任意の名前)
バックアップルール名	kudo-backup-test-rule(任意の名前)
バックアップ期間	バックアップ期間をカスタマイズ
バックアップ期間の開始時間	17:10(任意の時間)
次の時間以内に開始・完了	１時間（検証結果を早く知りたいので設定）

※他はデフォルトで設定。
これでバックアッププランの作成は完了です。

画像のように表示されれば設定完了です。

③「バックアップリソースの追加」を作成

続いてはバックアップリソースを追加していきます。
「何を」バックアップするかの設定です。今回はEC2を見たいのでEC2を対象に設定していきます。
「AWS Backup」→「バックアッププラン」→「リソースの割り当て」を選択します。

設定	項目
リソース割り当て	kudo-test-backup(任意の名前)
IAMロール	デフォルトのロール
リソース選択を定義	特定のリソースタイプを含める
特定のリソースタイプを選択	リソースタイプ：EC2 インスタンスID:事前に作成したEC2を選択

※他はデフォルトで設定。

こちらも画像のように「バックアッププラン」上にて確認でできます。

これでリソースの割り当ても完了です。

後は実際に指定したスケジュールにのっとってEC2のバックアップが取れているのか確認していきます。

④動作確認

「AWS Backup」のメニュー欄より「バックアッププラン」→「ジョブ」より指定した時間になるとジョブが動き出すことを確認します。

今回は PM 17:10 から 1時間以内 に指定しましたが、実際に完了したのは PM 17:38 でした。

最後にEC2のバックアップを確認します。

3/20 17:10に毎日ジョブを開始するように設定していたので現時点（3/22午前中）では
2日分である3/20・3/21 17:10分が記録されています。

今回の検証としてはEC2を対象にバックアップしました。
同様にAMI(マシンイメージ)が作成されてるかの確認もAWSサービス上の「EC2」よりしていきます。

EC2のバックアップを行う利点としては誤削除や障害時にEC2が削除されてしまった場合に
AMIとしてバックアップが取れることです。

無事にAMIが作成されていることも確認できました。
上記のようにAMIが作成されているので削除時には「AMIからインスタンスを起動」よりバックアップが可能です。

⑤EC2の起動

最後に最初に作成したEC2内に「hello!」というindex.txtファイルを作成したので
AMIから起動するEC2上でも同様のindex.txtファイルが格納されているか実際に確認していきましょう。
AWSサービスの「EC2」→「AMI」→「AMIからインスタンスを起動」

AMIより作成した2つ目のEC2は「kudo-backup-test-EC2(2)」としました。
「インスタンスを起動」より実際にEC2を起動していきます。

実際に「kudo-backup-testEC2(2)」が「実行中」になりました。

無事EC2の作成が完了したら、SSH接続し、格納されているindex.txtファイルを確認します。
catコマンドでファイルを確認しましょう。

cat /home/ec2-user/index.txt

「kudo-backup-testEC2(2)」上にて「hello!」のindex.txtファイルを確認することができました。
AWS BackupによりしっかりEC2のバックアップが取れていることが確認できました。
これにて検証は終了です。

最後に

SAAの資格勉強時に用語としては認識していたのですが、どのような動作を行い、どのような利点があるかまでは認識していませんでした。実際の経験として私自身、不備が起こるたびにEC2を削除しては一から設定していました。本当に便利な機能だと実感でき、より理解を深めることができました。