気づかないうちに増えるAWSコスト Top10

AWSの請求書は、EC2やRDSといった「主役」のコストだけでは説明がつかないことがあります。厄介なのは、時間課金・リクエスト課金・データ処理課金といった従量部分が、構成を変えていないのに静かに積み上がっていく点です。この記事では、EMWがコスト最適化の現場で繰り返し遭遇する「気づかないうちに増えるコスト源」を10個に絞り、なぜ増えるのかと、その対策をセットで整理します。

01NATゲートウェイ：時間課金とデータ処理課金の二重取り

コスト最適化の相談で最初に指摘することが多いのが、NATゲートウェイです。NATゲートウェイの料金は「起動している時間あたりの課金」と「処理したデータ量(GB)あたりの課金」の二本立てで、後者を見落とすと請求が読めなくなります。時間課金は1台あたり、東京リージョン(ap-northeast-1)で0.062ドル/時(月約45ドル)、us-east-1で0.045ドル/時(月約33ドル)と、単体ではさほど大きく見えないかもしれませんが、プライベートサブネットからインターネットに抜けるトラフィックすべてにGB単価が乗ります。

特に落とし穴になるのが、S3やDynamoDBといった同一リージョンのAWSサービス宛て通信です。VPCエンドポイントを張っていないと、これらの通信もNATゲートウェイを経由し、データ処理課金の対象になります。ECRからのイメージpull、yum/aptのアップデート、CloudWatchへのログ送信など、地味なトラフィックが積み上がります。

現場のコツ：S3とDynamoDBは「ゲートウェイ型VPCエンドポイント」を張れば無料で経路をNATから外せます。まずここだけでも効きます。ECR・SSM・CloudWatch Logsなどは「インターフェース型エンドポイント」で外せますが、こちらは時間課金とデータ処理課金があるため、トラフィック量との損益分岐を見て判断します。

マルチAZ構成で各AZにNATを置くのはSPOF回避として正しい設計ですが、開発・検証環境では1台に集約する、あるいはNATインスタンスに切り替えるといった割り切りも選択肢です。詳細はNATゲートウェイのコスト設計で掘り下げています。

02データ転送：AZ間・リージョン間・インターネットegress

AWSのデータ転送課金は、方向と経路で単価が変わる典型的な「読みにくいコスト」です。押さえるべき原則は3つです。インターネットへのegress(外向き)は課金対象、AZをまたぐ通信は往復とも課金対象、リージョンをまたぐ通信はさらに高い、という点です。逆に、同一AZ内かつプライベートIP経由の通信は無料です。

AZ間通信：EC2とRDS、EC2同士、EKSのPod間などがAZをまたぐと、送信・受信の両側で課金されます。可用性のためのマルチAZは必要ですが、「たまたま別AZに配置されて無駄に往復している」構成は見直す価値があります。
インターネットegress：ユーザー向けの配信量が多いなら、CloudFrontを挟むことでegress単価を下げられるケースがあります。オリジンがAWS内なら、オリジン向け転送が優遇される点も効きます。
NAT経由の外向き通信：01で触れたNATのデータ処理課金と、このegress課金は別物として両方乗ります。二重に効いていることを認識しておく必要があります。

図：同一AZ内のプライベート通信は無料。AZ間は往復とも課金、リージョン間はさらに高単価、インターネットへのegressも課金対象になります。

03S3：リクエスト課金とストレージクラスの選択ミス

S3は「保存容量が安い」という印象が先行しますが、実務で効いてくるのはリクエスト課金です。PUT/GET/LISTなどのAPIコール数に応じて課金され、単価はストレージクラスによって変わります。小さなオブジェクトを大量に読み書きするワークロード(ログの細切れ書き込み、サムネイル生成、頻繁なポーリング)では、ストレージ代よりリクエスト代が上回ることが珍しくありません。

もう一つの落とし穴がストレージクラスの取り違えです。アクセス頻度が低いからと安易にGlacier系へ落とすと、取り出し(リストア)時に高い取得料金と待ち時間が発生します。また、Standard-IAや1ゾーンIAには最小オブジェクトサイズ・最小保管期間の課金ルールがあり、小さいファイルや短命なファイルをここに置くとかえって割高になります。

現場のコツ：アクセスパターンが読めないバケットは、まず「S3 Intelligent-Tiering」に寄せると判断を自動化できます。加えて、ライフサイクルルールで不完全なマルチパートアップロードの残骸を自動削除しておくと、見えない容量課金を防げます。設計思想はS3データレイク設計も参考にしてください。

04CloudWatch：ログ取込・カスタムメトリクス・ダッシュボード

監視は入れた方がよいものですが、CloudWatchは「入れっぱなし」で静かに増えるコストの代表格です。効いてくるのは主に3つです。

ログ取込(Ingestion)：CloudWatch Logsは取り込んだGB量に対して課金されます。DEBUGログを本番で流しっぱなしにする、アクセスログを全量送るといった構成で膨らみます。リアルタイム性が不要なログは「Infrequent Access」ログクラスに寄せると取込単価を抑えられます。
カスタムメトリクス：1メトリクスあたりの月額課金です。EC2の詳細モニタリングや、アプリから大量のディメンション付きメトリクスをPutMetricDataすると、メトリクス数が指数的に増えて効いてきます。
ダッシュボード：無料枠を超えたダッシュボードは1枚あたり月額で課金されます。使われていない古いダッシュボードが放置されがちです。

加えて、Logs Insightsのクエリはスキャンしたデータ量で課金されるため、広い期間を何度も舐めるクエリはコストになります。保持期間(リテンション)を無期限のまま放置すると、保管料も積み上がります。監視の入り口の考え方はCloudWatch監視のはじめの一歩、アラート設計は監視設計の型で整理しています。

05EBSスナップショットの肥大と、放置される「未使用」リソース

EBSスナップショットは増分バックアップなので「1世代目以降は差分だけ」と説明されますが、実務では削除ポリシーが甘いと世代が無限に積み上がります。特にData Lifecycle Manager(DLM)やバックアップツールで日次スナップショットを取りつつ、削除ルールを入れていないと、静かに容量課金が伸びていきます。AMIを消してもその裏のスナップショットが残る、というのもよくある取りこぼしです。

あわせて棚卸ししたいのが、以下の「動いていないのに課金される」リソース群です。

未アタッチのEBSボリューム：インスタンスを消してもボリュームが残り、容量課金が続きます。
未解放のパブリックIPv4(Elastic IP)：2024年2月1日以降、EIPを含むすべてのパブリックIPv4アドレスは、稼働中インスタンスへの割り当ての有無にかかわらず0.005ドル/時が課金されます(EC2の無料利用枠は最初の12か月・月750時間まで対象)。使っていないアドレスは棚卸しして解放するのが基本です。
古いAMIとその裏のスナップショット：世代管理していないと際限なく残ります。

現場のコツ：これらは「AWS Trusted Advisor」や「Cost Optimization Hub」で機械的に洗い出せます。ボリューム選定そのものの考え方はEBSボリューム選定を参照してください。棚卸しは一度やって終わりではなく、タグ運用とセットで定期的に回す仕組みにするのが肝心です。

06RDS：バックアップ超過とプロビジョンドIOPS

RDSで見落としやすいのがバックアップストレージです。自動バックアップは「DBインスタンスの割当ストレージ量まで」は無料ですが、それを超えたバックアップ保管や、手動スナップショットの積み上げは課金対象です。保持期間を長めに設定していると、想定より早く無料枠を超えます。停止したはずのRDSも、7日で自動起動する仕様やスナップショット保管で費用が残る点に注意が必要です。

もう一つがストレージタイプの選択です。プロビジョンドIOPS(io1/io2)はIOPSを確保する分だけ課金され、実際の負荷が低ければ過剰投資になります。多くのワークロードは汎用SSD(gp3)で足り、gp3ならベースライン性能に加えてIOPS・スループットを必要な分だけ追加できます。旧世代のgp2から移行するだけでコストと性能のバランスが改善するケースは多いです。

07ELB：LCU課金という見えにくい従量部分

ALB/NLBの料金は「時間課金」と「LCU(Load Balancer Capacity Unit)課金」の二本立てです。LCUは、新規接続数・アクティブ接続数・処理したトラフィック量・ルール評価数(ALBの場合)という複数の指標のうち、最も高いもので決まります。つまり「接続は少ないが大きなデータを流す」構成でも「小さなリクエストが大量」な構成でも、いずれかの指標が跳ねればLCUが伸びます。

ヘルスチェックの過剰な頻度、不要になったターゲットグループへの振り分け、使われていないリスナールールなどが地味にLCUを押し上げます。マイクロサービスごとにALBを乱立させている場合は、1つのALBにパスベースルーティングで集約する、あるいはNLBとの使い分けを見直すことで、時間課金とLCU課金の両方を圧縮できることがあります。

08KMS：鍵の保管料とリクエスト課金

暗号化は必須ですが、KMSにも見えにくいコストがあります。カスタマー管理鍵(CMK)は1鍵あたりの月額保管料に加えて、暗号化・復号のAPIリクエスト数で課金されます。S3のSSE-KMS、EBS暗号化、Secrets Manager、RDS暗号化などが裏でKMSを叩くため、大量のオブジェクトを扱うワークロードではリクエスト課金が積み上がります。

現場のコツ：S3のSSE-KMSで大量の小さなオブジェクトを扱う場合、「S3 Bucket Keys」を有効化するとS3とKMS間のリクエスト回数を大幅に削減でき、KMSリクエスト課金を抑えられます。要件上マスターキーの分離が不要な部分は、KMS管理のAWSマネージドキーやSSE-S3で足りることも多く、どこにCMKを使うかは統制要件と照らして設計します。アカウント全体の鍵・統制の考え方はマルチアカウント統制も参考にしてください。

09リクエスト系・API系の盲点：地味だが積み上がる課金

単価が小さく見過ごされがちですが、回数が桁違いに多いと効いてくるのがリクエスト系の課金です。代表的なものを挙げます。

Secrets Managerのシークレット保管とAPIコール：1シークレットあたりの月額に加え、GetSecretValueの呼び出し回数で課金されます。アプリが毎リクエストごとに取得している場合はキャッシュで削減できます。
SQS/SNS/Lambdaの呼び出し回数：ポーリング間隔が短すぎるSQS、空振りのロングポーリング設定ミス、リトライ暴走などがリクエスト数を膨らませます。
Config・GuardDutyなどの記録・解析課金：統制系サービスは記録した構成項目数や解析したデータ量で課金されるため、対象を広げすぎると効いてきます。

これらは1件1件は小さくても、マイクロサービスやバッチが高頻度で叩く構成では無視できない額になります。設計段階で「呼び出し回数×単価」を意識できているかどうかが分かれ目です。料金の考え方や、アカウント設計の初期段階についてはアカウント初期設定もあわせてご覧ください。

10サポート・支払い体系の盲点：割引の取りこぼしと為替

最後は、サービスそのものではなく契約・支払い側の盲点です。まず、ビジネス/エンタープライズのサポートプランは月額利用料(利用額に対する一定割合)がかかります。必要な水準を超えたプランを惰性で継続していないか、逆に本番なのにベーシックのまま無理をしていないかは、定期的に見直す論点です。

次に、Savings PlansやReserved Instanceといったコミットメント割引の取りこぼしです。オンデマンドで走り続けているだけで、適用すれば数割下がる定常ワークロードは多くあります。ただし利用予測が甘いと持て余すため、まずはCompute Savings Plansのような柔軟性の高いものから、確実に使い切れる範囲でコミットするのが定石です。

現場のコツ：日本企業の場合、AWSの請求はドル建てが基準のため、為替変動が実質的なコスト増として効きます。ドルベースで最適化していても円建ての支払いが膨らむ局面があります。この論点は円安時代のAWSコスト管理で具体的に扱っています。

—まとめ

ここまで見てきたコスト源に共通するのは、「構成を変えていないのに、従量部分が静かに積み上がる」という性質です。時間課金・データ処理課金・リクエスト課金・保管料といった、EC2やRDS本体の陰に隠れた費用こそが、請求書の「なぜか増えている」部分の正体です。

まず経路系(NAT・データ転送・KMSリクエスト)を疑う。ここは構成の工夫で大きく効きます。
次に保管系(スナップショット・未使用リソース・RDSバックアップ)を棚卸しする。タグ運用と定期実行で仕組み化します。
最後に契約系(サポート・コミットメント割引・為替)を見直す。ここは経営レイヤーの判断とセットになります。

大切なのは、単価表を眺めることではなく、自社の構成のどこにどのトラフィックとリクエストが流れているかを把握することです。Cost Explorerで「サービス別」だけでなく「使用タイプ別」に分解すると、ここで挙げた見えないコストが浮かび上がってきます。EMWは請求書の読み解きから、構成を変えずに効く打ち手の設計、統制の仕組み化までを実務目線で支援しています。過去の導入事例もあわせてご覧ください。

見えないコストの棚卸しと、構成を変えずに効く打ち手の設計はEMWの実務経験が活きる領域です。請求書の内訳が読み解けない、どこから手を付けるべきか判断がつかないといった段階から、お問い合わせよりお気軽にご相談ください。

相談する

← ブログ一覧へ戻る