The pulumi price is based on the number of resources that Pulumi manages. If as part of your k8s cluster, you also create a VPC, some security groups and a few other resources, you will have more than 1 cluster and 2 nodes (3 resources). Last time I tried the

aws-go-eks

it consumed 16 pulumi resources. https://github.com/pulumi/examples/tree/master/aws-go-eks If we assume the cluster runs for 1 full month 24x7 (730 hours) then formula is like this: (((16*730)-150000)*0.00025) = $0/month The

150000

is the Pulumi free credit. And this free credit covers for about 200 resources per month.

The credit system is quite confusing and somewhat ambiguous in a bad way since it’s calculated per hr.

How about serverless system like lambda, let’s say a simple Route 53, Api Gate Way, Lambda, Aurora and a bunch of security groups..that would blow out pretty quickly.

Re resource blow out: I thought about it quite a lot. But I see this in 2 folds... 1 - with AWS, anything that's compute related (in your example Aurora) will significantly increase your fees. Aurora MySQL starts at $0.073/Hr. That's x292 times the price of a single Pulumi resource. Bear in mind there's about ~200 free resources/month as part of the free tier. But likewise with any Cloud providers, spinning up too many resources will inevitably increase the code. However, Pulumi elegantly reclaims resources that have been removed from your deployments. At best cloud providers will make suggestions on where/how you could save. 2 - I also see customers saving cost (ie, not spending money) on highly specialised engineers (TF, CFn...). Since Pulumi uses general purpose programming languages, it's easier to higher someone who already know one of the supported languages and get them to only learn the programming API. Now I hear about having too many resources. Pulumi users have access to the state file of their stack via

pulumi stack export

. If the number of resources is a concern, here's a command worth integrating into your CI/CD

pulumi stack export | jq '.deployment.resources | length'

. It actually outputs the number of resources in your stack. This could be pushed into a time series DB and have monitoring/alert in place or any business logic really. Last note: for the formula I shared with you above, I'll speak with the team and I agree with should try to make it clearer. Maybe the formula alongside with an example or two would be helpful. What do you think? I hope that makes sense.