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

Práticas recomendadas para configuração

Esta seção fornece uma descrição detalhada do cenário mais restritivo, em que toda a comunicação ocorre somente pelo canal privado, e inclui uma explicação detalhada dos requisitos e dos componentes correspondentes a serem criados para cada área.

Esta seção descreve a configuração para o cenário mais restritivo (replicação somente em redes privadas), conforme mostrado no primeiro diagrama, com base nas considerações analisadas anteriormente. Você pode configurar os dois cenários híbridos ignorando as partes da configuração mais restritiva:

As seções a seguir pressupõem que a configuração inicial do MGN já esteja concluída, conforme descrito nas postagens do blog (Acelere sua migração com AWS Transform MGN e Como usar o novo AWS Transform MGN para Lift-and-Shift migrações). Essa análise se concentra em componentes específicos do cenário restritivo e pressupõe uma sub-rede de teste privada que não tem conectividade com a internet.

Configurações de roteamento e sub-redes

Para o cenário restritivo, você configura os AWS recursos necessários na sub-rede privada de uma VPC de teste. Essa sub-rede não tem conectividade com a internet (não há gateway da internet conectado à tabela de rotas como uma rota padrão). Em vez disso, ela usa um gateway virtual associado a um gateway do AWS Site-to-Site VPN (conectado por meio de um túnel IPsec a um gateway on-premises), ou ela está conectada a um gateway de transferência ou a serviços do Direct Connect para fornecer interconectividade privada aos data centers on-premises.

Você usará essa sub-rede privada como uma sub-rede de preparação para recursos relacionados à replicação gerenciados pelo Application Migration Service, e configurará todo o acesso necessário à rede por meio dessa sub-rede usando endpoints da VPC, conforme discutido na próxima seção.

Configuração dos endpoints da VPC

Agora você precisa criar VPC endpoints na sub-rede de teste para fornecer conectividade aos servidores de replicação e aos agentes MGN a partir de sub-redes locais.

Confira uma lista completa dos endpoints da VPC de que você precisa:

As próximas seções abordam mais detalhes sobre como os endpoints da VPC operam. A tabela a seguir lista todos os endpoints criados para a sub-rede privada de preparação. (Observe que o endpoint do gateway do Amazon S3 não tem interfaces de rede provisionadas, mas tem listas de prefixos específicos provisionadas na tabela de rotas de sub-redes, conforme descrito posteriormente neste guia.)

Você pode criar endpoints de VPC opcionais para permitir o acesso a instâncias do EC2 em sub-redes privadas isoladas por meio de, AWS Systems Manager conforme discutido em Criação de endpoints de VPC na documentação do Systems Manager.

Endpoints de interface com VPC

A criação de um endpoint de interface também cria uma interface de rede elástica específica para cada sub-rede para a qual o determinado endpoint de interface está provisionado. Por exemplo, o endpoint da interface do Application Migration Service é provisionado em uma sub-rede privada na VPC de preparação com uma interface de rede elástica associada ao endereço IP dentro dessa sub-rede, e também tem três nomes DNS resolvidos da sub-rede para esse endereço IP:

Isso permite que qualquer instância em execução na sub-rede que esteja usando a configuração padrão do conjunto de opções do Protocolo de Configuração Dinâmica de Host (DHCP) na VPC, e tenha os atributos DNS enableDnsHostnames e enableDnsSupport habilitados, possa:

Isso fixa a conectividade de qualquer instância em execução na sub-rede de teste (como o servidor de replicação MGN ou o servidor de conversão) para qualquer instância AWS service (Serviço da AWS) que tenha endpoints de interface provisionados na sub-rede (como Amazon EC2, MGN, Systems Manager e assim por diante). AWS KMS

Endpoints de gateway da VPC

Para serviços como o Amazon S3, nenhum nome DNS fixo pode ser provisionado porque cada bucket tem seu próprio nome DNS. Para esse cenário, você usará endpoints de gateway da VPC. 

A criação de um endpoint de gateway Amazon S3 também cria um objeto de lista de prefixos específicos com uma lista de destinos de sub-rede (em notação CIDR), que pode ser adicionada à tabela de rotas de sub-redes. Assim, os nomes DNS dos buckets do S3 resolvidos para os endereços IP incluídos nessa lista serão acessíveis por meio da conectividade interna. 

Ao provisionar um endpoint do gateway do Amazon S3, você pode especificar as sub-redes nas tabelas de rotas que devem incluir esse ID de lista de prefixos (PL-<id>). A tabela de rotas resultante para a sub-rede privada de preparação deve incluir esse ID da lista de prefixos, como neste exemplo de tabela de rotas:

Endpoints de entrada do resolvedor de DNS

A configuração descrita na seção anterior é suficiente para instâncias que estão sendo executadas dentro das AWS sub-redes, porque elas já estão configuradas para usar servidores DNS internos do Amazon Route 53. No entanto, os servidores de origem locais exigem etapas adicionais para poder se comunicar com eles de forma Serviços da AWS privada. Em particular, o MGN Agent precisa baixar o instalador do Amazon S3 e depois se comunicar com o MGN usando os nomes DNS fornecidos na documentação. On-premises os servidores usam seus servidores DNS padrão para resolver esses nomes DNS, resultando em endereços IP públicos. As comunicações com esses endereços pela HTTPS/TCP porta 443 acabam sendo bloqueadas por firewalls corporativos.

Para evitar isso, você precisa configurar os servidores de origem ou seus servidores DNS padrão para usar o Amazon Route 53 Resolver na resolução desses nomes DNS específicos ou uma zona de subdomínio (ou seja, toda a zona *.<region>.amazonaws.com). Isso pode ser configurado criando um endpoint de entrada do Route 53 Resolver, que, como um endpoint de interface VPC, tem uma interface de rede elástica dedicada criada na sub-rede privada dedicada ativada e AWS, portanto, é capaz de encaminhar solicitações de DNS para. Amazon Route 53 Resolver 

Grupos de segurança da interface de rede elástica

Cada interface de rede elástica tem um grupo de segurança dedicado associado a ela, que deve permitir o tráfego esperado para essa interface de rede elástica e o endpoint correspondente. Portanto, o grupo de segurança do endpoint do resolvedor de DNS deve permitir a porta UDP 53 de entrada (e às vezes a porta TCP 53) para solicitações de DNS, e os grupos de segurança do endpoint para a maioria dos outros serviços (MGN, Amazon EC2, Systems Manager e assim por diante) precisam da porta de entrada 443 habilitada. HTTPS/TCP

Instalando o MGN Agent nos servidores de origem

Para instalar o MGN Agent nos servidores de origem, você precisa fornecer os nomes DNS dos endpoints da interface MGN e Amazon S3 aos parâmetros da linha de comando do Agente (consulte Instalação do Agente em uma rede segura na documentação do MGN). 

Para o endpoint MGN, você pode usar qualquer um dos nomes DNS associados a ele — um campo DNS privado (mgn.<region>.amazonaws.com) ou um nome DNS () — e VPC-specific fornecer um argumento:. vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com --endpoint <FQDN> Na verdade, se você ignorar esse argumento, o Agente usa o especificado Região da AWS para reconstruir o DNS FQDN (mgn.<region>.amazonaws.com) padrão e usa o FQDN para acessar o plano de controle do Application Migration Service. Na maioria dos casos, esse comportamento padrão deve ser suficiente, desde que o FQDN seja resolvido corretamente do servidor de origem para o endereço IP privado da interface de rede elástica do endpoint MGN VPC criado na sub-rede de teste. 

O endpoint da interface do Amazon S3 não terá um único nome DNS privado (porque cada bucket do S3 terá seu próprio), portanto, essa opção não é compatível. No entanto, um endpoint de interface do Amazon S3 ainda tem uma interface de rede elástica associada a ele. Ele também tem um IP privado específico e nomes DNS curinga (no formato .vpce-<VPC-ID>-<suffix>.s3.<region>.vpce.amazonaws.com ou. Region-specific vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com) que podem ser resolvidos para esse IP privado.

Esse nome DNS curinga pode ser usado para o argumento --s3-endpoint, como abaixo:

aws-replication-installer-init.py --region <region> --aws-access-key-id <MGN_IAM_ACCESS_KEY>  --aws-secret-access-key <MGN_IAM_SECRET> --no-prompt \
   --endpoint vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com --s3-endpoint vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com

A próxima seção fornece um exemplo de configuração da MGN, incluindo todos os VPC endpoints necessários, e implantação dos Agentes usando VPC endpoints em servidores de origem Windows e Linux. A seção aborda a implantação manual e automatizada.