What Lens 2 means
Lens 2 asks another important question:
What role does this module play in cost decision-making?
Not every module in CloudPilot needs to produce billing data. That is not the point. A monitoring module does not need to behave like a cost explorer. A CMDB does not need to become a billing system. A resilience module does not need to calculate cloud spend directly.
However, each module may still strengthen cost decisions.
Some modules provide the financial truth. Some explain why cost exists. Some justify why spending is necessary. Others help trigger action when spend is inefficient, unmanaged, risky, or no longer aligned to business needs.
This lens helps CloudPilot avoid treating every module as if it should do the same thing. Instead, it asks what each module contributes to a better cost decision.
That is important because cloud cost is rarely just a finance problem. It is usually connected to ownership, usage, performance, architecture, risk, governance, and operational maturity.
Cost data is not the same as cost context
A common mistake in cloud platforms is assuming that cost visibility only means showing billing data.
Billing data is important, but on its own it often does not explain enough.
For example, knowing that an EC2 instance costs £800 per month tells you what is being spent. But it does not tell you:
- who owns it
- what service it supports
- whether it is still needed
- whether it is underused
- whether it is business-critical
- whether it is part of a resilience requirement
- whether it is managed through Terraform
- whether it can safely be resized or removed
This is where CloudPilot’s wider architecture becomes valuable.
FinOps may provide the financial view, but other modules provide the decision context. Without that context, cost optimization can become risky, shallow, or difficult to act on.
Lens 2 therefore separates cost truth from cost understanding.
Why this matters in CloudPilot
CloudPilot is not just trying to show teams where money is being spent. It is trying to help them understand whether that spend makes sense.
That requires more than a billing dashboard.
For example:
- Monitoring can explain whether a costly resource is actually being used.
- CMDB can show who owns the resource and which service depends on it.
- Cloud Control can show whether the resource is managed, unmanaged, or drifting from its intended state.
- Resilience can explain why higher cost may be justified for availability, recovery, or risk reduction.
- Vault can add governance context where sensitive credentials or privileged access are linked to operational assets.
This means each module contributes to cost decision-making in a different way.
CloudPilot’s value comes from connecting those roles together, so cost decisions are not made in isolation.
The four cost decision questions
At a global level, each CloudPilot module should be assessed using four questions.
1. Does this module provide direct financial truth?
This means the module contributes actual financial data or calculations based on financial inputs.
Examples include:
- billing imports
- cloud spend data
- cost allocation
- forecasting
- unit cost modelling
- rightsizing calculations
- savings plan analysis
- idle resource savings
This is where FinOps sits most strongly.
If the question is “What are we spending?”, the answer should come from the financial layer.
2. Does this module explain cost through operational context?
This means the module helps explain why cost exists by showing how resources are behaving.
Examples include:
- CPU usage
- memory usage
- request volume
- throughput
- performance trends
- error rates
- capacity signals
- runtime anomalies
- underused resources
This is where Monitoring becomes important.
Monitoring may not be the financial source of truth, but it helps answer a different question:
Is the cost justified by actual usage and demand?
For example, if a database cost increases, monitoring can show whether traffic increased, whether workloads changed, or whether the resource is overprovisioned.
3. Does this module justify cost through business, risk, or governance context?
This means the module helps explain whether spend is intentional, accountable, or necessary.
Examples include:
- ownership
- service mapping
- business criticality
- environment classification
- resilience requirements
- recovery objectives
- compliance controls
- Terraform coverage
- drift status
- policy alignment
- access governance
This is where CMDB, Cloud Control, Resilience, and Vault become valuable.
They may not produce cost figures directly, but they help answer questions such as:
- Who owns this cost?
- What business service does it support?
- Is this spend intentional?
- Is the resource governed properly?
- Is the cost justified by risk or availability requirements?
- Is this infrastructure aligned to the intended state?
Without this context, cost decisions can become disconnected from operational reality.
4. Does this module trigger or support cost-related action?
This means the module helps teams act on cost information.
Examples include:
- rightsizing
- decommissioning
- ownership reassignment
- policy enforcement
- drift remediation
- exception review
- tagging improvement
- budget review
- resilience trade-off review
- approval workflows
This is where CloudPilot moves from visibility into action.
A platform should not only say, “This costs too much.”
It should help teams understand what to do next, who should do it, and whether it is safe to act.
The three cost decision layers
Lens 2 can be explained through three connected layers.
Layer 1: Financial truth
Layer 1 contains the modules or services that provide actual financial data.
This includes:
- billing imports
- cost allocation
- forecasting
- optimisation calculations
- savings opportunities
- unit cost modelling
- cloud spend reporting
In CloudPilot, this is mainly the role of FinOps.
FinOps tells the organisation what is being spent, where the money is going, and what optimisation opportunities may exist.
However, Layer 1 alone is not enough.
A cost recommendation based only on billing data may be technically correct but operationally unsafe. For example, a resource may look oversized, but it may support a critical service, have unpredictable usage patterns, or be required for resilience reasons.
That is why Layer 1 needs the other layers.
Layer 2A: Operational context
Layer 2A explains cost through runtime behaviour.
This includes:
- utilisation
- traffic
- demand
- throughput
- performance
- capacity
- errors
- runtime anomalies
- underused infrastructure
In CloudPilot, this is mainly the role of Monitoring.
Monitoring helps answer whether the spend is supported by real usage.
For example:
- A high-cost service may be justified if demand has increased.
- A large instance may be wasteful if utilisation is consistently low.
- A cost spike may make sense if there was a legitimate traffic increase.
- A rightsizing recommendation may be safer if monitoring confirms low usage over time.
This gives FinOps recommendations more confidence because they are backed by operational evidence.
Layer 2B: Ownership and governance context
Layer 2B explains whether cost is accountable, intentional, governed, and justified.
This includes:
- ownership
- service relationships
- business context
- criticality
- resilience posture
- recovery objectives
- drift
- Terraform coverage
- policy controls
- privileged access context
- compliance requirements
In CloudPilot, this layer is mainly supported by CMDB, Cloud Control, Resilience, and Vault.
This layer answers questions such as:
- Who owns this resource?
- Which service does it support?
- Is it production or non-production?
- Is it business-critical?
- Is it managed through infrastructure as code?
- Has it drifted from its intended state?
- Is the higher cost justified by resilience requirements?
- Does the asset have sensitive access or credentials linked to it?
This is important because not every expensive resource is a problem.
Some resources cost more because they support critical services, require high availability, or reduce operational risk. Others cost more because they are unmanaged, forgotten, oversized, duplicated, or poorly governed.
Layer 2B helps CloudPilot tell the difference.
How the layers work together
The layers become most valuable when they are connected.
Financial truth tells us:
What are we spending?
Operational context tells us:
Is that spend aligned with actual usage and demand?
Ownership and governance context tells us:
Who is accountable, is the spend intentional, and should action be taken?
This is where CloudPilot becomes more powerful than a standard cost tool.
A normal cost dashboard may show that a resource is expensive. CloudPilot can connect that cost to runtime usage, ownership, drift, resilience, and governance context.
For example:
- FinOps identifies a high-cost EC2 instance.
- Monitoring shows it has low CPU and memory usage.
- CMDB shows it belongs to a specific service owner.
- Cloud Control shows it is unmanaged and not covered by Terraform.
- Resilience shows it is not part of a critical recovery plan.
CloudPilot can then recommend review, ownership confirmation, rightsizing, or decommissioning.
That is a much stronger decision model than billing data alone.
Module interpretation
Each CloudPilot module should have a clear primary role in the cost decision model.
FinOps
FinOps sits primarily in Layer 1 Financial truth.
Its role is to provide cost visibility, financial interpretation, optimisation opportunities, allocation, forecasting, and savings analysis.
FinOps answers questions such as:
- What are we spending?
- Where is the spend coming from?
- Which services or accounts are driving cost?
- Where are the optimisation opportunities?
- What savings are possible?
FinOps is the financial anchor of the cost model.
Monitoring
Monitoring sits primarily in Layer 2A Operational context.
Its role is to explain cost through runtime behaviour.
Monitoring answers questions such as:
- Is this resource actually being used?
- Has demand increased?
- Is the workload under pressure?
- Is the resource overprovisioned?
- Is the cost spike linked to real traffic or an anomaly?
- Would rightsizing be safe based on utilisation?
Monitoring does not need to be a billing tool. Its value is that it strengthens the evidence behind cost decisions.
CMDB
CMDB sits primarily in Layer 2B Ownership and governance context.
Its role is to connect cost to ownership, services, teams, environments, and business context.
CMDB answers questions such as:
- Who owns this cost?
- What service does this resource support?
- Is it production or non-production?
- Which team should review it?
- Is the spend linked to a business-critical service?
Without CMDB, cost can be visible but not accountable.
Cloud Control
Cloud Control sits primarily in Layer 2B, with some overlap into Layer 2A.
Its role is to govern infrastructure by showing what exists, what is managed, what has drifted, and what does not align with the intended state.
Cloud Control answers questions such as:
- Is this resource managed through Terraform?
- Has it drifted from intended configuration?
- Is this asset unmanaged or unexpected?
- Does the actual cloud estate match the intended architecture?
- Could this cost be caused by infrastructure sprawl?
This makes Cloud Control an important cost governance layer.
It may not own financial truth, but it helps identify whether spend is controlled, intentional, and aligned with policy.
Resilience
Resilience sits primarily in Layer 2B Ownership and governance context.
Its role is to explain when higher cost may be justified by risk, availability, or recovery requirements.
Resilience answers questions such as:
- Is this cost required for high availability?
- Is the resource part of a disaster recovery plan?
- Does the service have strict RTO or RPO requirements?
- Would reducing cost increase operational risk?
- Is the spend justified by business continuity needs?
This is important because cost optimization should not blindly reduce spending.
Some spend is necessary because it protects the organisation.
Vault
Vault sits mainly in Layer 2B Ownership and governance context.
Its role is to provide governance context around credentials, secrets, privileged access, and sensitive operational assets.
Vault answers questions such as:
- Does this asset have sensitive credentials linked to it?
- Who has access to the credentials?
- Is access controlled and auditable?
- Would decommissioning or changing this asset affect secrets or integrations?
- Is there a governance risk attached to this resource?
Vault may not directly explain cost, but it can affect whether action is safe and controlled.
Why this lens matters for product design
Lens 2 is important because it prevents CloudPilot from forcing every module to become a cost module.
That would create confusion.
Instead, CloudPilot can define each module’s contribution clearly:
- FinOps gives financial truth.
- Monitoring gives usage evidence.
- CMDB gives ownership and service context.
- Cloud Control gives governance and drift context.
- Resilience gives risk and availability justification.
- Vault gives access and secrets governance context.
This allows each module to remain strong in its own area while still contributing to better cost decisions.
The platform does not need every module to calculate cost. It needs every module to help explain, justify, govern, or act on cost where relevant.
Example decision flow
A good example would be a high-cost cloud resource.
A basic cost tool may only show:
This resource costs £1,200 per month.
CloudPilot should be able to show:
- FinOps: This resource costs £1,200 per month and has a potential saving opportunity.
- Monitoring: Utilisation has been below 10% for the last 30 days.
- CMDB: The resource belongs to the ticketing service and is owned by the Platform team.
- Cloud Control: The resource is not managed through Terraform and appears outside the intended state.
- Resilience: It is not part of a critical recovery plan.
- Vault: No active privileged secrets are linked to this asset.
The decision becomes much clearer.
Instead of only asking, “Can we reduce this cost?”, CloudPilot helps ask:
- Is it being used?
- Who owns it?
- Is it governed?
- Is it risky to change?
- Is it justified?
- What action should happen next?
That is the difference between cost reporting and cost decision support.
The key principle behind Lens 2
The key principle behind Lens 2 is this:
Not every module needs to generate cost data, but every module can strengthen cost decisions.
This is an important distinction.
If CloudPilot tries to make every module financial, the platform becomes unclear. But if CloudPilot defines how each module contributes to cost understanding, the platform becomes much more powerful.
The goal is not to turn Monitoring, CMDB, Cloud Control, Resilience, and Vault into billing tools.
The goal is to connect their context to financial truth so that cost decisions are better informed, safer, and more actionable.
Summary
Lens 2 is ultimately about decision context.
Cost data tells you what is being spent, but it does not always tell you whether that spend is justified, efficient, risky, accountable, or actionable.
CloudPilot should therefore treat cost as a connected decision model:
- FinOps provides the financial truth.
- Monitoring explains cost through runtime behaviour.
- CMDB assigns ownership and service context.
- Cloud Control governs infrastructure state and drift.
- Resilience explains when cost is justified by risk and availability.
- Vault adds access and secrets governance context.
This is what allows CloudPilot to go beyond cost visibility.