Which solution will provide a granular view of the DynamoDB cost for each tenant with the LEAST operational effort?
Associate a new tag that is named tenant ID with each table in DynamoDB. Activate the tag as a cost allocation tag in the AWS Billing and Cost Management console. Deploy new Lambda function code to log the tenant ID in Amazon CloudWatch Logs. Use the AWS CUR to separate DynamoDB consumption cost for each tenant ID.
Configure the Lambda functions to log the tenant ID and the number of RCUs and WCUs consumed from DynamoDB for each transaction to Amazon CloudWatch Logs. Deploy another Lambda function to calculate the tenant costs by using the logged capacity units and the overall DynamoDB cost from the AWS Cost Explorer API. Create an Amazon EventBridge rule to invoke the calculation Lambda function on a schedule.
Create a new partition key that associates DynamoDB items with individual tenants. Deploy a Lambda function to populate the new column as part of each transaction. Deploy another Lambda function to calculate the tenant costs by using Amazon Athena to calculate the number of tenant items from DynamoDB and the overall DynamoDB cost from the AWS CUR. Create an Amazon EventBridge rule to invoke the calculation Lambda function on a schedule.
Deploy a Lambda function to log the tenant ID, the size of each response, and the duration of the transaction call as custom metrics to Amazon CloudWatch Logs. Use CloudWatch Logs Insights to query the custom metrics for each tenant. Use AWS Pricing Calculator to obtain the overall DynamoDB costs and to calculate the tenant costs.
Explanations:
While associating a tenant ID tag can help in identifying costs, it does not automatically provide a granular view of costs based on resource consumption without additional processing to extract usage metrics per tenant. Logging tenant IDs in CloudWatch is also not sufficient to allocate costs accurately, as the cost allocation relies on detailed usage metrics that are not captured by tagging alone.
This option captures the resource consumption (RCUs and WCUs) directly related to each tenant by logging these metrics in CloudWatch. It then uses a Lambda function to calculate tenant costs based on this data and the overall DynamoDB cost, leveraging AWS Cost Explorer API, which offers a more precise allocation based on actual usage. This approach minimizes operational effort by automating the cost calculation and tracking process.
Although creating a partition key for tenants in DynamoDB could help organize data, it requires additional Lambda functions to populate this key and to calculate costs using Athena, adding operational complexity. Furthermore, using Athena for cost calculations introduces more steps than necessary when the required information is already available through CloudWatch logs. This method is less efficient compared to the direct logging and calculation approach in Option B.
This option suggests logging response sizes and durations rather than actual resource consumption metrics (RCUs and WCUs), which are necessary for accurate cost allocation. Using CloudWatch Logs Insights for queries does not provide a direct mapping to costs, and relying on the AWS Pricing Calculator for tenant cost calculations is not practical as it requires manual input and does not reflect actual consumption.
In my experience, the answer is:
Configure the Lambda functions to log the tenant ID and the number of RCUs and WCUs consumed from DynamoDB for each transaction to Amazon CloudWatch Logs. Deploy another Lambda function to calculate the tenant costs by using the logged capacity units and the overall DynamoDB cost from the AWS Cost Explorer API. Create an Amazon EventBridge rule to invoke the calculation Lambda function on a schedule.