-
-## Apollo Sandbox
-
-The landing page above provides a link to [Apollo Sandbox](https://studio.apollographql.com/sandbox), a powerful web IDE that enables you to build and run operations against your router. Sandbox is a special mode of [GraphOS Studio](https://www.apollographql.com/docs/studio/) that doesn't require an Apollo account.
-
-
diff --git a/docs/source/images/cloud-dedicated/add-a-subgraph.jpg b/docs/source/images/cloud-dedicated/add-a-subgraph.jpg
new file mode 100644
index 0000000000..7f75526238
Binary files /dev/null and b/docs/source/images/cloud-dedicated/add-a-subgraph.jpg differ
diff --git a/docs/source/images/cloud-dedicated/create-new-graph.jpg b/docs/source/images/cloud-dedicated/create-new-graph.jpg
new file mode 100644
index 0000000000..249c9896d3
Binary files /dev/null and b/docs/source/images/cloud-dedicated/create-new-graph.jpg differ
diff --git a/docs/source/images/cloud-dedicated/create-resource-share-final.jpg b/docs/source/images/cloud-dedicated/create-resource-share-final.jpg
new file mode 100644
index 0000000000..6a2b5ce958
Binary files /dev/null and b/docs/source/images/cloud-dedicated/create-resource-share-final.jpg differ
diff --git a/docs/source/images/cloud-dedicated/delete-network-associations.jpg b/docs/source/images/cloud-dedicated/delete-network-associations.jpg
new file mode 100644
index 0000000000..daa7bae0d3
Binary files /dev/null and b/docs/source/images/cloud-dedicated/delete-network-associations.jpg differ
diff --git a/docs/source/images/cloud-dedicated/delete-resource-share.jpg b/docs/source/images/cloud-dedicated/delete-resource-share.jpg
new file mode 100644
index 0000000000..0e9dc8f7fa
Binary files /dev/null and b/docs/source/images/cloud-dedicated/delete-resource-share.jpg differ
diff --git a/docs/source/images/cloud-dedicated/graphos-service.jpg b/docs/source/images/cloud-dedicated/graphos-service.jpg
new file mode 100644
index 0000000000..473f7d6376
Binary files /dev/null and b/docs/source/images/cloud-dedicated/graphos-service.jpg differ
diff --git a/docs/source/images/cloud-dedicated/http-listener.jpg b/docs/source/images/cloud-dedicated/http-listener.jpg
new file mode 100644
index 0000000000..183ee38fef
Binary files /dev/null and b/docs/source/images/cloud-dedicated/http-listener.jpg differ
diff --git a/docs/source/images/cloud-dedicated/insights-page.jpg b/docs/source/images/cloud-dedicated/insights-page.jpg
new file mode 100644
index 0000000000..b113aca704
Binary files /dev/null and b/docs/source/images/cloud-dedicated/insights-page.jpg differ
diff --git a/docs/source/images/cloud-dedicated/manage-capacity.jpg b/docs/source/images/cloud-dedicated/manage-capacity.jpg
new file mode 100644
index 0000000000..d58ab78255
Binary files /dev/null and b/docs/source/images/cloud-dedicated/manage-capacity.jpg differ
diff --git a/docs/source/images/cloud-dedicated/managed-permissions.jpg b/docs/source/images/cloud-dedicated/managed-permissions.jpg
new file mode 100644
index 0000000000..15369112b8
Binary files /dev/null and b/docs/source/images/cloud-dedicated/managed-permissions.jpg differ
diff --git a/docs/source/images/cloud-dedicated/register-targets.jpg b/docs/source/images/cloud-dedicated/register-targets.jpg
new file mode 100644
index 0000000000..e062b3890c
Binary files /dev/null and b/docs/source/images/cloud-dedicated/register-targets.jpg differ
diff --git a/docs/source/images/cloud-dedicated/request-rate.jpg b/docs/source/images/cloud-dedicated/request-rate.jpg
new file mode 100644
index 0000000000..485ab7d07b
Binary files /dev/null and b/docs/source/images/cloud-dedicated/request-rate.jpg differ
diff --git a/docs/source/images/cloud-dedicated/resource-principal.jpg b/docs/source/images/cloud-dedicated/resource-principal.jpg
new file mode 100644
index 0000000000..ed80e5706d
Binary files /dev/null and b/docs/source/images/cloud-dedicated/resource-principal.jpg differ
diff --git a/docs/source/images/cloud-dedicated/resource-selection.jpg b/docs/source/images/cloud-dedicated/resource-selection.jpg
new file mode 100644
index 0000000000..8e41770a7a
Binary files /dev/null and b/docs/source/images/cloud-dedicated/resource-selection.jpg differ
diff --git a/docs/source/images/cloud-dedicated/resource-share-summary.jpg b/docs/source/images/cloud-dedicated/resource-share-summary.jpg
new file mode 100644
index 0000000000..03073f86f9
Binary files /dev/null and b/docs/source/images/cloud-dedicated/resource-share-summary.jpg differ
diff --git a/docs/source/images/cloud-dedicated/service-identifiers.jpg b/docs/source/images/cloud-dedicated/service-identifiers.jpg
new file mode 100644
index 0000000000..57855ea476
Binary files /dev/null and b/docs/source/images/cloud-dedicated/service-identifiers.jpg differ
diff --git a/docs/source/images/cloud-dedicated/service-rules.jpg b/docs/source/images/cloud-dedicated/service-rules.jpg
new file mode 100644
index 0000000000..6855a8cb41
Binary files /dev/null and b/docs/source/images/cloud-dedicated/service-rules.jpg differ
diff --git a/docs/source/images/cloud-dedicated/target-group-configuration.jpg b/docs/source/images/cloud-dedicated/target-group-configuration.jpg
new file mode 100644
index 0000000000..cde5a76df2
Binary files /dev/null and b/docs/source/images/cloud-dedicated/target-group-configuration.jpg differ
diff --git a/docs/source/images/cloud-dedicated/vpc-lattice-access-logs.png b/docs/source/images/cloud-dedicated/vpc-lattice-access-logs.png
new file mode 100644
index 0000000000..7bbe0a5c27
Binary files /dev/null and b/docs/source/images/cloud-dedicated/vpc-lattice-access-logs.png differ
diff --git a/docs/source/images/cloud-dedicated/vpc-lattice-metrics.png b/docs/source/images/cloud-dedicated/vpc-lattice-metrics.png
new file mode 100644
index 0000000000..5853d2dd20
Binary files /dev/null and b/docs/source/images/cloud-dedicated/vpc-lattice-metrics.png differ
diff --git a/docs/source/images/cloud-dedicated/vpc-lattice-routing.png b/docs/source/images/cloud-dedicated/vpc-lattice-routing.png
new file mode 100644
index 0000000000..b181e70150
Binary files /dev/null and b/docs/source/images/cloud-dedicated/vpc-lattice-routing.png differ
diff --git a/docs/source/images/get-started/qp-dark.svg b/docs/source/images/get-started/qp-dark.svg
new file mode 100644
index 0000000000..83b4402049
--- /dev/null
+++ b/docs/source/images/get-started/qp-dark.svg
@@ -0,0 +1,24 @@
+
diff --git a/docs/source/images/get-started/qp.svg b/docs/source/images/get-started/qp.svg
new file mode 100644
index 0000000000..acb4808d9c
--- /dev/null
+++ b/docs/source/images/get-started/qp.svg
@@ -0,0 +1,24 @@
+
diff --git a/docs/source/images/get-started/super-routing-1-dark.svg b/docs/source/images/get-started/super-routing-1-dark.svg
new file mode 100644
index 0000000000..af4bc9a20e
--- /dev/null
+++ b/docs/source/images/get-started/super-routing-1-dark.svg
@@ -0,0 +1,55 @@
+
diff --git a/docs/source/images/get-started/super-routing-1.svg b/docs/source/images/get-started/super-routing-1.svg
new file mode 100644
index 0000000000..6c417ece8b
--- /dev/null
+++ b/docs/source/images/get-started/super-routing-1.svg
@@ -0,0 +1,65 @@
+
diff --git a/docs/source/images/get-started/super-routing-2-dark.svg b/docs/source/images/get-started/super-routing-2-dark.svg
new file mode 100644
index 0000000000..45d85cdf75
--- /dev/null
+++ b/docs/source/images/get-started/super-routing-2-dark.svg
@@ -0,0 +1,59 @@
+
diff --git a/docs/source/images/get-started/super-routing-2.svg b/docs/source/images/get-started/super-routing-2.svg
new file mode 100644
index 0000000000..2ae570f87e
--- /dev/null
+++ b/docs/source/images/get-started/super-routing-2.svg
@@ -0,0 +1,69 @@
+
diff --git a/docs/source/images/get-started/super-routing-3-dark.svg b/docs/source/images/get-started/super-routing-3-dark.svg
new file mode 100644
index 0000000000..cc6cea31d4
--- /dev/null
+++ b/docs/source/images/get-started/super-routing-3-dark.svg
@@ -0,0 +1,67 @@
+
diff --git a/docs/source/images/get-started/super-routing-3.svg b/docs/source/images/get-started/super-routing-3.svg
new file mode 100644
index 0000000000..78e84e9e5c
--- /dev/null
+++ b/docs/source/images/get-started/super-routing-3.svg
@@ -0,0 +1,67 @@
+
diff --git a/docs/source/images/initiating-endpoint.jpg b/docs/source/images/initiating-endpoint.jpg
new file mode 100644
index 0000000000..b391c7d5aa
Binary files /dev/null and b/docs/source/images/initiating-endpoint.jpg differ
diff --git a/docs/source/images/router/cloud-router-configuration.jpg b/docs/source/images/router/cloud-router-configuration.jpg
new file mode 100644
index 0000000000..b14986e31a
Binary files /dev/null and b/docs/source/images/router/cloud-router-configuration.jpg differ
diff --git a/docs/source/images/router/cloud-router-details.jpg b/docs/source/images/router/cloud-router-details.jpg
new file mode 100644
index 0000000000..965810919b
Binary files /dev/null and b/docs/source/images/router/cloud-router-details.jpg differ
diff --git a/docs/source/images/router/cloud-router-region-ord.jpg b/docs/source/images/router/cloud-router-region-ord.jpg
new file mode 100644
index 0000000000..ff8ec6bef3
Binary files /dev/null and b/docs/source/images/router/cloud-router-region-ord.jpg differ
diff --git a/docs/source/images/router/router-endpoint.jpg b/docs/source/images/router/router-endpoint.jpg
new file mode 100644
index 0000000000..bb341ecae0
Binary files /dev/null and b/docs/source/images/router/router-endpoint.jpg differ
diff --git a/docs/source/index.mdx b/docs/source/index.mdx
deleted file mode 100644
index 3ad0bb4e8f..0000000000
--- a/docs/source/index.mdx
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: Self-Hosted Router
-subtitle: High-performance routing with self-hosted supergraph runtimes
-description: Distribute operations efficiently across microservices in your federated GraphQL API with the Apollo GraphOS Router or Apollo Router Core. Configure caching, security features, and more.
----
-
-import { Link } from 'gatsby';
-
-API]; - serviceC[Reviews
API]; - router -->|Sub-query| serviceB & serviceC; - end; - clients -.->|Query| router; - class clients secondary; -``` - -The router intelligently distributes inbound queries across your GraphQL-powered microservices, enabling clients to fetch data from multiple sources with a single request. - -> Learn about the [distinction between the router and an API gateway](/technotes/TN0037-api-gateways/). - - -If you have an existing federated graph that currently uses `@apollo/gateway`, you can move to the router without changing any other part of your graph. - -
- - -
- -> **This documentation helps you run a _self-hosted_ instance of a router.** If you [create a cloud supergraph](/graphos/quickstart/cloud/) with Apollo GraphOS, Apollo provisions and hosts a GraphOS Router for you. -> -> Cloud supergraphs are recommended for organizations that don't need to host their router in their own infrastructure. - - -## Features - -- Full support for [Apollo Federation](/federation/) and supergraph management via [GraphOS](/graphos/) -- Extensive declarative [configuration options](./configuration/overview) (header propagation, CORS settings, OpenTelemetry support, and more) -- Support for [scripting](./customizations/rhai/) via the Rhai scripting language -- Advanced [GraphOS Enterprise features](./enterprise-features), including: - - Real-time data via [GraphQL subscriptions](./executing-operations/subscription-support/) - - [JWT authentication](./configuration/authn-jwt) - - [Distributed caching](./configuration/distributed-caching/) for multi-router fleets - - Customization in any language via [external coprocessing](./customizations/coprocessor/) - - [Operation limits](./configuration/operation-limits/) diff --git a/docs/source/privacy.mdx b/docs/source/privacy.mdx deleted file mode 100644 index 5d675f8779..0000000000 --- a/docs/source/privacy.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Privacy and Data Collection -subtitle: Learn what data the router collects and how to opt out -description: Learn what data the Apollo GraphOS Router and Apollo Router Core collect and how to opt out. By default, the router collects anonymous usage data to help improve the product. ---- - -By default, the GraphOS Router or Apollo Router Core collects anonymous usage data to help us improve the product. - -The router doesn't collect any personally identifiable information such as API keys, graph names, or file paths. - -and license"-->uplink; +``` + +A router instance retains its license for the duration of its execution. If you stop a router instance and then later start a new instance on the same machine, it must fetch a new license. + +Licenses are served via [Apollo Uplink](/graphos/routing/uplink), the same multi-cloud endpoint that your router uses to fetch its supergraph schema from GraphOS. Because of this, licenses introduce no additional network dependencies, meaning your router's uptime remains unaffected. To learn more about multi-cloud Uplink, read the [Apollo blog post](https://www.apollographql.com/blog/announcement/backend/introducing-multi-cloud-support-for-apollo-uplink). + +A router instance's license is valid for the duration of your organization's current subscription billing period (plus a [grace period](#grace-period-for-expired-plans)), even if the router temporarily becomes disconnected from GraphOS. + +
| - |
-Standard Check Behavior -(Legacy reference reporting) - |
-
-Enhanced Check Behavior -(Extended reference reporting) - |
-||
|---|---|---|---|---|
+
+ |
+ |
+ Standard Check Behavior |
+ + (Legacy reference reporting) +
+ Enhanced Check Behavior |
+ + (Extended reference reporting) + | |
| ##### Enum value removal - | -Removing any enum values is considered a breaking change if any operations use the enum. | -Removing enum values is only a breaking change if historical operations use the specific enum value(s) that were removed. | -||
| + | +Removing any enum values is considered a breaking change if any operations use the enum. | +Removing enum values is only a breaking change if historical operations use the specific enum value(s) that were removed. | +||
| ##### Default argument changes for input object fields - | - -Changing or removing a default argument is generally considered a breaking change, but changing or removing default values for input object fields isn't. | -- -Changing or removing default values for input object fields is considered a breaking change. -You can [configure checks to ignore default values changes](/graphos/delivery/schema-checks/#ignored-conditions-settings). + | ++ Changing or removing a default argument is generally considered a breaking change, but changing or removing default values for input object fields isn't. + | ++ Changing or removing default values for input object fields is considered a breaking change. +You can [configure checks to ignore default values changes](/graphos/platform/schema-management/checks#ignored-conditions-settings). - | -
| + | +||||
| ##### Nullable input object field removal - | -Removing a nullable input object field is always considered a breaking change. | -Removing a nullable input object field is only considered a breaking change if the nullable field is present in historical operations. If the nullable field is always omitted in historical operations, its removal isn't considered a breaking change. | -||
| + | +Removing a nullable input object field is always considered a breaking change. | +Removing a nullable input object field is only considered a breaking change if the nullable field is present in historical operations. If the nullable field is always omitted in historical operations, its removal isn't considered a breaking change. | +||
| ##### Changing nullable input object fields to non-nullable - | -Changing a nullable input object field to non-nullable is considered a breaking change. | -Changing a nullable input object field to non-nullable is only considered a breaking change if the field had a null value in historical operations. If the field was always a non-null value in historical operations, changing it to non-nullable isn't considered a breaking change. |
-Changing a nullable input object field to non-nullable is considered a breaking change. | +Changing a nullable input object field to non-nullable is only considered a breaking change if the field had a null value in historical operations. If the field was always a non-null value in historical operations, changing it to non-nullable isn't considered a breaking change. |
+
+
+
+
+### Runtime of GraphOS platform
+
+As the runtime of the [GraphOS platform](/graphos/get-started/concepts/graphos), a GraphOS Router gets the supergraph schema—the blueprint of the federated graphs—from the GraphOS control plane. It then executes incoming clients operations based on that schema.
+
+Unlike API gateways that offer capabilities to manage API endpoints, the router isn't based on URLs or REST endpoints. Rather, the router is a GraphQL-native solution for handling client APIs.
+
+### Subgraph query planner
+
+Whenever your router receives an incoming GraphQL operation, it needs to figure out how to use your subgraphs to populate data for each of that operation's fields. To do this, the router generates a _query plan_:
+
+
+
+
+A query plan is a blueprint for dividing a single incoming operation into one or more operations that are each resolvable by a single subgraph. Some of these operations depend on the results of other operations, so the query plan also defines any required ordering for their execution. The router's query planner determines the optimal set of subgraph queries for each client operation, then it merges the subgraph responses into a single response for the client.
+
+
+
+
+
+
+
+### Common router core
+
+Both cloud-hosted and self-hosted routers are powered by the [Apollo Router Core](https://github.com/apollographql/router)—a high-performance router packaged as a standalone binary.
+
+### Router type comparison
+
+Apollo offers the following router options, in increasing order of configurability:
+
+| Router type | +Description | +Configurability | +Plan availability | +
|---|---|---|---|
| Shared cloud router | +Apollo provisions and manages routers on shared infrastructure. | ++ Basic configurability, including HTTP header rules, CORS settings, and + subgraph error inclusion + | ++ Serverless** + | +
| Dedicated cloud router | ++ Apollo provisions and manages routers on dedicated infrastructure that + you control and scale. + | ++ Highly configurable, including all options for shared cloud routers and + additional configurations + | ++ Dedicated** + | +
| Self-hosted router | +You host and manage the router on your own infrastructure. | ++ Highly configurable and customizable, including all options for Cloud + Dedicated routers and additional [customization options](/graphos/routing/customization/overview). + | ++ The Apollo Router Core is available as a free and source-available router. + Connecting your self-hosted router to GraphOS requires an{' '} + Enterprise plan. + | +
+
+Cloud routers on Fly.io will continue to operate until June 27, 2024. After this date, any cloud routers on Fly.io will be permanently deleted and graphs using them will no longer respond to requests.
+Don't hesitate to contact [cloud@apollographql.com](mailto:cloud@apollographql.com) 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 GraphOS Router features. Refer to the [pricing page](https://www.apollographql.com/pricing#graphos-router) 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.
+
+before sleep | 2 minutes | 7 days | +| Inactivity period
before deletion | 30 days | 30 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 graph ref and endpoint URL that you must redirect your client traffic to. + +
+
+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 subgraph. If you have multiple subgraphs, [add each subgraph](/graphos/quickstart/next-steps/#add-another-subgraph) to your new variant.
+
+### Step 3. Setup router configuration
+
+Copy and paste your old router's configuration into your new one. You can access a cloud router's configuration in GraphOS Studio under **Cloud Router > Configuration**.
+
+
+
+Router configuration defines important values like CORS policies and header propagation.
+
+
+
+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 Fly.io cloud router.
diff --git a/docs/source/routing/cloud/configuration.mdx b/docs/source/routing/cloud/configuration.mdx
new file mode 100644
index 0000000000..010ff55b34
--- /dev/null
+++ b/docs/source/routing/cloud/configuration.mdx
@@ -0,0 +1,373 @@
+---
+title: Cloud Router Configuration
+subtitle: Learn how to configure cloud routers in GraphOS Studio
+description: Learn about cloud router configurations including HTTP header rules, CORSs settings, secret management, and more in GraphOS Studio.
+redirectFrom:
+ - /graphos/cloud-routing/configuration
+---
+
+After you create a cloud supergraph, you can manage its router configuration from the **Cloud Router** page in [GraphOS Studio](https://studio.apollographql.com?referrer=docs-content).
+
+The **General** tab shows the following information:
+
+- The URL of your router's GraphQL endpoint
+ - Every cloud router's URL is on a subdomain of `apollographos.net`.
+- Your router's current status and [launch history](/graphos/platform/schema-management/delivery/launch)
+
+From the **Configuration** tab, you can manage the following:
+
+- [Secrets](#managing-secrets)
+- Your router's [YAML-based configuration](#router-configuration-yaml)
+
+
+
+## Managing secrets
+
+You can store secret string values that you can then use in your router's [YAML configuration](#router-configuration-yaml). For example, you might store an authorization token that the router needs to include in each of its request to a subgraph.
+
+To add a new secret, click **Save a secret**.
+
+In the dialog that appears, enter a name and value for your secret. You can't view a secret's value after you save it, so make sure that the value is correct before saving. When you're ready, click **Save secret**.
+
+Your secret is encrypted and stored. You can then use the secret's value in your router's YAML configuration.
+
+The following example YAML configuration uses the value of a secret named `MY_SECRET`:
+
+```yaml
+headers:
+ all:
+ request:
+ - insert:
+ name: 'subgraph-token'
+ value: '${env.MY_SECRET}' # highlight-line
+```
+
+## Router configuration YAML
+
+You can configure your router's behavior in **Router configuration YAML** on the **Cloud Router** tab or page.
+
+On the [Serverless plan](https://www.apollographql.com/pricing/), you can configure:
+
+- [HTTP headers](#http-header-rules) that the router sends to your subgraphs
+- [CORS rules](#cors-settings) for browser-based applications connecting to the router
+- [Subgraph error inclusion](#subgraph-error-inclusion) to expose subgraph errors to querying clients (including the Apollo Explorer)
+
+* [Introspection](#introspection) to allow resolving introspection queries.
+
+[Dedicated and Enterprise plans](https://www.apollographql.com/pricing/) offer a [wider variety of configurations](/graphos/routing/configure-your-router#yaml-file-based-configuration).
+
+If you require more advanced router customization, ❌
+ +```yaml title="bad_configuration.yaml" +headers: + all: + request: + - remove: + named: 'test' + - propagate: + matching: .* +``` + +In this example, first any header named `test` is removed from the list of headers to propagate. However, the list of headers to propagate is currently empty! Next, the `propagate` rule adds all headers to the propagation list, including `test`. + +To correctly remove a header from the propagation list, make sure to define your `remove` rule after any `propagate` rules: + +✅
+ +```yaml title="good_configuration.yaml" +headers: + all: + request: + - propagate: + matching: .* + - remove: + named: 'test' +``` + +With this ordering, first all headers are added to the propagation list, then the `test` header is removed. + +#### Example + +Here's a complete example that demonstrates all supported `headers` configuration options: + +```yaml +headers: + # Header rules for all subgraphs + all: + request: + # Propagate matching headers + - propagate: + matching: ^upstream-header-.* + # Propagate matching headers + - propagate: + named: 'some-header' + default: 'default-value' + rename: 'destination-header' + # Remove the "x-legacy-account-id" header + - remove: + named: 'x-legacy-account-id' + # Remove matching headers + - remove: + matching: ^x-deprecated-.* + # Insert the 'my-company' header + - insert: + name: 'my-company' + value: 'acme' + # Subgraph-specific header rules + subgraphs: + products: + request: + # Calls to the products subgraph have the "router-subgraph-name" header set to `products`. + - insert: + name: 'router-subgraph-name' + value: 'products' + accounts: + request: + # Calls to the accounts subgraph have the "router-subgraph-name" header set to `accounts`. + - insert: + name: 'router-subgraph-name' + value: 'accounts' +``` + +### CORS settings + +
+
+
+
+## Step 2. Connect APIs
+
+1. Next, connect your GraphQL API to Apollo.
+
+ - If your API URL is publicly accessible, enter the API URL. This URL is the URL that client applications currently use to query your API.
+ - If your API isn't publicly accessible and requires private networking, you can connect to it with [AWS VPC Lattice](/graphos/routing/cloud/lattice-configuration). Select **My endpoint isn't publicly accessible** to connect a VPC. Follow the prompts to complete private subgraph setup.
+
+2. Enter a **Subgraph name**. The name should reflect your API's data or capabilities and uniquely identify your API among any other APIs you might add to the supergraph later.
+
+ 
+
+Every router configuration or supergraph schema change—including adding a subgraph—triggers a new [launch](/graphos/delivery/launches/). Every launch automatically deploys new cloud router instances for your supergraph.
+
+
+
+## Step 4. Test and validate
+
+To test whether your graph works as intended, run a sample query by clicking **Run in Explorer** from your graph's **README** page.
+
+[Enable subgraph error reporting](/graphos/routing/cloud/lattice-troubleshooting/#enable-subgraph-error-inclusion) if you run into issues.
+
+For further testing, you can add variants to your graph for development or staging environments. To do so, go to **Settings** > **This Graph** > **Variants** and click **Add a variant**.
+
+Apollo recommends running a [load test](/graphos/routing/cloud/throughput-guide#load-testing) to determine how much [throughput capacity](/graphos/routing/cloud/throughput-guide) you need to run your graph.
+
+## Step 5. Go live
+
+Your supergraph is ready to start receiving client operations! If you have existing client applications that connect directly to your GraphQL API, you can update their GraphQL endpoint URL to your router's URL.
+
+Similarly, any new client applications should use your router's URL.
+
+
+
+
+
+
+## Cloud router status
+
+Cloud routers can have the following statuses:
+
+| Status | Description |
+| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Initializing** | Your cloud router is being created. This process may take up to five minutes. [Learn more.](#initializing) |
+| **Running** | Your graph is operating normally. |
+| **Error** | Your cloud router is running, but a deployment recently failed. For more information on the failure, see the **Launches** page in GraphOS Studio. |
+
+
+
+Once initialized, you can [configure your cloud router](/graphos/routing/cloud/configuration).
+
+## Cloud launches
+
+Publishing a new subgraph schema or editing a cloud router's config triggers a new [launch](/graphos/delivery/launches/). Every launch automatically deploys new router instances for your graph. You can see a launch's details, including possible failures, from a graph's **Launches** page in GraphOS Studio.
+
+router"]); + end; + subgraph "Amazon Virtual Private Cloud" + lattice[Amazon VPC
Lattice service] + service1[Subgraph 1]; + service2[Subgraph 2]; + service3[Subgraph 3]; + end; + + router --> lattice + lattice --> service1 & service2 & service3; + + clients -->|Requests| router; +``` + +This guide shows how to create Lattice services and share them with GraphOS. This configuration lets your GraphOS cloud routers securely communicate with your private subgraphs. + +
+
+5. (Optional) If you use a target type with health checks, ensure you configure your health checks. Otherwise, Lattice can't send traffic to your subgraphs.
+6. Register the targets based on your chosen target type. For example, if you selected **IP addresses** as your target type, add each IP address.
+
+ 
+
+7. Review your targets to make sure all information is correct.
+8. Click **Create target group** at the bottom right corner of the page.
+
+Congratulations! You've created an Amazon VPC Lattice target group.
+Repeat this process for each subgraph you want to share with GraphOS.
+
+## Step 2. Create a Lattice service
+
+In Lattice, a _service_ represents a self-contained software module.
+A VPC Lattice service has a listener that uses rules, called listener rules, that you can configure to help route traffic to your targets.
+In this step, you create a single VPC Lattice service with listener rules for each of your target groups.
+
+In the GraphOS context, a Lattice service maps to a graph variant.
+Create one service for each of your variants.
+
+1. In the AWS Console for your region, go to the VPC service page:
+
+- [US East (N. Virginia) - us-east-1](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1)
+- [Europe (Ireland) - eu-west-1](https://eu-west-1.console.aws.amazon.com/vpc/home?region=eu-west-1)
+
+2. In the left navigation, scroll down and open **VPC Lattice > Services**.
+3. Click **Create service** in the top right.
+4. In the **Identifiers** section, enter a descriptive name for the service. Optionally, enter a description and tags.
+
+ 
+
+5. In the **Custom domain configuration** section, leave **Specify a custom domain configuration** unchecked.
+6. In the **Service access** section, select the **AWS IAM** authentication type and paste the following authorization policy. This policy ensures that only the Apollo AWS Organization can send traffic to your subgraphs.
+
+ ```json showLineNumbers=false
+ {
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Effect": "Allow",
+ "Principal": "*",
+ "Action": "vpc-lattice-svcs:Invoke",
+ "Resource": "*",
+ "Condition": {
+ "ForAnyValue:StringLike": {
+ "aws:PrincipalOrgPaths": "o-9vaxczew6u/*/ou-leyb-l9pccq2t/ou-leyb-fvqz35yo/*"
+ }
+ }
+ }
+ ]
+ }
+ ```
+
+7. (Optional) For extra security, you can audit all the traffic coming to your subgraph by enabling **Access logs** in the **Monitoring** section.
+8. Once you've configured the service, click **Next** on the bottom right of the page.
+9. Define routing information to the target group you created in [Step 1](#step-1-create-lattice-target-group). Set the protocol to **HTTPS** and the port to **443**.
+
+ 
+
+10. If you have multiple target groups, add a **Listener rule** for each target group.
+
+ 
+
+11. Click **Next** at the bottom right of the page once you've configured your listener.
+12. Don't select a VPC Lattice service network. Your subgraphs will integrate with a service network managed by Apollo. Instead, click the **Next** button at the bottom right of the page.
+13. Ensure the information you've entered is correct. Then click **Create VPC Lattice service** at the bottom right of the page.
+
+Congratulations! You've now created a Lattice service with listeners for your subgraphs.
+
+## Step 3. Share Lattice service
+
+For GraphOS to access your Lattice service, you must share it with the Apollo AWS organization.
+You do this through a _resource share_ in AWS Resource Access Manager (AWS RAM).
+A resource share specifies the resources to share and the consumers with whom to share them.
+
+```mermaid
+flowchart LR;
+ apollo(Apollo Cloud)
+ subgraph "Amazon Virtual Private Cloud"
+ lattice[Amazon VPC Lattice service] + service1[Subgraph 1]; + service2[Subgraph 2]; + service3[Subgraph 3]; + end; + + apollo-. AWS RAM
resource share .- lattice + lattice --> service1 & service2 & service3; +``` + +If you have multiple Lattice services, you can share them all through one resource share. + +1. In the AWS Console for your region of choice, go to the Resource Access Manager service page: + +- [US East (N. Virginia) - us-east-1](https://us-east-1.console.aws.amazon.com/ram/home?region=us-east-1) +- [Europe (Ireland) - eu-west-1](https://eu-west-1.console.aws.amazon.com/ram/home?region=eu-west-1) + +2. In the left navigation, scroll down and open **Shared by me > Resource shares**. +3. Click **Create resource share** in the top right corner. +4. In the **Resource share name** section, enter a name for your resource share. +5. In the **Resources section**, select the **VPC Lattice Services** resource type. +6. Select all the Lattice services that contain subgraphs. + +
+
+7. (Optional) Set tags for your resource share.
+8. Click the **Next** button at the bottom right corner of the page.
+9. Verify that the **Managed permissions** give access to associate the Lattice services with a service network (`vpc-lattice:CreateServiceNetworkServiceAssociation` and `vpc-lattice:GetService`). Then click the **Next** button at the bottom right of the page.
+
+ 
+
+10. In the **Principals** section, select **Allow sharing with anyone** with a **principal type** of `AWS account`. Enter the following value for the account ID: `282421723282`, then click the **Add** button.
+
+ 
+
+11. Confirm that `282421723282` is the only selected principal for this resource share, then click the **Next** button on the bottom right corner.
+12. Confirm that all the information is correct, then click **Create resource share** at the bottom right of the page.
+
+Congratulations! You've now shared your Lattice service(s) with Apollo's AWS organization.
+
+The last step is associating your resource share with a graph in GraphOS.
+
+router"]); + end; + subgraph "Amazon Virtual Private Cloud" + lattice[Amazon VPC
Lattice service] + service1[Subgraph 1]; + service2[Subgraph 2]; + service3[Subgraph 3]; + end; + + router --> lattice + lattice --> service1 & service2 & service3; + + clients -->|Requests| router; +``` + +1. In the AWS Console for your region of choice, go to the Resource Access Manager service page: + +- [US East (N. Virginia) - us-east-1](https://us-east-1.console.aws.amazon.com/ram/home?region=us-east-1) +- [Europe (Ireland) - eu-west-1](https://eu-west-1.console.aws.amazon.com/ram/home?region=eu-west-1) + +2. In the left navigation, scroll down and open **Shared by me > Resource shares**. +3. Click the resource share you created in the previous step. +4. Copy the **ARN** for the resource share. + +
+
+The next steps differ depending on whether you're creating a [new graph](#setup-for-new-graphs) in GraphOS or adding this [service to an existing graph](#setup-for-existing-graphs).
+
+### Setup for new graphs
+
+1. Go to [GraphOS Studio](https://studio.apollographql.com?referrer=docs-content).
+2. Click the **Create New Graph** tab at the top right of the screen.
+3. Follow Studio's onboarding steps to create a graph with a new private subgraph.
+4. When prompted to **Provide your GraphQL API endpoint**, select **My endpoint is not directly accessible** at the bottom of the page.
+5. Choose the backend provider you want to use for your private subgraph and the region where your subgraph should be provisioned.
+
+ 
+
+Use the **Metrics** tab to get a quick overview of traffic flowing to your private subgraphs.
+
+
+
+You can also use [Amazon CloudWatch metrics emitted by Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-cloudwatch.html) to set up dashboards and alarms to understand the health of your private subgraphs.
+
+## Further restrict access
+
+Once you configure an Amazon VPC Lattice service to accept traffic from GraphOS, it's protected by multiple security layers:
+
+- The Amazon VPC Lattice service network only allows traffic with a valid signature over HTTPS.
+- The Lattice service's configured authorization policy allows traffic only from Apollo AWS accounts. (This is the authorization policy you configured in step 6 [when creating your Lattice service](/graphos/routing/cloud/lattice-configuration#step-2-create-a-lattice-service).)
+- GraphOS cloud router provisioning compares subgraphs in a supergraph's configuration against the list of known private subgraphs in its Apollo account. It refuses to create or update cloud routers with unknown private subgraphs.
+- Cloud routers can only invoke private subgraphs listed in their supergraph configuration.
+
+You can further restrict access to your private subgraphs by configuring additional [conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in your service's authorization policy.
+Specifically, you can add conditions to restrict traffic based on your organization's Apollo account ID or your supergraph's graph ref.
+
+### Update Lattice service authorization policy
+
+To update a Lattice service's authorization policy, you first need the **Apollo account ID** and/or **graph ref** to which you want to restrict subgraph access.
+
+#### Get account ID and graph ref
+
+- Reach out to your Apollo contact to get your account ID. Specify that you need the account ID to update your Lattice service's authorization policy.
+
+ 
+
+5. Click the **Actions** button in the top right of that section. Then, click **Delete network associations**.
+
+
+
+6. Follow the confirmation instructions and click **Delete**.
+
+Deleting the network association can take a few seconds. Once you delete the network association, GraphOS can no longer contact your subgraphs.
diff --git a/docs/source/routing/cloud/lattice-troubleshooting.mdx b/docs/source/routing/cloud/lattice-troubleshooting.mdx
new file mode 100644
index 0000000000..89f8127c5d
--- /dev/null
+++ b/docs/source/routing/cloud/lattice-troubleshooting.mdx
@@ -0,0 +1,135 @@
+---
+title: Lattice Troubleshooting Guide
+subtitle: Troubleshoot common issues and errors with Amazon VPC Lattice
+description: Troubleshoot common issues and errors with Amazon VPC Lattice and an Apollo Cloud Dedicated router
+redirectFrom:
+ - /graphos/cloud-routing/lattice-troubleshooting
+---
+
+
+
+5. Check that you have a listener with a `protocol:port` configuration of **HTTPS:443**.
+
+If not, you must create a new listener by clicking on the **Add listener** button at the top left of this section.
+Refer to step 10 of [Create a Lattice service](/graphos/routing/cloud/lattice-configuration#step-2-create-a-lattice-service) for more details.
+
+### HTTP fetch failed from '\_subgraph\_': 403: Forbidden
+
+This error likely occurs for one of the following reasons:
+
+- One of your clients is sending a subscription request to a private subgraph over WebSockets.
+- The VPC Lattice IAM policy doesn't allow traffic from Apollo GraphOS Cloud.
+
+#### Subscriptions over WebSockets
+
+Subscriptions over WebSockets aren't supported in AWS VPC Lattice, as the platform currently [lacks WebSocket support](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listeners.html#listener-configuration). When sending a request to upgrade to a WebSockets connection, Lattice returns a blank response with a 403 response code. In this situation, Lattice also doesn't emit access log entries to Amazon CloudWatch Logs. [Contact your AWS account team](https://aws.amazon.com/contact-us/sales-support/) to notify them of your interest in this feature.
+
+#### VPC Lattice IAM policy
+
+You can check that a Lattice service is configured to allow traffic from Apollo GraphOS Cloud on the service's **Access** page:
+
+1. In the AWS Console for your region of choice, go to the VPC service page.
+2. In the left navigation, scroll down and open **VPC Lattice > Services**.
+3. Click the Lattice service used by the subgraph in question.
+4. Click the **Access** tab.
+5. Ensure that the Auth type is set to **IAM** and that the policy looks like this:
+
+```json
+{
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Effect": "Allow",
+ "Principal": "*",
+ "Action": "vpc-lattice-svcs:Invoke",
+ "Resource": "*",
+ "Condition": {
+ "ForAnyValue:StringLike": {
+ "aws:PrincipalOrgPaths": "o-9vaxczew6u/*/ou-leyb-l9pccq2t/ou-leyb-fvqz35yo/*"
+ }
+ }
+ }
+ ]
+}
+```
diff --git a/docs/source/routing/cloud/migrate-to-dedicated.mdx b/docs/source/routing/cloud/migrate-to-dedicated.mdx
new file mode 100644
index 0000000000..96a5bddb01
--- /dev/null
+++ b/docs/source/routing/cloud/migrate-to-dedicated.mdx
@@ -0,0 +1,54 @@
+---
+title: Migrate to Dedicated
+subtitle: Learn what to consider when migrating to a Dedicated cloud router
+description: Migrate your self-hosted GraphQL APIs to a federated cloud supergraph with a pre-provisioned router on dedicated infrastructure.
+---
+
+
+
+2. Scroll down to the **Request Rate** chart. This chart shows the request rate in requests per minute (RPM).
+3. To calculate your required requests per second (RPS), find the peak RPM and divide it by 60.
+4. Since, as [a baseline](#performance-expectations), 1 GCU can serve 25 RPS, divide your peak RPS by 25 to calculate your required GCUs.
+
+
+
+- In the example above, the peak is **19,000 RPM**.
+- `19,000 / 60 = 317`, so the graph has a peak of **317 RPS**.
+- `317 / 25 = 13`, so this workload requires at least **13 GCUs** to operate.
+
+
+
+Then, select the number of GCUs required and click **Save changes**.
+
+### Edit GCUs via API
+
+You can change a graph variant's GCUs with the following mutation from the [GraphOS Platform API](/graphos/reference/platform-api/).
+
+```graphql
+mutation Graph($graphId: ID!, $name: String!, $gcus: Int!) {
+ graph(id: $graphId) {
+ variant(name: $name) {
+ router {
+ setGcus(gcus: $gcus) {
+ ... on RouterGcusSuccess {
+ order {
+ id
+ }
+ }
+ }
+ }
+ }
+ }
+}
+```
+
+This mutation requires setting the following variables:
+
+- `graphId`: a graph's ID is the first part of the graph's graph ref
+ - You can a graph's ID in GraphOS Studio under **Settings** > **This Graph**
+- `name`: the variant name
+ - If you haven't set a variant name, the default is `current`
+- `gcus`: the number of GCUs to provision for the variant
diff --git a/docs/source/routing/configure-your-router.mdx b/docs/source/routing/configure-your-router.mdx
new file mode 100644
index 0000000000..c5c835b946
--- /dev/null
+++ b/docs/source/routing/configure-your-router.mdx
@@ -0,0 +1,103 @@
+---
+title: Configuring a Router
+subtitle: Learn to configure cloud-hosted and self-hosted routers
+description: Learn how to configure the Apollo GraphOS Router with environment variables, command-line options and commands, and YAML configuration files.
+redirectFrom:
+ - /router/configuration/overview/
+---
+
+You can configure a router in multiple ways. Because cloud-hosted and self-hosted routers share the common foundation of Apollo Router Core, all routers support declarative configuration with a YAML file, usually named `router.yaml`. Differences between configuring cloud-hosted and self-hosted routers:
+
+- A cloud-hosted router is managed by Apollo and fully integrated with GraphOS, so its configuration is provided via the GraphOS Studio IDE.
+- A self-hosted router is launched via command line, so its configuration includes command-line options and environment variables.
+
+| | Cloud-Hosted Router | Self-Hosted Router |
+| --- | :---: | :---: |
+| Studio IDE | ✅ | ❌ |
+| YAML file | ✅ | ✅ |
+| Command-line options | ❌ | ✅ |
+| Environment variables | ❌ | ✅ |
+
+
+## YAML file-based configuration
+
+Both cloud-hosted and self-hosted routers support YAML file-based configuration. You can edit a YAML file named `router.yaml` to declaratively configure your router.
+
+- For cloud-hosted routers, use GraphOS Studio to edit `router.yaml`.
+- For self-hosted routers, edit a local `router.yaml` and run your router with the `--config` flag:
+
+ ```bash
+ ./router --config router.yaml
+ ```
+
+
-Because field-level instrumentation is dependent on general-purpose [OpenTelemetry tracing](./exporters/tracing/overview), the value of `telemetry.apollo.field_level_instrumentation_sampler` cannot exceed the value of `telemetry.exporters.tracing.common.sampler`.
+Because field-level instrumentation is dependent on general-purpose [OpenTelemetry tracing](/router/configuration/telemetry/exporters/tracing/overview), the value of `telemetry.apollo.field_level_instrumentation_sampler` cannot exceed the value of `telemetry.exporters.tracing.common.sampler`.
+```sh
+curl --request POST \
+ --header 'content-type: application/json' \
+ --url 'http://127.0.0.1:4000/' \
+ --data '{"query":"query { __typename }"}'
+```
## GET requests
-The router also accepts GET requests for queries (but not mutations). With a GET request, query details (`query`, `operationName`, `variables`) are provided as URL query parameters. The `variables` option is a URL-escaped JSON object.
+The Apollo Router also accepts GET requests for queries (but not mutations). With a GET request, query details (`query`, `operationName`, `variables`) are provided as URL query parameters. The `variables` option is a URL-escaped JSON object.
Here's the same query from [POST requests](#post-requests) formatted for a `curl` GET request:
@@ -60,8 +67,7 @@ curl --request GET \
## Persisted queries protocol
-The Automatic Persisted Queries (APQ) feature available for Apollo Router Core and the Persisted Query List (PQL) feature available for GraphOS Router use a separate protocol to send the operation document information in the `extensions`. This protocol can also use HTTP POST or GET. See the Apollo Client docs on the [APQ protocol](/react/api/link/persisted-queries/#protocol) for details.
-
+The Automatic Persisted Queries (APQ) and Persisted Query List (PQL) features of the Apollo Router use a separate protocol to send the operation document information in the `extensions`. This protocol can also use HTTP POST or GET. See the Apollo Client docs on the [APQ protocol](/react/api/link/persisted-queries/#protocol) for details.
## Related topics
diff --git a/docs/source/configuration/header-propagation.mdx b/docs/source/routing/header-propagation.mdx
similarity index 97%
rename from docs/source/configuration/header-propagation.mdx
rename to docs/source/routing/header-propagation.mdx
index 686f269552..5d2fae3323 100644
--- a/docs/source/configuration/header-propagation.mdx
+++ b/docs/source/routing/header-propagation.mdx
@@ -6,7 +6,7 @@ description: Configure which HTTP headers the Apollo GraphOS Router or Apollo Ro
You can configure which HTTP headers the GraphOS Router or Apollo Route Core includes in its requests to each of your subgraphs. You can define per-subgraph header rules, along with rules that apply to _all_ subgraphs.
-You define header rules in your [YAML configuration file](./overview/#yaml-config-file), like so:
+You define header rules in your [YAML configuration file](/router/configuration/overview/#yaml-config-file), like so:
```yaml title="router.yaml"
# ...other configuration...
@@ -214,7 +214,7 @@ headers:
## Response header propagation
-It is not currently possible to propagate response headers from subgraphs to clients using YAML configuration alone. However, you _can_ achieve this using [Rhai scripting](../customizations/rhai).
+It is not currently possible to propagate response headers from subgraphs to clients using YAML configuration alone. However, you _can_ achieve this using [Rhai scripting](/graphos/routing/customization/rhai).
This approach relies on the fact that each request has a `context` object that can store data for the duration of that request:
@@ -264,7 +264,7 @@ If you require a configuration-based solution for response header propagation, [
## Propagation between subgraphs
-It is not currently possible to propagate headers between subgraphs using YAML config alone. However, you _can_ achieve this using [Rhai scripting](../customizations/rhai).
+It is not currently possible to propagate headers between subgraphs using YAML config alone. However, you _can_ achieve this using [Rhai scripting](/graphos/routing/customization/rhai).
This approach relies on the fact that each request has a `context` object that can store data for the duration of that request:
diff --git a/docs/source/managed-federation/client-awareness.mdx b/docs/source/routing/observability/client-awareness.mdx
similarity index 96%
rename from docs/source/managed-federation/client-awareness.mdx
rename to docs/source/routing/observability/client-awareness.mdx
index d27cb1aca5..f7660f85a8 100644
--- a/docs/source/managed-federation/client-awareness.mdx
+++ b/docs/source/routing/observability/client-awareness.mdx
@@ -10,7 +10,7 @@ The GraphOS Router and Apollo Router Core support [client awareness](/graphos/me
## Overriding client awareness headers
-Different header names can be used by updating the configuration file. If those headers will be sent by a browser, they must be allowed in the [CORS (Cross Origin Resource Sharing) configuration](../configuration/cors), as follows:
+Different header names can be used by updating the configuration file. If those headers will be sent by a browser, they must be allowed in the [CORS (Cross Origin Resource Sharing) configuration](/router/configuration/cors), as follows:
```yaml title="router.yaml"
telemetry:
diff --git a/docs/source/routing/observability/client-id-enforcement.mdx b/docs/source/routing/observability/client-id-enforcement.mdx
new file mode 100644
index 0000000000..da882d2ba7
--- /dev/null
+++ b/docs/source/routing/observability/client-id-enforcement.mdx
@@ -0,0 +1,143 @@
+---
+title: Client ID Enforcement
+subtitle: Require client details and operation names to help monitor schema usage
+description: Improve GraphQL operation monitoring by tagging operations with with client details. See code examples for Apollo GraphOS Router and Apollo Server.
+published: 2022-05-31
+id: TN0001
+tags: [server, observability, router]
+redirectFrom:
+ - /technotes/TN0001-client-id-enforcement/
+---
+
+As part of GraphOS Studio metrics reporting, servers can [tag reported operations with the requesting client's name and version](/graphos/metrics/client-awareness). This helps graph maintainers understand which clients are using which fields in the schema.
+
+Clients can (and should) also [name their GraphQL operations](/react/data/operation-best-practices/#name-all-operations), which provides more context around how and where data is being used.
+
+Together, these pieces of information help teams monitor their graph and make changes to it safely. We strongly encourage that your GraphQL gateway require client details and operation names from all requesting clients.
+
+## Enforcing in GraphOS Router
+
+The GraphOS Router supports client awareness by default if the client sets the `apollographql-client-name` and `apollographql-client-id` in their requests. These values can be overridden using the [router configuration file](/router/managed-federation/client-awareness/) directly.
+
+Client headers can also be enforced using a [Rhai script](/graphos/routing/customization/rhai) on every incoming request.
+
+```rhai title="client-id.rhai"
+fn supergraph_service(service) {
+ const request_callback = Fn("process_request");
+ service.map_request(request_callback);
+ }
+
+fn process_request(request) {
+ log_info("processing request");
+ let valid_clients = ["1", "2"];
+ let valid_client_names = ["apollo-client"];
+
+ if ("apollographql-client-version" in request.headers && "apollographql-client-name" in request.headers) {
+ let client_header = request.headers["apollographql-client-version"];
+ let name_header = request.headers["apollographql-client-name"];
+
+ if !valid_clients.contains(client_header) {
+ log_error("Invalid client ID provided");
+ throw #{
+ status: 401,
+ message: "Invalid client ID provided"
+ };
+ }
+ if !valid_client_names.contains(name_header) {
+ log_error("Invalid client name provided");
+ throw #{
+ status: 401,
+ message: "Invalid client name provided"
+ };
+ }
+ }
+ else {
+ log_error("No client headers set");
+ throw #{
+ status: 401,
+ message: "No client headers set"
+ };
+ }
+}
+```
+
++
+ +- Connecting a self-hosted router to GraphOS +- Forwarding metrics to Datadog + +
+ +Reporting metrics from [Apollo Server](/apollo-server) or a [monograph](/graphos/get-started/concepts/graphs/#monographs) requires an [Enterprise or legacy Team plan](https://www.apollographql.com/pricing). + +If your organization doesn't currently have an Enterprise plan, you can test out this functionality by signing up for a free [GraphOS trial](https://studio.apollographql.com/signup?referrer=docs-content). + +
request"| router; ``` - - If every field in a particular subquery requires authorization, the router's [query planner](../customizations/overview#request-path) can _eliminate entire subgraph requests_ for unauthorized requests. For example, a request may have permission to view a particular user's posts on a social media platform but not have permission to view any of that user's personally identifiable information (PII). Check out [How it works](#how-it-works) to learn more. + - If every field in a particular subquery requires authorization, the router's [query planner](/router/customizations/overview#request-path) can _eliminate entire subgraph requests_ for unauthorized requests. For example, a request may have permission to view a particular user's posts on a social media platform but not have permission to view any of that user's personally identifiable information (PII). Check out [How it works](#how-it-works) to learn more. ```mermaid flowchart LR; @@ -38,7 +38,7 @@ Services may have their own access controls, but enforcing authorization _in the router -.->|"❌ Unauthorized
subquery"| serviceB; clients -->|"⚠️ Partially authorized
request"| router; ``` - - Also, [query deduplication](./traffic-shaping/#query-deduplication) groups requested fields based on their required authorization. Entire groups can be eliminated from the query plan if they don't have the correct authorization. + - Also, [query deduplication](/router/configuration/traffic-shaping/#query-deduplication) groups requested fields based on their required authorization. Entire groups can be eliminated from the query plan if they don't have the correct authorization. - **Declarative access rules**: You define access controls at the field level, and GraphOS [composes](#composition-and-federation) them across your services. These rules create graph-native governance without the need for an extra orchestration layer. @@ -80,7 +80,7 @@ The GraphOS Router provides access controls via **authorization directives** tha - The [`@requiresScopes`](#requiresscopes) directive allows granular access control through the scopes you define. - The [`@authenticated`](#authenticated) directive allows access to the annotated field or type for _authenticated requests only_. -- The [`@policy`](#policy) directive offloads authorization validation to a [Rhai script](../customizations/rhai/) or a [coprocessor](../customizations/coprocessor) and integrates the result in the router. It's useful when your authorization policies go beyond simple authentication and scopes. +- The [`@policy`](#policy) directive offloads authorization validation to a [Rhai script](/graphos/routing/customization/rhai/) or a [coprocessor](/router/customizations/coprocessor) and integrates the result in the router. It's useful when your authorization policies go beyond simple authentication and scopes. For example, imagine you're building a social media platform that includes a `Users` subgraph. You can use the [`@requiresScopes`](#requiresscopes) directive to declare that viewing other users' information requires the `read:user` scope: @@ -106,12 +106,12 @@ The router then enforces these directives on all incoming requests.
@@ -436,6 +430,6 @@ You can also chart the percentage of operations that would be allowed or rejecte
diff --git a/docs/source/routing/security/index.mdx b/docs/source/routing/security/index.mdx
new file mode 100644
index 0000000000..e69edf4ff5
--- /dev/null
+++ b/docs/source/routing/security/index.mdx
@@ -0,0 +1,21 @@
+---
+title: Supergraph Security with GraphOS Router
+subtitle: Protect your supergraph at its entry point, the router
+---
+
+As the public endpoint of a federated GraphQL API, a GraphOS Router has the responsibility for protecting its downstream subgraphs from malicious clients and their requests.
+
+Its security features contribute to a defense-in-depth approach, where different authentication and authorization measures are applied in various places, from clients to the router itself to subgraphs. The supergraph can also be secured by having the router accept GraphQL operations from validated safelists of operations.
+
+The features covered in this section include:
+
+- [**Authorization**](/graphos/routing/security/authorization) - define authorized access to GraphQL fields and types by annotating schemas with authorization primitives
+- [**Persisted Queries**](/graphos/routing/security/persisted-queries) - configure the router to allow clients to register and persist cached lists of safe GraphQL queries and operations
+- [**Best Practices**](/graphos/platform/security/overview) - best practices for securing supergraphs
+- [**CORS**](/graphos/routing/security/cors) - control router access from browser-based clients
+- [**CSRF Prevention**](/graphos/routing/security/csrf) - configure cross-site request forgery (CSRF) prevention in the router
+- [**Request Limits**](/graphos/routing/security/request-limits) - protect your router from requests exceeding network, parser, and operation-based limits
+- [**Demand Control**](/graphos/routing/security/demand-control) - protect your graph from high-cost GraphQL operations
+- [**JWT Authentication**](/graphos/routing/security/jwt) - restrict access to credentialed users and systems with JSON Web Tokens (JWT)
+- [**Router Authentication**](/graphos/routing/security/router-authentication) - authorization and authentication strategies to secure your graph
+- [**Subgraph Authentication**](/graphos/routing/security/subgraph-authentication) - implement subgraph authentication by using AWS SigV4
\ No newline at end of file
diff --git a/docs/source/configuration/authn-jwt.mdx b/docs/source/routing/security/jwt.mdx
similarity index 88%
rename from docs/source/configuration/authn-jwt.mdx
rename to docs/source/routing/security/jwt.mdx
index bb16070e10..4083721245 100644
--- a/docs/source/configuration/authn-jwt.mdx
+++ b/docs/source/routing/security/jwt.mdx
@@ -4,17 +4,11 @@ subtitle: Restrict access to credentialed users and systems
description: Protect sensitive data by enabling JWT authentication in the Apollo GraphOS Router. Restrict access to credentialed users and systems.
---
-API]; + serviceC[Reviews
API]; + router -->|Sub-query| serviceB & serviceC; + end; + clients -.->|Query| router; + class clients secondary; +``` + +