In many cloud-native organizations, container orchestration platforms like Amazon EKS and ECS are deployed as shared clusters. These clusters often host dozens—or even hundreds—of microservices, spread across teams, environments, and functions.
From an operational standpoint, shared clusters improve infrastructure efficiency and reduce overhead. However, from a financial perspective, they have historically introduced a major blind spot: cost attribution.
When multiple teams share the same compute layer, traditional AWS billing aggregates all expenses at the cluster level. Finance teams see a large monthly cost, but no detail on who used what. Engineering leaders are left to guess which service is consuming resources, and teams lack the data needed to take ownership of their infrastructure spend.
The Workaround: Third-Party Solutions
Until recently, organizations turned to external tools to bridge this gap. Platforms like Kubecost, or homegrown solutions parsed container metrics and applied resource-based allocation models. While effective, these setups introduced complexity:
Separate pipelines for collecting and storing metrics
Custom logic for mapping container usage to spend
Limited consistency with AWS native billing data
Higher operational overhead and tooling costs
Despite best efforts, there remained a disconnect between application activity and AWS billing.
The Breakthrough: AWS Native Container-Level Cost Allocation
AWS has now addressed this long-standing issue with a native feature: Split Cost Allocation Data (SCAD) for Amazon ECS and Amazon EKS. This enhancement enables customers to break down containerized compute costs directly within AWS billing and usage data, without relying on third-party tooling.
Use Case: Allocating Costs in a Shared EKS Cluster
Imagine a mid-sized SaaS company running multiple internal and customer-facing workloads in a single Amazon EKS cluster. Teams deploy their services to isolated namespaces, but the cluster spans all environments—production, staging, QA.
Before SCAD:
All EKS costs (including EC2 instances or Fargate) are grouped under a single line item.
There’s no breakdown by service, namespace, or team.
Finance can’t allocate spend accurately, and engineering has no clear view of cost impact.
Optimizing costs requires guesswork or reliance on external tooling.
After SCAD:
AWS now emits Split Cost Allocation Data that includes container-level metadata such as:
Kubernetes namespace and pod name
ECS task and service names
Container CPU and memory usage over time
This data is available through AWS Cost and Usage Reports (CUR) and integrates natively with cost analytics tools like AWS Athena or QuickSight.
Costs are split proportionally across services based on actual resource usage, down to the hour.
This enables:
Per-service cost visibility even in shared clusters
Tag-based allocation to business units or teams
Informed rightsizing decisions based on granular data
Internal chargeback models driven by actual usage
Simplified reporting pipelines, using AWS-native data formats
Why This Matters
The introduction of SCAD marks a major shift in how containerized workloads are managed from a FinOps perspective. Organizations no longer need to stitch together billing and usage data from multiple sources or maintain separate observability stacks just to answer the question, “What did this service cost us last month?”
With AWS providing this capability out-of-the-box:
Accuracy improves—allocations are now based on real usage, not estimates
Overhead reduces—no need to maintain external exporters or sync billing with metrics manually
Consistency increases—cost data aligns with AWS invoices and reporting
How to Use SCAD
Using Split Cost Allocation Data (SCAD) involves a few practical steps within AWS, all of which are fully supported by native services:
Enable SCAD in your AWS account:
SCAD is automatically included in the AWS Cost and Usage Report (CUR), but you must ensure container-level cost allocation is turned on. Navigate to the Billing and Cost Management section of the AWS console, and within the CUR settings, enable the option for container-level data for ECS and/or EKS.Ensure workload tagging is consistent:
SCAD uses container metadata—including tags and labels—to attribute cost. For EKS, this includes Kubernetes namespaces and pod labels; for ECS, task definitions and service names. Apply standardized tags (e.g.,Team,Service,Environment) to all relevant workloads.Query SCAD data:
Once enabled, SCAD output is embedded within your CUR files, typically delivered to an S3 bucket. You can then use AWS Athena to query this data using SQL-like syntax. For example, you can write queries to view costs grouped by namespace, container name, or task ID over a given time period.Integrate insights:
Visualize the parsed data using Amazon QuickSight, or export summaries to internal dashboards or BI tools. This allows FinOps teams and engineering leaders to review costs by application or team during monthly planning and retrospectives.
SCAD doesn’t require any additional agents, metrics collectors, or third-party setups—it integrates directly with AWS’s native billing pipeline, making cost allocation more accurate, automated, and maintainable.