Keep these limitations in mind when designing your Spin applications to run on Akamai Functions. You can also refer to the FAQ section to learn more about Akamai Functions.

Resource tier limits

These limitations are unique for each Akamai Functions resource tier. There are currently two resource tiers available, Standard and Extended. Standard is intended for more lightweight use cases, while Extended allows more computationally intensive applications.

These limits can be increased to custom values. Reach out to your Akamai representative for more information

The rest of the limits on this page apply to all Functions regardless of their resource tier.

Request limits

These limits apply to each request handled by a Function, as well as outbound subrequests made from within a Function, for example, using the JavaScript fetch() API.

Outbound subrequests are further limited to 10000 requests per minute per deployed Akamai Function.

📘

These limits can be increased to custom values if needed. Reach out to your Akamai representative to inquire about options.

By default, connection pooling for subrequests is disabled. This creates a new connection for each subrequest, which can potentially impact performance. You can enable connection pooling on a per-Function basis if needed. Reach out to your Akamai representative for more information.

📘

The maximum request and response body sizes do not apply when streaming the body through an Akamai Function. In that case, there is no directly enforced limit besides related limits such as total memory usage.

Akamai Functions strips out the following request headers and request header prefixes before a request is handled by your code:

• x-request-id
• x-forwarded-for
• x-real-ip
• x-forwarded-client-cert
• akamai-* (except akamai-Bot and akamai-GRN)
• x-envoy-*
• fermyon-*
• x-akamai-*

Akamai Functions does not directly enforce specific limits on request rates per second (RPS) or minute (RPM). This is because the expected performance can vary significantly depending on factors such as chosen programming language, computational complexity of the use case, and the use of outbound connections. Internal load test results range anywhere between thousands (complex, resource intensive) to several millions (simple, fully optimized) of RPS per region. Below you can find some high-level guidance on what to expect.

• Functions are deployed across 25+ regions. The more geographically distributed your audience, the better Functions will scale.
• Use Rust if you need optimal performance. JavaScript and especially Python tend to scale worse due to their interpreted nature (sometimes two or three times worse than Rust depending on use case).
• For some use cases, the new Instance Reuse feature can have a strong positive impact on maximum RPS.
• Outbound connections (including Functions KV store reads/writes) can have a strong negative impact on maximum RPS.
• We do not recommend running your own (high scale) load tests without involvement from your Account team. There are many different limits that can come into play, both for Functions itself but also for the CDN you choose to front the Function with. Additionally, Functions has strong fairness restrictions in place which prevent a single app from taking up too many resources without manual overrides.

If you require additional information, need to make sure the platform can support your intended traffic numbers, want to run your own load tests, or get manual limit overrides in place, reach out to your Akamai representative.

Function quota limits

To get the total Function bundle size from Spin before deploying you can use the Spin dashboard project to view the the size of each individual component in the Akamai Function. The total bundle size is the sum of the component sizes. This project can also show you other information, such as how much memory your Akamai Function is using during local execution.

Account quota limits

As explained in Manage accounts, Akamai Functions has its own account system that uses Akamai Control Center as an identity provider to let you log in with your Akamai credentials.

There are currently no limits on the maximum number of Akamai Functions users or team accounts per Akamai Control Center contract. There is also no limit on the maximum number of users per team account or maximum team accounts a user can join.

Spin aka plugin quota limits

The spin aka plugin internally calls the Akamai Functions’ administrative API, which is rate limited. Additionally, some commands have their own limitations.

Personal Access Tokens generated with spin aka auth for automation purposes have largely the same rights and capabilities as the user who created them, but cannot:

• Delete a deployed Function
• Manage (create/update/delete/…) Personal Access Tokens

Logging quota limits

As described in Application logs and usage, Akamai Functions automatically captures stdout and stderr logs from your Akamai Functions and makes them available via spin aka logs.

These logs are intended to help you debug an application during development and should not be used as a full, production-level observability system. This is also reflected in the conservative logs limits.

Functions cron quota limits (Tech preview)

The Akamai Functions cron system for scheduling tasks using spin aka cron is currently still in a tech preview phase and is not subject to the same expectations of stability as the rest of the platform.

For example, crons are not 100% guaranteed to run, nor are they guaranteed to run at exactly the scheduled time. Additionally, crons are limited in number.

Functions KV quota limits (Limited availability)

The Akamai Functions Key Value store is currently in Limited Availability and is not subject to the same expectations of scalability as the rest of the platform. Additionally, the Functions KV backends are not deployed to the same level of geographical distribution as the rest of the platform, so there can be higher latencies when using it from certain regions.

This Limited Availability status is also reflected in the limits.

If these limits are not sufficient for your use case and you need a production-level KV store you can request a limit increase at an additional cost. Reach out to your Akamai representative for more information.

The Spin WASI Key Value interface is also compatible with other KeyValue stores, such as (self-hosted) Redis or the Akamai ValKey Managed Database.

Spin limits

Akamai Functions supports Spin CLI v4.0.0 or newer. Older Spin versions may work (especially for existing Functions projects), but are not guaranteed to. Some Spin SDK triggers and APIs are not yet supported on Akamai Functions.

To view the feature support for various programming languages, go to the Spin Language Support Guide.

Akamai Functions is committed to always running a supported version of the underlying wasmtime engine and to downstream security patches as soon as possible. In practice, this means we keep the platform updated to one of the two latest versions of wasmtime and the related Spin releases.

Platform limits

Due to the way Akamai Functions are currently deployed as a distributed setup in Akamai Cloud behind the fwf.app CDN property, calling function A from inside of function B can lead to degraded performance.

For example, if function B at FUNC-B.fwf.app executes the following JavaScript code, the platform will route the request starting from the Akamai Cloud into FUNC-A.fwf.app via the nearest Akamai CDN edge node, before coming back into the Akamai Cloud to call function A’s actual endpoint.

let result = await fetch("https://FUNC-A.fwf.app/endpoint?param=val");

Even though function A and B are likely deployed in the same cloud cluster, they cannot immediately access each other’s endpoints without an added round trip of latency via the CDN.

This is explicitly NOT the case for the Local Service Chaining feature, where components within the same Function can call each other over an HTTP abstraction. In those cases, the outbound call to COMPONENT.spin.internal is abstracted out completely and the endpoint invocation stays within the same WebAssembly execution context, never leaving the local server.

For example, if Function C consists of component X and component Y, the following request inside component X would be fully optimized and call the correct endpoint handler within Y directly. Local service chaining is a recommended best practice within Akamai Functions when using multiple components.

let result = await fetch("https://COMPONENT-Y.spin.internal/endpoint?param=val");