はじめに
6月に中途入社しましたクラウドインテグレーション部の秋山です。
最近AWS Backupのドキュメントを眺めていたところ、CloudFormationがサポート対象に含まれているのを発見しました。CloudFormationとはAWSのリソースをコードで管理、つまりIaCを実現するサービスです。IaCでインフラを管理する場合、インフラの復元が必要になった際はソースコードを使って再プロビジョニングを行うという認識だったのでCloudFormationスタック自体をバックアップするということに疑問を持ち、改めて調査しました。
※機能自体は2022年からリリースされているようです。
バックアップで保護するリソース
システムにおいてどのリソースをバックアップ対象とするかは、主に非機能要件によって決定されます。以下のAWSの公式ブログでは、バックアップ対象となるリソースの性質を以下のように分類しています。
| ステートフルコンポーネント | データベースやファイルシステム |
|---|---|
| ステートレスコンポーネント | コンテナやネットワーク設定 |
ステートフルコンポーネントであるリソース（S3、RDS、DynamoDBなど）は、ほぼすべてAWS Backupによってサポートされています。CloudFormationでスタックをバックアップすると、ステートレスコンポーネントの構成情報を含めてバックアップすることができます。ステートレスコンポーネントにはバックアップストレージの料金がかかりません。
実際に動かしてみる
ALB、ECS、S3をCloudFormationで作成します。
テンプレートの作成はAmazon Q CLIを使って5分ほどで完了しました。便利ですね～。
今回は以下の二つを確認してみたいと思います。
- スタックの管理下にあるリソースをコンソール上で編集した場合にバックアップに反映されるか
- スタックの管理下にあるS3にアップロードしたファイルはバックアップに反映されるか
スタックの管理下にあるリソースをコンソール上で編集した場合にバックアップに反映されるか
スタックを作成した後、コンソール上でALBのセキュリティグループを編集してインバウンドルールを追加してみます。その後オンデマンドバックアップを実行し、リストアしたらどうなるかを検証します。
コンソール上でインバウンドルールを変更した後ドリフト検出を行い、ドリフトステータスが「DRIFTED」であることを確認します。
検証結果
結果はコンソール上の設定変更は反映されず、スタック作成時の状態になっていました。
もしコンソール上の設定変更も復元できたら便利だったと思いますが、IaCの原則に則ると本来パラメータ修正はコード上で行うべきなので、この挙動は理にかなっているとも言えます。
スタックの管理下にあるS3にアップロードしたファイルはバックアップに反映されるか
結論から言うと、自動でリストアはされません。S3などのステートフルコンポーネントを含むスタックをバックアップすると、ネストされたバックアップジョブとして、そのステートフルコンポーネントのリカバリポイントが作成されます。 
スタックのリストアを行うと、設定を保持した空のステートフルコンポーネントが作成されるので、そのリソースにS3のリカバリポイントからリストアすることで復元できます。
詰まった個所
オンデマンドバックアップを作成するときに以下のエラーメッセージが出力されました。
Resource type is not opted in. Opt in to the resource type using update region settings.
このエラーはBackupの対象サービスでCloudFormationを有効にしていないことが理由で発生するものなので、以下の手順を踏む必要があります。
- AWS Backupのコンソール画面から「設定」を選択。
- サービスのオプトインでCloudFormationを有効にする。
調べてみて
私自身IaCはTerraformしか経験がなかったのですが、CloudFormationを採用している場合、スタック単位で単一のリカバリポイントを得られるのはもしかしたらメリットがあるかもしれません。
最後までお読みいただきありがとうございました。
