The Problem: A Growing Cloud, a Growing Blind Spot

For a company that runs infrastructure services for its customers, staying on top of its own infrastructure is not optional; it’s the business. That’s why the operations team at one cloud hosting provider was bothered by a problem that seemed like it should have a simple solution: they couldn’t tell, at a glance, which of their cloud servers were covered by cost-saving long-term commitments and which ones were running at the more expensive pay-as-you-go rate.

The issue was specific to how cloud providers like AWS structure their pricing. When a business commits to running a certain type of server for a year or more, it can pay a lower rate, often significantly lower than what it would pay without any commitment. These agreements are worth real money. But to get the discount, the details of the commitment have to match the actual server exactly: the right type, the right region, the right operating system. A mismatch means the discount doesn’t apply and the company pays more than it should.

As the company’s infrastructure grew from a handful of servers to dozens and then to well over a hundred, keeping track of all of this became genuinely difficult. The cloud provider’s own reporting tools would tell you, in aggregate, whether your commitments were being used. What they couldn’t tell you was which specific server was covered by which specific agreement, or which servers weren’t covered at all.

The operations team had been managing this with a combination of browser tabs, manual notes, and institutional memory. It worked until someone left the company, or until the volume of servers grew large enough that the informal tracking system simply broke down. They needed something better.

“The cloud console would tell us our commitments were being used. What it couldn’t tell us was which specific server was covered and which ones weren’t. That gap was costing us money every month.” — Director of Operations

Using RT to Track What the Cloud Console Couldn’t

The team already used Request Tracker to manage customer support and internal IT requests. When they started thinking about the infrastructure tracking problem, they realized they were essentially describing an asset management challenge, and RT had an asset management module built in.

The setup took a few weeks. The team configured RT to automatically pull in data from their cloud provider, so every server and database instance appeared as a tracked record in the system with all the relevant details: server type, region, operating system, and current status. A parallel set of records was created to represent their purchased commitments, with start and end dates, agreement terms, and current status.

Then came the part that changed everything: connecting the two. Each commitment was linked to the specific server it covered. The system could then automatically surface every server running without a commitment, giving the team a clear, accurate view of exactly where money was being left on the table. That report became a shopping list for new agreements.

Making the case for a new agreement also became easier. Previously, buying a commitment meant carefully copying information from one part of the cloud console to another, checking every field manually to make sure the details matched. With everything in RT, the team could pull up a server record, see exactly what attributes a matching commitment would need, and fill out the purchase form with confidence. The risk of a mismatch, along with the wasted money that came with it, dropped significantly.

Getting Ahead of Expiring Agreements

One of the most valuable features turned out to be expiration tracking. Every commitment has a duration, typically one to three years, and when one expires, the server it covered reverts to the more expensive rate, usually without any automatic notification.

In RT, the end date of each commitment was stored alongside all the other details. The system automatically flagged any commitments expiring within the next 60 days. Rather than discovering an expired agreement after the fact (when a higher-than-expected bill arrived), the operations team could plan renewals in advance, maintaining cost coverage without interruption.

A second report tracked recently expired agreements, catching anything that had slipped through. Together, these two views gave the team the kind of forward-looking visibility that simply hadn’t existed before.

Infrastructure That Connects to Everything Else

The cost savings were significant, but the deeper benefit was connection. Once the company’s cloud infrastructure was represented in RT as assets, it could be linked to everything else the company tracked in the same system: customer support tickets, change management records, service agreements, even sales activity.

When a customer reported an issue, support staff could see which servers were involved and whether any maintenance or changes had recently taken place. When an infrastructure change was planned, the relevant servers could be linked to the change request, creating a complete record. The infrastructure was no longer a separate world that lived in the cloud console; it was part of the same connected picture that the whole team could see and work with.

That integration turned out to be worth at least as much as the direct cost savings. For a company whose entire business runs on its infrastructure, having that infrastructure visible and connected to the rest of operations is a meaningful competitive advantage.

“We started this project to save money on cloud costs. What we didn’t expect was that it would also change how we handle customer escalations and infrastructure changes, because now everything connects.” — Director of Operations