Summary

  • A AWS permite que uma conta participante na mesma organização coloque EC2, RDS, Redshift e Lambda em sub-redes de uma VPC pertencente a outra conta. O participante paga esses recursos e as transferências especificadas entre zonas de disponibilidade, por peering, gateway de internet e Direct Connect.
  • A conta proprietária paga pelos IPv4 públicos usados na VPC compartilhada e pelas cobranças aplicáveis de NAT, PrivateLink e endpoints. Encerrar o compartilhamento impede novas criações do participante, mas os recursos existentes continuam funcionando e impedem a exclusão da sub-rede ou VPC enquanto não forem retirados.

Dois centros de custo no mesmo endereço

Compartilhar a sub-rede dentro de uma organização AWS permite que o time central mantenha uma VPC e que outros times executem aplicações com suas próprias contas. A descrição parece prometer simplicidade administrativa. A tabela de cobrança mostra outra divisão: instâncias EC2, bancos RDS, clusters Redshift e funções Lambda pertencem financeiramente ao participante. Endereços IPv4 públicos usados nessa VPC aparecem para o proprietário. O time que contratou o servidor pode não enxergar no próprio extrato o custo do endereço que o acompanha.

O caminho do tráfego também tem pagadores diferentes. A AWS atribui ao participante transferências entre zonas de disponibilidade, por peering de VPC, gateways de internet e Direct Connect. Atribui ao proprietário taxas aplicáveis por hora, processamento e transferência em gateways NAT, gateways privados virtuais, transit gateways, PrivateLink e endpoints da VPC. Assim, uma aplicação pode gerar uma linha de transferência na conta participante e outra ligada ao gateway central na conta proprietária. A comparação entre produtos internos fica distorcida quando só se olha o custo de computação.

A mesma documentação oferece um marco concreto para analisar o trajeto. Transferência dentro da mesma zona de disponibilidade, definida pelo AZ ID, é gratuita independentemente do dono das contas. Se a aplicação passa a cruzar esse limite, o custo pode mudar sem que a quantidade de servidores mude. A regra publicada não revela o valor da conta de nenhuma empresa; esse cálculo depende dos registros de uso e da topologia implantada.

Quem pode mexer no NAT não é quem usa cada aplicação

O dono da VPC cria e controla sub-redes, tabelas de rota, gateways NAT e endpoints. Participantes podem cuidar das próprias interfaces de rede e grupos de segurança, mas não podem criar, apagar ou sequer descrever gateways NAT na sub-rede compartilhada. A AWS concentra a alavanca de rede em quem recebe as cobranças centrais. Ocorre que os participantes escolhem as aplicações e podem aumentar a demanda sobre essa infraestrutura. É aí que um acordo interno de preço deixa de ser uma formalidade.

O IPv4 público dá uma referência simples. A página de preços VPC da AWS lista US$ 0,005 por endereço e por hora, tanto para endereços em uso quanto ociosos, com apuração por segundo e mínimo de 60 segundos. No caso da VPC compartilhada, a página específica atribui esses endereços ao proprietário. O gasto real de uma empresa só aparece quando endereços por participante são conciliados com a fatura da conta dona da rede. Não há fatura ou contagem de cliente identificada nas fontes públicas.

Descompartilhar não apaga o morador

O proprietário pode parar de compartilhar a sub-rede. O participante perde a capacidade de criar recursos novos ali, mas os antigos continuam em operação e ainda podem ser modificados ou excluídos por ele. Enquanto existirem recursos do participante, o dono não pode excluir a sub-rede nem a VPC compartilhada. A decisão de encerrar o convite não retira automaticamente uma carga de produção.

A empresa precisa combinar o preço interno do endereço, o rateio dos gateways e a ordem de saída antes de instalar mais um time. Caso contrário, o time de aplicação mostra uma conta baixa, o time de rede mostra uma conta alta, e as duas contas estão corretas. O erro está no modelo de responsabilidade entre elas.

Fontes