Hybrid Cloud CMDB in Amsterdam Fails Without a Rule for Which Data Wins

On 19 October 2025, a DNS record for one database endpoint went empty in a single AWS region. According to AWS’s own account, the event ran for more than 14 hours. Customers saw three distinct periods of impact: DynamoDB errors, then failed EC2 launches, then load balancer connection errors.

According to the same summary, EC2 instances that were already running stayed healthy. New launches failed, so a tier that adds capacity by launching instances could not scale until the launch path recovered. That gap between running capacity and launchable capacity is the kind of detail a change review should know before a booking peak. The underlying question is plain: which of your services depend on the component that failed, and does your record of that dependency match what is deployed?

Amsterdam teams ask that question in stacks that are often hybrid. Since 15 August 2026, teams in scope also face that question under the Cyberbeveiligingswet (Cbw), the Dutch law that implements the EU’s NIS2 Directive.

A configuration management database (CMDB) records what a team runs and what depends on what. A hybrid cloud CMDB in Amsterdam only helps when its records can be trusted, and that trust turns on one design decision: what happens when two discovery sources disagree.

This article covers why Amsterdam stacks split, where hybrid records go wrong, and what the Cbw asks of asset records. It then shows how rule-based reconciliation keeps the map usable for cloud-native tech and travel platforms.

Why Amsterdam Stacks Split Across Colo, Cloud, and SaaS

Colocation (“colo”) means renting space and power in a third-party data center for hardware you own and operate. New data center capacity around Amsterdam is constrained by grid power and by national and municipal rules. Hyperscale projects of 70 MW or more, or larger than 10 hectares, are banned across most of the Netherlands. The Amsterdam and Haarlemmermeer municipalities added their own restrictions in December 2023 to control data center energy use.

Delivery figures show the effect. JLL’s mid-year 2026 report puts Amsterdam’s first-half additions at 16.3 MW, against 45 MW in Frankfurt and 49 MW in London.

Amsterdam still draws teams for its connectivity, and the AMS-IX ended 2025 with 902 connected parties. Teams that want to stay near that exchange while capacity grows elsewhere often settle on one shape. Latency-sensitive components sit in colocation, elastic workloads run in a hyperscale region, and payment, fraud, and partner services sit behind SaaS and vendor APIs.

Amsterdam follows a wider pattern here. Gartner’s November 2024 forecast expects 90% of organizations to adopt a hybrid cloud approach through 2027.

That shape creates a record-keeping problem, because each layer answers to a different source of truth. Colocation hosts respond to network scans, cloud accounts respond to provider APIs, and SaaS platforms respond to vendor consoles. No single source describes the whole service.

What a Hybrid Cloud CMDB in Amsterdam Records, and What It Should Skip

A CMDB stores configuration items (CIs) and the relationships between them. In a hybrid estate, the practical question is which items deserve a record.

Long-lived assets such as a colocation server, a load balancer, or a managed database earn a record without debate. Short-lived resources age out before the next scheduled scan finishes. An instance that an autoscaling group launches at 14:00 and terminates at 16:00 is stale before the next scan. The stable record is the group’s configuration, including its owner and its dependencies. Virima’s earlier piece on cloud CMDB design covers the ephemeral-resource decision in detail, and this article builds on it.

Kubernetes follows the same recording logic for longer-lived objects. Pods and namespaces are the longer-lived components suited to CMDB records under Virima IT Discovery. A team that needs a record of every container invocation belongs in a log or observability tool for that level of detail.

Four Places Hybrid CMDB Records Go Wrong

Flexera’s 2026 State of ITAM report found that only 36% of respondents reported complete IT asset visibility, down from the previous year. In hybrid estates, the gaps tend to cluster in four places. Each discovery method sees part of the estate and leaves a predictable gap of its own.

1. Two sources describe the same CI differently

A virtual machine in a cloud account can also respond to a host scan. Both may report its hostname and operating system version, and the two values can diverge. When a tool keeps whichever value arrived last, the record changes with scan order, and nobody can say which value is right.

Result: The CI record changes with scan timing, so two engineers reading it on different days can reach different conclusions.

2. Autoscaled tiers are recorded as instances

A snapshot of an autoscaling tier captures whichever instances happened to be running when the scan ran. Scale-out during a seasonal peak adds instances after the scan, and scale-in removes them before the next one. AWS’s October 2025 summary also reports container launch failures and cluster scaling delays across ECS, EKS, and Fargate. The running set of a containerized tier can diverge quickly from a stored record.

Result: The CMDB lists instances that no longer exist and omits the ones that carried the peak.

3. Accounts and regions sit outside the scan

AWS resources are regional, and a multi-account estate needs read access in every account and every region. Virima’s AWS and Azure discovery guide describes the multi-account pattern in more depth. A central discovery account assumes a read-only role in each target account through AWS Security Token Service, so long-term keys stay out of day-to-day distribution. A product team that opens a new account for a launch, without adding it to that pattern, creates a gap.

Result: Production workloads in an unregistered account never appear in impact analysis.

4. SaaS and payment dependencies fall outside infrastructure discovery

A booking flow usually depends on a payment provider, a fraud check, and partner inventory APIs. API-based discovery reaches cloud and SaaS platforms that have an integration, so those accounts can enter the record. Browser-side scripts, such as a payment widget or tracking tag loaded into the customer’s browser, sit outside that scan path. Those scripts run outside the network-connected infrastructure and cloud accounts discovery reaches, so those dependencies need a separate control. Their relationships can be added by hand to the service map with a named owner.

Result: The service map shows a clean infrastructure path and leaves out the vendor whose outage stops bookings.

You can test your own records against these four gaps without new tooling. Pick one booking-critical service, trace its dependencies by hand, and compare the result with the CMDB. Pick one CI and ask which source populated each attribute and when it was last verified. List every cloud account and subscription, then check which ones your discovery covers.

What the Cyberbeveiligingswet Asks of Your Asset Records

The Cbw is the Dutch law that implements NIS2, and it sets cybersecurity duties for organizations in scope. For those teams, the record gaps above also make regulatory duties harder to meet. The Cbw entered into force on 15 August 2026, according to the NCSC, and applies to about 8,000 organizations. It sets three duties: register, take risk-based security measures, and report significant incidents. The NCSC also describes cybersecurity as a board matter, with management approving the measures and overseeing their execution.

Whether the law applies depends on sector and size. The NCSC’s scope guidance lists sectors that include energy, digital infrastructure, research, and government. An organization in a listed sector must also be large enough: 50 or more employees, or fewer than 50 with annual turnover and balance sheet both above €10 million. Partner and linked companies count toward those figures. The NCSC adds that larger companies in other sectors and some suppliers can also fall under the law, which matters for platforms that sell to regulated customers. Tech and travel firms need a confirmed scope answer. The RDI’s self-assessment tool gives a first answer, and legal counsel should confirm it.

Incident reporting is phased, and once an organization becomes aware of a significant incident, the NCSC’s reporting guidance calls for an early warning within 24 hours. A notification with an initial assessment of severity and impact follows within 72 hours, and a final report is due within one month of that notification. The risk analysis and the 72-hour assessment start from the same question: which systems exist, and what depends on them? A CMDB with source-tagged records and mapped dependencies gives a team a working inventory for both. Virima’s NIS2 checklist covers the asset-overview requirement in more detail.

The CMDB has clear boundaries here. It maps the infrastructure that supports risk analysis and incident scoping, and it records which systems connect to which. Classification of personal or commercial data that moves across those connections sits with a separate data loss prevention (DLP) or data classification tool. Duty of care still needs policies, controls, and management sign-off beyond the inventory layer the CMDB supplies.

When cloud accounts and ITSM desks need connectors, use the integrations hub as the single catalog page.

Building the Map: Discovery, Reconciliation, and Service Maps

Three mechanisms keep a hybrid record usable, and each ties to a specific Virima capability.

1. Combine three collection methods on a schedule

Virima IT Discovery uses agent-based, agentless, and API-based collection together. Over 140 extendable probes cover on-premises servers, network devices, storage, and hypervisors. API connectors pull data from AWS and Azure, and from VMware vCenter and Hyper-V. Agents cover endpoints that leave the network. In a hybrid estate, network scans and cloud API calls both feed one CMDB, where the results are merged.

Discovery runs as high-frequency scheduled scans, so a resource that starts and stops between two scans is recorded through the autoscaling group’s configuration rather than as its own CI. For that reason, the autoscaling group’s configuration is the record that counts. Virima’s own guidance is to scan on a recurring cadence and vary the timing, so devices that appear only at certain hours are still caught.

2. Give every attribute one authoritative source

When two sources describe the same CI, Virima applies authority rules instead of keeping the latest scan. Each attribute has a designated authoritative source. Every attribute carries a source tag and a last-verified timestamp, and every resolution is logged with the source, protocol, timestamp, and rule applied. A reviewer who doubts a value can see which source supplied it, through which protocol, and when it was last verified. That traceability matters when an auditor, a change board, or an incident commander asks why the record says what it says.

A team might designate the cloud API as authoritative for instance size and tags, and the host scan for patch level and installed software. The principle matches AWS’s own modernization guidance, which describes cloud-native configuration services as authoritative sources that feed the CMDB.

3. Turn records into dependency views

Discovered CIs and their relationships feed ViVID™ service maps, which show which business services depend on a CI and who owns each. Service definitions still come from the team, by hand, spreadsheet import, or architecture tooling. Once those definitions are in place, the platform builds the dependency map from discovered infrastructure. Teams can enhance the generated relationships by hand. Records sync into the Virima CMDB and out to ITSM tools including ServiceNow and Jira Service Management, so incident and change teams read the same records. Partner connectors for those desks are listed once on the integrations hub.

Owners still validate what automated discovery records mean. AWS’s modernization guidance notes that CMDB efforts often fail when nobody updates, verifies, or retires records. It adds that automated discovery feeds still need validation by the people who own the services. Discovery reduces the manual work of finding assets, and owners still confirm what the records mean.

For how discovery-sourced records support change and agent-ready operations, start with Trusted Runtime Truth.

Two Change Windows, Walked Through

Both scenarios below are illustrative walkthroughs for planning purposes.

• A cache upgrade before a booking peak. A platform team plans to upgrade a shared cache tier ahead of the holiday season. The change ticket lists two services. The service map, built from discovery data, shows a third: an itinerary-sharing service owned by another team. The reviewer widens the notification list and moves the window. Dependency views of this kind support change approval when the blast radius of a shared tier is wider than the ticket list.
• A payment service moves between cloud regions. A payments team relocates a service to a different cloud region. If something fails and the organization falls under the Cbw, the team must assess impact inside the 72-hour notification window. A record that shows which attributes changed between scans, and who owns each affected CI, shortens that scoping work.

A Five-Step Starting Plan

AWS’s guidance suggests starting with a small set of critical applications and expanding in waves, and the plan below follows that logic.

1. Draw the hybrid boundary: list the colocation sites, cloud accounts and subscriptions, Kubernetes clusters, and SaaS platforms in scope, and name an owner for each.

2. Assign one authoritative source per attribute: decide which source wins for hostname, operating system version, instance size, tags, and patch level before the first scan runs.

3. Map one revenue-critical service end to end: start with the booking or checkout path, verify each dependency with its owner, and widen scope only after that map holds up.

4. Set the scan schedule and work the exceptions: vary scan times, then diagnose gaps such as missing credentials, unreachable subnets, or accounts without a configured integration.

5. Connect your ITSM tool and name a retirement owner: sync records to the ticketing tool through the integrations hub. When a platform lead decommissions a service after confirming nothing depends on it, this owner retires the CI.

Close the hybrid map before the next peak tests it

Hybrid estates around Amsterdam are already split across colo, cloud, and SaaS. The Cbw raises the cost of an incomplete asset view for teams in scope. Authority rules, scheduled multi-method discovery, and owned service maps give change and incident teams one place to trust when sources disagree.

To see what discovery returns for a hybrid estate like yours, schedule a demo.

Frequently Asked Questions