O requerente paga

Configuração

Esta página oferece uma vista geral da funcionalidade Requester Pays para o Cloud Storage.

Introdução

Sempre que um utilizador acede a um recurso do Cloud Storage, como um contentor ou um objeto, existem custos associados à criação e execução do pedido.

Normalmente, o proprietário do projeto do recurso é faturado por estas cobranças; no entanto, se o requerente fornecer um projeto de faturação com o seu pedido, o projeto do requerente é faturado. Com a funcionalidade "O requerente paga" ativada no seu contentor, pode exigir que os requerentes incluam um projeto de faturação nos respetivos pedidos, faturando assim o projeto do requerente. A ativação da funcionalidade "O requerente paga" é útil, por exemplo, se tiver muitos dados que quer disponibilizar aos utilizadores, mas não quer que lhe seja cobrado o acesso a esses dados.

Restrições

Aplicam-se as seguintes restrições quando usa a funcionalidade Requester Pays:

  • Não pode usar um contentor com a funcionalidade Requester Pays ativada para importações e exportações do Cloud SQL.
  • Não pode usar um contentor com a funcionalidade Requester Pays ativada para exportações do Pub/Sub.

Requisitos de utilização e acesso

Para ativar a funcionalidade Requester Pays num contentor, ative a flag de metadados no contentor. Depois de ativado, apenas os seguintes utilizadores podem aceder ao contentor ou ao respetivo conteúdo:

  • Os requerentes que incluem um projeto de faturação no respetivo pedido. O projeto usado no pedido tem de estar em conformidade, e o utilizador tem de ter uma função no projeto que contenha a autorização serviceusage.services.use. A função Utilizador do consumo de serviços contém a autorização necessária.

  • Os requerentes que não incluem um projeto de faturação, mas têm autorização resourcemanager.projects.createBillingAssignment para o projeto que contém o contentor. A função de gestor do projeto de faturação contém a autorização necessária. As taxas de acesso associadas a estes pedidos são faturadas ao projeto que contém o contentor.

Todos os outros pedidos ao contentor falham com um erro 400 UserProjectMissing.

Além destes requisitos, o requerente tem de ter autorização suficiente para realizar a ação pedida. Por exemplo, um utilizador que fornece um projeto de faturação válido no respetivo pedido não pode carregar objetos para o contentor, a menos que também tenha autorização explícita para o fazer, como ter a autorização storage.objects.create para esse contentor ou o projeto que o contém.

Quando desativa a funcionalidade O requerente paga, tem de incluir um projeto de faturação no seu pedido ou ter a autorização resourcemanager.projects.createBillingAssignment.

Operações faturadas na origem

As operações que têm um contentor de origem e um contentor de destino, como uma cópia ou uma reescrita, são cobradas ao projeto que contém o contentor de origem. Na maioria dos casos, como chamadas diretas através das APIs JSON e XML, só precisa de incluir um projeto de faturação se o contentor de origem tiver o Requester Pays ativado.

Em alguns casos, como gcloud storage cp com uma flag --no-clobber, tem de incluir um projeto de faturação se o contentor de origem ou o contentor de destino (ou ambos) tiverem o Requester Pays ativado. Isto deve-se ao facto de essas operações fazerem chamadas para os contentores de origem e de destino durante a execução da ação.

Operações de vários pedidos

Para operações que requerem vários pedidos para serem concluídas, a utilização de projetos de faturação nos seus pedidos tem os seguintes comportamentos:

O que se segue?