--- title: Keep AI traffic flowing with failover providers in AI Runtime Control summary: >- Use AI Runtime Control (ARC) to keep requests flowing when a provider has trouble by configuring a second provider that serves the same model as a backup. url: >- https://www.fastly.com/documentation/solutions/tutorials/ai-runtime-control/set-up-failover-ai-providers --- In this tutorial, you'll use AI Runtime Control (ARC) to keep your team's AI traffic flowing when a provider has trouble. We'll use the same three engineers from the [per-engineer usage tutorial](https://www.fastly.com/documentation/solutions/tutorials/ai-runtime-control/track-per-engineer-ai-usage/) as a stand-in for a larger team. The scenario is a common one. You route Claude Code traffic through Anthropic, but when Anthropic has technical trouble or rate limits you, your engineers stop working. You'll configure AWS Bedrock as a second provider serving the same model, add it to each engineer's virtual key as a backup, and learn where failover shows up in ARC when it happens. By the end, you'll understand why failover is configured between providers that serve the same model, and how the order you choose encodes a preference. ## Before you begin This tutorial assumes you've already [tracked per-engineer AI usage](https://www.fastly.com/documentation/solutions/tutorials/ai-runtime-control/track-per-engineer-ai-usage/), so you have a virtual key for each engineer. If you don't, create one key per person before you start. You'll also need the following: - The [superuser role](https://www.fastly.com/documentation/guides/organizations-and-accounts/account-members-and-permissions/about-user-roles-and-permissions/). Other account roles can't access ARC. - Anthropic configured as a provider in ARC, serving Claude Opus 4.8, and a virtual key for each engineer that routes to it. - An API key for an AWS Bedrock account that also serves Claude Opus 4.8. Bedrock also supports AWS IAM authentication, but this tutorial uses an API key. ## Why failover is between providers Failover replaces the provider that serves a request, not the model that answers it. Your engineers ask for a particular model, and ARC's job is to find a provider that can serve it. That's why the two providers in this tutorial both offer Claude Opus 4.8. If your backup provider doesn't serve the model your engineers request, ARC can't use it, and failover does nothing for you. It also means the order you choose is a preference rather than a ranking of quality. You might lead with the provider you've standardized on, or with the one that costs you least, and keep the other in reserve for when the first can't serve a request. ## Step 1: Configure your backup provider You already have Anthropic configured from the per-engineer tutorial. Now add AWS Bedrock, making the same model available. 1. Go to **Tools** > **AI Runtime Control**. 2. Click the **Providers** tab. 3. Click **Add**, then select **AWS Bedrock**. 4. For **Authentication type**, select **API Key**. 5. Fill out the rest of the provider form as follows: - In the **API key** field, enter your AWS Bedrock API key. - Under **Model permissions**, select **Limit model access** and add **Claude Opus 4.8**. 6. Click **Save**. Both providers now serve Claude Opus 4.8. Check the model you selected against the one on your primary provider. If they don't match, failover won't work when you need it. ## Step 2: Add the backup to an engineer's key Next, add AWS Bedrock to an engineer's virtual key as the second provider in the list. 1. Click the **Virtual keys** tab. 2. Click the three dots More icon to the right of the engineer's virtual key and then click **Edit**. 3. In the **Provider Routing & Failover** area, confirm that **Anthropic** is selected in the **Select provider** menu as the primary target for this key. 4. Click **Add failover**, then select **AWS Bedrock** from the **Select provider** menu that appears. 5. Click **Save**. The key now routes to Anthropic first. If Anthropic can't serve a request, ARC tries Bedrock instead, and your engineer's Claude Code session continues without interruption. ## Step 3: Repeat for each engineer Repeat the steps for adding a backup provider on each remaining engineer's virtual key. You can set a different order for different keys. If one engineer's work is more cost-sensitive than another's, the cheaper provider can lead on their key while another key leads with a different one. ## Step 4: Recognize failover when it happens ARC fails over when your primary provider can't serve a request, whether because the provider returns an error or because it can't serve the model your engineer asked for. Each request starts fresh at the top of the list, so once your primary recovers, requests go back to it without you doing anything. There's nothing to turn on and nothing to watch for day to day. What's worth knowing is where failover shows up afterward. 1. Click the **Logging** tab. 2. Search for an engineer's virtual key, or set the virtual key filter. 3. Click the **view details** icon at the end of a record's row to open its session log. When ARC fails over during a session, the session log indicates that a request moved from one provider to another. Failed-over request log entries show the provider that actually served the request. ## What's next You've set up a backup provider for your team's AI traffic and seen where failover is recorded. From here, you can: - apply the same pattern to the virtual keys your applications use. - add a third provider to a key. - set [budget and rate limits](https://www.fastly.com/documentation/solutions/tutorials/ai-runtime-control/cap-team-ai-spending/) on those same virtual keys.