As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Alocação flexível de custos
Por padrão, o Transit Gateway usa um modelo de alocação de custos baseado no remetente, no qual as cobranças de processamento de dados são alocadas à conta proprietária do anexo de origem. Você pode criar políticas de medição personalizadas que definam quais contas devem ser cobradas com base nas propriedades do fluxo de tráfego, como tipos de anexos IDs, anexos específicos ou endereços de rede.
As políticas de medição consistem em regras ordenadas que são avaliadas do menor para o maior número de regras. Quando o tráfego corresponde a uma regra, a conta especificada é cobrada de acordo com a configuração da regra. Você pode especificar o responsável pela conta para alocar custos a partir das seguintes opções:
Proprietário do anexo de origem - As cobranças são alocadas à conta proprietária do anexo de origem (comportamento padrão)
Proprietário do anexo de destino - As cobranças são alocadas à conta proprietária do anexo de destino
Proprietário do Transit Gateway - As cobranças são alocadas à conta proprietária do Transit Gateway
A alocação flexível de custos permite um melhor gerenciamento de custos para organizações que usam arquiteturas de rede centralizadas, permitindo que os custos sejam alocados às unidades de negócios ou proprietários de aplicativos apropriados, independentemente da topologia da rede.
nota
A alocação flexível de custos permite a alocação flexível do uso da medição e, por sua vez, dos custos para os proprietários de contas de sua escolha. No entanto, as implicações fiscais para as AWS contas podem variar significativamente com base na localização geográfica, nos padrões de uso e em outros fatores. Analise as implicações de cobrança, impostos e gerenciamento de custos para contas em sua AWS organização antes de ativar esse recurso. Referência: O que é AWS Billing and Cost Management?
Políticas de medição
As políticas de medição permitem que você configure regras de alocação de custos para seu gateway de trânsito para controlar quais contas são cobradas pelo processamento de dados e custos de transferência com base nas propriedades do fluxo de tráfego. Esse recurso permite um melhor gerenciamento de custos e recursos de cobrança retroativa para organizações que usam arquiteturas de rede centralizadas.
Uma política de medição é composta pelo seguinte:
-
Política de medição - O contêiner de configuração geral que contém as regras da política de medição. Quando criado, ele contém uma única entrada de política de medição padrão que é configurada para cobrar todo o tráfego do proprietário do anexo de origem. Cada gateway de trânsito pode ter somente uma política de medição.
-
Entrada da política de medição - regras individuais dentro de uma política de medição que definem critérios de correspondência específicos e a conta para medir o uso. Cada entrada inclui um número de regra para a ordem de avaliação, condições de correspondência de tráfego (como tipos de anexo de origem e destino IDs, anexo, blocos CIDR, portas e protocolos) e qual proprietário da conta cobrar pelo tráfego correspondente. Uma política pode conter até 50 entradas, avaliadas em ordem do menor para o maior número de regras.
Você pode alocar o uso da medição para qualquer um dos seguintes:
-
Proprietário do anexo de origem: aloca o uso da medição para a conta proprietária do anexo de origem do tráfego (comportamento padrão)
-
Proprietário do anexo de destino: aloca o uso da medição para a conta proprietária do anexo em que o tráfego termina e
-
proprietário do gateway de trânsito: aloca o uso da medição para a conta proprietária do gateway de trânsito.
-
-
Anexos do Middlebox - (opcional) anexos de gateway de trânsito designados que roteiam o tráfego por meio de dispositivos de rede para inspeção de segurança, balanceamento de carga ou outras funções de rede. O uso de dados para o tráfego que atravessa os anexos do middlebox é medido ao proprietário da conta especificado na política de medição. Você pode especificar no máximo 10 anexos de caixa intermediária. Os tipos de anexo de middlebox compatíveis são anexos de Função de AWS Rede (Firewall de Rede), VPC e VPN.
Como as políticas de medição funcionam
Por padrão, o Transit Gateway usa um modelo de alocação de custos baseado no remetente, no qual as cobranças de processamento de dados são calculadas para a conta proprietária do anexo de origem. Com as políticas de medição, você pode criar regras personalizadas para medir com flexibilidade o uso com base nas seguintes propriedades do fluxo de tráfego:
Tipos de anexo de origem e destino (VPC, VPN, Direct Connect Gateway, Peering, Network Function e VPN Concentrator)
Anexo de origem e destino IDs
Endereços IP de origem e destino, intervalos de portas e protocolos
As políticas de medição consistem em regras ordenadas que são avaliadas do menor para o maior número de regras. Quando o tráfego corresponde a uma regra, a conta especificada é cobrada de acordo com a configuração da conta medida da regra. As políticas de medição abordam vários cenários organizacionais comuns:
-
Alocação de custos do ambiente híbrido: aloque os custos AWS da entrada de dados do local por meio do Direct Connect Gateway para o proprietário da conta VPC de destino, em vez do proprietário da conta de administrador de TI central.
-
Arquitetura de inspeção centralizada: aloque custos para proprietários individuais de aplicativos ou contas de VPC, em vez da equipe de segurança central, para tráfego atravessado por meio de inspeção. VPCs
-
Estorno baseado em aplicativos: aloque todos os custos de uso de dados de uma carga de trabalho para o proprietário da VPC, independentemente da direção do tráfego.
-
Alocação de custos do cliente: aloque os custos de dados às contas dos clientes quando eles criam anexos ao seu gateway de transporte público.
Anexos Middlebox
as políticas de medição de gateway de trânsito oferecem suporte a anexos do Middlebox, permitindo que você aloque com flexibilidade as taxas de processamento de dados para o tráfego de rede roteado por meio de dispositivos middlebox, como firewalls de rede e balanceadores de carga. Exemplos de anexos de middlebox são anexos de Função de Rede ao AWS Firewall de Rede ou anexos de VPC que roteiam o tráfego para dispositivos de segurança de terceiros em uma VPC. O tráfego entre os anexos do gateway de trânsito de origem e destino passa por esses anexos de middlebox para casos de uso típicos de inspeção de segurança. Você pode definir políticas de medição para alocar de forma flexível o uso do processamento de dados em anexos do middlebox ao anexo de origem original, ao anexo de destino final ou ao proprietário da conta do gateway de trânsito. Para anexos da Função de Rede, as cobranças de processamento de dados do Firewall de AWS Rede também são alocadas à conta limitada.
Alocação flexível de custos - tipos de uso de medição
A alocação flexível de custos por meio de políticas de medição se aplica aos seguintes tipos de uso de dados:
-
Uso do processamento de dados do Transit Gateway em anexos VPC, VPN, VPN Concentrator e Direct Connect
-
Site-to-site Uso de transferência de dados de VPN para fora em anexos de VPN
-
Uso da transferência de dados do Direct Connect em anexos do Direct Connect.
-
Uso da transferência de dados em anexos de emparelhamento TGW
-
Uso do processamento de dados do Transit Gateway em anexos da função de rede
-
AWS uso do processamento de dados do firewall de rede (NFW) em anexos da função de rede.
A alocação flexível de custos não se aplica ao uso horário de anexos e ao uso do processamento de dados multicast. Para anexos do Transit Gateway Connect, a política de medição pode ser definida para o anexo VPC de transporte ou Direct Connect subjacente. Para anexos VPN IP privados, a política de medição pode ser definida para o anexo subjacente do Direct Connect de transporte.
Considerações e limitações
Considere o seguinte ao implementar políticas de medição para seu gateway de trânsito.
Permissões
Somente o proprietário do gateway de trânsito pode criar, modificar ou excluir políticas de medição.
As configurações de alocação de custos se aplicam no nível do gateway de trânsito.
Os proprietários do anexo não podem substituir as configurações de alocação de custos definidas pelo proprietário do gateway de trânsito.
Emparelhamento do Transit Gateway
Quando o tráfego atravessa as conexões de emparelhamento do gateway de trânsito:
Cada gateway de trânsito aplica sua própria política de medição de forma independente.
As cobranças de dados são alocadas separadamente por cada gateway de trânsito com base em sua política local.
O tráfego pode ser considerado como dois fluxos separados: conexão de origem ao peering e peering ao anexo de destino.
Integração de WAN em nuvem
Quando um gateway de trânsito é conectado a uma rede principal do Cloud WAN:
As taxas de transferência de dados do Transit Gateway em conexões de peering são alocadas de acordo com a política de medição do Transit Gateway.
As políticas de medição não são suportadas nas redes principais do Cloud WAN.
Impacto no desempenho
As políticas de medição não introduzem nenhuma latência adicional no caminho de dados.
As políticas de medição não têm impacto na largura de banda máxima por anexo.
Não há alterações nos recursos de compartilhamento de recursos do gateway de trânsito.
Integração de faturamento
As etiquetas de alocação de custos continuam funcionando com políticas de medição para organizar os custos por unidade de negócios.
As políticas de medição definem quais contas incorrem em custos, enquanto as etiquetas de alocação de custos ajudam a categorizar esses custos.
As alterações nas políticas de medição entrarão em vigor no final da próxima hora de cobrança.
IPv6 apoio
As políticas de medição são suportadas tanto para o tráfego IPv4 quanto para o IPv6 tráfego. A correspondência de blocos CIDR nas entradas de política funciona com ambas as famílias de endereços.
Suporte de anexo Middlebox
-
A política de medição da caixa intermediária pressupõe que o tráfego entre o anexo original de origem e o de destino seja fixado por meio do anexo da caixa intermediária especificado (exemplo, inspeção leste-oeste do tráfego). VPC-to-VPC Portanto, a rede de 5 tuplas (source/destination IPs, source/destinationportas e protocolo) para fluxos que entram e saem dos anexos intermediários deve corresponder. Fluxos com incompatibilidades de 5 tuplas em anexos de caixa intermediária (por exemplo, transformação NAT na VPC de inspeção) são tratados como fluxos regulares de anexos de origem e destino (em oposição aos fluxos de anexos de caixa intermediária).
-
Todos os fluxos somente de saída no anexo da caixa intermediária (por exemplo, tráfego norte-sul para a Internet via IGW em uma VPC de inspeção) são tratados como fluxos regulares de origem e destino (em oposição aos fluxos de conexão da caixa intermediária).
-
Para anexos da função de rede quando o firewall de AWS rede descarta pacotes, todo o uso do processamento de dados é cobrado de volta na conta do remetente, independentemente da configuração da política de medição.
Tópicos
