CMDB for Hybrid Cloud Visibility in Stockholm: What Discovery-Sourced Records Cover

A CMDB for hybrid cloud visibility in Stockholm gets tested the moment a provider fails. On 12 June 2025, a policy change containing blank fields reached Google Cloud’s regional Service Control datastores at about 10:45 PDT. The data replicated globally within seconds, and the Service Control binaries went into crash loops. Google’s incident report lists Stockholm (europe-north2) among the affected locations, with the incident running from 10:51 to 18:18 PDT.

Google also reports that its first incident post appeared about an hour after the crashes began, because Cloud Service Health infrastructure was down as well. Some customers lost their own monitoring, since it ran on Google Cloud too. Google’s Stockholm region announcement names Spotify as one of its earliest customers.

Teams in that position ask which of their services call the failing product. A CMDB answers that question from recorded relationships.

Where visibility slips first in a cloud-native estate

Flexera’s 2026 State of the Cloud report surveyed more than 750 cloud decision-makers and users. It found that 73% of organizations operate hybrid environments. Multi-cloud adoption keeps rising, often driven by mergers, SaaS sprawl, and decentralized teams. Each of those routes adds accounts and subscriptions that no single team designed.

Flexera’s 2026 State of ITAM report, a separate survey of 512 technology professionals, found that complete IT asset visibility fell to 36%. It attributes the decline to growing complexity across AI, SaaS, and cloud environments. That’s the paradox worth naming directly: FinOps, IaC, and observability tooling have all matured over this same period, yet visibility still fell because none of those tools were built to record ownership and cross-environment relationships, which is where the gap actually lives. The two surveys use different samples, so each figure stands on its own. Virima’s own cloud CMDB guidance ties that visibility gap to a specific cause: a hybrid cloud CMDB built for stable, on-premises IP addressing doesn’t model resources that appear and disappear in minutes.

Stockholm’s cloud footprint

AWS opened its Europe (Stockholm) region in December 2018, with the API name eu-north-1. Google Cloud added Stockholm (europe-north2) in March 2025 as its 42nd region. A Stockholm engineering team can therefore run workloads in two hyperscaler regions inside Sweden while keeping on-premises systems in service.

Flexera’s State of the Cloud release adds the provider mix. AWS (83%) was slightly ahead of Azure (79%) for active enterprise workloads, and Google Cloud Platform remained a distant third. A record that covers AWS, Azure, and on-premises assets covers the largest share of that mix.

What cloud consoles, IaC and observability each leave out

Cloud consoles, infrastructure as code and observability tools each answer a real question. Platform engineers who rely on them are right to ask what a CMDB adds. The table below sets out what each source records and where its view ends.

AWS documents the IaC boundary directly. Users can edit resources outside CloudFormation, and CloudFormation drift detection covers only resources that support it. Unsupported resources receive a status of NOT_CHECKED. A stack-level check also skips nested stacks, which need their own drift detection run.

A CMDB sits alongside these sources and links their output to ownership and relationships. The console, the template and the telemetry stay in service as the detailed record for their own layer.

Four places a hybrid record goes stale

Four patterns recur in estates that span cloud and on-premises systems.

1. The record models instances, so it decays by the hour. Virima’s cloud CMDB guidance treats the Auto Scaling group configuration, the Lambda function definition, or the container spec as the stable CI. Recording every spawned instance creates thousands of orphaned, instantly stale records.
2. Ownership lives in someone’s head. When a resource has no recorded owner, nobody can approve its removal, so it keeps running and keeps costing money.
3. On-premises and cloud systems are mapped separately. A dependency path that crosses the boundary between a data center and a cloud account breaks at that boundary.
4. Managed and SaaS services are missing as dependencies. During an incident, time goes to asking vendors which of their components a service uses.

Each pattern has a record-keeping fix. Model the template, make ownership a required field, map both environments in one place, and record external services as dependencies.

See how ViVID™ service maps connect ownership and cross-boundary dependencies in one view, so none of these four patterns stay invisible until an incident surfaces them.

CMDB for hybrid cloud visibility: where discovery reaches, and where it stops

CMDB for hybrid cloud visibility in Stockholm depends on what discovery can reach in each layer. Virima’s published coverage is listed below.

Virima lists integrations for Kubernetes, OpenShift, AWS EKS, Azure AKS and Docker, which connect container workloads and clusters to the assets and services recorded in the CMDB. Those workloads are tracked as configuration items in their own right. The ITSM sync works alongside the ITSM platform a team already runs, rather than requiring a migration to a new one. See the full integrations list.

Virima’s cloud asset discovery connectors cover AWS and Azure directly. Google Cloud workloads in a Stockholm estate need a separate plan, such as records loaded through the REST API.

Discovery runs as high-frequency scheduled cycles. Each cycle updates the records for resources that exist when it runs. Resources that live for seconds fall between cycles, which is why the record models the template and leaves individual instances to discovery logs.

Virima’s AWS and Azure discovery guide walks through connector setup for both providers. Virima’s Discovery App can also run inside the cloud environment for application discovery and dependency mapping.

What a CMDB records and what stays with other tools

A CMDB records inventory, ownership, and relationships as discovery finds them. FinOps tools allocate and forecast spend. IaC tools define and deploy infrastructure. Policy engines enforce rules.

What a better record contributes to cloud cost control

Flexera’s State of the Cloud report estimates that wasted cloud spend reached 29%, the first increase in five years. Flexera ties the rise to cloud-based AI workloads. The figure is an industry estimate drawn from survey respondents, separate from any Virima customer result.

Cost work starts with an inventory that lists what runs, who owns it, and which service it supports. A discovery-sourced record supplies that list. Spend allocation then happens in the FinOps tooling, using the same resource identifiers.

When a resource has no owner, one named person decides whether it is removed. That person needs the dependency view first, because deleting an unowned database that a service still calls can create an outage. The record turns removal from a guess into a checked decision.

A CIO who wants a conservative measure can track one internal metric: the time needed to identify affected services after an alert, measured before and after the record is maintained. The numbers come from the team’s own incidents. Virima’s own article on closing the cloud spend gap covers the FinOps side in more detail.

Three documented incidents and the question each posed

In each incident below, the first practical question was the same. Which of our services depend on the component that failed? A maintained dependency record holds that answer. Each description uses only what the provider or news source states.

AWS, 19 to 20 October 2025. AWS’s post-event summary describes a service disruption in the N. Virginia (us-east-1) Region. It started at 11:48 PM PDT on 19 October and ended at 2:20 PM PDT on 20 October. It lists three distinct periods of impact. DynamoDB saw increased API error rates, the Network Load Balancer saw increased connection errors, and new EC2 instance launches failed. AWS traces the DynamoDB period to a latent race condition in its DNS management system. The record question: which of our services reach DynamoDB in that region, directly or through other AWS services?

Azure Front Door, 29 October 2025. Microsoft’s engineering recap states that a sequence of configuration changes across two control-plane versions produced incompatible metadata. The metadata propagated globally and affected connectivity and DNS resolution for all applications onboarded to the platform. The record question: which of our services route through Front Door?

Tietoevry, January 2024. Help Net Security reported that a ransomware attack on the night of 19 to 20 January hit one part of a Tietoevry data center in Sweden and disrupted services for several customers. Data Center Knowledge’s report states that the Riksbank filed a police report after its human resources and payroll systems became inaccessible. The practical question didn’t change: which of our services run at that provider?

Five steps to start with one service

1. Trace one product-critical service by hand across cloud accounts and on-premises systems.
2. Run discovery on AWS, Azure, and on-premises, then compare the result with IaC state and the console.
3. Set the CI model by choosing a template or instance for each resource type, with ownership as a required field.
4. Connect the CMDB to your ITSM platform so incidents and changes carry CI context.
5. Set a review cadence, and measure the time needed to identify affected services before and after.

ViVID™ service maps turn the relationships from step 1 into CMDB dependency mapping you can see, not just records you have to query. Service definitions come from your team, by manual entry, spreadsheet import, or an integration, and Virima builds the map from that input.

See what your cloud accounts contain today

Start with one service and one cycle of discovery. Explore Trusted Runtime Truth to see how Virima records what exists, how it connects, what changed, and who owns it.

Frequently Asked Questions