前回 のおまけコーナーで、どのくらい削減できる PublicIP があって、どのくらい来年2月から費用が増加するのかを調べます。
IPv6化をするかは新規は必須としても、既存サービスには絶妙に微妙なラインなので、実際の数値を整理して、着手するかどうかの価値判断をしたらいいと思います。
参考ページ
公式だけですが、この辺に目を通せば十分です。- 新着情報 – パブリック IPv4 アドレスの利用に対する新しい料金体系を発表 / Amazon VPC IP Address Manager が Public IP Insights の提供を開始 | Amazon Web Services ブログ
- AWS におけるパブリック IPv4 アドレスの使用状況の特定と最適化 | Amazon Web Services ブログ
- パブリック IP に関するインサイトを確認する – Amazon Virtual Private Cloud
公式なので、お堅く伝えていただけるのはありがたいとしても、どうにもわかりづらい感は相変わらずです。内容はちゃんとしてるのに何故でしょうね:-)
では、この辺をほぐしていきましょう。
PublicIP Insights
AWS管理画面にて、Amazon VPC IP Address Manager という機能の中に、【パブリック IP に関するインサイト】があります。VPC IP Address Manager (IPAM) というページ内にありますが、特に IPAM 関連のリソースを作成する必要はなく、いつでも見られる機能です。ここでは以下の内容を確認できます。
EC2 PublicIP | EC2 に割り当てられた PubliIP の数 |
ElasticIP | 確保済みの EIP の数 |
ElasticIP未関連 | 関連付けしていない EIP の数 |
Service Managed IP | ALB や Global Accelerator に自動的に割り当てられた PublicIP の数 |
BYOIP | Bring-Your-Own-IP で持ち込んだアドレスなので、今回の有料化は関係なし |
各アドレスが何に割り当てられているかのリストも見れるので、基本的には全容を把握することが可能です。
ただし注意点として、閲覧した現時点での情報である、ということです。
EC2 の PublicIP を課金目線で数える
PublicIP の有料化は1時間単位のため、Insights で見て現在の情報で計算しても、AutoscalingGroup のリソース量変動によって、少し実情と離れた結果になりそうなので、工夫して数えます。CloudWatch 管理画面で、【すべてのメトリクス】→【Auto Scaling】→【グループメトリクス】に移動し、<GroupDesiredCapacity>を検索に追加します。
出てきた AutoscalingGroup で Public Subnet に属するものに全てチェックを入れれば、まずは現在の実台数を表示できるので、その数値を全て足しておきます。そしてその数値を、Insights で表示した EC2 PublicIP の数から引くと、Autoscaling に属さない静的な EC2 PublicIP の数がわかります。
次にグラフの表示を【グラフ化したメトリクス】タブに移動し、全体の表示期間を 3d くらいにし、<統計>を平均、<期間>を1日にすることで、対象グループを足せば1日の平均起動台数 すなわち使用 PublicIP の平均数がわかります。
前日分だけ見ると、前日だけ盛り上がった盛り下がったとかあっても嫌なので、数日分を見ておくとよいですね。どっちにしても概算なので繊細に気にする必要はないです。
静的/動的リソースの数を足せば、EC2 PublicIP の1日あたりの本当の数となり、本気を出せば例外を除き全てが PublicIP 削減の対象となります。
※AWS CLI でも書こうと思ったけど、多分、管理画面の方が早いです
ElasticIP 未関連 の削除
今まで割り当て条件を満たしていた ElasticIP は無料でしたが、同様に有料化されます。でも、普通は割り当てたということは外部からのアクセスがあるか、送信元アドレスとして活用しているはずなので、削減対象にはほぼできません。未関連状態の EIP はほぼ100%邪悪なので、即削除しましょう。超偶然に入れ替え作業中とかならまだしも、いや~また同じアドレス割り当てる必要あるからとっといたんだよね~w なんてことはなく、ほぼただの削除忘れです。
Service Managed IP
ALB や Global Accelerator ですが、ほぼ ALB の話になります。Global Accelerator はそこまで扱われないってのもあるけど、基本的に ALB と1:1で扱うので、同じような内容となるでしょう。ALB には通常 PublicIP が 1~3 個を割り当てられます。そこまで大量に見たわけじゃないですが、トラフィックの流量に関わらず、流量が少なくても 2~3 個を持つ ALB もあったので、その個数条件についてはよくわかりません。
ここで言えることは、AWSコスト削減とリソース管理 | 外道父の匠 で説明した ALB 統合による削減の価値がより高くなったということです。
仮に 1 ALB あたり平均 2 PublicIP とすると、これまで起動するだけで $23/月 かかっていた ALB が、来年2月から $23 + $3.6 * 2 = $30.2/月 と30%増になります。
ACM を共通化できる URL で扱うというだけで、本番以外の ALB を1つにまとめることは簡単なので、ちょっとした運用方法の差で開発用に大量に ALB があるなら、いままで以上の勢いでガンガン減らしておしまい!ってことです。
コスト増加抑制の概算
使用中 EIP を除く、EC2 PublicIP の全てと、ALB 統合で減らせる数を足すと、それが最大限削減できる PublicIP の数となります。削減PublicIP数 * $0.005/h * 24h * 30d = 削減$/月
でいったん算出してみましょう。ついでに、ALB も減らせるなら、その本体費用も一緒に算出したほうが良いでしょう。
実際に費用がかかれば、共通支払いアカウントで各アカウントごとの PublicIP 費用を簡単に見れると思いますが、今は複数アカウントある場合は、地道に個別で見て全てを足すことになりそうです(Cost and Usage Report で見れることは書いてあったけど、数えづらそう)。
100 IP あれば、$360/月、$4380/年 となり、年間60万円を超える費用が、2024年2月 から単純増加します。
放置した場合に予定する増加コストと、対処した場合に PublicIP + ALB で減らせる差額を算出してみたら、けっこう多くの環境において思ったより大きめの額面になるんじゃないかなと想像しています。
削減計画
一番簡単な未関連 EIP は悪即斬です。本番以外の ALB の統合は難しくないので、ヤル気を出してサクッと最初に終わらせたらいいと思います。
EC2 Autoscaling は、AWSのPublic IPv4構成をIPv6に切り替える | 外道父の匠 の通りにやれば、Private Subnet に移動するだけでそこまで不安はないのですが、本番移動前には念のため、IPv6 を持たせたサーバーのアプリケーションの外部接続処理が、適切に動くかくらいは確認してから実施するとよいでしょう。
Autoscaling に所属しない単発系 EC2 は、おそらく Private Subnet への起動し直しが若干面倒なので、1つ1つ対応するとコスパ悪く感じるかもです。でもやることは普通なら、イメージを確保して、Private Subnet に起動し、EBS を元通りマウントして、必要なら変更された Privateアドレスを DNSレコードに登録する、くらいになると思います。あとはミドルウェアの自動起動がされてなければ面倒みるとか……です。
※ちなみに、PublicIP を剥がして IPv6 を付けることで Public Subnet のままでも外部接続が問題なく動くなら作り直しは不要かと思いきや、一度ネットワークインターフェースに割り当てられた PublicIP は削除することができないため、作り直しは必須です
やった方がいいかどうかで言えば、やった方がいいのですが、PublicIPの増加コストに対する、作業コストとリスクが微妙なバランスなせいで、絶対にやるべきとまでは言えない匙加減があまりに絶妙な本件であります。
まぁ実際に、2024年2月2日以降に、日割りで課金額を見てから焦るなりしてもイィかもしれません。でもいきなり増えましたって情報共有されるのもアレなんで、今くらいから各アカウント毎にこれくらい増える想定です、って告知して対応を促しておけば、あとは運営事情と価値観の問題なので、数字の整理と対応準備くらいは各位やっておきましょうそうしましょう:-)