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分ほどで完了しました。便利ですね～。
今回は以下の二つを確認してみたいと思います。
スタックを作成した後、コンソール上でALBのセキュリティグループを編集してインバウンドルールを追加してみます。その後オンデマンドバックアップを実行し、リストアしたらどうなるかを検証します。
コンソール上でインバウンドルールを変更した後ドリフト検出を行い、ドリフトステータスが「DRIFTED」であることを確認します。
結果はコンソール上の設定変更は反映されず、スタック作成時の状態になっていました。
もしコンソール上の設定変更も復元できたら便利だったと思いますが、IaCの原則に則ると本来パラメータ修正はコード上で行うべきなので、この挙動は理にかなっているとも言えます。
結論から言うと、自動でリストアはされません。S3などのステートフルコンポーネントを含むスタックをバックアップすると、ネストされたバックアップジョブとして、そのステートフルコンポーネントのリカバリポイントが作成されます。
スタックのリストアを行うと、設定を保持した空のステートフルコンポーネントが作成されるので、そのリソースにS3のリカバリポイントからリストアすることで復元できます。
オンデマンドバックアップを作成するときに以下のエラーメッセージが出力されました。
Resource type is not opted in. Opt in to the resource type using update region settings.
このエラーはBackupの対象サービスでCloudFormationを有効にしていないことが理由で発生するものなので、以下の手順を踏む必要があります。
私自身IaCはTerraformしか経験がなかったのですが、CloudFormationを採用している場合、スタック単位で単一のリカバリポイントを得られるのはもしかしたらメリットがあるかもしれません。
最後までお読みいただきありがとうございました。