EC2停止でも課金は続く?削除・終了との料金の違いと請求を止める対策

AWS

AWSのEC2インスタンスを停止したはずなのに、なぜか請求が続いて困惑していませんか。

結論から言うと、EC2を「停止(Stop)」しただけでは、インスタンス本体のコンピューティング料金が止まるだけで、接続されているEBS(ストレージ)などの周辺リソースには課金が発生し続けます。また、「削除・終了(Terminate)」を実行しても、設定次第では孤立したリソースが残り、請求の原因になるケースも少なくありません。

この記事では、EC2の停止と終了に伴う課金仕様の違いを整理し、不要な請求を完全に防ぐクリーンアップ手順を分かりやすく解説します。無駄なコストをゼロにするため、ぜひ最後までお読みください。

AWSを使っていないのに請求が来る原因と仕組み

EC2インスタンス本体を止めても料金が発生する理由

AWSのコンソール画面でEC2インスタンスを「停止」状態にしても、それだけで請求が完全にゼロになるとは限りません。なぜなら、EC2の料金システムは、仮想マシンを動かすCPUやメモリの費用だけでなく、周辺にある複数の関連サービスと連動しているからです。インスタンスを止めたからもう安心だと思い込んでいると、想定外のコストが翌月に請求されてしまいます。

料金が発生し続ける代表的な原因として、以下の2つが挙げられます。

  • 接続されたまま放置されている「EBSボリューム(ストレージ)」
  • インスタンスから切り離されて解放漏れになった「Elastic IP(固定パブリックIPアドレス)」

これらはインスタンス本体が動いていなくても、確保されているだけで維持費がかかる仕組みです。無駄な出費を抑えるためには、EC2の稼働状況だけでなく、これら周辺リソースのステータスまで正しく把握しなければなりません。

EC2の「停止(Stop)」と「開始」の違いと課金仕様

停止中に発生する料金と止まる料金

EC2インスタンスを「停止」した際にストップするのは、仮想マシンの稼働に伴うコンピューティング料金のみです。インスタンスが実行中でない間は、CPUやメモリのリソース消費が発生しないため、この部分の課金は確実に止まります。一方で、インスタンスに割り当てられていたEBSボリューム(ストレージ)の料金は、停止中も継続して発生する仕組みです。

サーバー内に保存されているデータやOSのシステム領域は、インスタンスが止まっていても維持し続けなければなりません。AWS側はデータを保管するためのディスク容量を確保しているため、ストレージ費用を請求します。ライフサイクルにおける「実行中」はすべてが課金対象となり、「停止」時はコンピューティングのみが無料になると覚えておきましよう。

インスタンスを一時的に止めるメリットと実務での使いどころ

実務において「停止」操作を行う最大のメリットは、設定やデータを保持したまま、後からいつでも「開始」して作業を再開できる点にあります。仮想マシンの中身を消去することなく、一時的にシステムを休止させたい場合に最適なステータスです。

具体的な使いどころとしては、社内でのみ利用する開発環境や検証環境の運用が挙げられます。例えば、夜間や休日など誰もアクセスしない時間帯にインスタンスを自動で停止させれば、無駄なコンピューティングコストの大幅な削減が見込めるでしょう。完全に削除するわけではないため、翌営業日の朝に再び「開始」をクリックするだけで、前日と同じ状態から業務を再開できます。

EC2の「削除・終了(Terminate)」時の注意点

終了後に「EBSの亡霊」が残るケースと原因

EC2の「終了(Terminate)」は、インスタンス自体をAWSの環境から完全に消去し、復元できない状態にする操作を指します。しかし、この操作を行っても、ストレージであるEBSボリュームだけが削除されずに残ってしまうケースが少なくありません。

この現象の原因は、EC2インスタンスの作成時に設定される「終了時に削除(Delete on Termination)」という属性にあります。この属性はボリュームの種類によってデフォルトの挙動が異なります。

  • ルートボリューム:デフォルトで有効(オン)になっており、インスタンスの終了と同時に自動的に削除されます
  • 後から追加でアタッチしたボリューム:デフォルトで無効(オフ)になっており、インスタンスを終了してもボリュームだけが残ります

つまり「EBSの亡霊」が発生しやすいのは主に、データ保存用などに追加でアタッチしたボリュームのケースです。設定を確認しないままインスタンスを終了すると、追加ボリュームが「Available(使用可能)」ステータスとなって孤立し、使っていないにもかかわらずストレージ料金だけが請求され続けます。

なお、ルートボリュームであっても、起動時に意図的に「終了時に削除」を「いいえ」に設定していた場合(データ保持のためにあえてそうするケースもあります)は、同様に残り続けるため注意が必要です。確認を怠ると、存在しないサーバーのディスク代を毎月支払い続けるリスクが生じるため、十分な注意が求められます。

インスタンス削除後も課金され続けるElastic IP

固定のパブリックIPアドレスを提供する「Elastic IP」は、実はインスタンスを削除するかどうかに関わらず、保有しているだけで課金が発生するリソースです。

以前は、起動中のEC2インスタンスに紐づけている1つ目のElastic IPアドレスは無料で利用できました。しかし2024年2月1日のAWSの料金改定により、この扱いが変更されています。現在は、EC2インスタンスに紐づいて稼働中であっても、Elastic IPを保有している時点で1IPアドレスあたり時間単位の課金が発生します(無関連(未割り当て)のアドレスは、この改定以前から課金対象でした)。

つまり、インスタンスを終了してElastic IPとの紐づきがなくなっても「新たに課金が発生する」わけではなく、稼働中から変わらず課金され続けているというのが正確な理解です。ただし、紐づく先のインスタンスがなくなった状態でElastic IPを保有し続けるのは、単に無駄な費用を払い続けているだけの状態になります。

EC2を削除したからといって、Elastic IPまでが自動的に手放されるわけではありません。インスタンス終了後は、必ず手動でアドレスの管理画面を確認し、不要なIPを解放する手順を踏む必要があります。

AWSの請求を完全に止めるための確認・対策チェックリスト

1. Available(使用可能)状態のEBSボリュームを削除する

不要な請求を止めるための最初のステップとして、どこのEC2インスタンスにも接続されていないEBSボリュームを削除してください。EC2の管理コンソールにログインし、左側メニューにある「ボリューム」の項目を選択します。

一覧が表示されたら、ステータスの列を確認しましょう。特定のインスタンスに接続されているものは「in-use」と表示されますが、孤立しているものは「Available」となっています。この状態のボリュームは現在使用されていないため、アクションメニューから削除を実行してください。なお、将来的にデータを再利用する可能性があれば、削除前にスナップショットを取得してバックアップを残す方法も有効です。

2. 紐づきのないElastic IP(固定IP)を解放する

次に、どこのリソースにも関連付けられていないElastic IPアドレスを特定して手放す作業に移ります。EC2コンソールのメニューから「Elastic IP」を選択し、アドレスの一覧を確認してください。

チェックすべきポイントは、「関連付けられたインスタンス ID」の項目が空欄になっているかどうかです。空欄のアドレスは、維持しているだけで毎時間コストが発生している状態を意味します。該当するアドレスを選択し、アクションから「Elastic IP アドレスの解放(Release)」を実行しましょう。単に「関連付けの解除」を行うだけではアドレス自体がアカウントに残ったままになるため、必ず「解放」まで完了させることが重要です。

3. コスト配分タグや一元管理で不要リソースを先回りして見直す

クラウドインフラを健全に維持するためには、無駄なリソースを定期的に見直す運用体制が欠かせません。コスト配分タグを設定してプロジェクトごとに費用を可視化すれば、削除漏れのボリュームやIPアドレスを早期に発見できます。

また、手動でのチェックに加えて、AWSの管理ツールを活用した一元管理を取り入れるのも賢明な判断と言えます。削除漏れが発生しやすいリソースの具体的な対策や、より効率的なコスト最適化のノウハウについては、関連記事である「AWSコスト削減の具体的なアプローチと管理手法」も合わせて参考にしてみてください。

まとめ

EC2インスタンスは、ただ画面上で「停止」や「終了」をクリックしただけでは、関連リソースによる思わぬ課金が続いてしまう落とし穴があります。AWSのコストを最適化するためには、インスタンス本体だけでなく、紐づいている周辺リソースのステータスまで正確に把握する習慣が欠かせません。

今回の重要なポイントは以下の3点です。

  • 「停止」で止まるのは本体の稼働料金のみであり、EBSボリュームのストレージ料金は発生し続ける
  • 「削除・終了」時でも、設定によっては「Available」状態のEBS(亡霊)や、紐づきのないElastic IPが残る
  • 不要な請求を完全に止めるには、手動でのボリューム削除やアドレス解放(Release)の確認が必須である

クラウドインフラを実務で運用する際は、定期的にコンソールを見直し、不要なリソースが孤立していないかチェックする体制を整えましょう。手順に沿って適切なクリーンアップを行い、無駄なコスト負担のないクリーンなAWS環境を維持してください。

AWSをさらに深く学びたい方には 以下の書籍がおすすめです。

「※本記事にはアフィリエイトリンクが含まれています」

AWSの基礎から実践まで体系的に 学べる一冊です。

コメント

タイトルとURLをコピーしました