AWSの利用料は米ドル建てで確定し、請求のタイミングで円に換算されます。使用量が同じでも為替が動けば円建ての請求額は変わる、という当たり前の事実が、月次予算の管理を悩ませます。この記事では、為替がコストのどこに効くのかを分解し、RIやSavings Plansで固定できるものと固定できないもの、そして円安局面で本当に効く最適化と経営への説明の仕方を、実務目線で整理します。
01AWSの請求はUSDで確定し、あとから円になる
まず前提を正確に押さえます。AWSの料金表はすべて米ドル建てで、各サービスの単価も従量課金の計算もUSDで行われます。日本の多くのお客様は円建てで請求を受け取りますが、これは「AWS側がドルで確定した金額を、請求書発行のタイミングの為替レートで円に換算している」だけです。円で単価が決まっているわけではありません。
この換算に使われるレートや適用タイミングの詳細は契約形態(直接契約か、パートナー経由か)や支払通貨の設定によって異なるため、自社の請求書がどのレートで換算されているかは実際の請求書と設定を確認するのが確実です。ただし共通して言えるのは、使った量(USDのコスト)と、円に直すレートは別物であり、両方が請求額を動かすという点です。
02為替がコストに効く経路を分解する
「円安でAWS代が上がった」と一括りにすると、対策を打つ場所を見誤ります。円建ての月次請求のブレは、大きく分けて次の要素の掛け算・足し算で決まります。
- 使用量の増減：起動しているインスタンス数、データ転送量、S3の保存量など。自社でコントロールできる部分です。
- USD単価：AWSの料金改定や、オンデマンドからコミット割引への切り替えで変わります。これも設計でコントロールできます。
- 為替レート：USD→JPYの換算レート。自社ではコントロールできず、外から降ってくる変動要因です。
ポイントは、最初の2つ(使用量・単価)は技術と契約で動かせるのに対し、3つ目の為替は動かせないという非対称性です。だからこそ、コスト増を見たときに「為替のせいで増えた分」と「自分たちの使い方で増えた分」を切り分けることが、最初にやるべき作業になります。切り分けの基本は単純で、USD建てのコスト推移を先に見ることです。USDが横ばいなら円増加は為替要因、USDも増えていれば使い方の要因、と切り分けられます。
03RI・Savings Plansは単価を固定するが、為替は固定しない
ここが誤解の多いところです。リザーブドインスタンス(RI)やSavings Plans、あるいは各種のコミットメント割引は、USD建ての単価やコミット金額を固定・割引する仕組みです。1年・3年の期間、オンデマンドより安いレートを確保できます。これは大きな武器です。
しかし、これらはあくまでUSDの世界での約束です。「1時間あたり$X」で固定しても、その$Xを円に直すレートは固定されません。3年のSavings Plansで単価を約束しても、円建ての支払額は毎月の為替で上下します。つまり、コミット割引は使用量リスクと単価変動リスクには効くが、為替リスクには効かないと理解すべきです。
なお、コミット割引そのものの選び方や損益分岐の考え方は、NAT Gatewayのコスト設計や気づかないうちに増えるAWSコスト Top10と合わせて読むと、削減の全体像が掴みやすくなります。
04コスト予測に「為替前提」を明記する
月次のコスト予測を立てるとき、多くの現場はUSDの使用量予測だけを作り、円換算のレートを暗黙のまま置いてしまいます。これだと、予測が外れたときに「使いすぎたのか、為替なのか」が後から追えません。おすすめは、予測を必ず二段構えにすることです。
- USD建ての予測：使用量とコミット割引を織り込んだ、技術的に責任を持てる数字。ここは自分たちのコントロール範囲。
- 円換算の前提レート：予算を円で立てる以上どこかでレートを掛けます。そのレートを「前提◯◯円/ドル」と明示して置く。財務と相談し、保守的な(円安寄りの)レートを置くのが安全です。
こうしておくと、実績が予算を超えたときに「USD予測は当たっていたが、前提レートより円安に振れた分」と「USDの使用量自体が超過した分」を分けて報告できます。前者は財務・全社の話、後者は技術チームが手を打つ話です。責任の所在が分かれるだけで、レビューの生産性が大きく変わります。
05円安局面で本当に効く最適化(と、効かない誤解)
為替は動かせない以上、打てる手はUSDコストそのものを下げることに集約されます。円安局面だからといって特別な魔法はなく、王道の最適化を粛々とやるのが正解です。優先順位はおおむね次の通りです。
- 不要リソースの削減：止め忘れの検証環境、アタッチされていないEBSやEIP、使われていないスナップショットや旧世代インスタンス。効果が確実で、リスクもゼロに近い最初の一手です。
- 使用量の最適化(ライトサイジング)：CPU・メモリの実使用に対して過大なインスタンスをサイズダウンする、gp2からgp3への切り替えでIOPS/スループットを実需に合わせる、といった調整。EC2インスタンスタイプの選定やEBSボリュームの選び方が参考になります。
- コミット割引の活用：安定して動き続けるベースライン分に、Savings PlansやRIを当てる。前述の通り単価は固定できます。使用実績が読める部分にだけ当てるのが鉄則です。
削減の網羅的なチェックは気づかないうちに増えるAWSコスト Top10に、マルチアカウント環境での予算とガードレールの敷き方はマルチアカウント統制に整理してあります。
06経営への説明は「切り分け」と「前提の開示」で通す
コスト増を経営に説明する場面では、技術の正しさよりも「何が原因で、誰が手を打つのか」が伝わることが重要です。ありがちな失敗は、円建ての請求額だけを見せて「増えました、削減します」と報告してしまうことです。これだと、為替で増えた分まで技術チームの責任にされ、際限のない削減圧力を招きます。
通る説明の型はシンプルです。
- USD建てで実績を示す：「使った量は前月比で横ばい/◯%増でした」と、自分たちの制御範囲を先に開示する。
- 為替の影響を金額で分離する：「円換算後の増加のうち、◯◯円分は為替の影響、◯◯円分は使用量です」と分けて示す。
- 予算の前提レートを明示する：「予算は◯◯円/ドル前提で組んでいます。現状レートはそれより円安のため、円建て予算を上回っています」と、前提のズレとして説明する。
- 手を打つ範囲を約束する：技術で下げられるのはUSDコストであることを明確にし、削減の打ち手と見込み効果をUSDで示す。
この切り分けができていると、為替は財務・全社で受け止める話、使用量は技術チームが継続的に最適化する話、と役割が整理され、レビューが建設的になります。EMWがコスト相談で最初にやるのも、多くの場合この「請求額を要因に分解して、共通言語にする」作業です。手を動かす前に、まず数字の見え方を揃える。ここが効きます。
—まとめ
AWSの利用料はUSDで確定し、あとから円に換算されます。だからこそ、コスト管理は次の順で考えると迷いません。
- 請求のブレを「使用量・USD単価・為替・一時費用」に分解し、USD建ての推移を先に見る。
- RIやSavings Plansで固定できるのはUSDの単価であって、為替ではないと正確に理解する。
- 予測は「USD予測 + 前提レート」の二段構えにし、超過要因を切り分けられる形で残す。
- 円安局面でも王道の最適化(不要リソース削減・ライトサイジング・コミット割引)を優先し、「安いリージョンに移す」という誤解には手を出さない。
- 経営には、要因分解と前提レートの開示で説明し、技術が責任を持つのはUSDコストだと明確にする。
為替は動かせませんが、動かせる部分を正しく切り出して手を打つことはできます。制御できるものとできないものを分けることが、円安時代のコスト管理の出発点です。関連して気づかないうちに増えるAWSコスト Top10やNAT Gatewayのコスト設計、契約・支援体制については料金も参考にしてください。
← ブログ一覧へ戻る