EC2停止時にEBSタイプを変更して課金を減らす作戦

今日はAWS関連のネタです。

AWSのEC2を使ってサーバを立てる場合、基本的にはEC2利用料とEC2にアタッチするEBS利用料がコストの大部分を占めると思います。 今回はEC2が止まっているという一定の条件下において、コストを抑える作戦をご紹介します。

EC2とEBSの課金体系

AWSは使った分だけ支払う従量課金が原則ですので、EC2はインスタンス(サーバ)が起動している間だけ課金されますが、 EBSはボリュームを確保している状態をもって使っていることになるため、サーバが稼働していても止まっていても関係なく、 さらに言えばサーバにアタッチされていない状態でも課金は発生します。

EC2もEBSも以下のAWSブログに記載されている通り、課金は1秒単位で計算されます。 aws.amazon.com

EBSの価格体系とコスト抑制の作戦

EC2がインスタンスタイプで料金単価が異なるように、 EBSの料金はボリュームサイズとボリュームタイプによって規定されます。 このうち、ボリュームサイズは拡張はできますが単純な方法での縮小は許可されていません。 そのため、当面の必要サイズを確保して、利用に応じて足りなくなってきたら拡張するのが基本的な使い方になります。

他方のボリュームタイプは主にIO性能の違いにより複数のタイプが用意されています。 通常はデフォルトである汎用SSD(gp2)を使うことが多いと思いますが、高いIO性能を必要とする場合はプロビジョンドIOPS SSD (io1)を使ったり、逆にIO性能が重要ではないボリュームの場合は、スループット最適化HDD (st1)やコールドHDD (sc1)といったHDDを採用することでコストを抑えることができます。

aws.amazon.com

オンプレ時代はサーバの設計時に各ディスクの用途や将来予測、求められるIO性能等から固定的にボリュームサイズとボリュームタイプを見積る必要がありましたが、 クラウド時代の現在ではボリュームサイズだけでなく、ボリュームタイプについても必要なときに必要なタイプを選択することができます。

今回の作戦は、EC2を停止している間はEBSタイプも安価なものに変更することでコスト削減を図ろうとするものです。 例えば、gp2は1GB当たり0.12USD/月ですが、sc1だと同0.03USD/月となるため、単純計算でコストを1/4にすることができます。

EBS ボリューム変更時の制限

上記の作戦が無条件に適用できればいいのですが、残念ながらAWSには一定の仕様制限があります。

docs.aws.amazon.com

AWSブログによると、次のような制限が存在します。

  1. 変更を行うために、ボリュームのデタッチやインスタンスの停止が必要になる場合もあります。
  2. ルートボリュームとしてインスタンスに接続されている gp2 ボリュームを st1 または sc1 ボリュームに変更することはできません。
  3. 要求されたボリュームサイズが st1 および sc1 ボリュームの最小サイズを下回る場合、gp2 ボリュームを st1 または sc1 ボリュームに変更することはできません。
  4. 既存の io1 ボリュームに 32,000 IOPS 以上のプロビジョニングを行う場合は、完全なパフォーマンスを確認するために、ボリュームをデタッチしてアタッチするか、インスタンスを再起動を実行する必要があります。
  5. EBS ボリュームのサイズを小さくすることはできません。
  6. ボリュームを変更した後、少なくとも 6 時間待ってから、同じボリュームにさらに変更を適用する前に、そのボリュームがin-use または available の状態にあることを確認してください。
  7. m3.medium インスタンスはボリュームの変更を完全にサポートしていますが、m3.large、m3.xlarge、および m3.2xlarge インスタンスのいくつかは、すべてのボリューム変更機能をサポートしているわけではありません。

結構制限が多いようにも見えますが、私の理解で簡潔に要約すると、以下の通りです。

現役世代のインスタンスタイプやボリュームタイプで構築された、 ルートボリュームを除く500GiB以上のボリュームについては、EBSタイプの変更が可能です。 ただし、頻繁な変更は許可されず、1度変更したら6時間は再度の変更はできません。 また、この変更は基本的にはEC2インスタンス起動中にオンラインで変更できますが、 一定の条件でio1を使用する場合はEC2の再起動等が必要が必要になります。

この作戦が使えるケース

開発機やテスト機など、24時間起動しておく必要がないインスタンスに対して適用することを想定しています。 例えば、データベース領域をルートボリュームとは別に専用のEBSとして設計することで、停止期間中のコストを大幅に抑えることが可能になります。