For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Authenticate to AWS, Azure, or Google Cloud with the gateway’s own identity.

Some backends do not accept a credential that you can hold. A managed cloud service issues its own short-lived tokens, and it expects the caller to prove an identity that the cloud itself recognizes. The AWS, Azure, and Google Cloud methods cover that case: the gateway authenticates as itself and exchanges its own identity for a token that the service accepts. The GitHub Copilot method works differently, because the gateway sends an existing Copilot token instead of exchanging an identity.

When to use a provider method

Use a provider method when the backend is an AWS, Azure, or Google Cloud service, or the GitHub Copilot API. Use a static key instead when the service issues you a long-lived API key, even if that service happens to run on one of those clouds.

For AWS, Azure, and Google Cloud, workload identity lets the gateway authenticate without storing a credential. On a managed cluster the platform already gives the gateway an identity: a Google service account through Workload Identity on GKE, an IAM role for a service account on EKS, or an Azure workload identity on AKS. Each of these providers also accepts an explicit credential when the ambient identity is not the one you want, or when the gateway does not run on that cloud.

What the gateway sends

Three of the four attach a bearer token to the request. AWS is the exception: it signs the whole request instead, so it runs last, after every other policy that changes the request.

The AWS, Azure, and Google Cloud methods resolve implicit credentials through a chain of sources, and stop at the first one that answers. The order matters whenever more than one source is present, so each page documents its own chain.

First request latency

The AWS, Azure, and Google Cloud methods resolve implicit credentials on the first request that needs them, not at startup. That first request therefore pays the cost of the exchange, and can take several seconds. The gateway caches the result, so later requests do not. A route that is slow only on its first call after a restart is showing this, not a misconfiguration.

Guides

The following guides cover AWS, Azure, and Google Cloud.