最近ランサムウェアの被害がニュースにでており、被害のあった企業は大きな損害を被っています。ランサムウェア対策ではバックアップを堅牢に保つことが重要であると考えています。
AWS Backupにはボールトロックという機能があります。
これを使うと設定した保持期間はIAMの権限に関係なく消すことができなくなります。
AWS Backupと同じようなバックアップサービスとしてライフサイクルマネージャ（DLM）の存在があります。こちらはデータを世代数でも管理できることと、バックアップ操作が指定した時刻となるためAWS Backupに比べて制御しやすいサービスだと考えています。
AWS Backup、DLMいずれも、バックアップの実態はスナップショットなのですが、DLMにはロックをかける設定項目はありません。代わりに取得したEBSスナップショットにてスナップショットロックという設定をかけることが可能です。
ただDLMで取得したスナップショットをいちいち手動でロックをかけていくのは、現実的ではないのでDLMで取得したスナップショットの自動的にロックする仕組みを考えます。
ここから今回の目的であるKiroを使っていきます！
まずは以下のように要件を整理しました。
目的
ライフサイクルマネージャで取得したバックアップのスナップショットロックの設定自動化
要件
・DLMで取得したAMIやEBSスナップショットを指定した日数でスナップショットロックを設定したい。DLMで取得後にスナップショットを設定するジョブが起動するイメージ。
・AMIの場合はAMIに紐づくEBSスナップショットすべてにスナップショットロックを適用。
・DLMが世代数または保持期間でデータを保持するため、世代数または保持期間から外れた際にDLMが削除できるようにスナップショットロックの保持期間を設定する。
・スナップショットロックのロックモードはガバナンスモードを指定。
・汎用的に実装が可能となるように、Cloudformationで実装できるようにする。
kiroには要件定義から実装まで一連の流れをこなすSPECと呼ばれるチャット機能がついています。
早速上にあげた要件を打ち込んでみます。
数分すると
要件定義書がでてきました。
要求事項については英文だったので、copilotに日本語で要約してもらいました。
要約（日本語）
この要件は、AWSのDLM（Data Lifecycle Manager）で作成されたAMIやEBSスナップショットに対して、自動的にスナップショットロックを適用し、データ保護とライフサイクル管理を両立する仕組みを定義しています。主なポイントは以下の通りです。
スナップショットロックの自動適用
DLMがAMIやEBSスナップショットを作成した際、自動でロックを適用
ガバナンスモードを使用し、保持期間はDLM設定と整合性を取る
DLMによる正当な削除を妨げない仕組み
CloudFormationによるデプロイ対応
CloudFormationテンプレートでシステムを構築可能
パラメータでロック期間やDLMポリシー連携を設定
スタック更新時にデータ損失がないこと
カスタムロック期間の設定
スナップショット種別ごとに保持期間を柔軟に設定可能
DLMポリシーとの整合性を検証し、競合時は警告と安全なデフォルト値を使用
ログと監視の強化
ロック操作の詳細ログ（タイムスタンプ、リソースID）
エラー時の詳細記録、CloudWatch連携による監視・アラート
成功/失敗のメトリクス提供
ログと監視強化までは要件にはいれていませんでしたが、しっかりと要件定義書に入っています。
Kiroから問題なければ設計フェーズに進むかと聞かれているので、このまま次に進みます。
続いて設計フェーズのドキュメントがでてきました。（こちらも数分です）
アーキテクチャ
この設計書によるとDLMが動いた際にEvenbridgeで検知し、Lambda関数からスナップショットロックのAPIを呼び出す流れとなっています。
さらに利用するサービスごとに設計内容が記載されています。
こちらも問題なさそうなので続いて実装計画に進んでみます。
実装計画に進むと実装計画の特徴とタスクの構成についての説明があり、実際のタスクのドキュメントが作られています。
タスクを進めるにあたり、コア機能の実装のみ進めるか、オプションも含めたすべてのタスクを実行するか選択できるようです。
今回オプションは保持したまま進みます。
タスクリストのドキュメントを開き、「Start task」をクリックするとタスクが実行されます。
以下のようにTask1の内容が進んでいきます。
途中、デプロイのためスクリプトに実行権限を付与しようとしますが、私の環境がWindowsのため失敗します。
あとで自分のAWSアカウントに入って、cloudshellから実行するのでいったんこちらはそのまま進めます。
しばらくするとTask1が完了し、次の成果物ができました。
Task1ではディレクトリ構成やcfnテンプレート、lambda関数、readmeなど、このアプリケーションの全体像が作られているようなイメージです。
続けてTask2を実行してみます。Task2ではさらにlambdaの処理を追加しているようです。
続いてTask3です。Task3ではsnapshot lockに関する実装となります。
続いてTask４
実行途中にまたしてもpythonのコマンド実行がでてきたので、microsoft storeからpythonをインストール。
いったんkiroを閉じて再度開いてみるとTask実行がabortしていましたが、隣にretryがあったので
Retryしてみます。
Task4も無事成功です。
ようやく半分まで来ましたが、まだまだ続きます。続いてTask5にまいりましょう。
Task5は最初に伝えていなかったログと監視についてですね。
途中pytestコマンドで何度か確認するのですが、失敗すると失敗原因を調査してコードを修正し再度テストを繰り返す動きをします。
Task5も完了！
次はTask6、Cloudformationのテンプレートについての実装です。
Cfnは形式がきまっているのかあっさり終わりました。
続いてTask7はオプショナルなのでTask8を実行します。
Task8ではテストとなっています。
途中エラーがでたりしますが、すべて必要な解決策を自分でこなしながら完了までもっていきます。
続いてTask9にうつります。
と思ったらCreditsが残り20%以下なのでPlanのUpgradeをすすめられました・・・
フリープランだと厳しいですね。
もう少しこのまま粘ります
何とかTask9も完了しました。Task9はCloudformationのデプロイガイドになります。
この時点であと6Creditです・・・
最後のタスクいってみましょう
途中でCreditがつきてしまいました・・・
Creditは毎月1日にまた戻るようですが、FreePlanではちょっと力不足ですね。
Proだと1000Creditですが、今回のペースを考えると1000でもすぐに使いきってしまいそうです。
ちなみにProプランは$20です。ただ月に$20払ってここまで自律的に作業してくれる助手がいると思えばはるかにコストメリットは大きいのではと思います。
今回は実際に成果物を動かせていないのでKiroがどれぐらい使えるのかはっきりとはいえませんが、
自分のやりたいことを伝えるだけで要件定義～実装までこなす力はやはり凄いと言わざるを得ません。
これまで人が時間をかけてきたことが数分でできてしまう。これからは本当にいい道具を使っていかに早くサービスを提供できるかが生き残るための鍵ではないかと今回の検証を通して感じさせられました。
今回の続きはまた1月にやりたいと思います。