

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.

# Migración de aplicaciones de IIS a Elastic Beanstalk
<a name="dotnet-migrating-applications"></a>

AWS Elastic Beanstalk proporciona una ruta de migración simplificada para las aplicaciones de Windows que se ejecutan en los Servicios de Información de Internet (IIS). La capacidad de migración descrita en este capítulo reduce considerablemente el tiempo y la complejidad que suelen conllevar las migraciones a la nube, lo que le ayuda a mantener la funcionalidad de las aplicaciones y la integridad de la configuración durante la transición a AWS.

**La operación **eb migrate****  
Utilice el comando **eb migrate** de la interfaz de la línea de comandos de Elastic Beanstalk (CLI de EB) para detectar, empaquetar e implementar automáticamente las aplicaciones de IIS en la Nube de AWS. El proceso mantiene la funcionalidad de las aplicaciones y preserva las configuraciones, incluidos los enlaces, los grupos de aplicaciones y la configuración de autenticación.

Los siguientes pasos resumen el proceso que lleva a cabo la operación `eb migrate` para hacer la transición de la aplicación a Nube de AWS:

1. Detecte los sitios de IIS y sus configuraciones.

1. Contenido y configuración del contenido de la aplicación de paquete.

1. Cree una aplicación y un entorno de Elastic Beanstalk.

1. Implemente la aplicación con la configuración conservada.

**Opciones de ejecución del flujo de trabajo y ubicación**  
El comando **eb migrate** proporciona opciones para flujos de trabajo de migración y ubicaciones de ejecución flexibles. De forma predeterminada, ejecute el comando en el servidor de destino que contiene la aplicación que desea migrar a Elastic Beanstalk. Si no puede ejecutar los comandos directamente en el servidor de aplicaciones, utilice la opción `remote` para ejecutar el comando desde un host bastión que se conecte al servidor de destino que contiene la aplicación y las configuraciones. Para completar la migración en dos pasos, también puede generar el paquete de migración sin implementarlo mediante la opción `archive-only` y, a continuación, implementarlo más adelante, según le convenga, utilizando la opción `archive`.

Para obtener información de referencia sobre el comando **eb migrate**, consulte [**eb migrate**](eb3-migrate.md).

**Temas**  
En los siguientes temas se proporciona información detallada sobre la migración de aplicaciones de IIS a Elastic Beanstalk:
+ [Requisitos previos](dotnet-migrating-applications-prerequisites.md): conozca el software, el acceso y los permisos necesarios para migrar las aplicaciones de Windows a los entornos de AWS Elastic Beanstalk .
+ [Glosario de migración](dotnet-migrating-applications-glossary.md): comprenda cómo los componentes de IIS se asignan a los recursos de Elastic Beanstalk.
+ [Comprensión de la asignación de la migración de IIS a Elastic Beanstalk](dotnet-migrating-applications-mapping.md): comprenda cómo los componentes de IIS se asignan a los recursos de Elastic Beanstalk.
+ [Realización de migraciones básicas de IIS](dotnet-migrating-applications-basic-migration.md): aprenda a realizar migraciones básicas.
+ [Escenarios de migración avanzada](dotnet-migrating-applications-advanced-scenarios.md): gestione escenarios de migración complejos.
+ [Configuraciones de seguridad y roles de IAM](dotnet-migrating-applications-security.md): configure los ajustes de seguridad durante la migración.
+ [Configuración de red y ajustes de puerto](dotnet-migrating-applications-network.md): gestione las configuraciones de red y puertos
+ [Solución de los problemas y diagnóstico](dotnet-migrating-applications-troubleshooting.md): solucione los problemas de migración más comunes.
+ [Comparación de las opciones de migración: EB CLI vs. AWS Application Migration Service](dotnet-migrating-applications-comparison.md): compare dos opciones de migración principales.

# Requisitos previos
<a name="dotnet-migrating-applications-prerequisites"></a>

Antes de utilizar el comando **eb migrate**, asegúrese de que su entorno cumpla estos requisitos.

**Instalación y versión de IIS**  
El servidor desde el que va a realizar la migración debe ejecutar Internet Information Services (IIS), versión 7.0 o posterior. IIS 10.0 en Windows Server 2016 o posterior es el entorno más compatible para la migración.  
Para comprobar la versión de IIS ejecute el siguiente comando:  

```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\InetStp\"
...
SetupString             : IIS 10.0
VersionString           : Version 10.0
...
```

**Requisitos de Windows Server**  
Su entorno de origen debe ejecutar Windows Server 2016 o posterior para lograr una compatibilidad óptima. Elastic Beanstalk admite las siguientes versiones de Windows Server como plataformas de destino:  
+ Windows Server 2025
+ Windows Server 2022
+ Windows Server 2019
+ Windows Server 2016

**Instalación de la CLI de EB**  
+ *Flujo de trabajo predeterminado (sin la opción `--remote`)*:
  + Python y la Interfaz de la línea de comandos de Elastic Beanstalk (CLI de EB) deben estar instalados en el servidor que contiene la aplicación que desea migrar a Elastic Beanstalk. Si bien no es obligatorio, recomendamos instalar la CLI de EB dentro de un entorno de pruebas `virtualenv`, tal y como se describe en [Instalación de la CLI de EB en un entorno virtual](eb-cli3.md#eb-cli3-install-virtualenv).
+ *Uso de la opción `--remote`*:
  + Python y la Interfaz de la línea de comandos de Elastic Beanstalk (CLI de EB) deben estar instalados en el host bastión. Si bien no es obligatorio, recomendamos instalar la CLI de EB dentro de un entorno de pruebas `virtualenv`, tal y como se describe en [Instalación de la CLI de EB en un entorno virtual](eb-cli3.md#eb-cli3-install-virtualenv).

**Permisos de ** necesarios  
También necesita las siguientes credenciales y permisos:  
+ Privilegios de administrador en el servidor de IIS de origen o en el host bastión (si utiliza la opción `--remote`).
+ AWS credenciales con permisos para crear y administrar los recursos de Elastic Beanstalk

**Web Deploy 3.6**  
La herramienta Web Deploy (versión 3.6 o posterior) de Microsoft debe estar instalada en el servidor de origen o en el host bastión (si utiliza la opción `--remote`). **eb migrate** utiliza esta herramienta para empaquetar las aplicaciones.  
Para comprobar la instalación de Docker, ejecute el siguiente comando:  
:  

```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\3" -Name InstallPath

InstallPath  : C:\Program Files\IIS\Microsoft Web Deploy V3\
...
```
Para obtener instrucciones de instalación, consulte [Installing and Configuring Web Deploy on IIS 8.0 or Later](https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy-on-iis-80-or-later) en el sitio web de documentación del producto de Microsoft Windows.

**Requisitos de red**  
+ *Flujo de trabajo predeterminado (sin la opción `--remote`)*:
  + El servidor de origen debe tener acceso saliente a los AWS servicios de Internet.
+ *Uso de la opción `--remote`*:
  + El servidor de origen debe tener acceso saliente a los servicios de Internet. AWS 
  + Configure las reglas de entrada adecuadas de los grupos de seguridad que permitan una conexión de red saliente desde el host bastión y una conexión entrante a la máquina remota. Asegúrese de que la IP del host bastión aparezca en la lista de permitidos mediante TCP en el puerto 22 para acceder a la máquina remota.
  + Asegúrese de que su cliente SSH esté instalado y funcionando tanto en su máquina remota como en su host bastión.
  + Asegúrese de que la configuración del firewall contenga las reglas adecuadas que abran el puerto 22 o permitan la conexión al cliente.
  + Pruebe la conexión mediante una conexión SSH manual al host remoto desde el host bastión antes de intentar la migración.

# Glosario de migración
<a name="dotnet-migrating-applications-glossary"></a>

En este glosario se proporcionan definiciones de términos y conceptos clave relacionados con IIS, Elastic Beanstalk y la migración de aplicaciones de IIS a Elastic Beanstalk.

## Términos de Windows, IIS y .NET
<a name="dotnet-migrating-applications-glossary-windows"></a>

****IIS****  
Internet Information Services, un software de servidor web desarrollado por Microsoft para su uso con Windows Server. IIS aloja sitios, aplicaciones y servicios web, lo que proporciona una plataforma para ejecutar ASP.NET y otras tecnologías web. Durante la migración a Elastic Beanstalk, los sitios de IIS y sus configuraciones se empaquetan e implementan en las instancias de Windows Server en la nube. AWS   
Se admiten las versiones 7.0 y posteriores de IIS para la migración; IIS 10.0 en Windows Server 2016 o posterior es el entorno más compatible.

****.NET Framework****  
Una plataforma de desarrollo de software establecida por Microsoft para crear y ejecutar aplicaciones de Windows. Proporciona una gran biblioteca de clases llamada Framework Class Library (FCL) y admite la interoperabilidad entre varios lenguajes de programación.  
Cuando migran a Elastic Beanstalk, las aplicaciones creadas en .NET Framework siguen ejecutándose en la misma versión del marco en el entorno de nube. Elastic Beanstalk admite varias versiones de .NET Framework (4.x) en sus plataformas de Windows Server.

****.NET Core****  
Un sucesor multiplataforma y de código abierto de .NET Framework, diseñado para ser más modular y ligero. .NET Core (ahora denominado simplemente .NET 5 y versiones posteriores) permite que los desarrolladores creen aplicaciones que se ejecutan en Windows, Linux y macOS.  
Cuando migra aplicaciones creadas en .NET Core a Elastic Beanstalk, puede elegir entre plataformas de Windows Server o plataformas basadas en Linux, según los requisitos y las dependencias de su aplicación.

****Common Language Runtime (CLR)****  
El componente de máquina virtual de .NET Framework que administra la ejecución de los programas de .NET. El CLR proporciona servicios como la administración de memoria, la seguridad de tipos, el manejo de excepciones, la recopilación de elementos no utilizados y la administración de subprocesos.  
Cuando se migra a Elastic Beanstalk, la versión adecuada de CLR está disponible automáticamente en la plataforma de Windows Server que seleccione, lo que garantiza la compatibilidad con los requisitos de la aplicación.

****Sitio****  
Un contenedor lógico de IIS que representa una aplicación o un servicio web, identificado mediante un enlace único de dirección IP, puerto y encabezado de host. Cada sitio de IIS tiene su propio grupo de aplicaciones, enlaces y valores de configuración, y puede contener una o más aplicaciones.

****Aplicación****  
Agrupación de archivos de contenido y código dentro de un sitio de IIS que gestiona las solicitudes de un espacio de URL específico. Las aplicaciones de IIS pueden tener sus propios valores de configuración, que normalmente se almacenan en archivos `web.config`.  
Cuando se migra a Elastic Beanstalk, las aplicaciones se conservan con su estructura de rutas y sus ajustes de configuración. El proceso de migración garantiza que las aplicaciones anidadas mantengan su jerarquía y sus rutas de URL en el entorno de nube.

****ApplicationPool****  
Característica de IIS que aísla las aplicaciones web para mejorar la seguridad, la fiabilidad y la administración del rendimiento. Los grupos de aplicaciones definen el entorno del tiempo de ejecución de las aplicaciones, incluida la versión de .NET Framework, el modo de canalización y la configuración de identidad.

****VirtualDirectory****  
Una asignación de directorios en IIS que permite que el contenido se sirva desde una ubicación fuera del directorio raíz del sitio. Los directorios virtuales permiten organizar el contenido en diferentes ubicaciones físicas y, al mismo tiempo, presentan a los usuarios una estructura de URL unificada.  
Cuando se migra a Elastic Beanstalk, los directorios virtuales se conservan con sus asignaciones de rutas. El comando **eb migrate** crea la estructura de directorios y las configuraciones necesarias en el entorno de nube para mantener las mismas rutas de URL.

****ARR****  
Enrutamiento de solicitudes de aplicaciones (Application Request Routing), una extensión de IIS que proporciona capacidades de equilibrio de carga y proxy para servidores web. ARR permite el enrutamiento basado en URL, el reenvío de solicitudes HTTP y la distribución de la carga entre varios servidores.  
Durante la migración a Elastic Beanstalk, las configuraciones de ARR se conservan mediante la instalación de características de ARR en las instancias de EC2 y la configuración de las reglas de enrutamiento adecuadas. Para escenarios de enrutamiento complejos, el proceso de migración también puede aprovechar las reglas del Equilibrador de carga de aplicación para implementar una funcionalidad similar.

****Reescritura de URL****  
Módulo de IIS que modifica las solicitudes en URLs función de reglas definidas antes de que lleguen a la aplicación web. La reescritura de URL permite la manipulación de las URL, el redireccionamiento y la entrega de contenido en función de patrones y condiciones.  
Cuando se migra a Elastic Beanstalk, las reglas de reescritura de URL de los archivos `web.config` se traducen en reglas de enrutamiento del ALB siempre que es posible o se conservan en la configuración de IIS de las instancias de EC2. Esto garantiza que los patrones de URL y los redireccionamientos sigan funcionando según lo previsto en el entorno de nube.

****msdeploy.exe****  
Herramienta de la línea de comandos que se utiliza para implementar aplicaciones web y sitios web en servidores de IIS. También conocida como Web Deploy, proporciona una forma de empaquetar, sincronizar e implementar aplicaciones y sitios web y configuraciones de servidores.  
El comando **eb migrate** usa Web Deploy (versión 3.6 o posterior) para empaquetar las aplicaciones durante la migración a Elastic Beanstalk. Esta herramienta debe estar instalada en el servidor de origen para que el proceso de migración funcione correctamente.

****Ruta física****  
La ubicación real del sistema de archivos en la que se almacenan los archivos de contenido de un sitio o una aplicación de IIS. Las rutas físicas pueden apuntar a directorios locales, recursos compartidos de red u otras ubicaciones de almacenamiento accesibles para el servidor de IIS.  
Durante la migración a Elastic Beanstalk, las rutas físicas se asignan a las ubicaciones adecuadas de las instancias de EC2 del entorno. El proceso de migración preserva la estructura del contenido y, al mismo tiempo, garantiza que todos los archivos se implementen correctamente en el entorno de nube.

****applicationHost.config****  
El archivo de configuración raíz de IIS que define la configuración de todo el servidor y contiene la configuración de todos los sitios, aplicaciones y directorios virtuales. Este archivo se encuentra en el directorio `%windir%\System32\inetsrv\config` y controla el comportamiento general del servidor de IIS.  
Cuando se migra a Elastic Beanstalk, la configuración relevante de `applicationHost.config` se extrae y se aplica a la configuración de IIS en las instancias de EC2 de su entorno. Esto garantiza que la configuración de todo el servidor se conserve durante la migración.

****web.config****  
Archivo de configuración basado en XML que se utiliza en las aplicaciones de ASP.NET para controlar la configuración, la seguridad y el comportamiento de las aplicaciones a nivel de la aplicación o el directorio. Los archivos `web.config` pueden contener configuraciones de autenticación, autorización, estado de sesión, compilación y parámetros de aplicación personalizados.  
Durante la migración a Elastic Beanstalk, los archivos `web.config` se conservan e implementan con la aplicación. El proceso de migración garantiza que las configuraciones específicas de la aplicación sigan funcionando según lo esperado en el entorno de nube.

****DefaultDocument****  
Característica de IIS que especifica el archivo predeterminado que se mostrará cuando un usuario solicite un directorio sin especificar un nombre de archivo. Los documentos predeterminados están habilitados de forma predeterminada e IIS 7 define los siguientes archivos de documentos predeterminados del archivo `applicationHost.config` como valores predeterminados para todo el servidor: Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm.  
Al migrar a Elastic Beanstalk, la configuración predeterminada del documento se conserva en la configuración de IIS en las instancias de EC2, lo que garantiza que las solicitudes de directorio se gestionen de forma coherente en el entorno de nube.

****system.webServer****  
Una sección de configuración de `web.config` o `applicationHost.config` que contiene configuraciones específicas de IIS para módulos, controladores y otros comportamientos del servidor. Esta sección controla la forma en que IIS procesa las solicitudes, administra los módulos y configura las características del servidor.  
Durante la migración a Elastic Beanstalk, la configuración de system.webServer se conservan en los archivos `web.config` de la aplicación y se utilizan en la instalación de IIS en las instancias de EC2 de su entorno. Esto garantiza que los comportamientos específicos de IIS se mantengan en el entorno de nube.

## Términos de Elastic Beanstalk
<a name="dotnet-migrating-applications-glossary-eb"></a>

****Plataforma****  
Una combinación de sistema operativo, tiempo de ejecución de un lenguaje de programación, servidor web, servidor de aplicaciones y componentes de Elastic Beanstalk que define la pila de software para las aplicaciones en ejecución.  
Para las migraciones de Windows, Elastic Beanstalk proporciona plataformas basadas en Windows Server 2016, 2019 y 2022 con IIS y varias versiones de .NET Framework para garantizar la compatibilidad con el entorno de origen.

****SolutionStack****  
Una configuración de plataforma predefinida en Elastic Beanstalk que especifica el sistema operativo, el tiempo de ejecución y otros componentes necesarios para ejecutar una aplicación. Conceptualmente es idéntico a una plataforma y se usa indistintamente para operar entornos.  
Durante la migración, el comando **eb migrate** selecciona una pila de soluciones adecuada en función de la configuración del entorno de origen, lo que garantiza la compatibilidad con las aplicaciones de IIS.

****CreateEnvironment****  
Acción de la API de Elastic Beanstalk que crea un nuevo entorno para alojar una versión de la aplicación. El comando **eb migrate** utiliza esta API para aprovisionar los recursos de AWS necesarios para la aplicación migrada.  
El proceso de migración configura los parámetros de entorno adecuados en función del entorno de IIS de origen, incluidos el tipo de instancia, las variables de entorno y la configuración de las opciones.

****CreateApplicationVersion****  
Acción de la API de Elastic Beanstalk que crea una nueva versión de la aplicación a partir de un paquete de código fuente almacenado en Amazon S3. El comando **eb migrate** usa esta API para registrar la aplicación de IIS empaquetada como una versión en Elastic Beanstalk.  
Durante la migración, los archivos y la configuración de la aplicación se empaquetan, se cargan en Amazon S3 y se registran como una versión de la aplicación antes de la implementación.

****DescribeEvents****  
Acción de la API de Elastic Beanstalk que recupera una lista de eventos de un entorno, incluidas las implementaciones, los cambios de configuración y los problemas operativos. El comando **eb migrate** usa esta API para monitorear el progreso de la migración.  
También puede usar el comando **eb events** después de la migración para ver el historial de eventos de su entorno.

****DescribeEnvironmentHealth****  
Una acción de la API de Elastic Beanstalk que proporciona información de estado detallada sobre las instancias y otros componentes de un entorno. Esta API se utiliza para comprobar el estado de la aplicación migrada después de la implementación.  
Tras la migración, puede utilizar el comando **eb health** para comprobar el estado de su entorno e identificar cualquier problema que necesite atención.

****HealthD****  
Un agente de monitoreo de Elastic Beanstalk que recopila métricas, monitorea registros e informa sobre el estado de las instancias de EC2 en un entorno. HealthD proporciona informes de estado avanzados sobre las aplicaciones migradas.  
Tras la migración, HealthD monitorea el rendimiento de la aplicación, la utilización de los recursos y las tasas de éxito de las solicitudes, lo que proporciona una visión integral del estado de su entorno.

****Agrupe los registros****  
Característica de Elastic Beanstalk que comprime y carga los registros de las instancias de EC2 a Amazon S3 para un almacenamiento y un análisis centralizados. Esta característica le permite solucionar problemas con las aplicaciones migradas.  
Tras la migración, puede utilizar el comando **eb logs** para recuperar y ver los registros de su entorno.

****aws-windows-deployment-manifest.json****  
Archivo que describe el contenido, las dependencias y la configuración de una aplicación o paquete de software. Este manifiesto se genera durante el proceso de migración para definir cómo deben implementarse las aplicaciones de IIS en Elastic Beanstalk.

****sección personalizada del manifiesto****  
Una sección dentro de `aws-windows-deployment-manifest.json` que proporciona un control personalizado sobre la implementación de las aplicaciones. Esta sección contiene PowerShell los scripts y comandos que se ejecutan durante el proceso de despliegue.  
Durante la migración, se generan secciones personalizadas del manifiesto para gestionar aspectos específicos de la configuración de IIS, como la configuración del directorio virtual, la administración de permisos y la configuración del grupo de aplicaciones.

****CLI DE EB****  
Herramienta de la línea de comandos que proporciona comandos para crear, configurar y administrar aplicaciones y entornos de Elastic Beanstalk. La CLI de EB incluye el comando **eb migrate** específico para migrar aplicaciones de IIS a Elastic Beanstalk.  
Después de la migración, puede continuar utilizando la CLI de EB para administrar el entorno, implementar actualizaciones, monitorear el estado y realizar otras tareas administrativas.

****Configuración de opciones****  
Valores de configuración que definen la forma en que Elastic Beanstalk aprovisiona AWS y configura los recursos en su entorno. La configuración de las opciones se organiza en espacios de nombres que representan los diferentes componentes del entorno, como los equilibradores de carga, las instancias y los procesos del entorno.  
Durante la migración, el comando **eb migrate** genera la configuración de opciones adecuada en función de la configuración de IIS para garantizar que el entorno de nube coincida con las capacidades del entorno de origen. Para obtener más información, consulte las [Opciones de configuración](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html) en la Guía para desarrolladores de Elastic Beanstalk.

****aws:elbv2:listener:default****  
Un espacio de nombres de configuración de Elastic Beanstalk para el oyente predeterminado de un Equilibrador de carga de aplicación. Durante la migración, este espacio de nombres se configura en función de los enlaces del sitio de IIS para garantizar un adecuado enrutamiento del tráfico.  
El oyente predeterminado normalmente gestiona el tráfico HTTP en el puerto 80, que luego se reenvía a las instancias de la aplicación según las reglas de enrutamiento.

****aws:elbv2:listener:listener\$1port****  
Un espacio de nombres de configuración de Elastic Beanstalk para un puerto oyente específico de un Equilibrador de carga de aplicación. Este espacio de nombres se utiliza para configurar oyentes adicionales para las aplicaciones migradas, como HTTPS en el puerto 443.  
Durante la migración, los oyentes se crean en función de los enlaces de puertos de los sitios de IIS, lo que garantiza que las aplicaciones sigan siendo accesibles en los mismos puertos que en el entorno de origen.

****aws:elbv2:regla de escucha: rule\$1name****  
Un espacio de nombres de configuración de Elastic Beanstalk para definir reglas de enrutamiento para un oyente del Equilibrador de carga de aplicación. Estas reglas determinan cómo se enrutan las solicitudes entrantes a los diferentes grupos de destino en función de los patrones de ruta o los encabezados de los hosts.  
Durante la migración, se crean las reglas de oyente para que coincidan con la estructura de URL de las aplicaciones de IIS, lo que garantiza que las solicitudes se dirijan a las rutas de aplicación correctas.

****aws:elasticbeanstalk:environment:process:default****  
Un espacio de nombres de configuración de Elastic Beanstalk para el proceso predeterminado en un entorno. Este espacio de nombres define cómo se configura el proceso predeterminado de la aplicación web, incluida la configuración de comprobación de estado, las asignaciones de puertos y la configuración del proxy.  
Durante la migración, el proceso predeterminado se configura en función de la configuración del sitio de IIS principal, lo que garantiza un adecuado monitoreo del estado y gestión de las solicitudes.

****aws:elasticbeanstalk:environment:process:process\$1name****  
Un espacio de nombres de configuración de Elastic Beanstalk para un proceso denominado específico. Este espacio de nombres le permite definir procesos múltiples con diferentes configuraciones, de forma similar a tener varios grupos de aplicaciones en IIS.  
Durante la migración, se pueden crear procesos adicionales para representar diferentes enlaces de sitios desde el entorno de origen.

**nota**  
Para obtener más información sobre algunos de los términos descritos en este tema, consulte los siguientes recursos:  
[Acciones de la API de Elastic Beanstalk:AWS Elastic Beanstalk API Reference](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/)
Plataformas de Elastic Beanstalk, incluidas las versiones de plataforma compatibles: [Plataformas compatibles](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) en la guía *AWS Elastic Beanstalk Platforms*
Espacios de nombres de configuración de Elastic Beanstalk: [Opciones generales para todos los entornos](command-options-general.md) en esta guía
La CLI de EB o comandos específicos de la CLI de EB: [Configuración de la interfaz de la línea de comandos de EB (CLI de EB) para administrar Elastic Beanstalk](eb-cli3.md) en esta guía

## Términos de Python
<a name="dotnet-migrating-applications-glossary-python"></a>

****pip****  
El instalador de paquetes para Python, utilizado para instalar y administrar paquetes de software escritos en Python. La CLI de EB se instala y actualiza mediante pip.  
Durante el proceso de migración, pip se utiliza para instalar el paquete de la CLI de EB y sus dependencias en el servidor de origen, lo que proporciona las herramientas necesarias para la migración.

****PyPI****  
Python Package Index, el repositorio oficial de paquetes de software de Python de terceros, desde el cual pip recupera e instala paquetes. La CLI de EB y sus dependencias se alojan en PyPI.  
Cuando se instala la CLI de EB para la migración, pip se conecta a PyPI para descargar e instalar los paquetes necesarios.

****virtualenv****  
Una herramienta para crear entornos de Python aislados, que permite que diferentes proyectos tengan sus propias dependencias y paquetes sin conflictos. Se recomienda usar virtualenv cuando instale la CLI de EB para evitar conflictos con otras aplicaciones de Python.  
La creación de un entorno virtual antes de instalar la CLI de EB garantiza que las herramientas de migración tengan un entorno limpio y aislado con las dependencias correctas.

****pywin32****  
Un conjunto de extensiones de Python que proporcionan acceso a muchos de los Windows APIs, lo que permite la interacción con el sistema operativo Windows y sus componentes. La CLI de EB utiliza pywin32 para interactuar con características específicas de Windows durante la migración.  
Durante el proceso de migración, se utiliza pywin32 para acceder a la configuración de IIS, a los ajustes del registro de Windows y a otra información del sistema necesaria para empaquetar y migrar correctamente las aplicaciones.

****pythonnet****  
Un paquete que permite que el código de Python interactúe con las aplicaciones .NET Framework y .NET Core. Esta integración permite que la CLI de EB funcione con componentes de .NET durante el proceso de migración.  
El proceso de migración puede utilizar pythonnet para interactuar con los ensamblajes y componentes de .NET cuando analiza y empaqueta las aplicaciones para su implementación en Elastic Beanstalk.

# Realización de migraciones básicas de IIS
<a name="dotnet-migrating-applications-basic-migration"></a>

En esta sección, se detalla el proceso de migración de las aplicaciones de IIS a Elastic Beanstalk mediante el comando **eb migrate**.

## Exploración de su entorno de IIS
<a name="dotnet-migrating-applications-basic-migration-exploring"></a>

Antes de realizar cualquier cambio, querrá saber qué recursos existen en su servidor. Comience por explorar sus sitios de IIS mediante la ejecución de **eb migrate explore**, como se muestra en el siguiente ejemplo:

```
PS C:\migrations_workspace> eb migrate explore
```

Este comando revela sus sitios de IIS. Consulte la siguiente lista:

```
Default Web Site
Intranet
API.Internal
Reports
```

Para obtener una vista detallada de la configuración de cada sitio, incluidos los enlaces, las aplicaciones y los directorios virtuales, añada la opción `--verbose`, como se muestra en este ejemplo:

```
PS C:\migrations_workspace> eb migrate explore --verbose
```

En la siguiente lista se muestra la información completa sobre el entorno que proporciona el comando:

```
1: Default Web Site:
  - Bindings:
    - *:80:www.example.com
    - *:443:www.example.com
  - Application '/':
    - Application Pool: DefaultAppPool
    - Enabled Protocols: http
    - Virtual Directories:
      - /:
        - Physical Path: C:\inetpub\wwwroot
        - Logon Method: ClearText
  - Application '/api':
    - Application Pool: ApiPool
    - Enabled Protocols: http
    - Virtual Directories:
      - /:
        - Physical Path: C:\websites\api
        - Logon Method: ClearText
2: Intranet:
...
3. API.Internal:
...
4. Reports:
...
```

### Comprensión del resultado de la detección
<a name="dotnet-migrating-applications-basic-migration-exploring-output"></a>

El resultado detallado proporciona la siguiente información fundamental para la planificación de la migración:

Sitios  
El resultado de la detección muestra una lista de todos los sitios de IIS en su servidor. Cada sitio se identifica por su nombre (por ejemplo, «Sitio web predeterminado», «Intranet», «API.internal») y se numera secuencialmente. Cuando hay sitios múltiples en un servidor, el comando `eb migrate` puede empaquetarlos e implementarlos por separado o juntos, según la estrategia de migración.

Enlaces  
Los enlaces de protocolos revelan qué protocolos (HTTP/HTTPS) utilizan sus sitios y en qué puertos funcionan. La información de enlace incluye los requisitos de encabezado del host que definen las configuraciones de enrutamiento basadas en el dominio.

Aplicaciones  
Las rutas de aplicación muestran las estructuras de aplicaciones raíz y anidadas dentro de la configuración de IIS. Las asignaciones de grupos de aplicaciones indican cómo se aíslan las aplicaciones entre sí para la seguridad y la administración de los recursos.

Directorios virtuales  
Las asignaciones de rutas físicas indican dónde reside el contenido en el sistema de archivos. La configuración de autenticación muestra requisitos de acceso especiales que deben mantenerse después de la migración.

## Preparación para la migración
<a name="dotnet-migrating-applications-basic-migration-preparing"></a>

Con una comprensión de su entorno, asegúrese de que el servidor cumple los requisitos previos. En primer lugar, compruebe la versión de IIS con el siguiente PowerShell comando:

```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\InetStp\" -Name MajorVersion
```

Necesita IIS 7.0 o una versión posterior. La herramienta de migración utiliza Web Deploy 3.6 para empaquetar las aplicaciones. Verifique su instalación mediante el siguiente comando:



```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\3" -Name InstallPath
```

Si Web Deploy no está instalado en su servidor, puede descargarlo desde la página de descargas de [Microsoft Web Platform Installer](https://www.iis.net/downloads/microsoft/web-deploy).

## Su primera migración
<a name="dotnet-migrating-applications-basic-migration-first"></a>

Empecemos con una migración básica del sitio web predeterminado. En el siguiente ejemplo, se muestra el comando más simple, **eb migrate**.

```
PS C:\migrations_workspace> eb migrate
```

Este comando inicia una serie de pasos automatizados, como se muestra en el siguiente resultado de ejemplo:

```
Identifying VPC configuration of this EC2 instance (i-0123456789abcdef0)
  id: vpc-1234567890abcdef0
  publicip: true
  elbscheme: public
  ec2subnets: subnet-123,subnet-456,subnet-789
  securitygroups: sg-123,sg-456
  elbsubnets: subnet-123,subnet-456,subnet-789

Using .\migrations\latest to contain artifacts for this migration run.
Generating source bundle for sites, applications, and virtual directories...
  Default Web Site/ -> .\migrations\latest\upload_target\DefaultWebSite.zip
```

La herramienta de migración crea un directorio estructurado que contiene los artefactos de la implementación. La siguiente lista muestra la estructura del directorio:

```
C:\migration_workspace\
└── .\migrations\latest\
    └── upload_target\
        ├── DefaultWebSite.zip
        ├── aws-windows-deployment-manifest.json
        └── ebmigrateScripts\
            ├── site_installer.ps1
            ├── permission_handler.ps1
            └── >other helper scripts<
```

## Control de la migración
<a name="dotnet-migrating-applications-basic-migration-controlling"></a>

Para tener más control sobre el proceso de migración, puede especificar exactamente qué sitios migrar con el siguiente comando:

```
PS C:\migrations_workspace> eb migrate --sites "Default Web Site,Intranet"
```

También puede personalizar el nombre del entorno y el nombre de la aplicación, como se muestra en el siguiente ejemplo de comando:

```
PS C:\migrations_workspace> eb migrate `
    --sites "Default Web Site" `
    --application-name "CorporateApp" `
    --environment-name "Production"
```

Para obtener una lista completa de opciones, consulte [**eb migrate**](eb3-migrate.md).

## Monitoreo del progreso
<a name="dotnet-migrating-applications-basic-migration-monitoring"></a>

Durante la migración, **eb migrate** proporciona actualizaciones de estado en tiempo real. Consulte el siguiente ejemplo de resultado:

```
...
Creating application version
Creating environment... This may take a few minutes

2024-03-18 18:12:15    INFO    Environment details for: Production
  Application name: CorporateApp
  Region: us-west-2
  Deployed Version: app-230320_153045
  Environment ID: e-abcdef1234
  Platform: 64bit Windows Server 2019 v2.7.0 running IIS 10.0
  Tier: WebServer-Standard-1.0
  CNAME: production.us-west-2.elasticbeanstalk.com
  Updated: 2024-03-20 15:30:45
2025-03-18 18:12:17    INFO    createEnvironment is starting.
2025-03-18 18:12:19    INFO    Using elasticbeanstalk-us-east-1-180301529717 as Amazon S3 storage bucket for environment data.
2025-03-18 18:12:40    INFO    Created security group named: sg-0fdd4d696a26b086a
2025-03-18 18:12:48    INFO    Environment health has transitioned to Pending. Initialization in progress (running for 7 seconds). There are no instances.
...
2025-03-18 18:23:59    INFO    Application available at EBMigratedEnv-arrreal3.us-east-1.elasticbeanstalk.com.
2025-03-18 18:24:00    INFO    Successfully launched environment: EBMigratedEnv-arrreal3
```

## Comprobación de la migración
<a name="dotnet-migrating-applications-basic-migration-verifying"></a>

Una vez que el entorno esté listo, Elastic Beanstalk proporciona varias formas de comprobar la implementación.

Acceso a su aplicación  
Abra la URL de la aplicación (CNAME) en un navegador web para comprobar que funciona correctamente.

Comprobación del estado del entorno  
Utilice el comando **eb health** para ver el estado de su entorno.  

```
PS C:\migrations_workspace> eb health
```
La siguiente imagen de pantalla muestra el estado de la instancia, las métricas de respuesta de las aplicaciones y la utilización de los recursos del sistema.  

![\[El resultado del comando eb health muestra el estado de la instancia, las métricas de respuesta de las aplicaciones y la utilización de los recursos del sistema.\]](http://docs.aws.amazon.com/es_es/elasticbeanstalk/latest/dg/images/eb-health-after-migration.png)


Utilice el comando **eb logs** para acceder a los registros y solucionar cualquier problema:  

```
PS C:\migrations_workspace> eb logs --zip
```
El comando **eb logs** descarga los registros en el directorio `.elasticbeanstalk/logs`. Para obtener más información, consulte [Uso de Elastic CloudWatch Beanstalk con Amazon Logs](AWSHowTo.cloudwatchlogs.md).

Conexión a instancias  
Si especificó un par de claves durante la migración, puede conectarse a sus instancias mediante RDP para solucionar problemas directamente.

Acceso a la consola de Elastic Beanstalk  
Puede ver el estado, los registros y las propiedades de configuración del entorno a través de la [consola de administración del entorno](environments-console.md) correspondiente a ese entorno. 

## Administración de artefactos de migración
<a name="dotnet-migrating-applications-basic-migration-cleanup"></a>

El comando **eb migrate** crea artefactos locales durante el proceso de migración. Estos artefactos contienen información confidencial y, con el tiempo, pueden consumir una cantidad considerable de espacio en el disco. Utilice el subcomando **cleanup** para administrar estos artefactos, como se muestra en el siguiente ejemplo:

```
PS C:\migrations_workspace> eb migrate cleanup
Are you sure you would like to cleanup older artifacts within ./migrations/? (Y/N):
```

Para forzar la limpieza sin confirmación, utilice la opción **--force**:

```
PS C:\migrations_workspace> eb migrate cleanup --force
```

El proceso de limpieza conserva la migración correcta más reciente del directorio de `./migrations/latest` y elimina los directorios de migración más antiguos.

# Configuración de red y ajustes de puerto
<a name="dotnet-migrating-applications-network"></a>

En esta sección, se describen las opciones de configuración de red para las migraciones de IIS, incluidas la configuración de la VPC, la configuración de los puertos y las implementaciones en sitios múltiples.

## Configuración de la VPC
<a name="dotnet-migrating-applications-network-vpc"></a>

El comando **eb migrate** proporciona opciones de configuración de la VPC flexibles para el entorno de Elastic Beanstalk. La herramienta puede detectar la configuración de la VPC de una instancia de EC2 de origen o aceptar la configuración de la VPC personalizada mediante parámetros de la línea de comandos. Revise [Uso de Elastic Beanstalk con Amazon VPC](vpc.md) para entender cómo configurar Elastic Beanstalk con la VPC.

### Detección automática de VPC
<a name="dotnet-migrating-applications-network-vpc-auto"></a>

Cuando **eb migrate** se ejecuta en una instancia de EC2, detecta y utiliza automáticamente la configuración de la VPC de las instancias de EC2 del entorno de origen. El siguiente ejemplo de resultado ilustra la información de configuración que detecta:

```
PS C:\migrations_workspace > eb migrate
Identifying VPC configuration of this EC2 instance (i-0123456789abcdef0):
  id: vpc-1234567890abcdef0
  publicip: true
  elbscheme: public
  ec2subnets: subnet-123,subnet-456,subnet-789
  securitygroups: sg-123,sg-456
  elbsubnets: subnet-123,subnet-456,subnet-789
...
```

La configuración detectada incluye:
+ Identificador de VPC
+ Configuración de asignación de IP pública
+ Esquema del equilibrador de carga (público/privado)
+ Asignaciones de subredes de instancias de EC2
+ Asociaciones de grupos de seguridad
+ Asignaciones de subredes del equilibrador de carga

### Hosts locales o no AWS en la nube
<a name="dotnet-migrating-applications-network-vpc-onprem"></a>

Cuando **eb migrate** se ejecuta desde un servidor local o un host que no sea de AWS nube, el servicio Elastic Beanstalk utilizará la VPC predeterminada de su cuenta. AWS La siguiente lista muestra un ejemplo de comando y salida:

```
PS C:\migrations_worspace> eb migrate `
      -k windows-test-pem `
      --region us-east-1 `
      -a EBMigratedEnv `
      -e EBMigratedEnv-test2 `
      --copy-firewall-config
Determining EB platform based on host machine properties
Using .\migrations\latest to contain artifacts for this migration run.
...
```

Revise [Uso de Elastic Beanstalk con Amazon VPC](vpc.md) para comprender cómo Elastic Beanstalk configura la VPC predeterminada para su entorno.

### Configuración personalizada de la VPC
<a name="dotnet-migrating-applications-network-vpc-custom"></a>

Para cualquier entorno de origen (EC2, local o no en la AWS nube) en el que necesite una configuración de VPC específica, proporcione un archivo de configuración de VPC como el que se muestra en el siguiente ejemplo:

```
{
    "id": "vpc-12345678",
    "publicip": "true",
    "elbscheme": "public",
    "ec2subnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"],
    "securitygroups": "sg-123456,sg-789012",
    "elbsubnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"]
}
```

Aplique esta configuración con el siguiente comando:

```
PS C:\migrations_workspace> eb migrate --vpc-config vpc-config.json
```

**nota**  
El archivo de configuración de la VPC requiere el campo `id` que especifica el ID de la VPC. Todos los demás campos son opcionales y Elastic Beanstalk utilizará los valores predeterminados para los campos que no especifique.

**importante**  
*La migración ignorará cualquier configuración de la VPC existente en el entorno de origen cuando especifiques el *parámetro* `--vpc-config`*. Cuando usa este parámetro, la migración usará solamente la configuración de la VPC especificada en el archivo de configuración que está transfiriendo. El uso de este parámetro anula el comportamiento predeterminado de detección de la configuración de VPC de la instancia de origen o de uso de la VPC predeterminada.

Utilice el parámetro `--vpc-config` en los siguientes escenarios:
+ Cuando migre entornos que no son de EC2 y que no tienen configuraciones de VPC detectables.
+ Cuando migre a una VPC diferente de la utilizada por el entorno de origen.
+ Cuando necesite personalizar las selecciones de subredes o las configuraciones de los grupos de seguridad.
+ Cuando la detección automática no identifica correctamente la configuración deseada de la VPC.
+ Cuando realiza una migración desde una configuración en las instalaciones y no desea utilizar la VPC predeterminada.

### Configuración de seguridad de la red
<a name="dotnet-migrating-applications-network-vpc-security"></a>

De forma predeterminada, **eb migrate** abre el puerto 80 en las instancias de destino, pero no copia otras reglas de Firewall de Windows de la máquina de origen. Para incluir todas las configuraciones de firewall, utilice el siguiente comando:

```
PS C:\migrations_workspace> eb migrate --copy-firewall-config
```

Este comando realiza las siguientes acciones:
+ Identifica los puertos utilizados por los enlaces de sitios de IIS.
+ Recupera las reglas de firewall correspondientes.
+ Genera PowerShell scripts para recrear las reglas en las instancias de destino
+ Conserva todas las reglas de DENEGACIÓN para el puerto 80 de la máquina de origen (de lo contrario, el puerto 80 está habilitado de forma predeterminada).

Considere un caso de uso en el que la máquina de origen tenga las reglas de firewall especificadas en el siguiente ejemplo:

```
# Source machine firewall configuration
Get-NetFirewallRule | Where-Object {$_.Enabled -eq 'True'} | Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq 80 -or $_.LocalPort -eq 443 -or $_.LocalPort -eq 8081}
# Output shows rules for ports 80, 443, and 8081
```

La migración crea un script (`modify_firewall_config.ps1`) que contiene la siguiente configuración:

```
New-NetFirewallRule -DisplayName "Allow Web Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80,443
New-NetFirewallRule -DisplayName "Allow API Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8081
```

La herramienta de migración realiza automáticamente las siguientes acciones:
+ Extrae HTTP/HTTPS los puertos de todos los enlaces de sitios de IIS
+ Utiliza la interfaz Firewall [INetFwPolicy2](https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwpolicy2) de Windows para enumerar las reglas del firewall
+ Filtra las reglas para incluir únicamente aquellas que hacen referencia explícita a los puertos especificados.
+ Procesa únicamente los enlaces de sitios HTTP y HTTPS y sus reglas de firewall asociadas.
+ Conserva las propiedades de las reglas, incluidos el nombre para mostrar, la acción, el protocolo y el estado de activación.
+ Gestiona tanto los puertos individuales como los rangos de puertos en las reglas del firewall.
+ Agrega el script de configuración del firewall al manifiesto de implementación.

### Configuración del equilibrador de carga
<a name="dotnet-migrating-applications-network-vpc-lb"></a>

Puede especificar la configuración del equilibrador de carga mediante el argumento `--vpc-config`. El siguiente ejemplo muestra los parámetros.

Selección de esquemas  
Elige entre esquemas públicos y privados del equilibrador de carga:  

```
{
    "id": "vpc-12345678",
    "elbscheme": "private",
    "elbsubnets": ["subnet-private1", "subnet-private2"]
}
```

Distribución de subredes  
Para obtener una alta disponibilidad, distribuya las subredes del equilibrador de carga entre las zonas de disponibilidad:  

```
{
    "elbsubnets": [
        "subnet-az1", // Availability Zone 1
        "subnet-az2", // Availability Zone 2
        "subnet-az3"  // Availability Zone 3
    ]
}
```

**nota**  
Si bien Elastic Beanstalk admite la creación de entornos con Equilibradores de carga de aplicación, Equilibradores de carga de red y Equilibradores de carga clásicos, el comando **eb migrate** admite solamente Equilibradores de carga de aplicación. Para obtener más información acerca de los tipos de equilibrador de carga, consulte [Balanceador de carga del entorno de Elastic Beanstalk](using-features.managing.elb.md).

## Implementaciones en sitios múltiples con configuraciones de puertos
<a name="dotnet-migrating-applications-network-multi"></a>

El comando **eb migrate** gestiona implementaciones complejas de IIS en sitios múltiples en los que las aplicaciones pueden compartir dependencias o utilizar puertos no estándar. Considere el siguiente ejemplo de una configuración empresarial típica con sitios múltiples:

```
<!-- IIS Configuration -->
<sites>
    <site name="Default Web Site" id="1">
        <bindings>
            <binding protocol="http" bindingInformation="*:80:www.example.com" />
        </bindings>
    </site>
    <site name="InternalAPI" id="2">
        <bindings>
            <binding protocol="http" bindingInformation="*:8081:api.internal" />
        </bindings>
    </site>
    <site name="ReportingPortal" id="3">
        <bindings>
            <binding protocol="http" bindingInformation="*:8082:reports.internal" />
        </bindings>
    </site>
</sites>
```

Para migrar esta configuración, utilice el siguiente ejemplo de comandos y parámetros:

```
PS C:\migrations_workspace> eb migrate `
    --sites "Default Web Site,InternalAPI,ReportingPortal" `
    --copy-firewall-config `
    --instance-type "c5.large"
```

El comando **eb migrate** crea un paquete de implementación que preserva la identidad y la configuración de cada sitio. El comando genera un comando `aws-windows-deployment-manifest.json` que define cómo se deben implementar estos sitios. En el siguiente ejemplo se muestra un archivo json generado:

```
{
    "manifestVersion": 1,
    "deployments": {
        "msDeploy": [
            {
                "name": "DefaultWebSite",
                "parameters": {
                    "appBundle": "DefaultWebSite.zip",
                    "iisPath": "/",
                    "iisWebSite": "Default Web Site"
                }
            }
        ],
        "custom": [
            {
                "name": "InternalAPI",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\install_site_InternalAPI.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\restart_site_InternalAPI.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\uninstall_site_InternalAPI.ps1"
                    }
                }
            },
            {
                "name": "ReportingPortal",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\install_site_ReportingPortal.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\restart_site_ReportingPortal.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\uninstall_site_ReportingPortal.ps1"
                    }
                }
            }
        ]
    }
}
```

El proceso de migración crea las siguientes reglas de oyente del Equilibrador de carga de aplicación que mantienen la lógica de enrutamiento original:
+ El tráfico del puerto 80 se enruta al sitio web predeterminado.
+ El tráfico del puerto 8081 se enruta a la API interna.
+ El tráfico del puerto 8082 se dirige a ReportingPortal

## Configuración y dependencias compartidas
<a name="dotnet-migrating-applications-network-shared"></a>

Cuando los sitios comparten configuraciones o dependencias, **eb migrate** gestiona estas relaciones de forma adecuada. Consulte el siguiente ejemplo en el que sitios múltiples comparten una configuración común:

```
<!-- Shared configuration in applicationHost.config -->
<location path="Default Web Site">
    <system.webServer>
        <asp enableSessionState="true" />
        <caching enabled="true" enableKernelCache="true" />
    </system.webServer>
</location>
```

Durante el proceso de migración se completan las siguientes tareas:

1. Identifica las configuraciones compartidas en todos los sitios.

1. Genera los PowerShell scripts adecuados para aplicar esta configuración

1. Mantiene la jerarquía y la herencia de la configuración.

## Prácticas recomendadas
<a name="dotnet-migrating-applications-network-best"></a>

Recomendamos que siga estas prácticas recomendadas para la configuración de red de la aplicación migrada. Las siguientes agrupaciones proporcionan un resumen de las directrices.

Diseño de VPC  
+ Siga las AWS prácticas recomendadas de diseño de VPC
+ Utilice subredes independientes para los equilibradores de carga y las instancias de EC2.
+ Implemente tablas de enrutamiento adecuadas y NACLs
+ Considere los puntos finales de VPC para los servicios AWS 

Alta disponibilidad  
+ Implemente en varias zonas de disponibilidad
+ Use al menos dos subredes para los equilibradores de carga.
+ Configura el autoscaling entre AZs
+ Implemente una comprobación de estado adecuada.

Seguridad  
+ Seguimiento de las prácticas de seguridad recomendadas
+ Utilice los grupos de seguridad como control de acceso principal.
+ Implemente listas de control de acceso a la red (ACLs) para mayor seguridad
+ Supervise los registros de flujo de la VPC.

## Resolución de problemas
<a name="dotnet-migrating-applications-network-troubleshooting"></a>

Los problemas comunes de configuración de red incluyen las siguientes áreas. Después de cada tema, hay comandos de ejemplo para obtener más información sobre la configuración de la red y el estado de su entorno.

Configuración de subredes  

```
# Verify subnet availability
PS C:\migrations_workspace> aws ec2 describe-subnets --subnet-ids subnet-id

# Check available IP addresses
PS C:\migrations_workspace>aws ec2 describe-subnets --subnet-ids subnet-id --query 'Subnets[].AvailableIpAddressCount'
```

Acceso al grupo de seguridad  

```
# Verify security group rules
PS C:\migrations_workspace> aws ec2 describe-security-groups --group-ids sg-id

# Test network connectivity
PS C:\migrations_workspace> aws ec2 describe-network-interfaces --filters Name=group-id,Values=sg-id
```

Estado del equilibrador de carga  

```
# Check load balancer health
PS C:\migrations_workspace> aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:region:account-id:targetgroup/group-name/group-id
```

# Configuraciones de seguridad y roles de IAM
<a name="dotnet-migrating-applications-security"></a>

El **eb migrate** comando administra las configuraciones AWS de seguridad mediante funciones de IAM, perfiles de instancia y funciones de servicio. La comprensión de estos componentes garantiza un control de acceso adecuado y el cumplimiento de las normas de seguridad durante la migración.

## Configuración de perfiles de instancia
<a name="dotnet-migrating-applications-security-instance"></a>

Un perfil de instancia sirve de contenedor para un rol de IAM que Elastic Beanstalk asocia a las instancias de EC2 de su entorno. Cuando ejecuta **eb migrate**, puede especificar un perfil de instancia personalizado:

```
PS C:\migrations_workspace> eb migrate --instance-profile "CustomInstanceProfile"
```

Si no especifica un perfil de instancia, **eb migrate** crea un perfil predeterminado con los siguientes permisos:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::elasticbeanstalk-*",
                "arn:aws:s3:::elasticbeanstalk-*/*"
            ]
        }
    ]
}
```

------

## Administración de roles de servicio
<a name="dotnet-migrating-applications-security-service"></a>

Un rol de servicio permite a Elastic Beanstalk administrar los recursos en AWS su nombre. Especifique un rol de servicio personalizado durante la migración con el siguiente comando:

```
PS C:\migrations_workspace> eb migrate --service-role "CustomServiceRole"
```

Si no se especifica, **eb migrate** crea un rol de servicio predeterminado denominado `aws-elasticbeanstalk-service-role` con una política de confianza que permite que Elastic Beanstalk asuma el rol. Este rol de servicio es esencial para que Elastic Beanstalk monitoree el estado del entorno y realice actualizaciones de plataformas administradas. El rol de servicio requiere dos políticas administradas:
+ `AWSElasticBeanstalkEnhancedHealth`: permite que Elastic Beanstalk monitoree el estado de las instancias y del entorno mediante el sistema mejorado de informes de estado.
+ `AWSElasticBeanstalkManagedUpdates`: permite que Elastic Beanstalk realice actualizaciones de plataforma administradas, incluida la actualización de los recursos del entorno cuando hay una nueva versión de la plataforma disponible.

Con estas políticas, el rol de servicio tiene permisos para lo siguiente:
+ Crear y administrar grupos de escalado automático
+ Crear y administrar Equilibradores de carga de aplicación
+ Sube registros a Amazon CloudWatch
+ Administrar instancias de EC2

Para obtener más información sobre los roles de servicio, consulte [Rol de servicio de Elastic Beanstalk](concepts-roles-service.md) en la Guía para desarrolladores de Elastic Beanstalk.

## Configuración del grupo de seguridad
<a name="dotnet-migrating-applications-security-sg"></a>

El comando **eb migrate** configura automáticamente los grupos de seguridad en función de los enlaces de sitios de IIS. Por ejemplo, si el entorno de origen tiene sitios que utilizan los puertos 80, 443 y 8081, se obtiene la siguiente configuración:

```
<site name="Default Web Site">
    <bindings>
        <binding protocol="http" bindingInformation="*:80:" />
        <binding protocol="https" bindingInformation="*:443:" />
    </bindings>
</site>
<site name="InternalAPI">
    <bindings>
        <binding protocol="http" bindingInformation="*:8081:" />
    </bindings>
</site>
```

Durante el proceso de migración se completan las siguientes acciones:
+ Crea un grupo de seguridad del equilibrador de carga que permite el tráfico entrante en los puertos 80 y 443 desde Internet (0.0.0.0/0).
+ Crea un grupo de seguridad de EC2 que permite el tráfico procedente del equilibrador de carga.
+ Configura puertos adicionales (como el 8081) si se especifica `--copy-firewall-config`.

De forma predeterminada, el Equilibrador de carga de aplicación está configurado con acceso público desde Internet. Si necesita personalizar este comportamiento, por ejemplo, restringir el acceso a rangos de IP específicos o usar un equilibrador de carga privado, puede anular la configuración predeterminada de VPC y de los grupos de seguridad mediante el parámetro `--vpc-config`:

```
PS C:\migrations_workspace> eb migrate --vpc-config vpc-config.json
```

Por ejemplo, la siguiente configuración de `vpc-config.json` crea un equilibrador de carga privado en una subred privada:

```
{
    "id": "vpc-12345678",
    "publicip": "false",
    "elbscheme": "internal",
    "ec2subnets": ["subnet-private1", "subnet-private2"],
    "elbsubnets": ["subnet-private1", "subnet-private2"]
}
```

Para obtener más información acerca de las opciones de configuración de VPS, consulte [Configuración de la VPC](dotnet-migrating-applications-network.md#dotnet-migrating-applications-network-vpc).

## Integración de certificados SSL
<a name="dotnet-migrating-applications-security-ssl"></a>

Al migrar sitios con enlaces HTTPS, integre los certificados SSL mediante AWS Certificate Manager (ACM):

```
PS C:\migrations_workspace> eb migrate --ssl-certificates "arn:aws:acm:region:account:certificate/certificate-id"
```

Esta configuración completa las siguientes acciones:
+ Asocia el certificado al Equilibrador de carga de aplicación.
+ Mantiene la finalización HTTPS en el equilibrador de carga.
+ Conserva la comunicación HTTP interna entre el equilibrador de carga y las instancias de EC2.

## Autenticación de Windows
<a name="dotnet-migrating-applications-security-windows"></a>

En el caso de las aplicaciones que utilizan la autenticación de Windows, **eb migrate** conserva la configuración de autenticación en la `web.config` de la aplicación de la siguiente manera:

```
<configuration>
    <system.webServer>
        <security>
            <authentication>
                <windowsAuthentication enabled="true">
                    <providers>
                        <add value="Negotiate" />
                        <add value="NTLM" />
                    </providers>
                </windowsAuthentication>
            </authentication>
        </security>
    </system.webServer>
</configuration>
```

**importante**  
El comando **eb migrate** no copia perfiles o cuentas de usuario del entorno de origen a las instancias de Elastic Beanstalk de destino. Todas las cuentas de usuario o grupos personalizados que haya creado en el servidor de origen deberán volver a crearse en el entorno de destino tras la migración.

Las cuentas como `IUSR` y los grupos como `IIS_IUSRS`, integrados con Windows, además del resto de las cuentas y los grupos integrados, se incluyen de forma predeterminada en las instancias de Windows Server de destino. Para obtener más información acerca de las cuentas y los grupos de IIS integrados, consulte [Comprensión de las cuentas de usuario y de grupo integradas en IIS](https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis) en la documentación de Microsoft.

Si la aplicación se basa en cuentas de usuario de Windows personalizadas o en la integración con Active Directory, tendrá que configurar estos aspectos por separado una vez finalizada la migración.

## Prácticas recomendadas y solución de problemas
<a name="dotnet-migrating-applications-security-best"></a>

### Administración de roles
<a name="dotnet-migrating-applications-security-best-role"></a>

Implemente las mejores prácticas de AWS IAM al gestionar las funciones de sus entornos de Elastic Beanstalk:

Creación y administración de roles  
+ Siempre que sea posible, cree roles mediante políticas administradas AWS 
+ Siga las [prácticas recomendadas de seguridad para IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html).
+ Utilice el [generador de políticas de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) para crear políticas personalizadas.
+ Implemente [límites de permisos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) para mayor seguridad.

Monitoreo y auditoría  
Habilite AWS CloudTrail para monitorear el uso de los roles:  
+ Siga la [Guía del usuario de AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ Configure la integración CloudWatch de los registros para la supervisión en tiempo real
+ Configure alertas para llamadas a la API no autorizadas.

Proceso de revisión regular  
Establezca un ciclo de revisión trimestral para realizar las siguientes tareas:  
+ Auditar los permisos no utilizados mediante [Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ Eliminar permisos obsoletos
+ Actualizar los roles según los principios de privilegios mínimos

### Administración de certificados
<a name="dotnet-migrating-applications-security-best-cert"></a>

Implemente estas prácticas para SSL/TLS los certificados en sus entornos de Elastic Beanstalk:

Ciclo del certificado  
+ Utilice [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) para la administración de certificados.
+ Habilite la [renovación automática](https://docs.aws.amazon.com/acm/latest/userguide/check-certificate-renewal-status.html) de los certificados emitidos por ACM.
+ Configure las [notificaciones de caducidad](https://docs.aws.amazon.com/acm/latest/userguide/notifications-for-ACM.html).

Estándares de seguridad  
+ Utilice TLS 1.2 o una versión posterior
+ Siga las [políticas de seguridad de AWS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) para los oyentes de HTTPS.
+ De ser necesario, implemente HTTP Strict Transport Security (HSTS).

### Administración de los grupos de seguridad.
<a name="dotnet-migrating-applications-security-best-sg"></a>

Implemente estas prácticas recomendadas para grupos de seguridad:

Administración de reglas  
+ Documente todos los requisitos de puertos personalizados.
+ Utilice los [registros de flujo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) para monitorear el tráfico.
+ Siempre que sea posible, utilice [reglas de referencia de grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) en lugar de rangos de IP.

Auditoría regular  
Establezca revisiones mensuales para realizar las siguientes tareas:  
+ Identificar y eliminar las reglas no utilizadas
+ Valide los requisitos source/destination 
+ Comprobar si hay reglas superpuestas

### Registro y supervisión
<a name="dotnet-migrating-applications-security-best-logging"></a>

Para un monitoreo de seguridad eficaz, configure los siguientes registros:

Registros de eventos de Windows en instancias de EC2  

```
# Review Security event log
PS C:\migrations_workspace> Get-EventLog -LogName Security -Newest 50

# Check Application event log
PS C:\migrations_workspace> Get-EventLog -LogName Application -Source "IIS*"
```

CloudWatch Integración de registros  
Configure el agente de CloudWatch registros para que transmita los registros de eventos de Windows a CloudWatch fin de centralizar la supervisión y las alertas.

En caso de problemas persistentes, recopile estos registros y póngase en contacto AWS Support con la siguiente información:
+ ID del entorno
+ ID de implementación (si corresponde)
+ Mensajes de error relevantes
+ Cronología de los cambios de seguridad

# Comprensión de la asignación de la migración de IIS a Elastic Beanstalk
<a name="dotnet-migrating-applications-mapping"></a>

La migración de IIS a Elastic Beanstalk implica asignar la configuración del servidor Windows local a los recursos de la nube. AWS Comprender esta asignación es crucial para el éxito de las migraciones y la administración posterior a la migración.

## Sitios y aplicaciones de IIS en Elastic Beanstalk
<a name="dotnet-migrating-applications-mapping-sites"></a>

En IIS, un sitio web representa un conjunto de aplicaciones web y directorios virtuales, cada uno con su propia configuración y contenido. Cuando se migra a Elastic Beanstalk, estos componentes se transforman de la siguiente manera:

**Sitios web de IIS**  
Los sitios web de IIS se convierten en aplicaciones dentro de Elastic Beanstalk. La configuración de cada sitio web, incluidos sus enlaces, grupos de aplicaciones y ajustes de autenticación, se conserva en el manifiesto de implementación de Elastic Beanstalk (`aws-windows-deployment-manifest.json`).  
Por ejemplo, si tiene varios sitios, como el *sitio web predeterminado *IntranetSite**, y **eb migrate** empaqueta el contenido y la configuración de cada sitio manteniendo su aislamiento.  
El comando crea reglas de oyente del Equilibrador de carga de aplicación (ALB) adecuadas para gestionar las solicitudes de enrutamiento a sus aplicaciones. También configura los grupos de seguridad para garantizar el acceso adecuado a los puertos en función de los enlaces de IIS originales.

**Grupos de aplicaciones**  
Los grupos de aplicaciones de IIS proporcionan capacidades de aislamiento de los procesos de trabajo, administración del tiempo de ejecución y reciclaje para sus aplicaciones. En Elastic Beanstalk, se asignan a los procesos del entorno definidos `aws:elasticbeanstalk:environment:process` mediante el espacio de nombres y configurados mediante IIS en las instancias. EC2   
La migración conserva la configuración crítica del grupo de aplicaciones, e incluye lo siguiente:  
+ Configuraciones del modelo de proceso: identidad (o cuentas personalizadas) ApplicationPoolIdentity NetworkService, configuración de tiempo de espera de inactividad e intervalos de reciclaje de procesos
+ Configuración de la versión de CLR de .NET: mantiene la versión de .NET Framework especificada (v2.0, v4.0 o sin código administrado) para garantizar la compatibilidad de las aplicaciones
+ Modo de canalización gestionado: conserva la configuración del modo de canalización integrado o clásico para mantener la arquitectura de procesamiento de solicitudes HTTP
+ Configuración avanzada: longitud de la cola, límites de CPU, umbrales de protección contra errores rápidos y límites de tiempo de startup
El comando **eb migrate** conserva las asignaciones entre sitios y grupos de aplicaciones durante la migración al entorno de Elastic Beanstalk.  
Si sus grupos de aplicaciones utilizan programas de reciclaje personalizados (tiempos o umbrales de memoria específicos), estos se implementan mediante PowerShell scripts incluidos en el paquete de implementación que configuran los ajustes de IIS adecuados en las EC2 instancias.

**Enlaces de sitios web**  
Los enlaces de sitios web de IIS, que definen la forma en que los clientes acceden a las aplicaciones, se transforman en las siguientes configuraciones del Equilibrador de carga de aplicación (ALB):  
+ Los enlaces de puertos se asignan a las reglas de oyente del ALB correspondientes.
+ Las configuraciones de los encabezados del host se traducen en reglas de enrutamiento del ALB.
+ Los sitios habilitados para SSL utilizan AWS Certificate Manager (ACM) para la administración de certificados

## Administración de directorios virtuales y rutas de aplicaciones
<a name="dotnet-migrating-applications-mapping-virtual-dirs"></a>

Los directorios y aplicaciones virtuales de IIS proporcionan una asignación de rutas URL a los directorios físicos. Elastic Beanstalk mantiene estas relaciones mediante los siguientes constructos:

**Directorios virtuales**  
El proceso de migración conserva las rutas físicas de los directorios virtuales en el paquete de implementación.  
Las asignaciones de rutas se configuran en la configuración de IIS de las EC2 instancias, lo que garantiza que la estructura de URL permanezca intacta después de la migración.

**Rutas físicas de la unidad que no contiene el sistema**  
De forma predeterminada, los entornos Windows de Elastic Beanstalk aprovisionan solamente la unidad C:\$1 (volumen raíz). En la versión actual, no se admiten las aplicaciones con contenido en unidades que no contienen el sistema (D:\$1, E:\$1, etc.) para la migración.
El comando **eb migrate** detecta automáticamente las rutas físicas ubicadas en las unidades que no son del sistema y le advierte sobre posibles problemas, como en el siguiente ejemplo:  

```
ERROR: Detected physical paths on drive D:\ which are not supported in the current version:
  - D:\websites\intranet
  - D:\shared\images

Migration of content from non-system drives is not supported. Please relocate this content to the C:\ drive before migration. Otherwise, select only those sites that are on C:\.
```
Si su aplicación tiene dependencias de unidades que no son del sistema, tendrá que modificarla para almacenar todo el contenido en la unidad C:\$1 antes de la migración.

**Aplicaciones anidadas**  
Las aplicaciones anidadas en sitios web se implementan con las configuraciones de ruta correctas y las asignaciones de grupos de aplicaciones adecuadas. El proceso de migración conserva todas las configuraciones ` web.config`, lo que garantiza que la configuración específica de la aplicación siga funcionando según lo esperado en el entorno de nube.

## Reescritura de URL y enrutamiento de solicitudes de aplicaciones (ARR)
<a name="dotnet-migrating-applications-mapping-url-rewrite"></a>

Si su implementación de IIS utiliza la reescritura de URL o el enrutamiento de solicitudes de aplicaciones (ARR), **eb migrate** gestiona estas configuraciones mediante las siguientes reglas y configuraciones:

**Reglas de reescritura de URL**  
Las reglas de reescritura de URL de sus archivos `web.config` se traducen en reglas de enrutamiento del ALB siempre que es posible. Por ejemplo, la siguiente entrada se convierte en una regla de oyente del ALB que dirige el tráfico en función de los encabezados del host y los patrones de ruta.  

```
<!-- Original IIS URL Rewrite Rule -->
<rule name="Redirect to WWW" stopProcessing="true">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTP_HOST}" pattern="^example.com$" />
    </conditions>
    <action type="Redirect" url="http://www.example.com/{R:1}" />
</rule>
```


**Enrutamiento de solicitudes de aplicaciones**  
Las configuraciones de ARR se conservan mediante la instalación de las funciones de ARR en EC2 las instancias. Durante el proceso de migración se completan las siguientes tareas:  
+ Configura los ajustes del proxy para que coincidan con su entorno de origen.
+ Mantiene las reglas de reescritura de URL asociadas a ARR.

## Estructura de artefactos de migración
<a name="dotnet-migrating-applications-mapping-artifacts"></a>

Cuando se ejecuta **eb migrate**, crea un directorio estructurado que contiene todos los componentes de implementación necesarios. La siguiente lista describe la estructura del directorio:

```
C:\migration_workspace\
└── .\migrations\latest\
    └── upload_target\
        ├── [SiteName].zip                 # One ZIP per IIS site
        ├── aws-windows-deployment-manifest.json
        └── ebmigrateScripts\
            ├── site_installer.ps1         # Site installation scripts
            ├── arr_configuration.ps1      # ARR configuration scripts
            ├── permission_handler.ps1     # Permission management
            └── firewall_config.ps1        # Windows Firewall rules
```

El archivo `aws-windows-deployment-manifest.json` es el archivo de configuración principal que indica a Elastic Beanstalk cómo implementar las aplicaciones. Consulte el siguiente ejemplo de estructura:

```
{
    "manifestVersion": 1,
    "deployments": {
        "msDeploy": [
            {
                "name": "Primary Site",
                "parameters": {
                    "appBundle": "DefaultWebSite.zip",
                    "iisPath": "/",
                    "iisWebSite": "Default Web Site"
                }
            }
        ],
        "custom": [
            {
                "name": "ConfigureARR",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\arr_configuration.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\noop.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\noop.ps1"
                    }
                }
            }
        ]
    }
}
```

Este manifiesto garantiza los siguientes resultados para su migración:
+ Las aplicaciones se implementan para corregir las rutas de IIS.
+ Se aplican configuraciones personalizadas.
+ Se conserva la configuración específica del sitio.
+ Se mantiene el orden de la implementación.

# Escenarios de migración avanzada
<a name="dotnet-migrating-applications-advanced-scenarios"></a>

En esta sección se describen los escenarios de migración avanzada para implementaciones complejas de IIS.

## Migraciones de sitios múltiples con enrutamiento de solicitudes de aplicaciones (ARR)
<a name="dotnet-migrating-applications-advanced-scenarios-arr"></a>

El comando **eb migrate** detecta y conserva automáticamente las configuraciones de ARR durante la migración. Cuando identifica la configuración de ARR en su IIS`applicationHost.config`, genera los PowerShell scripts necesarios para reinstalar y configurar ARR en las EC2 instancias de destino.

### Detección de configuración de ARR
<a name="dotnet-migrating-applications-advanced-scenarios-arr-detection"></a>

El proceso de migración examina tres secciones clave de configuración en IIS:
+ `system.webServer/proxy`: configuración de proxy de ARR principal
+ `system.webServer/rewrite`: reglas de reescritura de URL
+ `system.webServer/caching`: configuración de almacenamiento en caché

Por ejemplo, considere una configuración de ARR común en la que un `RouterSite` que se ejecuta en el puerto 80 envía solicitudes al `APIService` y `AdminPortal` que se ejecutan en los puertos 8081 y 8082, respectivamente:

```
<!-- Original IIS ARR Configuration -->
<rewrite>
    <rules>
        <rule name="Route to API" stopProcessing="true">
            <match url="^api/(.*)$" />
            <action type="Rewrite" url="http://backend:8081/api/{R:1}" />
        </rule>
        <rule name="Route to Admin" stopProcessing="true">
            <match url="^admin/(.*)$" />
            <action type="Rewrite" url="http://backend:8082/admin/{R:1}" />
        </rule>
    </rules>
</rewrite>
```

El siguiente diagrama muestra cómo estas reglas se ocultan detrás del puerto 80 del servidor IIS y no se exponen a través de los grupos EC2 de seguridad. El Equilibrador de carga de aplicación tiene acceso solamente al puerto 80 y todo el tráfico procedente de él se enruta al grupo de destino en el puerto 80.

![\[Arquitectura de Elastic Beanstalk con enrutamiento de solicitudes de aplicaciones (ARR)\]](http://docs.aws.amazon.com/es_es/elasticbeanstalk/latest/dg/images/architecture-diagram-with-arr.png)


El siguiente comando puede migrar esta configuración:

```
PS C:\migrations_workspace> eb migrate --sites "RouterSite,APIService,AdminPortal" `
    --copy-firewall-config
```

### Proceso de migración de ARR
<a name="dotnet-migrating-applications-advanced-scenarios-arr-process"></a>

El proceso de migración conserva la configuración de ARR mediante varios pasos.

Exportación de configuraciones  
La herramienta exporta los ajustes de ARR existentes de las tres secciones clave de configuración a archivos XML por separado almacenados en el directorio `ebmigrateScripts`:  

```
ebmigrateScripts\
├── arr_config_proxy.xml
├── arr_config_rewrite.xml
└── arr_config_caching.xml
```

Scripts de instalación  
Se generan dos PowerShell scripts para gestionar la configuración de ARR:  

1. `arr_msi_installer.ps1`: descarga e instala el módulo ARR

1. `arr_configuration_importer_script.ps1`: importa la configuración de ARR exportada

Integración del manifiesto de implementación  
Los scripts se integran en el proceso de implementación mediante entradas en `aws-windows-deployment-manifest.json`:  

```
{
    "manifestVersion": 1,
    "deployments": {
        "custom": [
            {
                "name": "WindowsProxyFeatureEnabler",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\windows_proxy_feature_enabler.ps1"
                    }
                }
            },
            {
                "name": "ArrConfigurationImporterScript",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\arr_configuration_importer_script.ps1"
                    }
                }
            }
        ]
    }
}
```

### Integración de un equilibrador de carga
<a name="dotnet-migrating-applications-advanced-scenarios-arr-lb"></a>

El proceso de migración convierte las reglas de ARR en reglas de oyente del Equilibrador de carga de aplicación (ALB) siempre que sea posible. Por ejemplo, la configuración ARR anterior da como resultado reglas de ALB que enrutan el tráfico en función de los patrones de ruta de las URL y, al mismo tiempo, mantienen el enrutamiento interno en las EC2 instancias.

El entorno resultante mantiene la lógica de enrutamiento de ARR y, al mismo tiempo, aprovecha la infraestructura elástica de AWS. Sus aplicaciones seguirán funcionando como antes: ARR gestiona el enrutamiento interno mientras que el Equilibrador de carga de aplicación administra la distribución del tráfico externo.

## Migraciones de sitios múltiples sin ARR mediante enrutamiento basado en host
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr"></a>

Si bien el enrutamiento de solicitudes de aplicaciones (ARR) es un enfoque común para administrar sitios múltiples en IIS, también puede migrar las implementaciones de sitios múltiples directamente a Elastic Beanstalk sin ARR aprovechando las capacidades de enrutamiento basado en host del Equilibrador de carga de aplicación. Este enfoque puede reducir la complejidad y mejorar el rendimiento con la eliminación de una capa de enrutamiento adicional.

### Descripción general del enrutamiento basado en host
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-overview"></a>

En este enfoque, cada sitio de IIS se expone fuera de la EC2 instancia y el Application Load Balancer dirige el tráfico directamente al puerto correspondiente en función del encabezado del host. Esto elimina la necesidad de utilizar el ARR y, al mismo tiempo, mantiene la separación entre las aplicaciones.

Considere una configuración de IIS de sitios múltiples con tres sitios, cada uno con su propio enlace de nombre de host:

```
<sites>
    <site name="Default Web Site" id="1">
        <bindings>
            <binding protocol="http" bindingInformation="*:8081:www.example.com" />
        </bindings>
    </site>
    <site name="InternalAPI" id="2">
        <bindings>
            <binding protocol="http" bindingInformation="*:8082:api.internal" />
        </bindings>
    </site>
    <site name="ReportingPortal" id="3">
        <bindings>
            <binding protocol="http" bindingInformation="*:8083:reports.internal" />
        </bindings>
    </site>
</sites>
```

Estos sitios se exponen en los puertos 8081, 8082 y 8083 a través de los grupos de seguridad. EC2 El Equilibrador de carga de aplicación se enruta a ellos en función de la configuración de la regla del oyente del equilibrador de carga.

![\[Arquitectura de Elastic Beanstalk sin enrutamiento de solicitudes de aplicaciones (ARR)\]](http://docs.aws.amazon.com/es_es/elasticbeanstalk/latest/dg/images/architecture-diagram-without-arr.png)


### Proceso de migración
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-migration"></a>

Para migrar esta configuración a Elastic Beanstalk sin usar el ARR, utilice el comando **eb migrate** del siguiente ejemplo:

```
PS C:\migrations_workspace> eb migrate --sites "Default Web Site,InternalAPI,ReportingPortal"
```

El proceso de migración configura automáticamente el Equilibrador de carga de aplicación con reglas de enrutamiento basadas en el host que dirigen el tráfico al grupo objetivo adecuado en función del encabezado del host. Cada grupo objetivo reenvía el tráfico al puerto correspondiente de sus instancias: EC2 

1. Encabezado de host www.example.com → Grupo objetivo en el puerto 8081

1. Encabezado de host api.internal → Grupo objetivo en el puerto 8082

1. Encabezado de host reports.internal → Grupo objetivo en el puerto 8083

### Configuración de SSL/TLS
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-ssl"></a>

Para proteger sus aplicaciones, siga estos pasos: SSL/TLS 

1. Solicite certificados para sus dominios a través de AWS Certificate Manager(ACM).

1. Configure los oyentes HTTPS en su Equilibrador de carga de aplicación con estos certificados.

1. Actualice la configuración de su entorno para incluir los oyentes HTTPS con las siguientes opciones de configuración.

   ```
   option_settings:
     aws:elb:listener:443:
       ListenerProtocol: HTTPS
       SSLCertificateId: arn:aws:acm:region:account-id:certificate/certificate-id
       InstancePort: 80
       InstanceProtocol: HTTP
   ```

Con esta configuración, la finalización de SSL se produce en el equilibrador de carga y el tráfico se reenvía a las instancias a través de HTTP. Esto simplifica la administración de los certificados y, al mismo tiempo, mantiene las conexiones seguras con los clientes.

### Prácticas recomendadas
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-best"></a>

Grupos de seguridad  
Configure los grupos de seguridad para permitir el tráfico entrante solamente en los puertos que utilizan los sitios de IIS (8081, 8082, 8083 en este ejemplo) desde el grupo de seguridad del Equilibrador de carga de aplicación.

Comprobaciones de estado  
Configure las comprobaciones de estado para cada grupo de destino a fin de garantizar que el tráfico se dirija solamente a las instancias en buen estado. Cree puntos de conexión para la comprobación de estado para cada aplicación, si aún no existen.

Supervisión  
Configure CloudWatch alarmas para supervisar el estado y el rendimiento de cada grupo objetivo por separado. Esto permite identificar los problemas específicos de las aplicaciones individuales.

Escalado  
Tenga en cuenta los requisitos de recursos de todas las aplicaciones cuando configure las políticas de escalado automático. Si una aplicación tiene necesidades de recursos significativamente diferentes, considere la posibilidad de migrarla a un entorno diferente.

## Administración de directorio virtual
<a name="dotnet-migrating-applications-advanced-scenarios-vdir"></a>

El comando **eb migrate** conserva las estructuras de directorios virtuales mientras migra sus aplicaciones de IIS a Elastic Beanstalk.

### Configuración predeterminada de permisos
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-default"></a>

Al migrar los directorios virtuales, **eb migrate** establece un conjunto básico de permisos al conceder ReadAndExecute acceso a:
+ IIS\$1IUSRS
+ IUSR
+ Usuarios autenticados

Por ejemplo, considere una estructura típica de directorios virtuales:

```
<site name="CorporatePortal">
    <application path="/" applicationPool="CorporatePortalPool">
        <virtualDirectory path="/" physicalPath="C:\sites\portal" />
        <virtualDirectory path="/shared" physicalPath="C:\shared\content" />
        <virtualDirectory path="/reports" physicalPath="D:\reports" />
    </application>
</site>
```

### Directorios virtuales protegidos con contraseña
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-password"></a>

Cuando **eb migrate** encuentra directorios virtuales protegidos por contraseña, emite advertencias y requiere una intervención manual. 

El siguiente ejemplo de configuración generará la respuesta de advertencia que sigue al ejemplo.

```
<virtualDirectory path="/secure" 
                 physicalPath="C:\secure\content"
                 userName="DOMAIN\User"
                 password="[encrypted]" />
```

```
[WARNING] CorporatePortal/secure is hosted at C:\secure\content which is password-protected and won't be copied.
```

Para mantener la protección con contraseña, cree un script de implementación personalizado, como el siguiente:

```
# PS C:\migrations_workspace> cat secure_vdir_config.ps1

$vdirPath = "C:\secure\content"
$siteName = "CorporatePortal"
$vdirName = "secure"
$username = "DOMAIN\User"
$password = "SecurePassword"

# Ensure directory exists
if (-not (Test-Path $vdirPath)) {
    Write-Host "Creating directory: $vdirPath"
    New-Item -Path $vdirPath -ItemType Directory -Force
}

# Configure virtual directory with credentials
Write-Host "Configuring protected virtual directory: $vdirName"
New-WebVirtualDirectory -Site $siteName -Name $vdirName `
    -PhysicalPath $vdirPath -UserName $username -Password $password

# Set additional permissions as needed
$acl = Get-Acl $vdirPath
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $username, "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl $vdirPath $acl
```

Añada este script a su implementación incluyéndolo en el manifiesto:

```
{
    "manifestVersion": 1,
    "deployments": {
        "custom": [
            {
                "name": "SecureVirtualDirectory",
                "scripts": {
                    "install": {
                        "file": "secure_vdir_config.ps1"
                    }
                }
            }
        ]
    }
}
```

### Administración de permisos personalizada
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-custom"></a>

El comando **eb migrate** proporciona un marco para que los scripts de permisos personalizados se adapten a las aplicaciones que requieren permisos distintos de los predeterminados. 



```
$paths = @(
    "C:\sites\portal\uploads",
    "C:\shared\content"
)

foreach ($path in $paths) {
    if (-not (Test-Path $path)) {
        Write-Host "Creating directory: $path"
        New-Item -Path $path -ItemType Directory -Force
    }

    $acl = Get-Acl $path

    # Add custom permissions
    $customRules = @(
        # Application Pool Identity - Full Control
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "IIS AppPool\CorporatePortalPool", 
            "FullControl", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        ),
        # Custom Service Account
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "NT SERVICE\CustomService", 
            "Modify", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        )
    )

    foreach ($rule in $customRules) {
        $acl.AddAccessRule($rule)
    }
    
    Set-Acl $path $acl
    Write-Host "Custom permissions applied to: $path"
}
```

### Prácticas recomendadas
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-best"></a>

Siga estas prácticas recomendadas para planificar, ejecutar, monitorear y comprobar la migración.

Planificación previa a la migración  
Documente los requisitos y permisos de autenticación existentes antes de la migración. Pruebe los scripts de permisos personalizados en un entorno de desarrollo antes de implementarlos en producción.

Administración de contenido compartido  
En el caso de los directorios de contenido compartido, asegúrese de que todos los permisos necesarios del sistema de archivos estén configurados correctamente mediante scripts personalizados. Considere la posibilidad de utilizar [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) para los requisitos de almacenamiento compartido.

Monitoreo y verificación  
Monitoree los registros de las aplicaciones después de la migración para comprobar el acceso correcto a los directorios virtuales. Preste especial atención a las siguientes áreas:  
+ Acceso a la identidad del grupo de aplicaciones
+ Permisos personalizados de cuentas de servicio
+ Conectividad de red compartida
+ Errores de autenticación

## Configuración personalizada del grupo de aplicaciones
<a name="dotnet-migrating-applications-advanced-scenarios-apppool"></a>

De forma predeterminada, el comando **eb migrate** no copia la configuración personalizada del grupo de aplicaciones. Para conservar las configuraciones personalizadas del grupo de aplicaciones, siga este procedimiento para crear y aplicar una sección personalizada del manifiesto.

1. Cree un archivo de sus artefactos de migración.

   ```
   PS C:\migrations_workspace> eb migrate --archive
   ```

1. Cree un PowerShell script personalizado para configurar los grupos de aplicaciones.

   ```
   # PS C:\migrations_workspace> cat .\migrations\latest\upload_target\customize_application_pool_config.ps1
   
   $configPath = "$env:windir\System32\inetsrv\config\applicationHost.config"
   
   [xml]$config = Get-Content -Path $configPath
   
   $newPoolXml = @"
   <!-- Original IIS Configuration -->
   <applicationPools>
       <add name="CustomPool" 
            managedRuntimeVersion="v4.0" 
            managedPipelineMode="Integrated">
           <processModel identityType="SpecificUser" 
                        userName="AppPoolUser" 
                        password="[encrypted]" />
           <recycling>
               <periodicRestart time="00:00:00">
                   <schedule>
                       <add value="02:00:00" />
                       <add value="14:00:00" />
                   </schedule>
               </periodicRestart>
           </recycling>
       </add>
   </applicationPools>
   "@
   $newPoolXmlNode = [xml]$newPoolXml
   
   # Find the applicationPools section
   $applicationPools = $config.SelectSingleNode("//configuration/system.applicationHost/applicationPools")
   
   # Import the new node into the document
   $importedNode = $config.ImportNode($newPoolXmlNode.DocumentElement, $true)
   $applicationPools.AppendChild($importedNode)
   
   # Save the changes
   $config.Save($configPath)
   
   Write-Host "ApplicationHost.config has been updated successfully."
   ```

1. Actualice el archivo `aws-windows-deployment-manifest.json` para incluir el script personalizado.

   ```
   {
       "manifestVersion": 1,
       "deployments": {
           ...
           "custom": [
               ...,
               {
                   "name": "ModifyApplicationPoolConfig",
                   "description": "Modify application pool configuration from source machine to remove",
                   "scripts": {
                       "install": {
                           "file": "customize_application_pool_config.ps1"
                       },
                       "restart": {
                           "file": "ebmigrateScripts\\noop.ps1"
                       },
                       "uninstall": {
                           "file": "ebmigrateScripts\\noop.ps1"
                       }
                   }
               }
           ]
       }
   }
   ```

1. Cree un entorno con el directorio de archivos actualizado.

   ```
   PS C:\migrations_workspace> eb migrate `
       --archive-dir '.\migrations\latest\upload_target\'
   ```

El argumento de `--archive-dir` indica al comando **eb migrate** que utilice el código fuente que creó previamente, evitando la creación de nuevos archivos.

## Cómo restaurar versiones anteriores
<a name="dotnet-migrating-applications-advanced-scenarios-previous"></a>

El comando **eb migrate** mantiene un historial de sus migraciones a través de directorios con marca de tiempo y versiones de aplicaciones en Elastic Beanstalk. Cada migración crea un archivo zip único que se puede implementar si es necesario.

```
PS C:\migrations_workspace> ls .\migrations\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----l        3/18/2025  10:34 PM                latest
d-----        3/16/2025   5:47 AM                migration_1742104049.479849
d-----        3/17/2025   9:18 PM                migration_1742246303.18056
d-----        3/17/2025   9:22 PM                migration_1742246546.565739
...
d-----        3/18/2025  10:34 PM                migration_1742337258.30742
```

El enlace simbólico `latest` siempre apunta al directorio de artefactos de migración creado más recientemente. Además de los registros de aplicaciones y errores relevantes, cada directorio de artefactos de migración también contiene un archivo `upload_target.zip` que puede implementar en Elastic Beanstalk.

```
PS C:\migrations_workspace> ls .\migrations\latest\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        3/18/2025  10:34 PM                upload_target
-a----        3/18/2025  10:34 PM          13137 application.log
-a----        3/18/2025  10:34 PM              0 error.log
-a----        3/18/2025  10:34 PM        1650642 upload_target.zip
```

Puede implementar el archivo `upload_target.zip` mediante **eb migrate**:

```
PS C:\migrations_workspace> eb migrate --zip .\migrations\latest\upload_target.zip
```

# Solución de los problemas y diagnóstico
<a name="dotnet-migrating-applications-troubleshooting"></a>

**Pruebe la CLI de Amazon Q Developer para solucionar problemas con ayuda de la IA**  
 La CLI de Amazon Q Developer puede ayudarle a solucionar rápidamente los problemas de entorno. La CLI de Q permite solucionar problemas comprobando el estado del entorno, revisando eventos, analizando registros y formulando preguntas aclaratorias. Para obtener más información y tutoriales detallados, consulte [Solución de problemas de entornos de Elastic Beanstalk con Amazon](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/) Q Developer CLI en los blogs. AWS 

En esta sección se proporciona orientación para solucionar problemas comunes que pueden surgir durante la migración de aplicaciones de IIS a Elastic Beanstalk.

## Asociación de un par de claves a su entorno EC2
<a name="dotnet-migrating-applications-troubleshooting-keypair"></a>

Puede iniciar sesión de forma segura en las instancias de Amazon Elastic Compute Cloud (Amazon EC2) aprovisionadas para su aplicación de Elastic Beanstalk con un par de claves de Amazon. EC2 Para obtener instrucciones sobre cómo crear un par de claves, consulta [Cómo crear un par de claves con Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair) en la *Guía del EC2 usuario de Amazon*.

Especificar un nombre clave para **eb migrate** tiene el efecto de asociar el entorno de Elastic Beanstalk al par de claves. Por motivos de seguridad, esto no abrirá el puerto 3389 en el grupo de seguridad de la EC2 instancia. Puede asociar grupos de EC2 seguridad adicionales que permitan el tráfico en el puerto 3389 **eb config** después de la migración inicial.

```
PS C:\migrations_workspace> eb migrate  `
    --keyname "my-keypair"  `
    --verbose
```

Cuando creas un par de claves, Amazon EC2 almacena una copia de tu clave pública. Si ya no necesitas usarlo para conectarte a ninguna instancia del entorno, puedes eliminarlo de Amazon EC2. Para obtener más información, [consulta Eliminar un par de claves](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair) en la *Guía del EC2 usuario de Amazon*.

Para obtener más información sobre cómo conectarse a EC2 instancias de Amazon de Windows, consulte [Conexión a Windows Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html).

## Acceso a los registros
<a name="dotnet-migrating-applications-troubleshooting-logs"></a>

La CLI de EB proporciona **eb logs** una función que puede utilizar para recuperar registros de un entorno de Elastic Beanstalk sin iniciar sesión en sus instancias. EC2 Tras ejecutar **eb migrate**, puede ejecutar el comando **eb logs --zip** que descargará y guardará los registros en el directorio `.elasticbeanstalk\logs`.

Como alternativa, puede ver los registros a través de la consola de AWS Elastic Beanstalk. Para obtener más información, consulte [Visualización de registros de instancias de Amazon EC2 en su entorno de Elastic Beanstalk](using-features.logging.md).

## Acceso a los artefactos del cliente
<a name="dotnet-migrating-applications-troubleshooting-artifacts"></a>

El comando **eb migrate** almacena los registros de aplicaciones y errores generados por los directorios internos de artefactos de migración de **msdeploy**.

```
./migrations/
├── latest -> migration_20240308_123456/
└── migration_20240308_123456/
    ├── application.log
    ├── error.log
    └── upload_target\
```

## Monitoreo del estado del entorno
<a name="dotnet-migrating-applications-troubleshooting-health"></a>

Elastic Beanstalk le permite monitorear el estado mediante las capacidades mejoradas de monitoreo del estado. Se trata de un sistema automatizado de monitoreo del estado que realiza un seguimiento continuo del estado operativo de las instancias de la aplicación y aprovecha las métricas integradas, como la utilización de la CPU, la latencia, el recuento de solicitudes y los códigos de respuesta.

El sistema de monitoreo del estado utiliza un enfoque basado en agentes para recopilar datos a nivel de la instancia y se integra con el registro y las alertas en tiempo real. Elastic Load Balancing (ELB) y el escalado automático responden de forma dinámica a los cambios en el estado, lo que garantiza una alta disponibilidad y tolerancia a errores. Los modos de monitoreo avanzados, que incluyen informes de estado mejorados, proporcionan una visibilidad detallada del comportamiento de las aplicaciones, lo que permite la resolución proactiva de problemas y los mecanismos de recuperación automática.

Ejecute el comando **eb health** de la CLI de EB para mostrar el estado del entorno. Se muestra la siguiente información:
+ Estado de una instancia
+ Métricas de respuesta de la aplicación
+ Utilización de recursos del sistema
+ Eventos recientes de implementación

## EC2 optimización del rendimiento
<a name="dotnet-migrating-applications-troubleshooting-performance"></a>

De forma predeterminada, **eb migrate** selecciona el tipo de instancia [c5.2xlarge](https://aws.amazon.com/ec2/instance-types/c5/) para ofrecer una experiencia óptima por primera vez con Elastic Beanstalk. Puede anular este comportamiento con el argumento **--instance-type**:

```
PS C:\migrations_workspace> eb migrate `
    --instance-type "t3.large"
```

Para los entornos de producción, tenga en cuenta los siguientes factores a la hora de seleccionar un tipo de instancia:
+ Requisitos de memoria de sus aplicaciones
+ Requisitos de CPU para procesar las cargas de trabajo
+ Necesidades de rendimiento de la red
+ Objetivos de optimización de costos

## Configuración del volumen de EBS
<a name="dotnet-migrating-applications-troubleshooting-ebs"></a>

De forma predeterminada, Elastic Beanstalk creará solo un volumen de dispositivo de bloques raíz (`C:\`) para su entorno. Puede transferir volúmenes de instantáneas adicionales a Amazon Elastic Block Store con la opción **--ebs-snapshots**:

```
PS C:\migrations_workspace> eb migrate `
    --ebs-snapshots "snap-123456789abc"
```

Para ver ejemplos de cómo configurar las asignaciones de dispositivos de bloques con Elastic Beanstalk, consulte el artículo del blog [Customize Ephemeral and EBS Volumes in Elastic Beanstalk Environments](https://aws.amazon.com/blogs/devops/customize-ephemeral-and-ebs-volumes-in-elastic-beanstalk-environments/).

Para las aplicaciones con requisitos de almacenamiento elevados, tenga en cuenta las siguientes opciones:
+ Uso de volúmenes de EBS para datos persistentes
+ Implementación de Amazon S3 para contenido estático
+ Uso de Amazon FSx for Windows File Server para sistemas de archivos compartidos

## Problemas y soluciones comunes de
<a name="dotnet-migrating-applications-troubleshooting-common"></a>

**Evento:** *falta la instalación de Web Deploy*

Si encuentra errores relacionados con la falta de localización de Web Deploy, instale Web Deploy 3.6 o una versión posterior desde el [instalador de la plataforma web de Microsoft](https://www.iis.net/downloads/microsoft/web-deploy). En el siguiente ejemplo, se muestra un posible mensaje de error.

```
Couldn't find msdeploy.exe. Follow instructions here: https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy
```

**Evento:** *problemas de permisos durante la migración*

Si encuentra errores relacionados con los permisos, asegúrese de ejecutar la CLI de EB con privilegios administrativos. En el siguiente ejemplo, se muestra un posible mensaje de error.

```
[ERROR] Access to the path 'C:\inetpub\wwwroot\web.config' is denied.
```

**Evento:** *problemas de identidad del grupo de aplicaciones*

Si la aplicación no se puede iniciar debido a problemas de identidad del grupo de aplicaciones, cree un script personalizado para configurar las identidades del grupo de aplicaciones, tal y como se muestra en [Configuración personalizada del grupo de aplicaciones](dotnet-migrating-applications-advanced-scenarios.md#dotnet-migrating-applications-advanced-scenarios-apppool).

**Evento:** *errores de configuración del certificado SSL*

Si los enlaces HTTPS no funcionan, asegúrese de haber especificado un ARN de certificado de ACM válido mediante la opción **eb mibrate** del parámetro `--ssl-certificates`.

**Evento:** *tiempo de espera para la creación del entorno*

Si se agota el tiempo de espera para la creación del entorno, compruebe si hay errores específicos en la creación de recursos en los CloudFormation eventos de la consola de AWS administración. Entre las causas más comunes se incluyen los problemas de configuración de la VPC o los límites de servicio.

## Cómo obtener asistencia
<a name="dotnet-migrating-applications-troubleshooting-support"></a>

Si encuentra problemas que no puede resolver, AWS Support recopile la siguiente información antes de ponerse en contacto con usted:
+ ID del entorno (`eb status`)
+ Registros de aplicaciones (`eb logs --zip`)
+ Artefactos de migración de `.\migrations\latest\`
+ Configuración de IIS de origen (salida de `eb migrate explore --verbose`)
+ Mensajes de error detallados

Para obtener más información acerca de la solución de errores de Elastic Beanstalk, consulte [Solución de problemas del entorno de Elastic Beanstalk](troubleshooting.md).

# Comparación de las opciones de migración: EB CLI vs. AWS Application Migration Service
<a name="dotnet-migrating-applications-comparison"></a>

AWS ofrece múltiples rutas para migrar las aplicaciones de Windows a la nube. En esta sección se comparan dos opciones principales: el **eb migrate** comando de la CLI de EB y AWS Application Migration Service (MGN). Comprender las diferencias entre estos enfoques le permitirá elegir la estrategia de migración más adecuada para sus necesidades específicas.


**Comparación de opciones de migración**  

| Característica | CLI de EB (**eb migrate**) | AWS Application Migration Service (MGN) | 
| --- | --- | --- | 
| Enfoque principal | Migración a nivel de la aplicación de sitios web y aplicaciones de IIS | Realojamiento de máquinas enteras a nivel del servidor (servidores físicos, virtuales o en la nube) | 
| El más adecuado para lo siguiente: | Aplicaciones de IIS que desee migrar directamente a Elastic Beanstalk con una reconfiguración mínima. | Migraciones a gran escala que implican muchos servidores o una infraestructura compleja. | 
| Enfoque de detección | Detección a nivel de aplicación de sitios, aplicaciones y configuraciones de IIS | Replicación de máquinas enteras a nivel del servidor, incluidos el sistema operativo y las aplicaciones | 
| Entorno de destino | Crea y configura directamente entornos de Elastic Beanstalk optimizados para aplicaciones de Windows. | Crea EC2 instancias que requieren una configuración adicional para funcionar con Elastic Beanstalk | 
| Conservación de la configuración | Conserva automáticamente las configuraciones específicas de IIS (sitios, grupos de aplicaciones, enlaces). | Conserva toda la configuración del servidor, que puede incluir componentes innecesarios. | 
| Modelo de implementación | Crea un entorno de Elastic Beanstalk limpio con las aplicaciones implementadas mediante las prácticas recomendadas de Elastic Beanstalk. | Crea una réplica del servidor de origen que puede requerir una optimización para las operaciones en la nube. | 
| Escala de migración | Es ideal para migraciones específicas de aplicaciones específicas. | Está diseñada para migraciones a gran escala de muchos servidores. | 
| Pasos posteriores a la migración | Mínimo; el entorno está listo para su uso con las herramientas de administración de Elastic Beanstalk. | Requiere pasos adicionales para la integración con Elastic Beanstalk, como la ejecución de acciones de SSM posteriores al lanzamiento. | 

## Cuándo usar cada opción de migración
<a name="dotnet-migrating-applications-comparison-when"></a>

**Elija **eb migrate** si tiene los siguientes requisitos:**  
+ Quiere migrar aplicaciones de IIS específicas en lugar de servidores completos.
+ Su objetivo es adoptar Elastic Beanstalk como plataforma de administración de aplicaciones.
+ Desea aprovechar las características de la plataforma administrada de Elastic Beanstalk, como el escalado, la implementación y el monitoreo sencillos.
+ Prefiere una implementación limpia que siga las AWS mejores prácticas para las operaciones nativas de la nube
+ Desea minimizar el trabajo de configuración posterior a la migración.

**Elija AWS Application Migration Service si tiene los siguientes requisitos:**  
+ Necesita migrar una gran cantidad de servidores.
+ Tiene configuraciones de servidor complejas que deben conservarse con exactitud.
+ Sus aplicaciones tienen problemas de compatibilidad que requieren mantener el entorno de servidor exacto.
+ Lo que quiere es que sus aplicaciones «migren mediante lift-and-shift» con cambios mínimos.
+ Planea refactorizar u optimizar sus aplicaciones después de la migración.

## Comparación del flujo de trabajo de migración
<a name="dotnet-migrating-applications-comparison-workflow"></a>

**Flujo de trabajo de la CLI de EB (**eb migrate**):**

1. Instale la CLI de EB en el servidor de IIS de origen o en un host bastión.

1. Ejecute **eb migrate** para detectar las aplicaciones de IIS.

1. El comando empaqueta sus aplicaciones y configuraciones.

1. Se crea un entorno de Elastic Beanstalk con los recursos adecuados.

1. Sus aplicaciones se implementan en el nuevo entorno.

1. Puede administrar sus aplicaciones de forma inmediata con las herramientas de Elastic Beanstalk.

**AWS Application Migration Service flujo de trabajo:**

1. Instale el agente de AWS replicación en los servidores de origen.

1. Configure y pruebe la replicación de los datos.

1. Lance instancias de prueba para comprobar la funcionalidad.

1. Programe la transferencia a. AWS

1. Lance instancias de producción.

1. Ejecute acciones posteriores al lanzamiento para optimizarlas para la nube.

1. Si Elastic Beanstalk es la plataforma de destino, se requiere una configuración adicional para la integración con Elastic Beanstalk.

## Conclusión
<a name="dotnet-migrating-applications-comparison-conclusion"></a>

Elastic Beanstalk es el destino preferido para las AWS aplicaciones de la plataforma Windows, ya que ofrece un entorno gestionado que simplifica la implementación, el escalado y la administración. El comando **eb migrate** proporciona una ruta directa a Elastic Beanstalk para aplicaciones de IIS, con detección y configuración automáticas que conservan la configuración de la aplicación.

Si bien AWS Application Migration Service ofrece potentes capacidades para migraciones de servidores a gran escala, requiere pasos adicionales para integrarse con Elastic Beanstalk. Para la mayoría de las migraciones de aplicaciones de IIS en las que Elastic Beanstalk es la plataforma de destino, **eb migrate** ofrece un enfoque más simplificado que se alinea con el modelo de servicio administrado de Elastic Beanstalk.

Elija el enfoque de migración que mejor se adapte a sus requisitos específicos, teniendo en cuenta factores como el escalado, la complejidad y la arquitectura de estado final de AWS que desee.

[Para obtener más información AWS Application Migration Service, consulte ¿Qué es? AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) en la Guía AWS Application Migration Service del usuario.