Cost Layers

Documentation Index

Fetch the complete documentation index at: https://docs.cloudcapital.co/llms.txt

Use this file to discover all available pages before exploring further.

Cost layers are the named categories your cloud spend is mapped to. Every dollar of AWS spend flows into a cost layer, and that structure becomes the foundation for your forecast, your savings analysis, and Cloud Capital’s commitment proposals. This page covers how to manage that structure over time. For the initial setup walkthrough — the guided flow, the manual canvas, and the toolbar — see Cloud Resource Mapping.

---

​

Default structure

Cloud Capital starts every organisation with three top-level layers:

• Production (COGS) — infrastructure that directly supports your live product or service. Cost of Goods Sold in financial terms: scales with revenue, belongs on the P&L as a direct cost of delivery.
• Non-Production (OpEx) — development, staging, testing, and internal tooling. Operating Expenditure: necessary business cost, but not directly tied to serving customers.
• Unallocated — spend that hasn’t been assigned to a layer yet. Your goal is to move all meaningful spend out of Unallocated and into the right layer. The Coverage % filter on the canvas shows your current allocation percentage — aim for 90%+ before building out your forecast.

The Cost Layers column on the right side of the canvas shows your current structure and how spend is distributed across it.

---

​

Adding a sub-layer

Sub-layers let you break down Production or Non-Production into meaningful categories — by product, team, AWS service family, region, or business line. The Forecast table reflects this structure directly, so adding a sub-layer immediately gives your finance team more granular visibility into where spend is going. To add a sub-layer:

1. Click any Product Code node on the canvas to open the Assign to Cost Layer picker.
2. Hover over the layer you want to add a child under. A + button appears to the right of the layer name.

3. Click +. An inline text input appears beneath the layer.

4. Type a name and click Create (or press Enter). The new layer appears immediately in the tree.
5. Click Save Changes in the toolbar to persist the new layer.

---

​

Reassigning a service

Assignments can be changed at any time as your infrastructure evolves. A service that launched under one cost layer may belong under a different one after a re-architecture or ownership change. To reassign a service:

1. Click the Product Code node you want to reassign on the canvas.
2. The Assign to Cost Layer picker opens showing the current assignment.
3. Click the new destination layer in the tree. The flow in the canvas updates immediately.
4. Click Save Changes to persist.

If the Product Code node is showing as already assigned (green checkmark), you can still click it to open the picker and change the assignment.

---

​

Understanding inheritance

Assignments flow down the hierarchy. When a Linked Account has been assigned to a cost layer, all Product Code nodes within that account inherit that assignment automatically — you don’t need to assign each service individually. This means:

• Account-level assignment is the efficient path when all services in an account belong to the same layer.
• Product Code-level assignment overrides the account-level assignment for that specific service only. Use this when one account contains services that belong to different layers — for example, a shared services account where most spend is Non-Production but a specific RDS instance is production-grade.

If you reassign an account to a different layer, all Product Code nodes within it that were inheriting the old assignment will update automatically. Any Product Code nodes that had been explicitly assigned at the service level keep their individual assignments unchanged. To see which nodes are inheriting vs explicitly assigned, use the Hierarchy filter in the top-right of the canvas — it toggles between leaf-level and full hierarchy views.

---

​

When to update your structure

Cost layer structure should reflect how your business and your finance team think about cloud spend. Common reasons to revisit it:

• New product line launched — add a sub-layer under Production to track that product’s infrastructure separately from day one.
• Team reorganisation — if engineering ownership has changed, update layer names and reassign services to match the new structure before the next forecast review.
• Infrastructure migrated — if a service that was Non-Production is now customer-facing, reassign it to Production (COGS). This affects your COGS/OpEx split and flows directly into the forecast and commitment sizing.
• Coverage below 90% — check the Unallocated only filter to find unassigned services and work them into the right layers.

The earlier Cloud Capital knows about a structural change, the better the forecast can reflect it. For planned changes — migrations, new workloads, deprecations — consider also adding an Engineering Initiative so the cost impact is visible in the forecast before it hits the bill.

---

​

Related pages