Mike Julian Profile picture
Dec 3 13 tweets 2 min read
I've been neck-deep in AWS billing data all day and all the technical debt AWS has here is somewhat amusing.

And, also, I feel for them so hard.

Some things that stand out 🧵
UsageTypes have regional prefixes (eg, USW2-EBS:VolumeUsage.gp2 for gp2 EBS volume in us-west-2).

Except us-east-1, which has no regional prefix, so the UsageType is VolumeUsage.gp2.

This is true of every UsageType for every service in us-east-1.
Speaking of EBS, every volume type has a code associated: VolumeUsage.gp2, VolumeUsage.io2, etc.

Except magnetic volumes, which are simply VolumeUsage.

Likewise, io1 is VolumeUsage.piops while io2 and VolumeUsage.io2, thanks to io1 previously being called Provisioned IOPS.
The EC2-Other service is a catch-all of stuff: inter-AZ data transfer, EBS volumes, VPC Peering, Elastic IPs

Basically none of which belongs there but one can imagine when AWS was young, this made sense.

Managed NAT Gateway is also here, presumably for lack of a better place
Interestingly, data transfer charges are under a separate AWSDataTransfer product code in the raw data but not in Cost Explorer. Maybe we'll see that reflected in Cost Explorer one day.
S3 storage likewise has UsageTypes: TimedStorage-GIR for Glacier Instant Retrieval, TimedStorage-INT-FA for Intelligent Tiering Frequent Access, TimedStorage-SIA for Standard Infrequent Access.

Standard, however, is simply TimedStorage.
Even the name 'Standard Infrequent Access' seems to me to be a bit of technical debt, considering how many other tiers there are now. SIA's main difference is one nine less availability than Standard.
Some RI-covered instances show up as UsageType 'HeavyUsage' instead of InstanceUsage (RDS) or BoxUsage (EC2).

This is an anacronism dating back over ten years now, when AWS had light, medium, and heavy RIs that came with different discount levels

aws.amazon.com/about-aws/what…
Some services will bill for out-of-cycle billing charges, typically to cover overages or unmet commits from private pricing. They're typically grouped with the service incurring the fee.

Cloudfront, though, bills these through its own top-level service 'OCBCloudfront'.
Speaking of OCB, Enterprise Support is called Premium Support in the bill and also gets charged under a top-level service OCBPremiumSupport.

Cost Explorer shows this one as simply Premium Support, without the OCB bit (unlike Cloudfront).
And that's all for now. Back to the depths of hell for me now!
An interesting find that speaks to iteration:

Cross-AZ data transfer is UsageType XXX-DataTransfer-Regional-Bytes where XXX is the region code (or not for us-east-1!)

There now appears to be a UsageType XXX-DataTransfer-xAZ-In-Bytes, though it's currently being billed at zero
Notably, no DataTransfer-xAZ-Out-Bytes though.

I wonder if this is the start of replacing the usage type to make it easier to understand?

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Mike Julian

Mike Julian Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @mike_julian

Jun 8
I once heard @moonpolysoft comment that monitoring tools are what SREs build when they don't have any better ideas. That was some years ago, now.

I think the current iteration of that is:

Cloud cost tools are what engineers build when they don't have a better idea.
Seems like I'm finding new cloud cost tools every damn day, and there's basically clones of each other (which are, in turn, clones of Cost Explorer).

It's just getting silly.
In all seriousness, I don't have a problem with people starting new things in a space other people are. That's actually a good thing.

I'm a little annoyed that so many have a core product thesis of "cloud is expensive, it should be cheaper"

That's just lazy customer research.
Read 11 tweets
Jun 6
I love @ScrivenerApp. This is the second book I've written with it.

And yet, I still have one glaring problem: how to track feedback easily?

Last time, it was such a pain I stopped using Scrivener because the workflow necessary created new problems.
Last time, feedback came in via email comments and marked-up PDF/DOC. I'd then implement it, generate a new manuscript, and share that one.

Such a pain in the ass with all the different manuscript versions it resulted in.
My plan this time is to use @robfitz's helpthisbook.com for feedback management in a more iterative, ongoing way.

I think that's going to be a PITA on my end, though, because I'll still be syncing things up manually.
Read 4 tweets
May 1
A friend asked me recently what I think the big things are that make GCP, Azure, and AWS different from each other.

I think the biggest thing is how they view customers.
GCP, organizationally, seems to have disdain for customers. Almost as if the whole org is thinking, "We would have the best cloud if it weren't for all these pesky customers bothering us"

I don't know how true that is personally, but it's my perception.
Steve Yegge wrote a great piece about GCP's product management a while back. It's sort of a scathing indictment on this topic of how GCP views customers.

steve-yegge.medium.com/dear-google-cl…
Read 15 tweets
Mar 15
One of the things that's always bugged me about the way @DuckbillGroup does consulting is that we inevitably move further and further upmarket as we go.

Today we've made a move to help our smaller, more startup-y brethren. 🧵
The main issue is that AWS bills get shockingly large.

We have clients spending $5mm/mo (and more!) on AWS.

When you've got a choice between working on a $250k/mo bill and a $5m/mo bill, you go with the latter--you can charge more.
But that means over time, you start to leave behind the smaller organizations. That sucks! I love small companies.

Their issues with the AWS bill are just as painful (sometimes more so).

It's been hard to find a way to help both ends of the market.
Read 9 tweets
Jan 13
I've had a front-row seat to organizations building cloud finance teams.

Here's the top three mistakes I see most of them making. 🧵
#1 - Putting a finance person in charge of it

Managing cloud costs is an engineering problem, not a finance one. Finance has to assume that's what running is correct and that's a bad assumption.
By putting an engineer in charge, they can question how things are built and drive significantly more savings long-term than finance can.

I went into more detail on this point in this thread:
Read 8 tweets
Jan 10
One of the most misunderstand aspects of managing an AWS bill is that people often think it's a finance problem.

It's not.

It's an engineering problem.

A thread. 🧵
The challenge comes down to this:

Cost and architecture are the same problem.

To optimize cost, you're optimizing architecture. That's engineering, not finance.
The best finance can do here is buy RIs/SPs and negotiate contracts.

That's valuable but it has a huge downside: It assumes the architecture is already optimized.
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(