1.はじめに
こんにちは！今年社会人５年目を迎える新保です。
近年、AWSをはじめとしたクラウドの普及によって、インフラ構築やシステム運用は劇的に楽になりました。
一方で「気づいたら請求額がとんでもないことに…」という声もよく耳します。
私自身が過去関わったことのあるお客様でも同じ事象が発生し、CFM (Cost Financial Management）という形で携わらせていただき、年間約1億円のコスト削減を実現しました。
この記事では私自身の経験をもとに、サービスのコスト構造を改めて整理し、「どこでコストが増えやすいのか」、「どうやってそれを抑えるのか」を実際によくあるユースケースとともに解説できればと思います。コスト削減を実施したサービスのうち、今回はS3を紹介させていただきます。
エンジニアだけでなく、クラウド運用関わる全ての方にとって、請求書を開くのが怖くなくなるヒントになれば嬉しいです
2.今回解説するサービス：Amazon S3とは？
AmazonS3は、AWSが提供するオブジェクトストレージサービスです。用途は幅広く、次のようなシーンで活用されています。
- ログ・バックアップ・データーの長期保管
- ビックデータ処理やデータレイクのデータソース
- 静的ウェブサイトのホスティングなど
特徴的なのは次の3点です
- 高い耐久性（99.9999999999%)と可用性
- 容量無制限
- 使った分だけ課金される重量課金モデル
便利で柔軟な一方、S3には目に見えにくいコストの落とし穴があります。
課金ポイントをきちんと理解しておくことが、運用中の無駄を防ぐ最初の一歩になります
3. Amazon S3のコスト内訳
S3のコストは主に次の3つで構成されています。なお単価はすべて東京リージョンを前提とします
| # | コスト項目 | 課金指標 | 単価（2025年時点） |
|---|---|---|---|
| ① | 保存量 | GB・月 | $0.025/GB (S3 Standard) |
| ② | APIリクエスト | 1,000あたり | $0.0047（PUT/LIST等） |
| ③ | データ転送量（OUT） | GB（リージョン外、インターネット） | $0.114/GB（10TBまで） |
正式な価格は、以下公式料金ページをご確認ください
4. 料金が膨らむユースケース及び対応方法（コスト項目毎）
①保存量
ケース1：バージョニング有効化により、削除済みと認識していたファイルが実は残っていた
■シナリオ: システムログをS3へアップロード。一定期間過ぎたものは削除するようライフサイクルールを設定していたが、削除したつもりのファイルも”旧バージョン”として残っていた
※「バージョニング」とは？
S3バケットに保存したファイルの変更履歴を自動で残す機能。これによりS3内のファイルを上書きや削除をしても、過去バージョンへ戻すことが可能
■落とし穴： バージョン管理が有効なバケットでは、通常のExpirationではオブジェクトの「削除マーカー」が追加されるだけで、旧バージョンはそのまま残る
■対応方法：
- 旧バージョンのオブジェクトも削除されるよう、バージョニング有効時は、「NoncurrentVersionExpiration」の設定要否を検討する
- バージョニングが本当に必要かを検討（不要であればバケット単位で無効化する）
ケース2：ストレージ料金削減のためライフサイクル設定をしているのに、コストが全然削減されない
■シナリオ： CloudtrailやアプリログをS3に保管しており、コスト最適化のためにライフサイクルルールでIntelligent-Tiering→Glacier Deep Archiveに自動移行するよう設定済み。ログファイルは500KB未満のものが1日数十万件生成されおり、請求額を確認すると月々のS3コストほとんど下がっていない
■落とし穴：
- Intelligent-Tieringには監視コスト（$0.0025/1,000オブジェクト）がかかる
- ライフサイクルの移行処理にも移行リクエスト課金（Glacier Deep Archiveの場合、$0.065/1,000オブジェクト）が発生
- 小さいファイルを大量に扱う場合、保存料金よりもリクエスト料金の方が高くつくこともある
■対応方法：
- 「サイズが小さいオブジェクト」については、ライフサイクルルールを適用しない
- ログファイルをまとめて圧縮・集約してから保存する（例：gzip+日次まとめ書き）
②APIリクエスト
ケース3：点列センサーデータを収集していたら、月数百ドルになっていた
■シナリオ： スマートファクトリーや車から上がってくるIoTのセンサーデータをS3にて集約。センサーデータは秒間の点列データとして上がってきており、1件ずつS3に直接PUTされている。「S3は安価で、処理速度も速いため問題ない」と思っていたが、請求を確認すると月数百ドルかかっていることが判明
■落とし穴：
- S3はストレージ料金としては安価だが、APIのリクエスト（PUTリクエスト）は、$0.0047/1000回と、PUT量が多い場合無視できないレベルに
- 特にIoTデータの収集では「小さなデータを高頻度で送る」構造上、意図せず高額になるパターンが多い
■対応策：
- Amazon Data Firehoseなどを活用して、一定サイズ（例：5MB）や一定時間ごとにまとめてPUTする
- あるいは1件ごとではなく1000件単位でまとめられると、PUT回数を1/1,000以下に圧縮
- 一方でFirehose自体にもコストが発生する（$0.029/GB）ので、場合によってはデータを上げる側である程度まとめて送信することも要検討
③データ転送量
ケース4：静的サイトを公開したら、転送コストが大変なことに
■シナリオ： 企業の製品ページやキャンペーンサイトなどを、手軽さを重視してS3の静的ホスティングで公開。公開後に画像やHTMLなどの合計で数TBのトラフィックが発生。インフラ費用は最小構成だから大丈夫だろうと思っていたが、S3からのデータ転送コストが高額になっていることが判明
■落とし穴：
- S3は「静的ホスティング」機能があり、外部公開も簡単だが、転送先がインターネット（リージョン外）だとインターネット向けのデータ転送量が発生（$0.09/GB）
■対応策：
- CloudfrontをS3の前段に配置し、静的ファイルをエッジキャッシュ経由で配信（S3からの転送頻度を減少）
- Cloudfrontキャッシュの転送単価はS3よりも安価（初回1TB/月は無料枠あり、それ以降は$0.085/GB~)
- キャッシュ設定を最適化することで（max-age等）、CDNキャッシュ率を高めることができ、さらなるコスト削減も可能
5. まとめ
S3は従量課金の仕組みで基本単価も低めです。しかし、実際に運用してみると、保存料よりリクエスト課金や転送課金のほうが高くなるケースも少なくありません。
そのため見えづらいコスト構造を理解し、日々の運用の中で見直していきましょう。
Discussion