Anexos do Amazon VPC no AWS Transit Gateway - Amazon VPC

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 no AWS Transit Gateway

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 de zonas hospedadas privadas para todas as VPCs anexadas a um gateway de trânsito, consulte Gerenciamento centralizado de DNS de nuvem híbrida com Amazon Route 53 e AWS Transit Gateway.

  • 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.

  • Não é possível criar um anexo do gateway de trânsito usando sub-redes exclusivamente IPv6. 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 pontos de entrada/saída 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.

Ciclo de vida do anexo da VPC
  • 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 para deleting.

  • 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 available foi 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 para rolling 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.

Ciclo de vida dos anexos da VPC entre contas que estão com a opção Aceitar automaticamente os anexo compartilhados desativada
  • Aceitação pendente: a solicitação de anexo da VPC está aguardando aceitação. Nesta fase, o anexo pode ir para pending, para rejecting ou para deleting.

  • 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 acceptance foi 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 para deleting.

  • 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 available ou pending acceptance foi 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 para rolling 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 o tempo de vida de um 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.

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. Estes são cenários de exemplo:

Cenário 1: roteamento de tráfego de zona intra-disponibilidade 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 zona intra-disponibilidade 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 de origem us-east-1a para um destino sem informações de zona de disponibilidade (por exemplo, tráfego com destino à internet), com anexos VPC no modo dispositivo em us-east-1a e us-east-1b, o Gateway de Trânsito 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.

nota

O modo dispositivo só é compatível com anexos de VPC. Certifique-se de que a propagação de rotas esteja habilitada para uma tabela de rotas associada a um anexo VPC do appliance.

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 ao grupo de segurança não oferece suporte para endpoints do PrivateLink. Recomendamos o uso de regras de segurança baseadas em IP CIDR 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.

  • Recomenda-se desativar esse atributo no nível de anexo da VPC para VPCs com sub-redes em Zonas Locais, AWS Outposts e AWS Wavelength Zones 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 AWS Gateway Load Balancer ou no AWS Network Firewall.