Amazon Web Services Cost Management Headaches
Amazon Web Services (AWS) is an intrinsic and unavoidable, but highly useful, tool for most development and DevOps teams. Their businesses want to ensure developers, designers, testers, … everyone has access to the tools, virtual machines, storage and other services as and when they need them. The beauty of elastic services such as AWS is that you can scale up and down your resource allocations as needed. In theory, that means you shouldn’t have to pay for any more resource than you actually need or use.
However, the reality isn’t always quite so clean. Test systems get started and execution takes a lot longer than originally thought. Engineers might spin up virtual machines and forget to shut them down. In general, every team has, at some point, had a bit of surprise when they’ve been challenged at the end of the month or quarter to explain the bill that the Finance team have just received from AWS.
Understanding the AWS Bill
At Osirium, several teams have access to AWS. Normally, the engineering team don’t usually pay too much attention to the AWS bill. The first our operations department, who are responsible for paying the bills, know about these costs is when the invoice turns up. Then they have to work out who ran which systems and ask the questions around do they still need them.
Giving the Operations team direct access to AWS management would be a non-starter. That could mean sharing valuable AWS account login information, but, even then, working out how to navigate the AWS reports and dashboards can be a complicated process. We needed a better way for the Operations team to easily verify bills before making payment.
Opus to the Rescue!
Therefore, our Opus team created a simple task to read the state of our AWS bills and a forecast of the current months spend.
Of course, they are separating the operations department from the AWS API key. But crucially they are separated from the whole AWS interface. The Ops team get the information they need when they need it, and without interrupting the teams that use AWS.
AWS is just one example. As with many organisations, we also use Azure and other systems and we’ve extended the Opus task to also report on Azure usage.
This is a classic example of using Opus to automate complex operations using privileged technical processes to deliver information financial billing information while never exposing valuable AWS credentials. If this is similar to an issue that you’d like to solve — as always, please get in touch.