Join us from October 8-10 in New York City to learn the latest tips, trends, and news about GraphQL federation and API platform engineering.Join us for GraphQL Summit 2024 in NYC
Start for Free

Migrate Serverless routers to AWS

Learn how to migrate Serverless cloud routers from to AWS


This page only applies to created before May 21, 2024. All Serverless cloud routers created on or after this date automatically run on AWS.

Serverless is switching cloud providers from to AWS to improve reliability and performance. Serverless cloud routers running on infrastructure must be migrated in .

Who needs to migrate?

You may need to migrate if:

  • Your organization is on a OR
  • Your organization is on a but uses Serverless for non-production environments

To check if you need to migrate, go to GraphOS Studio. If a 's Cloud Router Details on the Overview page shows ord - US (Chicago) as the Region, you need to migrate it.

Cloud router region showing ord - US (Chicago) in GraphOS Studio

on will continue to operate until June 27, 2024. After this date, any cloud routers on will be permanently deleted and using them will no longer respond to requests. Don't hesitate to contact with any migration questions or concerns.

What's changing?

The move to AWS improves reliability and performance. It also changes the cloud hosting region and inactivity periods. With improved reliability and performance, Serverless can offer additional features. Refer to the pricing page for the full list of supported features.

Reliable throughput

On AWS, Serverless cloud routers can process a consistent 10 requests per second (RPS) of throughput.


If you need more than 10 RPS throughput or have complex schemas, consider upgrading to .

Hosting region

On, cloud routers were hosted in Chicago (ord). On AWS, they're hosted in Northern Virginia (us-east-1). This means faster performance, particularly for customers running on AWS, especially if they are in or near us-east-1.


Dedicated offers a wider variety of AWS regions.

Inactivity periods

On, Serverless cloud routers sleep after two minutes of inactivity. Sleeping routers can't serve requests and must wake up to do so. On AWS, cloud routers sleep after seven days of inactivity.

After a total 30 days of inactivity, Apollo deletes Serverless cloud routers. Deletion preserves a cloud router's associated 's schema but deletes the underlying cloud router. Learn more in Serverless router status. HostedAWS Hosted
Inactivity period
before sleep
2 minutes7 days
Inactivity period
before deletion
30 days30 days

How to migrate

Apollo is unable to offer an in-place migration. To migrate, you need to create a new variant on your graph, or create a new graph entirely. Once you create this new variant or graph, you receive a new and endpoint URL that you must redirect your client traffic to.


To avoid downtime for clients your graph, don't delete the variant that houses your existing until you've created a new one.

Step 1. Create a new graph

To get started, create a new graph or variant in GraphOS Studio. See the getting started for details on creating a new graph.


For Dedicated customers with Serverless variants:

You can't migrate Serverless variants on a Dedicated plan from Studio. Instead, you must publish a new variant or graph using the Rover CLI. All variants created via default to Serverless, even if your organization is on the Dedicated plan.

All Serverless cloud routers created on or after May 21, 2024 automatically run on AWS. You can confirm your new router is running on AWS by checking that the router region is AWS us-east-1 on the variant's Overview page under Cloud Router Details.

Variant overview page in GraphOS Studio

Creating a new graph or variant generates a new endpoint URL and graph ref. You'll update these values in later steps.

Step 2. Add subgraphs

Each variant needs at least one . If you have multiple subgraphs, add each subgraph to your new variant.

Step 3. Setup router configuration

Copy and paste your old 's configuration into your new one. You can access a cloud router's configuration in GraphOS Studio under Cloud Router > Configuration.

Configuring the cloud router in GraphOS Studio

configuration defines important values like CORS policies and header propagation.


If you have secrets in your old cloud router config, you must also set them in your new one. Secrets can't be read once saved.

Step 4. Test

After you've added all your and set up your cloud router config, try running a few sample from Explorer. You may need to enable subgraph errors to troubleshoot if your operations don't execute.

Simulate production traffic before going live. Serverless on AWS offers less but more reliable throughput than on If you exceed throughput limits, your clients receive 429 errors.


It isn't possible to increase throughput on Serverless. If you need more than 10 RPS throughput, consider upgrading to Dedicated.

Step 5. Go live

To go live, update the endpoint URL your clients use to your graph. You can see your new router's endpoint from the Overview page of your variant.

Variant overview page in GraphOS Studio

If you use any Rover commands in your CI/CD, update the graph ref.

Once you've updated your client codebase and Rover commands, you can delete the variant housing your cloud router.

Rate articleRateEdit on GitHubEditForumsDiscord

© 2024 Apollo Graph Inc.

Privacy Policy