今回はシンプルなLambda。
今秋のre:InventでアップデートされたScheduled Eventを利用して、AMIバックアップをとるファンクションを作成しました。
仕様
仕様は以下のような感じ。
- AMIバックアップをとりたいEC2に、タグ’Backup–Generation : 世代数’を設定しておく
- ‘Backup-Generation’には、保持したい世代数を設定する
- AMIおよびSnapShotには、元となるEC2のタグ群()を設定する ()Backup-Generationを除く
- LambdaのScheduled Eventをトリガーに実行する
- AMI取得後、本ファンクションで作成したAMIのうち、保持したい世代数よりも古いイメージおよびスナップショットを削除する
- ファンクションで作成したAMIを区別するため、AMIおよびsnapshotにタグ’Backup-Type : auto’を付与する
EC2設定
まずは、EC2にタグ付け。
ここでは、２世代のバックアップをとることとします。
Lambdaファンクション
次は肝心かなめのLambdaファンクション。
コード
コードは、長くなるのでQiitaを参照ください。
AMIバックアップを取るLambdaファンクション（python） – Qiita
IAM Role
roleには以下を設定しています。
- AmazonEC2FullAccess
- AWSLambdaBasicExecutionRole
Event Source
毎朝２時に設定しました。
公式ドキュメントがわかりやすいです。
結果
こんな感じで、意図通り動いていそうです！
まとめ
EC2と1ヶ月のコスト比較をしてみます。コストは超概算ですので悪しからず。
EC2(*)の運用コストは以下です。
(*) 東京リージョン、オンデマンド、t2.micro、Linux
0.02 (/hr) * 24 (hr) * 31 (days) = $14.88 / 月
Lambda(*)の運用コストを計算してみます。
(*) 東京リージョン、128MB
リクエスト回数は誤差の範囲になるので無視します。
実行時間は上述のログから引っ張ってきました。
0.000000208 (/msec) * 43,889.93 (msec) * 31 (days) = $0.283 / 月
コストはなんと、52分の1に！！
Lambdaは今のところ無料枠に期間制限がないので、こちらも考慮すると更なるコスト削減になるかもです。
可用性のメリットもお忘れなく！
Scheduleイベントを使うことで、バッチ処理的に使っていたサーバーを捨てることができそうです！
今回はさらっと作ったLambdaファンクションですが、wait処理をSNSとかで無駄時間を減らすよう改善していきたいところです。
