Hey guys, I’m trying to understand the pricing mod...
# getting-started
Hey guys, I’m trying to understand the pricing model for Team plan. Let’s say if I spin up a k8s cluster with 2 nodes on EKS and it runs 24/7. How many resources does it take? and how many credits will I consume?
Hi Nick.
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
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
is the Pulumi free credit. And this free credit covers for about 200 resources per month.
Thanks for the explanation @steep-sunset-89396!
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 calculation per Hour: I think this is actually great. With the previous model, it was based on the number of users and regardless of the users activities. Now customers can have as many users as they want, not worry about license cost and how efficient these licenses are used. And pay a monthly fee inline with their actual usage.
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.