Bring your own endpoint
Bedrock & Vertex
Not served today. This page says exactly what exists and what does not.
AWS Bedrock and Google Vertex are the two most-asked-for lanes that Conifer does not serve yet. Rather than leave you to discover that from a 404, here is the real state.
Why they are harder than a key
Every provider Conifer serves today authenticates with a fixed value: a bearer token or an API-key header, resolved once at startup and reused. Bedrock and Vertex do not work that way.
| Platform | What its credential actually is |
|---|---|
| AWS Bedrock | A SigV4 signature computed over this request's method, path, query, headers, and body. It cannot be pre-computed or reused across requests. |
| Google Vertex | A short-lived OAuth token from the metadata server or a service-account JWT exchange. It expires and must be re-fetched and cached. |
| Azure OpenAI | A static api-key header — which is why Azure is the one that ships. Entra ID tokens have the same expiry problem as Vertex. |
What exists
The signing and token-acquisition work is written and tested as its own unit: SigV4 request signing, the Google metadata and service-account JWT flows, and the Entra client-credentials and managed-identity flows. What is missing is not the cryptography but the served lane — catalog entries, pricing rows, and the account-level credential storage that would let you paste the credential in the console the way you can for Azure.
What to do today
If your inference has to run inside your own AWS or GCP account for compliance reasons, that is a real constraint and Conifer does not meet it yet. If the reason is committed spend, note that Conifer adds no markup of its own, so the arbitrage is usually smaller than it looks. For an Azure resource, the lane is open now: Azure OpenAI.
This page is the tracking surface. If Bedrock or Vertex is blocking you, say so on the SDK issue tracker — demand recorded there is what moves a lane up the list.