Step Functionsで実現する「EC2専有ホスト(Dedicated host)構成の起動・停止」運用ワークフロー
はじめに
こんにちは、DELTAの馬場です。
今回はEC2専有ホストの起動停止運用を検討する機会があったので、備忘がてら記事にします。
そもそも
AWSの 専有ホスト(Dedicated Host) は、物理サーバーの一部を他のユーザーと共有せず、単一のアカウントで占有できる仕組みです。しかし、コスト効率の観点でいくつかの制約があります。
本記事では、 EC2専有ホスト構成での起動・停止をStep Functionsで自動化 することでコスト効率を高めた事例を紹介していきます。
専有ホスト利用時のコスト課題
あまりなじみが無い方もいらっしゃるかと思うので、ここでEC2専有ホストを利用する際のコスト課題について紹介します。
- EC2インスタンス料金に加えて、専有ホスト自体にも課金 される
- 開発・検証環境などで 未使用時間が多い とコストが無駄になる
- RI(リザーブドインスタンス)やSavings Plansを使っても、使わない時間のコストは回避できない
つまり「そもそも使わない状態にする」のが一番のコスト削減策です。
専有ホスト構成で起動・停止は少し難しい
通常のEC2では「起動」「停止」といった操作が簡単に行えますが、専有ホストを使った構成では事情が異なります。なぜなら、起動停止という機能がそもそも存在しないため、不要なタイミングでは単純に停止をして料金が発生しないようにするということもできません。
また、専有ホスト自体をリリースするにしても、専有ホスト上で動かしているEC2インスタンスがある場合、リリースできないという仕様があるためです。
専有ホスト構成の「起動・停止」はどうする?
先述の通り「専有ホストを停止する」ような機能はありません。
そのため、前回の記事のAWS Client VPNの起動停止ツールを実装してコスト削減した話のように実際には以下のような「削除と再作成による停止と起動の代替処理」で実現します。
停止フロー
- EC2インスタンスの停止
- AMI(マシンイメージ)の取得
- インスタンスのTerminate(削除)
- 専有ホストのリリース
起動フロー
- 専有ホストを新たに割り当て
- 停止フローで作成したAMIから新たにEC2インスタンスを作成
フローについて
例に挙げた記事での処理より処理の個数が多くなってしまいますが
専有ホストの上でインスタンスを動かすという複数のリソースが関与し、その処理の順番が重要になるため複雑な処理が必要となってきます。
なぜStep Functionsなのか?
ここまでで解説したフローは頑張れば実装はできますが、処理が複雑になってしまいがちです。
例えば起動停止のフローをLambdaだけで処理すると、待機処理やポーリングロジックが必要になり、コードが複雑になってしまうことは想像できるかなと思います。
そこでStep Functionsを使うことで、これらの状態管理やリトライ、時間のかかる処理のオーケストレーションが非常に簡単になります。
Step Functionsによる実装の概要
今回は sogaohさんに協力してもらってIaC化を実施してもらいました。
Special Thanks!!
検証の手法についてはREADMEに記載の通りとなりますがStep Functionsを用いることで専有ホストの起動停止運用を実現することができます。
注意点
Apple Macインスタンス(mac1.metal
)を対象とする場合、以下の制限に注意が必要です。
そのため、夜間停止といった運用はできないため 起動・停止の頻度 には注意が必要です。
まとめ
- 専有ホストは通常のEC2のように「停止」ができないため、Terminateと再作成で実現
- 起動・停止を自動化するには、待機や状態管理ができるStep Functionsが適している
- コスト削減の観点では「使わない時間を完全になくす」 というのが最大のポイント
今回の記事はかなりニッチな内容であったなと改めて振り返っていますが、開発・検証環境などにおいて、専有ホストの構成を採用している場合は、こうした工夫で無駄なコストを抑えることが可能となります。
今回の記事がどなたかのお役に立てれば幸いです!
Discussion