Uma listagem, várias entidades jurídicas: subsidiárias no AWS Marketplace

Num grupo com uma entidade nos EUA, uma Ltda no Brasil e uma subsidiária na Índia, o motivo de ter três contas vendedoras não é técnico, é fiscal. Cada entidade precisa ser seller of record no seu mercado: segura o contrato com o cliente, fatura na moeda local, paga as próprias taxas do Marketplace e recebe na própria conta bancária. A documentação deixa isso explícito, e a funcionalidade nova não muda essa premissa. Ela só remove a obrigação de manter o produto dentro de cada conta.

O custo que pesava não era criar a listagem. Era manter três cópias sincronizadas por anos: cada dimensão de preço nova, cada ajuste de descrição, cada versão do produto multiplicada pelo número de entidades, e cada divergência descoberta por um cliente antes de ser descoberta por você. Esse é o custo de manutenção que a funcionalidade ataca, e ele é real.

O que ela coloca no lugar merece o mesmo cuidado. A conta primária passa a emitir autorizações, uma por produto e por subsidiária, dizendo em quais países e com quais dimensões de preço aquela entidade pode vender. Isso é controle de acesso sobre receita. Em ambiente regulado, qualquer coisa que decide quem vende o quê, para quem e onde cai no mesmo balde de um IAM role: precisa de dono, de trilha de auditoria e de revisão periódica.

Um detalhe que encurta o otimismo de quem já tem listagens duplicadas: agreements vivos numa listagem própria da subsidiária ficam nela e não podem ser movidos para o produto da primária. A migração vale para ofertas novas, não para a base instalada. Você vai conviver com os dois modelos até o último contrato antigo vencer.

A autorização tem duas camadas, e confundir uma com a outra é o primeiro erro que eu esperaria ver em produção.

Conexão: feita no AWS Partner Central. A primária envia o pedido, com até 10 IDs de conta por envio, e um administrador da subsidiária aceita. O aceite tem um efeito colateral que precisa passar pelo jurídico: ele registra o consentimento da subsidiária em compartilhar receita atribuída e os relatórios do Marketplace insights com a primária. A conexão sozinha não autoriza venda nenhuma.

Autorização: uma entidade SubsidiaryAuthorization@1.0 no Catalog API, criada pela primária com StartChangeSet e a change type CreateSubsidiaryAuthorization. Ela nasce em Draft, vira Active com UpdateAvailability e termina em Restricted. Carrega o ARN do produto (imutável), a lista de Dimensions, o SubsidiaryAccountId (também imutável, vira a SubsidiaryTargetingRule) e um BuyerTargetingTerm com CountryCodes e OfferTargeting, que hoje aceita só PrivateOffer.

Service role: as duas contas precisam do AWSMarketplaceSubsidiaryAuthorizationServiceRole, que a AWS usa para criar o resource share entre elas. Sem ele, pelo console a autorização é criada e nunca fica ativa, e a subsidiária não enxerga nada. Pela API o erro aparece como INCOMPATIBLE_ACCOUNT_STATE na primária ou INCOMPATIBLE_SUBSIDIARY_ACCOUNT_STATE na subsidiária, e só no DescribeChangeSet, porque a validação é assíncrona.

IAM das pessoas: separado do service role, e você precisa dos dois. Para autorizar, a primária usa AWSMarketplaceSellerFullAccess ou AWSMarketplaceSellerProductsFullAccess; para criar oferta pela página de ofertas privadas, a subsidiária usa AWSMarketplaceSellerOfferManagement. Essas managed policies são largas. Em produção eu escreveria policy própria, restrita às ações do Catalog API que cada time de fato usa.

O anúncio diz que revogar a autorização impede imediatamente a subsidiária de criar ofertas novas. Correto, e incompleto para quem desenha controle. A documentação detalha quatro comportamentos que mudam o runbook.

Oferta publicada sobrevive: revogar não cancela ofertas já publicadas. O comprador ainda pode aceitar uma oferta que a subsidiária publicou antes da revogação, e os agreements existentes seguem pelos termos acordados, com renovações e desembolsos para a subsidiária. Se o motivo da revogação é a venda da entidade, uma restrição num país ou uma disputa societária, o bloqueio não alcança a exposição que já está na rua.

Restricted é terminal: não existe reativação. Para autorizar de novo, crie outra autorização, que ganha outro ID. Qualquer sistema que use o ID da autorização como chave de negócio quebra na primeira revogação por engano.

Conexão derruba tudo: encerrar a conexão no Partner Central encerra todas as autorizações entre as duas contas. Um analista que desfaz a conexão para corrigir atribuição de receita derruba a capacidade de venda da entidade inteira.

Estreitar quebra rascunho: remover um país ou uma dimensão faz falhar a publicação de ofertas em draft que usavam aquele escopo. A oferta fica parada e o vendedor local só descobre na hora de publicar, em geral na véspera do fechamento do trimestre.

A lição prática: revogação é um processo, não um clique. Revogue a autorização, levante as ofertas publicadas e ainda não aceitas daquela subsidiária, decida o destino de cada uma e só então mexa na conexão. Para encurtar a janela de exposição, use datas de expiração curtas nas ofertas privadas que as subsidiárias publicam.

Com mais de duas subsidiárias, autorização feita no console vira deriva em semanas. O Catalog API permite tratar cada autorização como recurso versionado, e três detalhes tornam isso obrigatório, não estético.

Substituição total: UpdateInformation substitui Name, Description, Resource e Terms inteiros; o que você omitir é removido. A validação síncrona devolve 422 se Dimensions vier vazio, mas um BuyerTargetingTerm sem CountryCodes passa, e lista vazia significa todos os países. Um script que só queria trocar a descrição pode abrir a venda da entidade brasileira para o mundo inteiro. A única forma segura é enviar sempre o estado completo, lido de um arquivo versionado.

O default está do lado errado: a elegibilidade do comprador é avaliada pelo endereço fiscal dele. Uma autorização sem países contradiz a premissa fiscal que justificou criar a entidade local. No pipeline, eu bloquearia merge de qualquer autorização com CountryCodes vazio.

Produto não propaga: adicionar uma dimensão ao produto não chega à subsidiária; é preciso chamar UpdateInformation com a lista nova. Se o produto tem dimensões Metered ou ExternallyMetered, todas precisam estar na autorização, senão a change set falha com INCOMPATIBLE_PRODUCT_DIMENSIONS.

O resto é idempotência e observabilidade. StartChangeSet é assíncrono: guarde o ChangeSetId, consulte DescribeChangeSet até SUCCEEDED ou FAILED e leia o ErrorDetailList. Duas autorizações para o mesmo produto e a mesma subsidiária não podem sobrepor países e dimensões (DUPLICATE_SUBSIDIARY_AUTHORIZATION), o que dá uma chave natural para o seu estado: produto, subsidiária e conjunto de países, não o ID. Reconcilie todo dia com ListEntities usando EntityType: SubsidiaryAuthorization e compare com o repositório.