Reference · built on requestOperator by FibricIT & reliability

Idle Resources

Reads cloud inventory, utilization, and owner tags. Finds unattached volumes and idle instances and proposes a stop or delete to each owner.

Request accessPricing ↗

About

Idle capacity has an owner, and the owner is the one who can say whether it is idle. Idle Resources reads the recommendations Datadog builds from billing and utilization data, the hosts it knows with their tags, and the CloudWatch metrics behind each instance and volume. It groups what it finds by the owner tag.

Per owner, it proposes a stop for each instance that sat below the line for the whole window and a delete for each volume in status available. Each owner sees their own list in Slack or Microsoft Teams and answers item by item. An approved stop or delete runs once, and the result the cloud API returned is kept with the approval. A resource with no owner tag goes to a ticket for the cloud team, never to a delete.

This is a reference listing. It documents what Fibric would read from Idle Resources and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Cloud Cost Recommendations in Datadog: unattached EBS volumes, idle EC2 instances, unused Elastic IPs, and unattached Azure managed disks, with their Open or Dismissed status
  • Hosts through GET /api/v1/hosts in Datadog, with aws_name, last_reported_time, up, and tags_by_source, so the owner tag arrives with the host
  • CPUUtilization, NetworkIn, and NetworkOut per InstanceId in the AWS/EC2 namespace, at 5-minute periods or every minute with detailed monitoring
  • VolumeIdleTime, VolumeReadOps, and VolumeWriteOps per VolumeId in the AWS/EBS namespace, sent only while a volume is attached
  • Volumes with status available through DescribeVolumes, filtered by tag:<key>, with Size, VolumeType, and CreateTime, when an account role is attached
  • Approve and decline responses from each owner in Slack or Microsoft Teams

Proposed actions

  • Target capability: propose stopping an instance through StopInstances, to its tagged owner, with the utilization window that decided it and the volumes it keeps
  • Target capability: propose deleting a volume in status available, to its tagged owner, with its size, type, and create time, and a snapshot first
  • Target capability: propose muting the host in Datadog through POST /api/v1/host/{host_name}/mute once a stop is approved, so the stop raises no alert
  • Target capability: propose a Jira issue through POST /rest/api/3/issue for each resource with no owner tag, with the savings estimate Datadog attaches
  • Target capability: propose one message per owner in Slack or Microsoft Teams, with approve and decline per item

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Return unattached volumes to their owners

    Datadog lists unattached EBS volumes. The operator confirms each with DescribeVolumes, status available, groups them by the Owner tag, and posts one message per owner in Slack. Each approved volume is deleted once.

    With Datadog, Slack

  • Stop the instance nobody has used

    CPUUtilization and NetworkIn in CloudWatch stay near zero for the whole window. The operator proposes a stop to the owner, with the graph, and mutes the host in Datadog once approved so the stop raises no alert.

    With Amazon CloudWatch, Datadog

  • Do the same for Azure disks and VMs

    Datadog's Azure recommendations list unattached managed disks and VMs with low CPU and high available memory. The operator proposes a stop or delete to each owner in Microsoft Teams, with the savings estimate attached.

    With Datadog, Microsoft Teams

  • Ticket what has no owner

    An idle instance carries no Owner tag. The operator opens a Jira issue with the instance id, its utilization, and the recommendation, and assigns it to the cloud team to tag or remove.

    With Jira, Datadog

Requirements

  • A Datadog organization with the AWS or Azure integration and Cloud Cost Management, so recommendations and host tags exist
  • Read access to the AWS/EC2 and AWS/EBS namespaces in CloudWatch, with detailed monitoring where a 1-minute view matters
  • An owner tag key agreed in advance, such as Owner, present on instances and volumes
  • An account role allowed to describe volumes, stop instances, and delete volumes. Without it, proposals reach owners as messages only
  • A Slack or Microsoft Teams channel, or a direct message route, per owner
Authentication
Runs on a Datadog API key and application key, CloudWatch read access, and, for stops and deletes, a cloud account role you attach at deployment. It holds nothing of its own.

Limits

  • EBS sends metrics only while a volume is attached. An unattached volume is found through Datadog recommendations or DescribeVolumes, never through metrics
  • A resource without an owner tag has nobody to propose to. It goes to a ticket for the cloud team, never to a delete
  • Stopping an instance ends instance charges. Its root and data volumes persist and stay billed. Instance store-backed instances cannot be stopped
  • Datadog refreshes recommendations daily and does not act on them. Neither does this operator without an approval

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Idle Resources ↗

Questions and answers

What does an owner approve?
Each item on their list, one at a time: stop this instance, delete this volume. The proposal shows the utilization window or the attachment state, the size and type, and the savings estimate. An owner can decline any item. Approval applies that one change once.
What record is left when something is stopped or deleted?
A line per resource: the id, the evidence, the owner who approved, the time, and the result the cloud API returned, such as the instance's previous and current state. For a deleted volume the record names the snapshot taken first, when one was.
Does it stop or delete anything on its own?
No. Every stop and delete is a proposal to a named owner. Untagged resources are ticketed, not touched. A stop the owner declines is recorded as declined and not proposed again until the utilization window has passed once more.
Ask about Idle Resources

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy