Nobody has seen the whole estate: what a multi-cloud map shows that four consoles cannot

Ask an engineering team where their infrastructure runs and you will get a confident answer: "Frankfurt and Ireland, mostly". Ask the console and you will get a different one. There is almost always something in us-east-1, because that is the default and somebody once clicked through a wizard. There is often a region in a continent nobody on the team can explain, left over from a proof of concept, a contractor, or a service that quietly provisions a global resource.

This is not incompetence. It is a structural property of cloud consoles: they are organised per provider, per account, per region, and they show you exactly the slice you navigated to. There is no view in any of the four major clouds that shows you everything you run in all of them. So nobody has ever seen it.

Drawing that one view is the thing Skyline was originally built to do, because we needed it for our own assessments and there was no honest way to produce it in an afternoon.

One data model, four providers

The design decision that makes the rest possible is that everything lands in the same shape. A live AWS scan, a Google Cloud organisation scan, an Azure subscription, an Oracle Cloud tenancy and a folder of .tf files all produce the same thing: a flat list of resources with Terraform-style type names, grouped by region.

That is why the security rules are written once and work on all of them, why the cost engine is a provider-agnostic core with a price catalog per cloud plugged into it, and why the map does not care where a resource came from. A finding in the security report points at the same resource you see on the map and in the cost table, because there is only one of it.

The scopes match how each provider actually organises things, rather than forcing a shape on them:

• AWS — one account, all regions.
• Google Cloud — a project, a folder or the entire organisation.
• Azure — a subscription or a management group.
• Oracle Cloud — the whole tenancy.

What the map consistently surprises people with

After doing this on a few dozen estates, the surprises repeat. Four of them are almost universal.

Regions nobody chose

The us-east-1 residue is the classic. Also common: a region enabled for a load test two years ago that still holds a NAT gateway and three volumes, and global services whose resources are attributed to a home region the team has never thought about. None of this is expensive on its own. All of it is compliance surface — data in a jurisdiction nobody approved — and that is a much shorter conversation when it is a dot on a map than when it is a spreadsheet.

Resources Terraform does not know about

This is the one that changes behaviour. Load the Terraform and load the live account, and the difference between them is the set of resources somebody created by hand — or, more often, the debris left when somebody destroyed a stack by hand and Terraform never knew the pieces existed.

Orphaned EBS volumes, unattached addresses, load balancers with no healthy targets, a database from a migration weekend. Individually cheap, collectively significant, and invisible in both a terraform plan (they are not in state) and a console (they look like everything else).

A cost distribution nobody predicted

Ask the team to name their three most expensive services before opening the cost view. It is worth doing as an exercise, because the miss is informative. Compute is usually correctly guessed. What people miss is data transfer, which is nobody's line item and everybody's bill, and the fixed monthly costs of networking components — a NAT gateway per availability zone across four environments is a serious number that appears on no architecture diagram.

Skyline estimates monthly cost per region and per service from public price lists, and puts real spend from your billing export next to it where that is available. The estimate is for prioritising; the gap between the estimate and the real spend is itself informative, because it usually points at usage-based lines nobody is watching.

The dependency graph nobody had drawn

Click a region and you get its resources grouped by service, plus the graph of what points at what — derived from Terraform references and depends_on in the code path, and from the real relationships in a live scan. Most teams have an architecture diagram. Very few have one that matches what is deployed, and the difference between the two is usually where the incidents live.

Why we give it away

The commercial logic is straightforward enough to state plainly. We do cloud, AI and security consulting, and every engagement starts with the same ten-day read-only assessment. Skyline is the tool we run in that assessment. Publishing it costs us the hosting and gains us clients who arrive already knowing what their estate looks like, which makes the first conversation much better.

It is also, frankly, the fastest way to show what we mean rather than assert it. An estate map with eleven findings and a cost breakdown is a more honest sample of our work than a case study.

So the account is free, the scans are free and the reports are free. Credentials are used in memory for the scan you ask for and discarded when it finishes, and Skyline refuses credentials that can write. If you would rather not connect anything at all, the Terraform path gives you the same four views from code alone.

What to do with it this week

Point it at one account you think you understand well. Then look at three things in order: the regions on the map you did not expect, the top three cost lines by service, and the highest-severity finding. If all three match your mental model, you are in better shape than most teams and it cost you ten minutes.

Try Skyline. If the map raises questions that need a person rather than a tool, that is what our cloud work is.