How to Manage Multiple Cloud Accounts Without Losing Track

One account per client. One per environment. One that came with an acquisition and one nobody can explain. Whether you are an agency, a consultancy or just the person who has been here longest, the count only ever goes up.

Each cloud calls the boundary something different. AWS has accounts, Azure has subscriptions, Google Cloud has projects. They are not identical, and for this problem the difference does not matter, because the pain is the same in all three: the console shows you one at a time, and the question you were asked spans all of them.

The answer that is quietly incomplete

Start with this one, because it undermines everything else you do.

Azure Resource Graph is the tool for querying across many subscriptions at once. It is free and it is good. It also only returns what your login can read, and here is Microsoft's own description of what happens when you are missing access to some of them: "you get resource groups that you can access, without any indication that the result might be partial".

Without any indication. You ask what is exposed to the internet across the company, four things come back, and you move on. The two subscriptions you cannot read contributed nothing and nothing said so.

The principle generalises past Azure. Every cross-account query you run is scoped by your own permissions, and almost none of them tell you what they left out. A clean result is not the same as a clean estate.

So the first habit is counting. Keep a written list of every account, subscription and project you are responsible for. Not in your head and not implied by what shows up in a dropdown. A list, somewhere, with an owner against each one. Then reconcile every answer you get against that count before you believe it.

It sounds too simple to be the important part. It is the important part, because everything else is downstream of knowing what exists.

The tax you are paying without noticing

Switching accounts is about thirty seconds. That is not the cost.

The cost is that a thirty second barrier turns cheap questions into decisions. "Is that thing still running in the client-four account" stops being a thought and becomes a task, and tasks get deferred. Multiply by six accounts and the effect is that you only ever look at whichever account is already open.

The accounts you have not looked at are exactly where the surprises are. Not because anything is wrong with them, because nobody has checked.

Roll the money up to the top

This is the quickest win available and most people never change it, because the default view is per account and the default looks like the only option.

On Azure, Cost Management works on a scope. Open it inside a subscription and you see that subscription. Change the scope to the billing account or a management group and you get the combined number with subscription as a grouping.

AWS and Google Cloud both have the equivalent: a billing view above the individual account, with the account as a dimension you group by rather than a wall you have to climb.

Set a budget at that top scope as well as per account. One account doubling from forty to eighty is invisible in six separate views and obvious in one total.

On Google Cloud there is an extra thing to check, because the billing account is a separate object from the project. You can hold a project and not have access to the billing account it is linked to. Inheriting responsibility for something you cannot see the price of is a bad position, and it is quiet, so go and confirm you actually have that access.

Access is the thing that rots

Resources are visible. Somebody notices a machine. Nobody notices a role assignment.

Every account you manage accumulates access that made sense once. Contractors who finished. A service account created for a migration that completed two years ago. Someone's personal login from before you had proper groups. None of it announces itself and none of it appears on a cost report.

Once a quarter, per account, open the access list and read it. That is the whole practice. You are not looking for attackers, you are looking for people and machines that no longer need to be there, and you will find some every time.

Pay particular attention to the roles that are broader than they look. On Azure, Contributor can pull storage account keys and read all the data behind them. On Google Cloud, the default Compute Engine service account may hold Editor across the whole project. Neither of those reads as dangerous on the screen.

Standardise the two cheapest things

Naming and tags. Both are free, both are additive, and both pay you back every single time.

A name that tells you the client, the environment and the purpose removes a lookup you would otherwise do a hundred times. A tag saying who owns a resource and when somebody last confirmed it is still needed is the difference between an audit and an archaeology dig.

Do not try to retrofit this everywhere at once. Apply it to everything new, and to anything you touch for another reason. Within a few months most of what matters is covered, and you never had to schedule a project for it.

The shorter way

All of the above is real work and it is the right work. It also does not scale past the point where you can hold the list in your head, and that point arrives sooner than anybody expects.

Liberra treats the account as the unit and then stops caring how many there are. Connect each one, AWS or Azure, and they go into one index together. Six accounts run the same code as one, six times.

The account selector in the interface is a view filter and nothing more. It changes what you are looking at, never what the AI can reach. That is deliberate, and it is the direct answer to the partial result problem: you cannot accidentally ask a question of one account while believing you asked it of all of them.

So the questions get cheap again. What is running everywhere. What am I spending in total and which account moved. Who has access they should not. The thirty second barrier goes away, and the questions you stopped asking come back.

And across every account, one safety rule rather than one per account. Liberra cannot delete anything, because the delete commands are blocked in the code, not in permissions you would have to configure correctly six times. Every write stops and waits for your approval. More accounts means more chances to be tired and click the wrong thing, which is exactly when a rule that cannot be misconfigured earns its place.

Founder, Liberra AI