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á.
Anexos do Amazon VPC em AWS Gateway de trânsito
Um anexo Amazon Virtual Private Cloud (VPC) a um gateway de trânsito permite rotear o tráfego de e para uma ou mais sub-redes VPC. Quando uma VPC é anexada a um gateway de trânsito, é necessário especificar uma sub-rede de cada zona de disponibilidade a ser usada pelo gateway de trânsito para rotear o tráfego. As sub-redes especificadas servem como pontos de entrada e saída para o tráfego do gateway de trânsito. O tráfego só pode alcançar recursos em outras sub-redes dentro da mesma zona de disponibilidade se as sub-redes do anexo do gateway de trânsito tiverem rotas apropriadas configuradas em suas tabelas de rotas apontando para as sub-redes de destino.
Limites
-
Quando uma VPC é anexada a um gateway de trânsito, nenhum recurso nas zonas de disponibilidade em que não houver um anexo do gateway de trânsito alcançará este gateway de trânsito.
nota
Nas zonas de disponibilidade que têm anexos do gateway de trânsito, o tráfego só é encaminhado para o gateway de trânsito a partir das sub-redes específicas associadas ao anexo. Se houver uma rota para o gateway de trânsito em uma tabela de rotas de sub-rede, o tráfego será enviado ao gateway de trânsito somente quando este tiver um anexo em uma sub-rede na mesma zona de disponibilidade e o anexo da tabela de rotas da sub-rede contiver rotas apropriadas para o destino pretendido do tráfego dentro da VPC.
-
Um gateway de trânsito não é compatível com a resolução de DNS para nomes de DNS personalizados de VPCs anexadas configuradas usando zonas hospedadas privadas no Amazon Route 53. Para configurar a resolução de nomes para zonas hospedadas privadas para todas as VPCs conectadas a um gateway de trânsito, consulte Gerenciamento centralizado de DNS da nuvem híbrida com o Amazon Route 53 e o Transit Gateway AWS
. -
Um gateway de trânsito não é compatível com o roteamento entre VPCs com CIDRs idênticos ou se um CIDR em um intervalo se sobrepor ao CIDR em uma VPC conectada. Se uma VPC for anexada a um gateway de trânsito e seu CIDR for idêntico ao CIDR de outra VPC, ou se sobrepor ao CIDR de outra VPC, que já esteja anexada ao gateway de trânsito, as rotas para a VPC recém-anexada não serão propagadas para a tabela de rotas do gateway de trânsito.
-
Não é possível criar um anexo para uma sub-rede da VPC que resida em uma zona local. Porém, é possível configurar a rede para que as sub-redes na Zona Local se conectem a um gateway de trânsito por meio da Zona de Disponibilidade principal. Para obter mais informações, consulte Conectar sub-redes da Zona Local a um gateway de trânsito.
-
Você não pode criar um anexo de gateway de trânsito usando IPv6-only sub-redes. As sub-redes do anexo do gateway de trânsito também devem ser compatíveis com endereços IPv4.
-
Um gateway de trânsito deve ter pelo menos um anexo de VPC antes que esse gateway de trânsito possa ser adicionado a uma tabela de rotas.
Requisitos de tabela de rotas para anexos de VPC
Os anexos da VPC do Transit Gateway exigem configurações específicas da tabela de rotas para funcionarem adequadamente:
-
Tabelas de rotas de sub-redes de anexos: as sub-redes associadas ao anexo do gateway de trânsito devem ter entradas na tabela de rotas para qualquer destino dentro da VPC que precise ser acessado por meio do gateway de trânsito. Isso inclui rotas para outras sub-redes, gateways da Internet, gateways NAT e endpoints da VPC.
-
Tabelas de rotas de sub-rede de destino: as sub-redes que contêm recursos que precisam se comunicar por meio do gateway de trânsito devem ter rotas apontando de volta para o gateway de trânsito para retornar o tráfego aos destinos externos.
-
Tráfego local da VPC: o anexo do gateway de trânsito não habilita automaticamente a comunicação entre sub-redes dentro da mesma VPC. As regras padrão de roteamento da VPC se aplicam, e a rota local (CIDR da VPC) deve estar presente nas tabelas de rotas para comunicação intra-VPC.
nota
Ter rotas configuradas em sub-redes sem anexos dentro da mesma zona de disponibilidade não permite o fluxo de tráfego. Somente as sub-redes específicas associadas ao anexo do gateway de trânsito podem servir como entry/exit pontos para o tráfego do gateway de trânsito.
Ciclo de vida do anexo da VPC
Um anexo da VPC passa por vários estágios, começando quando a solicitação é iniciada. Em cada etapa, pode haver ações possíveis, e, ao final do ciclo de vida, o anexo da VPC permanece visível no Amazon Virtual Private Cloud Console e na API ou na saída de linha de comando por um período.
O diagrama a seguir mostra os estados pelos quais um anexo pode passar em uma única configuração de conta ou em uma configuração para várias contas que tenha a opção Aceitar automaticamente os anexos compartilhados ativada.
-
Pendente: uma solicitação de anexo da VPC foi iniciada e está no processo de provisionamento. Nesta fase, o anexo pode falhar, ou pode ir para
available. -
Falhando: uma solicitação de anexo da VPC está mostrando falhas. Nesta fase, o anexo da VPC vai para
failed. -
Falha: a solicitação de anexo da VPC falhou. Enquanto estiver neste estado, ela não pode ser excluída. O anexo da VPC com falha permanece visível por 2 horas e, em seguida, não será mais visível.
-
Disponível: o anexo da VPC está disponível e o tráfego pode fluir entre a VPC e o gateway de trânsito. Nesta fase, o anexo pode ir para
modifying, ou paradeleting. -
Excluindo: um anexo da VPC que está em processo de ser excluído. Nesta fase, o anexo pode ir para
deleted. -
Excluído: um anexo da VPC
availablefoi excluído. Enquanto estiver nesse estado, o anexo da VPC não pode ser modificado. O anexo da VPC permanece visível por 2 horas e, em seguida, não será mais visível. -
Modificando: foi feita uma solicitação para modificar as propriedades do anexo da VPC. Nesta fase, o anexo pode ir para
available, ou pararolling back. -
Revertendo: a solicitação de modificação do anexo da VPC não pode ser concluída e o sistema está desfazendo todas as alterações feitas. Nesta fase, o anexo pode ir para
available.
O diagrama a seguir mostra os estados pelos quais um anexo pode passar em uma configuração de várias contas que tenha a opção Aceitar automaticamente os anexos compartilhados desativada.
-
Pending-acceptance: a solicitação de anexo do VPC está aguardando aceitação. Nesta fase, o anexo pode ir para
pending, pararejectingou paradeleting. -
Rejeitando: um anexo da VPC que está em processo de ser rejeitado. Nesta fase, o anexo pode ir para
rejected. -
Rejeitado: um anexo da VPC
pending acceptancefoi rejeitado. Enquanto estiver nesse estado, o anexo da VPC não pode ser modificado. O anexo da VPC permanece visível por 2 horas e, em seguida, não será mais visível. -
Pendente: um anexo da VPC foi aceito e está no processo de provisionamento. Nesta fase, o anexo pode falhar, ou pode ir para
available. -
Falhando: uma solicitação de anexo da VPC está mostrando falhas. Nesta fase, o anexo da VPC vai para
failed. -
Falha: a solicitação de anexo da VPC falhou. Enquanto estiver neste estado, ela não pode ser excluída. O anexo da VPC com falha permanece visível por 2 horas e, em seguida, não será mais visível.
-
Disponível: o anexo da VPC está disponível e o tráfego pode fluir entre a VPC e o gateway de trânsito. Nesta fase, o anexo pode ir para
modifying, ou paradeleting. -
Excluindo: um anexo da VPC que está em processo de ser excluído. Nesta fase, o anexo pode ir para
deleted. -
Excluída: um anexo da VPC
availableoupending acceptancefoi excluído. Enquanto estiver nesse estado, o anexo da VPC não pode ser modificado. O anexo da VPC permanece visível por 2 horas e, em seguida, não será mais visível. -
Modificando: foi feita uma solicitação para modificar as propriedades do anexo da VPC. Nesta fase, o anexo pode ir para
available, ou pararolling back. -
Revertendo: a solicitação de modificação do anexo da VPC não pode ser concluída e o sistema está desfazendo todas as alterações feitas. Nesta fase, o anexo pode ir para
available.
Modo do dispositivo
Se há planos para configurar um dispositivo de rede com estado na VPC, é possível habilitar o suporte ao modo de dispositivo para o anexo da VPC no qual o dispositivo está localizado ao criar um anexo. Isso garante que o AWS Transit Gateway use a mesma zona de disponibilidade para esse anexo de VPC durante toda a vida útil do fluxo de tráfego entre a origem e o destino. Também permite que um gateway de trânsito envie tráfego para qualquer zona de disponibilidade na VPC, desde que haja uma associação de sub-rede nessa zona. Embora o modo dispositivo seja suportado apenas em anexos VPC, o fluxo de rede pode vir de qualquer outro tipo de anexo do gateway de trânsito, incluindo anexos VPC, VPN e Connect. O modo dispositivo também funciona para fluxos de rede que têm origens e destinos diferentes Regiões da AWS. Os fluxos de rede podem ser potencialmente rebalanceados em diferentes zonas de disponibilidade se você não ativar inicialmente o modo de dispositivo, mas depois editar a configuração do anexo para habilitá-lo. Você pode habilitar ou desabilitar o modo de dispositivo usando o console, a linha de comando ou a API.
Importante
O modo dispositivo só é compatível com anexos de VPC.
Pré-requisitos para AZ-aware roteamento: a propagação de rotas deve estar habilitada para a tabela de rotas do Transit Gateway associada ao anexo VPC no modo appliance. Sem propagação, o gateway de trânsito não pode determinar as zonas de disponibilidade de origem e destino. Todo o tráfego, incluindo os mesmos Availability-Zone fluxos descritos no Cenário 1, volta para a seleção de zona de disponibilidade baseada em hash de fluxo. Isso significa que o tráfego dentro da mesma zona de disponibilidade pode ser roteado para uma zona de disponibilidade diferente na VPC do dispositivo, quebrando o isolamento da zona de disponibilidade.
O modo de dispositivo no AWS Transit Gateway otimiza o roteamento de tráfego considerando as zonas de disponibilidade de origem e destino ao determinar o caminho por meio de uma VPC no modo de dispositivo. Essa abordagem aumenta a eficiência e reduz a latência. O comportamento varia dependendo da configuração e dos padrões de tráfego específicos.
Os cenários a seguir pressupõem que a propagação de rotas esteja habilitada para a tabela de rotas do Transit Gateway associada ao anexo VPC no modo appliance. Sem propagação, o gateway de trânsito não pode determinar as zonas de disponibilidade de origem e destino, e todos os cenários usam como padrão a seleção da zona de disponibilidade baseada em fluxo de hash (o comportamento descrito no Cenário 2).
Cenário 1: roteamento de tráfego de Intra-Availability zona via appliance VPC
Quando o tráfego flui da zona de disponibilidade us-east-1a de destino para a zona de disponibilidade us-east-1a, com anexos da VPC do modo de dispositivo em us-east-1a e us-east-1b, o Transit Gateway seleciona uma interface de rede de us-east-1a dentro da VPC do dispositivo. Essa zona de disponibilidade é mantida por toda a duração do fluxo de tráfego entre a origem e o destino.
Cenário 2: roteamento de tráfego de Inter-Availability zona via appliance VPC
Para o tráfego flui da zona de disponibilidade us-east-1a de destino para a zona de disponibilidade us-east-1b, com anexos da VPC do modo de dispositivo em us-east-1a e us-east-1b, o Transit Gateway seleciona uma interface de rede de us-east-1a ou us-east-1b dentro da VPC do dispositivo. A zona de disponibilidade escolhida é usada de forma consistente durante a vida útil do fluxo.
Cenário 3: roteamento de tráfego por meio de uma VPC de dispositivo sem dados da zona de disponibilidade
Quando o tráfego se origina da Zona de Disponibilidade us-east-1a de origem para um destino sem informações da Zona de Disponibilidade (por exemplo, tráfego vinculado à Internet), com anexos VPC do Modo de Dispositivo em us-east-1a e us-east-1b, o Transit Gateway seleciona uma interface de rede de us-east-1a dentro da VPC do dispositivo.
Cenário 4: roteamento de tráfego por meio de uma VPC de dispositivo em uma zona de disponibilidade distinta da origem ou do destino
Quando o tráfego flui da Zona de Disponibilidade de origem us-east-1a para a zona de disponibilidade de destino us-east-1b, com anexos VPC no modo dispositivo em diferentes zonas de disponibilidade, por exemplo, us-east-1c e us-east-1d, o Transit Gateway usa um algoritmo de hash de fluxo para selecionar us-east-1c ou us-east-1d na VPC do dispositivo. A zona de disponibilidade escolhida é usada de forma consistente durante a vida útil do fluxo.
Referenciamento de grupo de segurança
Esse atributo pode ser usado para simplificar o gerenciamento de grupos de segurança e o controle do tráfego de instância a instância em VPCs conectadas ao mesmo gateway de trânsito. Só é possível fazer referência cruzada a grupos de segurança em regras de entrada. As regras de segurança de saída não são compatíveis com o referenciamento de grupos de segurança. Não há custos adicionais associados à ativação ou ao uso da referenciamento de grupos de segurança.
O suporte de referência do grupo de segurança pode ser configurado tanto para gateways de trânsito quanto para anexos do VPC do gateway de trânsito e só funcionará se tiver sido habilitado tanto para um gateway de trânsito quanto para seus anexos de VPC.
Limitações
As limitações a seguir se aplicam ao utilizar a referência ao grupo de segurança com um anexo do VPC.
A referência ao grupo de segurança não oferece suporte para as conexões de emparelhamento do Transit Gateway. As duas VPCs devem estar conectadas ao mesmo gateway de trânsito.
Não há suporte para a referência de grupos de segurança para anexos da VPC na zona de disponibilidade use1-az3.
A referência a grupos de segurança não é suportada para PrivateLink endpoints. Recomendamos usar as regras CIDR-based de segurança IP como alternativa.
A referência do grupo de segurança funciona para o Elastic File System (EFS), desde que uma regra de grupo de segurança de permissão para todas as saídas esteja configurada para as interfaces EFS na VPC.
Para conectividade de Zona Local por meio de um gateway de trânsito, há suporte apenas para as seguintes Zonas Locais: us-east-1-atl-2a, us-east-1-dfw-2a, us-east-1-iah-2a, us-west-2-lax-1a, us-west-2-lax-1b, us-east-1-mia-2a, us-east-1-chi-2a e us-west-2-phx-2a.
-
Recomendamos desativar esse recurso no nível de anexo da VPC para VPCs com sub-redes em Zonas Locais, AWS Outposts AWS e Zonas de Wavelength sem suporte, pois isso pode causar interrupção do serviço.
-
Se você tiver uma VPC de inspeção, a referência ao grupo de segurança por meio do gateway de trânsito não funcionará no Gateway Load AWS Balancer ou no Network Firewall. AWS
Suporte a IPv6
Ao criar ou modificar um anexo de VPC, você pode ativar ou desativar o suporte a IPv6. O valor padrão é disable.
A ativação do suporte ao IPv6 faz o seguinte:
-
Atribui um endereço IPv6 à interface de rede do Transit Gateway na sub-rede do anexo. O gateway de trânsito usa esse endereço para enviar e receber tráfego IPv6 por meio do anexo.
-
Propaga CIDRs IPv6 VPC para a tabela de rotas do gateway de trânsito quando a propagação da rota é configurada.
Quando você desativa o suporte ao IPv6, os seguintes comportamentos ainda se aplicam:
-
Você ainda pode criar rotas IPv6 estáticas que tenham como alvo o anexo.
-
O tráfego IPv6 ainda pode entrar no gateway de trânsito vindo da VPC se a tabela de rotas da VPC tiver uma rota IPv6 que aponte para o gateway de trânsito, e as ACLs de rede e os grupos de segurança permitirem o tráfego.
Essa configuração controla somente o endereçamento da interface de rede e a propagação da rota — ela não filtra pacotes.
Tarefas
