AWS コスト最適化 on Ubuntu — Cost ExplorerとInfrastructure最適化

この記事のポイント

Ubuntu 24.04 LTS では apt から awscli が入りません（Candidate が (none)・2026-06-15 実測）。python3-venv + pip install awscli が正攻法です
AWS Cost Explorer の CLI コマンドで請求データを JSON 取得 → jq で整形 → cron で月次自動記録、という流れを Ubuntu の端末だけで組めます
日本から各リージョンへ ping した実測では、東京 18.0ms / 大阪 23.1ms に対しバージニア北部は 185.0ms（約10倍）。リージョン選びだけで体感が変わります
EC2 オンデマンドの実価格（公式 Price List API）では、Graviton（ARM64）の t4g.micro が $0.0108/hr。同等の Intel t3.micro より約20%安いことを確認しました

注意

本記事は Ubuntu 24.04 LTS（公式Dockerイメージ・arm64）で検証しています。AWS Cost Explorer CLI を使うには有効な AWS アカウントと IAM ユーザーのアクセスキー、そしてコストデータへの ce:GetCostAndUsage 権限が必要です。Cost Explorer の API 呼び出しは1回あたり $0.01 課金される点にも注意してください。

AWSのコスト、どこから削ればいいの？
Ubuntu 24.04 に AWS CLI をインストールする
Cost Explorer CLI でコストデータを取得する
リージョン選びで損をしないために（実測レイテンシ）
EC2の料金を実価格で把握する（公式API実測）
Graviton（ARM64）への移行でコスト削減
Ubuntu スクリプトでコスト監視を自動化する
コスト最適化チェックリスト
まとめ

AWSのコスト、どこから削ればいいの？

「気づいたら AWS の請求が思ったより高くなっていた」というのは、AWS を使い始めた人によくある悩みです。EC2 インスタンスを起動したまま放置したり、リージョンを深く考えずに選んでいたりすると、じわじわとコストが積み上がっていきます。

AWS コスト最適化の第一歩は、まず「現状を数字で把握する」ことです。 AWS Cost Explorer という無料ツール（コストの可視化・分析サービス）がそれを助けてくれます。Cost Explorer は AWS マネジメントコンソールから使えるほか、CLI 経由でもコストデータを JSON 形式で取得でき、Ubuntu の端末から jq（JSON整形コマンド）と組み合わせてレポートを自動化することも可能です。

この記事では、Ubuntu 24.04 LTS に AWS CLI をインストールする手順から、Cost Explorer での分析、リージョン選び、そして EC2 の実価格にもとづく Graviton 移行まで、実際にコマンドを動かして確認した結果をお伝えします。料金やレイテンシの数字は、想像ではなく公式 API や ping の実測値です。

正直、「コスト最適化」って難しそうに聞こえますが、最初にやることはシンプルです。Cost Explorer でどのサービスがいくら使っているかを見て、止められるものを止める——それだけでかなり変わります。あとはリージョンと CPU の選び方で、何もしなくても2割くらい変わってきます。

Ubuntu 24.04 に AWS CLI をインストールする

①まず apt で試してみると…

Ubuntu ユーザーなら最初に sudo apt install awscli を試すと思いますが、Ubuntu 24.04 LTS では awscli は apt から入りません。公式 Docker イメージ ubuntu:24.04 で実際に確認すると、Candidate が (none) になっていました（2026-06-15 実測）。

Ubuntu 24.04 への AWS CLI インストール（apt不可→venv+pip、実測）

ubuntu@linuxlab: ~

$ apt-cache policy awscli
awscli:
Installed: (none)
Candidate: (none)
Version table:
$ apt-get install -y awscli
E: Package ‘awscli’ has no installation candidate

ちなみに Ubuntu 22.04（jammy）では awscli 1.22.34-1 が universe リポジトリに残っていました。24.04 で消えたパッケージなので、22.04 の感覚で進めると詰まります。

ubuntu@linuxlab: ~（22.04コンテナ）

$ apt-cache policy awscli
awscli:
Installed: (none)
Candidate: 1.22.34-1
1.22.34-1 500 http://ports.ubuntu.com/ubuntu-ports jammy/universe

②推奨インストール方法：python3-venv + pip

Ubuntu 24.04 には Python 3.12.3 が標準搭載されていますが、システムの Python に pip install を直接使うと PEP 668 のエラーが出ます。これは「OSが管理する Python 環境を pip で壊さないための保護機能」で、24.04 から有効になりました。仮想環境（venv）を使うのが正しい方法です。

ubuntu@linuxlab: ~

# システムpipに直接入れようとすると弾かれる
$ pip install awscli
error: externally-managed-environment

# 必要なパッケージを入れる
$ sudo apt update && sudo apt install -y python3 python3-venv jq curl unzip
$ python3 –version
Python 3.12.3
$ jq –version
jq-1.7

# venv 仮想環境を作って、その中で pip install する
$ python3 -m venv ~/.aws-env
$ source ~/.aws-env/bin/activate
(aws-env) $ pip install awscli
(aws-env) $ aws –version
aws-cli/1.45.29 Python/3.12.3 Linux/5.10.76-linuxkit botocore/1.43.29

インストールが確認できたら、AWS の認証情報を設定します。アクセスキーは AWS マネジメントコンソールの IAM で発行したものを使います。

ubuntu@linuxlab: ~

(aws-env) $ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: ****************************
Default region name [None]: ap-northeast-1
Default output format [None]: json

リージョンは ap-northeast-1（東京）か ap-northeast-3（大阪）を指定します。理由は後のセクションで実測値とともに説明します。設定は ~/.aws/credentials と ~/.aws/config に保存されます。

③ AWS CLI v2 公式バイナリのインストール（別の方法）

最新の AWS CLI v2 を使いたい場合は、AWS 公式の Linux バイナリインストーラーを使います。ここで重要なのが CPU アーキテクチャの確認です。

ubuntu@linuxlab: ~

# まず自分のアーキテクチャを確認する
$ uname -m
x86_64 # ← または aarch64

# x86_64 の場合
$ curl -sL “https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip” -o awscliv2.zip
$ unzip awscliv2.zip && sudo ./aws/install

# ARM64 (Graviton / Raspberry Pi) の場合
$ curl -sL “https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip” -o awscliv2.zip
$ unzip awscliv2.zip && sudo ./aws/install

注意：アーキテクチャを間違えると動きません

uname -m が x86_64 なら x86_64 用、aarch64 なら aarch64 用をダウンロードしてください。ARM64 環境（Graviton インスタンスや一部のVPS）で x86_64 バイナリを実行するとエラーになります。後述の Graviton 移行をする人ほど、ここは要注意です。

Cost Explorer CLI でコストデータを取得する

AWS CLI のインストールが終わったら、Cost Explorer コマンドでコストデータを取得します。流れとしては「aws ce get-cost-and-usage で JSON を取る → jq でサービス別に整形する → 高い順に把握する → cron で月次自動化する」というイメージです。

Cost Explorer は AWS マネジメントコンソールにも GUI があります。CLI の前に、まずは公式ページで雰囲気を掴んでおくと理解が早いです。

AWS Cost Explorer 公式ページ（Playwright実撮影、2026-06-15）

出力例について

以下のコマンド出力は、Cost Explorer API が返すJSONの構造を示した例です（金額はサンプル値）。実際の数字は、あなた自身の AWS アカウント・IAM権限で取得した値に置き換わります。コマンドの形と jq での整形方法を確認するために載せています。

手順1：先月のコスト合計を取得する

ubuntu@linuxlab: ~

(aws-env) $ aws ce get-cost-and-usage \
–time-period Start=2026-05-01,End=2026-06-01 \
–granularity MONTHLY \
–metrics “BlendedCost” \
–output json | jq ‘.ResultsByTime[0].Total.BlendedCost’
# ↓ 返ってくるJSONの構造（金額は例）
{“Amount”: “47.23”, “Unit”: “USD”}

手順2：サービス別のコスト内訳を確認する

--group-by で SERVICE 軸に分解すると、どのサービスにいくらかかっているかが分かります。

ubuntu@linuxlab: ~

(aws-env) $ aws ce get-cost-and-usage \
–time-period Start=2026-05-01,End=2026-06-01 \
–granularity MONTHLY –metrics “BlendedCost” \
–group-by Type=DIMENSION,Key=SERVICE \
–output json | jq ‘.ResultsByTime[0].Groups[] | {service: .Keys[0], cost: .Metrics.BlendedCost.Amount}’
# ↓ 構造の例（jq で整形した結果。金額はサンプル）
{“service”: “Amazon EC2”, “cost”: “28.15”}
{“service”: “Amazon RDS”, “cost”: “12.40”}
{“service”: “Amazon S3”, “cost”: “4.32”}
{“service”: “AWS Data Transfer”, “cost”: “2.36”}

多くの個人開発者の環境では、EC2 が最大のコスト要因になりがちです。EC2 が高い場合は、後述する「放置インスタンスの停止」「リージョン集約」「Graviton への移行」が効いてきます。

手順3：放置インスタンスを洗い出す

コスト削減で一番効くのは、実は「使っていないのに起動したままのインスタンスを止める」ことです。describe-instances で稼働中のものを一覧にします。

ubuntu@linuxlab: ~

ここで「テスト用に起動したまま忘れていた」インスタンスが見つかったら、すぐ停止・終了しましょう。後述の実価格では t3.micro でも動かし続けると月 $9.93、m5.large なら月 $90 を超えます。1台でも止める価値は大きいです。

リージョン選びで損をしないために（実測レイテンシ）

AWS のリージョン選びは、コストと性能の両面に効きます。日本から使うならどのリージョンが有利なのか、各リージョンの S3 エンドポイントへ実際に ping を10回ずつ打って計測しました（macOSホストから・パケットロス0%）。

ubuntu@linuxlab: ~

$ ping -c 10 s3.ap-northeast-1.amazonaws.com # 東京
round-trip min/avg/max = 9.3/18.0/.. ms
$ ping -c 10 s3.ap-northeast-3.amazonaws.com # 大阪
round-trip min/avg/max = ../23.1/.. ms
$ ping -c 10 s3.ap-southeast-1.amazonaws.com # シンガポール
round-trip min/avg/max = ../92.7/.. ms
$ ping -c 10 s3.us-east-1.amazonaws.com # バージニア北部
round-trip min/avg/max = ../185.0/.. ms

実測結果をまとめると、こうなりました：

東京（ap-northeast-1）：avg 18.0ms — サービス数が最も多く、まず第一候補
大阪（ap-northeast-3）：avg 23.1ms — 国内のもう一つの選択肢
シンガポール（ap-southeast-1）：avg 92.7ms — 約5倍の遅延
オレゴン（us-west-2）：avg 149.5ms
バージニア北部（us-east-1）：avg 185.0ms — 日本からは約10倍
アイルランド（eu-west-1）：avg 302.9ms — 約17倍

よくある落とし穴

AWS の公式チュートリアルやブログ記事では us-east-1（バージニア北部）がデフォルトとして使われがちです。日本のユーザーが何も考えず同じ設定でサービスを立ち上げると、レイテンシが東京の約10倍（185ms 対 18ms）になります。リージョンは必ず ap-northeast-1 か ap-northeast-3 を指定しましょう。

また、リージョン間のデータ転送は課金対象です。東京リージョン内での転送は無料ですが、東京↔バージニア間のような跨ぎ転送には $0.09/GB ほどかかります。複数リージョンに散らばったリソースを東京に集約するだけでもコスト削減になります。

EC2の料金を実価格で把握する（公式API実測）

コスト最適化を考えるうえで、インスタンスタイプごとの実価格を知っておくと判断が速くなります。AWS が公開している Price List API（認証不要の公式価格表）から、東京リージョンの EC2 オンデマンド（Linux）の実価格を取得しました（2026-06-12版を 2026-06-15 に取得）。

ubuntu@linuxlab: ~

# 公式の公開価格表（認証不要）から東京リージョンの価格表URLを取得
$ curl -s “https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/\
AmazonEC2/current/region_index.json” | jq -r ‘.regions[“ap-northeast-1”].currentVersionUrl’
/offers/v1.0/aws/AmazonEC2/20260612073040/ap-northeast-1/index.json
# この価格表から t3.micro / t4g.micro のオンデマンド定価を抽出した実測値:
$0.0136 per On Demand Linux t3.micro Instance Hour
$0.0108 per On Demand Linux t4g.micro Instance Hour

月額は 730 時間（ほぼ1か月フル稼働）で換算した参考値です。実際は使った秒数ぶんの課金になります。t3.micro でも常時起動なら月 $9.93、m5.large は月 $90.52 と、放置するとそれなりの金額になることが分かります。

スポットインスタンスについて

さらに安く使う手段としてスポットインスタンス（AWSの余剰キャパシティを割安で借りる仕組み）があります。中断されても再実行できるバッチ処理・CI/CDビルド・機械学習の学習ジョブなどに向いています。ただしスポット価格の取得には IAM 認証（aws ec2 describe-spot-price-history）が必要なため、本記事では認証不要で誰でも確認できるオンデマンド定価を基準に解説しています。スポットはこのオンデマンド価格からさらに大きく割引されるイメージで捉えてください。

Graviton（ARM64）への移行でコスト削減

AWS Graviton は Amazon が独自開発した ARM64 プロセッサです。先ほどの実価格データで Intel 系と Graviton 系を並べると、同じ vCPU / メモリでも Graviton 系（t4g・m6g・c6g）は一貫して約20%安いことが分かりました。Ubuntu 22.04 / 24.04 は ARM64（aarch64）に完全対応しているので、移行に特別な作業はほとんど要りません。

インスタンス	アーキテクチャ	vCPU / RAM	オンデマンド/hr	月換算(730h)	対 Intel 比
t3.micro	Intel x86_64	2 / 1 GiB	$0.0136	$9.93	基準
t4g.micro ★	ARM64 (Graviton2)	2 / 1 GiB	$0.0108	$7.88	−21%
t3.small	Intel x86_64	2 / 2 GiB	$0.0272	$19.86	基準
t4g.small ★	ARM64 (Graviton2)	2 / 2 GiB	$0.0216	$15.77	−21%
m5.large	Intel x86_64	2 / 8 GiB	$0.124	$90.52	基準
m6g.large ★	ARM64 (Graviton2)	2 / 8 GiB	$0.099	$72.27	−20%

出典：AWS Price List API（ap-northeast-1・OnDemand・Linux、2026-06-15 取得）。t4g.micro は t3.micro に対して約21%安く、m6g.large は m5.large に対して約20%安いという結果でした。AMD系の t3a.micro（$0.0122）も Intel より1割ほど安いですが、Graviton がさらに一歩リードしています。

移行の流れは、インスタンスを停止 → AMI（スナップショット）取得 → ARM64 対応 AMI をもとに t4g 系でインスタンスを作り直す、というものです。Ubuntu の公式 AMI は x86_64・ARM64 どちらも提供されているので、同じ感覚で立て直せます。アプリが純粋な Python / Node.js / Go などで書かれていれば、たいてい再ビルドだけで動きます。

Ubuntu スクリプトでコスト監視を自動化する

Cost Explorer の CLI を使えば、コスト監視を Ubuntu の cron ジョブで自動化できます。毎月のサービス別コストをログに残しておけば、急に増えたときにすぐ気づけます。

手順1：月次コストレポートスクリプトを作成する

ubuntu@linuxlab: ~

$ cat > ~/cost_report.sh <<‘EOF’
#!/bin/bash
source ~/.aws-env/bin/activate
START=$(date -d “$(date +%Y-%m-01) -1 month” +%Y-%m-%d)
END=$(date +%Y-%m-01)
echo “=== AWS コスト集計 ${START} 〜 ${END} ===”
aws ce get-cost-and-usage \
–time-period Start=$START,End=$END \
–granularity MONTHLY –metrics “BlendedCost” \
–group-by Type=DIMENSION,Key=SERVICE \
–output json | jq -r ‘.ResultsByTime[0].Groups[] | “\(.Keys[0]): $\(.Metrics.BlendedCost.Amount)”‘
EOF
$ chmod +x ~/cost_report.sh

手順2：cron で毎月1日に自動実行する

ubuntu@linuxlab: ~

$ crontab -e
# 毎月1日 09:00 にレポートを ~/cost_log.txt に追記
0 9 1 * * /home/ubuntu/cost_report.sh >> ~/cost_log.txt 2>&1

注意：API課金とループ

Cost Explorer の API（ce:GetCostAndUsage）は呼び出し1回あたり $0.01 課金されます。月1回の cron なら誤差ですが、スクリプトで短い間隔のループに入れると地味に効いてくるので、無制限に叩かないよう注意してください。

CPU性能の参考値（Docker ubuntu:24.04 実測）

「どのくらいの性能のインスタンスを選ぶか」を考える出発点として、手元の ubuntu:24.04 コンテナで sysbench CPU ベンチを3回計測しました。avg 15,579 events/sec（Run1: 15,485 / Run2: 15,560 / Run3: 15,693）。EC2 のバースト型（t系）はCPUクレジットの挙動が異なるため、あくまで比較の出発点として捉えてください。

sysbench CPU実測（ubuntu:24.04 Docker / 3回計測）

コスト最適化チェックリスト

ここまでの内容を、効果の大きい順に整理しました。上から順に手を付けると効率的です。

最初にやるのは「現状把握」と「放置インスタンスの停止」。次に「リージョンを東京/大阪に寄せる」「Graviton への移行」。最後に「cron での自動監視」と「予算アラート」です。料金の確認は、AWS の EC2 オンデマンド料金ページからいつでもできます。

Amazon EC2 オンデマンド料金公式ページ（Playwright実撮影、2026-06-15）

まとめ

Ubuntu 24.04 LTS で AWS コスト最適化に取り組む方法を、実測値ベースでまとめました。

Ubuntu 24.04 では awscli は apt から入らない（Candidate が none）。python3-venv + pip install awscli が正攻法。システムpip直は PEP668 で弾かれる
AWS Cost Explorer CLI でサービス別コストを JSON 取得 → jq で整形して把握する。cron で月次自動化できる
日本から使うなら東京（avg 18.0ms）か大阪（avg 23.1ms）一択。バージニア北部は avg 185ms と約10倍の遅延（実測）
EC2 オンデマンドの実価格は t3.micro が $0.0136/hr（月 $9.93）。放置インスタンスを止めるだけで効果が大きい
Graviton（ARM64）の t4g・m6g・c6g は同等の Intel 系より一貫して約20%安い。Ubuntu は ARM64 完全対応で移行が楽
本格的に運用するなら、まずは安価な VPS で Ubuntu サーバー運用に慣れてから AWS に広げるのもおすすめです

AWS をいきなり本番運用するのが不安なら、月数ドルの VPS で Ubuntu サーバーの基本（SSH・systemd・cron）に慣れておくと、AWS に移ったときの理解がぐっと深まります。

Vultr 公式サイトでプランを確認する →

DigitalOcean でVPSを試してみる →