[アップデート] AWS Compute Optimizer のアイドル検出対象に DynamoDB・WorkSpaces など 6 種類のリソースが追加されました

こんにちは！クラウド事業本部のおつまみです。

みなさん、AWS Compute Optimizer のアイドルリソース検出機能を使っていますか？
使われていないのに課金され続けているリソースを見つけてくれる、コスト最適化に欠かせない機能です。

これまでは EC2 や Auto Scaling グループ、EBS ボリュームなど、限られたリソースしかアイドル判定の対象になっていませんでしたが、今回のアップデートで 6 種類のリソースタイプ が新たにアイドル検出の対象に追加されました！

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/aws-compute-optimizer-six-new-idle/

早速確認してみよう！とのことで、今回は概要と注目ポイントについてご紹介します。

3行まとめ

1. AWS Compute Optimizer のアイドル検出対象に新しく 6 種類のリソースタイプが追加された
2. 対象は DynamoDB、ElastiCache、MemoryDB、DocumentDB、WorkSpaces、SageMaker エンドポイント
3. これまで見逃しがちだった「使われていない DB・キャッシュ・仮想デスクトップ・ML エンドポイント」のコスト浪費を可視化できるようになった

アップデートにより何が嬉しくなったのか

AWS Compute Optimizer は、機械学習を用いて利用状況メトリクスを分析し、リソースが「アイドル状態（idle）」かどうかを判定してくれる機能を提供しています。
アイドルと判定されたリソースは、停止・削除・縮小の候補としてレコメンドされます。

これまでも EC2 インスタンスや Auto Scaling グループ、EBS ボリュームなどはアイドル検出の対象でしたが、データベース・キャッシュ・WorkSpaces・SageMaker といった「停止し忘れ・使い忘れ」が起こりやすいサービスは対象外でした。

今回のアップデートにより、以下のメリットがあります。

• 使われていない DB・キャッシュを発見できる: 検証用に作って放置されている DynamoDB テーブルや ElastiCache・MemoryDB クラスター、DocumentDB クラスターのアイドル状態を検出できる
• 使われていない WorkSpaces を発見できる: 退職者・異動者の WorkSpaces や、長期間利用されていない WorkSpace を可視化できる
• 使われていない SageMaker エンドポイントを発見できる: 推論リクエストが来ていないにも関わらず起動し続けているエンドポイントを検出できる
• アイドル判定はサービス固有の利用シグナルで評価: 単純な CPU 使用率だけでなく、各サービスの特性に合わせた指標で判定される

「気づけば月末に高額請求」という事故を防ぐためにも、嬉しいアップデートです。

新たにアイドル検出対象になったリソース

今回追加されたリソースは以下の 6 種類です。

リソースタイプ	対象範囲
Amazon DynamoDB	プロビジョニングテーブル
Amazon ElastiCache	Redis OSS および Valkey
Amazon MemoryDB	クラスター
Amazon DocumentDB	プロビジョニング型およびサーバーレス
Amazon WorkSpaces	WorkSpace
Amazon SageMaker	エンドポイント

データストア系（DynamoDB・ElastiCache・MemoryDB・DocumentDB）、エンドユーザー向け（WorkSpaces）、ML 推論（SageMaker エンドポイント）と幅広いカテゴリのリソースが一気に対象に加わりました。

確認してみた

実際に AWS Compute Optimizer のコンソールで、新たに追加されたアイドル推奨を確認してみます。

手順 1. Compute Optimizer のコンソールを開く

AWS マネジメントコンソールにサインインし、Compute Optimizer を開きます。

今回追加されたリソースが表示されていることがわかります。

手順 2. アイドル推奨の一覧を確認する

左メニューの アイドル状態のリソース を選択すると、アイドル状態と判定されたリソースの一覧が表示されます。

手順 3. リソースタイプでフィルタする

フィルタで Resource type を指定すると、今回追加されたサービスごとに絞り込んで確認できます。

手順 4. 個別の推奨内容を確認する

リソース名をクリックすると、アイドル判定の根拠となった利用状況メトリクスや、推奨される対応（削除・停止など）と推定削減額が確認できます。

DynamoDBはConsumed read capacity unitsとConsumed write capacity unitsで判断していることがわかりますね。
また推定削減額が$0なので、おそらく検証用で作成され、現在は稼働していないリソースであることがわかります。

このように利用状況の少ないリソースが想定通りピックアップされていることが確認できました。

利用時の注意点

Compute Optimizer のアイドル推奨を活用する際は、以下の点に注意してください。

「アイドル」判定はあくまで利用状況に基づく

サービス固有の利用シグナル（リクエスト数・接続数・トラフィックなど）から判定されるため、定期バッチで一時的にしか使われないリソースなど、利用パターンによってはアイドルと判定される可能性があります。削除前に必ず用途・所有者を確認してください。

ルックバック期間（評価期間）に注意

Compute Optimizer のアイドル判定は、デフォルトで 過去 14 日間 の利用状況メトリクスをもとに行われます（EBS ボリュームや NAT Gateway など一部リソースは 32 日間）。

そのため、以下のようなケースでは注意が必要です。

• 月次バッチや四半期処理など、ルックバック期間より長い周期で稼働するリソースは、本来必要であっても「アイドル」と判定されてしまう可能性がある
• 直近で作成・運用開始したばかりのリソースは、評価期間中の利用実績が少ないためアイドル扱いされやすい

削除や停止を判断する際は、ルックバック期間より長いスパンでの利用パターンを所有者に確認することをおすすめします。なお、ルックバック期間は Compute Optimizer の ライトサイジング設定 から拡張することもできるので、より長期の利用傾向で評価したい場合は設定変更を検討してください。

WorkSpaces や DB リソースの削除はデータ消失を伴う

WorkSpaces のユーザーディレクトリや DynamoDB・DocumentDB・MemoryDB のデータは、削除すると基本的に復元できません。スナップショット・バックアップを取得したうえで、関係者の確認を経てから削除を進めてください。

まとめ

今回は AWS Compute Optimizer のアイドル検出対象に新しく 6 種類のリソース（DynamoDB・ElastiCache・MemoryDB・DocumentDB・WorkSpaces・SageMaker エンドポイント）が追加されたアップデートをご紹介しました。

これまで「気づけば放置されていた」系のリソースを Compute Optimizer 経由で機械的に拾えるようになるのは、コスト最適化を継続的に進めるうえで非常に大きい変化です。すでに Compute Optimizer を有効化されている方は、次のコストレビューのタイミングでぜひ新しいアイドル推奨を確認してみてください。

最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。

以上、おつまみでした！

参考

• AWS Compute Optimizer now supports idle recommendations for six additional resource types
• アイドル状態のリソースに関する推奨事項の表示 - AWS Compute Optimizer