Skip to main content

Documentation Index

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

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

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, 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 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 TypeWhat It TargetsBest Used For
Cost LayerAn entire Cost Layer (e.g., Production, Staging)Changes that align to a business unit or environment boundary
ResourceSpecific AWS resources by attribute (service, region, instance type, etc.)Infrastructure migrations, right-sizing, service-level changes
AccountA specific AWS accountAccount-level changes or consolidations
TagResources sharing a specific AWS tagTeam- or project-level cost changes tracked via tagging
Cost CategoryAn AWS Cost Category groupingChanges aligned to custom AWS 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 AWS resources by their attributes, rather than an entire Cost Layer. 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:
DimensionDescriptionExample Values
ServiceThe AWS cloud serviceAmazon RDS, Amazon EC2
Resource FamilyBroad resource type groupingDatabase, Compute, Storage
RegionGeographic AWS regioneu-west-1, us-east-1
Instance TypeSpecific instance or resource typet3.large, db.r5.2xlarge
Usage TypeAWS usage type codeEU-RDS:db.t3.large
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: 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.
Resource filter values are drawn from your actual AWS cost data. The picker shows only values present in your imported cost history, sorted by spend impact (highest first).

Creating a Resource-Based Initiative

1

Create the 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
2

Add a Resource Mapping

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.
3

Optionally add a Cost Layer Mapping

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.
4

Set monthly impact values

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.
5

Set status to Committed

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:
ScenarioTypePermanent ChangeMapping
Deprecate a serviceAbsolute, negative — equal to the monthly cost of the serviceYesCost Layer or Resource
New product launchPercentage, positive — estimated growth rateYesCost Layer
One-time load event (e.g., seasonal spike)Percentage, positiveNoCost Layer
Infrastructure migration (phased)Percentage, negative — step-down each month as workloads moveYesResource
Right-sizing specific instance typesPercentage, negativeYesResource

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. 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:
FieldValue
NameRDS PostgreSQL t3.large Migration — EU West 1
TypePercentage
Permanent ChangeChecked (migration is complete after August; the cost reduction persists indefinitely)
ColorYour 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:
DimensionValue
ServiceAmazon RDS
Instance Typet3.large
Regioneu-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 PeriodPercentage ImpactWhat 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.