Great question—this is a super common pain point when mixing pay-per-use services (like API Gateway + Lambda) with fixed/hourly resources like RDS in multi-tenant applications. Let’s walk through the most practical, actionable ways to split those RDS costs fairly across your customers:

1. Usage-Based Allocation with Custom Metrics #

This is the most precise approach if your customers have wildly different database usage patterns. Here’s how to pull it off:

• Add tracking to your Lambda functions: Embed logic to count database operations (writes, queries, connection time) per customer ID. For example, every time a Lambda writes to RDS, increment a counter tagged with the customer’s unique ID.
• Leverage AWS tools for aggregation: Use PutMetricData to send these custom metrics to CloudWatch, or use AWS X-Ray to trace end-to-end requests and link Lambda invocations to RDS usage. RDS Performance Insights can also help you break down query volume by customer if you include customer IDs in query metadata.
• Calculate allocations: At the end of each billing period, take your total RDS cost and split it proportionally based on each customer’s share of the tracked metrics (e.g., if Customer A accounted for 40% of total write operations, they pay 40% of the RDS bill).

Pros: Hyper-fair for customers with varying usage. Cons: Requires extra development work to implement tracking and metric aggregation.

2. Tiered Pricing with Fixed Allocation Buckets #

If your customers fall into clear usage tiers (e.g., free, basic, premium), this low-effort method works well:

• Map tiers to cost shares: Assign a fixed percentage of the RDS cost to each tier. For example, premium customers might cover 60% of the total RDS bill, basic 30%, and free 10%. You can also weight by the number of customers in each tier (e.g., 50 premium customers split their 60% share equally).
• Include RI discounts: If you’ve purchased RDS Reserved Instances, split the discounted RI cost using the same tiered rules, then allocate any on-demand RDS costs (for peak capacity) based on real-time usage spikes tied to tiers.

Pros: No extra code needed—easy to manage and communicate to customers. Cons: Less precise if individual customers within a tier have very different usage.

3. Per-Customer Database Sharding (For Isolation & Clarity) #

If you have high-value customers or need strict data isolation, spinning up dedicated RDS resources per customer (or customer group) eliminates the need for cost splitting entirely:

• Automate instance provisioning: Use AWS CDK or Terraform to create RDS instances/clusters on-demand when a new customer signs up. Route Lambda requests to the correct database using customer ID-based routing logic.
• Charge directly for their instance: Each customer pays the hourly cost of their own RDS instance, plus any associated storage/transfer fees. You can even markup the cost slightly to cover management overhead.

Pros: 100% transparent and fair—no guesswork. Cons: Higher operational overhead, and may be cost-inefficient for small customers with low database usage.

4. Hybrid "Base + Usage" Model #

This balances simplicity and precision, ideal if you have a steady baseline RDS load plus variable peak usage:

• Split into fixed and variable costs: First, allocate the base RDS cost (e.g., the hourly rate for your minimum required instance size) equally across all active customers.
• Allocate variable costs by usage: For any additional RDS costs (e.g., scaling to a larger instance, extra storage, or on-demand capacity during peaks), split these based on each customer’s usage metrics (like CPU utilization contribution or write IOPS).

Pros: Fair to both light and heavy users—covers your fixed costs while accounting for spikes. Cons: Requires tracking both baseline and variable usage metrics.

Quick Practical Tips #

• Use AWS Cost Explorer cost allocation tags: Tag your RDS resources with labels like CustomerTier or Project to simplify cost breakdowns without manual calculations.
• Communicate clearly with customers: Make sure your pricing terms explicitly explain how RDS costs are allocated—transparency prevents billing disputes.
• Test first: Pick one method and run it for a billing cycle to see how it aligns with your actual customer usage before rolling it out fully.

内容的提问来源于stack exchange，提问作者Fred Sullet