How to Manage AWS and Azure Without a Cloud Team
Running two clouds is harder than running two of the same cloud, and the reason is not the tooling. It is that the same word means different things in each one.
Almost nobody chooses to run two clouds. It happens. An acquisition brings one in. A client insists. A team picked the thing they knew and the thing outlived the team. Someone got credits.
Then you are the person holding both, and there is no second hire coming.
The usual advice is to consolidate. Sometimes that is right. Usually it is a year of migration work to solve a problem that a different approach solves in a week, so let us talk about the different approach.
Why two clouds is harder than twice one cloud
If it were just twice the work it would be fine. Twice the work is a scheduling problem and you would solve it.
The actual cost is that your instincts stop being reliable. You learn a rule, it is correct, and it is correct in one place only. The word is the same in both clouds and the behaviour underneath is not, so being experienced makes you confident in exactly the situation where you should not be.
Three examples, all real, all things I would bet money catch people this month.
Off does not mean off
On Azure, shutting a VM down from inside the operating system puts it in a state called Stopped, and Microsoft's billing table marks that state as Billed. The machine still holds its place on the host. Only Stopped (deallocated) ends the compute charge.
And it is worse than a single trap, because the command line repeats it. "az vm stop" leaves the machine allocated and billing. "az vm deallocate" is the one that stops the charge. Two commands, nearly the same name, one of them costs money.
On Google Cloud, stopping an instance does end the vCPU and memory charge, and does nothing about the disks. Those keep billing at full price the whole time the machine is off.
So "we turned everything off" means three different things depending on where you said it, and in all three the bill is higher than the person saying it believes.
An idle address is not free, and on one cloud it costs more
Azure is direct about this: "you're charged for a static public IP address irrespective of the associated resource." It does not need to be attached to anything. It needs to exist.
Google Cloud goes further, and this is the one that makes people re-read it. Their documentation: "If you reserve a static external IP address and do not assign it to a resource such as a VM instance or a forwarding rule, you are charged at a higher rate than for static and ephemeral external IP addresses that are in use."
A higher rate. The address doing nothing costs more per hour than the same address doing its job. It is deliberate and the reasoning is sound, because IPv4 addresses are scarce and hoarding one should cost more than using one. It is also the exact opposite of what anybody assumes.
Admin does not mean admin
This is the one that matters for security rather than money.
On Azure, any role with the listkeys permission can pull a storage account's access keys, and Microsoft spells out the result: "By using this permission, a user can use the account access keys to access all data in a storage account." Contributor has it. Contributor is what most people hand out when somebody needs to deploy things.
On Google Cloud the equivalent surprise is the Compute Engine default service account. Google says it "might automatically be granted the Editor role on your project" and is "attached by default to all VMs that you created by using the Google Cloud CLI or the Google Cloud console". Every machine you made in the console may be running as something that can edit the whole project.
Both of those are quiet paths to everything, they are shaped completely differently, and neither shows up on a screen labelled permissions.
What does transfer
Enough that you should not feel like a beginner twice.
Least privilege transfers. Tagging things with who owns them transfers. Checking what is reachable from the internet transfers. Snapshot before you delete transfers. Knowing that the invoice is a lagging report on a decision made three weeks ago transfers completely.
The judgement is yours and it is portable. What does not transfer is the mechanism, and mechanisms are lookup-able. That is worth saying plainly, because the multi-cloud conversation is usually pitched as something only specialists can survive, and that is mostly marketing.
What actually helps day to day
One inventory. Not a dashboard per cloud, a single list of what you own. The moment the answer to "what have we got" requires two logins, nobody asks the question, and the things nobody asks about are the ones that surprise you.
One set of questions, asked the same way. What is running. What is it costing. What is open to the internet. Who changed something this week. If those four have to be phrased differently per cloud, you will run them on whichever cloud you are already logged into, which is how the other one drifts.
And one safety rule that does not depend on you configuring it correctly twice. Permissions are per cloud and shaped differently in each. Anything protecting you that has to be set up separately in both places is a rule you will get right once.
The shorter way
This is the thing we built Liberra to be, and it is the part where both clouds are live today rather than coming.
Connect an AWS account and an Azure subscription and it indexes both into one place. Then the questions stop being per cloud. What is running, everywhere. What am I spending in total, and where did it move. What is exposed, in either one. It runs a real Prowler scan on both, the actual open source tool rather than our impression of it.
The point is not that a model knows AWS and Azure. Any good model does. The point is that it knows YOUR accounts, because the index is already built when you ask, instead of spending fifteen minutes collecting your resources while you sit there paying for the wait.
And the safety rule is one rule, not two. Liberra cannot delete anything on either cloud, because the delete commands are blocked in the code rather than in permissions you would have to get right in two different systems. Every change that writes stops, says what it is about to do in plain English, and waits for you to approve it.
One person holding two clouds is twice the surface for a bad afternoon. A rule that cannot be misconfigured in either place is worth more than a rule that is stricter in one.
Founder, Liberra AI