If your Platform Team operates a Chargeback model, you need a pricing strategy. How do you translate raw AWS costs into internal invoices that are fair, transparent, and create the right incentives?
1. Pass-Through (Cost Recovery)
- Model: "AWS charged us $50 for this RDS instance, so we charge you $50."
- Pros: Maximally transparent. Teams can verify the number against public AWS pricing. No hidden markup.
- Cons: Doesn't recover the labor cost of the platform team managing, securing, and operating that database. The platform team effectively subsidizes every team's infrastructure management for free, which is economically unsustainable.
2. Markup (Platform Tax)
- Model: "AWS charged $50. We charge you $60." (20% platform overhead tax.)
- Pros: Funds the platform team's operational costs. Creates a sustainable economic model where the platform team's value is explicitly priced.
- Cons: Developers hate taxes. If the markup is too high, teams will attempt to bypass the platform and go directly to AWS ("Shadow IT") to save money — which defeats the entire purpose of the platform and creates security and compliance risks.
- Rule: Keep the markup below the cost of the alternative (self-managing the infrastructure). If managing your own RDS would cost a team 5 hours/month of engineering time at $100/hour = $500, a $10 markup on a $50 instance is a bargain. A $200 markup is not.
3. Subscription (SaaS-Style Flat Fee)
- Model: "Every team pays $500/month per developer for 'Platform Access' — unlimited use of all platform services."
- Pros: Predictable budgeting for consuming teams. Encourages unlimited use of platform tooling (since marginal cost is zero), which drives adoption and standardization.
- Cons: Hard to justify to teams with light usage ("We only use 10% of the platform but pay the same as the Data team"). Can mask runaway consumption by heavy users.
Choosing a Model
Most mature platform organizations use a hybrid: a base subscription fee covering access to shared services (CI/CD, observability, IDP), plus pass-through or light markup for variable consumption (compute, storage, data transfer). This gives teams predictable baseline costs while maintaining accountability for variable spend.
Interviewers for Staff Platform Engineer or Platform Product Manager roles sometimes ask: "How would you design a pricing model for your internal Kubernetes platform?" The trap is to pick one model and defend it dogmatically. The strong answer acknowledges the trade-offs of each model, explains that the right choice depends on organizational maturity and finance system capabilities, and proposes a hybrid approach with a clear rationale. Mentioning the Shadow IT risk of over-taxation demonstrates senior-level thinking.