はじめに

　AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 23 日目です。

　今回は EIPの解放を見落として予想外の請求を受けた話 を書いていきます。

やっていたこと

　ながらくほぼワンマンでやりくりしていた私の部署にも、ようやく新しい人がきてくれました。その方は AWS にほとんど触れたことがなかったので、じゃあまずは検証アカウントで一通り作業を経験してみよう！ということになり、EC2 + RDSという簡単な環境の構築をお願いしました。EC2 には wordpress がインストールされており、関連付けた EIP でアクセスをするとトップページが表示される想定です。

　最終的に、作成したリソースは下記の通りになりました。

VPC
サブネット
EC2
EIP
RDS
各種セキュリティグループ

　紆余曲折ありながらも無事に wordpress が表示されるところまで構築をすることができたため、終わり際に「今回作成したリソースは、しばらくは残しておいて大丈夫ですが、もう使わないなと思ったら削除をお願いしますね」ということを伝えました。その際、削除時の目視をお願いされたため、いくつかのリソースについてはコンソール上から削除するところまでを見届けました。

結果

　検証環境のコストが数十ドル単位で爆増しました。当初は「検証のためにちょっとたくさんリソースを作成したからかな…」と思っていたのですが、そのうち削除したリソースのコストが今も上がり続けるわけはないということに気が付き、調べてみると大量の EIP が放置されていることに気が付きました。

　CloudTrail のログを探り、どうやらあの時の検証で作成した EIP だな、ということがわかったので本人に確認をしてみると、

うまく接続できないので最初からやりたい → 新しいEIP取得
ネットワークの設定を変更したい → 新しいEIP取得
コンソールがごちゃごちゃしてきたのでまたやり直したい → 新しいEIP取得

　という感じに何度かリソースを作り直していたようで、その時の EIP が放置されてしまっている状態でした。

何を考えていたのか

　ひとえに確認不足でした…。
　EIP は RDS や EC2 等とは違い EIP というサービスが独立してあるわけではないので、リソースを削除する際に見落としがちです。あまり AWS へ触れたことがない人は特にわからないと思います。その辺りを考慮できていませんでした。

　また料金形態についても、EIP は EC2 等に関連付けられていない方が料金がかかる、ということももう少しきちんと周知していれば、今回の件は起こらなかったと思っています。

まとめ

　EIP は他のサービスと比べて独立性が高く、「EC2 を削除すれば EIP も一緒に削除される」と思い込んでしまいがちです。

課金が発生するリソースを明確に伝える
「見えにくいリソース」の存在を周知する
実際の削除作業を最後まで一緒に確認する

　もう少しこちらを徹底しておけばよかったな…と、今になって思います。

　また、AWS は基本的に従量課金制なので、使わないリソースは即座に削除という意識を持つことが重要だと改めて思いました。