ASAdSail LLC

A free read of your cloud bill, naming what is being spent on nothing.

Live

Cloud bills grow the way office junk drawers do: nobody adds much, nobody removes anything, and two years later a quarter of it is running for people who left. The read costs nothing, so the only question you have to answer up front is whether you can be bothered to grant read-only access.

Why it is free, and what is not attached to it

Because describing this work is worth less than doing it. A document naming four thousand dollars a year running for nobody makes the case better than any page can, and if there is nothing to find you should not have paid to discover that. There is no percentage of savings, no success fee and no invoice at the end. Apply everything, apply nothing, hand the document to your own team, or hand it to another vendor — none of that changes what you owe, which is nothing. If you would rather it did not drift back, there is a monthly watch below, and it is optional in the ordinary sense of the word.

What you get

The whole read, for nothing. No card, no deposit, no minimum spend to qualify.
Read-only access only. Nothing gets changed, and nothing can be — the role we ask for cannot start, stop, resize or delete anything.
Waste named in currency per month, not as a percentage of a percentage.
Instances, volumes, snapshots, load balancers and databases running for nobody, listed individually so each one is a decision you can make or refuse.
The commitment question answered with your own numbers: what a reserved or savings-plan purchase would return at your actual usage, and where it would lock you into a mistake.
The items not worth the engineering time marked as not worth it, because a fix list that ignores your team's hours is a fantasy.
Yours to keep, and to act on with whoever you like, including nobody.

What this is not

Making the changes. The document says what to do; you or your team do it.
Group buying. Some vendors pool customers to negotiate volume discounts off the provider. That is a real mechanism, it is a large part of why they can guarantee a percentage, and it is not one we have.
A savings guarantee. If the account is already tight, the document says so and you have a clean bill of health.
Any obligation. Nothing follows from taking this, and no invoice ever arrives for it.

How it runs

01
You grant read-only access
A billing and describe-level role, revocable the moment the document lands.
02
The account gets read against the bill
Every line item traced to the thing generating it, and every running resource checked for whether anything actually uses it.
03
You get the document
In priority order, sized in money per month, with the effort to remove each item stated next to it. Then you decide, and we are not part of that decision.

Questions

What is the catch?

There is not one, and the honest reason is that this is how we would rather sell the monthly watch — by doing a piece of the work instead of describing it. If the document is good you may want the watch. If it is not, you have lost an afternoon of access permissions.

Will you find enough to be worth it?

Usually, on a bill of any size, and that is an observation rather than a promise. If the account is already tight you get told that, which is worth knowing and costs you nothing to find out.

Can I give the document to my own team?

Yes, and that is the expected outcome for most people. It is yours.

Which providers?

AWS is where this is strongest, because that is where our own estate runs. Other providers are read on the same method with less pattern behind it, and you are told which you are getting before you grant access.

Is read-only really enough?

Yes. Everything here comes from billing data and resource descriptions. Write access would add risk and buy nothing, so it is not requested.

Also in devops

The same read, running continuously, shouting the week the bill starts drifting again. Servers provisioned, locked down and backed up, so they stop being your problem. Jobs that run unattended and shout the moment one stops running. A deploy pipeline that ships from your repo and rolls back in one step. Scrapers and pipelines that put somebody else's data into your own store, on a schedule. Credentials out of your code and your env files, injected at run time instead.