01
Overview
Fastly AI Runtime Control (ARC) puts a control layer between your application and the LLM providers it calls. Instead of embedding a raw Anthropic, Bedrock or other provider credential directly in every client, the application sends requests through ARC using a Fastly virtual key.
This guide focuses on the operational setup documented by Fastly: provider connections, virtual keys, limits, monitoring and provider failover. Exact UI labels and product lifecycle status can change, so verify them against current Fastly documentation before production rollout.
02
Before you start
Fastly's current ARC documentation requires appropriate account access; some monitoring tasks require the superuser role. You also need credentials for the upstream LLM providers you intend to route through ARC, unless you are registering an endpoint you host yourself.
ARC is a routing and governance layer. It does not host the models for you.
03
1. Connect an LLM provider
Configure the provider account and credentials that ARC will use upstream. ARC stores the provider credential so applications can authenticate with Fastly-issued virtual keys instead of carrying the raw provider secret.
If you operate your own compatible model endpoint, Fastly says ARC can register a self-hosted endpoint as a routing target as well.
Treat provider credentials as production secrets. The point of the virtual-key layer is to reduce how widely those upstream secrets need to be distributed.
04
2. Create a virtual key
A virtual key is the main policy object ARC applies to requests. It identifies where traffic should go and which limits apply.
Fastly recommends separating keys in ways that make usage understandable—for example one key per application, environment or developer. That lets ARC attribute requests and token usage to the workload that generated them.
A key can be refreshed or deleted without changing the upstream provider account. Refreshing rotates the ARC credential; deleting it revokes new requests using that key.
05
3. Point your application at ARC
Instead of calling the model provider directly, configure the application to send its request to the ARC endpoint and authenticate with its virtual key.
ARC identifies the key, determines its provider/model route, applies configured limits, substitutes the provider credential and forwards the request. The provider's response then returns through ARC to the application.
This means every governed request needs to traverse ARC. A client that bypasses ARC and calls the provider directly will also bypass ARC's key-level budget, rate and security controls.
06
4. Add a budget limit
Fastly supports monthly dollar budget limits on individual virtual keys. Its tutorial documents two actions: Alert, which notifies superusers while traffic continues, and Alert & Block, which stops additional use of the key after the limit is reached.
A practical pattern is to use a warning threshold below the hard cap. Fastly's tutorial uses illustrative dollar amounts, but those numbers are examples—not recommended universal budgets.
Set thresholds based on your own workload economics and the consequences of blocking a production key.
07
5. Add a rate limit
ARC can rate-limit a virtual key by requests per minute or tokens per minute. Rate limits are useful for runaway agents, unexpected traffic spikes and clients that could otherwise exhaust upstream quotas.
Fastly notes an important limitation: token counts are only known after a response completes, so token-based rate limits are applied on a best-effort basis rather than with perfect precision.
Set the threshold above expected normal traffic, then test how your application handles ARC's limit-exceeded response.
08
6. Configure provider failover
A virtual key can hold an ordered provider list. Fastly's own tutorial uses Anthropic as the primary route for Claude Code and AWS Bedrock as the backup provider serving the same model.
Add the secondary provider to the key's Provider Routing & Failover configuration. ARC starts each request at the first provider. If that provider cannot serve the request, ARC can move down the list. When the preferred provider recovers, subsequent requests begin there again automatically.
Do not assume different models are interchangeable simply because multiple providers are configured. Failover should preserve the model and workload behavior your application requires.
09
7. Verify monitoring
ARC exposes a Summary view for request and token volume and a Logging view for individual request records. Fastly documents filters including virtual key, provider, model and date range.
Use these views immediately after setup to confirm that requests are flowing through the expected key and provider, token accounting is appearing, and failover or limits behave as intended.
Fastly's monitoring documentation says session logs can contain the message and response as JSON. Review that behavior against your privacy, retention and compliance requirements before routing sensitive prompts through the system.
10
8. Decide whether to enable AI Firewall
AI Firewall is a separately purchased ARC add-on. When enabled on a virtual key, Fastly says it inspects requests and responses for LLM-specific threats including prompt injection.
Do not treat enabling the feature as proof that an application is secure. Test it against your own attack patterns, tool permissions and agent architecture, and maintain application-level authorization boundaries.
11
Production checklist
Before switching a production workload, verify provider credentials, virtual-key rotation, expected model route, backup-provider behavior, monthly budget actions, request/token rate limits, monitoring access, prompt/response logging requirements, application behavior when ARC blocks a request, and the current lifecycle status of ARC features.
Also measure end-to-end latency with your own region, model and workload. Fastly's performance language is vendor-reported and should not replace workload-specific testing.
12
Bottom line
A minimal Fastly ARC deployment is straightforward conceptually: connect the provider, create a virtual key, route the application through ARC, add spending/rate boundaries, and verify usage. Multi-provider failover and AI Firewall can then be layered on where the workload justifies them.
The most important architectural rule is that ARC is the intermediary, not the model host. Your provider accounts and model endpoints remain the systems actually serving inference; ARC centralizes how applications reach and govern them.
Sources
Primary and supporting sources
Use the linked documentation to check current pricing, access and product behaviour. The dates above describe this article; they do not guarantee that every vendor claim remains current.