How am I billed for Serverless Functions?

Principle

Serverless Functions is billed on a pay-as-you-go basis. Three components are taken into account:

• Monthly request number: each time your function is invoked we increase a counter.

• Resource consumption: this component is obtained by multiplying the memory tiers chosen by the duration of each function invocation.

• Resources provision: in order to mitigate cold start, users can choose to keep some function instances warm (by filing the minimum scale value). We then charge for the provisioned resources similarly to the Resources consumption component.

The scheme below illustrates our billing model:

Pricing

• Monthly requests: €0.15 per million requests, and we offer 1M free requests per account per month.

• Resources consumption: €1.20 per 100 000 GB-s, and we provide 400 000 GB-s free tiers per account and per month.

• Resources provision: €0.36 per 100 000 GB-s

Examples

Example 1: Without resources provisioning

• Resources consumption

  • Service usage duration: 30 000 000 Requests x 1 s = 30 000 000 seconds used
  • Memory conversion: 128 MB = 0.125 GB
  • Resources consumed: 30 000 000 s x 0.125 GB = 3 750 000 GB-s
  • Free tier: 400 000 GB-s
  • Resourced billed: 3 750 000 - 400 000 = 3 350 000 GB-s
  • Cost: 3 350 000 x €0.0000120 = €40.20

• Requests:

  • Free tier: 1 000 000 requests
  • Billed requests: 30 000 000 - 1 000 000 = 29 000 000 Requests
  • Cost: 29 000 000 x €0.00000015 = €4.35

Total monthly cost: €44.55

Example 2: With resources provisioning

• Resources consumption

  • Service usage duration: 30 000 000 Requests x 1 s = 30 000 000 seconds used
  • Memory conversion: 128 MB = 0.125 GB
  • Resources consumed: 30 000 000 s x 0.125 GB = 3 750 000 GB-s
  • Free tier: 400 000 GB-s
  • Resourced billed: 3 750 000 - 400 000 = 3 350 000 GB-s
  • Cost: 3 350 000 x €0.0000120 = €40.20

• Provisioned functions consumption:

  • Provisioned duration: 1 month = 2 592 000 seconds, with one minimum instance → 2 592 000 seconds used
  • Provisioned resources consumed: 2 592 000 x 0.125 GB = 324 000 GB-s
  • Cost: 324 000 x €0.0000036 = €1.17

• Requests:

  • Free tier: 1 000 000 requests
  • Billed requests: 30 000 000 - 1 000 000 = 29 000 000 Requests
  • Cost: 29 000 000 x €0.00000015 = €4.35

Total monthly cost: €45.72

How to select the right resources (vCPU/RAM) for Serverless Functions ?

Insufficient vCPU and RAM resources can lead to functions going to error status. Make sure to provision enough resources for your function.

We recommend you set high values, use metrics to monitor the resource usage of your function, then adjust the value accordingly.

How to reduce cold-start of Serverless Functions ?

• Optimize the startup: Cold-start can be affected by a loading a large number of dependencies and opening lot of resources at startup. Ensure that your code avoid heavy computations or long-running initialization at statup and optimize the number of loaded libraries.

• Keep your function warm: You can use CRON triggers at certain intervals to keep your function warm or set the min-scale parameter to one when required.

• Increase resources: Adding more vCPU and RAM can help to significantly reduce the cold-starts of your function.

• Use sandbox v2: we recommend to use sandbox v2 (advanced settings) to reduce cold start.

What are the limitations of Serverless Functions?

Refer to our dedicated page about Serverless Functions limitations and configuration restrictions for more information.

What runtimes are available on Serverless Functions?

Serverless Functions enables you to deploy functions using popular languages: Go, Node, Python, PHP, Rust…

Refer to our dedicated page about Serverless Functions Runtimes Lifecycle

How can I check build errors?

Some Serverless runtimes (ex: Go, Rust) will compile your code in order to make your function executable. Compilation can fail if errors are present in the code, for example syntax errors and missing libraries.

Build errors are sent to the Observability platform on Scaleway Cockpit.

In the Serverless Functions Logs dashboard, you will then be able to read information about your log build outputs, if errors occurred during compilation.

Can I allow to list the IPs of my functions?

Serverless Functions does not yet support Private Networks. However, you can use the Scaleway IP ranges defined at https://www.scaleway.com/en/peering/ on Managed Databases and other products that allow IP filtering.

How can I deploy my Functions?

Serverless Functions use cases are wide so several ways to deploy functions are available.

How can I test my functions locally?

Scaleway provides libraries to run your functions locally, for debugging, profiling, and testing purposes. Refer to the dedicated documentation for more information.

Where can I find some advanced code examples for functions?

Check out our serverless-examples repository for real world projects.

How to migrate runtimes?

There are no constraints when changing a function runtime, you simply need to choose the runtime version you want. Upgrading a runtime is highly recommended in case of deprecation, and for runtimes that have reached end-of-support or end-of-life. See the functions runtimes lifecycle documentation for more information.

How do I configure access to a Private Network?

Scaleway Serverless Functions does not currently support Scaleway VPC or Private Networks, though this feature is under development.

To add network restrictions on your resource, consult the list of prefixes used at Scaleway. Note that Serverless resources do not have dedicated or predictable IP addresses.

How can I attach Block Storage to a Serverless Function?

Scaleway Serverless Functions do not currently support attaching Block Storage. These functions are designed to be stateless, meaning they do not retain data between invocations. For persistent storage, we recommend using external solutions like Scaleway Object Storage.

Why does my function have an instance running after deployment, even with min-scale 0?

Currently, a new function instance will always start after each deployment, even if there is no traffic and the minimum scale is set to 0. This behavior is not configurable at this time.