ちょっと気になる事象があったので番外編です。
【2019/10/17 追記】
比較的見てくださってる方がいそうなので追記しておきました。もし少しでもためになった方がいたら幸いです。内容的には事象によっては対応①と②までで問題ないというものです。
事象
8月に入ってからEC2は一度も起動していなかったのですが（サボりすぎですねはい）、ワンタンポーリング（請求ダッシュボードを定期的にみる）によりEC2のEBSの無料枠が消費されていることを検知しました。
増加傾向から、このまま放置しても無料枠からはみ出すことはないと予想されますが勉強したいときにビクビクしながら使用するのもいやなので消費をとめられないかということです。
キャプチャにも載せていますが具体的には以下の通りです。
| Amazon Elastic Compute Cloud | 1 GB of Amazon Elastic Block Storage snapshot storage | 13.27%(0.13/1 GB-mo) |
|---|---|---|
| Amazon Elastic Compute Cloud | 30 GB of Amazon Elastic Block Storage in any combination of General Purpose (SSD) or Magnetic | 10.29%(3.09/30 GB-Mo) |
原因調査と対応
まだ緊急事態ではないので、ふんわりと調査した。
この辺が実務経験や本格的に学んだことがないのが痛いところ。正直よく分からない。
一応確認したが、もちろんインスタンスは停止されていた。
どうも、インスタンスを生成したAMIがスナップショットは自動で取得されて、EBSに保管されてその分の容量を食うとかとかなんとか。理解が違うかもしれません
対応①AMIの登録解除
スナップショットとかとった覚えもないし設定した覚えもないのほんとにあるの？？
ということでまずはスナップショットの確認。
サービスからEC2を選択すると確かにスナップショットがありました。
とりあえずスナップショットを選択しアクションから削除を実行してみる。
しかし、削除できない。
snap-0d0bd6b627f299456: The snapshot snap-0d0bd6b627f299456 is currently in use by ami-0cbc282bf9cff0594
AMIで使用しているからだめってことでしょうか。
次にAMIに向かいます。どうせ大したことしてないから復元できなくてもいいでしょぐらいの気持ちで、アクション＞登録解除。
登録解除できました。
非常に無知ですが、AMIの登録解除=削除になるんですね。
ちなみにここで削除したのは以下の記事でELBを試すために作成したカスタムAMIです。
うーん、これでどうなるか分からないからとりあえず放置しました。
対応①の経過観察
対応①から数日後です。
請求ダッシュボードを確認すると、まだ増えてますね。
| Amazon Elastic Compute Cloud | 1 GB of Amazon Elastic Block Storage snapshot storage | 17.70%(0.18/1 GB-mo) |
|---|---|---|
| Amazon Elastic Compute Cloud | 30 GB of Amazon Elastic Block Storage in any combination of General Purpose (SSD) or Magnetic | 11.72%(3.52/30 GB-Mo) |
対応②スナップショットの削除
今度は実際にEBSに保管されていると思われる。スナップショット自体を削除してみます。
手順は上記で失敗した手順通りでこちらも躊躇なく削除。
今度は削除できたようです。
やっぱりどうなるか分からないのでとりあえず放置してみる。
対応②の経過観察
対応②のまた数日後。
あれ？？むしろ加速してないですか？？
このままいくと月末に100%超えると言われているし。。。
ちょっと考えものですね
【2019/10/17 追記】
以降の月でも似たような事象が発生しましたので今後は様子を見ながら対応しました。
もしも増え続けているのが以下であればここまでの対応で大丈夫です。
・1 GB of Amazon Elastic Block Storage snapshot storage
見れば文字の通りですが、原因はスナップショットだからです。
つまりこれが増えていて不安な場合はカスタムAMIを削除⇒スナップショットを削除すればそこで止まります。以下に続く対応③のインスタンスボリュームの削除はやりすぎでした。
カスタムAMIを一個つくっただけで無料枠超えそうになるのはどうなの？って感じもありますが、無力枠利用でいく場合はカスタムAMIは使用したら削除の運用を徹底した方が安心して使えそうです。
対応③インスタンスボリュームの削除
【2019/10/17 追記】
上記にも追記しておきましたが、「1 GB of Amazon Elastic Block Storage snapshot storage」の増加を止めたい場合は対応③は不要です。それでもやる場合は復旧できなくなるので注意です。
ちゃんと調べないのが悪いんですけどこの辺ですかね
インスタンスに接続されている EBS ボリュームの場合、インスタンスを停止したとしても、情報の保持と料金の発生は継続されます。
EBS 関連の課金を停止するには、要らなくなった EBS ボリューム と EBS スナップショット を削除します。
ボリューム自体は前回対応時からあったようですが、以前から「in-use」だったのかは不明です。
どこまでやると何ができなくなるのか正直分かってないですが、停止中のインスタンスにボリュームがアタッチされているっぽいのでデタッチで引っぺがしてみます。
デタッチはできたようですね。
よし削除してみよう。
ボリュームも削除しちゃいました。
ここからまた放置ですね。
対応③の経過観察
約１日後、請求ダッシュボードを確認。
ああ、止まっている。とりあえず事態は解決しました。
しかしながらディスクにあたるボリュームを削除してしまったので当然ながらインスタンスは起動できなくなっています。
Invalid value 'i-07926837e618b4743' for instanceId. Instance does not have a volume attached at root (/dev/xvda)
そして、スナップショットも削除してしまっているのですぐに復旧もできないです。
まとめ
なんとか無料枠の消費はとめることができました。（今後も監視は続けますが）
完全にとめるためには、EBSにあるスナップショットとボリュームを消せば安全なんじゃないでしょうか。
ただ少し焦っていたとは言え、全てを完全に削除してしまったのは少し後悔です。
手順は残してあるのですぐに同様のものは構築しなおせそうですが、環境を構築するたびに完全に削除しなきゃいけないっていうのも不便すぎるので、もう少し理解して学習を楽しみたいものです。
サイズ的には「ボリューム ＞ スナップショット」らしいのでスナップショットだけ残しておくとかもありだったかもしません。
ボリュームをデタッチした段階での無料枠の消費挙動の観察もしていないですし、私の場合はインスタンスは３つあったので、一つのボリュームだけを残しておいて挙動を見てみるとかもやるべきだったかもしれません。
一つのインスタンスを停止して、そのボリュームを残した状態で放置して無料枠をはみ出るというのは少し考えにくいですしね。
完全に無料枠内で楽しみたい場合、ELBを試すときには複数のインスタンスを使用すると思うので放置する場合にも注意が必要なのかもしれません。
今後もEC2は確実に使用するので、理解しながら学習を進めていきたいと思います。
