[AWS Systems Manager] ジャストインタイムノードアクセスの課金時間は何に対する時間なのか確認してみた
課金の単位が気になる
こんにちは、のんピ(@non____97)です。
皆さんはSSMのジャストインタイムノードアクセス機能の課金の単位が気になったたことはありますか? 私はあります。
ジャストインタイムノードアクセスを用いることで、プリンシパルにマネージドノードへの永続的な接続権限を付与することを回避し、自動承認や手動承認による一時的な権限付与を行うことが可能になります。
実際の利用方法は以下記事をご覧ください。
ジャストインタイムノードアクセスは無料の機能ではありません。
ジャストインタイムノードアクセスを使用するにあたって、ノードあたりの時間料金が設定されています。
具体的には以下のとおりです。
Tier | Price per node per month* | Price per node per hour |
---|---|---|
Up to 100 nodes | $10.00 | $0.0137 |
101 to 1,000 nodes | $7.50 | $0.0103 |
1,001 to 10,000 nodes | $2.50 | $0.0034 |
10,001+ nodes | $1.00 | $0.0014 |
- Monthly prices are approximations-based calculations using 720 hours per month.
抜粋 : Centralized Operations Hub – AWS Systems Manager Pricing – Amazon Web Services
個人的には「時間料金」が何に対する時間なのか気になります。
ドキュメントを見ましたが、ジャストインタイムノードアクセスによって実際に接続している時間なのか、それともジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間課金なのか確証は持てていません。
しかし、料金例には以下のような記載があり、後者 = ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間課金な気がしています。
Pricing Example #1
You have a Consolidated Billing family with two accounts, Account A and Account B. Account A has 500 nodes opted into just-in-time node access for the entire month and Account B has 1,000 nodes opted into just-in-time node access for the entire month.
Total usage aggregated at the Consolidated Billing family = 500 + 1,000 = 1,500 nodes.
Tier 1 cost = 100 nodes $10.00/node/month = $1,000.00
Tier 2 cost = (1,000 nodes – 100 nodes = 900 nodes) $7.50/node/month = $6,750.00
Tier 3 cost = (1,500 nodes – 1,000 nodes = 500 nodes) * $2.50/node/month = $1,250.00Total expected cost = $1,000.00 + $6,750.00 + $1,250.00 = $9,000.00
ドキュメントから確信を持てなかったので、実際に動かして確認をします。
いきなりまとめ
- ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間で課金される
やってみた
確認の方向性
確認の方向性としては以下のどちらのパターンで課金が行われているか確認する形になります。
- ジャストインタイムノードアクセスによって実際に接続している時間
- ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間
「ジャストインタイムノードアクセスを有効化している期間で稼働している対象マネージドノードの台数の時間」もあるのでは? と思われた方もいるかも知れません。しかし、2025/5/6時点ではジャストインタイムノードアクセスの自体の対象に絞り込む機能はありません。
手動承認はタグで、自動承認はCedarポリシーでジャストインタイムノードアクセスの接続対象ノードの絞り込みが可能ですが、いずれもアクセスリクエストを行ったタイミングで評価されます。そのため、課金の計算に使われる可能性は低いでしょう。
そのため、課金単位である時間は上述の2パターンと考えます。
確認の方法は、シンプルでマネージドノードのEC2インスタンスを起動し、ジャストインタイムノードアクセスによる接続を行わず、放置する形です。
もし、EC2インスタンスの起動時間とジャストインタイムノードアクセスの課金時間が一致していれば、「ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間」でしょうし、一致していなければ「ジャストインタイムノードアクセスによって実際に接続している時間」と言えます。
マネージドノードのEC2インスタンス起動前のCost Explorerの確認
EC2インスタンス起動前のCost Explorerの確認をします。
確認したのは5/5の13時ごろです。
4/30と、5/1にジャストインタイムノードアクセスの課金使用タイプであるUSE1-JustInTimeAccessHour-Trial
が記録されていますね。
4/30と5/1はジャストインタイムノードアクセスによる接続の検証をしていたので、これだけでは断定はできません。
しかし、流石に4時間も接続しっぱなしではないことと、使用していたEC2インスタンスの稼働時間とほぼイコールなことを鑑みると、「ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間」の可能性が高そうです。
マネージドノードのEC2インスタンス停止後のCost Explorerの確認
EC2インスタンスを起動させ、マネージドノードとしていることを確認します。
EC2インスタンスは7時間ほど起動しています。
停止させます。
SSMのFleet Managerからもマネージドノードが停止したことを確認します。
翌日、5/6の13時ごろにCost Explorerの確認をします。
5/5にジャストインタイムノードアクセスの課金使用タイプであるUSE1-JustInTimeAccessHour-Trial
と、動作確認用に使用したEC2インスタンスの起動時間の使用タイプであるBoxUsage:t3.micro
が2時間分ほど記録されていますね。
EC2インスタンスを起動させてから停止させるまで、一切ジャストインタイムノードアクセス機能は触っていません。
StartSession
操作も行っていません。
加えて、AWSマネジメントコンソールでジャストインタイムノードアクセスの情報の表示もしていません。しかし、2つの使用タイプの使用量はほぼ同じです。
ということは「ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間」に対して課金が発生すると言えます。
Pricing Calculatorを見てみる
「もしかすると、Pricing Calculatorにも料金計算ロジックが記載されているかも」と思ったので、Pricing Calculatorも確認してみましょう。
SSMのマネージノードの台数と、それらが実行されている月の割合をベースに計算されていることが分かります。
ジャストインタイムノードアクセスの接続時間は料金計算の要素ではないということですね。
一方、右ペインには以下のように、ジャストインタイムノードアクセスのセッション時間で計算されると気になる文言が記載されていました。
開始されたジャストインタイムノードアクセスセッションの数と、これらのセッションの合計時間に基づいて課金されます。この料金は、JustinTimeNodeAccess 機能を使用するすべてのマネージドノード (オンプレミス、他のクラウドプロバイダー、または Amazon EC2) に適用されます。料金は、開始されたセッションの数と各セッションの所要時間(分単位)に基づいて計算されます。
書いてあることと実際の計算の内容が食い違っていますね。
流石にCost Explorerに表示されている内容が正だと思うので、これは後ほどフィードバックしておきます。
ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間で課金される
ジャストインタイムノードアクセスの課金時間は何に対する時間なのか確認してみました。
結論、ジャストインタイムノードアクセスを有効化している期間で稼働しているマネージドノードの台数の時間で課金されます。
EC2インスタンスの台数が多い環境においては月10USD/台はちょっとインパクトが大きいかもしれません。
しかし、EC2インスタンスへの接続管理用に特権ID管理システムを導入している場合、そのシステムのインフラ料金とライセンス料金を勘案すると逆に安くなるという場合もあるかと思います。一度トータルコストはどちらが安いのか、機能の過不足の比較をしてみると良いでしょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!