t3.mediumは、2vCPU・4GiBメモリのバースト可能な汎用インスタンスです。東京リージョンのLinuxオンデマンドは1時間0.0544ドルで、月730時間なら約39.7ドルになります。ただしこの金額で使えるCPUは平均20%までで、超えた分はunlimitedモードの追加課金の対象です。この記事では、スペックの確かめ方、CPUクレジットが尽きるまでの時間、平均CPU使用率から月額を出すコード、CloudWatchでの監視コマンドをまとめ、2026年9月に一般提供が始まったT8iやArm系のt4gへ移す判断基準も示します。
まとめ:t3.mediumを選ぶ条件と月額・クレジット・乗り換えの結論
t3.mediumを選ぶ理由は、実質的にメモリ4GiBだけです。CPUクレジットの獲得量はt3.smallと同じ毎時24で、CPUの持久力は変わりません。メモリが2GiBで足りるならt3.smallで月額は半分になり、CPUが足りないからといってt3.largeへ上げると、CPUのために払う額としては割高です。
費用の分かれ目は24時間平均のCPU使用率です。平均20%以下なら追加課金はゼロ、平均40%なら月約14.6ドル、常時100%なら月約58ドルの上乗せで、平均78%前後で固定性能のc7i.largeと月額が並びます。Arm64でアプリが動くならt4g.mediumで月約8ドル下がり、CPUが足りない案件は単価2割高・性能最大7割増のT8iが移行先の候補です。まずCPUSurplusCreditsChargedを1週間分取得し、追加課金の有無を確かめてください。判断はそこから始まります。
t3.mediumのスペックをAWS公式の仕様表とCLIの出力で確かめる手順
仕様は公式の表から取ります。取り違えやすいのはvCPUとベースラインです。
2vCPU・4GiB・ベースライン20%の意味とvCPUがスレッド単位である点
Amazon EC2 T3インスタンスの製品ページによると、t3.mediumは2vCPU・メモリ4GiB・vCPUあたりのベースライン20%・CPUクレジット毎時24で、ネットワークは最大5Gbps、EBS帯域は最大2,085Mbpsです。プロセッサは第1世代または第2世代のIntel Xeon Platinum 8000シリーズ(Skylake-SPまたはCascade Lake)で、ターボ時の最大クロックは3.1GHzとされています。
見落としやすいのはvCPUの数え方です。バースト可能インスタンスの主要概念のドキュメントには、T3とT3aのvCPUはコアの1スレッドであり、T2とT4gは例外だと書かれています。t3.mediumの2vCPUは物理コア1つ分のハイパースレッドです。CloudWatchのCPUUtilizationが20%を指している状態が、ちょうどベースラインにあたります。
describe-instance-typesで仕様を取得するコマンド例
比較する型番を並べて一度に出力します。describe-instance-typesのリファレンスにある--instance-typesで型番を指定し、--queryで列を絞ります。
# 東京リージョンで t3.medium と同クラスの型番を並べて仕様を出す
aws ec2 describe-instance-types \
--region ap-northeast-1 \
--instance-types t3.small t3.medium t3a.medium t4g.medium t8i.medium \
--query 'InstanceTypes[].[InstanceType,VCpuInfo.DefaultVCpus,VCpuInfo.DefaultThreadsPerCore,MemoryInfo.SizeInMiB,BurstablePerformanceSupported,NetworkInfo.NetworkPerformance]' \
--output table
DefaultThreadsPerCoreが2ならvCPUはスレッド単位、1なら物理コア単位で、BurstablePerformanceSupportedがtrueの型番がバースト型です。ファミリーの選び方やCLIでの絞り込みはEC2インスタンスタイプの選び方:命名規則の読み方とCLI絞り込み・変更手順で扱っています。
t3.smallとt3.mediumはCPUクレジットが同じでメモリだけが倍になる
公式のクレジット表では、t3.smallとt3.mediumはどちらも毎時24クレジット・最大576・ベースライン20%です。違うのはメモリの2GiBと4GiBだけで、東京の単価は0.0272ドルと0.0544ドルのちょうど倍です。
smallからmediumへ上げても、CPUの余力は増えません。クレジットが尽きて遅い環境をmediumに上げても症状は変わらず、請求だけが倍になります。t3.mediumを選ぶのは、アプリとOSとミドルウェアの常駐メモリが2GiBを超えるときに限られます。
東京リージョンでのt3.mediumの月額料金と同クラス4GiB型番との比較
解説記事でよく見る「1時間0.042ドル」前後は米国リージョンの単価です。
オンデマンド時間単価0.0544ドルから月額約39.7ドルを出す計算
Amazon EC2オンデマンド料金ページが読み込む東京リージョンの料金データ(2026年9月25日公開分・Linux)では、t3.mediumは1時間0.0544ドルです。T3製品ページの米国単価0.0418ドルと比べると、東京は約1.3倍になります。
AWSの月額試算で使う730時間を掛けると、0.0544×730=約39.71ドルです。これはインスタンス本体の金額で、EBSボリューム、データ転送、パブリックIPv4アドレスは別に請求されるため、本体と付帯費用を分けて見積もってください。付帯費用まで含めた見積もりの組み立てはAWSの見積もりとは?料金計算ツールの使い方と費用が変わる要因で整理しています。
t3a・t4g・T8iのmediumと固定性能型の東京単価を並べた比較表
同じ料金データから、t3.mediumの乗り換え先になりうる型番を抜き出しました。月額は730時間で換算しています。
| 型番 | vCPU/メモリ | CPU性能の方式 | 東京の時間単価 | 月額換算 |
|---|---|---|---|---|
| t3.small | 2/2GiB | バースト・20% | 0.0272ドル | 約19.86ドル |
| t3.medium | 2/4GiB | バースト・20% | 0.0544ドル | 約39.71ドル |
| t3a.medium | 2/4GiB | バースト・20%(AMD) | 0.0490ドル | 約35.77ドル |
| t4g.medium | 2/4GiB | バースト・20%(Arm) | 0.0432ドル | 約31.54ドル |
| t8i.medium | 2/4GiB | バースト・20%(Xeon 6) | 0.06528ドル | 約47.65ドル |
| t3.large | 2/8GiB | バースト・30% | 0.1088ドル | 約79.42ドル |
| m7g.medium | 1/4GiB | 固定性能(Arm) | 0.0527ドル | 約38.47ドル |
| c7i.large | 2/4GiB | 固定性能(Intel) | 0.11235ドル | 約82.02ドル |
表から読み取れるのは3点です。x86のまま安くするならt3a.mediumで月約3.9ドル、Arm64へ移れるならt4g.mediumで月約8.2ドル下がります。固定性能で2vCPU・4GiBをそろえるとc7i.largeで倍以上の金額になり、1vCPUで足りるならm7g.mediumがt3.mediumとほぼ同額で、クレジットを気にせず使えます。
CPUクレジットの減り方と576クレジットで続くバースト時間の計算
クレジットは概念で理解するより、数字で1回計算したほうが運用に効きます。
1クレジット=1vCPU×100%×1分の定義と1時間24クレジットの獲得
公式ドキュメントの定義では、1CPUクレジットは「1vCPUを100%で1分」使う量で、1vCPUを50%で2分でも同じです。t3.mediumの毎時24クレジットを2vCPUと60分で割ると20%になり、これがベースラインの計算式です。
貯められる上限は、24時間で獲得できる量と同じ576クレジットで、上限を超えて獲得した分は捨てられます。残高はインスタンスを停止しても7日間保持され、前世代のT2のように停止で消えることはありません。8日以上止めた検証環境で連休明けの初回ビルドだけ遅い、あるいは追加課金が出るという現象は、この仕様で説明できます。
両vCPU100%なら6時間・1vCPU張り付きなら16時間で残高が尽きる計算
残高576の状態から2vCPUとも100%で動かすと、1分あたり2クレジットを消費し、同時に0.4クレジットを獲得します。差し引き毎分1.6クレジットずつ減るので、576÷1.6=360分、6時間で残高はゼロになります。
シングルスレッドの処理が1vCPUだけを使い切る場合は、差し引き毎分0.6クレジットの減少で、576÷0.6=960分、16時間持ちます。Node.jsのように1プロセスが1スレッドで動くアプリでは、こちらが実態に近い値です。残高が満タンから始まるなら、両vCPUを使い切る処理が6時間を超えない限り、standardモードでも性能は落ちません。
unlimitedモードの追加課金を平均CPU使用率から月額で見積もる方法
T3は既定でunlimitedモードとして起動し、残高が尽きても遅くならない代わりに請求が増えます。
24時間平均が20%を超えた分にvCPU時間0.05ドルが掛かる仕組み
unlimitedモードの概念のドキュメントによると、残高を使い切った後は余剰クレジットを借りる形でバーストを続け、CPU使用率がベースラインを下回ると獲得したクレジットで返済します。24時間の平均がベースラインを超えた分は、vCPU時間あたりの定額で請求されます。
料金ページでは、T2とT3のunlimitedモードのCPUクレジットはLinux・RHEL・SLESでvCPU時間0.05ドル、Windowsで0.096ドル、T4gはLinux系で0.04ドルです。この単価は全サイズ・全購入方式・全リージョンで共通と明記されており、東京でも同額です。
平均40%で月約14.6ドル・常時100%で月約58ドルが上乗せされる試算
余剰分の月額は「(平均CPU使用率-20%)×2vCPU×730時間×0.05ドル」で近似できます。24時間平均が毎日同じ水準で続くと仮定した概算で、予算の当たりを付ける用途に向く計算です。次のPythonで、平均CPU使用率ごとの月額を一覧にできます。
# t3.medium(東京・Linux)の月額を24時間平均CPU使用率から見積もる
HOURS = 730 # AWSの月額試算で使う1か月の時間数
PRICE = 0.0544 # t3.medium 東京オンデマンド単価(USD/時)2026年9月時点
VCPU = 2
BASELINE = 0.20 # vCPUあたりのベースライン
SURPLUS = 0.05 # T3 unlimited の余剰クレジット単価(USD/vCPU時)
def monthly(avg_cpu):
extra_vcpu_hours = max(avg_cpu - BASELINE, 0) * VCPU * HOURS
return PRICE * HOURS + extra_vcpu_hours * SURPLUS
for cpu in (0.10, 0.20, 0.30, 0.40, 0.60, 0.78, 1.00):
print(f"{cpu:>5.0%} ${monthly(cpu):7.2f}")
計算結果は、平均20%以下で約39.71ドル、30%で約47.01ドル、40%で約54.31ドル、60%で約68.91ドル、常時100%で約98.11ドルです。100%に張り付くと本体の約2.5倍で、公式ドキュメントも同サイズのM5の約1.5倍を払うことになると注意しています。
固定性能のc7i.largeと月額が並ぶ損益分岐は平均CPU約78%
公式ドキュメントはt3.largeとm5.largeを例に、米国単価で損益分岐を42.5%と示しています。同じ式を東京の単価で2vCPU・4GiBの固定性能型c7i.largeに当てると、単価差0.05795ドルを0.05ドルで割って1.159vCPU時、2vCPUで割って約58%がベースラインへの上乗せ分になり、損益分岐は約78%です。
ただしc7i.largeは世代が新しく、vCPUあたりの処理性能が同じとは限りません。平均使用率が40%を超えた時点で固定性能型を候補に入れ、処理時間を測ってから判断してください。また、CPUが足りないからt3.largeへ上げるのは損な選択です。t3.mediumが平均30%で動く場合の月額は約47ドルで、t3.largeの本体約79ドルより30ドル以上安く済みます。t3.largeへ上げる理由は、メモリの8GiBが必要なときだけです。
CloudWatchとCLIでクレジット残高と追加課金を監視して設定を切り替える手順
追加課金は請求書が届くまで気付きにくい費用です。週に1回CLIで確認します。
クレジット設定のunlimitedとstandardを確認するCLIコマンド
最初に、対象インスタンスが今どちらのモードで動いているかを確かめます。describe-instance-credit-specificationsのリファレンスにあるとおり、インスタンスIDを渡すとCpuCreditsにunlimitedかstandardが返ります。
aws ec2 describe-instance-credit-specifications \
--region ap-northeast-1 \
--instance-ids i-0123456789abcdef0
T3は指定しなければunlimitedで起動し、例外はstandardが既定になるDedicated Host上のT3だけです。起動テンプレートやTerraformでcredit_specificationを明示していない環境では、ここで実際の値を確認してください。
4つのクレジット指標のうち毎週見るべき残高と課金済みクレジット
CPUクレジットの監視に関するドキュメントでは、CPUCreditUsage・CPUCreditBalance・CPUSurplusCreditBalance・CPUSurplusCreditsChargedの4指標が5分間隔で送られると説明されています。毎週見るのは、残高の最小値と課金済みクレジットの合計の2つで十分です。
# 直近7日間のクレジット残高の最小値を1時間ごとに取得する
aws cloudwatch get-metric-statistics \
--region ap-northeast-1 \
--namespace AWS/EC2 \
--metric-name CPUCreditBalance \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-09-19T00:00:00Z \
--end-time 2026-09-26T00:00:00Z \
--period 3600 \
--statistics Minimum \
--output table
# 同じ期間に課金された余剰クレジットを1日ごとに合計する
aws cloudwatch get-metric-statistics \
--region ap-northeast-1 \
--namespace AWS/EC2 \
--metric-name CPUSurplusCreditsCharged \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-09-19T00:00:00Z \
--end-time 2026-09-26T00:00:00Z \
--period 86400 \
--statistics Sum \
--output table
5分より長い期間で集計するときはAverageではなくSumを使うよう、ドキュメントに書かれています。課金済みクレジットは1クレジットが1vCPU分なので、60で割ってvCPU時間にし、0.05ドルを掛ければ金額になります。1日600クレジットなら0.5ドルです。統計値と期間の指定はget-metric-statisticsのリファレンスで確認できます。
standardへ切り替えた瞬間に未返済の余剰クレジットが課金される点
請求を固定したい環境では、modify-instance-credit-specificationでstandardに切り替えます。稼働中でも停止中でも変更でき、再起動は要りません。
aws ec2 modify-instance-credit-specification \
--region ap-northeast-1 \
--instance-credit-specifications "InstanceId=i-0123456789abcdef0,CpuCredits=standard"
注意点は切り替えのタイミングです。unlimitedからstandardへ変えると、CPUCreditBalanceは引き継がれますが、CPUSurplusCreditBalanceに残っている借りは即座に課金されます。負荷のピーク直後を避け、この値が0に戻った時間帯に実行してください。切り替え後は残高が尽きた時点でCPU性能が20%まで落ちるため、バッチの処理時間が伸びても困らない環境かどうかも先に確かめます。
t3.mediumを使い続ける条件とT8i・t4g・固定性能型へ移す判断基準
ここからは判断です。t3.mediumは万能ではありませんが、条件が合えば今でも安く使える型番です。
t3.mediumのまま据え置いてよい平均CPU20%以下の用途
24時間平均のCPU使用率が20%を下回り、CPUSurplusCreditsChargedが週を通して0なら、t3.mediumを変える理由はありません。社内向けの管理画面、利用者が数十人規模の業務Webアプリ、開発・ステージング環境、踏み台サーバーなどが該当し、型番を変えて浮く月数ドルより検証の工数のほうが高くつきます。
1台で完結する小さなWebサイトで構成を増やす予定がないなら、Lightsailの定額プランに移して運用の手間を減らす選択肢もあります。EC2との違いはAmazon Lightsailとは?EC2との違い・料金・始め方で比べています。
Arm64に移せるならt4g.mediumで月額約8ドル下がる条件
t4g.mediumはt3.mediumと同じ2vCPU・4GiB・ベースライン20%で、東京の単価は0.0432ドル、月額換算で約8.2ドル安くなります。unlimitedの余剰クレジットもvCPU時間0.04ドルとT3より2割安く、しかもT4gのvCPUはスレッドではなくコア単位です。
移行の壁はアーキテクチャです。x86_64向けのバイナリやコンテナイメージはArm64でそのまま動かず、Arm64用のAMIから起動し直す作業になります。PHP・Python・Node.js・Javaは移しやすい一方、ネイティブ拡張やベンダー製のエージェントを含む構成は、Arm64版の有無を先に確認してください。
T8i.mediumは単価2割高で性能最大7割増の新世代という位置づけ
2026年9月17日のAWSの発表で、第6世代Intel Xeon(Granite Rapids)を積んだT8iが東京を含むリージョンで一般提供されました。T3と比べて価格性能が最大30%、計算性能が最大70%、ネットワーク帯域が1.25倍、EBS帯域が2.4倍とされています。サイズはnano・micro・small・mediumの4つで、large以上のサイズは用意されていません。
東京のt8i.mediumは0.06528ドルで、t3.mediumのちょうど1.2倍です。x86_64のままでイメージの作り直しが要らないため、CPUクレジットが尽きて困っている環境なら最初に試す候補として検討できます。平均20%以下の環境を移しても、月約8ドル高くなるだけです。なお発表ブログの仕様表はt8i.mediumの獲得クレジットを毎時12としていますが、ユーザーガイドは毎時24・上限576で、ベースライン20%の計算式と合うのは後者です。Savings Plansは2026年9月時点で「近日対応」のため、長期割引を前提にした見積もりにはまだ使えません。
t3.mediumを本番に置くべきでないワークロードと見送る判断
次の3つに当てはまるなら、t3.mediumは本番に置きません。1つ目は、24時間平均が40%を超えるAPIサーバーやバッチです。月額が50ドルを超え、性能の読みにくさだけが残ります。2つ目は、DBを同居させた構成です。MySQLやPostgreSQLのバッファにメモリ4GiBは小さく、CPUクレジットの枯渇とメモリ不足が同時に起きたとき、どちらが原因か切り分けにくくなります。3つ目は、スポットインスタンスで短時間だけ動かす処理で、クレジットを貯める前に終了するためT系の利点が出ません。
これらのワークロードは、平均使用率を測ったうえでM系・C系の固定性能型か、処理単位で課金されるサービスへ移すのが筋です。EC2全体の料金モデルと採用判断はAmazon EC2とは?仕組み・インスタンスタイプと料金モデル・採用判断にまとめています。稼働中の構成を測って型番と台数を組み替える作業は、AWS・Google Cloud・Azureのインフラ構築支援で現状の計測から引き受けています。
よくある質問
t3.mediumの選定と運用で寄せられやすい疑問を5つ取り上げます。
t3.mediumは無料利用枠の対象になりますか?
t3.mediumは無料利用枠の対象として案内されていません。T8iの発表ブログでも、対象はt8i.microとt8i.smallだと書かれています。無料利用枠の条件はアカウントの作成時期で変わるため、aws ec2 describe-instance-types --filters Name=free-tier-eligible,Values=trueで自分のアカウントの対象型番を一覧にして判断してください。
t3.mediumとt3a.mediumは何が違いますか?
t3.mediumはIntel Xeon Platinum 8000シリーズ(最大3.1GHz)、t3a.mediumはAMD EPYC 7000シリーズ(最大2.5GHz)を積んでいます。vCPU・メモリ・クレジットの仕様は同じで、東京の単価はt3a.mediumが0.0490ドルと約1割安くなります。どちらもx86_64なのでタイプの変更だけで移れますが、クロックが低い分、シングルスレッド性能に依存する処理は先に処理時間を測ってください。
t3.mediumのCPUクレジットが0になるとどうなりますか?
standardモードでは、CPU性能がベースラインの20%まで徐々に落ち、クレジットが貯まるまでそれ以上は出ません。Webアプリなら応答が急に遅くなる形で表に出ます。unlimitedモードでは性能は落ちず、余剰クレジットを借りてバーストを続ける仕組みです。24時間の平均がベースラインを超えた分は、vCPU時間0.05ドルで請求に加算されます。どちらのモードかはdescribe-instance-credit-specificationsで確認できます。
リザーブドインスタンスやSavings Plansで追加課金も安くなりますか?
安くなるのはインスタンス本体の時間単価だけです。料金ページには、unlimitedモードのCPUクレジット単価がオンデマンド・スポット・リザーブドインスタンスで共通だと書かれており、長期契約でも追加課金は同じ額のまま残ります。契約前に1か月分のCPUSurplusCreditsChargedを確認し、追加課金が出ない型番へ選び直しておくほうが確実です。
t3.mediumからt3.largeへの変更に停止は必要ですか?
EBSをルートボリュームにしたインスタンスでは、停止してからタイプを変更し、再度起動します。本番ではロードバランサー配下で1台ずつ切り替えるか、メンテナンス時間を確保してください。停止から起動までが7日以内なら、クレジット残高は失われません。変更の具体的な手順とCLIのコマンドはEC2インスタンスタイプの選び方の後半で扱っています。
関連記事
- EC2インスタンスタイプの選び方:命名規則の読み方とCLI絞り込み・変更手順:ファミリー選定とタイプ変更手順
- インスタンスタイプとは?AWS・Azure・Google Cloudの命名規則と選定手順:他クラウドの近い型番の探し方
- Amazon EC2とは?仕組み・インスタンスタイプと料金モデル・採用判断:EC2の5つの料金モデル
- Amazon Lightsailとは?EC2との違い・料金・始め方:定額プランという選択肢
- AWSの見積もりとは?料金計算ツールの使い方と費用が変わる要因:付帯費用を含めた見積もり