# AWS → Cloud Capital Skill
Source: https://docs.cloudcapital.co/ai/aws-to-cloud-capital-skill
A Claude skill that automatically creates Cloud Capital Engineering Initiatives from Linear or Jira tickets describing AWS infrastructure work.
When an engineer creates a Linear or Jira ticket that involves AWS infrastructure — a right-sizing project, a new service launch, a migration, or a decommission — the cost impact needs to find its way into Cloud Capital's forecast before the change hits the bill. This skill bridges that gap automatically.
When invoked, the skill reads the ticket, extracts the affected AWS services and estimated cost impact, creates a matching Cloud Capital Engineering Initiative with the right duration and resource filters, and writes a reference back to the ticket so there is a permanent link between the engineering work and the forecast.
This skill is a starting point, not a finished product. As you use it, you will encounter edge cases, develop preferences for how initiatives are named and scoped, and build up a better sense of what assumptions are right for your team. We encourage you to open the skill and edit it — add your own service mappings, adjust the default magnitude assumptions, refine the descriptions it writes. Skills get meaningfully better the more you put back into them.
## Prerequisites
The skill requires access to both your project management tool and Cloud Capital via MCP. Install **one** of the following project management MCPs and **the Cloud Capital MCP**:
| MCP | Purpose | Install guide |
| ------------------------------------------------------------------ | -------------------------------------------- | ----------------------------------------- |
| [Linear MCP](https://linear.app/docs/mcp) | Read and update Linear issues | linear.app/docs/mcp |
| [Atlassian MCP](https://github.com/atlassian/atlassian-mcp-server) | Read and update Jira tickets | github.com/atlassian/atlassian-mcp-server |
| [Cloud Capital MCP](/ai/mcp-server) | Create initiatives and look up service names | docs.cloudcapital.co/ai/mcp-server |
## Installation
### Claude Desktop
1. [Download aws-to-cloud-capital.skill](https://cloudcapital-integration.s3.us-east-1.amazonaws.com/claude/aws-to-cloud-capital.skill).
2. In Claude Desktop, open **Settings** and navigate to the **Skills** tab.
3. Click **Import Skill** and select the downloaded file.
4. The skill is immediately available in any conversation as `/aws-to-cloud-capital`.
### Claude Code
Copy the `.skill` file into your global Claude skills directory:
```bash theme={null}
mkdir -p ~/.claude/skills
cp aws-to-cloud-capital.skill ~/.claude/skills/
```
The skill is immediately available in any Claude Code session as `/aws-to-cloud-capital`. No restart required.
To scope the skill to a single project instead, place it in that project's `.claude/skills/` directory.
## How to use it
Once the skill and MCPs are installed, trigger it any time you are working with a Linear or Jira ticket that touches AWS spend. The skill can be run explicitly or fires automatically when a ticket describing AWS infrastructure work is being created.
**Explicit invocation:**
```
/aws-to-cloud-capital
```
Call this while viewing or writing a ticket. The skill reads the ticket in context, asks for clarification only if something is ambiguous, and then creates the initiative.
**Automatic trigger:**
The skill is also designed to fire without being called when a Linear or Jira ticket is created that involves any of the following:
* ECS / Fargate task changes
* EC2 launches, resizes, or terminations
* RDS, Aurora, or managed database changes
* Lambda deployments
* S3 migrations or data movement
* Service deprecations or decommissions
* Right-sizing or optimisation projects
* New product launches on AWS
* On-prem to cloud or service-to-service migrations
* Capacity scaling plans
* Spot or Reserved Instance strategy changes
## What happens
The skill works through five steps behind the scenes:
1. **Extracts intent** — reads the ticket title and description to identify affected AWS services, cost direction (increase or decrease), magnitude, and timeline.
2. **Resolves service names** — maps plain-English references ("containers", "Postgres", "load balancer") to exact Cloud Capital service identifiers, confirming against your org's live data when needed.
3. **Creates an Engineering Initiative** — calls Cloud Capital with the right impact type (relative percentage or absolute dollar amount), duration (temporary or permanent), and a description referencing the ticket.
4. **Creates the resource filter mapping** — sets up the monthly cost effects tied to the correct AWS services.
5. **Updates the ticket** — writes a Cloud Capital reference back to the Linear issue or Jira ticket so engineers always know the forecast impact has been modelled.
## Examples
### Right-sizing an ElastiCache cluster
> *"Right-size Redis cluster — targeting \~25% cost reduction, work starts August, completes by end of September."*
The skill creates a single TEMPORARY initiative on `AmazonElastiCache` with a relative -25% effect for August and September, then closes. The Linear or Jira ticket gets a Cloud Capital section appended.
***
### New product launch adding EC2 capacity
> *"Launching Payments API in August — will require significant new EC2 capacity, estimating 40% growth over current EC2 spend."*
The skill creates a PERMANENT initiative on `AmazonEC2` with a relative +40% effect starting August. Because this is ongoing spend, no end date is set.
***
### Migration from EC2 to ECS Fargate
> *"Migrate worker fleet from EC2 to ECS Fargate over Q3. EC2 fleet fully decommissioned by end of September."*
Because the two services have different impact profiles, the skill creates two initiatives:
* **AmazonEC2** — TEMPORARY: ramps down to -100% by September
* **AmazonECS** — PERMANENT: ramps up to reflect the new Fargate workload
***
### Decommissioning a legacy RDS cluster
> *"Decommission legacy Postgres RDS cluster at end of Q3. Workload migrating to DynamoDB — no like-for-like replacement."*
The skill creates two initiatives:
* **AmazonRDS** — PERMANENT: -100% from October onwards
* **AmazonDynamoDB** — if DynamoDB spend is currently near zero, the skill uses an ABSOLUTE dollar estimate rather than a percentage (since a percentage of near-zero is meaningless), and flags the assumption clearly for you to update once you have real numbers.
## Tips
* **Uncertain magnitude?** The skill uses a conservative default and makes the assumption explicit in the initiative description — a prompt to revisit once better numbers are available.
* **No timeline in the ticket?** The skill defaults to starting next calendar month. Open-ended work gets PERMANENT duration; bounded work defaults to 3 months with a note.
* **Ticket already references an initiative?** The skill updates the existing initiative rather than creating a duplicate.
* **Purely operational work?** IAM policy changes, config updates, and similar tickets with no material cost impact are skipped, and the skill explains why.
# In-App Assistant
Source: https://docs.cloudcapital.co/ai/chat-assistant
Ask questions about your cloud costs, forecasts, initiatives, and more using the Cloud Capital AI assistant.
The Cloud Capital AI assistant is a chat interface built into the Cloud Capital web app. It can answer questions about your cloud costs, forecasts, initiatives, billing, and business metrics — and it has awareness of the page you're currently viewing.
![Cloud Capital AI chat assistant]()
## Opening the assistant
Click the floating chat button in the bottom-right corner of the app. A chat drawer opens on the right side of your screen.
![Chat assistant interface]()
## What you can ask
Here are some example prompts to get started:
* "What were our top 3 cost increases last month?"
* "Show me the forecast for the next 6 months"
* "Create an initiative to reduce EC2 costs by 15%"
* "Compare this month's spend to last month by service"
* "What cost layers are under Production?"
* "What business metrics are we tracking?"
## Capabilities
Query historical spend, compare periods, and break down costs by service, account, region, or tags.
View projected costs and understand your cost layers.
Create, view, and manage cost optimization [initiatives](/forecasting/initiatives).
Track and manage unit economics [business metrics](/forecasting/business-metrics).
Review billing periods, summaries, and breakdowns.
The assistant can see what page you're on and reference it in answers, so you can ask follow-up questions about what you're looking at.
## Managing conversations
* Click **New conversation** to start a fresh chat.
* Use the history toggle to view past conversations.
* Each conversation maintains context, so you can ask follow-up questions without repeating yourself.
## Notes
The assistant can only access data within your current organization.
* If you don't see the chat button, contact your Cloud Capital representative to have it enabled.
* Available capabilities may vary depending on how your organization is configured.
* The same tools available in the chat assistant are also accessible through the [MCP server](/ai/mcp-server) for use in external AI tools.
# MCP server
Source: https://docs.cloudcapital.co/ai/mcp-server
Connect AI tools like Cursor, Claude Desktop, and Windsurf to your Cloud Capital data using the Model Context Protocol.
The Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external data sources. Cloud Capital provides an MCP server that gives your AI tools direct access to your cloud cost data, forecasts, initiatives, and more — the same capabilities available in the [in-app chat assistant](/ai/chat-assistant).
## Server URL
```
https://app.cloudcapital.co/api/v1/mcp/server
```
## Setting up in Cursor
Open Cursor Settings and navigate to the MCP server configuration section.
Add a new server with this configuration:
```json theme={null}
{
"mcpServers": {
"cloudcapital": {
"url": "https://app.cloudcapital.co/api/v1/mcp/server"
}
}
}
```
Cursor opens a browser window for authorization. Sign in to Cloud Capital (if not already signed in), select the organization you want to authorize access for, and click **Authorize**.
Switch back to Cursor — the connection is now active.
## Setting up in Windsurf
Windsurf uses the same configuration format as Cursor. Follow the Cursor steps above, entering the same server URL and JSON configuration in Windsurf's MCP settings. The authorization flow is identical.
## Setting up in Claude Desktop
Claude Desktop's local config file only supports STDIO-based MCP servers — it cannot connect directly to remote HTTP servers. To connect to Cloud Capital's MCP server, use the `mcp-remote` bridge, which runs locally and handles the OAuth flow on your behalf.
You will need [Node.js](https://nodejs.org) installed on your machine for the `npx` command to work.
Claude Desktop reads MCP server settings from a JSON config file on your machine. Open it in any text editor:
* **macOS:** `~/Library/Application Support/Claude/claude_desktop_config.json`
* **Windows:** `%APPDATA%\Claude\claude_desktop_config.json`
If the file does not exist, create it.
Add the following to your config file. If `mcpServers` already exists, add the `cloudcapital` entry inside it:
```json theme={null}
{
"mcpServers": {
"cloudcapital": {
"command": "npx",
"args": ["mcp-remote", "https://app.cloudcapital.co/api/v1/mcp/server"]
}
}
}
```
`mcp-remote` acts as a local bridge between Claude Desktop and the Cloud Capital HTTP server. It handles the OAuth authorization flow automatically.
Quit and relaunch Claude Desktop to load the new configuration.
When Claude Desktop first connects, `mcp-remote` opens a browser window for authorization. Sign in to Cloud Capital (if not already signed in), select the organization you want to authorize access for, and click **Authorize**. The token is cached locally — you will not need to re-authorize on subsequent launches.
## API key authentication
By default, MCP clients use OAuth — a browser window opens for sign-in and the token is cached locally. Some clients do not persist this token between sessions, requiring you to re-authorize each time. Using an API key instead bypasses the OAuth flow entirely, giving you persistent access without re-authentication on restart.
### Create an API key
1. In the Cloud Capital app, click your organization name at the bottom of the sidebar to open **Organization Settings**.
2. Navigate to the **Developers** tab.
3. Under **API Keys**, click **Create API Key**, give it a name, and copy the key — it is only shown once.
### Configure your client with an API key
**Cursor and Windsurf**
Replace the standard URL-only configuration with:
```json theme={null}
{
"mcpServers": {
"cloudcapital": {
"url": "https://app.cloudcapital.co/api/v1/mcp/server",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
```
**Claude Desktop**
Pass the key as a header through `mcp-remote`. Using an environment variable keeps the key out of the config file itself:
```json theme={null}
{
"mcpServers": {
"cloudcapital": {
"command": "npx",
"args": [
"mcp-remote",
"https://app.cloudcapital.co/api/v1/mcp/server",
"--header",
"Authorization:${API_KEY}"
],
"env": {
"API_KEY": "Bearer YOUR_API_KEY"
}
}
}
}
```
Replace `YOUR_API_KEY` with the key you copied from the Developers tab.
***
## Authorization and security
When an MCP client connects for the first time, it opens a browser window with the Cloud Capital **Authorize Access** screen. From here you select the organization you want to grant access to and review the permissions being requested.
![Authorize Access screen]()
* The client only has access to the organization you selected during the consent step.
* You are shown the exact permissions being granted before you authorize.
* Click **Authorize** to complete the connection, or **Deny** to cancel.
* Authorization uses industry-standard OAuth 2.1 with PKCE.
## Managing connected applications
In the Cloud Capital app, click your organization name at the bottom of the sidebar.
Select the **Developers** tab. Under **Cloud Capital MCP Server**, you will see all connected applications.
From this screen you can:
* **Revoke Token** — invalidates a specific access token. The app can reconnect without re-authorizing.
* **Disconnect App** — fully removes the app and all its tokens. The app will need to go through the authorization process again.
## Available tools
The MCP server provides the same tools as the in-app [chat assistant](/ai/chat-assistant): cost queries, forecasts, initiatives, billing, business metrics, and more. You can ask your AI tool to list available capabilities at any time.
## Troubleshooting
| Issue | Solution |
| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Tool can't connect | Verify the correct URL is configured: `https://app.cloudcapital.co/api/v1/mcp/server` |
| Authorization fails | Confirm your account is a member of at least one Cloud Capital organization |
| Need to switch organizations | Disconnect the app from the Developers tab and re-authorize with the new organization selected |
| Claude Desktop — invalid configuration error | Claude Desktop does not support `"type": "http"` in its local config. Use the `mcp-remote` approach described above instead |
| Claude Desktop — `npx` not found | Node.js is required. Install it from [nodejs.org](https://nodejs.org) and restart Claude Desktop |
| Claude Desktop — browser doesn't open for authorization | Run `npx mcp-remote https://app.cloudcapital.co/api/v1/mcp/server` directly in a terminal to trigger the OAuth flow manually, then restart Claude Desktop |
| Re-prompted to sign in on every restart | Use API key authentication instead of OAuth — create a key in Organization Settings → Developers and configure it as a header (see above) |
# Compare costs across periods
Source: https://docs.cloudcapital.co/api-reference/cost-insights/compare-costs-across-periods
/api-reference/openapi.yaml post /cost-insights/compare
Compare costs between two time periods. Returns per-dimension
comparisons with absolute and percentage deltas, plus aggregated
totals for all key metrics.
# Create shared filter
Source: https://docs.cloudcapital.co/api-reference/cost-insights/create-shared-filter
/api-reference/openapi.yaml post /cost-insights/shared-filters
Store a shared filter configuration. Shared filters allow you
to save complex filter and grouping combinations and share them
with other team members via a unique ID.
# Get available filters
Source: https://docs.cloudcapital.co/api-reference/cost-insights/get-available-filters
/api-reference/openapi.yaml post /cost-insights/filters
Retrieve available filter values with cross-filtering support.
Returns the set of valid filter options based on the current
filter selection, allowing progressive refinement of queries.
When filters are provided, each requested field's options are
computed with all *other* active filters applied (cross-filtering).
# Get cost category values
Source: https://docs.cloudcapital.co/api-reference/cost-insights/get-cost-category-values
/api-reference/openapi.yaml post /cost-insights/cost-category-values
Retrieve values for a specific AWS cost category. Cost categories
allow you to group and filter costs using custom classification
rules defined in your AWS account.
# Get cost data
Source: https://docs.cloudcapital.co/api-reference/cost-insights/get-cost-data
/api-reference/openapi.yaml post /cost-insights/data
Retrieve cost data with flexible filtering and grouping options.
Results include a detailed cost breakdown per date and dimension,
plus an aggregated summary across the full period.
# Get shared filter
Source: https://docs.cloudcapital.co/api-reference/cost-insights/get-shared-filter
/api-reference/openapi.yaml get /cost-insights/shared-filters/{filterId}
Retrieve a previously stored shared filter configuration by its ID.
# Get tag values
Source: https://docs.cloudcapital.co/api-reference/cost-insights/get-tag-values
/api-reference/openapi.yaml post /cost-insights/tag-values
Retrieve values for a specific resource tag key. Use this endpoint
to discover available tag values for filtering cost data by
custom resource tags.
# Overview
Source: https://docs.cloudcapital.co/api-reference/overview
Get started with the Cloud Capital Public API to programmatically access your cloud cost data.
The Cloud Capital Public API gives you programmatic access to your cost insights data. You can query costs, apply filters, compare time periods, and manage saved filter configurations.
Successful responses are JSON objects with `"success": true` and a `"data"` property containing the endpoint-specific payload.
For most error status codes, the body is `{ "success": false, "error": { "message": "..." } }`. **HTTP 401** is an exception: missing or invalid credentials return `{ "message": "Unauthorized" }` from the API gateway.
## Base URL
All API requests are made to:
```
https://api.cloudcapital.co/v1
```
## Authentication
The API uses API key authentication. Include your key in the `Authorization` header as a Bearer token with every request.
```bash theme={null}
curl -X POST https://api.cloudcapital.co/v1/cost-insights/data \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"filters":{"inclusions":{"dateRange":{"start":"2025-01-01","end":"2025-01-31"}}},"groupBy":{"dimension":"service","dateGrouping":"monthly"}}'
```
### Creating an API key
Navigate to **Settings > API keys** in your [Cloud Capital dashboard](https://app.cloudcapital.co).
Click **Create API key**, give it a descriptive name, and select the appropriate permissions.
Copy the generated key immediately. For security, the full key is only shown once.
Keep your API keys secure. Do not expose them in client-side code, public repositories, or logs.
## Rate limits
API requests are rate-limited to protect service availability. When you exceed the limit, the API returns a `429` status code.
| Header | Description |
| ----------------------- | ---------------------------------------- |
| `X-RateLimit-Limit` | Maximum requests per minute |
| `X-RateLimit-Remaining` | Remaining requests in the current window |
| `Retry-After` | Seconds to wait before retrying |
## Error handling
The API returns standard HTTP status codes. Application errors (for example validation failures) use the envelope below.
```json theme={null}
{
"success": false,
"error": {
"message": "Invalid request. Please see message details.. Invalid input: expected object, received undefined (at groupBy)"
}
}
```
**401 Unauthorized** uses a different shape:
```json theme={null}
{
"message": "Unauthorized"
}
```
| Status code | Description |
| ----------- | --------------------------------------------------------------------------------------------- |
| `200` | Success (`success: true` and `data` payload) |
| `400` | Invalid request parameters or body |
| `401` | Missing or invalid API key |
| `429` | Rate limit exceeded |
| `500` | Server or upstream error (some operations may use this when a resource is missing or expired) |
## Next steps
Browse the **Cost insights** endpoints in the sidebar to start querying your data. Each endpoint page includes an interactive playground where you can send requests directly from the docs.
# What is Cloud Capital?
Source: https://docs.cloudcapital.co/cloud-capital
Cloud Capital helps companies control cloud spend across AWS and GCP, with a guaranteed savings rate on AWS commitments and no commitment risk.
[Cloud Capital](https://www.cloudcapital.co) is a cloud cost optimization platform, with **Forecasting** available for both AWS and GCP (GCP in Beta) and **Commitment Optimization** built for AWS. We help companies reduce their cloud spend by purchasing and managing Reserved Instances and Savings Plans on their behalf — taking on the financial risk of commitment underutilization so customers don't have to. Every Cloud Capital customer receives a **Guaranteed Savings Rate**: a contractual savings rate that Cloud Capital stands behind regardless of how commitments perform month to month.
Cloud Capital works across two connected disciplines. **Forecasting** builds a forward-looking model of your cloud spend, connecting your business plan and engineering roadmap to your cost trajectory so that commitment sizing is grounded in where your business is actually going — not just where it has been. **Commitment Optimization** uses that forecast to purchase and manage the right mix of commitments at the right time, adapting continuously as your usage evolves. Together, they deliver savings that compound over time with the risk carried by Cloud Capital, not your finance team.
To learn more about the company, visit [cloudcapital.co](https://www.cloudcapital.co) or [read about our story](https://www.cloudcapital.co/about).
***
How Cloud Capital models your savings potential and what your product path looks like.
Connect your AWS or GCP data and start building your forecast.
How Cloud Capital models your cloud spend.
How commitments are purchased, managed, and guaranteed.
How Cloud Capital accesses your data and what it can see.
# Business Metrics
Source: https://docs.cloudcapital.co/forecasting/business-metrics
Connect your growth data to your forecast so cloud costs move with your business plan, not just your recent history.
A business metric is an external dataset you bring into Cloud Capital — customer count, active users, revenue, transactions, or any other number that correlates with your cloud spend. When a metric is connected to a Cost Layer, Cloud Capital uses the historical relationship between that metric and your actual costs to project how spend will move as the metric changes.
This is the step that makes your forecast forward-looking. Instead of extrapolating from a cost trend, Cloud Capital projects from the thing that actually drives the cost: how many customers you expect to serve, how fast your user base is growing, how much revenue your finance team is already forecasting. Those inputs already exist in your business plan. Connecting them to your Cost Layers means both Finance and Engineering are working from the same numbers — and Cloud Capital has the signal it needs to size commitments against your real future rather than just your recent past.
***
## Your business metrics
The Business Metrics page shows all metrics you have defined, with a row for each one.
![Business Metrics overview page showing AI Customers, Forecasting Customers, and Users metric cards]()
Each metric card contains two rows:
* **Actuals** — historical values you have already observed
* **Forecast** — projected values going forward, aligned with your business plan
Cloud Capital will interpolate missing values in both rows to handle gaps in the dataset. If your forecast extends further than the values you have provided, costs for that Cost Layer will fall back to a flat projection after the final metric value.
***
## Adding a business metric
Click **+ New Business Metric**, enter a name for the metric, and press Enter. The new metric appears inline with editable cells.
![Adding a new business metric with an editable name field]()
Fill in the cells with your data. You do not need a value in every cell — Cloud Capital handles gaps automatically. A few practical tips:
* **Name it after what it measures**, not what it predicts. "Paying Customers" is better than "Production Cost Driver".
* **Actuals first.** The more historical overlap between metric values and actual cost data, the stronger the correlation Cloud Capital can calculate.
* **Forecast values come from your business plan.** Use the same growth assumptions Finance is already using for budgeting.
### What makes a good metric
A good business metric moves in step with the cost it is being connected to. If your production infrastructure cost grows as you add customers, then customer count is a good metric for your production Cost Layer. The stronger and more consistent that historical relationship, the more useful the metric becomes.
**Good metrics to consider:**
* Customer count or active users (for production / customer-serving infrastructure)
* Monthly recurring revenue or transactions (for billing or payment processing workloads)
* Internal users or seat count (for internal tooling or collaboration infrastructure)
* Data volume or events processed (for data pipeline or analytics cost layers)
### What makes a poor metric
Not every number correlates with every cost. A metric that moves independently of the cost layer it is connected to will not produce a meaningful forecast — it will inject noise rather than signal.
**Signs a metric may be a poor fit:**
* The cost layer includes infrastructure that scales with engineering effort, not business volume (consider [Engineering Initiatives](/forecasting/initiatives) instead)
* The metric is flat or nearly flat historically while costs vary significantly
* The metric tracks a business outcome that lags the actual cost driver by months
* The app shows **Insufficient Data** — meaning fewer than 3 months of overlapping metric and cost history exist (see correlation feedback below)
***
## Connecting a metric to a Cost Layer
Business metrics take effect when you assign them to a Cost Layer's [Projection Type](/forecasting/projection-types). Open the Projection panel for the relevant Cost Layer, select **Metric - Auto**, and choose your metric from the **Associated Business Metric** dropdown.
![Metric-Auto projection type selected in the Cost Layer Projection panel, with the Associated Business Metric dropdown visible]()
### Correlation feedback in the dropdown
When you open the Associated Business Metric dropdown, Cloud Capital shows a correlation assessment next to each metric based on the historical relationship between that metric and this Cost Layer's actual spend.
![The Associated Business Metric dropdown open, showing correlation labels next to each metric]()
The labels indicate how reliably the metric tracks with cost:
| Label | What it means |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Strong Positive Correlation** | As the metric increases, costs tend to increase reliably. A strong signal for projection. |
| **Insufficient Data** | Fewer than 3 months of overlapping metric and cost data. Cloud Capital cannot calculate a reliable correlation yet — use **Direct: 1:1** instead, or wait until more data accumulates. |
Only metrics with sufficient historical data can use the Auto methodology. Newly created metrics will show as Insufficient Data until at least 3 months of actuals are in place.
### After selecting a metric
Once you select a metric, Cloud Capital shows you two things before you commit:
![Cost Layer Projection panel after selecting Users as the associated metric, showing the correlation description and Projection Preview chart]()
**Correlation description** — A plain-language summary of the inferred relationship, for example: *"For every 1 unit Users increases, costs increase by \$7.83."* This is the coefficient Cloud Capital has derived from the historical overlap of your metric and cost data. If it matches your intuition about how this cost scales, the metric is a good fit. If it feels off, consider whether a different metric or methodology is more appropriate.
**Projection Preview** — A chart showing how the selected methodology will affect your cost forecast over the next 6 months, compared to the current projection. The scenario table beneath it shows the Baseline (your previous projection), the Current selection, and the Selected methodology side by side, with the month-by-month delta so you can see exactly how the forecast shifts before saving.
***
## Correlation methodology options
With a metric selected, you can choose how Cloud Capital uses it:
**Auto** — Cloud Capital infers the cost impact from the historical data, deriving the coefficient automatically. This is the default and works best when you have at least 3 months of overlapping data. The correlation description tells you what coefficient was calculated.
**Direct: 1:1** — Cost is projected to move in exact proportion to the metric. If your metric grows 10%, costs are projected to grow 10%. Use this when you do not yet have enough historical data for Auto, or when you have a strong operational reason to expect a direct proportional relationship.
***
## Related pages
How business metrics fit into the full forecast model.
Metric-Auto and all other projection methodologies explained.
The Cost Layer structure metrics are connected to.
Sync business metrics directly from a Google Sheet.
# Import Business Metrics from Google Sheets
Source: https://docs.cloudcapital.co/forecasting/business-metrics-import-googlesheets
Connect a Google Sheet to Cloud Capital to keep your business metrics in sync and give your cloud cost forecasts real business context.
Business metrics let you project how your cloud costs will grow based on signals from across the company — things like customer counts, headcount, or product usage. With Google Sheets integration, you can maintain those numbers directly in a spreadsheet your team already uses, and pull them into Cloud Capital without manual re-entry.
This guide walks through connecting Google Sheets, importing a metric, keeping data in sync, and disconnecting when you no longer need it.
***
## How it works
Authorize Cloud Capital to see your Google Drive via OAuth. Only files you explicitly share are visible to your team.
Browse your Drive, share a sheet with your org, and map a data range to a named business metric.
When numbers change in the sheet, any team member can refresh the metric with one click.
***
## Step 1: Connect your Google account
Navigate to **Organization Settings** in Cloud Capital and select the **Data Connections** tab.
Click **Connect** next to the Google Sheets option. This launches an OAuth authorization flow where you'll grant Cloud Capital permission to access your Google Drive.
Cloud Capital only gains access to the individual files you choose to share — not your entire Drive. No one else on your team will see spreadsheets you haven't explicitly shared with the organization. For more on how Cloud Capital handles data access and security, see the [Security](/security) page.
Once authorized, your Google account will appear as connected under Data Connections. Any files you share will appear in the **Shared Files** list here, giving you a clear record of what's accessible to Cloud Capital.
***
## Step 2: Import a metric from Google Sheets
Navigate to **Business Metrics** and click **New Metric**. You'll see a drop-down — select **Import from Google Sheets**.
Click **Browse my Drive** to see your Google Sheets files. Select the spreadsheet you want to use as a data source, then click **Share one file with the org**.
The file is now available as an organizational data source. Other team members will be able to collaborate using this specific sheet, but won't gain broader access to your Drive.
Give the metric a descriptive name — for example, *AI Customers* or *Monthly Active Users*. This is the name that will appear throughout Cloud Capital.
Tell Cloud Capital how your sheet is structured:
| Setting | Choose this if... |
| ------------------------ | ------------------------------------------------------- |
| **Dates across the top** | Your columns are months/dates and your rows are metrics |
| **Dates down the side** | Your rows are months/dates and your columns are metrics |
Cloud Capital auto-detects orientation and data range by default. These controls are there for complex sheets with multiple metrics, or if the auto-detection doesn't match your layout.
Specify which cells contain the data you want to import. Cloud Capital will detect a range automatically, but you can override it here if your sheet has headers, notes, or multiple datasets in the same tab.
By default, Cloud Capital treats data as follows:
* **Past months** (including the most recently completed month) → imported as **actuals**
* **Current and future months** → imported as **forecasts**
This matches how Cloud Capital splits time in cost projections. Adjust if your sheet uses a different convention.
Click **Import Metric**. The metric will appear in your Business Metrics list with data synced directly from your Google Sheet.
***
## Step 3: Keeping data in sync
Once a metric is connected to Google Sheets, any changes made in the spreadsheet can be pulled into Cloud Capital on demand.
Make changes to the data in your spreadsheet as you normally would. Any member of your team with access to the sheet can update the numbers.
Open the metric in Cloud Capital and click the **Refresh** button. The values will update to match the current state of the sheet, and the **Last synced** timestamp will update to confirm it.
Refresh is currently manual — click the button whenever you want to pull in the latest numbers. Automatic syncing is planned for a future release.
Any member of your team can trigger a manual refresh, not just the person who originally connected or imported the metric.
***
## Disconnecting a metric or removing a shared file
When you no longer want a metric to be tied to a Google Sheet, or you want to remove a shared file entirely, you have a few options.
Open the metric and choose **Disconnect from Sheets**. The metric stays in Cloud Capital as a standard manually-managed business metric — historical data is preserved, but it will no longer sync from the spreadsheet.
This is useful if you want to switch to entering numbers directly in Cloud Capital going forward.
Open the metric and choose **Disconnect and delete**. This removes both the Google Sheets connection and the metric itself from Cloud Capital.
Go to **Organization Settings** → **Data Connections** → **Shared Files**. From here, you can revoke access to any file you previously shared. This removes it as an available data source for the entire organization.
Removing a shared file will break any metrics that are currently importing data from it. Disconnect those metrics first (or note that they'll stop syncing) before removing the file.
***
## Frequently asked questions
No. Cloud Capital only surfaces the specific files you choose to share with your organization. Your broader Drive and any unshared spreadsheets remain private.
Yes. Each person who completes the OAuth flow connects their own Google account independently. This means different team members can share different sheets — useful if different business metrics are owned by different people.
Yes. Once a sheet is shared with the organization, you can import multiple metrics from it by going through the **Import from Google Sheets** flow and specifying different data ranges each time.
Cloud Capital won't be able to sync data from a file that has been deleted or had its permissions changed. The metric will remain in Cloud Capital with the last successfully synced values, but refreshing will fail. Reconnect or disconnect the metric accordingly.
Manual sync is the current behavior. Automatic background syncing is on the roadmap and will be introduced in a future release.
***
## Next steps
Learn how to attach business metrics to your cloud cost projections to build more accurate forecasts.
View and manage all connected data sources for your organization.
# Cost Layers
Source: https://docs.cloudcapital.co/forecasting/cost-layers
Manage your cost layer structure — add sub-layers, reassign services, understand inheritance, and keep your mapping current as your business evolves.
Cost layers are the named categories your cloud spend is mapped to. Every dollar of cloud 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](/get-started/map-cloud-resources).
***
## 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.
![Cost Allocation canvas showing the Sankey flow from Linked Accounts through Product Codes to Cost Layers, with Production COGS, Non-Production OpEx, Unallocated, and sub-layers visible on the right]()
***
## Adding a sub-layer
Sub-layers let you break down Production or Non-Production into meaningful categories — by product, team, cloud 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.
![Hovering over a cost layer row in the picker shows the + button and Select option]()
3. Click **+**. An inline text input appears beneath the layer.
![Clicking + opens an inline New cost layer name input with a Create button]()
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.
You can also add sub-layers during the initial guided setup flow — Step 2 offers a text input specifically for grouping production accounts into named sub-layers before applying the mapping.
***
## 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](/forecasting/initiatives) so the cost impact is visible in the forecast before it hits the bill.
***
## Related pages
Initial setup: the guided flow, manual canvas, and toolbar reference.
Connect growth data to your cost layers to drive forward-looking projections.
Set the forecasting methodology for each cost layer.
Model planned infrastructure changes before they hit the bill.
# Exploring the Forecast
Source: https://docs.cloudcapital.co/forecasting/forecast-controls
How to use the Forecast page controls to customize your view, compare periods, and drill into cost layer details.
The Forecast page is the primary place to review your cloud cost structure and understand how spending is trending across Cost Layers. Beyond the table itself, a set of controls in the top-right of the page give you flexible ways to look at the data — and clicking into any Actuals cell opens a detailed comparison panel.
***
## Date Range
The calendar button in the top right controls the time window shown across the table and chart. Click it to open the date range picker.
![Forecast date range selector]()
The picker has two settings:
**Granularity** — toggle between **Month** and **Quarter** columns. Quarter view condenses the table, useful when reviewing longer time windows with your finance team.
**Range presets** — choose a common window with one click:
| Preset | What it shows |
| -------------- | ----------------------------------------------------------------- |
| Last 6 months | Six months of actuals, ending with the most recent complete month |
| Next 12 months | The current month through the next 12 months of forecast |
| 3mo + 9mo | Three months of actuals plus nine months of forecast (default) |
| 6mo + 6mo | Six months of actuals plus six months of forecast |
| Current year | January through December of the current calendar year |
| YTD | January through the current month |
You can also set a custom **Start** and **End** date using the date pickers, then click **Apply**.
***
## Display Options
The controls icon (the sliders icon, second from the right) opens two display settings that change how numbers are presented in the table.
![Forecast display options]()
### Period Over Period Change
Adds a change indicator next to each monthly value, showing how the cost layer moved compared to the prior period.
| Option | What it adds |
| ---------- | ------------------------------------------------------ |
| None | No change indicator (default) |
| Percentage | Shows the % change vs. the prior month or quarter |
| Absolute | Shows the dollar change vs. the prior month or quarter |
This is useful for finance reviews — it surfaces cost movements at a glance without having to calculate the delta manually.
### Show Cost Layer Value
Changes the numbers in the table from dollar amounts to a percentage view.
| Option | What it shows |
| ---------------------------- | ---------------------------------------------------- |
| None | Absolute cost in dollars (default) |
| As Percent of Total | Each cost layer as a share of total cloud spend |
| Percent of Parent Cost Layer | Each child cost layer as a share of its parent layer |
The percent-of-parent view is particularly useful when reviewing cost allocation — it shows how spend distributes within a layer (for example, how much of Production is Compute vs. Database vs. Data Transfer).
***
## Chart Type
The chart icon (bar chart icon, third from the right) changes the visualization above the table.
![Forecast chart type selector]()
| Option | Description |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Layers (Stacked) | Stacked bar chart — each color represents a top-level Cost Layer, and heights show total spend per period. Best for seeing total cloud spend at a glance. |
| Line (Series) | Line chart — each Cost Layer is a separate line. Best for seeing trends within individual layers over time. |
| Area (% of total) | Area chart — shows each Cost Layer as a share of total spend. Best for seeing how the cost mix is shifting over time. |
***
## Exporting Data
The download icon (rightmost button) exports the currently displayed forecast table.
![Forecast export options]()
Two formats are available:
* **Export CSV** — comma-separated file, compatible with any spreadsheet tool or data pipeline
* **Export Excel** — formatted spreadsheet, ready for sharing with your finance team
The export reflects your current view — including the selected date range, granularity, and any display options applied.
***
## Cell Detail: Month-over-Month Comparison
Clicking any **Actuals** cell in the table opens a detailed comparison panel on the right side of the screen.
![Cell detail panel — comparison metrics]()
The panel shows the selected Cost Layer compared against the prior month. Because calendar months have different numbers of days, Cloud Capital normalizes spend to a 28-day equivalent so the comparison is fair — a 31-day month with the same daily run rate won't look artificially higher than a 28-day month.
The comparison includes:
**Month header** — shows which two months are being compared, for example "February 2026 vs January 2026."
**Comparison bar** — a visual bar showing how the two months compare. The prior month is shown at full width; the current month is scaled proportionally, with the percentage change labeled.
**Daily Spend Average** — the average daily spend for each month. The prior month's value appears in parentheses, so you can see at a glance whether spending is trending up or down on a per-day basis.
**Effective Savings Rate** — the commitment savings rate for each month. This shows whether commitment coverage is improving or eroding month over month.
**Daily cost chart** — a bar chart of day-by-day amortized spend since the beginning of the comparison month. Useful for spotting specific days or events that caused cost spikes.
### Top Services Comparison
Scrolling down in the panel reveals the **Top Services Comparison** table.
![Cell detail panel — top services]()
This table lists the cloud services that contributed most to spend in this Cost Layer, showing each service's share of total cost for both months and the change between them. This is one of the fastest ways to understand *why* a cost layer moved — whether it was a specific service scaling up, a deployment that changed resource utilization, or a commitment change affecting net cost.
Cell detail is only available for **Actuals** columns. Forecast columns do not have month-over-month comparison data since they represent projected values rather than recorded spend.
# Forecasting FAQ
Source: https://docs.cloudcapital.co/forecasting/forecasting-faq
Common questions about how correlation is calculated, how to validate your forecast, and how often to keep it current.
## Correlation and Business Metrics
**How does Cloud Capital calculate correlation?**
When you connect a [Business Metric](/forecasting/business-metrics) to a Cost Layer using the Metric - Auto projection type, Cloud Capital compares the historical values of that metric against the historical actual costs for that layer. Using the overlapping data, it derives a coefficient — a number that captures how much costs tend to move for each unit change in the metric.
For example, if your Users count has grown alongside your Production costs over the past year, Cloud Capital quantifies that relationship: "For every 1 new User, costs increase by \$7.83." That coefficient is then applied forward using your forecast metric values to project future costs.
This calculation requires at least 3 months of overlapping data — historical metric values and actual cost data for the same period. The more months of overlap, the more reliable the coefficient.
***
**How do I know if the correlation has worked?**
Three signals tell you:
1. **The label in the dropdown.** When you open the Associated Business Metric dropdown in the Projection panel, each metric shows a correlation assessment. **Strong Positive Correlation** means the historical relationship is reliable and the metric is a good fit for this Cost Layer.
2. **The plain-language description.** After selecting a metric, Cloud Capital shows a sentence like *"For every 1 unit Users increases, costs increase by \$7.83."* Read it against your operational knowledge of how this Cost Layer scales. If the number feels roughly right — if losing one customer really does reduce costs by approximately that amount — the correlation is working. If it feels wildly off, consider whether a different metric or methodology is a better fit.
3. **The Projection Preview.** The chart and scenario table show exactly how the forecast would shift if you accept this metric. Compare the "Selected" line against the "Baseline" and sense-check the trajectory: does this match what you expect to happen as the metric grows?
***
**What does "Strong Positive Correlation" mean?**
It means there is a consistent, statistically meaningful relationship (|r| ≥ 0.7) between the metric's historical values and the Cost Layer's historical costs — specifically, that as the metric increases, costs tend to increase as well.
The stronger the correlation, the more confident Cloud Capital can be that changes in the metric will reliably predict changes in cost. Strong Positive Correlation is the best signal you can get — it means the metric is doing exactly the job a business metric is supposed to do.
***
**Why does my metric show "Insufficient Data"?**
Cloud Capital needs at least 3 months of overlapping data — metric values and actual costs for the same calendar months — before it can calculate a reliable correlation coefficient. A newly created metric will show Insufficient Data until that threshold is met.
Two options while you wait:
* Switch the Correlation Methodology to **Direct: 1:1**, which projects costs in exact proportion to metric changes without requiring historical overlap. Useful for new metrics or new Cost Layers where you have a strong operational reason to expect a proportional relationship.
* [Import historical metric data](/forecasting/business-metrics-import-googlesheets) via Google Sheets to backfill actuals. Once 3+ months of overlap exist, Cloud Capital will recalculate the correlation and Auto methodology will become available.
***
**Can I use different metrics for different Cost Layers?**
Yes — each Cost Layer has its own projection setting, and each can be connected to a different business metric. This is intentional: the metric that drives your production workload (customer count) is probably not the same metric that drives your data infrastructure (data volume processed) or your internal tooling (seat count).
Setting projections at the right granularity — different metrics for different layers — is where the forecast moves from a rough estimate to a model that genuinely reflects how your business works.
***
**What if I don't have any business metrics yet?**
Start with Flat or Trend projections while you set up your metrics. Those are valid starting points, and a forecast with good Cost Layer structure using Flat projections is still useful for Cloud Capital's optimization work.
Once you have even one well-defined metric — customer count is usually the easiest to start with — connect it to your most cost-significant production Cost Layer. Three months of overlapping data will unlock Auto correlation. From there, expand to additional metrics as your data matures.
***
## Validating Your Forecast
**How do I validate that my forecast is accurate?**
There is no single check — validation is a combination of sense-checks across the forecast inputs:
* **Cost Layer structure.** Does the structure reflect how Finance thinks about cloud spend? Are COGS and OpEx separated? Do the sub-layers match the products, teams, or service families that matter for reporting? A poorly structured forecast is hard to reason about, which makes it hard to validate.
* **Business metric values.** Are the Forecast row values in your business metrics aligned with what Finance is actually planning? Open each metric and compare the forecast numbers to your operating plan. If Finance is forecasting 500 customers by Q4 and your metric says 200, the forecast will be wrong regardless of how good the correlation is.
* **Projection type choices.** Does each Cost Layer have the right methodology? Production workloads with a connected metric should use Metric - Auto. Fixed infrastructure with no expected change should use Flat. A layer where you know the exact growth rate should use Fixed Percentage.
* **Engineering Initiatives.** Are upcoming infrastructure changes captured? A planned migration, a service deprecation, or a major new deployment all have real cost implications. If those are not in the forecast, the projection for the affected layers will be wrong.
* **The Projection Preview.** Before saving any change to a Cost Layer projection, check the Projection Preview. The scenario comparison table shows you the month-by-month impact. If a change produces a trajectory that surprises you, investigate before saving.
Your Cloud Capital team reviews the forecast with you in weekly, monthly, and quarterly sessions. Those reviews are the primary validation mechanism — bring questions, flag anomalies, and use the session to align Finance and Engineering on what the forecast is assuming.
***
**How often should I update my business metrics?**
Metric actuals should be updated monthly — when real data from the previous month is available, enter it. This keeps the historical dataset growing, which improves correlation quality over time.
Metric forecasts should be updated whenever your business plan changes. If Finance revises the growth plan at the end of a quarter, update the Forecast row to match. The forecast is only as forward-looking as the inputs that drive it.
A practical rhythm: review and update metrics as part of your monthly Cloud Capital review. That cadence keeps the forecast current without requiring constant attention.
***
**How often should I update my engineering initiatives?**
Update [Engineering Initiatives](/forecasting/initiatives) as soon as plans firm up — not at the end of the quarter when the work is about to start. The earlier Cloud Capital knows about a planned infrastructure change, the earlier it can reflect that change in commitment sizing.
This matters most for changes that will reduce committable spend — a migration off EC2, a service deprecation, a workload right-sizing project. If Cloud Capital purchases commitments sized against current spend and the reduction happens immediately after, the commitment may not have enough time in the optimized state to fully pay back. Leading with the initiative keeps the proposal well-timed.
If a plan changes or is cancelled, remove or update the initiative immediately. The forecast should reflect what you actually expect to happen, not what you planned six months ago.
***
**What if my forecast looks wrong?**
Work backwards through the inputs:
1. **Check the metric values** — are Actuals current, and do Forecast values match the business plan?
2. **Check the projection type** — is Metric - Auto applied to layers where you'd expect it? Is Flat applied where you'd expect costs to hold steady?
3. **Check the Cost Layer structure** — is spend allocated to the right layers? Misallocated spend produces projections that look correct in total but wrong at the layer level.
4. **Check engineering initiatives** — is a planned change already affecting actuals that hasn't been captured as an initiative?
If something still looks off after those checks, raise it in your next Cloud Capital review. The team can look at the underlying data and help identify whether the issue is in the inputs, the correlation, or the structure.
***
## Forecast and the Guaranteed Savings Rate
**How does the forecast affect my Guaranteed Savings Rate?**
The GSR Cloud Capital guarantees is calculated from your forecast. Cloud Capital uses the forecast — your Cost Layer structure, your business metrics, your engineering initiatives — to determine how much spend is committable, over what term, and with what buffer.
A more accurate forecast allows Cloud Capital to calculate the GSR more precisely and stand behind it more fully. A vague or stale forecast constrains what Cloud Capital can confidently guarantee, because the uncertainty in the inputs requires a larger safety margin in the rate.
The practical consequence: keeping your forecast current is the single most direct action you can take to maximize your guaranteed savings. It is also a requirement of your agreement — Cloud Capital can only do its best work when the inputs are complete and up to date.
***
**What happens if my actual spend diverges significantly from the forecast?**
Cloud Capital monitors actual vs forecast continuously. In your monthly and quarterly reviews, significant divergences will be surfaced and discussed. The response depends on the cause:
* **The business metric moved differently than forecast.** Update the Forecast row to reflect the revised expectation going forward. The historical data now includes the divergence, which may also improve the model's accuracy over time.
* **An engineering change happened that wasn't captured as an initiative.** Add a retroactive initiative or update Cost Layer projections to reflect the new baseline. Flag it in the next review so Cloud Capital can assess whether any commitments are affected.
* **The divergence is unexplained.** Investigate Cost Layer structure and resource mapping first — sometimes spend is being allocated to the wrong layer, which makes the forecast look wrong even when the total is accurate.
The GSR holds regardless of how actuals diverge from the forecast — that is the point of the guarantee. But keeping the forecast current reduces the likelihood that Cloud Capital has to absorb large true-up adjustments, which benefits both sides over time.
***
## Related pages
How to add metrics, what makes a good metric, and how correlation feedback works.
Trend, Fixed Percentage, Flat, and Metric - Auto explained.
Capturing planned infrastructure changes before they hit the bill.
How the GSR is calculated and what it guarantees.
# Engineering Initiatives
Source: https://docs.cloudcapital.co/forecasting/initiatives
Initiatives allow you to incorporate forward-looking business context into your forecast. They are a powerful way to represent planned changes — such as infrastructure migrations, new product launches, service deprecations, or capacity events — and have those changes reflected in your cloud cost projections before they happen.
![Add Initiative]()
***
## How Initiatives Work
Each Initiative applies a set of cost adjustments (+/- changes) to one or more Billing Periods. Cloud Capital takes the baseline forecast for the affected mapping and applies the Initiative's impact on top of it. The resulting changes are visible in the [Forecast table](forecast-controls), where Initiative-driven months show the adjusted projected spend.
A single Initiative can affect multiple mappings and include both positive and negative cost impacts — useful for representing complex projects that increase spend in one area while reducing it in another.
### Initiative Fields
**Name**
Give the Initiative a clear, descriptive name so that both your engineering and finance teams understand what it represents at a glance.
**Type**
Controls how the Initiative's impact is expressed:
* **Absolute** — a fixed dollar amount added or subtracted per Billing Period (e.g., −\$5,000/month)
* **Percentage** — a percentage of the baseline forecast to add or subtract (e.g., −25%)
The baseline the percentage applies against is determined by the [Projection Type](projection-types) set on the affected Cost Layer.
**Permanent Change**
A checkbox that controls whether the Initiative's effect persists after its active period ends.
* **Checked (Permanent)** — the final month's value repeats indefinitely. Use this for changes that permanently alter your infrastructure, such as completing a migration or decommissioning a service.
* **Unchecked (Temporary)** — effects are limited to the Initiative's active months only, then the forecast returns to baseline. Use this for one-time events such as a launch spike or seasonal capacity increase.
**Color**
A color label used to visually identify the Initiative in forecast charts and the initiatives table.
**Status**
Controls whether the Initiative is included in forecast calculations:
* **Draft** — work in progress, not yet included in the forecast
* **Committed** — active and included in the forecast
* **Completed** — the Initiative has concluded; retained for historical reference
* **Abandoned** — no longer relevant, excluded from the forecast
Only **Committed** Initiatives impact the forecast. Draft, Completed, and Abandoned Initiatives do not affect forecast calculations.
**Timeframe**
Start Month and Duration define the period during which the Initiative is active. For Temporary Initiatives, these are the only Billing Periods with impact calculated. Adjusting the Start Month shifts all months of the Initiative together.
***
## Mappings: Targeting an Initiative's Impact
Once an Initiative is created, you define *what* it affects by adding one or more **Mappings**. Click **Add Mapping** on any Initiative to choose the targeting type.
Cloud Capital supports the following mapping types:
| Mapping Type | What It Targets | Best Used For |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- |
| **Cost Layer** | An entire [Cost Layer](cost-layers) (e.g., Production, Staging) | Changes that align to a business unit or environment boundary |
| **Resource** | Specific cloud resources by attribute (service, region, instance type, etc.) — AWS and GCP resources both appear in the picker | Infrastructure migrations, right-sizing, service-level changes |
| **Account** | A specific AWS account or GCP project | Account/project-level changes or consolidations |
| **Tag** | Resources sharing a specific AWS tag or GCP label | Team- or project-level cost changes tracked via tagging |
| **Cost Category** | A custom cost category grouping | Changes aligned to custom cost categorization |
A single Initiative can have multiple Mappings — for example, a migration that reduces cost in one Cost Layer while increasing it in another.
***
## Resource Mappings
Resource mappings allow you to scope an Initiative to specific cloud resources by their attributes, rather than an entire Cost Layer. This works the same way whether the underlying resources are on AWS or GCP — both appear in the same picker. Cloud Capital automatically calculates what fraction of spend matches your resource filter and applies the Initiative's impact proportionally.
This is especially useful for:
* **Infrastructure migrations** — model the cost impact of moving off specific instance types or services
* **Right-sizing projects** — target oversized instances in specific regions without restructuring your Cost Layer taxonomy
* **Cross-cutting optimizations** — apply a single Initiative across multiple Cost Layers where the same resource type exists
You can filter by any combination of the following dimensions:
| Dimension | Description | Example Values |
| ------------------- | ---------------------------------- | -------------------------------------------------------- |
| **Service** | The cloud service (AWS or GCP) | Amazon RDS, Amazon EC2, Google Compute Engine, Cloud SQL |
| **Resource Family** | Broad resource type grouping | Database, Compute, Storage |
| **Region** | Geographic region (AWS or GCP) | `eu-west-1`, `us-east-1`, `europe-west1` |
| **Instance Type** | Specific instance or resource type | `t3.large`, `db.r5.2xlarge`, `e2-standard-4` |
| **Usage Type** | AWS usage type code | `EU-RDS:db.t3.large` |
**Usage Type** is an AWS-specific billing dimension with no direct GCP equivalent — for GCP resources, use **Service**, **Resource Family**, and **Instance Type** to scope your filter instead.
Multiple filter conditions are combined with AND logic — all conditions must match for a resource's spend to be included.
You can also combine a Resource mapping with a Cost Layer mapping on the same Initiative. This scopes the Initiative to matching resources *within* that specific Cost Layer, giving you both business context and technical precision.
**Example (AWS):** Production Cost Layer + Resource mapping for RDS `t3.large` in `eu-west-1` → targets only those specific RDS instances within Production, leaving all other Production resources and other environments unaffected.
**Example (GCP):** Non-Production Cost Layer + Resource mapping for Compute Engine `e2-standard-4` in `europe-west1` → targets only those specific Compute Engine instances within Non-Production, leaving everything else unaffected.
Resource filter values are drawn from your actual cloud cost data — AWS, GCP, or both, depending on which integrations you've connected. The picker shows only values present in your imported cost history, sorted by spend impact (highest first).
***
## Creating a Resource-Based Initiative
Navigate to **Initiatives** and click **+ New Initiative**. Provide a descriptive name, select the Type (Absolute or Percentage), and check **Permanent Change** if the effect should persist after the active period ends. Choose a color to identify the Initiative in charts, then click **Create Initiative**. The remaining steps are completed by editing the newly created Initiative row. To edit or delete an Initiative at any time, click the three-dot menu on its row and select **Edit** or **Delete**.
![Edit Initiative]()
Click **Add Mapping** on the Initiative row and select **Resource**. Use the dimension picker to build your filter — choose the dimensions relevant to your project (service, region, instance type, etc.) and select the applicable values. Add multiple conditions as needed; all conditions are combined with AND logic.
If you want to limit the Initiative to a specific Cost Layer, click **Add Mapping** again and select **Cost Layer**. Combined with your Resource mapping, this scopes the Initiative to matching resources within that Cost Layer only.
Enter the impact value for each Billing Period in the Initiative's active months. If you chose **Percentage**, enter a number representing the percentage change — for example, **30** to add 30%, or **−30** to reduce by 30%. The application will automatically apply that percentage to the actual spend matching your mapping filter and calculate the dollar impact for you — no manual calculation needed. If you chose **Absolute**, enter a positive or negative dollar amount — for example, **5000** to add \$5,000, or **−5000** to reduce by \$5,000.
Mark the Initiative as **Committed** to include it in your forecast. The forecast will immediately reflect the projected impact.
***
## Examples
Any planned change with an impact on your cloud costs can be represented as an Initiative:
| Scenario | Type | Permanent Change | Mapping |
| ------------------------------------------ | ------------------------------------------------------------- | ---------------- | ---------------------- |
| Deprecate a service | Absolute, negative — equal to the monthly cost of the service | Yes | Cost Layer or Resource |
| New product launch | Percentage, positive — estimated growth rate | Yes | Cost Layer |
| One-time load event (e.g., seasonal spike) | Percentage, positive | No | Cost Layer |
| Infrastructure migration (phased) | Percentage, negative — step-down each month as workloads move | Yes | Resource |
| Right-sizing specific instance types | Percentage, negative | Yes | Resource |
***
## Example Walkthrough: RDS PostgreSQL Migration off t3.large
The following example shows how to model a phased migration of RDS PostgreSQL instances away from `t3.large` in the `eu-west-1` region, where each month another quarter of the instances are replaced until the migration is complete. The same walkthrough applies equally to a GCP migration (e.g., moving off a Compute Engine or Cloud SQL instance type) — only the Resource Mapping values in Step 2 would change.
**Scenario:** Your engineering team is migrating Production RDS PostgreSQL workloads in EU West 1 off `t3.large` instances over four months (May through August 2026). Each month roughly another quarter of the instances are migrated to more cost-effective alternatives, so the cost reduction accumulates month by month until fully complete.
### Step 1 — Create the Initiative
Click **+ New Initiative** and fill in the following:
| Field | Value |
| -------------------- | ---------------------------------------------------------------------------------------- |
| **Name** | RDS PostgreSQL t3.large Migration — EU West 1 |
| **Type** | Percentage |
| **Permanent Change** | Checked *(migration is complete after August; the cost reduction persists indefinitely)* |
| **Color** | Your choice |
### Step 2 — Add a Resource Mapping
Click **Add Mapping** and select **Resource**. Configure the following dimensions to scope the Initiative to the affected infrastructure:
| Dimension | Value |
| ----------------- | ----------- |
| **Service** | Amazon RDS |
| **Instance Type** | `t3.large` |
| **Region** | `eu-west-1` |
### Step 3 — Add a Cost Layer Mapping
Click **Add Mapping** and select **Cost Layer**, then choose **Production**. This ensures the Initiative applies only to Production RDS costs — Non-Production and other environments are unaffected.
### Step 4 — Set Monthly Impact Values
Each month represents cumulative migration progress. By August, all targeted `t3.large` instances have been replaced and their spend is fully eliminated:
| Billing Period | Percentage Impact | What It Represents |
| -------------- | ----------------- | ------------------------------------------------------ |
| May 2026 | −25% | First quarter of instances migrated |
| June 2026 | −50% | Half of instances migrated |
| July 2026 | −75% | Three quarters of instances migrated |
| August 2026 | −100% | Migration complete — all t3.large RDS spend eliminated |
Because **Permanent Change** is checked, the −100% reduction from August carries forward indefinitely in the forecast, reflecting that the migration is a lasting infrastructure change.
### Step 5 — Set Status to Committed
Mark the Initiative as **Committed**. Your forecast will now show the progressive reduction in Production RDS costs in `eu-west-1` across the migration timeline, giving both your engineering and finance teams a shared, data-grounded view of when the savings will materialize.
# Forecasting Overview
Source: https://docs.cloudcapital.co/forecasting/overview
How Cloud Capital builds a forward-looking model of your cloud spend — and why the quality of that model determines the quality of your savings.
A Cloud Capital forecast is not a simple projection of last month's bill into the future. It is a structured financial model of your cloud spend — one that reflects your business structure, responds to your growth plans, and captures the engineering changes your team already knows are coming.
The quality of that model determines everything downstream: how accurately Cloud Capital can size commitments, how precisely the [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate) can be calculated, and how confidently your finance team can plan. A well-built forecast turns cloud spend from a reactive line item into a forward-looking input to your business.
***
## What can go wrong without one
Cloud costs move fast, and the consequences of a poor or missing forecast tend to surface at the worst possible moments.
**Over-commitment from a stale baseline.** A company commits to three years of Reserved Instances based on current EC2 spend. Six months later, the engineering team migrates a core service to containers. The RI coverage no longer matches the workload — and the company is locked into paying for capacity it no longer uses. AWS does offer a Reserved Instance Marketplace where unused commitments can be listed for sale, but it is not a reliable exit: listings may take weeks or months to sell, there is no guarantee of a buyer, and selling typically means accepting a discount on the remaining value. For most companies, an unwanted multi-year commitment is effectively a sunk cost.
**Under-commitment from excessive caution.** Without a forecast grounded in business growth, the risk of over-committing feels high and commitments are sized conservatively. A year later the business has grown 40%, on-demand rates have applied to most of that growth, and the difference — hundreds of thousands of dollars — was simply left on the table.
**Finance and Engineering out of sync.** Engineering completes a major infrastructure migration that reduces costs by 30%. Finance, unaware it was happening, had already signed off on a budget based on the old spend level. When the bill comes in lower, it looks like a planning failure rather than an engineering win — and the savings aren't captured in next year's targets.
**Commitment proposals built on the wrong signal.** Without a forecast that reflects real business context, any commitment recommendation is sized against what has already happened — not where the business is actually going.
***
## How native cloud recommendations compare
Your cloud provider offers its own commitment recommendations — AWS surfaces Savings Plans and Reserved Instance suggestions directly in its console, and GCP surfaces Committed Use Discount recommendations through its Recommender. These are useful as a starting point, but they are built entirely on your historical usage patterns. Native recommendations look backward.
That works reasonably well for workloads that are stable and mature — infrastructure that runs at roughly the same level month after month. It breaks down quickly for businesses that are growing, changing, or planning ahead.
Native recommendations have no visibility into your business plan. They cannot know that you are launching in a new market next quarter, that you are planning to migrate off EC2 in Q3, or that an engineering initiative will reduce your RDS spend by 40% over the next six months. They cannot distinguish between production workloads that scale with revenue and non-production environments that should stay flat. Every commitment proposal they surface is a backward-looking guess applied to a forward-looking question.
The practical consequences:
* Growing businesses routinely get under-commitment recommendations because recent usage is lower than future usage will be — native recommendations have no way to account for planned growth.
* Businesses with planned infrastructure changes get proposals that ignore those changes entirely, creating commitment mismatches that only surface after the workload moves.
* Finance and engineering are not in the picture at all. The recommendation comes from a usage graph, not from the people who understand where the business is going.
Cloud Capital's approach is different by design. The forecast integrates your business structure, your growth assumptions, and your engineering plans before a single commitment is proposed. Commitments are sized against your actual future — not just your recent past.
***
## What good forecasting enables
**Commitments sized to your actual trajectory — without the risk paralysis.** Most companies under-commit, or avoid committing altogether, because the downside of getting it wrong feels too large to absorb. The risk analysis, the sizing decisions, the exposure if conditions shift — Cloud Capital takes that on. Your job is to keep the forecast current: maintain your business metrics, keep engineering initiatives up to date, and reflect your real business structure in your Cost Layers. Cloud Capital does the rest, and the [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate) is what you get in return — maximum savings, with the risk carried by Cloud Capital, not your finance team.
**A Guaranteed Savings Rate that holds.** The GSR is a certainty your finance team can count on in a world where almost everything else about cloud costs is variable. It is not a target or an estimate — it is a rate Cloud Capital calculates based on your forecast and stands behind. Your business metrics and engineering initiatives are the inputs that make that calculation precise. Even if conditions change — growth accelerates, a migration completes ahead of schedule, a new product launches — the GSR holds. That stability is what makes it useful as a planning number.
**No surprises at budget time.** A live forecast that incorporates your business metrics means finance teams see cost changes coming before they hit the bill. A product launch, a new market expansion, a planned migration — all of these affect cloud spend, and all of them can be modelled in advance.
**Engineering initiatives that are financially visible.** When planned infrastructure changes are captured as [Engineering Initiatives](/forecasting/initiatives), finance sees the cost impact before it materialises. Migrations, deprecations, and new service launches become part of the financial plan rather than surprises in the next invoice.
**A shared model for two teams that need to work together.** Cloud spend sits at the intersection of Engineering decisions and Finance accountability. A well-structured forecast gives both teams a common reference point — the same numbers, the same assumptions, the same model. That alignment is what makes budget conversations productive instead of contentious, and it is what enables Cloud Capital to do its best work on your behalf.
***
## How a forecast is built
Cloud Capital's forecast is built from four inputs, applied in sequence. Each layer adds signal that makes the overall model more accurate and the resulting savings more optimised.
### 1. Cost Layers — your business structure
[Cost Layers](/forecasting/cost-layers) are how you map your cloud infrastructure to the categories your finance team actually uses. Production vs. Non-Production at the minimum — COGS vs. OpEx in financial terms. Sub-layers beneath them reflect products, teams, regions, or service families wherever that granularity matters.
The Cost Layer structure is the skeleton of your forecast. Everything else — metrics, projections, initiatives — operates within it. A flat, undifferentiated structure produces a flat, undifferentiated forecast. Granularity here pays dividends across every downstream use.
### 2. Business Metrics — your growth signal
[Business Metrics](/forecasting/business-metrics) are external datasets — customer count, active users, revenue, transactions — that correlate with your cloud spend. When a business metric is connected to a Cost Layer, Cloud Capital uses the relationship between historical metric values and historical cost to project how costs will move as the metric changes.
This is the step that connects your cloud forecast to your business plan. Instead of extrapolating from a cost trend, Cloud Capital projects from the thing that actually drives the cost: how many customers you expect to serve, how much revenue you are forecasting, how fast your user base is growing. Finance already has this data. Connecting it to the forecast means both teams are working from the same assumptions — and Cloud Capital has the signal it needs to size commitments against your real future.
### 3. Projection Types — your methodology per layer
Every Cost Layer has a [projection type](/forecasting/projection-types) that controls how its future spend is calculated. The four options — Trend, Fixed Percentage, Flat, and Metric-Auto — are not one-size-fits-all. Production workloads tied to customer growth should use Metric-Auto. Fixed infrastructure with no expected change should use Flat. A planned expansion at a known rate should use Fixed Percentage.
Choosing the right methodology per layer is where the forecast moves from plausible to precise. A single projection applied to everything is better than nothing — but it will always be wrong for most layers.
### 4. Engineering Initiatives — your planned changes
[Engineering Initiatives](/forecasting/initiatives) capture the changes your engineering team already knows are coming: service migrations, product deprecations, new deployments, right-sizing projects. These have real cost implications that a pure extrapolation of past spend will miss entirely — and they are precisely the information native cloud recommendation tools have no access to.
Initiatives let engineering teams quantify their plans in financial terms, and let finance teams see those plans before they hit the bill. A permanent reduction modelled as an Initiative becomes a saving in the forecast — not a surprise in retrospect. It also becomes an input to the GSR calculation, allowing Cloud Capital to size commitments with confidence that accounts for what is about to change.
***
## Who does what
A good forecast is a collaboration. The two teams that need to be in sync are Finance and Engineering — and the forecast is the shared artefact that keeps them that way.
**Finance defines the structure.** Cost Layers should reflect how finance thinks about cloud spend — which costs are COGS, which are OpEx, which product lines or business units matter for reporting. Business Metrics come from finance: the growth assumptions and operating plans that are already being used for budgeting.
**Engineering populates the detail.** Resource mapping assigns actual cloud spend to the Cost Layer structure finance has defined. Engineering Initiatives capture forward-looking changes that only the engineering team knows about. Without this input, the forecast is accurate for the past and blind to the future.
**Cloud Capital optimises from the result — and facilitates the conversation.** The commitment proposals, GSR calculations, and savings analyses Cloud Capital produces are all downstream of the forecast. But Cloud Capital's role is not just to run the numbers. The application itself — and the weekly, monthly, and [quarterly reviews](/optimization/qbr) with your Cloud Capital team — are the mechanism through which Finance and Engineering inputs are brought together, kept current, and acted on. Those reviews are not just reporting sessions; they are the cadence that keeps the forecast alive and the savings compounding. When the forecast is complete and current, Cloud Capital can propose the right commitments, at the right size, at the right time, and stand fully behind the savings rate it guarantees.
The Guaranteed Savings Rate Cloud Capital offers is calculated from your forecast. The more accurately your forecast reflects your real business trajectory — through solid Cost Layer structure, connected business metrics, and up-to-date engineering initiatives — the more precisely that rate can be calculated and the more fully Cloud Capital can stand behind it. Keeping your forecast current is the single most impactful thing you can do to maximise your savings.
***
## Where to start
Map your cloud spend to your business structure. The foundation everything else is built on.
Connect your growth data to your forecast so costs move with your business plan.
Choose the right forecasting methodology for each Cost Layer.
Model planned infrastructure changes before they hit the bill.
# Projection Types
Source: https://docs.cloudcapital.co/forecasting/projection-types
How to set the projection methodology for each Cost Layer, and when to use Trend, Fixed Percentage, Flat, or Metric - Auto.
The projection methodology you choose for each Cost Layer directly determines how Cloud Capital forecasts future spend. A well-configured projection gives your finance team a reliable view of where costs are heading — and gives Cloud Capital the signal it needs to surface accurate optimization opportunities.
## Opening the Cost Layer Projection Panel
In the Forecast table, each row includes a **Projection** column. Click any projection indicator (for example, **Flat**) to open the Cost Layer Projection panel for that layer.
![Cost Layer Projection panel]()
The panel shows:
* The Cost Layer you are editing (for example, **Production (COGS)**)
* Four projection type buttons to choose from
* A **Projection Preview** at the bottom showing how your selection will affect the next 6 months of forecast, compared against the current baseline
Hover over any projection type button (without clicking) to see a mini chart and short description of how that methodology works. Click to select it and update the preview.
***
## Projection Types
### Trend
![Trend hover description]()
**How it works:** Cloud Capital extrapolates the historical cost trend from your recent actuals forward into the forecast. If spending has been rising or falling consistently, the Trend projection continues that trajectory.
![Trend projection preview]()
**When to use it:** Use Trend when a Cost Layer's growth pattern is driven by organic factors — gradual scaling, increasing usage over time — and you expect that pattern to continue. It is less reliable for layers with highly variable or seasonal spend, or when a recent spike or anomaly would distort the trend line.
***
### Fixed Percentage
![Fixed Percentage hover description]()
**How it works:** The Cost Layer grows by a fixed percentage you specify each period (month or quarter), compounding indefinitely. When you select this type, a **Fixed Growth Rate** field appears — enter the percentage rate the layer will change each period.
![Fixed Percentage projection preview]()
**When to use it:** Use Fixed Percentage when you have a known growth rate — for example, a contractual commitment, a planned infrastructure expansion at a defined rate, or a business assumption provided by finance. A negative percentage models planned reductions (for example, -10% per month during a cost-reduction initiative).
***
### Flat
![Flat hover description]()
**How it works:** Future spend is projected equal to the most recent billing period, with no growth. Day-count differences between months are accounted for automatically.
![Flat projection preview]()
**When to use it:** Flat is the default for all Cost Layers and is a safe starting point before you have enough history or business metric data to use a more sophisticated methodology. It is also the right choice for truly fixed infrastructure — reserved capacity, fixed SaaS contracts, or pre-production environments where spend does not scale with business activity.
When insufficient data is available for a more advanced projection type, Cloud Capital will fall back to Flat automatically. You will see a notice in the panel when this applies.
***
### Metric - Auto
![Metric - Auto hover description]()
**How it works:** Future spend is projected based on a [Business Metric](business-metrics) you have defined (for example, customer count, active users, or revenue). Cloud Capital correlates your historical cost data against the metric's historical values to infer how costs move relative to the metric — then uses the metric's projected future values to drive the cost forecast forward.
![Metric - Auto projection preview]()
**When to use it:** This is the most powerful projection type for layers where business growth directly drives cloud cost — typically production workloads, data pipelines, or customer-facing services. A well-correlated business metric makes your forecast dynamically responsive to changes in your business plan rather than relying on static assumptions.
**This is Cloud Capital's recommended projection type** for any Cost Layer with a meaningful business metric. We're actively gathering feedback on correlation quality — if the inferred correlation doesn't look right for your data, let us know.
#### Correlation Methodology
When Metric - Auto is selected, you also choose how the metric is applied:
| Option | How it works |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Auto** (recommended) | Cloud Capital infers the correlation coefficient from your historical data. If costs scale at 0.6× the rate of the metric, the model captures that ratio rather than assuming 1:1. Requires 3+ months of overlapping actuals and metric data. |
| **Direct: 1:1** | Metric percentage changes are applied directly to costs at a 1:1 ratio. No historical data is required — useful when you are launching a new Cost Layer or metric without enough history for Auto correlation. |
![Direct 1:1 correlation selected]()
#### Insufficient Data
If your business metric does not yet have 3 or more months of overlapping data with the Cost Layer's actuals, you will see:
> *Insufficient data to calculate cost impact. Requires 3+ months of overlapping data.*
In this case, Cloud Capital falls back to a Flat projection until enough data accumulates. You can accelerate this by [importing historical metric data](business-metrics-import-googlesheets) or switching to **Direct: 1:1** correlation, which works without historical overlap.
***
## Setting Projections at Different Levels
You can set a projection at any level of your Cost Layer hierarchy.
* **Setting a projection on a parent layer** (for example, Production) applies that methodology to all child layers that do not have their own projection set. Children inherit the parent's selection.
* **Setting a projection on a child layer** overrides the parent for that specific layer only. Layers above it aggregate the children's individual projections.
This means you can use a simple Flat projection at the top level as a default, and then dial in more precise Metric - Auto projections for specific sub-layers where you have good business metric coverage — giving you granular control exactly where it matters.
For best forecast accuracy, configure projections at the most granular level where you have reliable data or business assumptions. The more precisely each Cost Layer is projected, the more actionable the forecast becomes for your finance team and for Cloud Capital's optimization recommendations.
# Auto-Mapping: Guided Cost Allocation Setup
Source: https://docs.cloudcapital.co/get-started/auto-mapping
How the Help me map wizard automatically categorizes your accounts and services into cost layers — and how to get the best results from it.
Manually mapping every account and service combination to cost layers is tedious, especially in environments with many cloud accounts or projects. The **Help me map** wizard automates 80–90% of this setup by analysing your account names and applying a curated service classification library — getting you to a working cost layer structure in minutes rather than hours.
Everything the wizard creates is **non-destructive and editable** — you review all mappings on the Sankey diagram before saving anything.
The wizard is part of the Cost Allocation setup flow. For an overview of the canvas, manual mapping, and toolbar controls, see [Cloud Resource Mapping](/get-started/map-cloud-resources).
***
## Step 1 — Categorize your accounts
The wizard auto-categorizes each cloud account based on its name using keyword matching. Each account is assigned to one of these categories:
| Category | Cost Layer | Production? | Example account names |
| --------------------- | -------------------------------- | ------------- | ------------------------------------------------ |
| Production | Production (COGS) | Yes | `prod-api`, `workload-us-east`, `live-services` |
| Development | Development (Non-Prod) | No | `dev-team-alpha`, `sandbox-experiments` |
| Testing | Testing (Non-Prod) | No | `qa-regression`, `uat-environment` |
| Staging | Staging (Non-Prod) | No | `staging-v2`, `pre-prod-us-west` |
| Security & Operations | Security & Operations (Non-Prod) | No | `audit-logs`, `security-hub`, `infra-management` |
| Support | Support (Non-Prod) | No | `support-services` |
| Not Sure | Production (COGS) | Yes (default) | Accounts that don't match any pattern |
The production vs. non-production distinction is fundamental to financial reporting. Production costs map to **COGS (Cost of Goods Sold)**, while non-production costs are **OpEx** — and your forecast, savings analysis, and commitment proposals are all built on that structure.
**"Not Sure" defaults to Production.** This is a deliberate conservative choice — it's better to over-allocate to COGS (which you'll refine) than to hide production costs in a non-production bucket.
The keyword matching is designed around common naming conventions — AWS Control Tower and Landing Zone patterns, GCP's folder and project naming conventions, and common SDLC patterns shared across both. Keywords are checked in a specific order so that terms like `preprod` match Staging (not Production) and `devops` matches Security & Operations (not Development).
**Review before proceeding** — the wizard shows a summary of how many accounts fall into each category. Pay special attention to "shared services" or "infrastructure" accounts — these default to Security & Operations but may contain production workloads. Accounts with ambiguous names (numeric IDs, single words) default to Production; renaming those in your cloud console improves auto-detection accuracy in future runs.
***
## Step 2 — Organize production accounts
This step only appears when **2 or more accounts** are categorised as Production (or "Not Sure"). With a single production account, the wizard skips it.
You can create **sub-layers** under the Production cost layer to organise production accounts by business line, product, or team. For example:
* **Core Product** — main customer-facing application
* **Data Pipeline** — ETL, analytics, ML infrastructure
* **Internal Tools** — admin dashboards, internal APIs
Each production account can then be assigned to a sub-layer, or left on Production directly. Sub-layers enable per-product-line cost tracking — essential if you price or forecast revenue for different products independently. Without sub-layers, all production spend pools together, making it harder to answer "how much does Product X cost to run?"
This step is optional. Skip it if all your production accounts serve a single product — you can always add sub-layers later via the [Cost Layers](/forecasting/cost-layers) management page.
***
## Step 3 — Service cost breakdown
Choose whether to split production accounts by cloud service and auto-group them into service categories.
**Production service categories (under Production / COGS):**
| Category | What it covers | Example services |
| --------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------ |
| Compute | Runtimes, containers, workflow engines | EC2, ECS, Lambda, EKS, Fargate, Compute Engine, GKE, Cloud Run, Cloud Functions |
| Database & Storage | Databases, warehouses, object storage | RDS, S3, DynamoDB, Redshift, ElastiCache, Cloud SQL, BigQuery, Cloud Storage, Memorystore |
| Networking & Delivery | Network, CDN, DNS, messaging, APIs | CloudFront, ELB, Route 53, API Gateway, SNS, Cloud Load Balancing, Cloud DNS, Cloud CDN, Pub/Sub |
| AI & Analytics | ML/AI, BI, data processing, streaming | SageMaker, Bedrock, Kinesis, Glue, MSK, Vertex AI, Dataflow, Dataproc |
**Non-production service categories (under Non-Production / OpEx):**
| Category | What it covers | Example services |
| --------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------ |
| Security & Operations | Monitoring, security, compliance, CI/CD | CloudWatch, GuardDuty, Config, CodeBuild, Cloud Monitoring, Security Command Center, Cloud Build |
| Support | Cloud provider support plans | AWS Business/Enterprise Support, GCP Enhanced/Premium Support |
**Why do Security & Operations and Support go under Non-Production?** Even when these services run in a production account, they represent operational overhead — not direct cost of delivering your product. Keeping them under OpEx produces cleaner COGS metrics and more accurate gross margin calculations.
You also choose **which parent cost layers** receive service categories. By default it's the top-level Production layer, but you can multi-select — including any sub-layers created in Step 2.
**Two options:**
* **Yes, group by service** — best for organisations that want visibility into what infrastructure types drive costs. Useful for engineering leaders optimising specific areas.
* **No, keep it simple** — best if you just need the Production vs. Non-Production split. Sufficient for high-level financial reporting and easier to manage.
The service classification covers hundreds of AWS and GCP services, including popular Marketplace vendors (Datadog, Snowflake, MongoDB, and others). Services outside the classification library land in an "All Other" bucket that you can manually sort afterwards.
***
## What happens when you apply
When you click **Apply mapping**, the wizard:
1. Creates service category cost layers (Compute, Database & Storage, etc.) under the selected parent layers
2. Creates any production sub-layers you defined in Step 2
3. Assigns non-production accounts to their category layer; production accounts go to their sub-layer or the production pool
4. Splits production accounts by service (if enabled) and auto-assigns each to its category
5. Reports what percentage of services were successfully auto-mapped
After applying, you review the full mapping on the Sankey diagram. **Nothing is saved until you click Save Changes in the toolbar.** You can adjust any mapping, reassign services, or click **Undo to Saved** to reverse the wizard entirely.
***
## Auto-mapping individual nodes
Even after the wizard completes, you can apply auto-mapping to a single node without rerunning the whole wizard. Click any node in the Sankey diagram to open its popup — the options depend on whether the node is already assigned:
* **Unassigned nodes** show a **Magic Assign this node** option, which runs the same classification engine as the wizard on just that node.
* **Already-assigned nodes** show a **Split by service** option instead, which breaks the node down into service categories beneath its current cost layer.
This is useful for:
* Accounts or services that were mapped manually rather than through the wizard
* Applying service breakdowns to new accounts added after the initial setup
* Refining specific sub-layers with more granular service visibility
For unallocated spend that doesn't sort cleanly by service — a grouped "N small items" bucket, or an entire linked account — the same node popup also offers **Split by dimension...**, which can break spend down by region, tag, or any other cloud dimension instead, at any level of the canvas. See [Cloud Resource Mapping](/get-started/map-cloud-resources#i’ll-do-it-myself-manual) for the full breakdown of node popup states and this feature.
***
## Best practices
1. **Start with Help me map** — even if you plan to customise heavily, the wizard creates a solid foundation in minutes
2. **Review before saving** — verify account categorisations match your organisational structure before clicking Save
3. **Default "Not Sure" to Production** — this is intentional; review and reclassify rather than risk missing production costs
4. **Use sub-layers for multi-product organisations** — if you have distinct product lines with independent P\&Ls, sub-layers make cost tracking far more useful
5. **Enable service grouping** — the extra visibility into Compute vs. Database vs. Networking costs is valuable for both engineering optimisation and finance reporting
6. **Iterate** — auto-mapping gets you 80–90% of the way; use the Sankey diagram to refine the rest
7. **Name your accounts well** — following common cloud naming conventions (AWS Control Tower/Landing Zone patterns, or GCP's folder and project naming conventions) significantly improves auto-categorisation accuracy
***
Canvas overview, manual mapping, and toolbar reference.
Add sub-layers, reassign services, and manage your structure over time.
# Onboarding via AWS Billing Transfer
Source: https://docs.cloudcapital.co/get-started/aws-billing-transfer
## Overview
Cloud Capital uses [AWS Billing Transfer](https://aws.amazon.com/blogs/aws/new-aws-billing-transfer-for-centrally-managing-aws-billing-and-costs-across-multiple-organizations/) to take responsibility for your AWS invoices while you keep full control of your AWS Organizations, accounts, infrastructure and security. This allows you to access discounts, improve visibility, and remove operational overhead without changing how your AWS environment is structured or managed.
Billing Transfer is a native AWS feature used by partners and customers to simplify billing and access better commercial terms, without impacting how their AWS environment operates day-to-day.
***We use this AWS native mechanism so that:***
* Your AWS environment, Organizations structure, IAM, SCPs and root accounts stay owned and operated by you.
* Cloud Capital only assumes responsibility for billing, discounts and payments on your behalf as a Certified AWS Advanced Partner, reseller.
This page explains how AWS Billing Transfer works with Cloud Capital, what changes, what does not, and how we handle common concerns around control, tax, discounts, security, exit and operational risk.
## How AWS Billing Transfer works
*At a high level:*
* Cloud Capital's AWS management account (the bill-transfer account) sends a billing transfer invitation to your AWS Organizations management account (the bill-source account)
* Your AWS Administrator, with Organizations permissions, can accept the invite. When you accept this invite, Cloud Capital becomes responsible for managing and paying the consolidated bill for your Organization from the agreed start month onwards. This invite is sent after all of the proper documents sent by Cloud Capital have been signed by your team.
*From AWS's perspective:*
* Only the **billing** moves to Cloud Capital.
* **Your AWS environment continues to operate exactly as before.** Your workloads, accounts, data, services, Reserved Instance commitments and Savings Plans all remain in your own Organization.
* **Your relationship with AWS remains unchanged**. You continue to work directly with your AWS account team, support, and services as you do today.
* For more detail, see the [AWS documentation on billing transfer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/orgs_transfer_billing.html).
## What changes versus what stays the same
## 1. Billing and payments
***What changes***
* Once Billing Transfer is active, you will receive your AWS usage invoices from Cloud Capital, with the contracted discounts and benefits under our agreement. You will no longer receive invoices directly from AWS. Any invoices issued to you prior to Billing Transfer must be settled directly with AWS.
* All payment terms, currency, and payment method will be as set out in the Order Form with Cloud Capital.
* Cloud Capital receives the AWS invoice(s) for your transferred Organization from the transfer start date onwards and pays AWS directly.
* Cloud Capital can view the billing and cost data AWS exposes to the bill-transfer account (for example Cost Explorer, CUR, Budgets, Bills), in order to calculate your discount and produce your invoice.
***What stays the same***
* Billing Transfer does not move or migrate any AWS accounts.
* Billing Transfer does not change which account is the management account for your AWS Organization.
## 2. Infrastructure, security and access
***What changes***
* Cloud Capital’s visibility is limited to the billing data AWS exposes to the bill-transfer account. Billing Transfer itself does not change infrastructure or security access.
* Historical cost data in AWS billing views is reset as part of the transfer, so earlier data may no longer show in Cost Explorer after the switch. Importantly, no data is lost - Cloud Capital preserves and backfills your full cost history in your own S3 bucket and within our Forecasting platform for ongoing reporting and analysis. If you need a longer (3 year) cost history, you may need to open an [AWS Support case to have them backfill the CUR data](/get-started/aws-cur-backfill).
* **AWS Cost Anomaly Detection is not supported for bill-source accounts** — this is an AWS limitation that applies after any Billing Transfer, regardless of partner. Existing monitors and any newly created monitors will not generate alerts. AWS Budgets and budget alerts continue to work as new cost data accumulates (typically reliable after 36–60 days of fresh data). See [AWS Cost Anomaly Detection](#aws-cost-anomaly-detection) in the FAQ below for alternatives.
***What stays the same***
* Billing Transfer does not grant Cloud Capital any infrastructure-level or security-level control within your AWS environment.
* Cloud Capital cannot access, create, modify, or delete any AWS resources in your accounts.
* Cloud Capital cannot change your AWS Organizations structure.
## Onboarding flow with Cloud Capital
1. **Prepare**: You and Cloud Capital agree the target start month, and we review your existing setup, discounts, PPAs, SPs/RIs and Marketplace usage. We handle the backfill of your historical cost data as part of onboarding. If extended history (up to 3 years) is required, this can be requested via [AWS Support request for a CUR backfill](/get-started/aws-cur-backfill).
**IAM policy check required before accepting the invitation.** AWS accounts
created before March 6, 2023 commonly have legacy `aws-portal:*` billing IAM
actions that block Billing Transfer from being enabled. Use the AWS Bulk
Policy Migrator (5–15 min) to identify and update any affected policies in
your management account and member accounts before proceeding.
[Check and migrate legacy IAM billing policies →](/get-started/aws-fine-grained-access-check)
2. **Invitation**: You receive a Billing Transfer invitation from Cloud Capital in your AWS Organizations management account, specifying the start month and pricing configuration.
3. **Accept**: Your management account administrator reviews the details and accepts the invitation in the AWS console.
4. **Go live**: From 00:00 UTC on the first day of the agreed month, Cloud Capital becomes responsible for the consolidated bill for your Organization.
5. **Operate**: You continue to run your AWS environment as before. You receive Cloud Capital invoices with the contracted discounts and benefits under our agreement.
## Common questions
### 1. Control and lock-in
* You retain full control of your AWS Organizations, accounts, IAM and infrastructure
* Billing Transfer does not give Cloud Capital management or root access
* Billing Transfer can be reversed at any time directly within AWS
### 2. Security and data access
* Cloud Capital only receives billing data (e.g. cost and usage data, tags, account metadata)
* We do not access application data, workloads or logs
* Any additional access is optional and read-only
### 3. Discounts and commitments
* Billing Transfer does not change how your workloads run or how AWS services are used
* Existing commitments (SPs, RIs, PPAs) continue to apply
* We work with you and AWS to optimize future commitments and reduce risk
### 4. Tax and invoicing
* Cloud Capital becomes the billing entity and seller of record for AWS usage
* Invoicing, currency and tax treatment are configured during onboarding
### 5. Data and reporting
* No historical data is lost — it is preserved and backfilled by Cloud Capital
* Cost Explorer and AWS Budgets continue to work for ongoing usage as new cost data accumulates
* AWS Cost Anomaly Detection is disabled after Billing Transfer (an AWS limitation) — see [below](#aws-cost-anomaly-detection) for alternatives
* Full data export is available if you ever leave
### 6. AWS Cost Anomaly Detection
AWS Cost Anomaly Detection (CAD) is not supported for bill-source accounts — this is an AWS-imposed limitation that applies after any Billing Transfer. Existing monitors stop generating alerts immediately, and new monitors created after the transfer will not alert either. This cannot be resolved through reconfiguration.
**Alternatives that cover most use cases:**
**AWS Budgets** — AWS Budgets and budget alerts continue to work after Billing Transfer and are often a good direct replacement. They operate on your pro forma cost data (the discounted rates Cloud Capital configures on your behalf). If you had budgets previously set against undiscounted AWS pricing, you may want to revisit the thresholds downward to reflect your new effective rates. Budgets become most reliable once 36–60 days of fresh post-transfer data has accumulated.
**Cloud Capital + Claude** — if you use Claude Desktop with the [Cloud Capital MCP](/ai/mcp-server) connected, you can ask Claude to check your spend against any condition you care about — service, tag, account, time period — and have it create or update a Cloud Capital alert on your behalf. This works well for custom anomaly-style checks that AWS Budgets thresholds can't easily express (for example, watching a specific tag combination or a ratio between two services). You can set up a recurring check to run daily or on whatever cadence makes sense.
**Neither works for your use case?** We'd love to understand what you were using Cost Anomaly Detection for specifically — some patterns have solutions we can help set up, and others are good candidates for new Cloud Capital features. Reach out to your Cloud Capital contact or [support@cloudcapital.co](mailto:support@cloudcapital.co) with a description of what you were monitoring.
### 7. AWS relationship and support
* You retain your direct relationship with AWS, including your account team and support
* You continue to work with AWS exactly as you do today
* Cloud Capital works alongside AWS, often in partnership with your AWS team
## Summary
Using AWS Billing Transfer with Cloud Capital lets you:
* Keep full control over your AWS Organizations, accounts and security
* Move billing, discounts and payment operations to a specialist partner
* Gain richer visibility into past and future cloud spend through our analytics and forecasting platform
* Maintain a clear, reversible path back to direct billing if you ever need it
If you have questions on how this applies to your specific setup, your Cloud Capital contact and your AWS account team can walk through it with you.
# Request an AWS CUR backfill from AWS Support
Source: https://docs.cloudcapital.co/get-started/aws-cur-backfill
## Overview
As part of the [Billing Transfer](/get-started/aws-billing-transfer) process, Cloud Capital automatically requests **1 year** of CUR backfill from AWS on your behalf. If you need up to **36 months** (3 years) of historical data, follow this guide to open an AWS Support case directly.
AWS supports backfilling Cost and Usage Report (CUR) data for up to 36 months through a support case. When submitting, use the **Chat** option rather than the default Web method — web cases are treated as low priority and take significantly longer to process.
## Prerequisites
Before requesting an AWS CUR backfill, ensure you have:
* An active CUR or Data Export (CUR 2.0) previously configured
* The exact **Export Name** or **Report Name** from that previously configured setup.
* Your **AWS Account ID** ( Your Management/Payer Account)
* Determined the **billing periods** you need backfilled (specific months/years, up to 36 months)
* At least one [active Cost Allocation tag](https://us-east-1.console.aws.amazon.com/costmanagement/home?region=us-east-1#/tags) (e.g. `aws:createdBy`)
### Step-by-Step Process
**Step 1: Gather Required Information**
Collect the following prerequisite details before attempting to open your support case.
1. **Account ID**: The Management/Payer Account ID where the CUR is configured
2. **Export/Report Name**: The name of your CUR or Data Export that you have previously configured:
* For Data Exports: Found in **Billing Console → Data Exports**
* For Legacy CUR: Found in **Billing Console → Cost & Usage Reports**
3. **Billing Periods**: Specify the months you need backfilled
* Example: "January 2024 through December 2024" or "Last 12 months"
* Maximum: 36 months of historical data
4. **S3 Bucket**: The destination bucket (usually auto-populated in the export configuration)
**Step 2: Open an AWS Support Case**
1. Sign in to the **AWS Console** for the Management / Payer Account
2. Navigate to **Support → Support Center**
3. Using the new Support experience page, you will have to enter text into the AI request dialog box. Here is suggested text to put in that dialog box and then hit **enter** .
```
I need to request a CUR backfill
```
4. The AI will come back with some information about CUR backfill. Then you can click the blue oval "**Create a Case**" button. This brings up a dialog that allows you to enter the following:
```
Subject: Request CUR Data Backfill for [Export Name]
Description:
Hello AWS Support,
I would like to request a backfill of historical Cost and Usage Report (CUR 2.0) data for the following export:
- AWS Account ID: [Your Account ID]
- Export/Report Name: [Exact Export Name used in Subject above]
- Backfill Period: [e.g., "January 2024 through December 2024" or "Last 12 months"]
- S3 Bucket: [Your S3 Bucket Name]
Please confirm when the backfill is complete so we can begin processing the historical data.
Thank you!
```
5. Under the Description box, ***Select***\_ \_a Case type: **Account and billing**, Service: **Cost and Usage Report (CUR)**, Category: **Backfill a Report**, Severity: **General Question**
6. Also select a Communication preference for language and then select **Chat** — do not use Web, as web cases are low priority and significantly slower to process.
7. Click the blue oval "**Submit" button**
**Step 3: Monitor**
* AWS typically processes backfill requests within **24–48 hours**.
* You will receive email updates on the case progress.
* Monitor your **S3 bucket** you designated for the backfilled data to appear.
* **Let Cloud Capital** know that the data has arrived so we can import the new data into our app.
## Important Limitations
### What **CAN** Be Backfilled:
✅ Up to 36 months of historical data\
✅ Data from the current AWS Organization structure\
✅ Data from after the account creation date
### What **CANNOT** Be Backfilled:
❌ Data from before the AWS account was created\
❌ Data with previous organization structures (if the management account changed)\
❌ Data from before the account joined the current AWS Organization
# Integrate AWS Data
Source: https://docs.cloudcapital.co/get-started/aws-data-integration
Time to complete: \~10 minutes
The first step to using Cloud Capital is connecting your AWS cost data. Cloud Capital reads your AWS Cost and Usage Report (CUR) directly from an S3 bucket you control.
**Using another provider?** Pick its guide from the provider list in [Getting started](/introduction).
***
## Connect your AWS cost data
### What Cloud Capital accesses
The [Forecasting CloudFormation template](https://cloudcapital-integration.s3.us-east-1.amazonaws.com/aws/aws-cloudformation-forecasting.json) creates a read-only IAM role. Cloud Capital uses this role to:
| Purpose | AWS Services Used |
| -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Read your Cost and Usage Report from S3 | `s3:GetObject`, `s3:ListBucket` — scoped to your specific CUR bucket only |
| Look up current AWS pricing for Savings Plans and Reserved Instances | `pricing:GetProducts`, `savingsplans:Describe*` |
| Discover commitment offerings available in your account | `rds:Describe*`, `elasticache:Describe*`, `redshift:Describe*`, `es:Describe*`, `ec2:Describe*` |
| Enumerate accounts in your AWS Organization | `organizations:List*`, `organizations:Describe*` |
| Read cost, billing, and utilization data | `ce:Get*`, `billing:Get*`, and related read-only billing APIs |
The Forecasting role is **strictly read-only**. No actions that create, modify, or delete any AWS resources are included. Cloud Capital cannot make any changes to your AWS environment through this role.
### Before you begin
**If you plan to enable AWS Billing Transfer**, your AWS account must use
fine-grained IAM billing permissions before the transfer can be enabled.
Accounts created before March 6, 2023 commonly have legacy `aws-portal:*`
policies that need to be updated first — and discovering this late delays
onboarding.
Check now while you're setting up the data integration:
If your account has legacy billing IAM actions, use the AWS Bulk Policy
Migrator (5–15 min) to update them before proceeding to Billing Transfer.
### Setup
From the main dashboard, navigate to **Cost Allocation** and click **Connect Cloud Provider**.
![Connect Cloud Provider]()
Then click **Create New Integration**, choose **AWS**, and give your integration a descriptive name (e.g., `AWS`).
![Create AWS Integration]()
This step walks you through creating a cost data export in the AWS Billing and Cost Management portal.
If you already have a daily CUR 2.0 export running with the settings below, you can use the existing bucket and skip ahead to the next step.
1. In the AWS console, navigate to **Billing and Cost Management**
2. Click **Data Exports** on the left, then click **Create**
3. Select **Standard data export**
4. Give the report a name (e.g., `cloud-capital-cost-export`) — you will enter this name in Cloud Capital
In **Data table content settings**, configure:
* Format: **CUR 2.0** (default)
* Include resource IDs: **No** (leave unchecked)
* Split cost allocation data: **No** (leave unchecked)
* Time granularity: **Hourly**
* Column selection: keep the default
In **Data table delivery options**, configure:
* Compression type and file format: **Parquet - Parquet**
* File versioning: **Overwrite existing data export file**
In **Data export settings**, configure:
* Choose **Configure** → **Create a bucket** (recommended), or select an existing bucket
* Add an S3 path prefix of `hourly-export`
![create a bucket]()
You will need the S3 destination (bucket name + path prefix + export name) in the next step. It is shown directly after creating the report — copy and paste it.
Copy and paste the **Bucket Name**, **Path Prefix**, and **Export Name** from the previous step into the Integration settings in Cloud Capital.
Under **Create IAM Policy**, click **Run Cloud Formation Stack**. Cloud Capital pre-populates the required parameters in the stack — you do not need to enter them manually. This creates a read-only IAM role in your AWS Payer or Management account, scoped to your specific CUR bucket.
Once the stack completes, AWS provides a **Role ARN**. Enter this Role ARN in Cloud Capital.
You can review the full policy: [aws-cloudformation-forecasting.json](https://cloudcapital-integration.s3.us-east-1.amazonaws.com/aws/aws-cloudformation-forecasting.json)
Click **Test Role** to verify that Cloud Capital can access the bucket. If the connection is successful, your Integration status changes to **Enabled**. Save your integration to activate it.
![Integration Enabled]()
AWS typically takes 24–48 hours to populate the Cost and Usage Report for the first time. After 24 hours, return to the Integration settings to verify that data is being imported before proceeding.
***
If Cloud Capital will be managing AWS Savings Plans and Reserved Instances on your behalf, a second IAM role is required. See Commitment Purchasing Authorization for the full setup.
***
## How the cross-account role works
The Forecasting role uses AWS's standard cross-account access pattern with an **ExternalId** condition. Cloud Capital's AWS account ID and your unique ExternalId are embedded in the role's trust policy at setup time — meaning only Cloud Capital's specific AWS account can assume the role, and only when presenting the correct ExternalId. This prevents confused deputy attacks.
You can revoke the role at any time by deleting the CloudFormation stack in your AWS console, which immediately removes Cloud Capital's access.
This is a well-established AWS pattern for granting third-party access. For more detail on how cross-account roles and ExternalId conditions work, see [How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html) in the AWS documentation.
***
## Security and access summary
| | Forecasting Role |
| --------------------------------- | ----------------------------------- |
| **Applied to** | Your management/payer account |
| **Read access** | CUR bucket and billing/pricing APIs |
| **Creates or modifies resources** | No |
| **Accesses workload accounts** | No |
| **Can be revoked** | Yes, instantly via CloudFormation |
For a full overview of how Cloud Capital handles data access, encryption, audit logging, and compliance, see the Security page.
# AWS IAM Policy Check
Source: https://docs.cloudcapital.co/get-started/aws-fine-grained-access-check
Before Cloud Capital sends your AWS Billing Transfer invite, complete this quick check to confirm your IAM policies are compatible. Takes 5 minutes and prevents delays during onboarding.
Your Cloud Capital contact has sent you this page as part of your onboarding. **Complete this check before they send your AWS Billing Transfer invite.** If you find and fix any issues now, your billing transfer will go through smoothly — if issues are found only after the invite is accepted, you'll need to fix them before data can flow and re-attempt the transfer.
**Most accounts are unaffected.** If your AWS account or organization was created **on or after March 6, 2023**, you can skip straight to [verifying you're not affected](#check-your-affected-policies) — the tool will confirm this in seconds.
***
## Why this check exists
AWS retired a set of legacy IAM actions (`aws-portal:*`) used to control access to Billing and Cost Management. If your AWS account was created before March 6, 2023, some of your IAM policies may still reference these old actions — and AWS Billing Transfer requires the newer fine-grained permissions to work correctly.
The good news: AWS provides a free tool that scans your policies and tells you exactly what (if anything) needs to change, with suggested fixes ready to copy.
***
## Check your affected policies
For the tool to show issues across your entire AWS Organization, sign in as a role or user with **Organizational level access in your management (payer) account** — organization admin or root access to that account works best so you can see all possible issues across the organization instead of just going account by account.
If you only have access to a single member account, the tool will still show issues for that account.
Go directly to the tool:
**[https://console.aws.amazon.com/poliden/home?region=us-east-1#/](https://console.aws.amazon.com/poliden/home?region=us-east-1#/)**
This is AWS's built-in IAM policy migration tool under Billing preferences. You may be prompted to sign in if you're not already.
The tool will either show:
**✅ No policies listed** — You're all set. No action is required. Let your Cloud Capital contact know you're clear to receive the billing transfer invite.
**⚠️ One or more policies listed** — Each entry shows the policy name, the deprecated actions it contains, and a suggested updated policy you can copy directly. Follow the [migration steps below](#fixing-affected-policies) to resolve them, then return here to confirm the list is empty.
The tool scans **IAM identity-based policies** only — not Service Control Policies (SCPs). If your organization uses SCPs to restrict billing access, review those separately. See the [FAQ below](#frequently-asked-questions) for details.
***
## Fixing affected policies
If the Affected Policies tool listed one or more policies, follow the steps below to update them. Come back to the tool afterward to confirm the list is empty, then let your Cloud Capital contact know you're ready.
The tool generates an updated version of each affected policy — you don't need to hand-write the new actions.
In the **[Affected Policies tool](https://console.aws.amazon.com/poliden/home?region=us-east-1#/)**, find the policy you want to update. Under the **Copy updated policy** column, click **Copy**.
The copied policy includes your existing statements *plus* a new block (prefixed `AffectedPoliciesMigrator`) with the equivalent fine-grained actions.
Navigate to [IAM → Policies](https://console.aws.amazon.com/iam/home#/policies), search for the policy by name, and click into it.
Click **Edit policy** → switch to the **JSON** tab → replace the existing policy document with the one you copied → click **Review policy** → **Save changes**.
Return to the Affected Policies tool and repeat this process for each policy listed.
Refresh the Affected Policies tool. If the list is now empty, you're done — let your Cloud Capital contact know.
**Keep the old `aws-portal:*` actions in place during migration.** The updated policy generated by the tool retains them alongside the new fine-grained actions. This ensures continuity of access while the deprecation completes.
If you manage an **AWS Organization with multiple member accounts**, the Bulk Policy Migrator lets you scan and fix all accounts in one pass from your management account.
In your management (payer) account, navigate to the AWS Billing console. In the left navigation, go to **Billing preferences** → **Bulk Policy Migrator**.
If you don't see this option, search for **"Bulk Policy Migrator"** in the AWS console search bar.
Choose **Customize** to review which member accounts are affected before applying changes.
The tool lists any member accounts with affected policies. For each, review the recommended changes and click **Migrate** to apply them. The migrator adds the new actions alongside the existing ones — it does not remove the old ones, so access is not interrupted.
After applying all migrations, return to the Bulk Policy Migrator overview. If the affected accounts list is empty, you're done.
You can also cross-check using the **[Affected Policies tool](https://console.aws.amazon.com/poliden/home?region=us-east-1#/)** directly.
The Bulk Policy Migrator typically takes **5–15 minutes** for most organizations.
If your IAM policies are managed via Terraform, CloudFormation, CDK, or version-controlled JSON/YAML, update those definitions as well — not just the console.
Use the [AWS old-to-new action mapping reference](https://docs.aws.amazon.com/cost-management/latest/userguide/migrate-granularaccess-whatis.html) to identify the fine-grained equivalents for each `aws-portal:*` action.
A typical before/after:
```json Before (legacy) theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewBillingAccess",
"Effect": "Allow",
"Action": [
"aws-portal:ViewBilling",
"aws-portal:ViewPaymentMethods"
],
"Resource": "*"
}
]
}
```
```json After (fine-grained) theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewBillingAccess",
"Effect": "Allow",
"Action": [
"aws-portal:ViewBilling",
"aws-portal:ViewPaymentMethods"
],
"Resource": "*"
},
{
"Sid": "AffectedPoliciesMigratorViewBillingAccess",
"Effect": "Allow",
"Action": [
"billing:GetBillingData",
"billing:GetBillDetails",
"billing:GetConsoleActionSetEnforced",
"payments:ListPaymentPreferences",
"payments:GetPaymentInstrument"
],
"Resource": "*"
}
]
}
```
The exact fine-grained actions that map to your existing permissions will vary. Use the [Affected Policies Tool](https://console.aws.amazon.com/poliden/home?region=us-east-1#/) output as your authoritative reference — it generates the correct replacement actions for each specific policy.
After deploying your IaC changes, confirm via the Affected Policies tool that the list is now empty.
***
## Frequently asked questions
No — accounts created on or after that date already enforce fine-grained actions by default. The Affected Policies tool will show an empty list, confirming you're ready to proceed. Just let your Cloud Capital contact know.
No — as long as you retain the old `aws-portal:*` actions in your policy during the transition, access remains uninterrupted. The migration adds new fine-grained actions alongside the existing ones; it does not remove the old ones.
No — use the **Bulk Policy Migrator** in your management (payer) account. It scans all member accounts at once and lets you apply recommended migrations in Customize mode. See the Bulk Policy Migrator tab above for step-by-step instructions.
The Affected Policies tool only scans **IAM identity-based policies**. SCPs are not included. If your organization uses SCPs to restrict billing or cost management access, review those separately using the [AWS action mapping reference](https://docs.aws.amazon.com/cost-management/latest/userguide/migrate-granularaccess-whatis.html).
You may encounter permission errors when accepting the invite, or cost and billing data may not flow through correctly after onboarding. Completing this check first ensures the transfer goes through without interruption.
***
## All clear? Let your Cloud Capital contact know
Once the Affected Policies tool shows an empty list, you're ready for the billing transfer invite. Reach out to your Cloud Capital contact and they'll send it right away.
Open the tool directly to check your IAM policies.
Official AWS documentation on the Affected Policies Tool.
# 12-Month AWS Tag Backfill
Source: https://docs.cloudcapital.co/get-started/aws-tag-backfill
Activate tag backfill in the AWS Billing Console to apply your active cost allocation tags to 12 months of historical cost and usage data.
Time to complete: \~3 minutes · One-time setup · Audience: AWS payer account owner
When you activate cost allocation tags in AWS, they only appear on cost data going forward. Historical spend — the data already in your Cost and Usage Report — remains untagged unless you explicitly trigger a backfill. This guide walks through the self-service tag backfill available directly in the AWS Billing Console.
Once complete, your full year of tagged spend flows into Cloud Capital's allocation, forecasting, and commitment planning.
This is a separate process from [requesting a CUR data backfill via AWS Support](/get-started/aws-cur-backfill). That process re-exports raw cost data for up to 36 months. This process re-applies your active cost allocation **tags** to existing CUR data — it takes \~3 minutes and requires no support case.
***
## Steps
Sign into the AWS Management Console as the payer account owner and navigate to **Billing and Cost Management**.
In the left navigation, select **Cost allocation tags**.
> Direct link: [console.aws.amazon.com/billing/home#/tags](https://console.aws.amazon.com/billing/home#/tags)
You'll see a table of your User-defined and AWS-generated tags with their activation status. Confirm the tags you want backfilled are listed as **Active** — only active tags are included in the backfill.
In the top-right toolbar of the Cost allocation tags page, click **Backfill tags**.
This action is separate from the **Activate** button. You can trigger a backfill without re-activating tags — they just need to already be active.
This opens the backfill range dialog.
In the dialog, use the **Backfill start month** dropdown and select the option for **12 months prior** to the current month.
The dropdown offers preset options (1 month, 3 months, 6 months, 12 months prior). Select **12 months prior** for the full year of historical data.
Click **Confirm**.
AWS will begin reprocessing your historical Cost and Usage Report data with your active cost allocation tags applied.
Updated data typically appears in Cost Explorer and Cloud Capital within **24 hours**. Full reconciliation completes in **48–72 hours** depending on account size.
***
## What this unlocks
With 12 months of tagged historical data in place, Cloud Capital can:
* Attribute every line item to its owner, environment, and cost center from day one
* Build accurate year-over-year forecasts using fully tagged spend
* Size commitment recommendations against a complete picture of historical usage rather than partial, untagged data
***
## Frequently asked questions
No — tags just need to already be **Active**. If your tags are active, click **Backfill tags** directly. The backfill and activation flows are independent.
Yes. If you activate additional tags later, you can return to this page and trigger another backfill to apply the new tags to historical data.
The account owner or a user with billing console access can perform this action. If you're using fine-grained IAM billing permissions, the `billing:*` read and write actions cover this. See [Migrating to Fine-Grained IAM Policies](/get-started/aws-fine-grained-access-check) if you're unsure whether your account uses updated permissions.
These are two separate operations:
| | Tag backfill (this guide) | CUR backfill via Support |
| ---------------- | ----------------------------------------------- | -------------------------------------------- |
| **What it does** | Re-applies active tags to existing CUR data | Re-exports raw CUR data to your S3 bucket |
| **Time** | \~3 min (self-service) | 24–48 hrs (support case) |
| **Max history** | 12 months | 36 months |
| **When to use** | Tags are active but historical data is untagged | You need more than the default history in S3 |
For most customers, running the tag backfill is all that's needed. The [CUR backfill via Support](/get-started/aws-cur-backfill) is only required if you need more than 12 months of raw cost data in your S3 bucket.
***
Assign your AWS resources to cost layers for allocation and forecasting.
Need more than 12 months of raw cost data? Open an AWS Support case to backfill up to 36 months.
# Integrate Claude.ai Enterprise
Source: https://docs.cloudcapital.co/get-started/claude-ai-data-integration
Connect Claude.ai Enterprise seat and usage spend to Cloud Capital with an Analytics API key. Claude.ai support is currently in Beta.
**Claude.ai Enterprise support is in Beta.** To enroll, request access from your Cloud Capital Customer Success Manager. Once your account is enabled, **Claude.ai Enterprise** appears as an option on the New Integration page. If you don't see it yet, reach out to your Customer Success Manager.
Building on the **Claude API** instead (developer bill at console.anthropic.com, `sk-ant-…` keys)? See [Integrate Claude API](/get-started/claude-api-data-integration). The two keys are not interchangeable.
Cloud Capital reads your **Claude.ai Enterprise** usage and seat spend from the Claude.ai Analytics API. You paste an **Analytics API key** and choose a **default seat rate**; the key is encrypted and stored on the integration. Seat fees are estimated from observed users × that rate. This path is **forecast-only**.
Setup takes about 5 minutes once you have an Analytics API key.
***
### What Cloud Capital accesses
| What you're granting | How | Scope |
| -------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------- |
| Analytics API key | Pasted into the integration form, encrypted at rest | Read access to Claude.ai Enterprise Analytics for your organization |
| Default seat rate | Configured in Cloud Capital | Used to synthesize seat fees when the API does not supply dollar seat prices |
Cloud Capital uses the key only to **read** analytics cost data. It does not create, modify, or delete resources in Claude.ai, and this integration does not enable commitment purchasing or billing transfer.
### What's available with Claude.ai today
| Available | Not yet available |
| ------------------------------------------------------------------------------------------- | ------------------------------------------- |
| Cost forecasting, cost insights, and cost allocation for Enterprise usage + estimated seats | Commitment purchasing through Cloud Capital |
| Nightly ingest of daily cost data | Billing through Cloud Capital |
***
### Before you begin
* **Enterprise only** — Max/Pro and Team plans are **not** covered. You need Claude.ai **Enterprise**.
* **Choose the right product** — Use Claude.ai if your team signs in at [claude.ai](https://claude.ai) for chat, Claude Code, or Cowork. If you bill API usage at console.anthropic.com, connect [Claude API](/get-started/claude-api-data-integration) instead.
* **Admin access** — You need permission to create an **Analytics API key** under Claude.ai organization settings → API. Keys for this path start with `sk-ant-api01-`.
* **Not covered here** — Amazon Bedrock Anthropic usage stays on your [AWS integration](/get-started/aws-data-integration).
* **Wrong key types fail** — Console Admin keys (`sk-ant-admin…`) and inference keys (`sk-ant-api03-…`) are rejected on this form.
### Setup
In Cloud Capital, go to the **Integrations** page — from Cost Allocation, use **Manage Cloud Providers**. Click **Create New Integration** and choose **Claude.ai Enterprise**.
The new integration opens on the Integration Settings page. Give it a descriptive name.
![Claude.ai Enterprise Integration Settings with Analytics API key and default seat rate fields]()
In Claude.ai, open **Organization settings → API** and create an **Analytics API key**.
The key should start with `sk-ant-api01-`. Copy it once at creation time.
Do not paste a Console Admin key or a Console inference key. Those belong to [Claude API](/get-started/claude-api-data-integration) and will fail here.
On the Integration Settings page:
1. Paste the Analytics API key into the **Analytics API key** field.
2. Choose a **Default seat rate** that matches your Anthropic seat type:
* **standard**
* **premium**
* **free**
3. Click **Test Connection**. Cloud Capital verifies it can reach the Claude.ai Enterprise Analytics API.
4. After a successful test, set status to **Enabled** and click **Save**.
Seat fees are synthesized from roster × your configured monthly rate; they are not imported from an invoice. Pick the rate that matches how Anthropic bills your seats. You can change it later and re-save.
***
### What to expect after setup
* **Data timing** — Cost data is ingested on a scheduled nightly cycle. Expect dashboards within about 24 hours of a successful connection.
* **Seat estimates** — Seat dollar amounts come from observed users × your default seat rate, not from a separate invoice PDF import.
* **Forecast only** — Commitment purchasing and billing transfer are not part of this integration.
### Troubleshooting
| Symptom | What to check |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Claude.ai card missing or Coming Soon | Your org is not enrolled yet. Ask your Customer Success Manager to enable `claudeAi`. |
| Connection test fails / 401 | Confirm you pasted an Analytics key (`sk-ant-api01-…`), not a Console Admin or inference key. |
| Form blocks save with a key-type notice | You likely pasted a Claude API Admin or inference key. Use Analytics, or switch to [Claude API](/get-started/claude-api-data-integration). |
| Max/Pro or Team plan | Not supported. Enterprise is required. |
| Test passes but dashboards are empty | Allow up to 24 hours for nightly ingest. Confirm Enterprise Analytics shows recent activity. |
***
For a full overview of how Cloud Capital handles data access, encryption, audit logging, and compliance, see the Security page.
# Integrate Claude API
Source: https://docs.cloudcapital.co/get-started/claude-api-data-integration
Connect Anthropic Claude API (Console) org spend to Cloud Capital with a Console Admin API key. Claude API support is currently in Beta.
**Claude API support is in Beta.** To enroll, request access from your Cloud Capital Customer Success Manager. Once your account is enabled, **Claude API** appears as an option on the New Integration page. If you don't see it yet, reach out to your Customer Success Manager.
Using the **Claude.ai** app instead (people signing in at claude.ai for chat, Claude Code, or Cowork)? See [Integrate Claude.ai Enterprise](/get-started/claude-ai-data-integration). The two keys are not interchangeable.
Cloud Capital reads your **Claude API** usage from the Anthropic Console Admin API. You paste a **Console Admin API key** into Cloud Capital; the key is encrypted and stored on the integration. This path is **forecast-only** — Cloud Capital does not purchase commitments or bill Claude API spend on your behalf through this integration.
Setup takes about 5 minutes once you have an Admin API key.
***
### What Cloud Capital accesses
| What you're granting | How | Scope |
| --------------------- | --------------------------------------------------- | ---------------------------------------------------------------------- |
| Console Admin API key | Pasted into the integration form, encrypted at rest | Read access to Console Admin cost APIs for your Anthropic organization |
Cloud Capital uses the key only to **read** cost data. It does not create, modify, or delete resources in your Anthropic Console, and this integration does not enable commitment purchasing or billing transfer.
### What's available with Claude API today
| Available | Not yet available |
| -------------------------------------------------------------------------- | ------------------------------------------- |
| Cost forecasting, cost insights, and cost allocation for Console API spend | Commitment purchasing through Cloud Capital |
| Nightly ingest of daily cost data | Billing through Cloud Capital |
***
### Before you begin
* **Choose the right product** — Use Claude API if you get a developer bill at [console.anthropic.com](https://console.anthropic.com) for apps, agents, and API keys (`sk-ant-…`). If your team uses Claude.ai Enterprise seats, connect [Claude.ai](/get-started/claude-ai-data-integration) instead.
* **Admin access** — You need permission to create a **Console Admin API key** in your Anthropic Console organization settings. Admin keys start with `sk-ant-admin`.
* **Not covered here** — Max/Pro and Team (non-Enterprise) plans. Amazon Bedrock or AWS Marketplace Anthropic usage stays on your [AWS integration](/get-started/aws-data-integration) — connecting both paths for the same spend can double-count.
* **Wrong key types fail** — Inference keys and Claude.ai Analytics keys are rejected. Paste only a Console Admin API key.
### Setup
In Cloud Capital, go to the **Integrations** page — from Cost Allocation, use **Manage Cloud Providers**. Click **Create New Integration** and choose **Claude API**.
The new integration opens on the Integration Settings page. Give it a descriptive name — you can add multiple Claude API integrations, so the name is how you'll tell them apart.
![Claude API Integration Settings with name and Console Admin API key fields]()
In the [Anthropic Console](https://console.anthropic.com), open your **organization settings** and create a **Console Admin API key**.
The key must start with `sk-ant-admin`. Copy it once — Anthropic shows the full value only at creation time.
Do not use an ordinary inference key (`sk-ant-api03-…`) or a Claude.ai Analytics key (`sk-ant-api01-…`). Those call different APIs and will fail the connection test.
On the Integration Settings page:
1. Paste the Console Admin API key into the **Console Admin API key** field.
2. Click **Test Connection**. Cloud Capital verifies it can reach the Anthropic Console Admin API with this key.
3. After a successful test, set the integration status to **Enabled** (or leave it if the app already switched it for you).
4. Click **Save**.
You must complete a successful connection test before you can enable a new integration. To rotate a key later, paste a new key and re-test; leave the field blank to keep the stored key.
***
### What to expect after setup
* **Data timing** — Cost data is ingested on a scheduled nightly cycle, not instantly on save. Expect your first data in dashboards within about 24 hours of a successful connection.
* **Empty at first is normal** — If the Admin API has little or no recent usage, dashboards may look empty until spend appears and the next nightly cycle runs.
* **Forecast only** — Claude API spend appears in forecasting and cost insights. Commitment purchasing and billing transfer are not part of this integration.
### Troubleshooting
| Symptom | What to check |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Claude API card missing or Coming Soon | Your org is not enrolled yet. Ask your Customer Success Manager to enable `claudeApi`. |
| Connection test fails / 401 | Confirm you pasted a Console Admin key (`sk-ant-admin…`), not an inference or Analytics key. |
| Form blocks save with a key-type notice | You likely pasted a Claude.ai Analytics key or an inference key. Use a Console Admin key, or switch to [Claude.ai](/get-started/claude-ai-data-integration). |
| Spend also on AWS CUR for Bedrock / Marketplace | Keep Bedrock/Marketplace on AWS only. Connecting the same Anthropic spend on both Claude API and AWS can double-count. |
| Test passes but dashboards are empty | Allow up to 24 hours for nightly ingest. Confirm the Console shows recent API usage. |
***
For a full overview of how Cloud Capital handles data access, encryption, audit logging, and compliance, see the Security page.
# Integrate Cursor
Source: https://docs.cloudcapital.co/get-started/cursor-data-integration
Connect Cursor Teams usage and seat spend to Cloud Capital with a Team Admin API key. Cursor support is currently in Beta.
**Cursor support is in Beta.** To enroll, request access from your Cloud Capital Customer Success Manager. Once your account is enabled, **Cursor** appears as an option on the New Integration page. If you don't see it yet, reach out to your Customer Success Manager.
Cloud Capital reads your **Cursor Teams** model usage and seat spend from the Cursor Team Admin API. You paste a **Team Admin API key** and choose a **default seat rate**; the key is encrypted and stored on the integration. Seat fees are synthesized from roster × configured rates. This path is **forecast-only**.
Setup takes about 5 minutes once you have a Team Admin API key.
***
### What Cloud Capital accesses
| What you're granting | How | Scope |
| -------------------- | --------------------------------------------------- | ---------------------------------------------------------------------- |
| Team Admin API key | Pasted into the integration form, encrypted at rest | Read access to team members, spend, and filtered usage events |
| Default seat rate | Configured in Cloud Capital | Used to synthesize seat fees (seat prices are not returned by the API) |
Cloud Capital uses the key only to **read** team usage and membership data. User / Cloud Agents keys will not work. This integration does not enable commitment purchasing or billing transfer.
### What's available with Cursor today
| Available | Not yet available |
| ---------------------------------------------------------------------------------------- | ------------------------------------------- |
| Cost forecasting, cost insights, and cost allocation for Teams usage + synthesized seats | Commitment purchasing through Cloud Capital |
| Nightly ingest of usage events and seat estimates | Billing through Cloud Capital |
***
### Before you begin
* **Teams Admin key** — Create a key from **Cursor Dashboard → Team API Keys**. Keys start with `crsr_`.
* **Not User / Cloud Agents keys** — Those keys cannot call the Team Admin endpoints Cloud Capital uses and will fail the connection test.
* **Seat rates** — Cursor does not expose seat dollar prices on this API. Cloud Capital synthesizes seat fees from members × your default seat rate.
* **Plan** — Team Admin API keys work for Teams (Enterprise is not required for this path).
### Setup
In Cloud Capital, go to the **Integrations** page — from Cost Allocation, use **Manage Cloud Providers**. Click **Create New Integration** and choose **Cursor**.
The new integration opens on the Integration Settings page. Give it a descriptive name.
![Cursor Integration Settings with Team Admin API key and default seat rate]()
In the Cursor Dashboard, open **Team API Keys** and create a **Team Admin** API key.
The key must start with `crsr_`. Copy it once at creation time.
Do not use a User API key or a Cloud Agents key. Only Team Admin keys work with this integration.
On the Integration Settings page:
1. Paste the Team Admin API key into the **Team Admin API key** field.
2. Choose a **Default seat rate** that matches your Cursor seat type:
* **standard**
* **premium**
* **free**
3. Click **Test Connection**. Cloud Capital verifies it can reach the Cursor Team Admin API (members and usage).
4. After a successful test, set status to **Enabled** and click **Save**.
Seat fees are synthesized from roster × your configured rate — pick the type that matches how you bill seats; you can change it later and re-save. You must complete a successful connection test before you can enable a new integration. To rotate a key later, paste a new key and re-test; leave the field blank to keep the stored key.
***
### What to expect after setup
* **Data timing** — Cost data is ingested on a scheduled nightly cycle. Expect dashboards within about 24 hours of a successful connection.
* **Usage + seats** — Model usage comes from filtered usage events; seat fees are synthesized from team members × your configured rates.
* **Forecast only** — Commitment purchasing and billing transfer are not part of this integration.
### Troubleshooting
| Symptom | What to check |
| ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| Cursor card missing or Coming Soon | Your org is not enrolled yet. Ask your Customer Success Manager to enable `cursor`. |
| Connection test fails | Confirm the key starts with `crsr_` and is a **Team Admin** key, not a User or Cloud Agents key. |
| Seat dollars look wrong | Adjust **Default seat rate** to match how you bill seats, then save. Seats are synthesized, not read as invoice line items. |
| Test passes but dashboards are empty | Allow up to 24 hours for nightly ingest. Confirm the team has recent usage in the Cursor Dashboard. |
***
For a full overview of how Cloud Capital handles data access, encryption, audit logging, and compliance, see the Security page.
# Integrate GCP Data
Source: https://docs.cloudcapital.co/get-started/gcp-data-integration
Connect your Google Cloud cost and commitment data to Cloud Capital by granting read access to your BigQuery exports, billing account, and Compute commitments. GCP support is currently in Beta.
**GCP support is in Beta.** To enroll, request access from your Cloud Capital Customer Success Manager. Once your account is enabled, **GCP** appears as an option on the New Integration page. If you don't see it yet, reach out to your Customer Success Manager.
Cloud Capital reads your Google Cloud cost and commitment data from resources you own — a **BigQuery billing export table**, a **CUD subscriptions export dataset**, your **billing account**, and your **Compute commitments**. You provide the coordinates for each, then grant Cloud Capital's service account read-only access.
Setup takes about 30 minutes, plus time for GCP to populate the exports if you're enabling them for the first time. The four grants need **administrator access in three different places** — your billing account, your organization, and BigQuery. One person may well hold all three; if not, the grants are independent, so each can be handed to whoever holds that access.
***
### What Cloud Capital accesses
Cloud Capital reads using a service account that is unique to your environment. Four grants are required:
| What you're granting | Role | Scope | Granted by |
| -------------------------------- | --------------------------- | --------------------------------- | ---------------------------------- |
| Billing account access | `roles/billing.viewer` | Your billing account | Billing Account Administrator |
| Compute commitment visibility | `roles/compute.viewer` | Your organization | Organization Administrator |
| Billing export table access | `roles/bigquery.dataViewer` | The billing export **table only** | BigQuery Data Owner on the dataset |
| CUD subscriptions dataset access | `READER` (dataset ACL) | The CUD subscriptions dataset | BigQuery Data Owner on the dataset |
All four grants are strictly **read-only**. Cloud Capital cannot create, modify, or delete any resources in your Google Cloud environment.
`roles/billing.viewer` includes visibility into your negotiated contract pricing, billing account credits and anomalies, Google's own commitment recommendations, and billing account payment metadata. Cloud Capital uses these to price your usage at your actual rates rather than list rates. If your security review needs a narrower discussion of any specific permission, raise it with your Customer Success Manager.
Cloud Capital runs its BigQuery queries in its own project rather than yours, so the query cost is ours, not yours. The grants above only need to let us *read* your data — no query or compute permissions are required on your project.
### What's available with GCP today
| Available for GCP | Not yet available for GCP |
| ------------------------------------------------------------ | ------------------------------------------- |
| Cost forecasting, cost insights, and cost allocation | Commitment purchasing through Cloud Capital |
| Commitment inventory and performance on the Commitments page | Billing through Cloud Capital |
***
### Before you begin
* **GCP permissions** — Between you and your colleagues, you need Billing Account Administrator, Organization Administrator, and BigQuery Data Owner. The grants are independent, so they can be applied in any order by different people. Organization Administrator is the one most likely to sit outside your team. If you can't get it, Step 4 covers granting on folders instead.
* **Export type** — Use the **Standard usage cost** billing export to BigQuery, not the detailed / resource-level export.
* **Two required exports** — Cloud Capital needs both the **Standard usage cost** export and the **Committed use discount (CUD) subscriptions** export. Both are enabled from the same BigQuery export tab in Google Cloud. The CUD dataset does not exist until that export is switched on, so enable both before running the grants.
* **Check for existing exports first** — GCP only exports data from the point an export is enabled, so an export that has been running for a while is worth finding. Check whether either export already exists in your billing project before creating a new one; connecting to an existing export gives Cloud Capital history from its start date rather than from today.
* **CLI tools** — The grant commands use `gcloud`, `bq`, and `jq`. All three are preinstalled in GCP Cloud Shell.
### Setup
In Cloud Capital, go to the **Integrations** page — from Cost Allocation, use **Manage Cloud Providers**. Click **Create New Integration** and choose **GCP**.
The new integration opens on the Integration Settings page named `Untitled GCP Integration`. Replace that with something descriptive — you can add multiple integrations per cloud provider, so the name is how you'll tell them apart. You'll enter your coordinates and grant access on this same page in the steps below.
![GCP Integration Settings showing the integration name field and the Billing Export and Commitment Information field groups]()
In the Google Cloud Console, go to **Billing → Billing export → BigQuery export**. Cloud Capital needs both of these:
1. **Standard usage cost** export. Its table is named like `gcp_billing_export_v1_XXXXXX`, in the dataset configured for the export.
2. **Committed use discount (CUD) subscriptions** export. This lives in a separate dataset and contains a `cud_subscriptions_export` table.
If either is already enabled, use it — its history goes back to the day it was switched on, which is history Cloud Capital can use. Enable whichever is missing, then note the project and datasets for both.
See [Google's billing export setup documentation](https://docs.cloud.google.com/billing/docs/how-to/export-data-bigquery-setup) for the setup steps. A newly enabled export starts empty and fills going forward — GCP does not backfill it.
The CUD subscriptions dataset does not exist until that export is enabled. Skipping it makes the grant command in Step 4 fail with a "not found" error.
The Cloud Capital integration form asks for six values, split into two groups.
**Billing export** — find these in the BigQuery Console: expand your billing project in the explorer, select the export dataset, and copy the export table's name.
| Field | What it is | Example |
| -------------------- | -------------------------------------------------- | -------------------------------------------- |
| GCP Project ID | The project containing your billing export dataset | `my-billing-project` |
| BigQuery Dataset ID | The dataset where the billing export lives | `billing_export` |
| Billing Export Table | The specific export table (not the dataset) | `gcp_billing_export_v1_018ECB_B18E18_C07590` |
**Commitment information** — find the billing account ID under **Billing** and the organization ID under **IAM & Admin → Settings** in the Google Cloud Console.
| Field | What it is | Example |
| ------------------------- | ------------------------------------------------------------- | ---------------------- |
| Billing Account ID | The billing account paying for the projects you want analyzed | `XXXXXX-XXXXXX-XXXXXX` |
| Organization ID | Your GCP organization's numeric ID | `123456789012` |
| CUD Subscriptions Dataset | The dataset created by the CUD subscriptions export | `billing_export_cud` |
The CUD Subscriptions Dataset is the **dataset**, not the table. Cloud Capital reads the `cud_subscriptions_export` table inside it.
On the Integration Settings page, the **Grant Access** step shows the service account email to grant to:
```
cloud-capital-forecasting@cloudcapital-production.iam.gserviceaccount.com
```
Copy it from the app rather than from this page — it is specific to your Cloud Capital environment, and a mismatch is the most common cause of a failed connection test.
![Grant Access step showing the service account email, the Permissions and All-in-one script tabs, and the four collapsible grants]()
**The commands below contain placeholders.** Every ``, ``, ``, ``, and `` on this page must be replaced with your real values before the command will work.
You don't have to do that by hand. Fill in all six fields in the app first, and the **Grant Access** step populates every command with your own values, ready to copy. Until you do, the app shows the same ``-style placeholders and warns you they aren't populated yet.
Run the commands in your terminal or in GCP Cloud Shell. Every grant is idempotent and safe to re-run.
These four grants need administrator access in three different places — your billing account, your organization, and BigQuery. Each grant is independent and can be applied in any order, so if the access is spread across your team you can route each command to whoever holds it.
**Granted by** Billing Account Administrator, on your billing account.
Gives Cloud Capital your contract pricing, commitment insights, anomalies, and credits.
```bash theme={null}
gcloud billing accounts add-iam-policy-binding \
--member="serviceAccount:" \
--role="roles/billing.viewer"
```
**Granted by** Organization Administrator, on your organization.
Gives Cloud Capital your resource-based Compute commitments. **Grant this at the organization if you possibly can** — it covers your whole estate, including projects you create later, and it's the only version of this grant that keeps working without maintenance.
```bash theme={null}
gcloud organizations add-iam-policy-binding \
--member="serviceAccount:" \
--role="roles/compute.viewer" \
--condition=None
```
**Genuinely can't get Organization Administrator?** Granting on folders is the next best thing — IAM inherits downward, so a folder grant still covers projects created in it later. Failing that, you can grant per project. See **If you can't grant at the organization**, below this tab group.
**Granted by** BigQuery Data Owner on the dataset, scoped to the single export table.
Gives Cloud Capital your cost data.
```bash theme={null}
bq add-iam-policy-binding \
--member="serviceAccount:" \
--role="roles/bigquery.dataViewer" \
:.
```
**Granted by** BigQuery Data Owner on the dataset.
Gives Cloud Capital your spend-based commitments.
The CUD subscriptions export is an **Analytics Hub linked dataset**, where per-table IAM is structurally unavailable — `bq add-iam-policy-binding` against a table in it fails. Access is granted through the legacy dataset ACL instead, by reading the dataset resource, appending an access entry, and writing it back. `READER` is the ACL equivalent of `roles/bigquery.dataViewer`.
```bash theme={null}
bq show --format=prettyjson : \
| jq --arg e "" \
'if any(.access[]; .userByEmail == $e)
then . else .access += [{"role":"READER","userByEmail":$e}] end' \
> /tmp/cc-cud-dataset.json
bq update --source /tmp/cc-cud-dataset.json :
```
`bq update --source` replaces the entire dataset resource. Use the command as given — the `jq` expression preserves existing access entries and no-ops if Cloud Capital is already present. Don't hand-edit the file to contain only the new entry.
If you hold all three — Billing Account Administrator, Organization Administrator, and BigQuery Data Owner — the app's **All-in-one script** tab bundles all four grants into one block, which is the fastest path. Requires the `gcloud`, `bq`, and `jq` CLIs; `jq` is preinstalled in GCP Cloud Shell.
Copy it from the app rather than reconstructing it here — it is generated from your entered coordinates and the service account email for your environment.
#### If you can't grant at the organization
The organization-level grant is strongly preferred, and it's worth a conversation with whoever holds Organization Administrator before falling back. If that grant genuinely isn't available to you, there are two narrower options — and IAM inherits down the resource hierarchy, so **granting at a folder is much closer to the organization grant than granting per project**.
**Grant on folders (preferred fallback).** If your projects are organized under folders, a grant on a folder covers every project inside it — including sub-folders and projects created in it later. That preserves the property that actually matters: new projects are covered automatically, without anyone remembering to do anything. It needs Folder IAM Admin rather than Organization Administrator, which is far more commonly delegated.
```bash theme={null}
# Repeat for each folder containing billed projects.
gcloud resource-manager folders add-iam-policy-binding \
--member="serviceAccount:" \
--role="roles/compute.viewer" \
--condition=None
```
List your folders with `gcloud resource-manager folders list --organization=`, or find them under **IAM & Admin → Manage Resources** in the Google Cloud Console. If your estate is organized so that every billed project sits under a folder you can grant on, this is effectively as durable as the organization grant. Projects created *outside* those folders are still uncovered, so it's worth checking whether that can happen in your setup.
**Grant per project (last resort).** If there's no usable folder structure, granting `roles/compute.viewer` on every project the billing account pays for gets you the same commitment visibility today. It needs Project IAM Admin on each project.
```bash theme={null}
# Grants on every project currently billed to this account.
for project in $(gcloud billing projects list \
--billing-account= \
--format="value(projectId)"); do
gcloud projects add-iam-policy-binding "$project" \
--member="serviceAccount:" \
--role="roles/compute.viewer" \
--condition=None
done
```
**Per-project grants are ongoing work.** Every project you create from now on is invisible to Cloud Capital until someone remembers to grant on it too, and a missed project means missing commitments rather than an obvious error. Cloud Capital names any project it can't read in the connection test result, but that only helps if someone re-tests. If you have folders, grant on those instead — and move to the organization grant when you can.
Whichever level you grant at, Cloud Capital reads commitments project by project and reports any it can't reach, so the connection test tells you whether your chosen scope actually covers the estate. Re-test after adding projects or restructuring folders.
Back on the Integration Settings page:
1. **Enter** all six values from Step 3. **Test Connection** stays disabled until the BigQuery coordinates are filled in.
2. **Grant access** as described in Step 4, if you haven't already.
3. Click **Test Connection**. You can test before saving.
4. A new integration starts with status **Draft**. A successful test switches it to **Enabled** automatically.
5. Click **Save**.
![Test Connection step with the Test Connection button and the Set integration status dropdown showing Draft]()
The test has three possible outcomes:
| Result | What it means |
| ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Connection successful** | Cloud Capital can read your billing export, your CUD subscriptions export, your billing account, and Compute commitments across every project on the billing account. |
| **Cost data is connected, but some commitment access is missing** | The billing export reads fine, so the integration works and can be saved. Each missing piece is listed by name so you know which command from Step 4 to re-run. |
| **Connection failed** | Cloud Capital cannot read your billing export. This is the one blocking failure — the integration cannot ingest cost data until it's resolved. |
The connection test confirms access. It does not validate the exports' contents or confirm that data has been ingested yet.
***
### What to expect after setup
* **Data timing** — Cost data is ingested on a scheduled nightly cycle, not instantly on save. Expect your first data in dashboards within about 24 hours of a successful connection, provided the billing export table already contains data.
* **Empty at first is normal** — If you just enabled the exports, GCP may not have written rows yet. Cloud Capital will pick them up on the next nightly cycle.
* **Commitments** — GCP commitments appear on the Commitments page once the inventory refresh runs. Both commitment sources are needed for a complete picture: the Compute API supplies resource-based commitments and the CUD subscriptions export supplies spend-based ones. Neither is a superset of the other, so a missing grant on either side leaves a blind spot rather than a partial view.
### Troubleshooting
| Symptom | What to check |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Connection test fails with a permission error | Re-check the BigQuery Data Viewer grant on the billing export table, and confirm the service account email you granted matches exactly what's shown on the Cloud Capital setup page. |
| Connection test fails with "not found" | Verify the project, dataset, and table values against the BigQuery Console. The Billing Export Table field needs the table name itself (e.g. `gcp_billing_export_v1_...`), not the dataset. |
| Warning: CUD subscriptions export "not found" | The CUD subscriptions export isn't enabled yet, or the CUD Subscriptions Dataset field points at the wrong dataset. Enable the export (Step 2), then re-test. |
| Warning: billing account cannot be read | Re-run the `roles/billing.viewer` grant and confirm the Billing Account ID is correct, including its hyphens. |
| Warning: Compute commitments cannot be read in *named projects* | Those projects have no `compute.viewer` grant, inherited or direct. Granting at the organization fixes this permanently; a grant on the folder those projects live under fixes it for that whole branch. Re-running the per-project loop fixes it only until the next new project. |
| Warning: coverage check timed out or was truncated | Cloud Capital could only check some of the projects on your billing account, so commitment visibility across the rest is unknown. The organization-level grant removes the need to check project by project and is the reliable fix here. |
| `bq add-iam-policy-binding` fails on the CUD dataset | Expected — the CUD export is an Analytics Hub linked dataset and doesn't support per-table IAM. Use the dataset ACL command in Step 4 instead. |
| Wrong export type | Confirm you connected the `gcp_billing_export_v1_*` table from the **Standard usage cost** export, not a detailed / resource-level export table. |
| Test passes but dashboards are empty | If the export was just enabled, GCP may not have written data yet, and Cloud Capital ingests nightly. Confirm the export table has rows in BigQuery, then allow up to 24 hours. |
| Saved configuration appears blank after reload | Contact Cloud Capital support. |
***
For a full overview of how Cloud Capital handles data access, encryption, audit logging, and compliance, see the Security page.
# Cloud Resource Mapping
Source: https://docs.cloudcapital.co/get-started/map-cloud-resources
Map your cloud accounts and services to Cost Layers so Cloud Capital can accurately forecast and optimise your spend.
Cost Allocation is where you connect your cloud infrastructure to your business structure. Every dollar of cloud spend gets assigned to a **[Cost Layer](/forecasting/cost-layers)** — a named category that reflects how your organisation thinks about its costs. Once mapped, your forecast, savings analysis, and commitment proposals all work from that structure rather than raw account or project data.
Cost Allocation requires at least one active cloud integration (AWS or GCP) with cost data available. If you've just connected your integration, allow up to 24 hours for data to appear before mapping.
***
## Why Cost Layers matter
Cloud Capital starts every organisation with two top-level cost layers:
* **Production (COGS)** — infrastructure that directly supports your live product or service. From a finance perspective, this is Cost of Goods Sold: the cloud spend that scales with your revenue and belongs on your P\&L as a direct cost of delivering your service.
* **Non-Production (OpEx)** — infrastructure used for development, staging, testing, and internal tooling. This is Operating Expenditure: necessary business cost, but not directly tied to serving customers.
This distinction matters to your finance team. COGS and OpEx are treated differently in financial reporting, margin analysis, and budgeting conversations. Mapping your cloud spend to these two categories from the start means Cloud Capital's forecasts and savings proposals are grounded in the same financial structure your CFO and board use — not just a flat view of your cloud bill.
**Going deeper with sub-layers**
Two top-level layers are the minimum. Most organisations benefit from further structure beneath them, which you can add at any time. Common approaches include:
* **By cloud service** — Compute, Database & Storage, Networking, AI & Analytics. Useful for understanding which service families (AWS or GCP) are driving cost growth, and for engineering teams who want to see their spend split by infrastructure type.
* **By region** — US East, EU West, APAC. Useful for organisations with regulatory, latency, or cost-allocation reasons to track spend by geography.
* **By team or product using tags or labels** — if your engineering teams tag their AWS resources or label their GCP resources, you can create cost layers that reflect those tags/labels, giving you per-team or per-product spend visibility directly in your forecast.
* **By business line** — Core Product, Data Pipeline, Internal Tools. Useful for companies with multiple products or revenue streams that want to understand cloud cost per product line.
You don't need to set up all of this on day one. Start with Production / Non-Production, get your forecast running, and add granularity as your needs become clearer. See [Cost Layers](/forecasting/cost-layers) for full details on managing and refining your structure over time.
***
## Getting there
Navigate to **Cost Allocation** using the left sidebar, or click **Cost Allocation** at the top of the **Cloud Provider Integrations** page.
The canvas shows a Sankey diagram flowing left to right. **Linked Accounts** sit on the left — your linked AWS accounts or GCP projects are always the starting point. In the middle, breakdown dimensions are flexible: by default this is **Product Code** (the AWS or GCP services within each account/project), but the columns between accounts and cost layers can vary. **Cost Layers** — your business categories — appear on the right.
Flow width represents spend volume. Colour indicates assignment status: green (assigned), amber (needs attention), peach (unallocated).
![Cost Allocation canvas showing Linked Account, Product Code, and Cost Layer columns connected by a Sankey flow diagram]()
***
## Mapping your resources
When you open Cost Allocation, click the **?** icon in the top-left of the canvas to open the mapping guide. You can take either path:
![Map Resources to Cost Layers guide showing the three-step flow from Accounts to Services to Cost Layers, with Help me map and I'll do it myself options]()
***
### Help me map (guided)
The guided flow walks through mapping in four steps. Cloud Capital suggests a cost layer structure based on your accounts and services — you review and adjust before anything is applied.
**Step 1 — Map your accounts**
Cloud Capital analyses your account names and suggests a cost layer structure — automatically grouping accounts into Production, Staging, or Security & Operations. If you have your own preferred structure, the suggestions are a starting point: every account can be overridden before anything is applied. The summary shows how many accounts landed in each suggested category.
Expand **Review or change assignments** to see every account with its suggested category and a dropdown to change it.
Non-production accounts (Staging, Dev, Sandbox) are assigned directly to their category. Everything else — including accounts Cloud Capital isn't confident about — defaults to Production. Check any account that doesn't look right before continuing.
![Step 1 expanded — each linked account shown with its auto-assigned category and a dropdown to change it]()
**Step 2 — Organise production accounts (optional)**
If you have multiple production accounts representing distinct products, teams, or pipelines, you can group them into named [sub-layers](/forecasting/cost-layers) under Production here. Type a name and click **Add layer**.
This step is optional — click **Skip, keep it flat** to leave all production accounts directly under Production and move on.
![Step 2 — optional production sub-layer creation with a text input and Add layer button]()
**Step 3 — Service cost breakdown**
Choose whether to split production spend by cloud service category:
* **Yes, group by service** — Cloud Capital creates sub-layers for Compute, Database & Storage, Networking & Delivery, and AI & Analytics under your selected cost layers. The preview at the bottom shows exactly which categories will be created under Production (COGS) and Non-Production (OpEx).
* **No, keep it simple** — production accounts map directly to their cost layer without service-level breakdown.
Use the checkboxes to select which cost layers get service sub-layers created beneath them.
![Step 3 — service breakdown options with category preview showing Compute, Database and Storage, Networking and Delivery, AI and Analytics under Production COGS]()
**Step 4 — Review and apply**
A full summary shows all account assignments and the cost layer structure that will be created. Review it, then click **Apply mapping** to write the changes to the canvas.
Applying the mapping only updates your local canvas view. Nothing is saved to your account until you click **Save Changes** in the toolbar.
![Step 4 — summary of account assignments and cost layer structure with Apply mapping button]()
***
### I'll do it myself (manual)
Dismiss the guide and work directly on the canvas. Click any node in the Sankey diagram — a linked account, a service, or a value in a breakdown column — to open a popup scoped to that node. What the popup offers depends on the node's current state:
**Unassigned node, with mapped siblings**
If a node hasn't been assigned yet but the other nodes in its column have, the popup flags it — **Unassigned while siblings are mapped** — and offers three actions:
* **Magic Assign this node** — runs the same auto-classification used by [Help me map](#help-me-map-guided) on just this node.
* **Split by dimension...** — break this node's spend down further before assigning. See "Splitting by dimension" below.
* **Assign to layer...** — opens the **Assign to Cost Layer** picker described below.
![Node popup on an unassigned service showing the "Unassigned while siblings are mapped" warning with Magic Assign, Split by dimension, and Assign to layer options]()
**Already-assigned node**
Clicking a node that's already mapped opens a different set of actions — **Split by service** (or by whichever dimension is active in that column), **Reassign to layer...**, and **Unassign**.
![Node popup on an already-assigned service showing its current cost layer plus Split by service, Reassign to layer, and Unassign options]()
**Assign to Cost Layer picker**
Choosing **Assign to layer...** or **Reassign to layer...** opens the same picker either way: your full [cost layer](/forecasting/cost-layers) tree with a search field. Click any leaf layer to assign the node to it. Hover any layer and click **+** to create a new child layer on the spot — useful if you want to add a sub-layer you didn't set up in the guided flow.
![Assign to Cost Layer picker showing the cost layer tree with search, Production COGS sub-layers, and Non-Production OpEx]()
**Splitting by dimension**
**Split by dimension...** opens a list of cloud dimensions (e.g. Service Category, Region) and tags/cost categories, each with a small preview of how the node's spend breaks down across its values. Pick one and Cloud Capital inserts it as a new column in the canvas, splitting the node into one sub-node per value — each of which gets its own popup so you can keep assigning, or split again by a different dimension.
![Split by Dimension panel showing Cloud Dimensions (Service Category, Region) and Tags & Cost Categories with breakdown previews]()
This is the fastest way to clear unallocated spend that doesn't map cleanly by service alone — you can drill into a whole linked account, a grouped "N small items" bucket, or a single service, at any level, by whatever dimension actually separates it out.
A grouped **"N small items"** bucket (Cloud Capital's catch-all for long-tail services) opens a simpler popup instead — **Assign manually...**, which opens an itemized list where you can assign, move, or unmap each underlying value individually (or **Promote** one out as its own node), and **Magic Assign**, which auto-classifies the whole bucket at once.
***
## Canvas controls
### Toolbar
| Button | What it does |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Save Changes** | Saves all mapping changes permanently. Only active when unsaved edits exist. |
| **Undo to Saved** | Reverts all unsaved changes to the last saved state. |
| **Manage Mappings** | Dropdown with two options: **Unmap All** removes all splits and assignments locally (reversible until saved); **Reset Cost Layers** permanently deletes all cost layers except Production & Non-Production — this cannot be undone. |
| **Done Editing** | Returns to read-only view. |
| **Manage Cloud Providers** | Opens the Cloud Provider Integrations page. |
![Manage Mappings dropdown open, showing Unmap All and Reset Cost Layers options with warning icons]()
### Filters
| Filter | What it does |
| -------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Coverage %** | Shows the percentage of total spend assigned to a cost layer. Aim for 90%+ before moving to forecasting. |
| **Unallocated only** | Filters the canvas to show only accounts and services not yet assigned — the fastest way to find remaining gaps. |
| **Hierarchy** | Toggles between leaf-level layers only and the full cost layer hierarchy. |
| **Current month** | Switches spend figures between current month and all-time totals. |
![Unallocated only filter active — canvas showing only unmapped product codes flowing to the Unallocated cost layer]()
The **+** / **−** buttons in the bottom-left corner zoom the canvas in and out. The icon below them resets to the default zoom.
***
## Saving your work
Changes are local until you click **Save Changes** in the toolbar. Navigate away without saving and your edits will be lost.
Once saved, your [Cost Layer](/forecasting/cost-layers) assignments feed directly into your Cloud Capital forecast. The structure you create here becomes the foundation your forecast, savings analysis, and commitment proposals are all built on.
***
## What's next
How the Help me map wizard categorises accounts and services — and how to get the best results.
Review and refine your cost layer structure, add sub-layers, and adjust assignments over time.
Connect business data to drive more accurate cost projections.
# Integrate OpenAI
Source: https://docs.cloudcapital.co/get-started/openai-data-integration
Connect OpenAI Platform organization API spend to Cloud Capital with an Admin API key. OpenAI support is currently in Beta.
**OpenAI support is in Beta.** To enroll, request access from your Cloud Capital Customer Success Manager. Once your account is enabled, **OpenAI** appears as an option on the New Integration page. If you don't see it yet, reach out to your Customer Success Manager.
Cloud Capital reads your **OpenAI Platform** organization API spend (projects, models, line items) from OpenAI's Admin Costs APIs. You paste an **OpenAI Admin API key**; the key is encrypted and stored on the integration. This path is **forecast-only**.
Setup takes about 5 minutes once you have an Admin API key.
***
### What Cloud Capital accesses
| What you're granting | How | Scope |
| -------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------- |
| OpenAI Admin API key | Pasted into the integration form, encrypted at rest | Read access to organization projects and costs APIs used by the nightly load |
Cloud Capital uses the key only to **read** cost data. Ordinary inference keys cannot call Admin APIs and will fail the connection test. This integration does not enable commitment purchasing or billing transfer.
### What's available with OpenAI today
| Available | Not yet available |
| ------------------------------------------------------------------------------- | ------------------------------------------- |
| Cost forecasting, cost insights, and cost allocation for Platform org API spend | Commitment purchasing through Cloud Capital |
| Daily-grain cost data from the Admin Costs API | Billing through Cloud Capital |
| | Per-user dollar breakout from this API |
| | ChatGPT Team or Enterprise seats |
***
### Before you begin
* **Choose this for Platform org API spend** — Usage billed in the OpenAI organization dashboard (projects, models, line items).
* **Admin API key** — Create an Admin key in the [OpenAI organization dashboard](https://platform.openai.com). Ordinary inference / project keys cannot call Admin APIs.
* **Not covered here** — ChatGPT Team or Enterprise seats. OpenAI usage billed through AWS Marketplace stays on your [AWS integration](/get-started/aws-data-integration) — connecting both paths for the same spend can double-count.
* **Grain** — Costs are daily. There is no per-user dollar breakout from this API.
This integration covers **OpenAI Platform organization API spend only**. It does not import ChatGPT Team or Enterprise seats. Keep AWS Marketplace-billed OpenAI usage on your AWS integration to avoid double-counting, and expect daily organization costs rather than per-user dollar totals.
### Setup
In Cloud Capital, go to the **Integrations** page — from Cost Allocation, use **Manage Cloud Providers**. Click **Create New Integration** and choose **OpenAI**.
The new integration opens on the Integration Settings page. Give it a descriptive name.
![OpenAI Integration Settings with Admin API key field]()
In the [OpenAI platform dashboard](https://platform.openai.com), open your **organization** settings and create an **Admin API key** (not a standard project or inference key).
Copy the key once at creation time.
See [OpenAI's Admin API documentation](https://platform.openai.com/docs/api-reference/administration) for how Admin keys differ from project API keys.
On the Integration Settings page:
1. Paste the Admin API key into the **OpenAI Admin API key** field.
2. Click **Test Connection**. Cloud Capital verifies it can reach OpenAI projects and organization costs with this Admin key (the same Costs API the nightly load uses).
3. After a successful test, set status to **Enabled** and click **Save**.
You must complete a successful connection test before you can enable a new integration. To rotate a key later, paste a new key and re-test; leave the field blank to keep the stored key.
***
### What to expect after setup
* **Data timing** — Cost data is ingested on a scheduled nightly cycle. Expect dashboards within about 24 hours of a successful connection.
* **Daily grain** — OpenAI costs land at daily resolution; there is no per-user dollar breakout from this Admin Costs path.
* **Forecast only** — Commitment purchasing and billing transfer are not part of this integration.
* **Cost allocation** — After ingest, OpenAI spend can appear in forecasting and cost insights. Mapping behavior for agentic providers may differ from AWS linked accounts; start from Cost Insights once data is present.
### Troubleshooting
| Symptom | What to check |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| OpenAI card missing or Coming Soon | Your org is not enrolled yet. Ask your Customer Success Manager to enable `openai`. |
| Connection test fails | Confirm you pasted an **Admin** API key from the organization dashboard, not an inference or project-only key. |
| ChatGPT seats missing | Not covered by this integration — Platform org API spend only. |
| Marketplace OpenAI also on AWS CUR | Keep Marketplace spend on AWS only for that path. Connecting both for the same usage can double-count. |
| Test passes but dashboards are empty | Allow up to 24 hours for nightly ingest. Confirm the OpenAI org dashboard shows recent API spend. |
***
For a full overview of how Cloud Capital handles data access, encryption, audit logging, and compliance, see the Security page.
# Single sign-on (SSO)
Source: https://docs.cloudcapital.co/get-started/sso
Set up OIDC-based single sign-on for your Cloud Capital organization.
Single sign-on (SSO) allows your team to authenticate with Cloud Capital using your organization's identity provider via OpenID Connect (OIDC). You can enable SSO through self-service in **Organization Settings**.
For a broader overview of how Cloud Capital handles authentication, data access, and security controls, see the [Security](/security) page.
## Prerequisites
* You must be an organization admin in Cloud Capital.
* You need access to your identity provider's admin console to create an OIDC application and retrieve its configuration values.
* You need access to your domain's DNS settings to add a verification record.
Before configuring your identity provider, navigate to **Organization Settings → SSO** to find Cloud Capital's **Redirect URI**. You will need the following values when creating the OIDC application in your IdP:
| Field | Value |
| ------------------------- | ------------------------------------------------------ |
| Redirect / Callback URI | `https://app.cloudcapital.co/api/v1/auth/sso/callback` |
| Initiate Login URI (Okta) | `https://app.cloudcapital.co/v1/auth/sso/initiate` |
## Set up SSO
Navigate to **Organization Settings** and select the **SSO** tab.
Enter the following values from your identity provider:
* **Issuer URL** — the OIDC issuer URL from your identity provider (e.g., `https://accounts.google.com` or `https://login.microsoftonline.com/{tenant}/v2.0`).
* **Client ID** — the client identifier assigned to Cloud Capital in your identity provider.
* **Client Secret** — the client secret generated for the Cloud Capital application.
* **Email Domain** — the email domain for users who should sign in via SSO (e.g., `yourcompany.com`).
Cloud Capital validates that the issuer URL belongs to a recognized identity provider domain. If your organization uses a **custom or vanity domain** for your IdP (for example, a company-branded Okta URL like `https://login.yourcompany.io/` instead of `https://yourcompany.okta.com/`), you may see an "Untrusted origin" error. Contact [Cloud Capital support](mailto:support@cloudcapital.co) to have your domain added to the allowlist.
The SSO settings page displays Cloud Capital's **Redirect URI** (`https://app.cloudcapital.co/api/v1/auth/sso/callback`). Make sure this value is added as an allowed redirect/callback URI in your identity provider's OIDC application settings.
Add the DNS record displayed in the SSO settings to your domain's DNS configuration. This verifies that you own the domain and allows Cloud Capital to associate SSO logins with your organization.
DNS propagation can take up to 48 hours, though it typically completes within a few minutes.
Select how SSO is enforced for your organization:
* **Optional** — members can sign in with SSO or with their existing email and password. Use this while rolling out SSO or if some users need non-SSO access.
* **Required** — all members must sign in through SSO. Email and password login is disabled for your organization.
Click **Save** to enable SSO. Members matching your verified domain will be able to sign in using your identity provider on their next login.
## User provisioning
When a user signs in via SSO for the first time, Cloud Capital automatically creates an account for them using their identity provider profile. New SSO-provisioned users are granted **member** permissions by default.
If a user requires **admin** access, an existing organization admin must update their role manually after their first sign-in. To do this, navigate to **Organization Settings → Members**, find the user, and update their role.
Cloud Capital uses SP-initiated OIDC. Users can sign in from the Cloud Capital login page, or from an Okta app tile using the Initiate Login URI above — Okta redirects to Cloud Capital, which then starts the authorization flow. True IdP-initiated SAML (where the IdP sends an assertion without a prior request) is not supported.
## Common identity providers
Most OIDC-compliant identity providers work with Cloud Capital SSO, including:
* Google Workspace
* Microsoft Entra ID (Azure AD)
* Okta
* Auth0
* OneLogin
Refer to your identity provider's documentation for instructions on creating an OIDC application and retrieving the issuer URL, client ID, and client secret.
## Okta configuration
Okta OIDC apps require two URLs to be configured — one for the OAuth callback, and one for the Okta app tile launch. Missing the second URL means SSO works from the Cloud Capital login page but fails when users click the app icon in their Okta dashboard.
In your Okta OIDC application settings, set the following:
| Okta field | Value |
| ------------------------ | ------------------------------------------------------ |
| **Sign-in redirect URI** | `https://app.cloudcapital.co/api/v1/auth/sso/callback` |
| **Initiate Login URI** | `https://app.cloudcapital.co/v1/auth/sso/initiate` |
| **Login flow** | Redirect to app to initiate login (OIDC Compliant) |
The Initiate Login URI is the entry point for Okta-dashboard-launched sign-ins. Okta appends an `iss` query parameter identifying your Okta org, and Cloud Capital uses this to resolve your SSO configuration and start the authorization flow — ending at the same sign-in outcome as if the user had started from the Cloud Capital login page.
The **Sign-out redirect URI** and **Callback URI** fields in Okta are different things. Only the Sign-in redirect URI listed above needs to be set for Cloud Capital SSO to function.
## Troubleshooting
| Issue | Solution |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Domain verification pending | Confirm the DNS record matches the value shown in SSO settings. Allow time for DNS propagation. |
| Login fails after enabling SSO | Verify the issuer URL, client ID, and client secret are correct. Check that `https://app.cloudcapital.co/api/v1/auth/sso/callback` is set as an allowed redirect URI in your identity provider. |
| Users not prompted for SSO | Ensure enforcement is set to **Required**, or confirm the user's email domain matches the verified domain. |
| "Untrusted origin" error on issuer URL | Your IdP uses a custom or vanity domain that isn't on Cloud Capital's allowlist. Contact [support](mailto:support@cloudcapital.co) to have it added. |
| Okta app tile doesn't redirect correctly | Set the **Initiate Login URI** in your Okta OIDC app to `https://app.cloudcapital.co/v1/auth/sso/initiate` and set **Login flow** to "Redirect to app to initiate login (OIDC Compliant)". |
# Glossary
Source: https://docs.cloudcapital.co/glossary
Definitions of key terms used throughout Cloud Capital's customer documentation.
This glossary defines key terms used across Cloud Capital's customer documentation. For context on how these terms relate to the onboarding process, refer to the [Commitment Proposal & Onboarding Process](/optimization/commitment-proposal-onboarding) page.
***
A detailed billing data file provided by AWS that records every metered resource charge, hour by hour. Cloud Capital uses CUR data as the primary source of truth when analyzing a customer's historical spend and building commitment proposals. The current version is CUR 2.0; some exports may still use the older 1.0 format. Cloud Capital prefers CUR 2.0, as it provides more complete cost information and is the current AWS standard.
Customer-provided operational data points — such as headcount, transaction volumes, active users, or seasonal patterns — that Cloud Capital uses to improve the accuracy of the spend forecast. Incorporating business metrics allows commitments to reflect anticipated changes in the business, not just historical trends.
A discount applied by Cloud Capital to a customer's standard AWS usage charges, passed through as a separate line item on the monthly Cloud Capital invoice. Cloud Discount applies to all standard AWS usage — AWS Marketplace charges and AWS Support costs are excluded. The discount rate is determined during the savings assessment and forms part of the overall Cloud Capital value proposition alongside commitment savings.
The portion of a customer's AWS spend that is eligible to be covered by a savings commitment such as a Compute Savings Plan, Database Savings Plan, or Reserved Instance. Not all spend is committable — services like data transfer or support are excluded.
GCP's commitment-based discount mechanism, analogous to AWS's Reserved Instances and Savings Plans — a customer commits to a consistent level of usage over a 1- or 3-year term in exchange for a discount compared to On-Demand pricing. Cloud Capital reads CUD subscription data (via the CUD subscriptions BigQuery export) to provide commitment inventory and performance visibility for GCP customers. Commitment purchasing through Cloud Capital is not yet available for GCP.
Cloud Capital's structured approach to building commitment coverage in four incremental steps rather than all at once. Each step covers approximately 50% of the remaining uncommitted spend, allowing the forecast to be refined between steps and giving the customer full visibility into each commitment before it is purchased.
An AWS commitment to a consistent hourly spend on compute usage (EC2, Fargate, Lambda) in exchange for a discount of up to 66% compared to On-Demand pricing. Available in 1-year and 3-year terms. Cloud Capital uses these as the primary commitment vehicle for general compute workloads. Compute Savings Plans apply to usage across Amazon EC2, AWS Lambda, and AWS Fargate.
A named category that cloud spend is mapped to within Cloud Capital. Every dollar of cloud spend flows into a Cost Layer, and the resulting structure becomes the foundation for forecasting, savings analysis, and commitment proposals. The default top-level layers are Production (COGS) and Non-Production (OpEx), with optional sub-layers for more granular visibility by product, team, region, or service family. See also: [Production (COGS)](#production-cogs) and [Non-Production (OpEx)](#non-production-opex).
An AWS commitment to a consistent hourly spend on eligible database services (RDS, Aurora) in exchange for discounts of up to 60% compared to On-Demand pricing. Available in 1-year terms. Cloud Capital proposes these alongside Compute Savings Plans for customers with significant database workloads.
Database Savings Plans provide coverage across Amazon Aurora, Amazon RDS, Amazon DynamoDB, Amazon ElastiCache, Amazon DocumentDB (with MongoDB compatibility), Amazon Neptune, Amazon Keyspaces (for Apache Cassandra), Amazon Timestream, AWS Database Migration Service (DMS), and Amazon OpenSearch Service. As new database services become eligible, they will automatically be included in coverage for your existing Database Savings Plans commitments.
The primary metric Cloud Capital uses to measure the efficiency of cloud spend optimisation. Calculated as Total Savings ÷ Total On-Demand Cost, expressed as a percentage. An ESR of 8% means that for every dollar of on-demand-equivalent spend, you save \$0.08. The ESR reflects Cloud Capital's direct contribution (commitments and Cloud Discount) and is tracked over time on the Savings page.
An AWS commercial agreement that offers custom pricing in exchange for a committed annual spend level over a multi-year term. Organisations with an active EDP may use Cloud Capital's In-Place Commitment Management while their agreement runs, with a planned transition to full Cloud Capital once the EDP expires or when they are ready to move.
Cloud Capital's projection of a customer's future cloud spend, derived from historical cost and usage data (AWS CUR, or GCP's BigQuery billing export) and refined over time by incorporating customer-provided business metrics and upcoming initiatives. The forecast directly informs the size and term mix of each ladder step.
Google Cloud's equivalent of the AWS CUR — a detailed billing dataset that GCP writes to a BigQuery table you control. Cloud Capital reads two separate exports: the **Standard usage cost** export (cost and usage data) and the **Committed Use Discount (CUD) subscriptions** export (commitment data). Unlike AWS CUR, GCP does not backfill history — an export only contains data from the date it was enabled.
A contractual commitment from Cloud Capital that guarantees a customer a minimum level of savings relative to On-Demand AWS pricing. The GSR ensures that customers benefit from long-term commitment discounts while Cloud Capital absorbs the financial risk of holding those commitments. This is a key differentiator of the Cloud Capital service model.
A Cloud Capital product option for organisations with an existing AWS Enterprise Discount Program (EDP), Private Pricing Agreement (PPA), or Managed Service Provider (MSP) agreement they want to retain or run down to expiry. Cloud Capital manages commitments within the existing AWS structure rather than replacing it, and a transition path to full Cloud Capital is planned for when the agreement expires or when the customer is ready to move.
A known upcoming change to a customer's cloud environment, such as a new product launch, a platform migration, or a planned decommission. Initiatives are factored into the forecast during ladder-up so that commitment levels account for expected future changes rather than relying solely on past spend.
The unique identifier for a specific Cloud Capital integration, found in the Cloud Capital app at **Integrations**. For AWS integrations, this value is used as the `sts:ExternalId` in the cross-account IAM trust policy — it is not the same as your Cloud Capital Organization ID (`org_...`), which is a different identifier shown elsewhere in the app. Using the wrong ID here is the most common cause of a failed AWS role assumption.
An AWS Partner Network member that manages cloud infrastructure on behalf of customers under an AWS-recognised MSP agreement. Organisations with an active MSP arrangement may use Cloud Capital's In-Place Commitment Management while that agreement is in place, with a path to full Cloud Capital when ready.
The ongoing review cadence that replaces weekly meetings once the customer's initial commitment ladder is complete. Monthly reviews focus on commitment performance, forecast updates, and identification of new optimization opportunities as the customer's environment evolves.
One of the default top-level Cost Layers in Cloud Capital. Covers infrastructure used for development, staging, testing, and internal tooling — Operating Expenditure in financial terms. Non-Production spend is necessary business cost but is not directly tied to serving customers, and is treated differently from Production (COGS) in financial reporting and margin analysis.
The standard AWS pricing model in which customers pay for compute or database resources by the hour or second with no long-term commitment. Savings Plans and Reserved Instances provide discounts relative to On-Demand rates.
An AWS negotiated pricing arrangement for customers with significant spend, offering custom discounts outside standard AWS rate cards. Organisations with an active PPA may use Cloud Capital's In-Place Commitment Management while their agreement runs, with a transition path to full Cloud Capital once the PPA expires.
One of the default top-level Cost Layers in Cloud Capital. Covers infrastructure that directly supports a live product or service — Cost of Goods Sold (COGS) in financial terms. Production spend scales with revenue and is treated as a direct cost of delivery in financial reporting, making it distinct from Non-Production (OpEx) for margin analysis and budgeting.
The forecasting methodology applied to a Cost Layer, determining how Cloud Capital projects future spend for that layer. Four options are available: **Trend** (extrapolates historical trajectory), **Fixed Percentage** (applies a specified growth rate per period), **Flat** (holds spend level with most recent actuals — the default), and **Metric - Auto** (drives the forecast from a correlated Business Metric). Projection types can be set independently per Cost Layer and inherited by child layers.
A 45–60 minute structured review between a customer and the Cloud Capital team, covering savings performance, forecast accuracy, business updates, and planning for the period ahead. Run at least quarterly for commitment customers, and also triggered by events such as a new stakeholder joining or a significant change in business trajectory. See [Business Reviews (QBR / MBR)](/optimization/qbr) for full details.
An AWS commitment to a specific instance type, region, and optionally a specific Availability Zone, in exchange for a discount compared to On-Demand pricing. RIs can offer deeper discounts than Savings Plans for predictable, stable workloads but are less flexible. Cloud Capital monitors RI utilization and proposes replacements or conversions as usage patterns evolve.
The structural arrangement by which Cloud Capital absorbs the financial risk of AWS commitments on the customer's behalf. The commitments themselves are held by Cloud Capital, but the customer does not bear the financial exposure if their usage decreases or shifts. This is paired with the Guaranteed Savings Rate to give customers both certainty and protection.
An umbrella term covering both Compute Savings Plans and Database Savings Plans — AWS's flexible commitment model where customers commit to a minimum hourly spend rather than a specific resource type. See individual entries for Compute Savings Plan and Database Savings Plan.
The duration of an AWS commitment. 1-year terms offer more flexibility with moderate discounts; 3-year terms deliver the deepest discounts but require a longer commitment horizon. Cloud Capital recommends a mix based on each customer's risk tolerance, forecast confidence, and savings objectives.
The degree to which a purchased commitment (Savings Plan or Reserved Instance) is being consumed by actual AWS usage. Cloud Capital monitors utilization continuously to ensure commitments remain fully used and to flag any coverage gaps or over-commitment that should be addressed.
A regular meeting held between Cloud Capital and the customer during the ladder-up phase. Each session reviews the current forecast, approves or adjusts the next commitment step, and incorporates any new business information. Once the ladder-up is complete, the cadence transitions to monthly reviews.
A category of cloud cost reduction focused on running infrastructure more efficiently — right-sizing compute resources, reducing idle capacity, and tuning applications to consume less CPU, memory, and storage. Workload optimization operates at the application and cluster level and is complementary to commitment optimization (Cloud Capital's focus). Specialist AWS Partner Network vendors focus on this area.
***
Terms and definitions may be updated as Cloud Capital's service offering evolves. For questions, contact your Cloud Capital account manager.
# Getting started
Source: https://docs.cloudcapital.co/introduction
**Welcome to Cloud Capital!**
![Forecast Preview]()
**Time to complete:** \~25 minutes
**This guide will walk you through connecting your cloud provider data to Cloud Capital.**
## Integration Steps
### Step 1: Connect a cost data source
* **Who:** Engineering / DevOps team
* **Time to complete:** \~10 minutes
* ***Required*** - Connect the source that holds the cost data you want Cloud Capital to forecast. Choose the matching guide:
Connect your AWS cost and usage data.
Connect your Google Cloud cost and commitment data.
Connect Anthropic Console (Claude API) organization spend.
Connect Claude.ai Enterprise usage and seats.
Connect OpenAI Platform organization API spend.
Connect Cursor Teams usage and seat spend.
### Step 2: Map your Cloud Costs to Production/Non-Production
* **Who:** Engineering / DevOps team
* **Time to complete:** \~15 minutes
* View the Engineering Quickstart guide:
* [Map Cloud Resources](/get-started/map-cloud-resources) - ***Required*** for cloud infrastructure providers — Map your imported consumption data (Cloud Resources) to your Forecast's Cost Layers. API and seat-based sources appear in forecasting and cost insights after nightly ingest; start there once data is present.
**Note:** once you connect your cloud provider data, it typically takes 24 hours to appear in your dashboard.
**Ready to get started?** Choose your source from Step 1, then follow its setup guide.
# Billing & Payments — Cloud Discount
Source: https://docs.cloudcapital.co/optimization/billing-cloud-discount
How Cloud Discount appears on your invoices and what it applies to.
If you are a customer billed directly by Cloud Capital — rather than through the AWS Marketplace — your AWS savings are delivered as a **Cloud Discount**. This is a discount applied to your AWS usage and passed through on your monthly Cloud Capital invoice.
***
## What Cloud Discount applies to
Cloud Discount is applied to all AWS usage charges with the following exceptions:
* **AWS Marketplace** charges — third-party software and services purchased through the Marketplace are excluded
* **AWS Support** charges — support plan fees are excluded regardless of tier
* **PPA / EDP spend** — any usage already covered under an AWS Private Pricing Agreement or Enterprise Discount Program cannot have Cloud Discount applied on top
Everything else — compute, storage, database, networking, and other standard AWS service usage — is eligible.
***
## How it appears on your invoice
Cloud Discount appears as a **separate line item** on your monthly Cloud Capital invoice. It is not embedded within the individual service charges — your underlying AWS usage lines remain unchanged. The discount is applied and shown as a single credit line, making it straightforward to reconcile and report.
***
## Related pages
How billing works for commitment-only customers using the AWS Marketplace.
Track commitment performance and savings over time in the Cloud Capital app.
How the GSR is calculated and what it guarantees.
Common questions about risk, billing models, and the review process.
# Billing & Payments — Marketplace
Source: https://docs.cloudcapital.co/optimization/billing-marketplace
How Cloud Capital billing works for commitment-only customers using the AWS Marketplace.
If you are a commitment-only customer — where your AWS relationship remains direct and Cloud Capital purchases commitments in-place within your AWS Organization — your billing runs through the **AWS Marketplace**. This page explains how that billing works, what to expect on your invoices, and how the Guaranteed Savings Rate adjustment appears each month.
***
## Setting up Marketplace billing
Before billing can begin, you need to accept a private offer from Cloud Capital via the AWS Marketplace. This is a one-time setup step completed during onboarding.
**How to accept your private offer:**
1. Cloud Capital will confirm which AWS Account ID you would like the offer sent to.
2. You will receive an email with the subject line: *"Your private offer in AWS Marketplace is ready to accept"* — sent from **[no-reply@suger.cloud](mailto:no-reply@suger.cloud)**.
3. In the email, click the **Private offer link** under *"Step 2: Review and accept the private offer"*.
4. This takes you to the AWS Marketplace where you can review and accept the offer.
If you are the root owner of the AWS account, you will also receive a separate notification directly from AWS in addition to the Suger email.
***
## Your monthly invoices
As a commitment-only customer, you will receive **two invoices from AWS each month**.
### Invoice 1 — AWS Usage Invoice
This is your standard AWS bill, issued directly from AWS as it always has been. It covers your infrastructure usage, support, and any other AWS charges. Nothing changes here — this invoice continues on its existing schedule regardless of your Cloud Capital arrangement.
### Invoice 2 — AWS Marketplace Invoice
This invoice arrives approximately **one month after your AWS usage invoice** and is issued directly from AWS via the Marketplace. It contains a single Cloud Capital line item — the **GSR adjustment** — which appears under:
> *Cloud Capital Technologies Holdings Inc*
This adjustment is how Cloud Capital ensures you achieve your [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate) every month, regardless of how commitments performed.
***
## How the GSR adjustment works
The GSR adjustment on your Marketplace invoice is a true-up mechanism. It reconciles actual commitment performance against your [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate) each month. Because commitment utilization naturally varies — your AWS usage fluctuates, workloads shift, and the mix of on-demand vs committed spend changes month to month — the adjustment keeps your effective savings rate anchored to the GSR regardless of that variability. Depending on how commitments performed that month, it appears as either a **fee** or a **rebate**. See [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate) for a full explanation of how the rate is calculated and what it covers.
**When it appears as a fee:**
If your commitments over-performed — generating savings above your guaranteed rate — Cloud Capital charges a fee that captures the value delivered beyond the guarantee. You still receive your full GSR in net savings; the fee reflects Cloud Capital's share of the outperformance.
**When it appears as a rebate:**
If your commitments under-performed — generating less savings than your guaranteed rate — Cloud Capital issues a rebate to make you whole. Your net savings position is brought back up to exactly the GSR level.
Either way, the result is the same: your effective savings rate for the month equals your guaranteed rate. The Marketplace invoice is the mechanism that keeps that promise regardless of month-to-month variability in commitment utilization.
***
## Example billing timeline
| Period | Event |
| -------------- | ----------------------------------------------------------- |
| 1–31 January | AWS usage period |
| Early February | AWS usage invoice issued |
| Early March | AWS Marketplace invoice issued (GSR adjustment for January) |
The approximately one-month lag between your usage invoice and the Marketplace invoice is standard AWS Marketplace billing behavior.
***
## Viewing your net position in Cloud Capital
Within the Cloud Capital application, **Cost Insights** and **Cloud Bills** display your net savings position. This reflects:
* Your AWS commitment savings for the period
* Adjusted for the GSR fee or rebate from the Marketplace invoice
The result is a clear, accurate view of your effective savings rate — what you actually saved, net of all adjustments, expressed as a single number you can use for reporting and planning.
For a full breakdown of how savings are tracked and reported over time, see [Savings Realisation](/optimization/savings-realisation).
***
## Related pages
How the GSR is calculated and what it guarantees.
Track commitment performance and savings over time in the Cloud Capital app.
How Cloud Capital is authorized to purchase commitments within your AWS Organization.
How Cloud Discount works for customers billed directly by Cloud Capital.
Common questions about risk, billing models, and the review process.
# Commitment Purchasing Authorization
Source: https://docs.cloudcapital.co/optimization/cloud-provider-account
How Cloud Capital is authorized to purchase AWS Savings Plans and Reserved Instances on your behalf.
Cloud Capital purchases AWS Savings Plans and Reserved Instances on your behalf using a dedicated AWS account and a cross-account IAM role. No root access to your AWS Organization is required, and your existing AWS Organization structure, account ownership, and infrastructure are not affected.
***
## How commitment purchasing works
Cloud Capital purchases commitments into a **dedicated, empty AWS account** that you create within your existing AWS Organization. This is how AWS Savings Plans and Reserved Instances are designed to work: when purchased in any account within an AWS Organization, the discount automatically applies to matching usage across **all member accounts** in the Organization — not just the account where the commitment was purchased. AWS handles this distribution automatically, with no additional configuration required on your end.
The dedicated account stays empty of workloads by design. Because AWS applies commitment discounts to wherever the matching usage occurs across your Organization, keeping the purchasing account empty ensures the full benefit flows to your actual workloads.
Cloud Capital accesses this account through an IAM role provisioned via CloudFormation. The role is scoped exclusively to purchasing and managing commitments — it has no read access to your cost data and no visibility into any of your workload accounts.
Root access to your AWS Organization or management account is not required at any point. All purchasing is performed through the scoped IAM role in the dedicated commitment account.
***
## Commitment models
Cloud Capital supports two commitment purchasing models depending on your AWS relationship:
### AWS Billing Transfer customers
If you are an AWS Billing Transfer customer, Cloud Capital is your payer of record. Commitments are purchased on your behalf through the dedicated commitment account within your AWS Organization, and discounts flow across your member accounts automatically. Follow the setup steps below.
### In-Place commitment customers
If your organization has a direct AWS relationship — including a Private Pricing Agreement (PPA), Enterprise Discount Program (EDP), or if you are working with an AWS Managed Service Provider (MSP) — Cloud Capital can purchase commitments **in-place** within your existing AWS Organization.
The setup is the same: create a dedicated, empty account in your Organization and deploy the Optimization CloudFormation stack into it. Cloud Capital purchases commitments through that account, and AWS distributes the discounts across your Organization as normal. Your direct AWS relationship, PPA/EDP pricing, and MSP arrangement are all preserved.
In-Place commitments work identically to Billing Transfer from a technical standpoint. The difference is only in who acts as the payer of record — your existing arrangement with AWS remains unchanged.
***
## Setting up the dedicated commitment account
### What Cloud Capital accesses
The [Optimization CloudFormation template](/cloudformation/aws-cloudformation-optimization.json) creates an IAM role scoped exclusively to purchasing and managing commitments in the dedicated account.
| Purpose | AWS Services Used |
| ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Purchase and manage Savings Plans | `savingsplans:*` |
| Purchase EC2 Reserved Instances | `ec2:PurchaseReservedInstancesOffering` and related EC2 RI actions |
| Purchase RDS, Redshift, ElastiCache, and OpenSearch Reserved Instances | `rds:PurchaseReservedDbInstancesOffering`, `redshift:PurchaseReservedNodeOffering`, `elasticache:PurchaseReservedCacheNodesOffering`, `es:PurchaseReservedInstanceOffering` |
| Create service-linked roles required by AWS during first purchase | `iam:CreateServiceLinkedRole` |
| Manage service quota increases when required | `servicequotas:*`, `support:*` |
The Optimization role has **no read access** to your cost data, billing APIs, or any of your workload accounts. It is scoped exclusively to the dedicated commitment account and can only take the purchasing actions listed above.
**Terraform-only shops:** if your organization requires all infrastructure changes to go through Terraform, see [Terraform Setup for the Optimization Role](/optimization/cloud-provider-account-terraform) for the equivalent IAM role and policy JSON instead of using the CloudFormation stack below.
### Setup
In your AWS Organization, create a new empty account. This account will hold all commitments Cloud Capital purchases on your behalf. It must contain no running workloads or resources — this ensures AWS distributes commitment discounts optimally across your Organization.
See [Creating an AWS account in your organization](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html) in the AWS documentation.
In the dedicated commitment account, deploy the [Optimization CloudFormation template](/cloudformation/aws-cloudformation-optimization.json). Cloud Capital pre-populates the required parameters — no manual entry needed.
Once the stack completes, copy the **Role ARN** from the stack Outputs tab.
Provide the Role ARN to your Cloud Capital representative, or paste it into the Cloud Capital application as directed during onboarding. This completes the authorization and enables Cloud Capital to begin purchasing commitments on your behalf.
***
## What Cloud Capital can and cannot do
| | Commitment purchasing account | Management / payer account |
| ----------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------- |
| Purchase Savings Plans and Reserved Instances | Yes | No |
| Read cost and usage data (CUR, billing, pricing APIs) | No | Yes — via the Forecasting role |
| Access running workloads or resources | No | No |
| Modify IAM policies or account settings | No | No |
| Revoke at any time | Yes — delete the Optimization CloudFormation stack | Yes — delete the Forecasting CloudFormation stack |
All commitment customers must also have the Forecasting role deployed. Cloud Capital uses that role — installed in your management or payer account — to read cost and usage data and size commitments accurately. The two roles are separate and independently revocable.
***
## Viewing commitments and purchase history
All active commitments, utilization, and purchase history are visible in the Cloud Capital application. During the weekly review cadence, your Cloud Capital team walks through commitment performance, upcoming renewals, and any proposed new purchases — each of which requires your approval before being executed.
For more on the review process, see [Commitment Proposal & Onboarding](/optimization/commitment-proposal-onboarding).
# Terraform Setup for the Optimization Role
Source: https://docs.cloudcapital.co/optimization/cloud-provider-account-terraform
For customers who manage all AWS infrastructure via Terraform: create the Cloud Capital Optimization role without using the CloudFormation template.
Cloud Capital normally provisions the [Optimization role](/optimization/cloud-provider-account) using a CloudFormation template deployed into your dedicated commitment account. If your organization requires that **all** infrastructure changes go through Terraform, you can create the equivalent IAM role directly — the role's trust policy, permissions, and function are identical to the CloudFormation version.
This page only covers the **Optimization role** (commitment purchasing). If you haven't already reviewed how commitment purchasing works and the dedicated commitment account model, start with [Commitment Purchasing Authorization](/optimization/cloud-provider-account) first.
***
## What this role does
The Optimization role is assumed by Cloud Capital's AWS account to purchase and manage Savings Plans and Reserved Instances **in your dedicated, empty commitment account only**. It has no read access to your cost data, no visibility into workload accounts, and cannot modify IAM policies or account settings. See [What Cloud Capital can and cannot do](/optimization/cloud-provider-account#what-cloud-capital-can-and-cannot-do) for the full breakdown.
***
## Required parameters
Your Terraform configuration needs the following three values:
| Parameter | Value |
| ------------------------------- | --------------------------------------------- |
| `param_CrossAccountRoleName` | `CloudCapitalOptimizationRole` |
| `param_CloudCapitalAccountRole` | `708317008333` |
| `param_CloudCapitalExternalId` | Your Cloud Capital Integration ID — see below |
Find your `CloudCapitalExternalId` in the Cloud Capital application at [app.cloudcapital.co/integrations](https://app.cloudcapital.co/integrations) — it's labeled **Integration ID** there. It's a UUID, e.g. `a1b2c3d4-e5f6-7890-abcd-ef1234567890`.
***
## IAM policy JSON
The two policy documents below are extracted directly from Cloud Capital's Optimization CloudFormation template. Import or reference them as-is in your Terraform configuration — do not modify the actions, effects, or condition keys.
### Trust policy (assume role policy)
This policy allows only Cloud Capital's AWS account to assume the role, and only when the correct External ID is presented.
```json trust-policy.json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "708317008333"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": ""
}
}
}
]
}
```
Replace `` with your Cloud Capital Integration ID from [app.cloudcapital.co/integrations](https://app.cloudcapital.co/integrations).
### Permissions policy
This policy scopes the role to purchasing and managing commitments only.
```json permissions-policy.json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:PurchaseReservedCapacityOfferings",
"athena:CancelCapacityReservation",
"athena:CreateCapacityReservation",
"athena:DeleteCapacityReservation",
"athena:PutCapacityAssignmentConfiguration",
"athena:UpdateCapacityReservation",
"bedrock:CreateProvisionedModelThroughput",
"bedrock:DeleteProvisionedModelThroughput",
"bedrock:UpdateProvisionedModelThroughput",
"cloudfront:CreateSavingsPlan",
"cloudfront:UpdateSavingsPlan",
"memorydb:PurchaseReservedNodesOffering",
"memorydb:TagResource",
"ec2:AcceptReservedInstancesExchangeQuote",
"ec2:CancelReservedInstancesListing",
"ec2:CreateReservedInstancesListing",
"ec2:DeleteQueuedReservedInstances",
"ec2:Describe*",
"ec2:GetCapacityReservationUsage",
"ec2:GetReservedInstancesExchangeQuote",
"ec2:ModifyReservedInstances",
"ec2:PurchaseHostReservation",
"ec2:PurchaseReservedInstancesOffering",
"elasticache:PurchaseReservedCacheNodesOffering",
"es:PurchaseReservedInstanceOffering",
"medialive:PurchaseOffering",
"rds:PurchaseReservedDbInstancesOffering",
"redshift:AcceptReservedNodeExchange",
"redshift:PurchaseReservedNodeOffering",
"savingsplans:*",
"servicequotas:*",
"support:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole"
],
"Resource": "*"
}
]
}
```
***
## Example Terraform configuration
The following wires the two policy documents above together with the required parameters using standard `aws_iam_role` and `aws_iam_role_policy` resources.
```hcl main.tf theme={null}
variable "cross_account_role_name" {
description = "The name of the cross account role that Cloud Capital will assume"
type = string
default = "CloudCapitalOptimizationRole"
}
variable "cloud_capital_account_id" {
description = "The Cloud Capital AWS account that will assume the role"
type = string
default = "708317008333"
}
variable "cloud_capital_external_id" {
description = "The Integration ID from app.cloudcapital.co/integrations"
type = string
}
resource "aws_iam_role" "cloud_capital_optimization" {
name = var.cross_account_role_name
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = ""
Effect = "Allow"
Principal = {
AWS = var.cloud_capital_account_id
}
Action = "sts:AssumeRole"
Condition = {
StringEquals = {
"sts:ExternalId" = var.cloud_capital_external_id
}
}
}
]
})
}
resource "aws_iam_role_policy" "cloud_capital_optimization_policy" {
name = "CloudCapitalOptimizationPolicy"
role = aws_iam_role.cloud_capital_optimization.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Effect = "Allow"
Action = [
"dynamodb:PurchaseReservedCapacityOfferings",
"athena:CancelCapacityReservation",
"athena:CreateCapacityReservation",
"athena:DeleteCapacityReservation",
"athena:PutCapacityAssignmentConfiguration",
"athena:UpdateCapacityReservation",
"bedrock:CreateProvisionedModelThroughput",
"bedrock:DeleteProvisionedModelThroughput",
"bedrock:UpdateProvisionedModelThroughput",
"cloudfront:CreateSavingsPlan",
"cloudfront:UpdateSavingsPlan",
"memorydb:PurchaseReservedNodesOffering",
"memorydb:TagResource",
"ec2:AcceptReservedInstancesExchangeQuote",
"ec2:CancelReservedInstancesListing",
"ec2:CreateReservedInstancesListing",
"ec2:DeleteQueuedReservedInstances",
"ec2:Describe*",
"ec2:GetCapacityReservationUsage",
"ec2:GetReservedInstancesExchangeQuote",
"ec2:ModifyReservedInstances",
"ec2:PurchaseHostReservation",
"ec2:PurchaseReservedInstancesOffering",
"elasticache:PurchaseReservedCacheNodesOffering",
"es:PurchaseReservedInstanceOffering",
"medialive:PurchaseOffering",
"rds:PurchaseReservedDbInstancesOffering",
"redshift:AcceptReservedNodeExchange",
"redshift:PurchaseReservedNodeOffering",
"savingsplans:*",
"servicequotas:*",
"support:*"
]
Resource = "*"
},
{
Effect = "Allow"
Action = ["iam:CreateServiceLinkedRole"]
Resource = "*"
}
]
})
}
output "cloud_capital_optimization_role_arn" {
description = "Role ARN for Cloud Capital"
value = aws_iam_role.cloud_capital_optimization.arn
}
```
Deploy this into the same **dedicated, empty commitment account** described in [Commitment Purchasing Authorization](/optimization/cloud-provider-account#setting-up-the-dedicated-commitment-account) — not your management/payer account and not an account running workloads.
***
## Setup
If you haven't already, create a new empty account in your AWS Organization to hold all commitments Cloud Capital purchases on your behalf. See [Creating an AWS account in your organization](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html).
Sign in to the Cloud Capital application and copy the **Integration ID** from [app.cloudcapital.co/integrations](https://app.cloudcapital.co/integrations). It's a UUID, e.g. `a1b2c3d4-e5f6-7890-abcd-ef1234567890`.
Add the configuration above to your Terraform codebase, set `cloud_capital_external_id` to the value from the previous step, and apply it in the dedicated commitment account.
After apply completes, copy the `cloud_capital_optimization_role_arn` output and provide it to your Cloud Capital representative, or paste it into the Cloud Capital application as directed during onboarding. This completes the authorization.
All commitment customers must also have the Forecasting role deployed in their management/payer account to read cost and usage data. That role is separate from the Optimization role covered here — talk to your Cloud Capital representative if you need a Terraform-equivalent for Forecasting as well.
# Commitment Proposal & Onboarding Process
Source: https://docs.cloudcapital.co/optimization/commitment-proposal-onboarding
How Cloud Capital analyzes your AWS spend, structures commitment proposals, and ladders up coverage through a collaborative weekly review process.
When a new commitment customer onboards with Cloud Capital, we begin by assessing their existing AWS commitment posture. These customers typically fall into one of two situations: they arrive with no active commitments, or they carry AWS Reserved Instances and Savings Plans purchased before onboarding, each with some time remaining on their terms.
New to AWS Savings Plans and Reserved Instances? See [How AWS Savings Plans and Reserved Instances Work](/optimization/savings-plans-and-reserved-instances) for a plain-language explanation of these commitment types.
Any pre-existing commitments are monitored for term expiration. However, because these commitments were purchased independently, the customer retains the financial risk on them until Cloud Capital can replace them. Replacements are planned based on the customer's usage patterns and forecast, and are proposed progressively as existing terms wind down to avoid savings interruptions.
***
## Understanding the Risk Transfer
One of the most important — and often overlooked — aspects of working with Cloud Capital is where the financial risk of AWS commitments sits. This distinction has meaningful implications for both your finance team and your technical leadership.
**Cloud Capital Absorbs the Commitment Risk — Not You**
When a business purchases AWS Reserved Instances or Savings Plans directly, it carries the full financial risk of those commitments. If workloads shrink, consolidate, or shift — for any reason — the unused commitment still must be paid. For most organizations, that risk is difficult to quantify and harder to hedge.
While you are a customer of Cloud Capital and we manage your commitments, that risk transfers to us. Cloud Capital covers the risk of the commitments, monitoring utilization continuously — meaning you receive the financial benefits of long-term commitments without being exposed to the downside if your needs change.
**Guaranteed Savings Rate (GSR)**
Cloud Capital backs your commitment coverage with a [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate). This means your organization is contractually assured a minimum level of savings relative to On-Demand pricing — combining the financial flexibility of managed risk with the certainty of a known, guaranteed savings. You get the upside of long-term AWS commitment discounts without the uncertainty of managing that exposure yourself.
The combination of risk transfer and the Guaranteed Savings Rate is one of the most significant structural advantages of working with Cloud Capital over managing AWS commitments independently.
***
## Establishing the Baseline
Our application analyzes your AWS Cost and Usage Report (CUR) data from the preceding months to establish a reliable baseline of actual spend. From this, we identify committable spend across all possible resource types — primarily compute workloads eligible for Compute Savings Plans and database-type workloads eligible for Database Savings Plans or Reserved Instances — and generate a structured ladder proposal tailored to your situation.
***
## The Four-Step Commitment Ladder
Rather than recommending full commitment coverage upfront, Cloud Capital proposes a four-step ladder approach that builds coverage incrementally over time. Each step commits approximately 50% of the remaining uncommitted spend for a given resource type, so coverage grows substantially with each rung while preserving flexibility as your environment evolves.
The term mix across the ladder — whether 3-year, 1-year, or a blend of both for Compute Savings Plans, and 1-year for Database Savings Plans or Reserved Instances — is determined by your risk tolerance, savings targets, and confidence in the forecast horizon. Shorter terms offer more flexibility; longer terms deliver deeper savings. Cloud Capital's recommendations balance both.
| Step | Coverage Added | Cumulative | Term Mix | Commitment Type |
| ----- | ------------------------------ | ---------- | ---------------------------- | ----------------------------- |
| **1** | 50% of committable spend | \~50% | 3-yr or 1-yr | Compute SP, Database SP / RIs |
| **2** | \~25% of baseline | \~75% | 3-yr, 1-yr, or blended | Compute SP, Database SP / RIs |
| **3** | \~12.5% of baseline | \~87.5% | 1-yr (near-term flexibility) | Compute SP, Database SP / RIs |
| **4** | Remaining gap to full coverage | \~100% | 1-yr or shorter | Compute SP, Database SP / RIs |
Each ladder step is reviewed and approved collaboratively with your team before any commitment is purchased.
***
## Weekly Review Cadence During Ladder-Up
The ladder-up process takes place over a series of weekly savings review meetings. These sessions give Cloud Capital and the customer the opportunity to assess each proposed commitment step together before it is purchased. As new initiatives are identified — or business metrics shift projected usage up or down — the remaining rungs of the ladder are adjusted accordingly, ensuring that each commitment reflects the most current view of your needs rather than a static snapshot taken at onboarding.
Once the initial resource coverage has been established, the first stack of initiatives has been factored in, and one or more business metrics have been incorporated to tune the forecast, Cloud Capital transitions you to a monthly review cadence. At this point the relationship shifts from active ladder-up to ongoing management — continuing to monitor commitment performance, refine the forecast, and identify new savings opportunities as your cloud footprint grows and changes.
**Weekly** savings review meetings. Each session reviews the forecast, approves the next commitment step, and incorporates any new business information before a commitment is purchased.
**Monthly** review meetings once the ladder is complete. Focus shifts to commitment performance, forecast refinement, and identifying new optimization opportunities.
***
## Summary
The goal of this process is to move you from your initial spend baseline to a fully optimized, well-forecasted commitment position in a structured and transparent way — without overcommitting early or leaving savings on the table. Cloud Capital carries the commitment risk so you do not have to, every step is reviewed collaboratively, and the pace adapts to your own rate of change.
For definitions of key terms used throughout this document, see the [Glossary](/glossary). For information on how Cloud Capital accesses your AWS environment and handles your data, see the [Security](/security) page.
# Commitment Setup
Source: https://docs.cloudcapital.co/optimization/commitment-setup
When you're ready to start Commitment Optimization, what Cloud Capital assesses, and how the initial commitment plan is structured.
Commitment Optimization begins with a readiness assessment — a structured review that establishes whether the conditions are right to start purchasing commitments and what those initial commitments should look like.
***
## When You're Ready
Cloud Capital looks for three conditions before proposing the first commitment:
**1. Financial and legal onboarding complete**
Compliance checks, credit assessment, and the legal agreement must be in place before any commitment is purchased. This is completed with your Cloud Capital account team — some Forecasting customers do this during their initial engagement; others complete it at this stage. If you're unsure whether it's done, ask your account team. For what's involved, see [Financial Onboarding](/optimization/onboarding).
**2. Forecast established**
At least 3 months of AWS cost data should be available in Cloud Capital, and your [Cost Layers](/forecasting/cost-layers) should reflect your real business structure — Production vs Non-Production at minimum, with more granular separation where it matters. The forecast doesn't need to be perfect, but it needs to be grounded in real data.
**3. AWS technical setup complete**
The dedicated commitment account and Optimization IAM role must be deployed before Cloud Capital can execute purchases. See [Commitment Purchasing Authorization](/optimization/cloud-provider-account) for the setup steps.
***
## What Cloud Capital Assesses
Once the preconditions are met, Cloud Capital runs an initial assessment covering three areas:
### Current Commitment Posture
Are there any active Reserved Instances or Savings Plans in your AWS Organization already? If so, Cloud Capital reviews their terms, utilization, and expiry dates. Pre-existing commitments remain your financial responsibility until they expire, but their coverage is factored into the proposal so there is no double-up.
### Committable Spend
From your CUR data, Cloud Capital identifies the portion of your spend eligible for commitment discounts — primarily compute workloads (Compute Savings Plans) and database workloads (Database Savings Plans or Reserved Instances). This establishes the addressable pool of spend that commitments can cover.
### Forecast and Risk Appetite
Your forecast — built from [Cost Layers](/forecasting/cost-layers), [business metrics](/forecasting/business-metrics), and [engineering initiatives](/forecasting/initiatives) — shapes how aggressively the initial commitment is sized. Your risk appetite, discussed during the setup meeting, determines the term mix: how much 1-year vs 3-year coverage to start with.
***
## The Initial Commitment Meeting
Cloud Capital schedules a setup meeting with your finance and engineering stakeholders to walk through:
* The current spend baseline and committable spend analysis
* The proposed first commitment step — instrument type, term, and size
* The [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate) for the proposed commitment
* Any questions about the ladder approach and review cadence going forward
Nothing is purchased at this meeting. The proposal is reviewed, adjusted if needed, and only executed with your explicit approval.
***
## After the First Purchase
The first commitment is purchased on your behalf through the dedicated commitment account in your AWS Organization — the first rung of a structured coverage ladder. From there, Cloud Capital moves to a **weekly review cadence** during which each subsequent ladder step is reviewed and approved before purchase. Coverage builds incrementally until your committable spend is fully optimized.
See [Commitment Proposal & Onboarding](/optimization/commitment-proposal-onboarding) for the full ladder structure and review process, and [Commitment Strategy](/optimization/commitment-strategy) for how each proposal is constructed.
# Commitment Strategy
Source: https://docs.cloudcapital.co/optimization/commitment-strategy
How Cloud Capital builds commitment proposals using your AWS usage data, forecast, business metrics, and engineering initiatives.
Every commitment Cloud Capital proposes is built from a combination of what your AWS environment has been doing and what it is expected to do. This forward-looking approach is what separates Cloud Capital's proposals from the native recommendations available directly from AWS.
***
## What Goes Into a Proposal
Cloud Capital combines four data sources to build each commitment proposal:
### 1. AWS Cost and Usage Report (CUR)
Your CUR data is the foundation. Cloud Capital analyzes your recent billing history to identify committable spend — the portion of your usage that matches commitment-eligible resource types (primarily compute and database workloads). This establishes an accurate baseline of what you're actually running and spending today.
### 2. Your Forecast
The forecast you've built in Cloud Capital — your [Cost Layers](/forecasting/cost-layers), growth projections, and projection methodology — tells us where your spend is expected to go. A commitment purchased today should reflect your anticipated usage 12 to 36 months from now, not just usage over the last 90 days. A rising forecast means committing to more; a stabilizing or declining forecast means keeping more flexibility.
The more accurate your forecast, the more precisely Cloud Capital can size commitments. See [Projection Types](/forecasting/projection-types) for guidance on choosing the right methodology for each Cost Layer.
### 3. Business Metrics
[Business metrics](/forecasting/business-metrics) — such as active customer counts, revenue, or transaction volumes — allow Cloud Capital to correlate cloud cost growth with the underlying business drivers. When your business plan projects growth or contraction, that signal flows into your forecast and directly shapes the commitment proposal. This is something AWS cannot see and does not factor in.
### 4. Engineering Initiatives
Planned infrastructure changes — migrations, deprecations, new product launches, right-sizing efforts — can significantly affect future spend. [Engineering Initiatives](/forecasting/initiatives) let you encode those planned changes into the forecast so that commitments aren't purchased against spend that is about to disappear, or undersized for spend that is about to grow.
***
## Why This Is Better Than AWS Native Recommendations
AWS provides its own commitment recommendations directly in the Cost Explorer and Billing Console. Those recommendations are based entirely on your historical usage — typically the past 7, 30, or 60 days.
Cloud Capital's proposals start with that same historical foundation but layer in everything AWS cannot see:
| | AWS Recommendations | Cloud Capital Proposals |
| ------------------------------------------- | ------------------- | ----------------------- |
| Historical CUR data | Yes | Yes |
| Forecast (Cost Layers, growth projections) | No | Yes |
| Business metric correlations | No | Yes |
| Engineering initiatives and planned changes | No | Yes |
| Reviewed and approved with your team | No | Yes |
The result is commitments sized to where your spend is going — not just where it has been. For businesses with growing, seasonally variable, or changing cloud footprints, the difference is material.
***
## Term Selection
Each commitment proposal includes a recommended term mix — the balance between 1-year and 3-year commitments. Longer terms deliver deeper discounts; shorter terms preserve more flexibility as your environment evolves.
The recommended term mix is based on the confidence level in your forecast horizon, your risk tolerance, and the stability of the underlying workloads. Cloud Capital reviews the term recommendation with you before any purchase — you can adjust the mix based on your own business context.
For the full four-step commitment ladder and how coverage is built over time, see [Commitment Proposal & Onboarding](/optimization/commitment-proposal-onboarding).
***
## Your Role
The quality of proposals depends on the quality of your inputs. Cloud Capital's recommendation is only as good as the forecast it's built on.
To get the most accurate proposals:
* Keep your [Cost Layers](/forecasting/cost-layers) up to date and mapped to real business boundaries
* Update [business metrics](/forecasting/business-metrics) regularly as your business plan evolves
* Add [Engineering Initiatives](/forecasting/initiatives) when significant changes are planned
* Review your forecast before each weekly review meeting during ladder-up
# Commitments FAQ
Source: https://docs.cloudcapital.co/optimization/commitments-faq
Common questions about commitment risk, billing, pre-existing commitments, and what happens when your cloud spend changes.
## Risk and Financial Protection
**What happens if Cloud Capital defaults or ceases to operate?**
Cloud Capital maintains a ring-fenced financial reserve specifically to protect commitment customers. In the event of a serious operational issue, a back-up servicer or financing partner can step in to ensure continuity of the commitment risk protection. Your commitment risk coverage does not depend solely on Cloud Capital's ongoing operation.
***
**Who owns the commitments Cloud Capital purchases?**
Cloud Capital purchases commitments as an AWS reseller. The commitments sit within the dedicated account in your AWS Organization, and the discount flows to your workloads as it would with any commitment in your Organization. You do not carry the financial risk of underutilization — that sits with Cloud Capital — but you do receive the full savings benefit.
***
**Can I still buy my own commitments alongside Cloud Capital?**
No — during the term of your agreement, you should not purchase AWS Reserved Instances or Savings Plans independently, or negotiate new pricing programs, without Cloud Capital's written agreement. Independent commitment purchases can conflict with Cloud Capital's coverage strategy, potentially creating overlap or disrupting the ladder structure. If you have a need to act independently, discuss it with your Cloud Capital account team first.
***
**What is the ring-fenced reserve?**
Cloud Capital maintains a dedicated financial reserve — separate from its operating funds — that is available specifically to cover commitment obligations in extraordinary circumstances. This reserve is part of the continuity structure that ensures your GSR protection and risk coverage remain in place even if Cloud Capital's normal operations are disrupted.
***
## Billing and Billing Models
**What is the difference between Consolidated Billing and In-Place (Marketplace)?**
There are two billing arrangements:
* **Consolidated Billing** — Cloud Capital acts as your AWS payer of record. You pay Cloud Capital monthly; Cloud Capital pays AWS. Your commitment savings and any Cloud Discount appear directly on your Cloud Capital invoice.
* **In-Place / Marketplace** — You maintain your direct AWS billing relationship (including any existing PPA, EDP, or MSP arrangement). Cloud Capital's charges and GSR rebates flow as a separate Private Offer line item through the AWS Marketplace. No changes to your existing AWS commercial relationship are required.
Both models receive the same commitment management and risk coverage. The difference is only in how billing flows.
***
**How does billing work if I already have an EDP or PPA with AWS?**
Cloud Capital's In-Place model is designed specifically for organizations with existing AWS commercial agreements. Your EDP, PPA, or MSP pricing is fully preserved — Cloud Capital purchases commitments in your Organization without disrupting your existing arrangement with AWS. Our charges appear separately through the Marketplace and do not interfere with your AWS commercial terms.
***
## Pre-Existing Commitments
**I already have Reserved Instances or Savings Plans. What happens to them?**
Pre-existing commitments remain your financial responsibility — Cloud Capital does not absorb the risk of commitments purchased before your agreement started. However, Cloud Capital monitors them for term expiration and factors them into coverage planning. As they expire, Cloud Capital will propose replacements as part of the normal ladder process, transitioning them into the managed program over time to avoid savings interruptions.
***
**What if my cloud spend drops significantly?**
Cloud Capital builds commitment proposals based on your forecast. If your spend drops for reasons outside your reasonable control — a major re-platforming, a business contraction — Cloud Capital will review the situation with you in good faith and agree an appropriate adjustment. There is a minimum spend level in the agreement to prevent deliberate shifting of spend outside Cloud Capital's coverage, but genuine business changes are handled collaboratively.
If your forecast changes significantly at any point, update your [Cost Layers](/forecasting/cost-layers), [business metrics](/forecasting/business-metrics), and [engineering initiatives](/forecasting/initiatives) as early as possible. The earlier Cloud Capital knows about a material change, the better the proposals can be adapted before commitments are purchased.
***
**What if my spend grows faster than expected?**
A growing forecast is a good problem to have. Cloud Capital will propose additional commitment steps at the next review meeting to capture the increased committable spend. Commitments are never purchased ahead of your forecast without your approval — the ladder adapts to your actual trajectory.
***
## The Review Process
**Do I have to approve every commitment? Isn't that what we pay Cloud Capital for?**
Yes — every commitment requires explicit approval before it is purchased, and this is intentional. Here is why.
Cloud Capital does the analytical heavy lifting. Every possible combination of commitment type, term, and size has been evaluated against your usage data and forecast to identify the best-case savings outcome for your situation. By the time a proposal reaches your review meeting, that analysis is complete.
What your approval confirms is something only you can verify: that the inputs to that analysis are current and accurate. Specifically:
* Are your [Business Metrics](/forecasting/business-metrics) up to date and correctly reflecting your business plan?
* Are all upcoming infrastructure changes — migrations, deprecations, new workloads, right-sizing — entered as [Engineering Initiatives](/forecasting/initiatives)?
* Do your [Cost Layers](/forecasting/cost-layers) reflect how your organisation is actually structured today?
Keeping these inputs accurate is a requirement of your agreement with Cloud Capital. The quality of every proposal depends directly on the quality of that data — if spend is about to shift in a way that isn't captured in your forecast, a commitment sized against the current picture may not be optimal.
When your inputs are current and complete, Cloud Capital has everything it needs to optimise fully on your behalf. The review meeting is your opportunity to confirm that your [Cost Layers](/forecasting/cost-layers), [business metrics](/forecasting/business-metrics), and [engineering initiatives](/forecasting/initiatives) are all solid, in place, and complete — making it easy to approve with confidence and unlock the savings on your cloud bill.
During the ladder-up phase, approvals happen in weekly review meetings. During ongoing management, they move to monthly reviews.
See [Commitment Proposal & Onboarding](/optimization/commitment-proposal-onboarding) for the full review cadence.
# Guaranteed Savings Rate
Source: https://docs.cloudcapital.co/optimization/guaranteed-savings-rate
How Cloud Capital's Guaranteed Savings Rate works and what it means for your cloud spend.
The Guaranteed Savings Rate (GSR) is a contractual commitment from Cloud Capital that guarantees your organization a minimum level of savings on your committed AWS spend — expressed as a fixed percentage off On-Demand pricing.
When Cloud Capital purchases Savings Plans and Reserved Instances on your behalf, each commitment carries a specific GSR. That rate is locked in for the life of the commitment and represents real, contractually-backed savings — not an estimate or a target.
New to AWS Savings Plans and Reserved Instances? See [How AWS Savings Plans and Reserved Instances Work](/optimization/savings-plans-and-reserved-instances) for a plain-language explanation of these commitment types before reading further.
![AWS Commitment vs Cloud Capital Guaranteed Savings Rate]()
***
## How GSR works
AWS offers significant discounts when you commit to a minimum level of spend over 1 or 3 years, through Savings Plans and Reserved Instances. The challenge is that those commitments carry risk: if your usage drops, you still owe the committed amount.
Cloud Capital solves this by purchasing and holding those commitments for you. We absorb the financial risk of underutilization and pass through the savings as a guaranteed rate. You benefit from long-term AWS commitment discounts without taking on the commitment exposure yourself.
**For every commitment Cloud Capital purchases on your behalf:**
* Your GSR is fixed at the time of purchase and does not change for the term of that commitment
* You only pay for the portion of the commitment you actually consume
* If your usage falls short of the committed amount, Cloud Capital absorbs the cost of the unused portion — you receive a **GSR Rebate** credit for the difference
* The GSR applies only to the committed portion of your spend, not your entire AWS bill
The GSR is specific to each individual commitment. When you have multiple commitments active, Cloud Capital calculates a weighted average GSR across all of them based on the spend each commitment covers.
***
## What GSR covers
GSR applies to spend covered by commitments — Savings Plans and Reserved Instances. It does not apply to On-Demand spend that falls outside of commitment coverage.
If you are an AWS Billing Transfer customer with Cloud Capital, you may also receive a **Cloud Discount** — a separate fixed percentage reduction on your total monthly AWS spend. Cloud Discount is additive to GSR: it applies to a broader portion of your bill and is calculated independently.
| Savings type | What it applies to | Fixed or variable |
| --------------------------- | -------------------------------------------------------------- | -------------------- |
| **Guaranteed Savings Rate** | Committed spend (Savings Plans, Reserved Instances) | Fixed per commitment |
| **Cloud Discount** | Total monthly AWS spend (excluding Marketplace, support, EDPs) | Fixed by agreement |
***
## A simple example
Suppose Cloud Capital purchases a Compute Savings Plan on your behalf with a GSR of **38%**.
| | On-Demand cost | With GSR applied |
| ---------------------------------------- | -------------- | -------------------- |
| Monthly spend covered by this commitment | \$10,000 | \$6,200 |
| **Your savings rate** | | **38% (guaranteed)** |
The **38% savings rate is guaranteed** for the full term of the commitment. The dollar saving will vary with your actual usage — but the rate never changes.
This distinction matters. With an AWS direct commitment, the listed savings figure is the best-case scenario: it assumes you fully utilize the commitment. If your usage falls short, your effective savings rate declines — and in the worst case, you pay above On-Demand price for capacity you committed to but did not use. With a Cloud Capital GSR-backed commitment, 38% is the only scenario. Cloud Capital absorbs any shortfall and issues a GSR Rebate credit for the unused portion — you always save 38% of what On-Demand would have cost you.
***
## GSR vs Effective Savings Rate
These are two distinct metrics that are easy to confuse:
| | Guaranteed Savings Rate (GSR) | Effective Savings Rate (ESR) |
| --------------------- | ----------------------------------------------- | ------------------------------------------------- |
| **What it measures** | The contractual savings rate on committed spend | Your actual blended savings rate across all spend |
| **Scope** | Committed spend only | Your entire AWS bill |
| **Fixed or variable** | Fixed per commitment | Varies month to month |
| **Set by** | Cloud Capital at time of purchase | Calculated from your actual bill |
Your ESR will typically be lower than your GSR because it includes On-Demand spend that is not covered by commitments. As your commitment coverage grows over time, your ESR moves closer to your GSR.
***
## How GSR appears on your invoice
GSR activity appears as two line items on your Cloud Capital invoice each month:
* **Guaranteed Savings Rate Fee** — the charge for Cloud Capital's commitment management service, calculated as a share of the savings delivered
* **Guaranteed Savings Rate Rebate** — a credit issued when your actual usage falls below the committed level, ensuring you only pay for what you consumed
Both line items are visible in your monthly invoice alongside your AWS usage charges and any applicable Cloud Discount.
When viewing your AWS service costs in Cloud Capital's Cost Insights, GSR activity appears as a **CloudCapitalGSR** line item.
***
## Risk transfer: what happens if your usage changes
AWS commitment risk works in one direction: if you commit to a fixed monthly spend and your usage drops, you still owe the full committed amount. Managing this risk independently requires either over-committing (and losing money on unused capacity) or under-committing (and missing out on discounts).
Cloud Capital changes this equation. Because we hold the commitments in a dedicated account on your behalf, the financial exposure belongs to us — not you. If your usage drops unexpectedly due to a workload migration, a product change, or a seasonal shift, Cloud Capital absorbs the cost of the unused commitment and issues you a rebate.
**The forecast is what makes this possible at scale.** The more accurately your forecast reflects your future spend, the more precisely Cloud Capital can size your commitments — maximizing your GSR coverage without over-committing. This is the core advantage of Cloud Capital over managing AWS commitments directly: your savings rate is guaranteed, your risk is absorbed, and your commitment levels stay calibrated to your actual business as it evolves. Cloud Capital continuously monitors utilization and adjusts future commitment proposals accordingly.
Cloud Capital maintains a financial reserve specifically to cover underutilization risk across all customers. This reserve is the structural backing for the GSR guarantee.
# Compliance Onboarding
Source: https://docs.cloudcapital.co/optimization/onboarding
## Quick summary
If you’re on our **Consolidated billing** model, there are two quick setup steps:
1. **Connect your financial data**\
Go to Organization Settings → [**Financial Data**](https://app.cloudcapital.co/account/financials) and connect your main business bank account(s) securely via Plaid. This allows us to do a light touch credit check.\
*Takes \~5–10 minutes.*
2. **Add a payment method**\
Go to Organization Settings → [**Payment Method**](https://app.cloudcapital.co/account/payment) and add the bank account for automated monthly payments (Direct Debit or ACH).\
*Takes \~5 minutes.*
Once both steps are complete, compliance onboarding is finished and legal documents will be sent for your signature.
***
## Overview
For customers on our Consolidated billing model, where Cloud Capital manages your AWS billing, we ask you to complete a small number of compliance onboarding checks.
***
### Step 1: Connect your Financial Data
**Who:** Finance\
**Time to complete:** 5–10 minutes
### What's required
Connect your financial data to Cloud Capital so we can perform a credit review.
### Why this is needed
Cloud Capital pays your cloud provider on your behalf. To support this, we verify your company’s financial health and carry out light-touch, ongoing credit monitoring. This helps us manage risk and keep billing running smoothly.
We use Plaid to securely connect to your bank account(s). Cloud Capital does not see individual transactions — we only review overall balances for credit assessment purposes.
### How to connect your financials
* Navigate to [**Organization Settings**](https://app.cloudcapital.co/account/general) and select [**Financial Data**](https://app.cloudcapital.co/account/financials)
* Click **Connect Financials with Plaid**
* Click **Continue** to open the Plaid connection
* Select your primary banking institution
* Click **Continue to Login** and sign in to your bank
* Select your core business account(s)
* Confirm by clicking **Connect account information**
Plaid supports multiple connections. Please connect your main business account(s).
***
### Step 2: Add a Payment Method
**Who:** Finance\
**Time to complete:** \~5 minutes
### **What’s required**
Add a bank account for automated monthly payments.
Cloud Capital collects payment via:
* **Direct Debit (GBP)** for UK-based customers
* **ACH (USD)** for US-based customers
Payments are securely authorised via **Stripe**.
### How to connect your payment method
1. Navigate to [**Organization Settings**](https://app.cloudcapital.co/account/general) and select [**Payment Method**](https://app.cloudcapital.co/account/payment).
2. Choose your **Region** based on your company’s location.
3. Add your **Billing Information** — this is the email address that will receive payment notifications and invoices.
4. Add your **Payment Method** — this is the bank account from which automated payments will be collected.
### What to expect from Cloud Capital billing
**Monthly invoices**\
Invoices are available in the platform at the start of each month for the prior month’s usage. Charges may include fixed, usage-based, or one-time fees.
**Automated payments**\
Once invoiced, your pre-authorised payment method will be charged automatically unless otherwise agreed.
**Late payments**\
Late invoices may incur a 1.5% monthly interest charge. After 15 days of non-payment, services may be suspended and accounts may be escalated in line with our terms.
***
Your **Account Manager** will guide you through both steps and is always happy to help if you have questions along the way.
# Commitment Optimization
Source: https://docs.cloudcapital.co/optimization/opt-process
How Cloud Capital purchases and manages AWS commitments on your behalf — reducing your cloud costs while eliminating commitment risk.
Cloud Capital's Commitment Optimization program manages AWS Reserved Instances and Savings Plans on your behalf. Rather than purchasing commitments directly — and taking on the financial risk if your usage changes — Cloud Capital purchases and holds those commitments, passes through the savings at a guaranteed rate, and absorbs any underutilization risk on your behalf.
The core value exchange: you get the discount benefits of long-term AWS commitments without carrying the exposure. Cloud Capital takes the risk; you keep the savings.
***
## Before You Begin
Financial and legal onboarding must be complete before any commitment is purchased. When this happens depends on your path into Cloud Capital:
**Forecasting customers**
Some Forecasting customers complete the financial and legal steps during the initial sales process — particularly those planning to move into commitment optimization within the next 6–8 months (for example, if existing commitments are expiring, or workloads are being restructured in preparation). If you're unsure whether this has been done, check with your Cloud Capital account team.
**In-Place customers**
If you're joining Cloud Capital specifically for Commitment Optimization, financial onboarding will be completed with your account team before the first commitment is purchased.
In both cases, onboarding is completed with your Cloud Capital account team — through meetings and async follow-up — not through a self-serve form.
Compliance checks, credit assessment, and legal agreements — completed with your account team before the first commitment is purchased.
***
## How the Program Works
Cloud Capital analyzes your recent AWS Cost and Usage Report (CUR) data to identify committable spend across your organization — the portion of your usage eligible for Reserved Instance or Savings Plan discounts.
Using your forecast, [business metrics](/forecasting/business-metrics), and [engineering initiatives](/forecasting/initiatives), Cloud Capital generates a structured commitment proposal calibrated to where your spend is heading — not just where it has been. See [Commitment Strategy](/optimization/commitment-strategy) for how proposals are built.
Every proposed commitment is reviewed with your team before it is purchased. Nothing is bought without your explicit approval.
Cloud Capital purchases the approved commitments on your behalf through the dedicated commitment account in your AWS Organization, and monitors utilization continuously. Coverage is built incrementally through a ladder approach — see [Commitment Proposal & Onboarding](/optimization/commitment-proposal-onboarding) for the full ladder and review cadence.
***
## Key Concepts
Every commitment carries a contractually guaranteed minimum savings rate. You know the discount before you approve the purchase.
New to commitment types? A plain-language explanation of how Savings Plans and Reserved Instances work.
How Cloud Capital builds commitment proposals using your forecast, business metrics, and engineering initiatives.
When you're ready to start, what Cloud Capital needs, and how the initial commitment plan is structured.
The AWS account and IAM role setup that allows Cloud Capital to purchase commitments on your behalf.
How to track the savings being generated — your ESR, utilization, and commitment performance over time.
***
## Questions?
See the [Commitments FAQ](/optimization/commitments-faq) for answers to common questions about risk, billing, pre-existing commitments, and what happens if your cloud spend changes.
# Business Reviews (QBR / MBR)
Source: https://docs.cloudcapital.co/optimization/qbr
What to expect from a Cloud Capital business review — when they happen, what's covered, and how to get the most value out of them.
A Cloud Capital Business Review — whether it runs as a Quarterly Business Review (QBR) or a Management Business Review (MBR) — is a structured 45 to 60 minute session with your Cloud Capital team. Rather than running on a fixed calendar schedule alone, these reviews are often triggered by a meaningful event: a new stakeholder joining your Finance or Engineering leadership, a significant shift in your business trajectory, or a major infrastructure change on the horizon.
The goal is to step back from the day-to-day, take stock of where you've been, look ahead at where you're going, and make sure every person in the room is getting full value from Cloud Capital.
***
## When a review is triggered
Business reviews are available to all commitment customers and are scheduled at least quarterly. Beyond the regular cadence, a review can be called any time there's a reason to get the right people in the room together. Common triggers include:
* **New stakeholder joining** — a new CFO, VP Engineering, or Finance Director who needs to understand the platform and the value Cloud Capital is delivering
* **Business inflection point** — rapid customer growth, a new product line launching, a major cloud architecture change, or a significant reduction in workload
* **Upcoming commitment decisions** — pre-existing Reserved Instances or Savings Plans approaching renewal that need a joint decision on whether to renew, restructure, or let expire
* **Forecast divergence** — actuals tracking materially different from the plan, warranting a deeper look before the next commitment step
***
## What gets covered
### Performance since last review
The session opens with a look back — how has the business performed since your last review? This covers your savings realised, [Effective Savings Rate (ESR)](/glossary), commitment utilisation, and how your forecast tracked against actuals. The intent is an honest read of the numbers before looking forward.
### Forecast and business update
With the recent past covered, the conversation moves to your business: what's changed, what's coming, and how that feeds into the forecast. Planned growth, new customers, anticipated changes in cloud spend, upcoming migrations or deprecations — anything that should be reflected in the model gets surfaced here. The forecast is updated to incorporate the new inputs so the next quarter starts with an accurate view.
### New stakeholder onboarding
If new Finance or Engineering stakeholders are joining the call for the first time, the review includes a platform walkthrough tailored to their role. Finance stakeholders are oriented around the Forecast, savings reporting, and billing. Engineering stakeholders are walked through Cost Layers, initiatives, and the commitment performance view. The aim is to ensure every stakeholder knows which parts of the platform are relevant to their work and how to use them.
***
## Finding more value
Business reviews are also an opportunity to identify where Cloud Capital can do more.
**For Forecasting-only customers** — if you're using Cloud Capital purely for forecasting, the review is a natural moment to look at what commitment management could add. Your Cloud Capital team will walk through what the savings potential looks like given your current spend and forecast, and what a path into commitment management would look like for your business.
**For commitment customers with pre-existing commitments** — if you hold Reserved Instances or Savings Plans that pre-date your Cloud Capital engagement, upcoming renewals are a standing agenda item. The review covers whether those commitments are still the right fit, whether utilisation justifies renewal, and how Cloud Capital can take them over or replace them with better-sized coverage going forward.
**For all customers** — expanding platform adoption across your Finance and Engineering teams compounds the value of Cloud Capital over time. The more visibility stakeholders have into the forecast and savings data, the better decisions get made — and the more accurately the forecast reflects what's actually coming.
***
## Related pages
How to track commitment performance, ESR, and savings in the Cloud Capital app.
How the GSR is calculated and what it guarantees.
How Cloud Capital models your cloud spend trajectory.
Common questions about risk, billing, and the review process.
# Savings Assessment
Source: https://docs.cloudcapital.co/optimization/savings-assessment
How Cloud Capital models your savings potential and what that means for your product path.
Once your AWS Cost and Usage Report (CUR) data is integrated, Cloud Capital has everything needed to model what savings are available to your organisation. The savings assessment is the first concrete, data-driven look at that potential — reviewed with your Finance and Engineering teams during a call with the Cloud Capital team, walking through the numbers together directly inside the Cloud Capital app.
***
## What the assessment shows
The assessment models two categories of savings from your actual AWS spend:
**Commitment savings** — the potential savings available from Reserved Instances and Savings Plans, sized against your current usage patterns. This shows the estimated savings rate achievable with Cloud Capital managing those commitments on your behalf, including a breakdown by commitment type.
**Cloud Discount** — the discount rate Cloud Capital can apply to your AWS usage charges, shown as both a percentage and a dollar amount based on your current spend run rate. Cloud Discount applies to all standard AWS usage — AWS Marketplace spend and AWS Support costs are excluded.
Together these give your Finance team a clear, single number for total savings potential before any decision is made.
***
## Forecasting is always included
Forecasting is available to any organisation that integrates their CUR data — at no cost. Once your data is connected, you have access to the full forecasting toolset: Cost Layers, Business Metrics, Projection Types, and Engineering Initiatives.
Cloud Capital uses Forecasting as the foundation for everything else. A mature forecast makes commitment sizing more accurate, which makes savings more predictable. Even if you're not ready to move forward with commitments or a discount arrangement today, Forecasting gives your Finance and Engineering teams immediate visibility into where your cloud spend is going — and it's the starting point for every conversation about what comes next.
***
## Product paths
The savings assessment leads into a decision about which Cloud Capital products fit your situation now, and what the path forward looks like. The options aren't mutually exclusive — most organisations start with one and expand over time.
**Cloud Discount**
Cloud Capital applies a discount to your standard AWS usage charges. No commitment management involved. A good fit if your existing commitment coverage is already strong, if you're not ready to hand off commitment management yet, or if you want immediate savings while your forecast matures.
**Commitment Management**
Cloud Capital purchases and manages Reserved Instances and Savings Plans on your behalf within your AWS Organisation, and carries the utilization risk. You receive a [Guaranteed Savings Rate](/optimization/guaranteed-savings-rate) — a contractual rate Cloud Capital stands behind regardless of how commitments perform month to month. Typically combined with Cloud Discount for maximum total savings.
**In-Place Commitment Management**
For organisations with an existing [AWS Enterprise Discount Program (EDP)](/glossary), [AWS Private Pricing Agreement (PPA)](/glossary), or [AWS Managed Service Provider (MSP)](/glossary) agreement that you want to retain or run down to expiry. Cloud Capital manages your commitments within that existing structure, and a path to transitioning fully to Cloud Capital is planned for when your agreement expires or when you're ready to move.
***
## What shapes the decision
Several factors feed into which product path makes sense and when:
* **Cloud spend size** — the absolute volume of your AWS spend affects which commitment types deliver the best return and whether a discount arrangement is commercially viable
* **Cloud Discount rate** — the rate available to your organisation is determined during the assessment itself
* **Growth trajectory** — fast-growing organisations benefit most from forecast-driven commitment sizing; backward-looking tools consistently undersize commitments and leave savings on the table
* **Existing commitments** — the types, coverage levels, and expiry dates of any Reserved Instances or Savings Plans you already hold affect how Cloud Capital phases in new commitments
* **Existing AWS agreements** — active [EDP, PPA, or MSP](/glossary) agreements shape the available product options and the timeline for a full transition
***
## The path forward
The conversation at assessment stage includes a forward plan — not just which product you're starting with, but what adding the next product looks like and when it makes sense. Forecasting gives your team the visibility to make that timing decision confidently rather than guessing.
***
## Related pages
How the ongoing commitment management program works once you're live.
What commitment types Cloud Capital works with and how they generate savings.
The contractual savings rate Cloud Capital stands behind.
How Cloud Capital models your cloud spend trajectory.
# How AWS Savings Plans and Reserved Instances Work
Source: https://docs.cloudcapital.co/optimization/savings-plans-and-reserved-instances
A plain-language explanation of AWS commitment types — what they are, how they work, and how stacking multiple commitments maximizes coverage.
AWS offers significant discounts when you commit to a fixed level of spend over time. Two instruments deliver those discounts: **Savings Plans** and **Reserved Instances**. Understanding how each works — and how they layer together — is the foundation of an effective commitment strategy.
For the full technical reference, see the official AWS documentation: [AWS Savings Plans User Guide](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html) and [Amazon EC2 Reserved Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html).
***
## Savings Plans
A Savings Plan is a commitment to spend a fixed dollar amount **per hour** in exchange for a discount off On-Demand pricing. Unlike Reserved Instances, Savings Plans do not lock you to a specific instance type, region, or operating system — the discount applies automatically to eligible usage as it occurs.
AWS offers two Savings Plan types relevant to most organizations:
### Compute Savings Plans
The most flexible commitment type available. A Compute Savings Plan applies a discount to any EC2, Fargate, or Lambda usage — across any instance family, size, region, or operating system. If your compute footprint shifts over time (new regions, different instance types, container migrations), the Savings Plan coverage moves with it.
* **Flexibility:** Highest — applies across all compute regardless of type, region, or OS
* **Discount depth:** Typically lower than more specific commitment types for equivalent coverage
* **Best for:** Organizations with diverse or evolving compute workloads, or those who want broad coverage without predicting exactly how they will scale
### EC2 Instance Savings Plans
A narrower commitment that locks in a specific EC2 **instance family** and **region** (for example, `m5` instances in `us-east-1`). In exchange for that specificity, the discount is deeper — and the Savings Plan still applies across sizes and operating systems within that family.
* **Flexibility:** Medium — flexible within a family and region, but not across them
* **Discount depth:** Higher than Compute Savings Plans for the same family
* **Best for:** Workloads with a stable, known instance family profile in a fixed region
### Database Savings Plans
A separate category of Savings Plan covering a broad range of AWS managed database services. Like Compute Savings Plans, the commitment is expressed as a fixed hourly rate and applies automatically across eligible database usage.
Covered services include:
| Service | Notes |
| ------------------------------------ | ----------------------------------------------------------------- |
| Amazon RDS | PostgreSQL, MySQL, MariaDB, Oracle, SQL Server — Gen 7+ instances |
| Amazon Aurora | Provisioned, Serverless v2, and I/O-Optimized |
| Amazon DynamoDB | Provisioned capacity and on-demand throughput workloads |
| Amazon ElastiCache | Valkey, Gen 7+ |
| Amazon DocumentDB | MongoDB-compatible |
| Amazon Neptune | Graph workloads |
| Amazon Keyspaces | Apache Cassandra-compatible |
| Amazon Timestream | Time-series workloads |
| Amazon OpenSearch Service | Search and analytics |
| AWS Database Migration Service (DMS) | Migration workloads |
Database Savings Plans apply primarily to **Generation 7 and newer instance families** (e.g., `r7g`, `m7i`, `r8g`). Organizations still running Gen 6 or earlier instances will not see coverage from a Database Savings Plan until those workloads are migrated to supported generations. If a significant portion of your database spend is on older instance families, migrating to Gen 7+ is a prerequisite to taking full advantage of this commitment type.
* **Term:** 1-year only (3-year terms are not available for Database Savings Plans)
* **Best for:** Organizations with significant managed database spend on Gen 7+ instance families
***
## Reserved Instances
Reserved Instances (RIs) are a more targeted commitment type. Instead of committing to a fixed hourly spend rate, you commit to a **specific instance configuration** — service, instance type, region, and term. The tradeoff is precision versus flexibility: RIs typically deliver the deepest discounts available, but they are scoped to an exact resource profile.
AWS supports Reserved Instances across several services:
| Service | Reserved Instance Type |
| ------------------ | -------------------------------- |
| Amazon EC2 | EC2 Reserved Instances |
| Amazon RDS | RDS Reserved DB Instances |
| Amazon Redshift | Redshift Reserved Nodes |
| Amazon ElastiCache | ElastiCache Reserved Cache Nodes |
| Amazon OpenSearch | OpenSearch Reserved Instances |
| Amazon MemoryDB | MemoryDB Reserved Nodes |
Unlike Savings Plans, RIs are applied directly to matching resource usage. If you purchase an `r5.2xlarge` RDS Reserved Instance in `eu-west-1`, the discount applies only to that specific configuration — any other instance type or region pays On-Demand pricing.
***
## Terms and Payment Options
The term and payment option together determine the effective discount rate.
### Term
Compute Savings Plans and EC2 Instance Savings Plans are available in 1-year or 3-year terms. **Database Savings Plans are available in 1-year terms only.** Reserved Instances are available in 1-year or 3-year terms across all supported services.
| Term | Flexibility | Discount |
| ---------- | ------------------------------------- | -------------------------- |
| **1-year** | More flexibility to adjust at renewal | Moderate discount |
| **3-year** | Locked for a longer horizon | Deepest available discount |
### Payment Options
AWS offers No Upfront, Partial Upfront, and All Upfront payment options, with deeper upfront payments delivering marginally higher discounts in exchange for capital committed at purchase.
Cloud Capital proposes **No Upfront** commitments by default. This preserves your organization's capital flexibility while still delivering the full term discount — and aligns with Cloud Capital's risk model, where the financial exposure sits with Cloud Capital rather than your balance sheet.
***
## How Commitments Stack: The Coverage Ladder
No single commitment type covers everything. An effective commitment strategy layers multiple purchases — across types, terms, and resource categories — so that coverage builds incrementally as confidence in the forecast grows.
AWS applies commitment discounts in a defined order when processing your usage:
1. **Reserved Instances** are applied first — against any usage that exactly matches the RI's configuration (instance type, region, service)
2. **EC2 Instance Savings Plans** apply next — against remaining EC2 usage matching the committed family and region
3. **Compute Savings Plans** apply last — against any remaining eligible EC2, Fargate, or Lambda usage
This order means that more specific commitments take priority, and broader commitments serve as a flexible backstop that catches whatever the specific commitments do not cover.
### The Hourly Commitment Ladder in Practice
A commitment ladder works by expressing each commitment as a fixed hourly rate — the amount of spend per hour that a given Savings Plan or RI will cover. As additional commitments are added, their hourly rates stack on top of prior commitments, progressively covering more of your total spend.
**Example: Layering compute coverage**
Suppose your EC2 baseline runs at \$10.00 per hour of On-Demand spend:
| Commitment | Term | Hourly rate committed | Running total covered |
| --------------------------------------------- | ---- | --------------------- | --------------------- |
| Compute Savings Plan (50% coverage) | 3-yr | \$5.00/hr | \$5.00/hr |
| EC2 Instance Savings Plan (m5, us-east-1) | 3-yr | \$2.00/hr | \$7.00/hr |
| EC2 Reserved Instance (m5.2xlarge, us-east-1) | 1-yr | \$1.00/hr | \$8.00/hr |
| Compute Savings Plan top-up | 1-yr | \$1.50/hr | \$9.50/hr |
Cloud Capital leads with 3-year commitments where the forecast supports it — maximizing the discount on the most stable portion of spend. As coverage builds toward full commitment, shorter 1-year terms fill the remaining gap, preserving flexibility at the margin.
AWS processes these commitments automatically — you do not manage which commitment applies to which instance. AWS applies discounts in the priority order described above and assigns coverage to minimize your bill.
***
## Flexibility vs. Discount Depth
Choosing between Savings Plans and Reserved Instances involves a tradeoff:
| | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instance |
| ------------------ | ---------------------------------- | ------------------------------ | ----------------------------- |
| **Flexibility** | Highest | Medium | Lowest |
| **Discount depth** | Moderate | Higher | Highest |
| **Applies to** | Any compute | Specific family + region | Specific instance + region |
| **Portability** | Full | Within family | None |
| **Best for** | Broad coverage, evolving workloads | Stable families, known regions | Pinned, stable configurations |
A well-structured commitment strategy typically uses all three — with Reserved Instances for the most stable, predictable workloads; EC2 Instance Savings Plans for families with stable regional footprints; and Compute Savings Plans as a flexible overlay that catches everything else.
***
## How Cloud Capital Uses These Instruments
Cloud Capital purchases Savings Plans and Reserved Instances on your behalf using this same layered approach. Each commitment proposal is structured to match the confidence level of your forecast:
* **High-confidence, stable workloads** → Reserved Instances or EC2 Instance Savings Plans for deeper discounts
* **Broad compute coverage** → Compute Savings Plans for flexibility
* **Database services** → Database Savings Plans or database-specific Reserved Instances
Cloud Capital absorbs the financial risk if your usage falls below a commitment level. Rather than over-committing to the highest-discount tier upfront, commitments are laddered in over time — stepping up coverage as the forecast is refined and confidence grows.
### Existing Commitments at Onboarding
If your organization already holds AWS Savings Plans or Reserved Instances purchased before onboarding to Cloud Capital, those commitments are not abandoned. Cloud Capital monitors each existing commitment for its expiry date and tracks utilization throughout the remaining term.
As each commitment approaches expiration, Cloud Capital proposes an optimized replacement using its proprietary algorithm — factoring in your current spend patterns, active engineering initiatives, business metrics, and the latest forecast. The goal is a seamless transition: existing savings are preserved without interruption, and each replacement is sized and structured to reflect where your infrastructure is heading, not just where it has been.
Pre-existing commitments purchased independently carry their financial risk with the customer until Cloud Capital replaces them. Once Cloud Capital purchases the replacement commitment, the risk transfers to Cloud Capital for that position.
Learn how Cloud Capital's GSR contractually backs the savings from every commitment it purchases on your behalf.
See how Cloud Capital structures the ladder proposal and manages the weekly review cadence with your team.
# Savings Realisation
Source: https://docs.cloudcapital.co/optimization/savings-realisation
How Cloud Capital measures and reports your realised AWS savings, including the Effective Savings Rate, savings breakdown by source, and commitment performance tracking.
Cloud Capital shows you exactly how much you're saving on AWS infrastructure — and where each dollar of savings comes from. This page explains how to read and use the Savings section, including how Cloud Capital measures realised savings and the Effective Savings Rate (ESR).
***
## The Savings Page
Navigate to **Savings** in the left sidebar to see your full savings summary. The page is organised into three areas:
* **Summary cards** — a top-level view of your coverage, risk, and total savings
* **Proposals** — new savings opportunities identified by Cloud Capital
* **Cloud Capital Commitments** — a detailed table of all active and historical commitments with utilisation, cost, and savings data
![Savings page overview]()
***
## Summary Cards
Three cards at the top of the page provide a real-time snapshot of your savings position:
| Card | What it shows |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Coverage** | The percentage of your eligible spend covered by commitments — how much of your on-demand equivalent spend has been converted to discounted committed usage |
| **Risk** | Your commitment exposure: the percentage of committed spend not yet matched to actual resource usage. 0% means all commitments are fully utilised |
| **Savings** | Total dollar savings realised since joining Cloud Capital, and your current Effective Savings Rate (ESR) |
***
## Savings Analysis Flyover
Click the arrow on the **Savings** card to open a detailed breakdown of where your savings come from. The flyover has two tabs.
### Cloud Capital Tab
Shows the savings directly attributable to Cloud Capital's actions — commitments sourced and managed on your behalf, plus the platform discount.
![Cloud Capital savings tab]()
* **Last Month Savings** — what Cloud Capital saved you in the most recent billing period, with ESR
* **Cloud Capital's Commitment Savings** — savings from Reserved Instances and Savings Plans that Cloud Capital sourced
* **Cloud Capital's Discount** — the platform discount Cloud Capital applies to your infrastructure costs
* **Total Cloud Capital Savings (last 12 months)** — cumulative savings over the trailing 12-month window, charted by month
### Total Savings Tab
Shows your complete savings picture across all sources, including commitments and discounts that pre-date your Cloud Capital engagement.
![Total savings tab]()
| Savings Category | Description |
| --------------------------------------------- | ----------------------------------------------------------------------- |
| **Cloud Capital's Commitment Savings** | Savings from commitments sourced and managed by Cloud Capital |
| **Cloud Capital's Discount** | Platform discount applied by Cloud Capital |
| **Customers Pre-existing Commitment Savings** | Savings from commitments you held before joining Cloud Capital |
| **Spot Usage Savings** | Savings from AWS Spot Instance usage |
| **Other Savings** | Enterprise discounts, product discounts, partner discounts, and similar |
***
## Effective Savings Rate (ESR)
The **[Effective Savings Rate](/glossary)** (ESR) is the primary metric Cloud Capital uses to measure the efficiency of your cloud spend optimisation.
> ESR = Total Savings ÷ Total On-Demand Cost
It answers the question: *"Out of what you would have paid at full on-demand rates, what percentage are you saving?"*
An ESR of 8% means that for every dollar of on-demand-equivalent spend, you pay \$0.92 and save \$0.08. A higher ESR indicates more effective commitment coverage and discounting.
The ESR shown on the **Savings** card and the **Cloud Capital** flyover tab reflects Cloud Capital's direct contribution. The **Total Savings** tab shows the ESR across all sources combined — including pre-existing commitments, Spot, and other discounts.
***
## Cloud Capital Commitments
The **Cloud Capital Commitments** table shows the detailed record of all commitments in your portfolio. Switch between two views using the tabs at the top right.
### Monthly Breakdown
A month-by-month view of commitment performance. Each row covers one billing period:
| Column | Description |
| ------------------- | ------------------------------------------------------------- |
| **Billing Period** | The calendar month |
| **Usage** | Total committed spend consumed that month, with utilisation % |
| **Commitment Cost** | The amortised cost of your commitments for the period |
| **On Demand Cost** | What the same usage would have cost at on-demand rates |
| **Savings** | On Demand Cost minus Commitment Cost |
| **Savings Rate** | Savings as a percentage of On Demand Cost |
### All-Time Performance
![All-time commitment performance]()
A per-instrument view aggregated across the full commitment term. Each row represents one commitment (for example, a Reserved Instance or Savings Plan):
| Column | Description |
| ------------------- | ------------------------------------------------------------------------------------------------- |
| **Instrument Type** | The commitment type — Reserved Instance or Savings Plan |
| **Usage** | Total units consumed vs available, with utilisation % |
| **Instance Type** | The specific instance or resource type committed to |
| **Region** | The AWS region the commitment applies to |
| **Operation** | The OS or usage operation covered by the commitment |
| **Commitment Cost** | Amortised cost over the commitment's full term |
| **On Demand Cost** | Equivalent cost at on-demand rates |
| **GSR Adjustment** | Reconciliation adjustment applied against your [Guaranteed Savings Rate](guaranteed-savings-rate) |
| **Savings** | Net savings after GSR adjustment |
| **GSR** | The Guaranteed Savings Rate for this commitment |
| **Time Remaining** | Months until the commitment expires |
***
## Reporting
Cloud Capital provides regular savings reporting to help you and your finance team track progress:
* **Monthly Reviews** — a shared view of savings realised over the prior month, covering ESR, utilisation, and any commitment changes. All customers receive monthly review access.
* **Quarterly Business Reviews (QBRs)** — a deeper performance review for commitment customers, typically attended by finance, engineering, and executive stakeholders. QBRs cover cumulative savings to date, ESR trends, optimisation recommendations, and the roadmap for further commitment coverage. See [Business Reviews (QBR / MBR)](/optimization/qbr) for details.
QBRs are available to commitment customers following the initial commitment ladder-up. If you're not yet on a commitment plan, speak to your Cloud Capital account team about getting started with [Cost Optimisation](opt-process).
# Cloud Cost Savings Strategies
Source: https://docs.cloudcapital.co/optimization/savings-strategies
The two main levers for reducing AWS spend — and where Cloud Capital focuses.
There are two distinct ways to reduce AWS costs, and most organisations benefit from both. Understanding the difference helps clarify where Cloud Capital fits and what other tools or partners might complement that work.
***
## Workload optimization
[Workload optimization](/glossary) is about running your infrastructure more efficiently — using the right instance types, right-sizing compute resources, reducing idle capacity, and tuning applications to consume less CPU, memory, and storage for the same output. This work happens at the application and cluster level and typically involves engineering effort to identify waste and restructure how workloads run.
This is specialist work. AWS and a number of AWS Partner Network vendors focus specifically on workload optimization — profiling utilization, recommending instance changes, and helping engineering teams reduce the underlying resource footprint. If your organisation is early in its infrastructure optimization journey, or if you're seeing high levels of idle or over-provisioned resources, working with a partner that specializes in this area is worth considering alongside the commitment-based savings Cloud Capital provides.
***
## Commitment optimization
Commitment optimization is about paying less for the infrastructure you're already running — by replacing on-demand pricing with Reserved Instance or Savings Plan discounts. The infrastructure itself doesn't change; the pricing structure does.
This is where Cloud Capital focuses. By building a forward-looking forecast of your spend, purchasing the right mix of commitments at the right time, and carrying the underutilization risk on your behalf, Cloud Capital delivers a guaranteed savings rate on your existing AWS usage without requiring any changes to how your workloads run.
***
## How they work together
The two approaches are complementary, not competing. Workload optimization reduces the total resource footprint; commitment optimization reduces the unit price of that footprint. Organisations that do both compound their savings — and Cloud Capital's forecast adapts as your usage changes, so commitment coverage stays accurate even as workload optimization work reshapes your spend profile.
***
How commitment types work and how they generate savings.
How Cloud Capital builds proposals using your forecast and business metrics.
The contractual savings rate Cloud Capital stands behind.
How Cloud Capital models your savings potential before you commit.
# Security
Source: https://docs.cloudcapital.co/security
How Cloud Capital accesses, handles, and protects your data — and what we never touch.
Security questions are common during vendor evaluation and procurement. This page answers the most frequent ones. For full details on certifications, controls, and third-party audits, visit the [Cloud Capital Trust Center](https://trust.cloudcapital.co).
***
## What Cloud Capital accesses — and what it does not
Cloud Capital reads your **cloud cost and usage data** only. We do not access your cloud infrastructure, workloads, customer data, or any resources running in your AWS accounts or GCP projects.
| | Cloud Capital accesses this | Cloud Capital does not access this |
| --------------------------------------------------------- | --------------------------------- | ---------------------------------- |
| AWS Cost and Usage Reports (CUR) | Yes | |
| AWS billing, pricing, and commitment APIs | Yes | |
| AWS Organizations account structure | Yes (read-only) | |
| EC2, RDS, and other AWS resource *descriptions* | Yes (read-only, for cost mapping) | |
| GCP BigQuery billing export and CUD subscriptions dataset | Yes | |
| GCP billing account, pricing, and Compute commitment APIs | Yes | |
| GCP organization/project structure | Yes (read-only) | |
| Compute Engine and other GCP resource *descriptions* | Yes (read-only, for cost mapping) | |
| Running workloads, application code, databases | | Never |
| Customer or end-user data | | Never |
| IAM credentials or secrets | | Never |
***
## How AWS access is granted
Cloud Capital connects to your AWS environment using AWS's standard **cross-account IAM role** pattern. Both roles are provisioned via CloudFormation templates that Cloud Capital provides — parameters are pre-populated, so no manual configuration is required. For teams that manage infrastructure exclusively through Terraform, Cloud Capital can provide an equivalent Terraform module. Contact your Cloud Capital representative or [support@cloudcapital.co](mailto:support@cloudcapital.co) to request it.
You retain ownership of the role and can revoke access at any time by deleting the CloudFormation stack (or destroying the Terraform resource).
Two separate roles are used, each scoped to its function. Full setup instructions, including how to deploy each CloudFormation stack, are in the [Integrate AWS Data](/get-started/aws-data-integration) guide.
### Forecasting role (all customers)
A read-only role applied to your AWS management or payer account. It grants access to:
* Your CUR S3 bucket (scoped to that specific bucket only)
* AWS billing, Cost Explorer, and pricing APIs
* Organization account enumeration
* Resource descriptions (EC2, RDS, ElastiCache, Redshift, OpenSearch) for cost mapping
This role cannot create, modify, or delete any AWS resource.
### Optimization role (commitment customers only)
A purchasing role applied **exclusively to a dedicated, empty AWS account** you create for this purpose — never to your management account or any workload account. See [Commitment Proposal & Onboarding](/optimization/commitment-proposal-onboarding) for how Cloud Capital uses this access to manage your commitments. It grants access to:
* Purchasing Savings Plans and Reserved Instances on your behalf
* Creating service-linked roles required by AWS during first purchase
* Managing service quota increases when needed
This role has no read access to your cost data and no access to any workload accounts.
Both roles use an **ExternalId** condition in the trust policy — a system-generated UUID unique to your organization. This means only Cloud Capital's specific AWS account can assume the role, and only when presenting the correct ExternalId. This prevents confused deputy attacks. You can review the full policy in each CloudFormation template: [Forecasting template](/cloudformation/aws-cloudformation-forecasting.json) · [Optimization template](/cloudformation/aws-cloudformation-optimization.json).
***
## How GCP access is granted
Cloud Capital connects to your GCP environment using a **service account unique to your environment**, granted **read-only** access through four scoped IAM and BigQuery grants. There is no CloudFormation-equivalent stack — each grant is applied directly via `gcloud` and `bq` commands (or an equivalent Terraform configuration, for teams that manage infrastructure that way).
Full setup instructions are in the [Integrate GCP Data](/get-started/gcp-data-integration) guide.
### Forecasting role (GCP, Beta)
The service account is granted:
* `roles/billing.viewer` on your billing account — contract pricing, credits, anomalies, and Google's own commitment recommendations
* `roles/compute.viewer` on your organization (or folder/project) — resource-based Compute commitments
* `roles/bigquery.dataViewer` on your billing export table — cost and usage data
* `READER` (dataset ACL) on your CUD subscriptions dataset — spend-based commitment data
This service account cannot create, modify, or delete any GCP resource — all four grants are strictly read-only.
GCP's IAM model doesn't need an ExternalId-style condition: each grant is scoped to a **service account email unique to your environment**, rather than to a whole AWS-style account. There is no equivalent "confused deputy" risk to mitigate, since the grant already names the exact principal rather than an entire account. See [Integrate GCP Data](/get-started/gcp-data-integration) for the exact grant commands and the service account email format.
**Commitment purchasing and billing through Cloud Capital are not yet available for GCP** (Beta). The GCP integration currently supports cost forecasting, cost insights, cost allocation, and commitment inventory/performance visibility only — there is no GCP equivalent of the AWS Optimization role today. See [Integrate GCP Data](/get-started/gcp-data-integration) for the current feature scope.
***
## Revoking access
**AWS:** You can revoke either role at any time by deleting the corresponding CloudFormation stack in your AWS console. Access is terminated immediately.
**GCP:** You can revoke access at any time by removing the IAM and dataset-ACL grants described above from your GCP environment. Access is terminated immediately once the grants are removed.
For commitment customers, revoking the AWS Optimization role removes Cloud Capital's ability to manage your commitments and fulfill its contractual obligations. Contact your Cloud Capital representative before revoking if you have active commitments in place.
***
## Data protection
**In transit:** All communication between Cloud Capital and your cloud provider (AWS or GCP) is encrypted with TLS.
**At rest:** All data stored in Cloud Capital is encrypted using AWS encryption standards, regardless of whether it originated from your AWS or GCP environment — this reflects how Cloud Capital's own infrastructure is hosted, not your source cloud provider.
**Retention:** Your cost and usage data is stored for the duration of your use of the platform. Upon account deletion, all associated data is deleted within 30 days. You may also request deletion at any time.
**Third parties:** Cloud Capital does not share your cost or usage data with any third party. We use third-party tools for internal purposes (analytics, support, payment processing), but none of those services have access to your cost or usage data.
***
## Audit logging
All access to customer data and platform actions are logged. For commitment customers, every commitment decision — including the context and approvals — is recorded in the audit trail. Customers can request logs as part of their compliance requirements.
***
## Google Sheets integration
Cloud Capital's [Google Sheets integration](/forecasting/business-metrics-import-googlesheets) lets you import business metrics directly from a spreadsheet into your forecasts. The connection uses Google's standard OAuth authorization flow.
**What Cloud Capital can access:**
* Only the specific files you explicitly share with your organization — not your entire Google Drive
* Each team member who connects their Google account does so independently; their unshared spreadsheets remain private
**Visibility and control:**
* All files shared with your organization are listed in **Organization Settings → Data Connections → Shared Files**, giving you a clear record of what is accessible at all times
* Any shared file can be revoked from that same settings page at any time
* Revoking a file immediately breaks the sync for any metrics currently importing from it
Cloud Capital does not store your Google credentials. Access is governed entirely by Google's OAuth token system and can be revoked from either Cloud Capital's settings or directly from your Google account's connected apps.
***
## User authentication and SSO
Cloud Capital supports Single Sign-On (SSO) via OIDC, compatible with Google Workspace, Microsoft Entra ID, Okta, Auth0, OneLogin, and other OIDC-compliant identity providers.
SSO can be configured as optional or enforced across your organization. See the [SSO setup guide](/get-started/sso) for full configuration instructions.
The [Cloud Capital API](/api-reference/overview) uses API key authentication. Keys are scoped to your organization and should be treated as secrets — do not expose them in client-side code, public repositories, or logs.
***
## Compliance and certifications
For information on Cloud Capital's security certifications, SOC 2 status, penetration testing, vendor questionnaire responses, and compliance documentation, visit the [Cloud Capital Trust Center](https://trust.cloudcapital.co).
If you have specific security or compliance questions that are not answered there, contact us at [support@cloudcapital.co](mailto:support@cloudcapital.co) or via your shared Slack channel.