Architecture is destiny

The illusion of perfect symmetry

Cloud architectures are initially built to be clean and predictable. Services are stateless, components are modular, and everything is designed to scale and replicate effortlessly. The prevailing assumption is that if each part behaves the same, the system will be easier to manage. However, this symmetry rarely lasts. Over time, as systems interact and evolve, unexpected patterns emerge, leading to emergent complexities. 

Consider a typical microservices architecture: You start with 10 services, each with clear boundaries and predictable costs. Six months later, you have 50 services, cross-region data transfers, three different database types, and costs that spike unpredictably. A single API call that once cost pennies now triggers a cascade of operations across multiple services, each adding its own overhead. The architecture that was designed for clarity has evolved into a complex web where cost attribution becomes nearly impossible.These unpredictable outcomes are not accidents, they’re the natural consequence of early architectural decisions.

Environments become entangled, and intricate dependencies emerge. For instance, an unused database instance might continue to incur costs due to overlooked snapshots, or an auto-scaling group might unnecessarily expand due to a misconfigured CloudWatch threshold, spinning up instances that serve no actual traffic. That’s why managing costs effectively means understanding the system’s structure, not just its parts.

This inherent unpredictability presents a significant architectural challenge in cloud environments. While cost is ideally supposed to follow consumption, it frequently follows misalignment. Organizations pay for what they provision, but also for what connects, lingers, and scales unexpectedly.

Consider data egress charges that escalate unexpectedly due to cross-region service calls, or the hidden costs of orphaned storage volumes left behind after a service is decommissioned.

Cost should align with consumption, yet often diverge. Organizations pay for what they provision, but also for what connects, lingers, and scales unexpectedly

Lambda functions that trigger unnecessarily, forgotten load balancers serving deprecated services, or S3 lifecycle policies that keep moving data to expensive storage tiers, these seemingly small, connected elements accumulate into significant, unpredictable expenses. This highlights a crucial principle: effective cost management demands more than just scrutinizing individual components; it requires a profound understanding of the true, evolving structure of your systems, observing them as they truly are, rather than clinging to the initial design aspirations.

Why traditional tools fall short

Many existing cost management solutions struggle with modern cloud complexity. While some of the tools have made significant strides, they often face limitations when dealing with highly distributed architectures. The primary challenge is capturing the full context of resource relationships, especially when services cascade across multiple teams and geographical regions.

Furthermore, these tools often fall short on granularity, focusing on easily quantifiable metrics like gigabytes, hours, requests, and tokens. While these technical metrics are useful, businesses require a different kind of answer. They need to understand cost per customer, per feature, or per use case to make informed strategic decisions. For instance, in a hypothetical scenario, knowing that your compute costs are substantial is less useful than understanding which customer segments or features drive those costs and whether they generate corresponding value.

These challenges are growing fast. Automation and AI are multiplying the number of resources, workloads, and interactions that must be tracked. With the rapid adoption of AI tools, infrastructure, workloads, and even code (both efficient and inefficient) are growing exponentially, amplifying the complexity of cost attribution and management. These are not mere operational glitches; they are direct consequences of the architecture itself. Cloud systems are built to be symmetrical, but they often miss the points where that symmetry breaks. And that’s exactly where real costs hide.

A different approach

These challenges led us to rethink how cost management tools should work. At Pelanor, we built our platform around understanding relationships first, costs second.

Our core innovation, Delphi, is a graph-based database that models cloud infrastructure as interconnected nodes rather than isolated resources. Unlike traditional time-series databases that store metrics independently, Delphi maintains live relationships between resources, tracking how changes propagate through your system. For example, when an EC2 instance scales up, Delphi tracks not just the instance cost, but how that scaling affects data transfer costs, load balancer charges, and downstream service performance.

delphi, is a graph-based database that models cloud infrastructure as interconnected nodes rather than isolated resources

To gain this level of insight, you need to understand not just how things are connected, but also how and when changes ripple through the system.

This approach has helped our customers better understand and control their cloud costs. More importantly, it reveals a fundamental truth: in cloud environments, your architecture determines your economics. The sooner you understand those relationships, the sooner you can take control – because architecture doesn’t just shape your system. It shapes your bottom line.