> ## Documentation Index > Fetch the complete documentation index at: /docs/llms.txt > Use this file to discover all available pages before exploring further. # Amazon Bedrock > Conecte o Amazon Bedrock ao AI Gateway do Toqan Router. Configure sua chave de acesso, segredo e região da AWS para encaminhar solicitações de modelos do Bedrock com observabilidade. Consulte [URLs e autenticação HTTP](/docs/pt-BR/reference/base-urls.md) e a referência da API para os formatos completos de solicitação e resposta. * **Name**: pode ser qualquer nome. Exemplo: `toqan_bedrock` * **Access key id**: obtenha no IAM da AWS. * **Secret access key**: também obtenha no IAM da AWS. * **Region**: certifique-se de selecionar a região correta. Exemplo: us-east-1 ## Obter chaves de acesso na AWS ## Políticas / permissões na AWS Para que o modelo funcione, certifique-se de que as duas permissões a seguir estejam incluídas na política anexada ao usuário na AWS. 1. Bedrock: InvokeModel 2. Bedrock: InvokeModelWithResponseStream ## Função do IAM O **AI Studio** disponibiliza o modo de autenticação **Pod Identity (On-Premise)** somente em implantações on-premise. Um modelo do Bedrock em uma implantação desse tipo pode se autenticar com uma função do IAM em vez de uma chave de acesso e um segredo, de modo que nenhuma credencial de longa duração da AWS fique armazenada com o modelo. Na barra lateral do **AI Gateway**, abra **Models**, selecione **Model** e escolha **AWS Bedrock**. Defina **Auth Mode** como **Pod Identity (On-Premise)**, o que envia `auth_mode: "pod-identity"` na API. As credenciais passam então a vir da cadeia de credenciais padrão da AWS da implantação: a função anexada ao gateway por meio do EKS Pod Identity ou do IAM Roles for Service Accounts (IRSA), ou o serviço de metadados da instância. ### Assumir uma função em outra conta Defina **Assume Role ARN** para que o **Toqan Router** assuma uma função em outra conta da AWS. O **External ID** opcional funciona como um segredo compartilhado que a política de confiança da função de destino exige antes de conceder acesso. | Campo | Obrigatório | Descrição | | - | - | - | | **Auth Mode** (`auth_mode`) | Sim | `pod-identity`. Usa a própria identidade da AWS da implantação em vez de uma integração da AWS armazenada. | | **Assume Role ARN** (`assume_role_arn`) | Não | ARN da função do IAM a ser assumida na conta de destino, como `arn:aws:iam::123456789012:role/bedrock-access-role`. | | **External ID** (`assume_role_external_id`) | Não | Enviado como o `ExternalId` da chamada `sts:AssumeRole`, sem nenhum valor adicionado pelo **Toqan Router**. A política de confiança da função de destino deve exigir o mesmo valor. Exibido assim que um Assume Role ARN é definido. | A função assumida precisa das permissões do Bedrock listadas acima. Sem um Assume Role ARN, as solicitações são assinadas com as credenciais que a implantação obtém do seu ambiente. ### Política de confiança na função de destino A política de confiança da função de destino deve permitir a identidade com a qual a implantação é executada, e essa identidade precisa da permissão `sts:AssumeRole` na função de destino. ```json JSON theme={"theme":{"light":"github-light","dark":"github-dark"}} { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::role/" }, "Action": "sts:AssumeRole" } ] } ``` Substitua `` e `` por essa identidade, que o comando `aws sts get-caller-identity` informa quando executado dentro da implantação. Quando um External ID estiver definido, adicione `"Condition": { "StringEquals": { "sts:ExternalId": "" } }` à declaração. *** ## Modelos personalizados via perfil de inferência Um modelo personalizado do Bedrock é adicionado pelo ARN do perfil de inferência. Os dois tipos de perfil são aceitos: | Tipo | ARN | | - | - | | Definido pelo sistema | `arn:aws:bedrock:::inference-profile/` | | Aplicação | `arn:aws:bedrock:::application-inference-profile/` | Um prefixo como `eu.` no id de um perfil definido pelo sistema é a geografia pela qual a AWS encaminha as solicitações. Um perfil de aplicação não tem prefixo. O perfil Claude Sonnet 4.5 da UE, com um id de conta de exemplo: ```text theme={"theme":{"light":"github-light","dark":"github-dark"}} arn:aws:bedrock:eu-west-3:123456789012:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0 ``` A validação pede à AWS que resolva o modelo por trás do ARN, então o usuário da AWS precisa de `bedrock:GetInferenceProfile` além das duas permissões de invocação acima. Sem essa permissão, um modelo de chat ainda é validado e informa seu tipo como chat; o desenvolvedor e os preços ficam vazios. Um perfil de embedding falha na validação. Um perfil entre regiões envia solicitações para as outras regiões da sua geografia. Permita também as ações de invocação nos modelos de base dessas regiões. ### Adicionar o perfil no console **1. Insira o perfil** Em **Models**, clique em Model e escolha **AWS Bedrock**. Defina **Auth Mode** como **AWS Integration**, selecione a integração da AWS e cole o **Inference Profile ARN**. A **Region** é preenchida a partir do ARN. **2. Valide a conexão** Clique em **Validate Connection**. O gateway resolve o modelo de base e preenche o tipo de modelo, o desenvolvedor, as capacidades e os preços que conhece para ele. **3. Nomeie o modelo** Defina o **Model slug** e um **Display name**. O slug completa o id do modelo aceito pelo gateway: `@aws/`. Consulte [Referenciar modelos privados no código](/docs/pt-BR/ai-gateway/using-the-router.md#referencing-private-models-in-code). ### Adicionar o perfil pela API `model_id` é o slug, e o ARN vai em `configuration.model_id`: ```bash cURL theme={"theme":{"light":"github-light","dark":"github-dark"}} curl --request POST \ --url https://router.toqan.ai/eu/v2/models/aws-bedrock \ --header "Authorization: Bearer $TOQAN_API_KEY" \ --header "Content-Type: application/json" \ --data '{ "display_name": "Claude Sonnet 4.5 EU", "model_id": "claude-sonnet-4-5-eu", "configuration": { "model_id": "arn:aws:bedrock:eu-west-3:123456789012:inference-profile/eu.anthropic.claude-sonnet-4-5-20250929-v1:0" }, "region": "eu-west-3", "model_developer": "anthropic", "auth_mode": "integration", "integration_id": "" }' ``` O modelo pode então ser chamado como `@aws/claude-sonnet-4-5-eu`. Referência dos campos: [Criar um modelo personalizado do AWS Bedrock](/docs/pt-BR/reference/models/create-aws-bedrock-custom-model.md). Este endpoint armazena o que o corpo envia: ele não detecta tipo, capacidade nem preço, então envie `model_type`, os indicadores de capacidade e os valores por token `input_cost` / `output_cost`, ou execute a [validação](/docs/pt-BR/reference/models/validate-aws-bedrock-inference-profile.md) antes para obter o tipo, o desenvolvedor e as capacidades a incluir no corpo. `region` deve ser a região do ARN, e `integration_id` é o id da integração da AWS no workspace. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.