A seemingly simple question posed on a team communication platform—"What are we actually running across both cloud environments?"—unraveled a complex reality for a major engineering organization. The inquiry wasn’t about documented infrastructure-as-code (IaC) configurations or reported billing expenditures. It was a demand for a real-time, comprehensive inventory of all active resources across every account, every cloud provider, and both merged entities. The subsequent hour-long discussion, involving three distinct teams and a reluctant acknowledgment of "some Azure stuff from that pilot," highlighted a critical operational gap: a cohesive, accurate map of the organization’s cloud infrastructure did not exist. The final response was not a definitive inventory but a candid admission of confidence levels, punctuated by noted areas requiring further investigation. This experience underscored a paradox: an organization populated by "serious engineers who take infrastructure seriously" lacked a unified view of its own technological landscape.
The Accidental Multi-Cloud Journey
The concept of a "multi-cloud strategy" is frequently discussed in industry circles, often framed as a deliberate architectural decision aimed at mitigating vendor lock-in, enhancing resilience, and optimizing workload placement across different cloud providers. However, the reality for many enterprises, as revealed by the organization’s predicament, is far less planned. Flexera’s 2024 State of the Cloud Report indicates that 89% of enterprises are now operating workloads across multiple public clouds, a figure that has steadily increased year-over-year. While this statistic is often cited to demonstrate widespread adoption, it frequently masks the organic, uncoordinated manner in which most organizations arrive at this multi-cloud state.
The prevalent pathway to multi-cloud adoption is through accumulation. This process is characterized by a series of individual, contextually sound decisions made by various teams over time. These decisions might include the adoption of a specific cloud service for a particular project, the onboarding of a new application with its own preferred infrastructure, or the integration of a service from a third-party vendor that utilizes a different cloud. Over an extended period, and across numerous teams, these incremental choices coalesce into a complex, sprawling cloud footprint. The organization in question found itself managing resources across four providers, not as the result of a strategic architectural review or a unified planning session, but as an emergent property of countless decentralized operational decisions. Each individual choice was logical in its immediate context, but collectively, they created a distributed infrastructure without a singular point of oversight.
The challenge of managing such an environment is compounded by the limitations of existing tools. While many cross-provider Infrastructure as Code (IaC) platforms, including solutions like env0, offer a centralized management plane for deployments across AWS, Google Cloud Platform (GCP), and Microsoft Azure, their efficacy is typically confined to resources provisioned through their pipelines. This leaves a significant "blind spot" for resources that predate the IaC implementation, were inherited through mergers or acquisitions, or were provisioned outside of established automated workflows. The recent merger of env0 and CloudQuery, aimed at bridging this operational gap, underscores the persistent need for comprehensive visibility. However, the problem must first be clearly articulated and understood. Solid IaC management provides visibility into what passes through automated pipelines; it does not inherently reveal what exists beyond them.
The Futile Quest for a Unified Spreadsheet
The traditional approach to understanding a multi-cloud environment involves navigating the distinct consoles of each provider, a process that is inherently fragmented and time-consuming. For instance, an engineer seeking to inventory resources would first meticulously traverse the AWS console, account by account, region by region. This would be followed by a similar, but entirely different, experience within the GCP console, and then again with Azure. Each platform possesses its own unique interface, navigation paradigms, and mental models, with no inherent capability for cross-provider query or aggregation. The concept of a universal "show me everything" button remains elusive.
Further complicating this inventory effort is the ubiquitous challenge of cloud resource tagging. In the case of the organization discussed, the merger of two entities introduced a significant hurdle: disparate tagging conventions. Each organization had its own approach to mandatory tags, preferred values, and enforcement mechanisms. Resources originating from the CloudQuery side might adhere to one tagging schema for owner identification, while those from the env0 side followed a different standard. Some resources predated any tagging policy altogether, while others were provisioned by automation systems that deviated from either established convention. Attempting to answer a seemingly simple question like "who owns this resource?" across the entire combined footprint would necessitate a prior agreement on the definition of "owner" and a complex cross-referencing of multiple systems to determine which tagging convention applied to each individual resource.
Driven by the need for clarity, the author attempted to compile a unified inventory in a spreadsheet. This endeavor, involving the manual extraction of data from cloud consoles, billing reports, and direct inquiries to team leads, proved largely unproductive. After dedicating a full day to populating the spreadsheet for just the first cloud provider, the author’s confidence in the accuracy of the collected data was significantly diminished, leading to the abandonment of the effort for the remaining providers. Billing reports, while useful for cost management, provide a record of expenditures rather than a precise inventory of running resources. Similarly, relying on team leads for information yields a snapshot of what teams actively manage or consider, not a complete enumeration of all existing infrastructure.
Reflecting on this experience, a key lesson emerged: the critical importance of establishing a unified tagging schema before any significant organizational changes, such as a merger, are finalized. Even a minimal schema, encompassing elements like owner, environment, and cost center, and enforced from day one, could prevent years of ambiguity and unanswerable questions regarding resource ownership and accountability. Retroactively imposing consistency on two years’ worth of pre-existing resources is an impractical undertaking; however, proactive implementation of a standardized tagging strategy can safeguard future operational clarity.
The Power of a Unified Query
The breakthrough in achieving a comprehensive inventory came with the integration of CloudQuery. This platform ingests real-time cloud state data from a multitude of providers, including AWS, GCP, Azure, Kubernetes, and Cloudflare, transforming it into queryable SQL tables. Each cloud provider’s resources are synced into dedicated tables (e.g., aws_ec2_instances, gcp_compute_instances, azure_compute_virtual_machines). This structure enables straightforward cross-provider aggregation.
A basic query to ascertain the count of compute instances across different providers would look like this:
SELECT 'aws' AS provider, 'ec2_instance' AS resource_type, COUNT(*) AS count
FROM aws_ec2_instances
UNION ALL
SELECT 'gcp', 'compute_instance', COUNT(*) FROM gcp_compute_instances
UNION ALL
SELECT 'azure', 'virtual_machine', COUNT(*) FROM azure_compute_virtual_machines
ORDER BY count DESC;This query, when extended to encompass all relevant resource types, provides a foundational view of the infrastructure. For more advanced analysis, CloudQuery offers pre-built multi-cloud inventory reports that automate this aggregation process. The author found that leveraging such a report transformed a potential week-long audit into a matter of minutes. The ability to filter by tags, join with cost data, and cross-reference declared IaC configurations with actual deployed resources provided an unprecedented level of insight. The initial Slack thread, which required extensive collaboration and elicited uncertainty, was effectively resolved by a single, well-defined query.
Beyond Inventory: Proactive Anomaly Detection
While unifying the inventory represented a significant achievement, it quickly revealed the next layer of complexity: knowing what to look for within that vast, consolidated data. For environments spanning two cloud providers, a manageable set of recurring checks can be developed. This might include queries to identify untagged resources, resources with publicly exposed sensitive data, or compute instances that should have been decommissioned. Running these checks on a scheduled basis can maintain a reasonable level of operational hygiene.
However, the organization’s post-merger footprint, involving two major providers each with distinct naming conventions, policy regimes, and a substantial volume of legacy resources, presented a far greater challenge. Attempting to cover all potential issues with manually crafted queries would necessitate anticipating every conceivable problem category in advance – an often impossible task.
The sudden transition from a single cloud environment to a dual-provider reality highlighted the need for a system that proactively surfaces anomalies, rather than merely responding to pre-defined questions. The goal evolved from simply having a current inventory to receiving alerts about what looks suspicious, eliminating the need for constant, manual inquiry.
The Foundational Role of Visibility
The pervasive multi-cloud reality was not a deliberate strategic choice but an emergent condition, the byproduct of years of individually justifiable operational decisions. Organizations that successfully navigate this complexity are not necessarily those with the most meticulously planned cloud architectures. Instead, they are the ones that have prioritized inventory and visibility as fundamental components of their infrastructure. They have built a unified picture of their cloud assets before mergers, incidents, or audits impose the necessity.
As the author concluded, the primary focus for any organization embarking on or already navigating multi-cloud operations should be the establishment of a robust inventory system. This is not to suggest that such a system eliminates multi-cloud complexity, but rather that it provides the essential prerequisite for effective governance. Security audits, cost attribution, incident response, and compliance preparations all depend on a clear understanding of what is actively running. The inventory is the bedrock upon which all these critical functions are built, and it is a foundation that becomes exponentially more difficult to construct retroactively. For organizations seeking to implement such a system, CloudQuery offers a straightforward setup process, allowing for the extension of single-provider methodologies to a multi-cloud context by configuring multiple data source plugins.