# Criar e gerenciar URLs de função do Lambda Um URL de função é um endpoint HTTP(S) dedicado para a função do Lambda. Você pode criar e configurar um URL de função no console do Lambda ou na API do Lambda. **dica** O Lambda oferece duas maneiras de invocar sua função por meio de um endpoint HTTP: URLs de função e Amazon API Gateway. Se não tiver certeza de qual é o melhor método para seu caso de uso, consulte [Seleção de um método para invocar a função do Lambda usando uma solicitação HTTP](furls-http-invoke-decision.md). Ao criar um URL de função, o Lambda gera automaticamente um endpoint de URL exclusivo para você. Após a criação de um URL de função, o endpoint de URL nunca muda. Os endpoints de URLs de função têm o seguinte formato: ``` https://.lambda-url..on.aws ``` **nota** Os URLs da função não são compatíveis com as seguintes Regiões da AWS: Ásia-Pacífico (Hyderabad) (`ap-south-2`), Ásia-Pacífico (Melbourne) (`ap-southeast-4`), Ásia-Pacífico (Malásia) (`ap-southeast-5`), Ásia-Pacífico (Nova Zelândia) (`ap-southeast-6`), Ásia-Pacífico (Tailândia) (`ap-southeast-7`), Ásia-Pacífico (Taipei) (`ap-east-2`), Oeste do Canadá (Calgary) (`ca-west-1`), Europa (Espanha) (`eu-south-2`), Europa (Zurique) (`eu-central-2`), Israel (Tel Aviv) (`il-central-1`), e Oriente Médio (EAU) (`me-central-1`). Os URLs de função são habilitados para pilha dupla, sendo compatíveis com IPv4 e IPv6. Depois de configurar um URL de função para a sua função, você pode invocar a função por meio de seu endpoint HTTP(S) via um navegador da Web, curl, Postman ou qualquer cliente HTTP. **nota** Você só pode acessar a URL da função pela Internet pública. Embora as funções do Lambda sejam compatíveis com o AWS PrivateLink, as URLs de função não o são. Os URLs de função do Lambda usam [políticas baseadas em recursos](access-control-resource-based.md) para segurança e controle de acesso. Os URLs de função também são compatíveis com opções de configuração de compartilhamento de recursos de origem cruzada (CORS). Você pode aplicar URLs de função a qualquer alias de função ou à versão da função não publicada `$LATEST`. Você não pode adicionar um URL de função a nenhuma outra versão da função. A seção a seguir mostra como criar e gerenciar um URL da função usando o console do Lambda, a AWS CLI e o modelo do CloudFormation. **Topics** + [Criar um URL de função (console)](#create-url-console) + [Criar um URL de função () (AWS CLI)](#create-url-cli) + [Adicionar um URL de função a um modelo do CloudFormation](#urls-cfn) + [Compartilhamento de recursos de origem cruzada (CORS)](#urls-cors) + [Controlar a utilização de URLs de função](#urls-throttling) + [Desativar URLs de função](#urls-deactivating) + [Excluir URLs de funções](#w2aac39c81c53) + [Controlar o acesso aos URLs de função do Lambda](urls-auth.md) + [Invocar URLs de função do Lambda](urls-invocation.md) + [Monitorar URLs de função do Lambda](urls-monitoring.md) + [Seleção de um método para invocar a função do Lambda usando uma solicitação HTTP](furls-http-invoke-decision.md) + [Tutorial: criar um endpoint de webhook usando um URL de função do Lambda](urls-webhook-tutorial.md) ## Criar um URL de função (console) Siga estas etapas para criar um URL de função usando o console. ### Para criar um URL da função para uma função existente 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha o nome da função para a qual você deseja criar o URL de função. 1. Escolha a guia **Configuration** (Configuração) e depois **Function URL** (URL de função). 1. Escolha **Create function URL** (Criar URL de função). 1. Para **Auth type** (Tipo de autenticação), escolha **AWS\$1IAM** ou **NONE** (NENHUM). Para obter mais informações sobre autenticação de URLs de função, consulte [Controle de acesso](urls-auth.md). 1. (Opcional) Selecione **Configure cross-origin resource sharing (CORS)** [Configurar compartilhamento de recursos de origem cruzada (CORS)] e defina as configurações de CORS para o URL de função. Para obter mais informações sobre CORS, consulte [Compartilhamento de recursos de origem cruzada (CORS)](#urls-cors). 1. Escolha **Salvar**. Isso cria um URL de função para a versão da função não publicada `$LATEST`. O URL de função aparece na seção **Function overview** (Visão geral de funções) do console. ### Para criar um URL da função para um alias existente 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha o nome da função com o alias para o qual você deseja criar o URL de função. 1. Escolha a guia **Aliases** e depois escolha o nome do alias para o qual você deseja criar o URL de função. 1. Escolha a guia **Configuration** (Configuração) e depois **Function URL** (URL de função). 1. Escolha **Create function URL** (Criar URL de função). 1. Para **Auth type** (Tipo de autenticação), escolha **AWS\$1IAM** ou **NONE** (NENHUM). Para obter mais informações sobre autenticação de URLs de função, consulte [Controle de acesso](urls-auth.md). 1. (Opcional) Selecione **Configure cross-origin resource sharing (CORS)** [Configurar compartilhamento de recursos de origem cruzada (CORS)] e defina as configurações de CORS para o URL de função. Para obter mais informações sobre CORS, consulte [Compartilhamento de recursos de origem cruzada (CORS)](#urls-cors). 1. Escolha **Salvar**. Isso cria um URL de função para o alias da função. O URL de função aparece na seção **Function overview** (Visão geral de funções) do console para o alias. ### Para criar uma nova função com um URL da função **Para criar uma nova função com um URL de função (console)** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha a opção **Criar função**. 1. Em **Basic information** (Informações básicas), faça o seguinte: 1. Em **Function Name** (Nome da função), insira o nome da função, como **my-function**. 1. Em **Runtime**, escolha o runtime da linguagem de sua preferência, como **Node.js 24**. 1. Para **Architecture** (Arquitetura ), escolha **x86\$164** ou **arm64**. 1. Expanda **Permissions** (Permissões) e depois escolha se vai criar uma nova função de execução ou usar uma já existente. 1. Expanda **Advanced settings** (Configurações avançadas) e selecione **Function URL** (URL de função). 1. Para **Auth type** (Tipo de autenticação), escolha **AWS\$1IAM** ou **NONE** (NENHUM). Para obter mais informações sobre autenticação de URLs de função, consulte [Controle de acesso](urls-auth.md). 1. (Opcional) Selecione **Configure cross-origin resource sharing (CORS)** [(Configurar compartilhamento de recursos de origem cruzada (CORS)]. Se essa opção for selecionada durante a criação da função, o URL de função permitirá solicitações de todas as origens por padrão. Você pode editar as configurações de CORS para o URL de função após criar a função. Para obter mais informações sobre CORS, consulte [Compartilhamento de recursos de origem cruzada (CORS)](#urls-cors). 1. Escolha a opção **Criar função**. Isso cria um novo URL de função para a versão da função não publicada `$LATEST`. O URL de função aparece na seção **Function overview** (Visão geral de funções) do console. ## Criar um URL de função () (AWS CLI) Para criar uma URL de função para uma função existente do Lambda usando a AWS Command Line Interface (AWS CLI), execute o seguinte comando: ``` aws lambda create-function-url-config \ --function-name my-function \ --qualifier prod \ // optional --auth-type AWS_IAM --cors-config {AllowOrigins="https://example.com"} // optional ``` Isso adiciona um URL de função ao qualificador **prod** da função **my-function**. Para obter mais informações sobre esses parâmetros de configuração, consulte [CreateFunctionURLConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) na referência da API. **nota** Para criar um URL de função por meio da AWS CLI, a função já deve existir. ## Adicionar um URL de função a um modelo do CloudFormation Para adicionar um recurso de `AWS::Lambda::Url` ao modelo do CloudFormation, use a seguinte sintaxe: ### JSON ``` { "Type" : "AWS::Lambda::Url", "Properties" : { "AuthType" : String, "Cors" : Cors, "Qualifier" : String, "TargetFunctionArn" : String } } ``` ### YAML ``` Type: AWS::Lambda::Url Properties: AuthType: String Cors: Cors Qualifier: String TargetFunctionArn: String ``` ### Parâmetros + (Obrigatório) `AuthType`: define o tipo de autenticação para o URL de função. Os valores possíveis são `AWS_IAM` ou `NONE`. Para restringir o acesso somente para usuários autenticados, defina como `AWS_IAM`. Para ignorar a autenticação do IAM e permitir que qualquer usuário faça solicitações à a função, defina como `NONE`. + (Optional) `Cors`: defina [CORS settings](#urls-cors) (Configurações de CORS) para o URL de função. Para adicionar `Cors` ao recurso `AWS::Lambda::Url` no CloudFormation, use a sintaxe a seguir. **Example AWS::Lambda::Url.Cors (JSON)** ``` { "AllowCredentials" : Boolean, "AllowHeaders" : [ String, ... ], "AllowMethods" : [ String, ... ], "AllowOrigins" : [ String, ... ], "ExposeHeaders" : [ String, ... ], "MaxAge" : Integer } ``` **Example AWS::Lambda::Url.Cors (YAML)** ``` AllowCredentials: Boolean AllowHeaders: - String AllowMethods: - String AllowOrigins: - String ExposeHeaders: - String MaxAge: Integer ``` + (Optional) `Qualifier`: o nome do alias. + (Obrigatório) `TargetFunctionArn`: o nome ou o nome do recurso da Amazon (ARN) da função do Lambda. Os formatos de nome válidos incluem o seguinte: + **Nome da função** – `my-function` + **ARN da função** – `arn:aws:lambda:us-west-2:123456789012:function:my-function` + **ARN parcial** – `123456789012:function:my-function` ## Compartilhamento de recursos de origem cruzada (CORS) Para definir como diferentes origens podem acessar o URL de função, use [Compartilhamento de recursos de origem cruzada (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). Recomendamos configurar o CORS se você pretender chamar o URL de função em um domínio diferente. O Lambda é compatível com os cabeçalhos de CORS a seguir para URLs de função. | Cabeçalhos de CORS | Propriedade da configuração de CORS | Exemplos de valores | | --- | --- | --- | | [ Access-Control-Allow-Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin) | `AllowOrigins` | `*` (permitir todas as origens) `https://www.example.com` `http://localhost:60905` | | [ Access-Control-Allow-Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods) | `AllowMethods` | `GET`, `POST`, `DELETE`, `*` | | [ Access-Control-Allow-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers) | `AllowHeaders` | `Date`, `Keep-Alive`, `X-Custom-Header` | | [ Access-Control-Expose-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers) | `ExposeHeaders` | `Date`, `Keep-Alive`, `X-Custom-Header` | | [ Access-Control-Allow-Credentials](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials) | `AllowCredentials` | `TRUE` | | [ Access-Control-Max-Age](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age) | `MaxAge` | `5` (padrão), `300` | Quando você configura o CORS para um URL de função usando o console do Lambda ou a AWS CLI, o Lambda adiciona automaticamente os cabeçalhos de CORS a todas as respostas por meio do URL de função. Como alternativa, você pode adicionar manualmente cabeçalhos de CORS à resposta da função. Se houver cabeçalhos conflitantes, o comportamento esperado depende do tipo de solicitação: + Para solicitações de preflight, como solicitações de OPTIONS, os cabeçalhos CORS configurados na URL da função têm precedência. O Lambda só retorna esses cabeçalhos CORS na resposta. + Para solicitações que não são de preflight, como solicitações GET ou POST, o Lambda retorna os cabeçalhos CORS configurados na URL da função, bem como os cabeçalhos CORS retornados pela função. Isso pode resultar em cabeçalhos CORS duplicados na resposta. Você pode ver um log similar a este: `The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed`. Em geral, recomendamos definir todas as configurações de CORS na URL da função, em vez de enviar cabeçalhos CORS manualmente na resposta da função. ## Controlar a utilização de URLs de função O controle de utilização limita a taxa na qual a função processa as solicitações. Isso é útil em muitas situações, como para impedir que a função sobrecarregue recursos downstream ou para lidar com um aumento repentino de solicitações. Você pode limitar a taxa de solicitações que a função do Lambda processa por meio de um URL de função configurando a simultaneidade reservada. A simultaneidade reservada limita o número máximo de invocações simultâneas para a função. A taxa máxima de solicitação por segundo (RPS) da função é equivalente a 10 vezes a simultaneidade reservada configurada. Por exemplo, se você configurar a função com uma simultaneidade reservada de 100, o RPS máximo será 1.000. Sempre que a simultaneidade da função exceder a simultaneidade reservada, o URL de função retornará um código de status HTTP `429`. Se a função receber uma solicitação que exceda o máximo de 10x RPS com base na simultaneidade reservada configurada, você também receberá um erro HTTP `429`. Para obter mais informações sobre simultaneidade reservada, consulte [Configurar a simultaneidade reservada para uma função](configuration-concurrency.md). ## Desativar URLs de função Em uma emergência, talvez você queira rejeitar todo o tráfego para o URL de função. Para reativar o URL de função, defina a simultaneidade reservada como zero. Isso controla a utilização de todas as solicitações ao URL de função, gerando respostas de status HTTP `429`. Para reativar o URL de função, exclua a configuração de simultaneidade reservada ou defina a configuração como um valor maior que zero. ## Excluir URLs de funções Quando você exclui um URL de função, não pode recuperá-lo. A criação de um novo URL de função resultará em um endereço URL diferente. **nota** Se você excluir um URL da função com o tipo de autenticação `NONE`, o Lambda não excluirá a política baseada em recursos associada a ela. Se quiser excluir essa política, deverá excluí-la manualmente. 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha o nome da função. 1. Escolha a guia **Configuration** (Configuração) e depois **Function URL** (URL de função). 1. Escolha **Excluir**. 1. Insira a palavra *delete* (excluir) no campo para confirmar a exclusão. 1. Escolha **Excluir**. **nota** Quando você exclui uma função que tem uma URL da função, o Lambda a exclui a URL da função de modo assíncrono. Se você criar imediatamente uma nova função com o mesmo nome e na mesma conta, é possível que a URL da função original seja mapeada para a nova função em vez de ser excluída. # Controlar o acesso aos URLs de função do Lambda **nota** A partir de outubro de 2025, os novos URLs da função exigirão as permissões `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction`. É possível controlar o acesso aos URLs da função do Lambda usando o parâmetro [AuthType](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html#lambda-CreateFunctionUrlConfig-request-AuthType) combino com as [políticas baseadas em recursos](access-control-resource-based.md) anexadas a sua função específica. A configuração desses dois componentes determina quem pode invocar ou executar outras ações administrativas no URL de função. O parâmetro `AuthType` determina como o Lambda autentica ou autoriza solicitações ao URL de função. Ao configurar o URL de função, você deve especificar uma das seguintes opções de `AuthType`: + `AWS_IAM`: o Lambda usa o AWS Identity and Access Management (IAM) para autenticar e autorizar solicitações com base na política de identidade da entidade principal do IAM e na política baseada em recursos da função. Escolha essa opção se quiser que apenas usuários e perfis autenticados para invocar a função usando o URL da função. + `NONE`: o Lambda não realiza nenhuma autenticação antes de invocar a função. Porém, a política baseada em recursos da função está sempre em vigor e deve conceder acesso público antes que o URL de função possa receber solicitações. Escolha essa opção para permitir acesso público e não autenticado ao URL de função. Para obter informações adicionais sobre segurança, você pode usar AWS Identity and Access Management Access Analyzer para obter uma análise abrangente do acesso externo ao URL de função. O IAM Access Analyzer também monitora permissões novas ou atualizadas nas funções do Lambda para ajudá-lo a identificar as permissões que concedem acesso público e acesso entre contas. Você pode usar o analisador de acesso do IAM sem custo. Para começar a usar o IAM Access Analyzer, consulte [Usando o AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html). Esta página contém exemplos de políticas baseadas em recursos para ambos os tipos de autenticação e como criar essas políticas usando a operação da API [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) ou o console do Lambda. Para obter informações sobre como invocar o URL da função depois de configurar as permissões, consulte [Invocar URLs de função do Lambda](urls-invocation.md). **Topics** + [Usar o tipo de autenticação `AWS_IAM`](#urls-auth-iam) + [Usar o tipo de autenticação `NONE`](#urls-auth-none) + [Governança e controle de acesso](#urls-governance) ## Usar o tipo de autenticação `AWS_IAM` Se você escolher o tipo de autenticação `AWS_IAM`, os usuários que precisarem invocar o URL da função do Lambda deverão ter as permissões `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction`. Dependendo de quem faz a solicitação de invocação, pode ser necessário conceder essa permissão usando uma [política baseada em recursos](access-control-resource-based.md). Se a entidade principal fazendo a solicitação estiver na mesma Conta da AWS que o URL da função, a entidade principal deve **ou** ter permissões `lambda:InvokeFunctionUrl` na `lambda:InvokeFunction` [política baseada em identidade](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html), **ou** ter permissões concedidas na política baseada em recursos da função. Em outras palavras, uma política baseada em recursos será opcional se o usuário já tiver permissões `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction` em sua política baseada em identidade. A avaliação de políticas segue as regras descritas na [Lógica de avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html). Se a entidade principal fazendo a solicitação estiver em uma conta diferente, a entidade principal deverá ter **ambas**, uma política baseada em identidade que forneça a ela as permissões `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction` **e** permissões concedidas em uma política baseada em recursos para a função que ela está tentando invocar. A avaliação da política segue as regras descritas em [Determinar se uma solicitação entre contas é permitida](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html#policy-eval-cross-account). A política baseada em recursos a seguir permite que a função `example` na Conta da AWS `444455556666` invoque o URL da função associado à função `my-function`. A chave de contexto [lambda:invokedViaFunctionUrl](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html#lambda-AddPermission-request-InvokedViaFunctionUrl) restringe a ação `lambda:InvokeFunction` para as chamadas do URL da função. Isso significa que a entidade principal deve usar o URL da função para invocar a função. Se você não incluir `lambda:InvokedViaFunctionUrl`, a entidade principal poderá invocar sua função por meio de outros métodos de invocação, além do URL da função. **Example — Política baseada em recursos entre contas** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action": "lambda:InvokeFunctionUrl", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "AWS_IAM" } } }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:my-function", "Condition": { "Bool": { "lambda:InvokedViaFunctionUrl": "true" } } } ] } ``` Você pode criar essa política baseada em recursos por meio do console, seguindo as seguintes etapas: **Como conceder permissões de invocação de URL a outra conta (console)** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Escolha o nome da função para a qual deseja conceder permissões de invocação de URL. 1. Escolha a guia **Configuration** (Configuração) e, depois, **Permissions** (Permissões). 1. Em **Resource-based policy** (Política baseada em recursos), escolha **Add permissions** (Adicionar permissões). 1. Escolha **Function URL** (URL de função). 1. Para **Auth type** (Tipo de autenticação), escolha **AWS\$1IAM**. 1. Insira um **ID de declaração** para sua declaração de política. 1. Em **Entidade principal**, insira o ID da conta ou o nome do recurso da Amazon (ARN) do usuário ou da função para a qual você deseja conceder permissões. Por exemplo: **444455556666**. 1. Escolha **Salvar**. Como alternativa, você pode criar essa política usando os seguintes comandos [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) do AWS Command Line Interface (AWS CLI). Ao usar a AWS CLI, você deve adicionar as declarações `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction` separadamente. Por exemplo: ``` aws lambda add-permission --function-name my-function \ --statement-id UrlPolicyInvokeURL \ --action lambda:InvokeFunctionUrl \ --principal 444455556666 \ --function-url-auth-type AWS_IAM ``` ``` aws lambda add-permission --function-name my-function \ --statement-id UrlPolicyInvokeFunction \ --action lambda:InvokeFunction \ --principal 444455556666 \ --invoked-via-function-url ``` ## Usar o tipo de autenticação `NONE` **Importante** Quando o tipo de autenticação do URL dA função for `NONE` e você tiver uma [política baseada em recursos](access-control-resource-based.md) que concede acesso público, qualquer usuário não autenticado com o URL da função poderá invocar a função. Em alguns casos, você pode querer que o URL da função seja público. Por exemplo, você pode querer atender a solicitações feitas diretamente de um navegador da Web. Para permitir acesso público ao URL de função, escolha o tipo de autenticação `NONE`. Se você escolher o tipo de autenticação `NONE`, o Lambda não usará o IAM para autenticar solicitações ao URL de função. No entanto, sua função deve ter uma política baseada em recursos que permita `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction`. Quando você cria um URL da função com o tipo de autenticação `NONE` usando o console ou o AWS Serverless Application Model (AWS SAM), o Lambda cria automaticamente a política baseada em recursos para você. Se estiver usando a AWS CLI, o AWS CloudFormation ou a API do Lambda diretamente, deverá [adicionar as políticas](#policy-cli) você mesmo. Recomendamos que você inclua a chave de contexto [lambda:InvokedViaFunctionUrl](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html#lambda-AddPermission-request-InvokedViaFunctionUrl) em suas políticas baseadas em recursos ao usar o tipo de autenticação `NONE`. Essa chave de contexto garante que a função só possa ser invocada por meio do URL da função e não por meio de outros métodos de invocação. Observe o seguinte sobre essa política: + Todas as entidades podem chamar `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction`. Isso significa que qualquer pessoa que tenha o URL da sua função pode invocá-la. + O valor da chave de condição `lambda:FunctionUrlAuthType` é `NONE`. Isso significa que a instrução da política só permite acesso quando o tipo de autenticação do URL da função também é `NONE`. + A condição `lambda:InvokedViaFunctionUrl` garante que a função só possa ser invocada por meio do URL da função e não por meio de outros métodos de invocação. **Example — Política baseada em recursos padrão para o tipo de autenticação NONE** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "FunctionURLAllowPublicAccess", "Effect": "Allow", "Principal": "*", "Action": "lambda:InvokeFunctionUrl", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "NONE" } } }, { "Sid": "FunctionURLInvokeAllowPublicAccess", "Effect": "Allow", "Principal": "*", "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Condition": { "Bool": { "lambda:InvokedViaFunctionUrl": "true" } } } ] } ``` **Crie a política baseada em recursos usando o AWS CLI** A menos que você use o console ou AWS SAM crie um URL da função com tipo de autenticação `NONE`, você mesmo deve adicionar a política baseada em recursos. Use os seguintes comandos para criar instruções com as permissões `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction`. Cada instrução deve ser adicionada em um comando separado. ``` aws lambda add-permission \ --function-name UrlTestFunction \ --statement-id UrlPolicyInvokeURL \ --action lambda:InvokeFunctionUrl \ --principal * \ --function-url-auth-type NONE ``` ``` aws lambda add-permission \ --function-name UrlTestFunction \ --statement-id UrlPolicyInvokeFunction \ --action lambda:InvokeFunction \ --principal * \ --invoked-via-function-url ``` **nota** Se você excluir um URL da função com o tipo de autenticação `NONE`, o Lambda não excluirá a política baseada em recursos associada a ela. Se quiser excluir essa política, deverá excluí-la manualmente. Se a política baseada em recursos para uma função não conceder as permissões `lambda:invokeFunctionUrl` e `lambda:InvokeFunction`, os usuários receberão um código de erro 403 Forbidden (Proibido) quando tentarem invocar o URL da função. Isso ocorrerá mesmo se o URL da função usar o tipo de autenticação `NONE`. ## Governança e controle de acesso Além das permissões de invocação de URL de função, você também pode controlar o acesso nas ações usadas para configurar URLs de função. O Lambda é compatível com as seguintes ações da política do IAM para URLs de função: + `lambda:InvokeFunctionUrl`: chamar uma função do Lambda usando o URL de função. + `lambda:CreateFunctionUrlConfig` – criar um URL de função e definir seu `AuthType`. + `lambda:UpdateFunctionUrlConfig` – atualizar a configuração de um URL de função e seu `AuthType`. + `lambda:GetFunctionUrlConfig`: visualizar os detalhes de um URL de função. + `lambda:ListFunctionUrlConfigs`: listar as configurações de URL de função. + `lambda:DeleteFunctionUrlConfig`: excluir um URL de função. Para permitir ou negar acesso a URLs de função a outras entidades da AWS, inclua essas ações nas políticas do IAM. Por exemplo, a política a seguir concede à função `example` na Conta da AWS `444455556666` permissões para atualizar o URL de função para a função **my-function** na conta `123456789012`. **Example política de URL de função entre contas** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action": "lambda:UpdateFunctionUrlConfig", "Resource": "arn:aws:lambda:us-east-2:123456789012:function:my-function" } ] } ``` ### Chaves de condição Para ter um controle de acesso refinado sobre os URLs da função, use chaves de contexto de condição. O Lambda é compatível com as seguintes chaves de condição para URLs da função: + `lambda:FunctionUrlAuthType`: define um valor de enumerador descrevendo o tipo de autenticação que o URL da função usa. O valor pode ser `AWS_IAM` ou `NONE`. + `lambda:InvokedViaFunctionUrl`: restringe a ação `lambda:InvokeFunction` às chamadas feitas por meio do URL da função. Isso garante que a função só possa ser invocada por meio do URL da função e não por meio de outros métodos de invocação. Para exemplos de políticas baseadas em recursos que usam a chave de contexto `lambda:InvokedViaFunctionUrl`, consulte os exemplos em [Usar o tipo de autenticação `AWS_IAM`](#urls-auth-iam) e [Usar o tipo de autenticação `NONE`](#urls-auth-none). É possível usar essas chaves de contexto em políticas associadas à sua função. Por exemplo, você pode restringir quem pode fazer alterações nas configurações dos URLs de função. Para negar todas as solicitações `UpdateFunctionUrlConfig` a qualquer função com o tipo de autenticação de URL `NONE`, você pode definir a seguinte política: **Example política de URL de função com negação explícita** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action":[ "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:us-east-1:123456789012:function:*", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "NONE" } } } ] } ``` Para conceder à função `example` na Conta da AWS `444455556666` permissões para fazer solicitações `CreateFunctionUrlConfig` e `UpdateFunctionUrlConfig` em funções com o tipo de autenticação de URL `AWS_IAM`, você pode definir a seguinte política: **Example política de URL de função com permissão explícita** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:role/example" }, "Action":[ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:us-east-1:123456789012:function:*", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "AWS_IAM" } } } ] } ``` Você também pode usar essa chave de condição em uma [política de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP). Use SCPs para gerenciar permissões em toda a organização em AWS Organizations. Por exemplo, para não permitir que usuários criem ou atualizem URLs de função que usem qualquer tipo de autenticação, exceto `AWS_IAM`, use a seguinte política de controle de serviço: **Example SCP de URL de função com negação explícita** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action":[ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:*:123456789012:function:*", "Condition": { "StringNotEquals": { "lambda:FunctionUrlAuthType": "AWS_IAM" } } } ] } ``` # Invocar URLs de função do Lambda Um URL de função é um endpoint HTTP(S) dedicado para a função do Lambda. Você pode criar e configurar um URL de função no console do Lambda ou na API do Lambda. **dica** O Lambda oferece duas maneiras de invocar sua função por meio de um endpoint HTTP: URLs de função e Amazon API Gateway. Se não tiver certeza de qual é o melhor método para seu caso de uso, consulte [Seleção de um método para invocar a função do Lambda usando uma solicitação HTTP](furls-http-invoke-decision.md). Ao criar um URL de função, o Lambda gera automaticamente um endpoint de URL exclusivo para você. Após a criação de um URL de função, o endpoint de URL nunca muda. Os endpoints de URLs de função têm o seguinte formato: ``` https://.lambda-url..on.aws ``` **nota** Os URLs da função não são compatíveis com as seguintes Regiões da AWS: Ásia-Pacífico (Hyderabad) (`ap-south-2`), Ásia-Pacífico (Melbourne) (`ap-southeast-4`), Ásia-Pacífico (Malásia) (`ap-southeast-5`), Ásia-Pacífico (Nova Zelândia) (`ap-southeast-6`), Ásia-Pacífico (Tailândia) (`ap-southeast-7`), Ásia-Pacífico (Taipei) (`ap-east-2`), Oeste do Canadá (Calgary) (`ca-west-1`), Europa (Espanha) (`eu-south-2`), Europa (Zurique) (`eu-central-2`), Israel (Tel Aviv) (`il-central-1`), e Oriente Médio (EAU) (`me-central-1`). Os URLs de função são habilitados para pilha dupla, sendo compatíveis com IPv4 e IPv6. Após configurar o URL de função, você pode invocar a função por meio de seu endpoint HTTP(S) via um navegador da Web, curl, Postman ou qualquer cliente HTTP. Para invocar um URL da função, você deve ter permissões `lambda:InvokeFunctionUrl` e `lambda:InvokeFunction`. Para obter mais informações, consulte [Controle de acesso](urls-auth.md). **Topics** + [Noções básicas sobre invocação de URL de função](#urls-invocation-basics) + [Cargas úteis de solicitações e respostas](#urls-payloads) ## Noções básicas sobre invocação de URL de função Se o URL de função usar o tipo de autenticação, `AWS_IAM`você deve assinar cada solicitação HTTP usando a \$1[AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)\$1. Ferramentas como [Postman](https://quickstarts.postman.com/guide/aws/index.html?index=..%2F..index#2) oferecem maneiras integradas de assinar solicitações com o Sigv4. Se não usar uma ferramenta para assinar as solicitações HTTP ao URL de função, você deverá assinar manualmente cada solicitação usando o SigV4. Quando o URL de função recebe uma solicitação, o Lambda também analisa a assinatura do Sigv4. O Lambda só processa a solicitação se as assinaturas corresponderem. Para obter instruções sobre como assinar manualmente as solicitações com o SigV4, consulte [Assinar solicitações da AWS com o Signature versão 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html), no *Guia Referência geral da Amazon Web Services*. Se o URL de função usar o tipo de autenticação `NONE`, você não precisará assinar as solicitações usando o Sigv4. Você pode invocar a função usando um navegador da Web, curl, Postman ou qualquer cliente HTTP. Para testar simples solicitações `GET` à função, use um navegador da Web. Por exemplo, se o URL de função for `https://abcdefg.lambda-url.us-east-1.on.aws` e aceitar um parâmetro de string `message`, o URL de solicitação pode ser semelhante a este: ``` https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld ``` Para testar outras solicitações HTTP, como uma solicitação `POST`, você pode usar uma ferramenta como curl. Por exemplo, se quiser incluir alguns dados JSON em uma solicitação `POST` ao URL de função, você poderá usar o seguinte comando curl: ``` curl -v 'https://abcdefg.lambda-url.us-east-1.on.aws/?message=HelloWorld' \ -H 'content-type: application/json' \ -d '{ "example": "test" }' ``` ## Cargas úteis de solicitações e respostas Quando um cliente chama o URL de função, o Lambda mapeia a solicitação para um objeto de evento antes de passá-la para a função. A resposta da função é então mapeada para uma resposta HTTP que o Lambda envia de volta ao cliente por meio do URL de função. Os formatos de evento de solicitação e resposta seguem o mesmo esquema do [formato de carga útil do Amazon API Gateway versão 2.0](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html#http-api-develop-integrations-lambda.proxy-format). ### Formato de carga útil de solicitação Uma carga útil de solicitação tem a seguinte estrutura: ``` { "version": "2.0", "routeKey": "$default", "rawPath": "/my/path", "rawQueryString": "parameter1=value1¶meter1=value2¶meter2=value", "cookies": [ "cookie1", "cookie2" ], "headers": { "header1": "value1", "header2": "value1,value2" }, "queryStringParameters": { "parameter1": "value1,value2", "parameter2": "value" }, "requestContext": { "accountId": "123456789012", "apiId": "", "authentication": null, "authorizer": { "iam": { "accessKey": "AKIA...", "accountId": "111122223333", "callerId": "AIDA...", "cognitoIdentity": null, "principalOrgId": null, "userArn": "arn:aws:iam::111122223333:user/example-user", "userId": "AIDA..." } }, "domainName": ".lambda-url.us-west-2.on.aws", "domainPrefix": "", "http": { "method": "POST", "path": "/my/path", "protocol": "HTTP/1.1", "sourceIp": "123.123.123.123", "userAgent": "agent" }, "requestId": "id", "routeKey": "$default", "stage": "$default", "time": "12/Mar/2020:19:03:58 +0000", "timeEpoch": 1583348638390 }, "body": "Hello from client!", "pathParameters": null, "isBase64Encoded": false, "stageVariables": null } ``` | Parameter | Descrição | Exemplo | | --- | --- | --- | | `version` | A versão do formato de carga útil para esse evento. Atualmente, os URLs de função do Lambda são compatíveis com o [formato de carga útil versão 2.0](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html#http-api-develop-integrations-lambda.proxy-format). | `2.0` | | `routeKey` | URLs de função não usam esse parâmetro. O Lambda define isso como `$default` para marcar um espaço reservado. | `$default` | | `rawPath` | O caminho da solicitação. Por exemplo, se o URL de solicitação for `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo`, o valor do caminho bruto será `/example/test/demo`. | `/example/test/demo` | | `rawQueryString` | A string bruta que contém os parâmetros de string de consulta da solicitação. Os caracteres compatíveis incluem `a-z`, `A-Z`, `0-9`, `.`, `_`, `-`, `%`, `&`, `=` e `+`. | `"?parameter1=value1¶meter2=value2"` | | `cookies` | Uma matriz contendo todos os cookies enviados como parte da solicitação. | `["Cookie_1=Value_1", "Cookie_2=Value_2"]` | | `headers` | A lista de cabeçalhos de solicitação, apresentada como pares chave-valor. | `{"header1": "value1", "header2": "value2"}` | | `queryStringParameters` | Os parâmetros de consulta para a solicitação. Por exemplo, se o URL de solicitação for `https://{url-id}.lambda-url.{region}.on.aws/example?name=Jane`, o valor `queryStringParameters` será um objeto JSON com uma chave `name` e um valor `Jane`. | `{"name": "Jane"}` | | `requestContext` | Um objeto que contém informações adicionais sobre a solicitação, como o `requestId`, a hora da solicitação e a identidade do chamador se autorizado pelo AWS Identity and Access Management (IAM). | | | `requestContext.accountId` | O ID da Conta da AWS do proprietário da função. | `"123456789012"` | | `requestContext.apiId` | O ID do URL de função. | `"33anwqw8fj"` | | `requestContext.authentication` | URLs de função não usam esse parâmetro. O Lambda define isso como `null`. | `null` | | `requestContext.authorizer` | Um objeto que contém informações sobre a identidade do chamador, se o URL de função usar o tipo de autenticação `AWS_IAM`. Do contrário, o Lambda define isso como `null`. | | | `requestContext.authorizer.iam.accessKey` | A chave de acesso da identidade do chamador. | `"AKIAIOSFODNN7EXAMPLE"` | | `requestContext.authorizer.iam.accountId` | O ID da Conta da AWS da identidade do chamador. | `"111122223333"` | | `requestContext.authorizer.iam.callerId` | O ID (ID do usuário) do chamador. | `"AIDACKCEVSQ6C2EXAMPLE"` | | `requestContext.authorizer.iam.cognitoIdentity` | URLs de função não usam esse parâmetro. O Lambda define isso como `null` ou exclui isso do JSON. | `null` | | `requestContext.authorizer.iam.principalOrgId` | O ID da organização da entidade principal associado à identidade do chamador. | `"AIDACKCEVSQORGEXAMPLE"` | | `requestContext.authorizer.iam.userArn` | O nome do recurso da Amazon (ARN) do usuário da identidade do chamador. | `"arn:aws:iam::111122223333:user/example-user"` | | `requestContext.authorizer.iam.userId` | O ID de usuário da identidade do chamador. | `"AIDACOSFODNN7EXAMPLE2"` | | `requestContext.domainName` | O nome do domínio do URL de função. | `".lambda-url.us-west-2.on.aws"` | | `requestContext.domainPrefix` | O prefixo do domínio do URL de função. | `""` | | `requestContext.http` | Um objeto que contém detalhes sobre a solicitação HTTP. | | | `requestContext.http.method` | O método HTTP usado na solicitação. Os valores válidos incluem `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PATCH` e `DELETE`. | `GET` | | `requestContext.http.path` | O caminho da solicitação. Por exemplo, se o URL de solicitação for `https://{url-id}.lambda-url.{region}.on.aws/example/test/demo`, o valor do caminho será `/example/test/demo`. | `/example/test/demo` | | `requestContext.http.protocol` | O protocolo da solicitação. | `HTTP/1.1` | | `requestContext.http.sourceIp` | O endereço IP de origem da conexão TCP imediata que está fazendo a solicitação. | `123.123.123.123` | | `requestContext.http.userAgent` | O valor do cabeçalho da solicitação User-Agent. | `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Gecko/20100101 Firefox/42.0` | | `requestContext.requestId` | O ID da solicitação da invocação. Você pode usar esse ID para logs de invocações relacionadas à função. | `e1506fd5-9e7b-434f-bd42-4f8fa224b599` | | `requestContext.routeKey` | URLs de função não usam esse parâmetro. O Lambda define isso como `$default` para marcar um espaço reservado. | `$default` | | `requestContext.stage` | URLs de função não usam esse parâmetro. O Lambda define isso como `$default` para marcar um espaço reservado. | `$default` | | `requestContext.time` | O timestamp da solicitação. | `"07/Sep/2021:22:50:22 +0000"` | | `requestContext.timeEpoch` | O timestamp da solicitação, no horário da era UNIX. | `"1631055022677"` | | `body` | O corpo da solicitação. Se o tipo de conteúdo da solicitação for binário, o corpo será codificado na base 64. | `{"key1": "value1", "key2": "value2"}` | | `pathParameters` | URLs de função não usam esse parâmetro. O Lambda define isso como `null` ou exclui isso do JSON. | `null` | | `isBase64Encoded` | `TRUE` se o corpo for uma carga útil binária e for codificado na base 64. `FALSE` nos demais casos. | `FALSE` | | `stageVariables` | URLs de função não usam esse parâmetro. O Lambda define isso como `null` ou exclui isso do JSON. | `null` | ### Formato de carga útil de resposta Quando a função retorna uma resposta, o Lambda analisa a resposta e converte-a em uma resposta HTTP. As cargas úteis de resposta de função têm o seguinte formato: ``` { "statusCode": 201, "headers": { "Content-Type": "application/json", "My-Custom-Header": "Custom Value" }, "body": "{ \"message\": \"Hello, world!\" }", "cookies": [ "Cookie_1=Value1; Expires=21 Oct 2021 07:48 GMT", "Cookie_2=Value2; Max-Age=78000" ], "isBase64Encoded": false } ``` O Lambda infere o formato de resposta para você. Se a função do Lambda retornar JSON válido e não retornar um `statusCode`, o Lambda pressupõe o seguinte: + `statusCode` is `200`. **nota** Os `statusCode` válidos vão de 100 a 599. + `content-type` is `application/json`. + `body` é a resposta da função. + `isBase64Encoded` is `false`. Os exemplos a seguir mostram como a saída da função do Lambda é mapeada para a carga útil da resposta e como a carga útil da resposta é mapeada para a resposta HTTP final. Quando o cliente invoca o URL de função, ele vê a resposta HTTP. **Exemplo de saída para uma resposta de string** | Saída da função do Lambda | Saída de resposta interpretada | Resposta HTTP (o que o cliente vê) | | --- | --- | --- | | 
"Hello, world!"
| 
{
  "statusCode": 200,
  "body": "Hello, world!",
  "headers": {
    "content-type": "application/json"
  },
  "isBase64Encoded": false
}
| 
HTTP/2 200
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 15

"Hello, world!"
| **Exemplo de saída para uma resposta em JSON** | Saída da função do Lambda | Saída de resposta interpretada | Resposta HTTP (o que o cliente vê) | | --- | --- | --- | | 
{
  "message": "Hello, world!"
}
| 
{
  "statusCode": 200,
  "body": {
    "message": "Hello, world!"
  },
  "headers": {
    "content-type": "application/json"
  },
  "isBase64Encoded": false
}
| 
HTTP/2 200
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 34

{
  "message": "Hello, world!"
}
| **Exemplo de saída para uma resposta personalizada** | Saída da função do Lambda | Saída de resposta interpretada | Resposta HTTP (o que o cliente vê) | | --- | --- | --- | | 
{
   "statusCode": 201,
    "headers": {
        "Content-Type": "application/json",
        "My-Custom-Header": "Custom Value"
    },
    "body": JSON.stringify({
        "message": "Hello, world!"
    }),
    "isBase64Encoded": false
}
| 
{
   "statusCode": 201,
    "headers": {
        "Content-Type": "application/json",
        "My-Custom-Header": "Custom Value"
    },
    "body": JSON.stringify({
        "message": "Hello, world!"
    }),
    "isBase64Encoded": false
}
| 
HTTP/2 201
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 27
my-custom-header: Custom Value

{
  "message": "Hello, world!"
}
| ### Cookies Para retornar cookies da função, não adicione manualmente cabeçalhos `set-cookie`. Em vez disso, inclua os cookies no objeto de carga útil da resposta. O Lambda interpreta isso automaticamente e adiciona-os como cabeçalhos `set-cookie` na resposta HTTP, como no exemplo a seguir. | Saída da função do Lambda | Resposta HTTP (o que o cliente vê) | | --- | --- | | 
{
   "statusCode": 201,
    "headers": {
        "Content-Type": "application/json",
        "My-Custom-Header": "Custom Value"
    },
    "body": JSON.stringify({
        "message": "Hello, world!"
    }),
    "cookies": [
        "Cookie_1=Value1; Expires=21 Oct 2021 07:48 GMT",
        "Cookie_2=Value2; Max-Age=78000"
    ],
    "isBase64Encoded": false
}
| 
HTTP/2 201
date: Wed, 08 Sep 2021 18:02:24 GMT
content-type: application/json
content-length: 27
my-custom-header: Custom Value
set-cookie: Cookie_1=Value2; Expires=21 Oct 2021 07:48 GMT
set-cookie: Cookie_2=Value2; Max-Age=78000

{
  "message": "Hello, world!"
}
| # Monitorar URLs de função do Lambda Você pode usar o AWS CloudTrail e o Amazon CloudWatch para monitorar os URLs de função. **Topics** + [Monitorar URLs de função com o CloudTrail](#urls-cloudtrail) + [Métricas do CloudWatch para URLs de função](#urls-cloudwatch) ## Monitorar URLs de função com o CloudTrail Para URLs de função, o Lambda é automaticamente compatível com o registro das seguintes operações de API como eventos nos arquivos de log do CloudTrail: + [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html) + [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html) + [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html) + [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html) + [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html) Toda entrada de log contém informações sobre a identidade do chamador, quando a solicitação foi feita e outros detalhes. Você pode ver todos os eventos nos últimos 90 dias visualizando o **Event history** (Histórico de eventos) do CloudTrail. Para reter registros por mais de 90 dias, você pode criar uma trilha. Por padrão, o CloudTrail não registra solicitações `InvokeFunctionUrl`, que são consideradas eventos de dados. Porém, você pode ativar o registro de eventos de dados no CloudTrail. Para obter mais informações, consulte [Registro eventos de dados em logs para trilhas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html) no *Guia do usuário do AWS CloudTrail*. ## Métricas do CloudWatch para URLs de função O Lambda envia métricas agregadas sobre solicitações de URL de função para o CloudWatch. Com essas métricas, você pode monitorar os URLs de função, criar painéis e configurar alarmes no console do CloudWatch. Os URLs de função são compatíveis as seguintes métricas de invocação. Recomendamos visualizar essas métricas com a estatística `Sum`. + `UrlRequestCount`: o número de solicitações feitas a esse URL de função. + `Url4xxCount`: o número de solicitações que retornaram um código de status HTTP 4XX. Os códigos da série 4XX indicam erros do lado do cliente, como solicitações incorretas. + `Url5xxCount`: o número de solicitações que retornaram um código de status HTTP 5XX. Os códigos da série 5XX indicam erros do lado do servidor, como erros de função e de tempo limite. Os URLs de função também são compatíveis com a métrica de performance a seguir. Recomendamos visualizar essas métricas com as estatísticas `Average` ou `Max`. + `UrlRequestLatency`: o tempo decorrido entre a hora que o URL de função recebe uma solicitação e a hora que o URL de função retorna uma resposta. Cada uma dessas métricas de invocação e performance é compatível com as seguintes dimensões: + `FunctionName`: visualizar as métricas agregadas para os URLs de função atribuídos a uma versão da função não publicada `$LATEST` ou para qualquer um dos aliases da função. Por exemplo, `hello-world-function`. + `Resource`: visualizar as métricas para um URL de função específico. Isso é definido por um nome de função, junto com a versão da função não publicada `$LATEST` ou um dos aliases da função. Por exemplo, `hello-world-function:$LATEST`. + `ExecutedVersion`: visualizar as métricas para um URL de função específico com base na versão executada. Você pode usar essa dimensão principalmente para rastrear o URL de função atribuído à versão não publicada `$LATEST`. # Seleção de um método para invocar a função do Lambda usando uma solicitação HTTP Muitos casos de uso comuns do Lambda envolvem invocar a função usando uma solicitação HTTP. Por exemplo, você pode querer que uma aplicação Web invoque sua função por meio de uma solicitação do navegador. As funções do Lambda também podem ser usadas para criar APIs REST completas, lidar com interações do usuário em aplicativos móveis, processar dados de serviços externos por meio de chamadas HTTP ou criar webhooks personalizados. As seções a seguir explicam quais são as opções para invocar o Lambda por meio de HTTP e fornecem informações para que você tome a decisão certa para seu caso de uso específico. ## Quais são suas opções ao selecionar um método de invocação HTTP? O Lambda oferece dois métodos principais para invocar uma função usando uma solicitação HTTP: [URLs de função](urls-configuration.md) e o [API Gateway](services-apigateway.md). As principais diferenças entre ambos são as duas opções seguintes: + Os **URLs de função do Lambda** fornecem um endpoint HTTP simples e direto para uma função do Lambda. Eles são otimizados para proporcionar simplicidade e economia e fornecem o caminho mais rápido para expor uma função do Lambda via HTTP. + O **API Gateway** é um serviço mais avançado para criar APIs completas. O API Gateway é otimizado para criar e gerenciar APIs de produção em grande escala e fornece ferramentas abrangentes para segurança, monitoramento e gerenciamento de tráfego. ## Recomendações se você já conhece seus requisitos Se você já sabe quais são seus requisitos, estas são as nossas recomendações básicas: Recomendamos usar os **[URLs de funções](urls-configuration.md)** para aplicações simples ou prototipagem em que você só precisa de métodos básicos de autenticação e tratamento de solicitações/respostas e onde deseja ter o mínimo de custo e a complexidade. O **[API Gateway](services-apigateway.md)** é a melhor opção para aplicações de produção em grande escala ou para casos em que você precisa de recursos mais avançados, como suporte à [descrição de OpenAPI](https://www.openapis.org/), opções de autenticação, nomes de domínio personalizados ou tratamento avançado de solicitações/respostas, incluindo controle de utilização, armazenamento em cache e transformação de solicitação/resposta. ## O que considerar ao selecionar um método para invocar a função do Lambda Ao selecionar entre URLs de função e o API Gateway, você precisa considerar os seguintes fatores: + Suas necessidades de autenticação, como se você precisa do OAuth ou do Amazon Cognito para autenticar usuários + Seus requisitos de escalabilidade e a complexidade da API que deseja implementar + Se você precisa de recursos avançados, como validação de solicitação e formatação de solicitação/resposta + Seus requisitos de monitoramento + Suas metas de custo Ao compreender esses fatores, você pode selecionar a opção que melhor equilibra seus requisitos de segurança, complexidade e custo. As informações a seguir resumem as principais diferenças entre as duas opções. ### Autenticação + Os **URLs de função** fornecem opções básicas de autenticação por meio do AWS Identity and Access Management (IAM). Você pode configurar seus endpoints para serem públicos (sem autenticação) ou para exigirem a autenticação do IAM. Com a autenticação do IAM, você pode usar credenciais padrão da AWS ou perfis do IAM para controlar o acesso. Embora seja simples de configurar, essa abordagem oferece opções limitadas em comparação a outros métodos de autenticação. + O **API Gateway** fornece acesso a uma variedade maior de opções de autenticação. Além da autenticação do IAM, você pode usar [autorizadores do Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) (lógica de autenticação personalizada), grupos de usuários do [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) e fluxos do OAuth2.0. Essa flexibilidade permite que você implemente esquemas complexos de autenticação, incluindo provedores de autenticação terceirizados, autenticação baseada em tokens e autenticação multifator. ### Tratamento de solicitação/resposta + Os **URLs de função** fornecem tratamento básico para solicitações e respostas HTTP. Eles são compatíveis com métodos HTTP padrão e incluem suporte integrado para compartilhamento de recursos de origem cruzada (CORS). Embora consigam lidar com cargas úteis JSON e parâmetros de consulta naturalmente, eles não oferecem recursos de transformação ou validação de solicitações. O tratamento de respostas é igualmente simples: o cliente recebe a resposta da sua função do Lambda exatamente como o Lambda a retorna. + O **API Gateway** fornece recursos sofisticados de tratamento de solicitações e respostas. Você pode definir validadores de solicitações, transformar solicitações e respostas usando modelos de mapeamento, configurar cabeçalhos de solicitação/resposta e implementar o armazenamento em cache de respostas. O API Gateway também oferece suporte a cargas úteis binárias e nomes de domínio personalizados e pode modificar as respostas antes que elas cheguem ao cliente. Você pode configurar modelos para validação e transformação de solicitação/resposta usando o esquema JSON. ### Escalabilidade + Os **URLs de funções** escalam diretamente com os limites de simultaneidade da sua função do Lambda e lidam com picos de tráfego escalando sua função até o limite máximo de simultaneidade configurado. Quando esse limite é atingido, o Lambda responde a solicitações adicionais com respostas HTTP 429. Não há um mecanismo de enfileiramento integrado, portanto, lidar com a escalabilidade depende inteiramente da configuração da sua função do Lambda. Por padrão, as funções do Lambda têm um limite de mil execuções simultâneas por Região da AWS. + O **API Gateway** fornece recursos adicionais de escalabilidade além da própria escalabilidade do Lambda. Ele inclui recursos integrados de enfileiramento e controle de utilização, permitindo que você gerencie os picos de tráfego com mais tranquilidade. Por padrão, o API Gateway pode lidar com até 10 mil solicitações por segundo por região, com uma capacidade de expansão de 5 mil solicitações por segundo. Ele também fornece ferramentas para solicitações de controle de utilização em diferentes níveis (API, estágio ou método) para proteger seu backend. ### Monitoramento + Os **URLs de funções** oferecem monitoramento básico por meio de métricas do Amazon CloudWatch, incluindo contagem de solicitações, latência e taxas de erro. Você tem acesso às métricas e logs padrão do Lambda, que mostram as solicitações brutas que chegam à sua função. Embora isso forneça visibilidade operacional essencial, as métricas se concentram principalmente na execução da função. + O **API Gateway** fornece recursos abrangentes de monitoramento, incluindo métricas detalhadas, geração de logs e opções de rastreamento. Você pode monitorar chamadas de API, latência, taxas de erro e taxas de acerto/erro de cache por meio do CloudWatch. O API Gateway também se integra ao AWS X-Ray para rastreamento distribuído e fornece formatos de logs personalizáveis. ### Custo + Os **URLs de funções** seguem o modelo de preços padrão do Lambda: você paga somente pelas invocações de funções e pelo tempo de computação. Não há cobranças adicionais pelo endpoint do URL em si. Isso o torna uma opção econômica para APIs simples ou aplicações com pouco tráfego, caso você não precise dos recursos adicionais do API Gateway. + O **API Gateway** oferece um [nível gratuito](https://aws.amazon.com/api-gateway/pricing/#Free_Tier) que inclui um milhão de chamadas de API recebidas para APIs REST e um milhão de chamadas de API recebidas para APIs HTTP. Depois disso, o API Gateway cobra por chamadas de API, transferência de dados e armazenamento em cache (se habilitado). Consulte a [página de preços](https://aws.amazon.com/api-gateway/pricing/) do API Gateway para entender os custos do seu próprio caso de uso. ### Outros recursos + Os **URLs de funções** são projetados para oferecer simplicidade e integração direta com o Lambda. Eles são compatíveis com endpoints HTTP e HTTPS, oferecem suporte CORS integrado e fornecem endpoints de pilha dupla (IPv4 e IPv6). Embora não tenham recursos avançados, eles se destacam em cenários em que você precisa de uma forma rápida e direta de expor as funções do Lambda via HTTP. + O **API Gateway** inclui vários recursos adicionais, como versionamento de API, gerenciamento de estágios, chaves de API para planos de uso, documentação de API por meio do Swagger/OpenAPI, APIs de WebSocket, APIs privadas em uma VPC e integração com WAF para segurança extra. Ele também oferece suporte a implantações canário, integrações simuladas para testes e integração com outros Serviços da AWS além do Lambda. ## Seleção de um método para invocar a função do Lambda Agora que você conhece os critérios para escolher entre URLs de funções do Lambda e o API Gateway, bem como as principais diferenças entre eles, você poderá selecionar a opção que melhor atende às suas necessidades e usar os recursos a seguir para ajudar a começar a usá-la. ------ #### [ Function URLs ] **Conceitos básicos para usar URLs de funções com os recursos abaixo** + Siga o tutorial [Criar uma função do Lambda com um URL de função](urls-webhook-tutorial.md) + Saiba mais sobre URLs de funções no capítulo [Criar e gerenciar URLs de função do Lambda](urls-configuration.md) deste guia + Experimente o tutorial guiado no console **Criar um aplicativo Web simples** fazendo o seguinte: 1. Abra a [página de funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Abra o painel de ajuda escolhendo o ícone no canto superior direito da tela. ![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/console_help_screenshot.png) 1. Selecione **Tutoriais**. 1. Em **Criar um aplicativo Web simples**, escolha **Iniciar tutorial**. ------ #### [ API Gateway ] **Conceitos básicos para usar o Lambda e o API Gateway com os recursos abaixo** + Siga o tutorial [Uso do Lambda com API Gateway](services-apigateway-tutorial.md) para criar uma API REST integrada a uma função do Lambda de backend. + Saiba mais sobre os diferentes tipos de API oferecidos pelo API Gateway nas seguintes seções do *Guia do desenvolvedor do Amazon API Gateway*: + [APIs REST do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) + [APIs HTTP do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html) + [APIs de WebSocket do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api.html) + Experimente um ou mais dos exemplos na seção [Tutoriais e workshops](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-tutorials.html) do *Guia do desenvolvedor do Amazon API Gateway*. ------ # Tutorial: criar um endpoint de webhook usando um URL de função do Lambda Neste tutorial, você cria um URL de função do Lambda para implementar um endpoint de webhook. Um webhook é uma comunicação leve e orientada por eventos que envia dados automaticamente entre aplicações usando HTTP. Você pode usar um webhook para receber atualizações imediatas sobre eventos que acontecem em outro sistema, como quando um novo cliente se cadastra em um site, um pagamento é processado ou um arquivo é carregado. Com o Lambda, os webhooks podem ser implementados usando URLs de funções do Lambda ou API Gateway. URLs de funções são uma boa opção para webhooks simples que não exigem atributos como autorização avançada ou validação de solicitações. **dica** Se não tiver certeza de qual é a melhor solução para seu caso de uso, consulte [Seleção de um método para invocar a função do Lambda usando uma solicitação HTTP](furls-http-invoke-decision.md). ## Pré-requisitos Para concluir este tutorial, você deve ter Python (versão 3.8 ou posterior) ou Node.js (versão 18 ou posterior) instalado em sua máquina local. Para testar o endpoint usando uma solicitação HTTP, o tutorial usa [curl](https://curl.se/), uma ferramenta de linha de comando que você pode usar para transferir dados usando vários protocolos de rede. Consulte a [documentação do curl](https://curl.se/docs/install.html) para saber como instalar a ferramenta, caso ainda não o tenha. ## Criar a função do Lambda Primeiro, crie a função do Lambda que será executada quando uma solicitação HTTP for enviada para seu endpoint de webhook. Neste exemplo, a aplicação de envio envia uma atualização sempre que um pagamento é enviado e indica no corpo da solicitação HTTP se o pagamento foi bem-sucedido. A função do Lambda analisa a solicitação e age de acordo com o status do pagamento. Neste exemplo, o código apenas imprime o ID do pedido para o pagamento, mas em uma aplicação real, você pode adicionar o pedido a um banco de dados ou enviar uma notificação. A função também implementa o método de autenticação mais comum usado para webhooks, a autenticação de mensagens baseada em hash (HMAC). Com esse método, as aplicações de envio e recebimento compartilham uma chave secreta. A aplicação de envio usa um algoritmo de hash para gerar uma assinatura exclusiva usando essa chave junto com o conteúdo da mensagem e inclui a assinatura na solicitação do webhook como um cabeçalho HTTP. A aplicação recebedora então repete essa etapa, gerando a assinatura usando a chave secreta, e compara o valor resultante com a assinatura enviada no cabeçalho da solicitação. Se o resultado corresponder, a solicitação será considerada legítima. Crie a função usando o console do Lambda com o runtime do Python ou do Node.js. ------ #### [ Python ] **Criar a função do Lambda** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Crie uma função básica "Hello world" fazendo o seguinte: 1. Escolha a opção **Criar função**. 1. Selecione **Criar do zero**. 1. Em **Function name** (Nome da função), insira **myLambdaWebhook**. 1. Em **Runtime**, escolha **Python3.14**. 1. Escolha a opção **Criar função**. 1. No painel **Código-fonte**, substitua o código existente copiando e colando o seguinte: ``` import json import hmac import hashlib import os def lambda_handler(event, context): # Get the webhook secret from environment variables webhook_secret = os.environ['WEBHOOK_SECRET'] # Verify the webhook signature if not verify_signature(event, webhook_secret): return { 'statusCode': 401, 'body': json.dumps({'error': 'Invalid signature'}) } try: # Parse the webhook payload payload = json.loads(event['body']) # Handle different event types event_type = payload.get('type') if event_type == 'payment.success': # Handle successful payment order_id = payload.get('orderId') print(f"Processing successful payment for order {order_id}") # Add your business logic here # For example, update database, send notifications, etc. elif event_type == 'payment.failed': # Handle failed payment order_id = payload.get('orderId') print(f"Processing failed payment for order {order_id}") # Add your business logic here else: print(f"Received unhandled event type: {event_type}") # Return success response return { 'statusCode': 200, 'body': json.dumps({'received': True}) } except json.JSONDecodeError: return { 'statusCode': 400, 'body': json.dumps({'error': 'Invalid JSON payload'}) } except Exception as e: print(f"Error processing webhook: {e}") return { 'statusCode': 500, 'body': json.dumps({'error': 'Internal server error'}) } def verify_signature(event, webhook_secret): """ Verify the webhook signature using HMAC """ try: # Get the signature from headers signature = event['headers'].get('x-webhook-signature') if not signature: print("Error: Missing webhook signature in headers") return False # Get the raw body (return an empty string if the body key doesn't exist) body = event.get('body', '') # Create HMAC using the secret key expected_signature = hmac.new( webhook_secret.encode('utf-8'), body.encode('utf-8'), hashlib.sha256 ).hexdigest() # Compare the expected signature with the received signature to authenticate the message is_valid = hmac.compare_digest(signature, expected_signature) if not is_valid: print(f"Error: Invalid signature. Received: {signature}, Expected: {expected_signature}") return False return True except Exception as e: print(f"Error verifying signature: {e}") return False ``` 1. Na seção **DEPLOY**, escolha **Implantar** para atualizar o código da função. ------ #### [ Node.js ] **Criar a função do Lambda** 1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda. 1. Crie uma função básica "Hello world" fazendo o seguinte: 1. Escolha a opção **Criar função**. 1. Selecione **Criar do zero**. 1. Em **Function name** (Nome da função), insira **myLambdaWebhook**. 1. Em **Runtime**, selecione **nodejs24.x**. 1. Escolha a opção **Criar função**. 1. No painel **Código-fonte**, substitua o código existente copiando e colando o seguinte: ``` import crypto from 'crypto'; export const handler = async (event, context) => { // Get the webhook secret from environment variables const webhookSecret = process.env.WEBHOOK_SECRET; // Verify the webhook signature if (!verifySignature(event, webhookSecret)) { return { statusCode: 401, body: JSON.stringify({ error: 'Invalid signature' }) }; } try { // Parse the webhook payload const payload = JSON.parse(event.body); // Handle different event types const eventType = payload.type; switch (eventType) { case 'payment.success': { // Handle successful payment const orderId = payload.orderId; console.log(`Processing successful payment for order ${orderId}`); // Add your business logic here // For example, update database, send notifications, etc. break; } case 'payment.failed': { // Handle failed payment const orderId = payload.orderId; console.log(`Processing failed payment for order ${orderId}`); // Add your business logic here break; } default: console.log(`Received unhandled event type: ${eventType}`); } // Return success response return { statusCode: 200, body: JSON.stringify({ received: true }) }; } catch (error) { if (error instanceof SyntaxError) { // Handle JSON parsing errors return { statusCode: 400, body: JSON.stringify({ error: 'Invalid JSON payload' }) }; } // Handle all other errors console.error('Error processing webhook:', error); return { statusCode: 500, body: JSON.stringify({ error: 'Internal server error' }) }; } }; // Verify the webhook signature using HMAC const verifySignature = (event, webhookSecret) => { try { // Get the signature from headers const signature = event.headers['x-webhook-signature']; if (!signature) { console.log('No signature found in headers:', event.headers); return false; } // Get the raw body (return an empty string if the body key doesn't exist) const body = event.body || ''; // Create HMAC using the secret key const hmac = crypto.createHmac('sha256', webhookSecret); const expectedSignature = hmac.update(body).digest('hex'); // Compare expected and received signatures const isValid = signature === expectedSignature; if (!isValid) { console.log(`Invalid signature. Received: ${signature}, Expected: ${expectedSignature}`); return false; } return true; } catch (error) { console.error('Error during signature verification:', error); return false; } }; ``` 1. Na seção **DEPLOY**, escolha **Implantar** para atualizar o código da função. ------ ## Criar a chave secreta Para que a função do Lambda autentique a solicitação do webhook, ela usa uma chave secreta que compartilha com a aplicação de chamada. Neste exemplo, a chave é armazenada em um variável de ambiente. Não inclua informações confidenciais, como senhas, no código de função, em uma aplicação em produção. Em vez disso, [crie um segredo do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html) e [use a extensão do Lambda AWS Parameters and Secrets](with-secrets-manager.md) para recuperar suas credenciais na função do Lambda. **Criar e armazenar a chave secreta do webhook** 1. Gere uma string longa e aleatória usando um gerador de números aleatórios criptograficamente seguro. Você pode usar os seguintes trechos de código em Python ou Node.js para gerar e imprimir um segredo de 32 caracteres, ou usar seu próprio método preferido. ------ #### [ Python ] **Example código para gerar um segredo** ``` import secrets webhook_secret = secrets.token_urlsafe(32) print(webhook_secret) ``` ------ #### [ Node.js ] **Example código para gerar um segredo (formato de módulo ES)** ``` import crypto from 'crypto'; let webhookSecret = crypto.randomBytes(32).toString('base64'); console.log(webhookSecret) ``` ------ 1. Armazene sua string gerada como uma variável de ambiente para sua função fazendo o seguinte: 1. Na guia **Configurações** para sua função, selecione **Variáveis de ambiente**. 1. Escolha **Editar**. 1. Escolha **Add environment variable (Adicionar variável de ambiente)**. 1. Para **Chave**, insira **WEBHOOK\$1SECRET**, e para **Valor**, insira o segredo que você gerou na etapa anterior. 1. Escolha **Salvar**. Você precisará usar esse segredo novamente em outro momento no tutorial para testar sua função, então anote-o agora. ## Criar o endpoint do URL da função Criar um endpoint para seu webhook usando um URL da função do Lambda. Como você usa o tipo de autenticação `NONE` para criar um endpoint com acesso público, qualquer pessoa com o URL pode invocar sua função. Para saber mais sobre como controlar o acesso aos URLs das funções, consulte [Controlar o acesso aos URLs de função do Lambda](urls-auth.md). Se você precisar de opções de autenticação mais avançadas para seu webhook, considere usar o API Gateway. **Criar o endpoint do URL da função** 1. Na guia **Configuração** para sua função, selecione **URL da função**. 1. Escolha **Create function URL** (Criar URL de função). 1. Para **Tipo de autenticação**, selecione **NONE**. 1. Escolha **Salvar**. O endpoint do URL da função que você acabou de criar é exibido no painel **URL da função**. Copie o endpoint para usar posteriormente no tutorial. ## Testar a função no console Antes de usar uma solicitação HTTP para invocar sua função usando o endpoint do URL, teste-a no console para confirmar se o código está funcionando conforme o esperado. Para verificar a função no console, primeiro calcule uma assinatura de webhook usando o segredo gerado anteriormente no tutorial com a seguinte carga útil JSON de teste: ``` { "type": "payment.success", "orderId": "1234", "amount": "99.99" } ``` Use um dos exemplos de código Python ou Node.js a seguir para calcular a assinatura do webhook usando seu próprio segredo. ------ #### [ Python ] **Calcular a assinatura do webhook** 1. Salve o código a seguir como um arquivo chamado `calculate_signature.py`. Substitua o segredo do webhook no código pelo seu próprio valor. ``` import secrets import hmac import json import hashlib webhook_secret = "arlbSDCP86n_1H90s0fL_Qb2NAHBIBQOyGI0X4Zay4M" body = json.dumps({"type": "payment.success", "orderId": "1234", "amount": "99.99"}) signature = hmac.new( webhook_secret.encode('utf-8'), body.encode('utf-8'), hashlib.sha256 ).hexdigest() print(signature) ``` 1. Calcule a assinatura executando o comando a seguir no diretório onde você salvou o código. Copie a assinatura que o código gera. ``` python calculate_signature.py ``` ------ #### [ Node.js ] **Calcular a assinatura do webhook** 1. Salve o código a seguir como um arquivo chamado `calculate_signature.mjs`. Substitua o segredo do webhook no código pelo seu próprio valor. ``` import crypto from 'crypto'; const webhookSecret = "arlbSDCP86n_1H90s0fL_Qb2NAHBIBQOyGI0X4Zay4M" const body = "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}"; let hmac = crypto.createHmac('sha256', webhookSecret); let signature = hmac.update(body).digest('hex'); console.log(signature); ``` 1. Calcule a assinatura executando o comando a seguir no diretório onde você salvou o código. Copie a assinatura que o código gera. ``` node calculate_signature.mjs ``` ------ Agora você pode testar o código da função usando uma solicitação HTTP de teste no console. **Testar a função no console** 1. Selecione a guia **Code** para sua função. 1. Na seção **TEST EVENTS**, selecione **Create new test event** 1. Em **Event Name (Nome do evento)**, insira **myEvent**. 1. Substitua o JSON existente copiando e colando o seguinte no painel **JSON do evento**. Substitua a assinatura do webhook pelo valor calculado na etapa anterior. ``` { "headers": { "Content-Type": "application/json", "x-webhook-signature": "2d672e7a0423fab740fbc040e801d1241f2df32d2ffd8989617a599486553e2a" }, "body": "{\"type\": \"payment.success\", \"orderId\": \"1234\", \"amount\": \"99.99\"}" } ``` 1. Escolha **Salvar**. 1. Escolha **Invoke (Invocar)**. Você deve ver uma saída semelhante a: ------ #### [ Python ] ``` Status: Succeeded Test Event Name: myEvent Response: { "statusCode": 200, "body": "{\"received\": true}" } Function Logs: START RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 Version: $LATEST Processing successful payment for order 1234 END RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 REPORT RequestId: 50cc0788-d70e-453a-9a22-ceaa210e8ac6 Duration: 1.55 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 36 MB Init Duration: 136.32 ms ``` ------ #### [ Node.js ] ``` Status: Succeeded Test Event Name: myEvent Response: { "statusCode": 200, "body": "{\"received\":true}" } Function Logs: START RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 Version: $LATEST 2025-01-10T18:05:42.062Z e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 INFO Processing successful payment for order 1234 END RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 REPORT RequestId: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 Duration: 60.10 ms Billed Duration: 61 ms Memory Size: 128 MB Max Memory Used: 72 MB Init Duration: 174.46 ms Request ID: e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 ``` ------ ## Testar a função usando uma solicitação HTTP Use a ferramenta de linha de comando curl para testar seu endpoint de webhook. **Testar a função usando solicitações HTTP** 1. Em um terminal ou programa shell, execute o seguinte comando curl. Substitua o URL pelo valor do endpoint do URL da sua própria função e substitua a assinatura do webhook pela assinatura que você calculou usando sua própria chave secreta. ``` curl -X POST https://ryqgmbx5xjzxahif6frvzikpre0bpvpf.lambda-url.us-west-2.on.aws/ \ -H "Content-Type: application/json" \ -H "x-webhook-signature: d5f52b76ffba65ff60ea73da67bdf1fc5825d4db56b5d3ffa0b64b7cb85ef48b" \ -d '{"type": "payment.success", "orderId": "1234", "amount": "99.99"}' ``` A seguinte saída deverá ser mostrada: ``` {"received": true} ``` 1. Inspecione os logs do CloudWatch da sua função para confirmar se ela analisou a carga útil corretamente, fazendo o seguinte: 1. No console do Amazon CloudWatch, abra a página [Grupo de logs](https://console.aws.amazon.com/cloudwatch/home#logsV2:log-groups). 1. Selecione o grupo de logs da função (`/aws/lambda/myLambdaWebhook`). 1. Selecione o stream de logs mais recente. Você deve ver uma saída semelhante à seguinte nos logs da sua função: ------ #### [ Python ] ``` Processing successful payment for order 1234 ``` ------ #### [ Node.js ] ``` 2025-01-10T18:05:42.062Z e54fe6c7-1df9-4f05-a4c4-0f71cacd64f4 INFO Processing successful payment for order 1234 ``` ------ 1. Confirme se seu código detecta uma assinatura inválida executando o seguinte comando curl. Substitua o URL pelo endpoint do URL da sua própria função. ``` curl -X POST https://ryqgmbx5xjzxahif6frvzikpre0bpvpf.lambda-url.us-west-2.on.aws/ \ -H "Content-Type: application/json" \ -H "x-webhook-signature: abcdefg" \ -d '{"type": "payment.success", "orderId": "1234", "amount": "99.99"}' ``` A seguinte saída deverá ser mostrada: ``` {"error": "Invalid signature"} ``` ## Limpe os recursos Agora você pode excluir os recursos criados para este tutorial, a menos que queira mantê-los. Excluindo os recursos da AWS que você não está mais usando, você evita cobranças desnecessárias em sua Conta da AWS. **Como excluir a função do Lambda** 1. Abra a página [Functions](https://console.aws.amazon.com/lambda/home#/functions) (Funções) no console do Lambda. 1. Selecione a função que você criou. 1. Selecione **Actions**, **Delete**. 1. Digite **confirm** no campo de entrada de texto e escolha **Delete** (Excluir). Quando você cria uma função do Lambda no console, o Lambda também cria um [perfil de execução](lambda-intro-execution-role.md) para essa função. **Para excluir a função de execução** 1. Abra a página [Roles](https://console.aws.amazon.com/iam/home#/roles) (Funções) no console do IAM. 1. Selecione o perfil de execução que o Lambda criou. O perfil tem o formato de nome `myLambdaWebhook-role-`. 1. Escolha **Excluir**. 1. Insira o nome do perfil no campo de entrada de texto e escolha **Delete** (Excluir).