How to Do Chargeback For Networking and Shared Services

Just when you didn't think chargeback could get more granular...

We’ve all heard about chargeback for account usage and consumption. It’s such a common topic and model that everyone aspires to have. But what if there was a way to go beyond that and do chargeback for shared services and networking?

Turns out, there is.

While I don’t imagine this will catch on with customers pushing a few GB of data over the pipes every week, it might just appeal to a sizable organization with sizable data transfer that leverages their networks and shared services for others to use and don’t have a nice, neat way to charge for it. Or maybe it just hasn’t occurred to them before?

Truthfully, it would be much the same as a landlord eating the utility bill for a renter. The consumption and mileage may vary by customer, so why not at least consider charging for it?

I have two articles to share with you today that might help you resolve that.

Chargeback for Shared Services (and Networking)

The first of course comes from the FinOps wizards in the AWS Cloud Financial Management team in the following AWS blog titled, “How-to chargeback shared services: An AWS Transit Gateway example.”

What I love about this article is that not only does it provide you a great approach at designing a chargeback strategy, it gives you some sample code to do it as well.

I’ve talked before about how Transit Gateway fees can rack up over time with a high enough volume of data transfer. Perhaps not earth-shattering, but it can become noticeable when it gets into the 100 TB and above range. Couple that with fees for the NAT Gateway, the Gateway Load Balancer, and other network services in the flow of traffic and it can collectively add up to quite a bit over time.

I love this idea of chargeback for shared and network services. I think it is a great tool to have for organizations where the cost incurred from providing a service is significant enough that it makes sense to charge for it.

Querying and quantifying those costs where they occur in a tactical manner like as described in the above article is a great way to achieve that granular chargeback that more accurately distributes the cost. In a way, creating a mini cloud within a cloud!

This requires a well-designed account structure first and foremost (see below). There’s no getting around that hard object. But if that’s in place, and chargeback for wider account consumption is already taken into account, this could be the next logical step.

A common centralized architecture, as depicted in Article 2

Let’s back up to that querying for a second. There are two ways to go about this, and this is where I’ll get into the second article I mentioned earlier:

1. In the first article, the query is performed using Athena (a SQL-based querying service) and the AWS Cost and Usage Reports (CUR). Anyone using AWS can generate these, so it would be a logical place to start for most organizations that already are used to working with the CUR and have someone with the SQL chops to query it. This is plenty powerful, but might not be the most granular way to identify and chargeback costs.

2. The second article, “Using AWS Transit Gateway Flow Logs to chargeback data processing costs in a multi-account environment” uses a combination of both the CUR and Flow Logs to achieve a similar but more granular effect. You use CUR for the final pricing, but use Flow Logs to identify the byte percentage. This really builds on top of the previous, but it also creates a capability that is beneficial towards better networking practices (gathering, using and querying VPC Flow Logs in a multi-account architecture).

When this information is gathered and queries, you can at that point take it and charge the spoke accounts. The recommendation in the articles is to use the byte percentage against the cost of shared services from the CUR, but no matter how you decide to distribute costs this will provide you a much more granular way to do so.

This could also be done for a service endpoint in a SaaS provider environment, where PrivateLink is used to connect to some service provider VPC.

Share your services through AWS PrivateLink - Amazon Virtual Private Cloud

But Why?

Using your imagination, there are many ways to get after granular chargeback. But should you?

This is a fair question, because passing on the costs to consumers isn’t always the best choice. Starting with the business model, and the price transparency around various billing models and service offerings is probably a good place to start. I wouldn’t recommend spinning all this up without ensuring Finance is on board!

However, I think it’s fair to propose this as an option when the organization is already bought in on a chargeback model. It’s sensible and fiscally responsible, especially if there is nothing currently in place to observe and identify costs associated with consumption of shared services and network services.

Ultimately, this is another tool to improve your own observability of spend. Use it wisely!