Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Prácticas recomendadas de configuración

En esta sección se proporciona una descripción detallada del escenario más restrictivo, en el que toda la comunicación se produce únicamente a través del canal privado, e incluye una explicación detallada de los requisitos y los componentes correspondientes que se van a crear para cada área.

En esta sección se describe la configuración para el escenario más restrictivo (la replicación únicamente a través de redes privadas), tal como se muestra en el primer diagrama, según las consideraciones expuestas anteriormente. Puede configurar ambos escenarios híbridos omitiendo partes de la configuración más restrictiva:

En las siguientes secciones se presupone que la configuración inicial de MGN ya está completa, tal y como se describe en las entradas del blog (Acelere su migración con AWS Transform MGN y Cómo utilizar lo nuevo AWS Transform MGN para Lift-and-Shift las migraciones). Este análisis se centra en los componentes que son específicos del escenario restrictivo y se presupone que hay una subred de pruebas privada que no tiene conectividad a Internet.

Configuraciones de subredes y enrutamiento

Para el escenario restrictivo, debe configurar los AWS recursos necesarios en la subred privada de una VPC provisional. Esta subred no tiene conectividad a Internet (no hay ninguna puerta de enlace de Internet conectada a la tabla de enrutamiento como ruta predeterminada). En su lugar, utiliza una puerta de enlace virtual asociada a una puerta de enlace de AWS Site-to-Site VPN (conectada a través de un túnel IPsec a una puerta de enlace en las instalaciones) o está conectada a una puerta de enlace de transferencia o a servicios de Direct Connect para proporcionar interconectividad privada a los centros de datos en las instalaciones.

Utilizará esa subred privada como subred de pruebas para los recursos relacionados con la replicación administrados por Application Migration Service y configurará todo el acceso a la red necesario a través de esta subred mediante puntos de conexión de VPC, como se explica en la siguiente sección.

Configuración de puntos de conexión de VPC

Ahora necesita crear puntos de enlace de VPC en la subred provisional para proporcionar conectividad a los servidores de replicación y a los agentes MGN desde las subredes locales.

Esta es una lista completa de los puntos de conexión de VPC que necesita:

En las siguientes secciones se explica con más detalle el funcionamiento de los puntos de conexión de VPC. En la siguiente tabla se enumeran todos los puntos de conexión creados para la subred privada de pruebas. (Tenga en cuenta que el punto de conexión de la puerta de enlace de Amazon S3 no tiene ninguna interfaz de red aprovisionada, pero tiene listas de prefijos específicas aprovisionadas en la tabla de enrutamiento de la subred, como se describirá más adelante en esta guía).

Puede crear puntos de enlace de VPC opcionales para permitir el acceso a las instancias de EC2 en subredes privadas aisladas AWS Systems Manager, tal como se explica en Creación de puntos de enlace de VPC en la documentación de Systems Manager.

Puntos de enlace de interfaz de VPC

Al crear un punto de conexión de interfaz, también se crea una interfaz de red elástica específica para cada subred para la que se aprovisiona el punto de conexión de interfaz en cuestión. Por ejemplo, el punto de conexión de interfaz de Application Migration Service se aprovisiona en una subred privada de la VPC de pruebas con una interfaz de red elástica que está asociada a la dirección IP de esa subred y también tiene tres nombres de DNS que se pueden resolver desde la subred a esta dirección IP:

Esto permite que todas las instancias que se ejecuten en la subred y que utilicen la configuración predeterminada del conjunto de opciones del protocolo de configuración dinámica de host (DHCP) en la VPC y que tenga los atributos de DNS enableDnsHostnames y enableDnsSupport habilitados pueda hacer lo siguiente:

Esto corrige la conectividad de cualquier instancia que se ejecute en la subred provisional (como el servidor de replicación o el servidor de conversión MGN) para cualquier instancia Servicio de AWS que tenga puntos de conexión de interfaz aprovisionados en la subred (como Amazon EC2, MGN, Systems Manager, etc.). AWS KMS

Puntos de conexión de puertas de enlace de VPC

En el caso de los servicios como Amazon S3, no se puede aprovisionar ningún nombre de DNS fijo porque cada bucket tiene su propio nombre de DNS. Para este escenario, utilizará puntos de conexión de puerta de enlace de VPC. 

Al crear un punto de conexión de puerta de enlace de Amazon S3, también se crea un objeto de lista de prefijos específico con una lista de destinos de subred (en notación CIDR), que se puede agregar a la tabla de enrutamiento de subred. Por lo tanto, se podría acceder a los nombres de DNS de los buckets de S3 resueltos en las direcciones IP incluidas en esta lista a través de la conectividad interna. 

Al aprovisionar un punto de conexión de puerta de enlace de Amazon S3, puede especificar las subredes en las tablas de enrutamiento que deben incluir ese ID de lista de prefijos (PL-<id>). La tabla de enrutamiento resultante para la subred privada de pruebas debe incluir ese ID de la lista de prefijos, como en esta tabla de enrutamiento de ejemplo:

Puntos de conexión de entrada del solucionador de DNS

La configuración descrita en la sección anterior es suficiente para las instancias que se ejecutan dentro de las AWS subredes, porque ya están configuradas para usar servidores DNS internos de Amazon Route 53. Sin embargo, los servidores de origen locales requieren pasos adicionales para poder comunicarse con Servicios de AWS ellos de forma privada. En concreto, MGN Agent debe descargar el instalador de Amazon S3 y, a continuación, comunicarse con MGN mediante los nombres de DNS que se proporcionan en la documentación. On-premises los servidores utilizan sus servidores DNS predeterminados para resolver estos nombres DNS, lo que da como resultado direcciones IP públicas. Los firewalls corporativos bloquean finalmente las comunicaciones con estas direcciones a través del HTTPS/TCP puerto 443.

Para evitarlo, debe configurar los servidores de origen o sus servidores DNS predeterminados para utilizar Amazon Route 53 Resolver en la resolución de estos nombres de DNS específicos o de una zona de subdominio (es decir, toda la zona *.<region>.amazonaws.com). Esto se puede configurar creando un punto final de entrada de Route 53 Resolver que, como un punto final de interfaz de VPC, tiene una interfaz de red elástica dedicada creada en la subred AWS privada dedicada y, por lo tanto, puede reenviar las solicitudes de DNS. Amazon Route 53 Resolver 

Grupos de seguridad para la interfaz de red elástica

Cada interfaz de red elástica tiene un grupo de seguridad dedicado asociado, que debe permitir el tráfico esperado para esta interfaz de red elástica y el punto de conexión correspondiente. Por lo tanto, el grupo de seguridad del punto final del solucionador de DNS debe permitir el puerto UDP 53 de entrada (y, a veces, el puerto TCP 53) para las solicitudes de DNS, y los grupos de seguridad del punto final para la mayoría de los demás servicios (MGN, Amazon EC2, Systems Manager, etc.) deben habilitar el puerto de HTTPS/TCP entrada 443.

Instalación del agente MGN en los servidores de origen

Para instalar el agente MGN en los servidores de origen, debe proporcionar los nombres DNS de los puntos finales de las interfaces MGN y Amazon S3 a los parámetros de la línea de comandos del agente (consulte Instalación del agente en una red segura en la documentación de MGN). 

Para el punto de conexión MGN, puede utilizar cualquiera de los nombres DNS asociados a él (un campo DNS privado (mgn.<region>.amazonaws.com) o un nombre VPC-specific DNS () e introducir un argumento:. vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com --endpoint <FQDN> De hecho, si omite este argumento, el agente utilizará el especificado Región de AWS para reconstruir el FQDN de DNS predeterminado (mgn.<region>.amazonaws.com) y lo utilizará para acceder al plano de control del Servicio de migración de aplicaciones. En la mayoría de los casos, ese comportamiento predeterminado debería ser suficiente, siempre que el FQDN se resuelva correctamente desde el servidor de origen en la dirección IP privada de la interface de red elástica para el punto final de la VPC de MGN creado en la subred provisional. 

El punto de conexión de interfaz de Amazon S3 no tendrá un único nombre de DNS privado (ya que cada bucket de S3 tendrá el suyo propio), por lo que esa opción no se admite. Sin embargo, un punto de conexión de interfaz de Amazon S3 todavía tiene asociada una interfaz de red elástica. También tiene una IP privada específica y nombres DNS comodín (en el formato o. .vpce-<VPC-ID>-<suffix>.s3.<region>.vpce.amazonaws.com Region-specific vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com) que se pueden resolver en esta IP privada.

Ese nombre de DNS comodín se puede utilizar para el argumento --s3-endpoint, como se muestra a continuación:

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

En la siguiente sección, se proporciona un ejemplo de configuración de MGN, incluidos todos los puntos de enlace de VPC necesarios, y de implementación de los agentes mediante puntos de enlace de VPC en servidores de origen de Windows y Linux. En la sección se tratan tanto la implementación manual como la automatizada.