LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

未使用リソースが静かにコストを押し上げる背景

クラウドの未使用リソース棚卸しとは、AWSなどのクラウド環境で稼働していないにもかかわらず課金が継続しているリソースを洗い出し、削除または解放することで請求額を下げる一連の作業を指します。

クラウドは「使った分だけ課金」という特性が知られています。しかし正確には、「存在するだけで課金されるリソース」と「稼働中にのみ課金されるリソース」が混在します。EC2インスタンスを停止すればコンピューティング料金は止まりますが、アタッチしたままのEBS（Elastic Block Store）ボリュームやElastic IPアドレスは停止後も課金が続きます。

こうした「存在課金」のリソースは、プロジェクトの終了・担当者の異動・環境のサイクルアウト後に取り残されやすい性質があります。開発・テスト環境は本番ほど監視されないため、終了後も数か月から数年にわたり放置されることがあります。

AWS Well-Architected Framework のコスト最適化の柱では、COST04（不要なリソースの廃棄）として「プロジェクト・従業員・技術リソースをライフタイム全体で追跡し、廃棄プロセスを確立する」ことを推奨しています^*1。棚卸し・削除は単発のコスト削減施策ではなく、継続的な体制として位置づけることが求められます。

棚卸し対象リソースの全体像——AWSで見落とされやすい7種

AWSを例に、棚卸し対象として特に見落とされやすいリソースを整理します。いずれもEC2インスタンスの停止・削除後に「取り残し」が発生しやすい種類です。

1. 未アタッチEBSボリューム
EC2インスタンスを削除してもEBSボリュームはデフォルトで残ります。「available（未アタッチ）」状態のボリュームは、データを保持したまま課金が続きます。

2. アイドル状態のElastic Load Balancer（ELB）
バックエンドのEC2インスタンスがゼロになったELBは通信を処理していなくても課金が継続します。プロジェクト終了後に削除されずに残りやすいリソースです。

3. 未使用のElastic IPアドレス（EIP）
EC2インスタンスに関連付けられていないElastic IPアドレスは時間課金が発生します。AWSでは2024年以降、使用中・未使用を問わずすべてのPublic IPv4アドレスに対して$0.005/時間の課金が適用されています^*2。

4. 古いEBSスナップショット・AMI
バックアップ目的で作成したスナップショットやAMI（Amazon Machine Image）は、元のインスタンスが廃棄された後も手動削除しない限り残り続けます。長期間蓄積すると無視できないストレージコストになります。

5. 停止中EC2インスタンスのPublic IPv4
EC2インスタンスを「停止」した状態でも、割り当てられたPublic IPv4アドレスは保持されます。前述のとおり$0.005/時間の課金が続くため、長期停止状態のインスタンスは解放または終了の対象となります^*2。

6. 未使用NAT Gateway
VPC内のプライベートサブネットからインターネットへの通信に使うNAT Gatewayは、通信量に加え時間単位の料金も発生します。テスト環境で使用後に削除されずに残るケースがあります。

7. 放置されたdev/test環境全体
開発・テスト用のAWSアカウントやVPCは、プロジェクト完了後も環境ごと残されることがあります。個々のリソース削除だけでなく、環境単位での棚卸しが求められるケースです。

特定に使うAWSツール——Cost Explorer・Trusted Advisor・Compute Optimizer

未使用リソースを特定するには、AWSが提供する3つのツールを組み合わせることが有効です。

AWS Cost Explorer

AWS Cost Explorer（コストエクスプローラー）はコストと使用量の推移をグラフで可視化できるツールです。サービス別・リソース別・タグ別に絞り込めるため、「どのサービスのコストが想定外に高いか」を把握する入り口として使います。棚卸しの優先順位を決める際の全体像把握に適しています。

AWS Trusted Advisor

AWS Trusted Advisor（トラステッドアドバイザー）は、AWSのベストプラクティスに基づく自動チェックを提供するサービスです。「アイドル状態のEC2インスタンス」「未使用のElastic IPアドレス」「低使用率のEBSボリューム」など、コスト最適化カテゴリで検出項目が一覧表示されます。ビジネスサポートプラン以上で全チェック項目が利用可能です。

AWS Compute Optimizer

AWS Compute Optimizer（コンピュートオプティマイザー）は、リソースの設定と使用率メトリクスを分析し、アイドルリソースの特定と右サイジング推奨を提供するサービスです^*3。対象はEC2・EC2 Auto Scalingグループ・EBSボリューム・Lambda関数・ECS on Fargate・RDS・NAT Gatewayなど多岐にわたります。オプトイン後、CloudWatchのメトリクスを14日間（有料の拡張機能では93日間）分析し、過剰プロビジョニングや未使用状態を検出します。

これらのツールはリソースの候補リストアップには有効ですが、「削除してよいかどうか」の最終判断にはアプリケーション構成や運用ルールの理解が求められます。ツールの出力をそのまま削除リストとして使うことはできず、依存関係の調査を別途行う段階があります。

棚卸し・削除が内製では難しい4つの理由

「ツールで検出できるなら自社でできる」と考える担当者もいます。しかし実務上、棚卸し・削除の完遂には専門的な判断とかなりの工数が求められます。

理由1：依存関係の調査に時間と専門知識を要する

AWSリソースは互いに依存しています。あるEBSボリュームを削除しようとしても、スナップショットから復旧する手順書が存在する場合や、AMIが参照している場合は単純に削除できません。

依存関係を正確に把握するには、AWS Config（構成管理）・CloudTrail（操作ログ）・タグ設計の理解が求められます。この調査には、AWSアーキテクチャと対象システムの両方を知るエンジニアが複数名・数日以上を要することがあります。

理由2：タグ未整備で所有者・用途が不明

多くの現場では、リソースに「環境（dev/stg/prd）」「プロジェクト」「所有者」のタグが体系的に付与されていません。タグがないリソースは誰が何のために作ったかわからず、安易に削除すると予期しない障害につながります。

タグポリシーの整備を棚卸しと並行して行うことになり、これは一時的な作業ではなく継続的な運用改善です。

理由3：削除ミスが本番障害に直結するリスク

クラウドリソースの削除は多くの場合「即時・不可逆」です。スナップショットを削除すれば復旧手段が失われ、使用中のEIPを解放すれば接続先のシステムに影響が出ます。

削除前のスナップショット取得・変更管理（CAB承認）・削除後の動作確認といったプロセスを漏れなく踏まないと、本番システムに影響が及ぶリスクがあります。削除作業はドキュメント管理を含め慎重な進め方が求められます。

理由4：定期的な体制化は「一人情シス」では回らない

棚卸しは一度やれば終わりではありません。新規リソースが追加されるたびに「取り残し候補」が生まれるため、月次または四半期ごとの定期チェックが求められます。情シス担当者が他業務と並行してこの作業を回し続けることは現実的に難しい場面があります。

外注で進める棚卸し・削除の4ステップ

棚卸し・削除を外部に委託する場合、一般的に以下の4ステップで進みます。各ステップでの委託側と受託側の役割分担を整理します。

ステップ1：現状調査・未使用リソースのリストアップ

外部パートナーがAWSアカウントへの読み取り権限を受け取り、Cost Explorer・Trusted Advisor・Compute Optimizerを用いて未使用リソースの候補一覧を作成します。アカウント数が多い場合はAWS Organizations（マルチアカウント管理）を使った横断調査が行われます。

この段階では削除は行わず「調査レポート」の作成が成果物です。課金額・最終アクセス日・タグ情報などを整理した一覧を共有し、優先順位を委託元と合意します。

ステップ2：依存関係の確認・削除可否の判断

候補リストに対して、削除してよいかどうかをシステム担当者・開発チームと照合します。外部パートナーはAWS ConfigやCloudTrailのログを参照しながら技術的な依存関係を整理し、各リソースの「削除可」「保留」「要確認」を分類します。

この工程に最も時間がかかります。担当者が既に退職している場合や、ドキュメントが残っていない場合は、実際に一時停止してシステムへの影響を確認する手順を踏むこともあります。

ステップ3：削除実行・コスト削減効果の測定

「削除可」に分類されたリソースに対して、スナップショット取得などの事前バックアップを行った上で削除・解放を実行します。削除前後のコストをCost Explorerで比較し、削減効果を定量化します。

削除は変更管理プロセス（作業計画書・承認・実施・事後確認）に従って行うことが、障害リスクを下げる上で重要です。

ステップ4：タグ整備・定期棚卸い体制の構築

クリーンアップ後、再び「取り残し」が発生しないよう、タグポリシーの整備と定期棚卸いの仕組みを作ります。AWS Config RulesやIaC（Infrastructure as Code）ツールでタグ必須化ルールを設定し、Cost AnomalyDetection（コスト異常検出）での自動アラートを組み合わせることで、次の取り残しを早期発見できる体制を構築します。

この体制化まで含めて委託できるかどうかが、単発の「削除作業代行」と継続支援の分かれ目になります。

外注先を選ぶ3つのチェックポイント

棚卸し・削除の外注先を選定する際に確認すべきポイントを整理します。

チェック1：AWS実績とCost Explorer/Trusted Advisor/Compute Optimizerの活用スキル

AWSの各ツールを実際の棚卸い業務に活用した実績があるかどうかを確認します。ツールの名称を知っているだけでなく、Trusted Advisorのチェック結果をどう解釈し、削除判断にどう繋げるかという実務経験が重要です。

AWS認定資格（AWS Certified Solutions Architect等）の保有者が担当するかどうかも一つの目安になります。

チェック2：元請（プライムベンダー）として横断的に対応できるか

棚卸し・削除はAWSコンソール操作だけでなく、アプリケーション・ネットワーク・セキュリティを横断した判断が求められます。特定サービスの専門業者に個別に発注すると、連携の隙間で「誰も判断しない」リソースが残ります。

クラウド基盤全体を元請（プライムベンダー）として一括で担える体制があるかどうかが、作業の確実性を左右します。

チェック3：定期棚卸いの継続支援まで対応できるか

前述のとおり、棚卸し・削除は一度完了しても次のサイクルが発生します。初回クリーンアップ後に月次・四半期の定期確認、タグポリシーの維持、Cost Anomaly Detection（コスト異常検出）のアラート対応まで含めた継続的な支援が可能かどうかを確認してください。

契約形態として「スポット対応（単発）」と「継続的な運用保守契約」のどちらに対応しているかも、費用設計の検討に影響します。

LASSICでは、クラウド基盤の構築・運用保守を元請（プライムベンダー）として対応できます。棚卸し・削除の実務だけでなく、タグ運用整備や定期棚卸い体制の構築まで含めた継続支援の実績を持ちます。

まとめ——棚卸し・削除で削れるコストを見極める3つの判断軸

本稿では、クラウドの未使用リソース棚卸し・削除によるコスト削減の外注について整理しました。要点を3つに集約すると次のとおりです。

第一に、棚卸しの起点はツールの活用です。AWS Cost Explorer・Trusted Advisor・Compute Optimizerを組み合わせることで、アイドル状態や未使用のリソースを候補としてリストアップできます。ただし削除可否の最終判断には依存関係調査が欠かせず、ツール出力は入口に過ぎません。

第二に、削除作業のリスクは内製で過小評価されやすい点です。タグ未整備の環境では所有者不明のリソースが多く、誤削除は本番障害に直結します。変更管理プロセスと事前バックアップをきちんと踏める体制が求められます。

第三に、外注先選定では「単発のクリーンアップ代行」か「継続的な棚卸い体制の構築まで対応できるか」を区別することが大切です。タグポリシーの整備と定期棚卸いまで含めて委託できれば、再び取り残しが蓄積するリスクを下げられます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「AWS Well-Architected Framework Cost Optimization Pillar — COST04 Decommission resources」
2. *2　出典：Amazon Web Services「Amazon VPC Pricing — Public IPv4 Address」（2024年以降、使用中・未使用とも$0.005/時間）
3. *3　出典：Amazon Web Services「What is AWS Compute Optimizer?」

Tweet