日本企業の AWS コスト管理でよくある 7 つの失敗

日本企業の AWS コスト管理には、本国 (北米) 向けに書かれた一般的な ベストプラクティスがそのままは当てはまらない事情がいくつもあります。 稟議文化・年度予算・夏期同期で進む人事ローテーション・円建ての社内 予算とドル建ての請求書 ── これらが組み合わさると、技術的には正しい 最適化策が組織的に実行できない場面が頻繁に発生します。本稿では、 私がこの 10 年で繰り返し見てきた 7 つの失敗を取り上げます。

1. リザーブドインスタンスを買えない

技術的に見ればリザーブドインスタンス (RI) や Savings Plans (SP) は 即効性のあるコスト削減策です。1 年契約で 30%、3 年で 50% 前後の 割引が効きます。にもかかわらず日本企業の現場では「買えない」 ケースが多発します。

理由は技術ではなく稟議です。前払金の発生する取引は資本支出 (CAPEX) 扱いとなることが多く、年度予算で計上していなければ稟議が 通りません。次年度予算策定のタイミングで RI 購入予算を別立てに 立て、月次オンデマンドコストの実績データを添付して稟議を回す ── このサイクルが回らない企業ほど割引機会を逃し続けます。

対処: 全額前払いではなく一部前払 (Partial Upfront) や月払 (No Upfront) を選択することで CAPEX 扱いを回避できます。SP の方が 柔軟で、稟議も通しやすいので、RI に拘る合理的理由がなければ SP で組み立ててください。

2. 月次定額の発想で予算を立てる

オンプレ時代のキャパシティプランニングをそのまま AWS に持ち込み、 「月いくら」の固定枠で予算を組む慣行が今も根強く残っています。 クラウド請求は使用量ベースで上下動するため、月次予算をフラットに 組んだ瞬間から実態とのずれが累積していきます。年度末になって 「予算オーバーで申し訳ありません」と頭を下げる構図が毎年繰り返さ れます。

対処: 年度予算は四半期ごとの幅を持たせて承認を取り、月次 予算は前月実績+予測 (Cost Explorer の Forecast) を組み合わせて スライドさせます。AWS Budgets のアラートを実額ベースではなく 「予算消化率」ベースに変えるだけでも、上振れ・下振れの両方を 早く検知できます。

3. 開発・検証環境を 24 時間稼働させる

平日 9 時 〜 18 時しか使わない開発環境を、土日も深夜も EC2 を 立てたままにする ── これも珍しくない構図です。理由はシンプルで、 「停止スクリプトを誰が書くか」が決まらないからです。インフラ 担当が書けば運用、アプリ担当が書けば開発、で押し付け合いに なります。

対処: AWS Instance Scheduler を導入するか、Lambda + EventBridge で起動・停止のスケジュールを組みます。土日・夜間に止めるだけで 週あたり 67% の時間が削減でき、開発環境の EC2 コストはほぼその 比率で減ります。Aurora Serverless v2 や Fargate Spot を組み合わ せると、停止すら不要になる構成も組めます。

4. ログを永続保存する

CloudWatch Logs に何でもかんでも吐き出し、ログ保管期間を「永続」 に設定しているケースをよく見ます。料金体系上、CloudWatch Logs は 保管 ($0.03/GB-月) より取り込み ($0.50/GB) の方が高いのに、保管 期間だけ気にして取り込み量を絞らない設計が多いです。

対処: 取り込み段階でサンプリングまたはフィルタリングをかけ ます。長期保管が必要なログは Kinesis Firehose 経由で S3 に直接 書き出し、S3 Intelligent-Tiering と Lifecycle Policy で Glacier Deep Archive に移行させます。CloudWatch Logs は直近 30 日分の運用向け参照に絞るのが標準的な構成です。

5. データ転送料を見落とす

東京リージョン (ap-northeast-1) のデータ転送料は、特にインターネット 向け egress と他リージョンへの転送が請求書の数 % 〜 10% を占める ことがあります。クロス AZ 通信 ($0.01/GB × 2 方向) も同じくらい 盲点になりがちで、サービスメッシュ導入時に zone-aware ルーティング を設定しないまま動かしているチームの転送料は無視できない金額に 膨らみます。

対処: VPC エンドポイントを S3・DynamoDB・ECR・CloudWatch などの主要 AWS サービスに張ります。NAT Gateway 経由のデータ 処理料 ($0.045/GB) が消えるため、効果は比較的早く出ます。 クロス AZ は、Kubernetes であれば topology.kubernetes.io/zone ラベルを使った routing、サービスメッシュなら locality-aware の 設定で抑えられます。

6. タグ統制が行われていない

部署別のコスト按分や担当者の特定が必要になる場面で、リソース タグが整備されていないと一切の按分ができません。日本の組織は 情報システム部門・各事業部・子会社の三層構造になっていることが 多く、誰が払うかを後から決めようとして詰むのが典型です。

対処: AWS Organizations の SCP (Service Control Policy) で、必須タグなしのリソース作成を弾きます。最低限 Environment・ Owner・CostCenter の 3 つを必須にすれば、Cost Explorer の 按分が機能します。レガシーで動いている既存リソースには Resource Groups + AWS Config を組み合わせて棚卸しを行い、半年 程度かけて 100% タグ付けに持っていきます。

7. 円安時のドル建て請求リスク

請求は米ドル建てで月末に確定し、各社の経理処理時点の為替レート で円換算されます。2022 年 以降のドル円の振れ幅 (115 円 → 150 円) の影響を受け、技術的にはコストが減っているのに円建てでは 増える、という現象が現場ではよく観察されます。

対処: 為替リスクは技術側で吸収できないため、財務側との連携が 必要です。Compute Savings Plans の上限額をドルで合意したうえで 為替変動の年次予算組み戻しを経理と合意するパターンが一般的です。 小規模なら法人カードで先払いして為替変動を吸収する手もあります。

まとめ

7 つのうち、純技術的に解決できるのは 3 (環境停止)・4 (ログ)・5 (データ転送) の 3 つです。1 (RI 稟議)・2 (月次予算)・6 (タグ 統制)・7 (為替) は組織側の動きが伴わないと効果が出ません。 個別最適より、四半期に 1 回・財務と現場が合同で見るレビューの 枠組みを作る方が長期的には効きます。

日々のコスト分析には、Cost Explorer の CSV を直接読み込んで主要 パターンを抽出できる AWS Billing Analyzer をご利用ください。 ファイルはブラウザ内のみで処理されるため、アカウント ID や リソース ARN を含む請求データを外部に送ることなく分析できます。