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 cobranças associadas à criação e execução do pedido. Essas cobranças incluem:
Custos de tratamento de dados para operações, replicação e obtenção de dados.
Custos de utilização da rede para ler os dados.
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.
Cobranças não abrangidas
As taxas de armazenamento de dados, incluindo taxas de eliminação antecipada, são sempre aplicadas ao projeto que contém o contentor, mesmo que a opção "O requerente paga" esteja ativada.
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 a funcionalidade Requester Pays ativada. 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:
Para carregamentos retomáveis, apenas o primeiro pedido tem de incluir um projeto de faturação, e aplica-se a todo o carregamento. Os projetos de faturação especificados em pedidos subsequentes são ignorados.
Para reescritas com a API JSON e carregamentos multipartes da API XML, cada pedido pode usar um projeto de faturação diferente, e um projeto de faturação especificado num pedido anterior não se aplica a pedidos subsequentes.
Faturação
Os custos associados à inclusão de um projeto de faturação no seu pedido não
aparecem separadamente na sua faturação. Por exemplo, suponhamos que faz vários
transfers de um contentor Requester Pays e usa o projeto my-project
como o projeto a faturar pelo pedido. Se my-project
também contiver um contentor a partir do qual faz transferências, a fatura apenas mostra os encargos totais das transferências combinadas. Não distingue entre os downloads do seu próprio contentor e os do contentor Requester Pays.
Se quiser distinguir entre os encargos dos seus próprios recursos do Cloud Storage e os encargos da inclusão de projetos de faturação nos seus pedidos, deve criar um projeto que não contenha recursos do Cloud Storage. Deste modo, este projeto é dedicado a fazer pedidos a recursos noutros projetos, como contentores de pagamentos do requerente.
O que se segue?
- Saiba como usar o Requester Pays.
- Disponibilize os dados publicamente.