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.

Manually mapping every account and service combination to cost layers is tedious, especially in multi-account AWS environments. 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.

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:
CategoryCost LayerProduction?Example account names
ProductionProduction (COGS)Yesprod-api, workload-us-east, live-services
DevelopmentDevelopment (Non-Prod)Nodev-team-alpha, sandbox-experiments
TestingTesting (Non-Prod)Noqa-regression, uat-environment
StagingStaging (Non-Prod)Nostaging-v2, pre-prod-us-west
Security & OperationsSecurity & Operations (Non-Prod)Noaudit-logs, security-hub, infra-management
SupportSupport (Non-Prod)Nosupport-services
Not SureProduction (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 AWS Control Tower and Landing Zone naming conventions, as well as common SDLC patterns. 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 AWS 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 management page.

Step 3 — Service cost breakdown

Choose whether to split production accounts by AWS service and auto-group them into service categories. Production service categories (under Production / COGS):
CategoryWhat it coversExample services
ComputeRuntimes, containers, workflow enginesEC2, ECS, Lambda, EKS, Fargate
Database & StorageDatabases, warehouses, object storageRDS, S3, DynamoDB, Redshift, ElastiCache
Networking & DeliveryNetwork, CDN, DNS, messaging, APIsCloudFront, ELB, Route 53, API Gateway, SNS
AI & AnalyticsML/AI, BI, data processing, streamingSageMaker, Bedrock, Kinesis, Glue, MSK
Non-production service categories (under Non-Production / OpEx):
CategoryWhat it coversExample services
Security & OperationsMonitoring, security, compliance, CI/CDCloudWatch, GuardDuty, Config, CodeBuild
SupportAWS support plansBusiness Support, Enterprise 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 approximately 200 AWS services, including popular AWS 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 service auto-mapping to any assigned leaf node in the Sankey diagram by clicking the tree icon on that node. A preview panel opens showing which service categories will be created, how much spend falls into each, and a breakdown preview before you commit. This is useful for:
  • Accounts 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

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 AWS Control Tower or Landing Zone naming conventions significantly improves auto-categorisation accuracy

Cloud Resource Mapping

Canvas overview, manual mapping, and toolbar reference.

Cost Layers

Add sub-layers, reassign services, and manage your structure over time.