It's based on invocations, GB-seconds, CPU-seconds, and network egress. And there's a free tier, so you should be able to try with your use case and estimate your total future cost.
Ah, sadly no outbound networking requests on the free tier. In my opinion that is a critical use case for a tool like this.
This could be a non-starter if there's really no way try it for outbound requests without paying $25 / month. Hopefully I'm misunderstanding the pricing page.
Edit: The fine print for the custom plan:
> 3 The Spark plan only allows outbound network requests to Google owned services. On the Blaze plan, Cloud Functions provides a perpetual free tier. The first 2,000,000 invocations, 400,000 GB-sec, 200,000 CPU-sec, and 5GB of Internet egress traffic is provided for free each month. You are only charged on usage past this free allotment. Pricing is based on total number of invocations, and compute time. Compute time is variable based on the amount of memory and CPU provisioned for a function. For more information, see Cloud Functions Pricing.
To clear things up: You Can use the Blaze plan which is pay-as-you-go and starts at 0$ and has a large free tier. External requests are disabled on projects that do not have billing enabled but you can have billing enabled and still be within the free tier of usage. The Flame plan is the "fixed cost" plan starting at 25$ and also includes external requests.
Oh, so if my app is currently under all the Free tier quotas for DB/Hosting/Storage/transfer, I could sign up for Blaze and my cost would be $0? I didn't realize that, the pricing page doesn't seem to make that clear to me.
Edit: Actually, if I'm exploring this price calculator right, it appears that there is no free tier for DB if you are on Blaze, only a free tier for Functions. Which suggests I should leave my Free tier plan as is, set up a second project that only has Functions that make external calls in it, sign that up for Blaze, and call those functions from my free tier functions... Convoluted, but hey, it'd be free.
As mentioned in some other comments, the restriction on outbound requests without a billing account is to prevent abuse. I'm sure you could imagine some bad behavior if Cloud Functions allowed anyone to spin up a few million executions per month and hit any arbitrary web services.
Based on https://cloud.google.com/functions/pricing it seems like you can't pick and choose ram and CPU speed, so I'm not sure what the reason is to split the pricing between the two. I was quite interested in this because I've just found myself having to provision ~4x the amount of ram I actually need on lambda because I need more compute power.
Edit - It's interesting to see another player in the field though, so I'll be watching how things go.
On the Google Cloud Console you can change the memory allocation of your Cloud Functions: https://console.cloud.google.com/functions/list?project=_ we'll be providing better integrations with Firebase tools and also looking into providing more options in the future.
It looks like that is tied to the processing power, is that right? I can't see a way of picking them independently in that section, unless I'm missing something.
It's based on invocations, GB-seconds, CPU-seconds, and network egress. And there's a free tier, so you should be able to try with your use case and estimate your total future cost.