月額3万円が気づいたら300万円になっていた
AWSの請求書が、買収から6ヶ月後に3.7倍になっていた── 買い手から「インフラコストが当初計画と大きく乖離している。どういうことか確認してほしい」と連絡が入る。Cost Explorerを開いて最初に気づいたのは、リザーブドインスタンスの有効期限が譲渡完了の翌月に切れていたこと。前経営者が購入した1年RIが失効し、すべてのEC2インスタンスがオンデマンド料金に自動で戻っていた。IMに記載された「サーバー費用：月額28万円」は、このRIが有効だった期間のコストであり、失効後の月額に換算すれば97万円だった。
財務系ブローカーは「P/Lの費用合計」しか見ません。その数字がどのような構造の上に成り立っているか── それを読み解ける人間が、バリューチェーンのどこにも存在しなかった結果です。本記事では、エンジニアでないと絶対に気づけないAWSコスト構造の罠を4つの時限爆弾に分解し、インフラDDの実務手順とチェックリストを、現場経験から丸ごと開示します。
1. なぜAWSコストはM&A後に「無音で爆発」するのか ── 財務DDがP/Lの費用合計しか見ないとき、EBITDA計算は根本から狂う
1-1. AWSの請求構造は「変動費の複合体」── P/L上の1行では絶対に読めない
AWSの月次請求書を受け取ったことがある経営者はご存じでしょうが、あのPDFは理解するために相当な訓練が必要です。EC2・RDS・S3・CloudFront・NAT Gateway・ElastiCache・Secrets Manager・CloudWatch・Data Transfer── 数十のサービスが並び、それぞれに複数の課金軸（リクエスト数・データ量・インスタンス時間・API呼び出し回数）が存在します。財務系ブローカーがIMで開示するのは「AWS費用：月額○万円」という1行です。その1行の内訳に、有効期限付きのRI節約効果が含まれているか、トラフィック急増時のCloudFront費用が平常期の数値で代表されているか、NAT Gatewayの従量課金が計算に入っているか── 財務の専門家には構造的に読めません。読めないのは能力の問題ではなく、AWSの料金体系はエンジニアリングの知識なしには分解できない設計になっているからです。
1-2. 「過去12ヶ月の平均」という罠 ── IMに記載されるAWS費用が「最も安かった時期」の数字である現実
財務系DDでIM記載のAWS費用を検証する際、通常は「過去12ヶ月の費用推移」を確認します。しかしこの手法には致命的な欠陥があります。RIが有効だった期間の費用が「過去の実績」として記録に残り、その平均値が将来コストの代表値として使われるからです。また、閑散期（アクセスが少なく転送量が低い時期）の平均で将来のCloudFront費用を試算すれば、繁忙期の実態コストを大幅に過小評価します。記事がバイラルした月・セール期のEC購入集中月・動画コンテンツが突然拡散した月── これらの「例外月」のAWS費用は平均値の5〜10倍に達することがあります。財務系DDが参照する「過去実績」は、しばしば「最も運営コストが低かった偶然の時期」の数字に過ぎません。
1-3. EBITDAが「根本から狂う」構造 ── AWS費用が年間1,200万円増加すれば、5倍EV企業の企業価値は6,000万円消滅する
AWSコストの見誤りが直接EBITDAを直撃する構造を確認します。仮にEBITDAマルチプル5倍の企業評価で5,000万円の譲渡対価だったとして、月額AWS費用が買収後に月100万円増加（年1,200万円増加）すれば、EBITDAは1,200万円減少し、同じマルチプルで評価すれば企業価値は6,000万円消滅します。つまり5,000万円で買った事業が、インフラコストの見誤りだけで、評価上はマイナスになる計算です。インフラコストを「P/Lの費用の一行」ではなく「構造として」読む技術者の視点が、M&Aの場でいかに決定的な意味を持つか── これがこの記事で伝えたい根幹です。
2. 【時限爆弾①】リザーブドインスタンスの有効期限切れ ── 「節約設計」が失効した翌月、AWS請求額が3〜4倍に跳ね返ってくる仕組み
2-1. リザーブドインスタンス（RI）の仕組みと、前払いコミットが生む「節約の時限性」
RIはEC2・RDS・ElastiCache等に適用できる、AWSに対して「1年または3年、このインスタンスを使い続ける」とコミットすることで、オンデマンド料金比で最大72%の割引を受けられる購入形態です。前払い方式（All Upfront）なら割引率が最大になりますが、有効期限を過ぎた翌秒から、そのインスタンスはオンデマンド料金に自動で切り替わります。切り替えはAWSからのアラートなしに静かに発生し、翌月請求書を見て初めて気づく── というのが定番の発見パターンです。東京リージョンのm5.xlarge（4vCPU/16GB）を例に取ると、オンデマンドが$0.248/時間のところ、1年RI（All Upfront）では$0.138/時間相当になります。RI失効後の請求増加は単純計算で約80%増であり、複数インスタンスが同時に失効すれば月額費用は一気に跳ね上がります。
2-2. 「1年RIを購入したのが前経営者で、その有効期限が譲渡完了の翌月だった」場合
M&Aで最も多いのが「前経営者が1年RIを購入→譲渡プロセスが半年かかる→譲渡完了とほぼ同時にRIが失効」というタイムラインです。Cost ExplorerのRI購入履歴は「AWSコンソール → EC2 → Reserved Instances」から確認できますが、この画面を開いたことがない非エンジニアが売り手側担当者である場合、RIの存在と有効期限を知らないまま交渉が進みます。RI失効後のコスト増加は3〜4倍というのが実態で、月額20万円のEC2費用が翌月から70〜80万円になる、というのは全くありえない話ではありません。しかもRIの「失効前後のコスト比較」は、Cost Explorerを月単位で見比べるだけでは気づきにくく、年間のトレンドグラフを見ても「先月から突然増えた」という急勾配として現れます。
2-3. DDでのRI有効期限確認手順と、失効後のコスト試算方法
買い手側DDで必ず実施すべき確認項目です。AWSコンソールへの読み取り専用アクセス（ReadOnlyAccess権限）を売り手から取得した上で、「EC2 → Reserved Instances → Active」タブで全RI一覧を取得し、End dateの列を確認します。End dateが譲渡予定日から12ヶ月以内にあるRIは要注意── 譲渡後の最初の更新時期に必ずコストが跳ねます。RIの更新（再購入）コストを見積もり、それをIM記載のAWS費用に上乗せした「更新後の実態コスト」で事業評価を組み直すべきです。また、RIの購入・更新権限が前経営者の個人AWSアカウントに紐づいている場合、名義変更と新規購入の手続きが発生し、最悪の場合は数ヶ月間オンデマンド料金で運用しなければならない事態に陥る点も確認してください。
2-4. Savings Plansとの違い ── フレキシブルな節約設計も「失効リスク」は同様に持つ
近年はRI単体よりSavings Plans（Compute Savings Plans・EC2 Instance Savings Plans）を利用している事業者が増えています。Savings Plansも有効期限があり、同様に失効リスクを持ちます。さらにSavings Plansは「コミット量（$/時間）」でコミットするため、利用パターンが変わった場合にコミット過不足が発生しやすい特性があります。「1時間あたり$1.0をコミットしているが実際の利用は$0.6相当」という状態では、差額の$0.4は節約にならず損失です。DDでは「現在のSavings Plans購入状況・コミット量・有効期限・実際の利用量との乖離率」を一覧として開示請求することが必要です。Cost Explorerの「Savings Plans Utilization」レポートが最も簡便な確認手段です。
3. 【時限爆弾②】CloudFrontのエグレス課金 ── 「CDN使ってます」のIMに、データ転送量コストの試算は一行も書かれていない
3-1. CloudFrontの「エグレス（送信）課金」の構造 ── 配信量×リージョン別単価で青天井に積み上がる
CloudFrontはAWSのCDN（Content Delivery Network）サービスで、画像・動画・JS・HTMLを世界中のエッジロケーションからキャッシュ配信します。CDNは「速くなる」技術として紹介されることが多いですが、AWSからインターネット方向へのデータ転送（エグレス）は有料です。料金体系は「ユーザーへの月次転送量（GB）× リージョン別単価」で、アジアパシフィック向けで最初の10TBまで$0.114/GB（2026年5月時点）が適用されます。月1TBのデータ転送でも約17,000円のCloudFront転送費用が発生し、動画コンテンツ・大容量ファイルダウンロード・高解像度画像を多用するサービスではここが急激に膨らみます。IMに「CDN利用中」と書かれていても、その費用がAWS請求書のどの行に計上されているかを理解できる財務担当者は皆無です。
3-2. IMには「閑散期の月次平均」しか反映されない ── 繁忙期・バイラル拡散時の転送量を誰も試算していない
WebメディアやEC事業では、アクセス量が季節・キャンペーン・SNSバイラルで激しく変動します。IMに記載されるAWS費用は「過去12ヶ月の平均」であることが多く、閑散期の低転送量が平均値を引き下げます。記事がバイラルした月・セール期のEC購入集中月・動画コンテンツが突然拡散した月── これらの「例外月」のCloudFront費用は平均値の5〜10倍に達することがあります。さらに、対象事業が今後SNSを活用したマーケティングを強化しようとしている場合、バイラル拡散はむしろ戦略的に狙うものであり、「アクセスが増えるほどインフラコストが青天井で増加する構造になっていないか」を事前に確認しておかないと、マーケティング施策の成功がキャッシュフローを直撃するという逆説が発生します。
3-3. CloudFront Price Class設定とキャッシュ設定の確認 ── 設定1つで費用が大きく変わる
CloudFrontにはPrice Classという設定があり、「全てのエッジロケーション（Price Class All）」「低コストリージョン限定（Price Class 100・200）」を選択できます。日本向けのサービスが大半なのにPrice Class Allを選んでいる場合、アフリカ・南米・インド等の高単価リージョンへのデータ転送費用まで発生している可能性があります。DDではCloudFrontのディストリビューション設定（Price Class・キャッシュポリシー・TTL設定・オリジンリクエスト設定）をコンソール上で確認し、キャッシュヒット率が低い設定（TTLが極端に短い・キャッシュキーに不要なパラメータが含まれている等）になっていないかを確認します。キャッシュヒット率が低いと毎回オリジンサーバーにリクエストが飛び、CloudFront費用だけでなくオリジン側のEC2・ALB処理コストも増加します。
4. 【時限爆弾③】NAT Gatewayの死角コスト ── VPC設計の「定番構成」が、月額数十万円を誰にも気づかれないまま焼き続ける
4-1. NAT Gatewayとは何か ── プライベートサブネットからの通信を中継する「必須コンポーネント」の料金体系
NAT（Network Address Translation）Gatewayは、プライベートサブネット内のEC2インスタンスやRDS等がインターネットと通信するための中継コンポーネントです。セキュリティ上、データベース・アプリサーバー等はプライベートサブネット（インターネットから直接到達できないネットワーク）に配置するのがAWSの定番ベストプラクティスであり、それらのインスタンスがAPIを叩いたりパッチを取得したりするためにNAT Gatewayが必要です。料金体系は「NAT Gateway稼働時間（$0.062/時間、東京リージョン）＋NAT Gatewayを経由したデータ処理量（$0.062/GB）」の2軸です。この料金体系を知らなければ、Cost Explorerの「EC2 Other」という行に混入しているNAT Gateway費用を発見することは不可能です。
4-2. 「データ処理量課金」の恐ろしさ ── SaaSやAPI多呼び出しの構成で爆発する
NAT Gatewayの稼働時間課金は1台月額約4,500円で大した金額ではありませんが、データ処理量課金は怪物です。プライベートサブネットのEC2から外部APIを1日100万回コールする構成では、1コールあたりの平均レスポンスが5KBであれば1日5GB、月150GBのデータ処理量となり、月額約1,500円です。しかし外部データ取得・機械学習モデルへの推論リクエスト・大量の画像変換・動画変換バッチ処理・外部DBへの大量データ同期といった「データ移動量が多い」構成では、月間数TBのデータ処理量が発生し、月額数十万円規模に達します。IMを見ても「NAT Gateway費用」という行は存在しないことがほとんどで、EC2費用やその他費用の中に埋没しています。
4-3. マルチAZ構成でのNAT Gateway二重コスト ── 可用性のための設計が料金を倍増させる
AWSの高可用性設計の定番は「マルチAZ（Availability Zone）」構成で、2つ以上のAZにリソースを分散配置します。各AZにそれぞれNAT Gatewayを配置する（AZ間のデータ転送費用を避けるために推奨される）と、NAT Gateway本体のコストが単純に2倍になります。「しっかりした高可用性設計をしていました」という売り手の説明が、実は「NAT Gatewayのコストが倍かかる構成でした」という意味でもあることを、財務系ブローカーは永遠に理解できません。コスト面だけを見れば「NAT Gatewayを1台に集約」したほうが安くなりますが、それは可用性を犠牲にする設計であり、ビジネス要件によってどちらが正解かは変わります。DDでは構成の合理性と費用の両面を技術者が評価する必要があります。
4-4. VPC Endpointによるコスト削減余地 ── DDで発見して買収後の改善計画に組み込む
NAT Gatewayコストの削減策として最も効果的なのが、S3・DynamoDB等のAWSマネージドサービス向けには「VPC Endpoint（Gateway型）」を利用することです。VPC Endpoint経由の通信はNAT Gatewayを経由せず、かつGateway型VPC Endpointは無料で利用できます。S3への大量アクセスが発生するバッチ処理・バックアップ・データ分析基盤では、VPC Endpointを設定するだけで月額数万〜数十万円のNAT Gateway費用が消滅します。買い手DDでこの改善余地を発見した場合、「改善コスト（開発工数：数時間〜数日）<<削減される月次費用」という計算が成立することが多く、買収後の運営コスト改善計画として積極的に組み込むべきです。（逆に言えば、買収価格に織り込まれているEBITDAは「改善前の非効率なコスト」で算出されているわけですから、ここは交渉の余地でもあります。）
5. 【時限爆弾④】スポットインスタンスと冗長設計の欠如 ── コスト削減目的の「安い構成」が、買収後に可用性リスクへ化ける
5-1. スポットインスタンスの仕組み ── AWSの余剰コンピューティングを最大90%引きで使える代わりに、2分前通知で中断される
スポットインスタンスはAWSのデータセンター内の余剰コンピューティングリソースを競争入札で利用する仕組みで、オンデマンド比で最大90%安い価格でEC2を利用できます。対価として要求されるのは「AWSの都合でいつでも2分前通知で中断される」という条件です。バッチ処理・機械学習の学習ジョブ・動画エンコード等「中断されても再実行可能な処理」には非常に向いていますが、常時起動・サービス継続が必要なAPIサーバーやWebサーバーにスポットインスタンスを使うことは、可用性を犠牲にしたコスト最適化であり、中断発生時に適切なフォールバック設計がなければサービス全断が発生します。
5-2. 「スポットインスタンス使ってます」が「可用性ゼロのギャンブル構成」である場合
「コスト最適化のためにスポットインスタンスを活用しています」というIMの一文は、一見すると運営の巧みさを示す好材料に見えます。しかし重要なのは「スポット中断時のフォールバック設計の有無」です。Auto Scaling GroupにスポットインスタンスとオンデマンドのMixed Instances設定をしている（中断時に自動でオンデマンドに切り替わる）、EKSのNodeGroupにスポットNodePoolとオンデマンドNodePoolを混在させる── これらの適切な設計なしに、メインのワークロードを単純にスポットで動かしているだけであれば、AWSのキャパシティ回収の都合で「突然5分間サービスが落ちる」という事態がいつでも起こりえます。買収後に新機能リリースのプレスリリースを打った直後にスポット中断が発生してサービスが落ちる── そういうシナリオは笑い話ではなく、現実の可能性として対処が必要です。
5-3. スポットインスタンス中断の「歴史ログ」はAWSコンソールでは簡単に確認できない ── DDで発見しにくいリスク
スポットインスタンスの中断履歴はCloudTrail上に記録はありますが、「中断が何回発生したか」「サービスへのインパクトは何分間だったか」を簡単に集計できるレポートはAWSコンソールには存在しません。売り手が「スポットインスタンスを使っていますが問題なく運用しています」と主張しても、それを覆すデータを買い手が即座に取り出すのは容易ではありません。DDでは「CloudTrail上のEC2 Spot interruption通知イベントの数と日時」と「その時間帯のCloudWatchアラーム・アプリケーションエラーログ（ALBの5xxエラー率等）」を突合して実態を確認すべきです。また、スポット中断への対応コード（Graceful Shutdown処理・チェックポイント保存処理）がアプリケーション側に実装されているかを、コードレビューの観点からも確認することを推奨します。
6. RI・CloudFront・NAT・スポットだけじゃない ── S3 APIコール・EBSスナップショット放置・サポートプラン引き継ぎという「その他費用」の正体
6-1. S3のAPIコール課金とGlacierライフサイクル設定の無効化
S3の料金はストレージ容量課金（$0.025/GB/月）だけでなく、APIコール課金（PUT/COPY/POST/LIST：$0.0047/1,000リクエスト、GET等：$0.00037/1,000リクエスト）が存在します。大量の小さなファイルを頻繁にPUTするシステム（ログ収集・IoTデータ蓄積・ユーザーアップロード処理）では、APIコール課金がストレージ課金を上回るケースがあります。また、コスト削減のためGlacierへのライフサイクル移行が設定されているはずが、バケットポリシーの変更でライフサイクルルールが無効化されているケースも頻発します。S3バケット一覧・各バケットのサイズ・ライフサイクルルール設定・月次APIコール数は、Cost ExplorerのS3詳細とS3コンソールの「Storage Lens」で確認できます。
6-2. EBSスナップショットの放置 ── 「念のため取っておいたバックアップ」が何年分も積み上がる
EBS（Elastic Block Store）スナップショットは「EC2インスタンスのディスクバックアップ」として取得しますが、古いスナップショットを削除しないと永遠に課金が続きます（$0.05/GB/月）。EC2インスタンスを削除したがスナップショットを消し忘れる、スナップショット取得スクリプトが世代管理されておらず2〜3年分が積み上がっている── こういった事態は頻繁に発生します。Cost ExplorerでEC2-Other（EBSスナップショット料金はこちらに分類される）が予想外に大きい場合は、スナップショット一覧（EC2 → Snapshots → Owned by me）を確認し、作成日時が古い順にソートして、不要な世代を整理するだけで大きなコスト削減ができます。テラバイト単位のスナップショットが積み上がっている事業では、月額数万〜数十万円規模の削減余地が生まれます。
6-3. AWSサポートプランの引き継ぎと隠れ固定費
AWSサポートプランはDeveloper・Business・Enterprise On-Ramp・Enterpriseの4段階があり、BusinessはAWS月額利用料の10%（最低$100）、Enterprise On-Rampは10%（最低$5,500）という料金体系です。月額AWS利用料が100万円の場合、Businessプランで月額約15万円のサポート費用が発生します。この費用はAWS請求書上では「Support」という独立した行として表示されますが、仲介業者のIMには「AWSサーバー費用：月額○万円」として前述のRI節約分・CloudFront費用とまとめて記載されることが多く、個別の費用構造が見えません。また、AWSサポートプランはアカウントに紐づく契約であり、株式譲渡の場合はアカウントオーナーが変わるため契約の見直し・継続手続きが必要になる点も確認してください。
7. AWS Cost ExplorerとTrusted Advisorで実施するインフラDDの実務 ── サービス別コスト分解からアーキテクチャ図との費用突合まで
7-1. Cost ExplorerでのDDの基本操作 ── サービス別・利用タイプ別のGroup by分析
インフラDDの最初のステップは、AWSコンソールへの読み取り専用アクセス（ReadOnlyAccess権限のIAMユーザーまたはロール）を売り手から取得することです。Cost Explorerを開き、「Group by: Service」で過去12ヶ月のコストをサービス別に分解します。この1画面で「どのサービスがコストの何%を占めているか」が明確になります。次に「Group by: Usage type」に切り替え、各サービスの課金軸（Transfer量・Request数・Instance時間等）を確認します。EC2 Other（NAT GatewayやEBSスナップショット料金が含まれる）・Data Transfer（クロスリージョン転送・CloudFrontエグレス）が異常に大きい場合は、前述の時限爆弾が潜んでいる可能性があります。月単位のグラフで費用の急増・急落を確認し、急増のあった月に何が起きたのか（RI失効・大量データ転送・スポット中断によるオンデマンド代替等）を追跡します。
7-2. RI有効期限の全件確認とSavings Plans残存期間の突合
Cost Explorerの「Reservations → Reserved Instance Utilization」レポートで、現在有効なRI一覧と利用率が確認できます。RI購入の詳細（購入日・有効期限・インスタンスタイプ・前払い金額）は「EC2 → Reserved Instances → Active」タブで全件確認し、End dateが12ヶ月以内のものをリストアップします。Savings Plans残存期間は「Cost Management → Savings Plans → Inventory」で確認できます。これらをスプレッドシートに出力し、「RI/Savings Plans失効後の試算コスト（オンデマンド換算）」を現在のIM記載費用と並べて比較するのがDDの基本作業です。失効後の月額がIM記載費用の1.5倍を超えるようであれば、その差額は譲渡対価の減額交渉のテコとして定量化できます。
7-3. Trusted Advisorの「コスト最適化」チェック項目を全件確認する
Trusted AdvisorはAWSが提供する「運用上の問題点自動検出」ツールで、コスト最適化・パフォーマンス・セキュリティ・耐障害性の4カテゴリで問題点を自動検出します。BusinessまたはEnterpriseサポートプランであれば全チェック項目が利用可能です（Developerプランは一部項目のみ）。コスト最適化カテゴリには「利用率の低いEC2インスタンス・未使用のEIPアドレス・未使用のEBSボリューム・RIの利用率低下・アイドル状態のRDSインスタンス」等の検出項目があり、これらの「問題あり」件数と内容を確認するだけで、改善余地と潜在的な問題の全体像が把握できます。Trusted Advisorの「問題あり」件数が多いほど、対象事業のインフラ運用の成熟度が低い証拠であり、将来の最適化コスト（工数）と、逆に言えば改善後のコスト削減余地として評価すべきです。
7-4. アーキテクチャ図とCost Explorerの突合 ── 「構成の主張」と「コストの実態」を照合する
売り手からアーキテクチャ図（draw.io・Lucidchart・Miro等で作成されたシステム構成図）を入手し、Cost Explorerのサービス別コストと照合します。アーキテクチャ図に記載されているはずのサービスのコストがCost Explorerに表示されていない場合、そのサービスは実際には使われていない可能性があります。逆に、アーキテクチャ図に記載がないサービスが大きなコストを占めている場合、「公式には整理されていない隠れたコスト構造」が存在することを示唆します。特にData Transfer費用が理由不明に大きい場合は、アーキテクチャ上の設計問題（AZ間のデータ往来が過多・不必要なクロスリージョン通信・CloudFrontエグレス費用の見落とし等）を疑うべきです。アーキテクチャ図が存在しない場合は、その時点で「エンジニアリング組織としての成熟度が低い」という判定材料になります。
8. 買い手が持つべき「インフラDDチェックリスト14項目」と、売り手がやるべき「コスト棚卸しの誠実開示」が譲渡対価を守る逆説
8-1. 買い手のインフラDDチェックリスト14項目
買い手がAWSコンソールへの読み取り専用アクセスを取得した上で確認すべき項目を、優先度順に整理します。
①Cost ExplorerのGroup by: Service表示（過去12ヶ月）でサービス別コスト構造の全体像を把握する。
②RI有効期限一覧（失効が12ヶ月以内のものを特定・オンデマンド換算で費用増加額を試算）。
③Savings Plans残存期間と利用率（Savings Plans Utilizationレポート）。
④CloudFrontのPrice Class設定と月次転送量推移（繁忙期を含む最大月の費用を確認）。
⑤CloudFrontキャッシュヒット率の確認（CloudWatchメトリクス「CacheHitRate」）。
⑥NAT Gateway台数・配置AZ・月次データ処理量（EC2 OtherのNAT Gateway行を特定）。
⑦VPC Endpoint設定状況（S3・DynamoDB向けのGateway型VPC Endpoint設定の有無）。
⑧スポットインスタンス利用状況とフォールバック設計の有無（Auto Scaling Group設定確認）。
⑨EBSスナップショット一覧と古い世代の残存状況（Owned by me・作成日時順でソート）。
⑩S3バケット別のストレージ量・ライフサイクル設定・Storage LensでのAPIコール数確認。
⑪Trusted Advisorのコスト最適化チェック結果（全件・問題あり項目を列挙）。
⑫AWSサポートプランの種別と月額費用（請求書上のSupportラインで確認）。
⑬CloudWatchコストアラームの設定有無（Cost Anomaly Detectionの利用状況）。
⑭アーキテクチャ図とCost Explorerの突合（記載サービスと実際の課金サービスの一致確認）。
この14項目を技術者が1〜2日かけて確認するだけで、財務系DDでは絶対に発見できないコスト時限爆弾の全貌が可視化されます。
8-2. 売り手が譲渡前3ヶ月でやるべきコスト棚卸し ── 自主開示が譲渡対価を守る
売り手がDD前にCost Explorerを自ら分解し、RI有効期限・CloudFront費用の繁忙期実態・NAT Gatewayコストの内訳・スポットインスタンスの設計状況を整理してIMに付記した場合、買い手の心象は劇的に変わります。「コストを完全に把握して開示してくる売り手」に対し、買い手はリスクプレミアムを低く見積もります。逆に、開示が不十分でDDの過程でコスト構造の問題が次々と発覚した場合、リスクプレミアムが積み上がり、最終的な譲渡対価への下落圧力は「自主開示した場合のコスト調整額」を大幅に上回ります。不都合を隠して高く売ろうとした売り手の最終手取りは、誠実に開示した売り手より確実に少なくなる── これがインフラコスト領域でも成立する逆説です。RI失効コストが月50万円増加する見込みであれば、それをIMに明記した上で年間600万円分を譲渡対価から事前に控除する形で着地したほうが、DDで発覚して買い手から1,500万円の値下げ要求が来るよりも、手取りは圧倒的に厚くなります。
本シリーズで分解してきたインフラコスト・未払残業代・労務DD・薬機法・景表法・OSSライセンス── これら全てに共通するのは「数字に出ない領域に、EBITDAと事業価値を根本から狂わせる時限爆弾が眠っている」構造です。AWSコストの時限爆弾は、その中でも最も「エンジニアリングの素養なしには存在にすら気づけない」領域です。Cost Explorerを操作し、RIの有効期限を読み、NAT Gatewayの課金軸を理解し、スポットインスタンスのフォールバック設計を評価する── この作業ができる技術者だけが、M&Aのインフラコスト時限爆弾を爆発前に解除できます。
