Replies: 3 comments
-
Combined approachMy initial idea is to support both use cases (aggregated usage definition vs specific resource definition). The aggregated approach would have usage parameters as is currently implemented, e.g:
which would result in output as such:
The specific resource approach might require a little more thought. However, my first idea would be to have similar usage parameters at a per resource level.
The origin region could be inferred from the resource itself. This could then be aggregated into a single output in the infracost cli, like such:
However, because of the tiered nature of the pricing, the numbers wouldn't exactly align with the resources. We'd have to take a naive approach and just increment the tier, meaning that a sub data transfer of a resource could be a different tier of data transfer pricing than the actual billing report. However, the overall numbers should add up. |
Beta Was this translation helpful? Give feedback.
-
Notes from a user chat: How do you see the data transfer costs? That’s the most mysterious costs. For example with AWS RDS, the IOPS/storage/compute costs are a big part of it, but no one knows the data transfer. If I switch to ARM-based processors, that’s meant to reduce my IOPS and costs too, but even when I ask the AWS people, they don’t know how to answer the question around data transfer. |
Beta Was this translation helpful? Give feedback.
-
It might help to see how AWS Cost Explorer (and Azure/Google equivalents) show data transfer costs? For example, if they and we show aggregates, and the Terraform project being run with Infracost accounts for a tiny-part of the AWS account, then showing the total account’s data transfer cost might be huge and it misses the context. Another option could be to show a range of costs. e.g. this TF resource could have between $40-60, and it has 4 usage-based resources that are priced in variable, you can use a usage file... But I’m not sure how we’d compute the ranges, maybe CloudWatch data can help. |
Beta Was this translation helpful? Give feedback.
-
Currently infracost supports
aws
data transfer as an aggregated resource, which is defined outside of any parent resource. The output is as following:This has been implemented in this fashion for two reasons:
However this approach has a downside - users are unable to associate data transfer/network costs with a specific resource. This could be beneficial because:
We need to figure out what approach to take as other network providers have similar aggregated and tiered pricing for network costs, which are yet to be implemented. e.g. resource
google_service_networking_connection
which is one of the most requested and still unsupported terraform resources depends on egress VM-VM network costs, which are aggregated and tiered across resources.Below are some ideas on how we could improve this feature. Please feel free to add your ideas as further comments. Upvote any you think would work best for your situation/use case.
Beta Was this translation helpful? Give feedback.
All reactions