

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Migrar aplicações do IIS para o Elastic Beanstalk
<a name="dotnet-migrating-applications"></a>

AWS Elastic Beanstalk fornece um caminho de migração simplificado para seus aplicativos Windows executados nos Serviços de Informações da Internet (IIS). A capacidade de migração descrita neste capítulo reduz significativamente o tempo e a complexidade normalmente associados às migrações para a nuvem, o que ajuda a manter a funcionalidade da aplicação e a integridade da configuração durante a transição para a AWS.

**A operação **eb migrate****  
Use o comando **eb migrate** na Elastic Beanstalk Command Line Interface (EB CLI) para descobrir, empacotar e implantar automaticamente suas aplicações do IIS na Nuvem AWS. O processo mantém a funcionalidade da aplicação e preserva suas configurações, incluindo associações, grupos de aplicações e configurações de autenticação.

As etapas a seguir resumem o processo que a operação `eb migrate` executa para fazer a transição da aplicação para a Nuvem AWS:

1. Descubra sites do IIS e suas configurações.

1. Empacote o conteúdo e a configuração da aplicação.

1. Crie um ambiente e uma aplicação do Elastic Beanstalk.

1. Implante a aplicação com configurações preservadas.

**Opções de execução de fluxo de trabalho e localização**  
O comando **eb migrate** fornece opções para fluxos de trabalho de migração flexíveis e locais de execução. Por padrão, execute o comando no servidor de destino que contém a aplicação que você deseja migrar para o Elastic Beanstalk. Se não conseguir executar comandos diretamente no servidor da aplicação, use a opção `remote` para executar o comando a partir de um bastion host que se conecta ao servidor de destino que contém sua aplicação e suas configurações. Para concluir a migração em duas etapas, você também pode gerar o pacote de migração sem implantá-lo usando a opção `archive-only` e, em seguida, implantá-lo posteriormente, conforme for conveniente, usando a opção `archive`.

Para obter informações de referência sobre o comando **eb migrate**, consulte [**eb migrate**](eb3-migrate.md).

**Tópicos**  
Os seguintes tópicos fornecem informações detalhadas sobre a migração de aplicações do IIS para o Elastic Beanstalk:
+ [Pré-requisitos](dotnet-migrating-applications-prerequisites.md): entenda o software, o acesso e as permissões necessários para migrar suas aplicações do Windows para ambientes do AWS Elastic Beanstalk .
+ [Glossário de migração](dotnet-migrating-applications-glossary.md): entenda como componentes do IIS são mapeados para recursos do Elastic Beanstalk
+ [Sobre o mapeamento de migração do IIS para o Elastic Beanstalk](dotnet-migrating-applications-mapping.md): entenda como componentes do IIS são mapeados para recursos do Elastic Beanstalk
+ [Executar migrações básicas do IIS](dotnet-migrating-applications-basic-migration.md): aprenda a realizar migrações básicas
+ [Cenários avançados de migração](dotnet-migrating-applications-advanced-scenarios.md): lide com cenários complexos de migração
+ [Configurações de segurança e perfis do IAM](dotnet-migrating-applications-security.md): defina configurações de segurança durante a migração
+ [Configuração de rede e de porta](dotnet-migrating-applications-network.md): gerencie configurações de rede e portas
+ [Solução de problemas e diagnóstico](dotnet-migrating-applications-troubleshooting.md): solucione problemas comuns de migração
+ [Comparando as opções de migração: EB CLI vs. AWS Application Migration Service](dotnet-migrating-applications-comparison.md): compare duas opções principais de migração.

# Pré-requisitos
<a name="dotnet-migrating-applications-prerequisites"></a>

Antes de usar o comando **eb migrate**, certifique-se de que seu ambiente atenda a estes requisitos necessários:

**Instalação e versão do IIS**  
O servidor do qual você está migrando deve executar Serviços de Informações da Internet (IIS) versão 7.0 ou superior. O IIS 10.0 no Windows Server 2016 ou posterior oferece o ambiente mais compatível para migração.  
Para verificar a versão do IIS, execute o seguinte comando:  

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

**Requisitos do Windows Server**  
Seu ambiente de origem deve executar o Windows Server 2016 ou posterior para otimizar a compatibilidade. O Elastic Beanstalk oferece suporte a estas versões do Windows Server como plataformas de destino:  
+ Windows Server 2025
+ Windows Server 2022
+ Windows Server 2019
+ Windows Server 2016

**Instalação da EB CLI**  
+ *Fluxo de trabalho padrão (sem a opção `--remote`)*:
  + O Python e a interface de linha de comando do Elastic Beanstalk (EB CLI) devem estar instalados no servidor que contém a aplicação que você deseja migrar para o Elastic Beanstalk. Embora não seja necessário, recomendamos instalar a EB CLI dentro de uma sandbox `virtualenv`, conforme descrito em [Instalar a EB CLI em um ambiente virtual](eb-cli3.md#eb-cli3-install-virtualenv).
+ *Usando a opção `--remote`*:
  + O Python e a interface de linha de comando do Elastic Beanstalk (EB CLI) do Elastic Beanstalk devem ser instalados no bastion host. Embora não seja necessário, recomendamos instalar a EB CLI dentro de uma sandbox `virtualenv`, conforme descrito em [Instalar a EB CLI em um ambiente virtual](eb-cli3.md#eb-cli3-install-virtualenv).

**Permissões obrigatórias do **  
Você precisa das seguintes credenciais e permissões:  
+ Privilégios de administrador no servidor IIS de origem ou no bastion host (se estiver usando a opção `--remote`).
+ AWS credenciais com permissões para criar e gerenciar recursos do Elastic Beanstalk

**Web Deploy 3.6**  
A ferramenta Microsoft Web Deploy (versão 3.6 ou posterior) deve ser instalada no servidor de origem ou no bastion host (se estiver usando a opção `--remote`). Essa ferramenta é usada por **eb migrate** para empacotar suas aplicações.  
Para verificar a instalação, execute o seguinte 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 obter instruções de instalação, consulte [Instalar e configurar o Web Deploy no IIS 8.0 ou posterior](https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy-on-iis-80-or-later) no site de documentação de produtos do Microsoft Windows.

**Requisitos de rede**  
+ *Fluxo de trabalho padrão (sem a opção `--remote`)*:
  + Seu servidor de origem deve ter acesso de saída à Internet aos AWS serviços.
+ *Usando a opção `--remote`*:
  + Seu servidor de origem deve ter acesso de saída à Internet aos AWS serviços.
  + Configure as regras de entrada do grupo de segurança adequadas que permitam uma conexão de rede de saída do seu bastion host e uma conexão de entrada na máquina remota. Certifique-se de que o IP do bastion host esteja na lista de permissões via TCP na porta 22 para acessar a máquina remota.
  + Certifique-se de que o cliente SSH esteja instalado e em execução no sua máquina remota, bem como no seu bastion host.
  + Verifique se a configuração do firewall contém as regras apropriadas que abrem a porta 22 ou permitem a conexão com o cliente.
  + Teste sua conexão inserindo manualmente o SSH no host remoto a partir do bastion host antes de tentar a migração.

# Glossário de migração
<a name="dotnet-migrating-applications-glossary"></a>

Este glossário fornece definições dos principais termos e conceitos relacionados ao IIS, ao Elastic Beanstalk e à migração de aplicações do IIS para o Elastic Beanstalk.

## Termos do Windows, IIS e.NET
<a name="dotnet-migrating-applications-glossary-windows"></a>

****IIS****  
Serviços de Informação da Internet, um software de servidor Web desenvolvido pela Microsoft para uso com o Windows Server. O IIS hospeda sites, aplicações Web e serviços Web, fornecendo uma plataforma para a execução do ASP.NET e outras tecnologias Web. Durante a migração para o Elastic Beanstalk, os sites do IIS e suas configurações são empacotados e implantados em instâncias do Windows Server na nuvem. AWS   
As versões 7.0 e posteriores do IIS têm suporte para migração, com o IIS 10.0 no Windows Server 2016 ou posterior fornecendo o ambiente mais compatível.

****.NET Estrutura****  
Uma plataforma de desenvolvimento de software desenvolvida pela Microsoft para criar e executar aplicações do Windows. Ele fornece uma grande biblioteca de classes chamada Framework Class Library (FCL) e oferece suporte à interoperabilidade de linguagens em várias linguagens de programação.  
Ao migrar para o Elastic Beanstalk, as aplicações criadas no .NET Framework continuam sendo executadas na mesma versão do framework no ambiente de nuvem. O Elastic Beanstalk oferece suporte a várias versões do .NET Framework (4.x) em suas plataformas Windows Server.

****.NET Core****  
Um sucessor multiplataforma e de código aberto do .NET Framework, projetado para ser mais modular e leve. O .NET Core (agora chamado simplesmente de .NET 5 e versões posteriores) permite que os desenvolvedores criem aplicações que são executadas no Windows, Linux e macOS.  
Ao migrar aplicações criadas no .NET Core para o Elastic Beanstalk, você pode escolher entre plataformas Windows Server ou plataformas baseadas em Linux, dependendo dos requisitos e dependências da sua aplicação.

****Common Language Runtime (CLR)****  
O componente de máquina virtual do .NET Framework que gerencia a execução de programas .NET. O CLR fornece serviços como gerenciamento de memória, segurança de tipos, tratamento de exceções, coleta de resíduos e gerenciamento de threads.  
Ao migrar para o Elastic Beanstalk, a versão CLR apropriada está automaticamente disponível na plataforma Windows Server que você selecionar, garantindo a compatibilidade com os requisitos da sua aplicação.

****Site****  
Um contêiner lógico no IIS que representa uma aplicação ou serviço Web, identificado por uma associação exclusiva de endereço IP, porta e cabeçalho do host. Cada site do IIS tem seu próprio grupo de aplicações, associações e definições de configuração e pode conter uma ou mais aplicações.

****Aplicativo****  
Um agrupamento de arquivos de conteúdo e código em um site do IIS que processa solicitações de um espaço de URL específico. As aplicações no IIS podem ter suas próprias configurações, que normalmente são armazenadas em arquivos `web.config`.  
Ao migrar para o Elastic Beanstalk, as aplicações são preservadas com sua estrutura de caminho e suas definições de configuração. O processo de migração garante que as aplicações aninhadas mantenham sua hierarquia e caminhos de URL no ambiente de nuvem.

****ApplicationPool****  
Um recurso do IIS que isola aplicações Web para melhorar a segurança, a confiabilidade e o gerenciamento do desempenho. Grupos de aplicações definem o ambiente de runtime das aplicações, incluindo a versão do .NET Framework, o modo de pipeline e as configurações de identidade.

****VirtualDirectory****  
Um mapeamento de diretórios no IIS que permite que o conteúdo seja servido de um local fora do diretório raiz do site. Diretórios virtuais permitem que você organize o conteúdo em diferentes locais físicos e, ao mesmo tempo, apresente uma estrutura de URL unificada aos usuários.  
Ao migrar para o Elastic Beanstalk, os diretórios virtuais são preservados com seus mapeamentos de caminhos. O comando **eb migrate** cria a estrutura de diretórios e as configurações necessárias no ambiente de nuvem para manter os mesmos caminhos de URL.

****ARR****  
Roteamento de solicitações de aplicações, uma extensão do IIS que fornece recursos de balanceamento de carga e proxy para servidores Web. O ARR permite roteamento baseado em URL, encaminhamento de solicitações HTTP e distribuição de carga em vários servidores.  
Durante a migração para o Elastic Beanstalk, as configurações de ARR são preservadas por meio da instalação de recursos de ARR em instâncias do EC2 e da configuração de regras de roteamento apropriadas. Para cenários complexos de roteamento, o processo de migração também pode aproveitar as regras do Application Load Balancer para implementar funcionalidades semelhantes.

****Reescrita de URL****  
Um módulo do IIS que modifica as solicitações URLs com base em regras definidas antes que elas cheguem ao aplicativo web. A reescrita de URL permite a manipulação, o redirecionamento e a entrega de conteúdo de URL com base em padrões e condições.  
Ao migrar para o Elastic Beanstalk, as regras de regravação de URL dos seus arquivos `web.config` são convertidas em regras de roteamento do ALB sempre que possível ou preservadas na configuração do IIS nas instâncias do EC2. Isso garante que os padrões e redirecionamentos de URL continuem funcionando conforme o esperado no ambiente de nuvem.

****msdeploy.exe****  
Uma ferramenta de linha de comando usada para implantar aplicações e sites da Web em servidores IIS. Também conhecida como Web Deploy, ela fornece uma maneira de empacotar, sincronizar e implantar aplicações Web, sites e configurações de servidores.  
O comando **eb migrate** usa o Web Deploy (versão 3.6 ou posterior) para empacotar suas aplicações durante a migração para o Elastic Beanstalk. Essa ferramenta deve estar instalada no servidor de origem para que o processo de migração funcione corretamente.

****Caminho físico****  
A localização real do sistema de arquivos em que os arquivos de conteúdo de um site ou aplicação do IIS são armazenados. Caminhos físicos podem apontar para diretórios locais, compartilhamentos de rede ou outros locais de armazenamento acessíveis ao servidor IIS.  
Durante a migração para o Elastic Beanstalk, os caminhos físicos são mapeados para os locais apropriados nas instâncias do EC2 no seu ambiente. O processo de migração preserva a estrutura do conteúdo e garante que todos os arquivos sejam implantados adequadamente no ambiente de nuvem.

****ApplicationHost.config****  
O arquivo de configuração raiz do IIS que define as configurações de todo o servidor e contém configurações para todos os sites, aplicações e diretórios virtuais. Esse arquivo está localizado no diretório `%windir%\System32\inetsrv\config` e controla o comportamento geral do servidor IIS.  
Ao migrar para o Elastic Beanstalk, as configurações relevantes de `applicationHost.config` são extraídas e aplicadas à configuração do IIS nas instâncias do EC2 no seu ambiente. Isso garante que as configurações de todo o servidor sejam preservadas durante a migração.

****web.config****  
Um arquivo de configuração baseado em XML usado em aplicações ASP.NET para controlar as configurações, a segurança e o comportamento da aplicação no nível da aplicação ou do diretório. Arquivos `web.config` podem conter configurações para autenticação, autorização, estado da sessão, compilação e parâmetros personalizados da aplicação.  
Durante a migração para o Elastic Beanstalk, os arquivos `web.config` são preservados e implantados com a sua aplicação. O processo de migração garante que as configurações específicas da aplicação continuem funcionando conforme o esperado no ambiente de nuvem.

****DefaultDocument****  
Um recurso do IIS que especifica o arquivo padrão a ser exibido quando um usuário solicita um diretório sem especificar um nome de arquivo. Os documentos padrão são habilitados por padrão, e o IIS 7 define os seguintes arquivos de documentos padrão no arquivo `applicationHost.config` como padrões para todo o servidor: Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm.  
Ao migrar para o Elastic Beanstalk, as configurações padrão do documento são preservadas na configuração do IIS nas instâncias do EC2, garantindo que as solicitações de diretório sejam tratadas de forma consistente no ambiente de nuvem.

****system.webServer****  
Uma seção de configuração no `web.config` ou `applicationHost.config` que contém configurações específicas do IIS para módulos, manipuladores e outros comportamentos do servidor. Esta seção controla como o IIS processa solicitações, gerencia módulos e configura os recursos do servidor.  
Durante a migração para o Elastic Beanstalk, as configurações de system.webServer são preservadas nos arquivos `web.config` da sua aplicação e aplicadas à instalação do IIS nas instâncias do EC2 no seu ambiente. Isso garante que os comportamentos específicos do IIS sejam mantidos no ambiente de nuvem.

## Termos do Elastic Beanstalk
<a name="dotnet-migrating-applications-glossary-eb"></a>

****Plataforma****  
Uma combinação de sistema operacional, runtime da linguagem de programação, servidor Web, servidor de aplicações e componentes do Elastic Beanstalk que definem a pilha de software para executar aplicações.  
Para migrações do Windows, o Elastic Beanstalk fornece plataformas baseadas no Windows Server 2016, 2019 e 2022 com IIS e várias versões do .NET Framework para garantir a compatibilidade com o seu ambiente de origem.

****SolutionStack****  
Uma configuração de plataforma predefinida no Elastic Beanstalk que especifica o sistema operacional, o runtime e outros componentes necessários para executar uma aplicação. Conceitualmente idêntico a uma plataforma e usado de forma intercambiável para operar ambientes.  
Durante a migração, o comando **eb migrate** seleciona uma stack de soluções apropriada com base na configuração do ambiente de origem, garantindo a compatibilidade com as suas aplicações do IIS.

****CreateEnvironment****  
Uma ação da API do Elastic Beanstalk que cria um novo ambiente para hospedar uma versão da aplicação. Essa API é usada pelo comando **eb migrate** para provisionar os recursos da AWS necessários para a sua aplicação migrada.  
O processo de migração configura os parâmetros de ambiente apropriados com base no seu ambiente do IIS de origem, incluindo tipo de instância, variáveis de ambiente e configurações de opções.

****CreateApplicationVersion****  
Uma ação da API do Elastic Beanstalk que cria uma nova versão da aplicação a partir de um pacote de origem armazenado no Amazon S3. O comando **eb migrate** usa essa API para registrar sua aplicação IIS empacotado como uma versão no Elastic Beanstalk.  
Durante a migração, os arquivos e a configuração da aplicação são empacotados, enviados ao Amazon S3 e registrados como uma versão da aplicação antes da implantação.

****DescribeEvents****  
Uma ação da API do Elastic Beanstalk que recupera uma lista de eventos para um ambiente, incluindo implantações, alterações de configuração e problemas operacionais. O comando **eb migrate** usa essa API para monitorar o andamento da migração.  
Você também pode usar o comando após **eb events** a migração para visualizar o histórico de eventos do seu ambiente.

****DescribeEnvironmentHealth****  
Uma ação da API do Elastic Beanstalk que fornece informações detalhadas de integridade sobre as instâncias e outros componentes de um ambiente. Essa API é usada para verificar a integridade do sua aplicação migrado após a implantação.  
Após a migração, você pode usar o comando **eb health** para verificar o status do seu ambiente e identificar quaisquer problemas que precisem de atenção.

****HealthD****  
Um agente de monitoramento no Elastic Beanstalk que coleta métricas, monitora logs e relata o status de integridade das instâncias do EC2 em um ambiente. HealthD fornece relatórios de integridade aprimorados para as suas aplicações migradas.  
Após a migração, HealthD monitora o desempenho da aplicação, a utilização dos recursos e as taxas de sucesso das solicitações, fornecendo uma visão abrangente da integridade do seu ambiente.

****Registros do pacote****  
Um recurso do Elastic Beanstalk que compacta e carrega logs de instâncias do EC2 para o Amazon S3 para armazenamento e análise centralizados. Esse recurso ajuda você a solucionar problemas com suas aplicações migradas.  
Após a migração, você pode usar o comando **eb logs** para recuperar e visualizar os registros do seu ambiente.

****aws-windows-deployment-manifest.json****  
Um arquivo que descreve o conteúdo, as dependências e a configuração de um pacote de software ou aplicação. Esse manifesto é gerado durante o processo de migração para definir como suas aplicações IIS devem ser implantadas no Elastic Beanstalk.

****seção de manifesto personalizada****  
Uma seção dentro de `aws-windows-deployment-manifest.json` que fornece controle personalizado sobre a implantação da aplicação. Esta seção contém PowerShell scripts e comandos que são executados durante o processo de implantação.  
Durante a migração, seções de manifesto personalizadas são geradas para lidar com aspectos específicos da configuração do IIS, como configuração do diretório virtual, gerenciamento de permissões e configuração do grupo de aplicações.

****EB CLI****  
Uma ferramenta de linha de comando que fornece comandos para criar, configurar e gerenciar aplicações e ambientes do Elastic Beanstalk. A EB CLI inclui o comando **eb migrate** específico para migrar aplicações do IIS para o Elastic Beanstalk.  
Depois da migração, é possível continuar usando a EB CLI para gerenciar o ambiente, implantar atualizações, monitorar a integridade e realizar outras tarefas administrativas.

****Configurações da opção****  
Valores de configuração que definem como o Elastic Beanstalk provisiona AWS e configura recursos em seu ambiente. As configurações das opções são organizadas em namespaces que representam diferentes componentes do seu ambiente, como balanceadores de carga, instâncias e processos do ambiente.  
Durante a migração, o comando **eb migrate** gera as configurações de opções apropriadas com base na configuração do IIS para garantir que seu ambiente de nuvem corresponda aos recursos do seu ambiente de origem. Para obter mais informações, consulte [Opções de configuração](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html), no Guia do desenvolvedor do Elastic Beanstalk.

****aws:elbv2:listener:default****  
Um namespace de configuração do Elastic Beanstalk para o ouvinte padrão em um Application Load Balancer. Durante a migração, esse namespace é configurado com base nas associações do site do IIS para garantir o roteamento de tráfego adequado.  
O ouvinte padrão normalmente manipula o tráfego HTTP na porta 80, que é então encaminhado para as instâncias da sua aplicação de acordo com as regras de roteamento.

****aws:elbv2: listener: listener\$1port****  
Um namespace de configuração do Elastic Beanstalk para uma porta de escuta específica em um Application Load Balancer. Esse namespace é usado para configurar receptores adicionais para suas aplicações migrados, como HTTPS na porta 443.  
Durante a migração, os receptores são criados com base nas associações de portas dos sites do IIS, garantindo que suas aplicações permaneçam acessíveis nas mesmas portas do ambiente de origem.

****aws:elbv2: listenerrule:rule\$1name****  
Um namespace de configuração do Elastic Beanstalk para definir regras de roteamento para um receptor do Application Load Balancer. Essas regras determinam como as solicitações recebidas são roteadas para diferentes grupos-alvo com base nos padrões de caminho ou nos cabeçalhos do host.  
Durante a migração, as regras de receptores são criadas para corresponder à estrutura de URL das aplicações do IIS, garantindo que as solicitações sejam roteadas para os caminhos corretos da aplicação.

****aws: elasticbeanstalk: ambiente: processo: padrão****  
Um namespace de configuração do Elastic Beanstalk para o processo padrão em um ambiente. Esse namespace define como o processo padrão da aplicação Web é configurado, incluindo configurações de verificação de integridade, mapeamentos de portas e configurações de proxy.  
Durante a migração, o processo padrão é configurado com base nas configurações do site principal do IIS, garantindo o monitoramento adequado da integridade e o tratamento de solicitações.

****aws: elasticbeanstalk: ambiente: processo: nome\$1de\$1processo****  
Um namespace de configuração do Elastic Beanstalk para um processo nomeado específico em um ambiente. Esse namespace permite definir vários processos com configurações diferentes, semelhante a ter vários grupos de aplicações no IIS.  
Durante a migração, processos adicionais podem ser criados para representar diferentes associações de sites do seu ambiente de origem.

**nota**  
Para obter mais informações sobre alguns dos termos descritos neste tópico, consulte os seguintes recursos:  
[Ações da API do Elastic Beanstalk — Referência da API AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/)
*Plataformas do Elastic Beanstalk, incluindo versões de plataforma compatíveis - [Plataformas suportadas](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) no Guia de plataformas do AWS Elastic Beanstalk *
Namespaces de configuração do Elastic Beanstalk - [Opções gerais para todos os ambientes](command-options-general.md) neste guia
A EB CLI ou comandos específicos da EB CLI - [Configurar a interface de linha de comando EB (EB CLI) para gerenciar o Elastic Beanstalk](eb-cli3.md) neste guia

## Termos do Python
<a name="dotnet-migrating-applications-glossary-python"></a>

****pip****  
O instalador de pacotes para Python, usado para instalar e gerenciar pacotes de software escritos em Python. A EB CLI é instalada e atualizada usando o pip.  
Durante o processo de migração, o pip é usado para instalar o pacote da EB CLI e suas dependências no servidor de origem, fornecendo as ferramentas necessárias para a migração.

****PyPI****  
Python Package Index, o repositório oficial para pacotes de software Python de terceiros, do qual o pip recupera e instala pacotes. A EB CLI e suas dependências são hospedados no PyPI.  
Ao instalar a EB CLI para migração, o pip se conecta ao PyPI para baixar e instalar os pacotes necessários.

****ambiente virtual****  
Uma ferramenta para criar ambientes Python isolados, permitindo que diferentes projetos tenham suas próprias dependências e pacotes sem conflitos. O uso do virtualenv é recomendado ao instalar a EB CLI para evitar conflitos com outras aplicações Python.  
Criar um ambiente virtual antes de instalar a EB CLI garante que as ferramentas de migração tenham um ambiente limpo e isolado com as dependências corretas.

****pywin32****  
Um conjunto de extensões do Python que fornecem acesso a muitos dos Windows APIs, permitindo a interação com o sistema operacional Windows e seus componentes. A EB CLI usa pywin32 para interagir com recursos específicos do Windows durante a migração.  
Durante o processo de migração, o pywin32 é usado para acessar a configuração do IIS, as configurações do registro do Windows e outras informações do sistema necessárias para empacotar e migrar adequadamente suas aplicações.

****pythonnet****  
Um pacote que permite que o código Python interaja com aplicações .NET Framework e o .NET Core. Essa integração permite que a EB CLI trabalhe com componentes do .NET durante o processo de migração.  
O processo de migração pode usar pythonnet para interagir com assemblies e componentes do .NET ao analisar e empacotar suas aplicações para implantação no Elastic Beanstalk.

# Executar migrações básicas do IIS
<a name="dotnet-migrating-applications-basic-migration"></a>

Esta seção orientará você no processo de migração de aplicações do IIS para o Elastic Beanstalk usando o comando **eb migrate**.

## Explorar seu ambiente do IIS
<a name="dotnet-migrating-applications-basic-migration-exploring"></a>

Antes de fazer qualquer alteração, você deve entender quais recursos existem no seu servidor. Comece explorando os sites do IIS executando **eb migrate explore**, conforme mostrado no exemplo a seguir:

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

Esse comando revela seus sites do IIS. Consulte a lista a seguir:

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

Para obter uma visão detalhada da configuração de cada site, incluindo vinculações, aplicações e diretórios virtuais, adicione a opção `--verbose`, conforme mostrado neste exemplo:

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

A lista a seguir mostra as informações abrangentes sobre seu ambiente que o comando fornece:

```
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:
...
```

### Entender o resultado da descoberta
<a name="dotnet-migrating-applications-basic-migration-exploring-output"></a>

A saída detalhada fornece as seguintes informações críticas para o planejamento da migração:

Sites  
A saída da descoberta lista todos os sites do IIS no seu servidor. Cada site é identificado por seu nome (por exemplo, “Site padrão”, “Intranet”, “API.internal”) e numerado sequencialmente. Quando existem vários sites em um servidor, o comando `eb migrate` pode empacotar e implantar cada um separadamente ou em conjunto, dependendo da sua estratégia de migração.

Associações  
As vinculações de protocolo revelam quais protocolos (HTTP/HTTPS) seus sites usam e em quais portas eles operam. As informações de vinculação incluem os requisitos do cabeçalho do host que definem as configurações de roteamento com base no domínio.

Aplicativos  
Os caminhos da aplicação mostram as estruturas da aplicação raiz e aninhada na configuração do IIS. As atribuições do grupo de aplicações indicam como suas aplicações são isoladas umas das outras para fins de segurança e gerenciamento de recursos.

Diretórios virtuais  
Os mapeamentos de caminhos físicos indicam onde seu conteúdo reside no sistema de arquivos. As configurações de autenticação mostram requisitos de acesso especiais que precisam ser mantidos após a migração.

## Preparar-se para migração
<a name="dotnet-migrating-applications-basic-migration-preparing"></a>

Com uma compreensão do ambiente, garanta que o servidor atenda aos pré-requisitos. Primeiro, verifique sua versão do IIS com o seguinte PowerShell comando:

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

Você precisa do IIS 7.0 ou posterior. A ferramenta de migração usa o Web Deploy 3.6 para empacotar suas aplicações. Verifique a instalação com o seguinte comando:



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

Se o Web Deploy não estiver instalado em seu servidor, você poderá baixá-lo na página de download do [Microsoft Web Platform Installer](https://www.iis.net/downloads/microsoft/web-deploy).

## Sua primeira migração
<a name="dotnet-migrating-applications-basic-migration-first"></a>

Vamos começar com uma migração básica do site padrão. O exemplo a seguir mostra o comando mais simples, **eb migrate**.

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

Esse comando inicia uma série de etapas automatizadas, mostradas no exemplo de saída a seguir:

```
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
```

A ferramenta de migração cria um diretório estruturado contendo seus artefatos de implantação. A lista a seguir mostra a estrutura do diretório:

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

## Controlar a migração
<a name="dotnet-migrating-applications-basic-migration-controlling"></a>

Para ter mais controle sobre o processo de migração, você pode especificar exatamente quais sites migrar com o seguinte comando:

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

Também é possível personalizar o nome do ambiente e da aplicação, conforme mostrado no seguinte exemplo de comando:

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

Para obter uma lista completa de opções, consulte [**eb migrate**](eb3-migrate.md).

## Monitorar o progresso
<a name="dotnet-migrating-applications-basic-migration-monitoring"></a>

Durante a migração, **eb migrate** fornece atualizações de status em tempo real. Consulte o seguinte exemplo de saída:

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

## Verificar a migração
<a name="dotnet-migrating-applications-basic-migration-verifying"></a>

Quando o ambiente estiver pronto, o Elastic Beanstalk fornece várias maneiras de verificar sua implantação.

Acessar sua aplicação  
Abra o URL da aplicação (CNAME) em um navegador da Web para verificar se ela está funcionando corretamente.

Verificar a integridade do ambiente  
Use o **eb health** comando para visualizar a integridade do ambiente.  

```
PS C:\migrations_workspace> eb health
```
A imagem da tela a seguir mostra a integridade da instância, as métricas de resposta da aplicação e a utilização dos recursos do sistema.  

![\[A saída do comando eb health mostra a integridade da instância, as métricas de resposta da aplicação e a utilização dos recursos do sistema.\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/eb-health-after-migration.png)


Use o comando **eb logs** para acessar logs e solucionar qualquer problema:  

```
PS C:\migrations_workspace> eb logs --zip
```
O comando **eb logs** baixa os logs para o diretório `.elasticbeanstalk/logs`. Para obter mais informações, consulte [Usando o Elastic CloudWatch Beanstalk com o Amazon Logs](AWSHowTo.cloudwatchlogs.md).

Conectar-se a instâncias  
Se você especificou um par de chaves durante a migração, pode se conectar às suas instâncias usando o RDP para solucionar problemas diretamente.

Acessar o console do Elastic Beanstalk  
É possível visualizar a integridade, os logs e as propriedades de configuração do ambiente por meio do [console de gerenciamento do ambiente](environments-console.md) desse ambiente. 

## Gerenciar artefatos de migração
<a name="dotnet-migrating-applications-basic-migration-cleanup"></a>

O comando **eb migrate** cria artefatos locais durante o processo de migração. Esses artefatos contêm informações confidenciais e podem consumir um espaço significativo em disco com o passar do tempo. Use o subcomando **cleanup** para gerenciar esses artefatos, conforme mostrado no exemplo a seguir:

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

Para forçar a limpeza sem confirmação, use a opção **--force**:

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

O processo de limpeza preserva a migração bem-sucedida mais recente `./migrations/latest` no diretório e remove os diretórios de migração mais antigos.

# Configuração de rede e de porta
<a name="dotnet-migrating-applications-network"></a>

Esta seção aborda as opções de configuração de rede para migrações do IIS, incluindo configurações de VPC, configurações de portas e implantações em vários sites.

## Configuração de VPC
<a name="dotnet-migrating-applications-network-vpc"></a>

O comando **eb migrate** oferece opções de configuração de VPC flexíveis para o ambiente do Elastic Beanstalk. A ferramenta pode detectar configurações de VPC de uma instância do EC2 de origem ou aceitar configurações personalizadas de VPC por meio de parâmetros de linha de comando. Analise [Usar o Elastic Beanstalk com Amazon VPC](vpc.md) para entender como configurar o Elastic Beanstalk com a VPC.

### Detecção automática de VPC
<a name="dotnet-migrating-applications-network-vpc-auto"></a>

Quando **eb migrate** é executado em uma instância do EC2, ele descobre e usa automaticamente a configuração de VPC das instâncias do EC2 do ambiente de origem. O exemplo de saída a seguir ilustra as informações de configuração detectadas:

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

A configuração detectada inclui:
+ Identificador de VPC
+ Configurações de atribuição de IP público
+ Esquema de balanceamento de carga (público/privado)
+ Atribuições de sub-rede de instâncias do EC2
+ Associações de grupos de segurança
+ Atribuições de sub-rede do balanceador de carga

### Hosts locais ou fora AWS da nuvem
<a name="dotnet-migrating-applications-network-vpc-onprem"></a>

Quando **eb migrate** executado a partir de um servidor local ou de um host fora da AWS nuvem, o serviço Elastic Beanstalk usará a VPC padrão em sua conta. AWS A lista a seguir mostra um exemplo de comando e saída:

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

Analise [Usar o Elastic Beanstalk com Amazon VPC](vpc.md) para entender como o Elastic Beanstalk configura a VPC padrão para um ambiente.

### Configuração personalizada da VPC
<a name="dotnet-migrating-applications-network-vpc-custom"></a>

Para qualquer ambiente de origem (EC2, local ou fora da AWS nuvem) em que você precise de configurações específicas de VPC, forneça um arquivo de configuração de VPC como o mostrado no exemplo a seguir:

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

Aplique esta configuração usando o seguinte comando:

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

**nota**  
O arquivo de configuração da VPC exige o campo `id` que especifica a ID da VPC. Todos os outros campos são opcionais, e o Elastic Beanstalk usará valores padrão para qualquer campo que você não especificar.

**Importante**  
*A migração ignorará todas as configurações de VPC existentes do ambiente de origem quando você especificar o *parâmetro* *`--vpc-config`. Quando você usa esse parâmetro, a migração usará apenas as configurações de VPC especificadas no arquivo de configuração que você está passando. O uso desse parâmetro substitui o comportamento padrão de descobrir a configuração da VPC da instância de origem ou usar a VPC padrão.

Use o parâmetro `--vpc-config` nesses cenários:
+ Ao migrar ambientes não EC2 que não têm configurações de VPC detectáveis
+ Quando você migra para uma VPC diferente daquela usada pelo ambiente de origem
+ Quando você precisa personalizar seleções de sub-rede ou configurações de grupos de segurança
+ Quando a descoberta automática não identifica corretamente as configurações de VPC desejadas
+ Quando você migra do ambiente on-premises e não quer usar a VPC padrão

### Configuração de segurança de rede
<a name="dotnet-migrating-applications-network-vpc-security"></a>

Por padrão, **eb migrate** abre a porta 80 nas instâncias de destino, mas não copia outras regras do Firewall do Windows da máquina de origem. Para incluir todas as configurações de firewall, use o seguinte comando:

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

Esse comando faz as seguintes ações:
+ Identifica as portas usadas pelas associações de sites do IIS
+ Recupera regras de firewall correspondentes
+ Gera PowerShell scripts para recriar regras nas instâncias de destino
+ Preserva todas as regras DENY para a porta 80 da máquina de origem (caso contrário, a porta 80 é permitida por padrão)

Considere um caso de uso em que sua máquina de origem tem as regras de firewall especificadas no exemplo a seguir:

```
# 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
```

A migração cria um script (`modify_firewall_config.ps1`) que contém a seguinte configuração:

```
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
```

A ferramenta de migração executa automaticamente as seguintes ações:
+ Extrai HTTP/HTTPS portas de todas as ligações de sites do IIS
+ Usa a interface do Windows Firewall [INetFwPolicy2](https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwpolicy2) para enumerar as regras de firewall
+ Filtra as regras para incluir somente aquelas que fazem referência explícita às portas especificadas
+ Processa somente associações de sites HTTP e HTTPS e suas regras de firewall associadas
+ Preserva as propriedades da regra, incluindo nome de exibição, ação, protocolo e estado habilitado
+ Lida com portas individuais e intervalos de portas nas regras de firewall
+ Adiciona o script de configuração do firewall ao manifesto de implantação

### Configuração do balanceador de carga
<a name="dotnet-migrating-applications-network-vpc-lb"></a>

É possível especificar a configuração do balanceador de carga por meio do argumento `--vpc-config`. Os exemplos a seguir demonstram os parâmetros.

Seleção de esquema  
Escolha entre esquemas de balanceador de carga públicos e privados:  

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

Distribuição de sub-rede  
Para obter alta disponibilidade, distribua sub-redes do balanceador de carga entre as zonas de disponibilidade:  

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

**nota**  
Embora o Elastic Beanstalk seja compatível com a criação de ambientes com Application Load Balancers, Network Load Balancers e Classic Load Balancers, o comando **eb migrate** apenas aceita Application Load Balancers. Para obter mais informações sobre os tipos de balanceador de carga, consulte [Balanceador de carga do ambiente do Elastic Beanstalk](using-features.managing.elb.md).

## Implantações em vários locais com configurações de portas
<a name="dotnet-migrating-applications-network-multi"></a>

O comando **eb migrate** manipula implantações complexas do IIS em vários sites, onde as aplicações podem compartilhar dependências ou usar portas não padrão. Considere o exemplo a seguir de uma configuração corporativa típica com vários sites:

```
<!-- 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 essa configuração, use o seguinte comando e parâmetros de exemplo:

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

O comando **eb migrate** cria um pacote de implantação que preserva a identidade e a configuração de cada site. O comando gera um `aws-windows-deployment-manifest.json` que define como esses sites devem ser implantados. O exemplo a seguir ilustra um arquivo json gerado:

```
{
    "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"
                    }
                }
            }
        ]
    }
}
```

O processo de migração cria as seguintes regras de ouvinte do Application Load Balancer que mantêm sua lógica de roteamento original:
+ Rotas de tráfego da porta 80 para o site padrão
+ Rotas de tráfego da porta 8081 para InternalAPI
+ Rotas de tráfego da porta 8082 para ReportingPortal

## Configuração e dependências compartilhadas
<a name="dotnet-migrating-applications-network-shared"></a>

Quando os sites compartilham configurações ou dependências, **eb migrate** gerencia esses relacionamentos adequadamente. Consulte o exemplo a seguir em que vários sites compartilham uma configuração comum:

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

O processo de migração conclui as seguintes tarefas:

1. Identifica configurações compartilhadas entre sites

1. Gera PowerShell scripts apropriados para aplicar essas configurações

1. Mantém a hierarquia e a herança da configuração

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

Recomendamos que você siga as práticas recomendadas da configuração de rede da aplicação migrado. Os agrupamentos a seguir fornecem diretrizes resumidas.

Design em VPC  
+ Siga as AWS melhores práticas de design de VPC
+ Usar sub-redes separadas para balanceadores de carga e instâncias do EC2
+ Implemente tabelas de rotas adequadas e NACLs
+ Considere os endpoints de VPC para serviços AWS 

Alta disponibilidade  
+ Implantar em diversas zonas de disponibilidade
+ Usar pelo menos duas sub-redes para balanceadores de carga
+ Configure o auto-scaling em AZs
+ Implementar verificações de integridade adequadas

Segurança  
+ Seguir práticas recomendadas de segurança
+ Usar grupos de segurança como controle de acesso primário
+ Implemente listas de controle de acesso à rede (ACLs) para segurança adicional
+ Monitorar logs de fluxo da VPC

## Solução de problemas
<a name="dotnet-migrating-applications-network-troubleshooting"></a>

Os problemas comuns de configuração de rede incluem as seguintes áreas. Depois de cada assunto, há exemplos de comandos para obter mais informações sobre a configuração da rede e a integridade do seu ambiente.

Configuração de sub-rede  

```
# 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'
```

Acesso ao grupo de segurança₢  

```
# 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
```

Integridade do balanceador 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
```

# Configurações de segurança e perfis do IAM
<a name="dotnet-migrating-applications-security"></a>

O **eb migrate** comando gerencia as configurações AWS de segurança por meio de funções do IAM, perfis de instância e funções de serviço. A compreensão desses componentes garante o controle de acesso adequado e a conformidade com a segurança durante a migração.

## Configuração de perfil de instância
<a name="dotnet-migrating-applications-security-instance"></a>

Um perfil de instância serve como um contêiner para um perfil do IAM que o Elastic Beanstalk atribui às instâncias do EC2 no seu ambiente. Ao executar **eb migrate**, você pode especificar um perfil de instância personalizado:

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

Se você não especificar um perfil de instância, o **eb migrate** criará um padrão com as seguintes permissões:

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

****  

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

------

## Gerenciamento de perfis de serviço
<a name="dotnet-migrating-applications-security-service"></a>

Uma função de serviço permite que o Elastic Beanstalk gerencie recursos em AWS seu nome. Especifique um perfil de serviço personalizado durante a migração com o seguinte comando:

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

Se não for especificado, **eb migrate** criará um perfil de serviço padrão chamada `aws-elasticbeanstalk-service-role`, com uma política de confiança que permite ao Elastic Beanstalk assumir o perfil. Esse perfil de serviço é essencial para que o Elastic Beanstalk monitore a integridade do ambiente e realize atualizações gerenciadas de plataforma. O perfil de serviço requer duas políticas gerenciadas:
+ `AWSElasticBeanstalkEnhancedHealth`: permite que o Elastic Beanstalk monitore a integridade do ambiente e da instância usando o sistema aprimorado de relatórios de integridade
+ `AWSElasticBeanstalkManagedUpdates`: permite que o Elastic Beanstalk realize atualizações gerenciadas da plataforma, incluindo a atualização dos recursos do ambiente quando uma nova versão da plataforma estiver disponível

Com essas políticas, o perfil de serviço tem permissões para:
+ Criar e gerenciar grupos do Auto Scaling
+ Criar e gerenciar Application Load Balancers
+ Carregar registros para a Amazon CloudWatch
+ Gerenciar instâncias do EC2

Para obter mais informações sobre perfis de serviço, consulte [Função de serviço do Elastic Beanstalk](concepts-roles-service.md) no Guia do desenvolvedor do Elastic Beanstalk.

## Configuração do security group
<a name="dotnet-migrating-applications-security-sg"></a>

O comando **eb migrate** configura grupos de segurança automaticamente com base em associações de sites do IIS. Por exemplo, se seu ambiente de origem tiver sites usando as portas 80, 443 e 8081, os seguintes resultados de configuração:

```
<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>
```

O processo de migração conclui as seguintes ações:
+ Cria um grupo de segurança do balanceador de carga que permite tráfego de entrada nas portas 80 e 443 da Internet (0.0.0.0/0)
+ Cria um grupo de segurança do EC2 que permite tráfego do balanceador de carga
+ Configura portas adicionais (como 8081) se `--copy-firewall-config` for especificado

Por padrão, o Application Load Balancer é configurado com acesso público pela Internet. Se precisar personalizar esse comportamento, como restringir o acesso a intervalos de IP específicos ou usar um balanceador de carga privado, substitua a configuração padrão da VPC e do grupo de segurança usando o parâmetro `--vpc-config`:

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

Por exemplo, a configuração `vpc-config.json` a seguir cria um balanceador de carga privado em uma sub-rede privada:

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

Para obter mais informações sobre as opções de configuração da VPC, consulte [Configuração de VPC](dotnet-migrating-applications-network.md#dotnet-migrating-applications-network-vpc).

## Integração de certificados SSL
<a name="dotnet-migrating-applications-security-ssl"></a>

Ao migrar sites com ligações HTTPS, integre certificados SSL por meio AWS Certificate Manager do (ACM):

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

Essa configuração conclui as seguintes ações:
+ Associa o certificado ao Application Load Balancer
+ Mantém a terminação HTTPS no balanceador de carga
+ Preserva a comunicação HTTP interna entre o balanceador de carga e as instâncias do EC2

## Autenticação do Windows
<a name="dotnet-migrating-applications-security-windows"></a>

Para aplicações que usam a Autenticação do Windows, **eb migrate** preserva as configurações de autenticação no `web.config` da aplicação, da seguinte maneira:

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

**Importante**  
O comando **eb migrate** não copia perfis ou contas de usuário do seu ambiente de origem para as instâncias de destino do Elastic Beanstalk. Todas as contas de usuário ou grupos personalizados que você criou no servidor de origem precisarão ser recriados no ambiente de destino após a migração.

Contas integradas do Windows, como `IUSR` e grupos como `IIS_IUSRS`, bem como todas as outras contas e grupos integrados, são incluídos por padrão nas instâncias do Windows Server do destino. Para obter mais informações sobre contas e grupos internos do IIS, consulte [Sobre contas de usuário e grupo incorporadas no IIS](https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis) na documentação da Microsoft.

Se sua aplicação depende de contas de usuário personalizadas do Windows ou da integração com o Active Directory, você precisará configurar esses aspectos separadamente após a conclusão da migração.

## Práticas recomendas e solução de problemas
<a name="dotnet-migrating-applications-security-best"></a>

### Gerenciamento de perfis
<a name="dotnet-migrating-applications-security-best-role"></a>

Implemente as melhores práticas AWS do IAM ao gerenciar funções em seus ambientes do Elastic Beanstalk:

Criação e gerenciamento de perfis  
+ Crie funções usando políticas AWS gerenciadas sempre que possível
+ Siga as [Práticas recomendadas de segurança do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ Use o [AWS Policy Generator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) para políticas personalizadas
+ Implemente [limites de permissão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) para segurança adicional

Monitoramento e auditoria  
Habilite AWS CloudTrail para monitorar o uso da função:  
+ Siga o [Guia do usuário do AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ Configure a integração de CloudWatch registros para monitoramento em tempo real
+ Configure alertas para chamadas de API não autorizadas

Processo regular de revisão  
Estabeleça um ciclo de revisão trimestral para realizar as seguintes tarefas:  
+ Auditar permissões não utilizadas usando o [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ Remover permissões desatualizadas
+ Atualizar funções com base nos princípios de privilégios mínimos

### Gerenciamento de certificado
<a name="dotnet-migrating-applications-security-best-cert"></a>

Implemente essas práticas para SSL/TLS certificados em seus ambientes do Elastic Beanstalk:

Ciclo de vida do certificado  
+ Usar [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) para o gerenciamento de certificados
+ Habilitar a [renovação automática](https://docs.aws.amazon.com/acm/latest/userguide/check-certificate-renewal-status.html) para certificados emitidos pelo ACM
+ Configurar [notificações de expiração](https://docs.aws.amazon.com/acm/latest/userguide/notifications-for-ACM.html)

Padrões de segurança  
+ Usar TLS 1.2 ou posterior
+ Seguir [políticas de segurança da AWS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) para receptores HTTPS
+ Implementar o HTTP Strict Transport Security (HSTS), se necessário

### Gerenciamento de grupos de segurança
<a name="dotnet-migrating-applications-security-best-sg"></a>

Implemente estas melhores práticas de grupos de segurança:

Gerenciamento de regras  
+ Documentar todos os requisitos de porta personalizados
+ Usar [Logs de fluxo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) para monitorar o tráfego
+ Usar [regras de referência de grupos de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) em vez de intervalos de IP sempre que possível

Auditorias regulares  
Estabeleça revisões mensais para realizar as seguintes tarefas:  
+ Identificar e remover regras não utilizadas
+ Valide os source/destination requisitos
+ Verificar se há regras sobrepostas

### Registro em log e monitoramento
<a name="dotnet-migrating-applications-security-best-logging"></a>

Para um monitoramento de segurança eficaz, configure os seguintes logs:

Logs de eventos do Windows em instâncias do 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 Integração de registros  
Configure o agente de CloudWatch registros para transmitir registros de eventos do Windows CloudWatch para monitoramento e alertas centralizados.

Para problemas persistentes, reúna esses registros e entre em contato AWS Support com as seguintes informações:
+ ID do ambiente
+ ID de implantação (se aplicável)
+ Mensagens de erro relevantes
+ Cronograma das alterações de segurança

# Sobre o mapeamento de migração do IIS para o Elastic Beanstalk
<a name="dotnet-migrating-applications-mapping"></a>

A migração do IIS para o Elastic Beanstalk envolve o mapeamento da configuração do servidor Windows local para os recursos da nuvem. AWS Compreender esse mapeamento é essencial para migrações de sucesso e gerenciamento pós-migração.

## Sites e aplicações do IIS no Elastic Beanstalk
<a name="dotnet-migrating-applications-mapping-sites"></a>

No IIS, um site representa uma coleção de aplicações da Web e diretórios virtuais, cada um com sua própria configuração e conteúdo. Na migração para o Elastic Beanstalk, esses componentes são transformados da seguinte forma:

**Sites do IIS**  
Seus sites do IIS se tornam aplicações dentro do Elastic Beanstalk. A configuração de cada site, incluindo suas associações, grupos de aplicações e configurações de autenticação, é preservada por meio do manifesto de implantação (`aws-windows-deployment-manifest.json`) do Elastic Beanstalk.  
Por exemplo, se você tiver vários sites, como o *site padrão *IntranetSite**, **eb migrate** empacota o conteúdo e a configuração de cada site, mantendo seu isolamento.  
O comando cria regras de ouvinte apropriadas do Application Load Balancer (ALB) para lidar com solicitações de roteamento para suas aplicações. Ele também configura grupos de segurança para garantir o acesso adequado às portas com base nas associações originais do IIS.

**Grupos de aplicações**  
Grupos de aplicações do IIS fornecem isolamento de processos de trabalho, gerenciamento de runtime e recursos de reciclagem para suas aplicações. No Elastic Beanstalk, eles são mapeados para processos de ambiente definidos `aws:elasticbeanstalk:environment:process` por meio do namespace e configurados via IIS nas instâncias. EC2   
A migração preserva as configurações essenciais do grupo de aplicações, incluindo as seguintes:  
+ Configurações do modelo de processo - Identidade (ApplicationPoolIdentity, NetworkService, ou contas personalizadas), configurações de tempo limite de inatividade e intervalos de reciclagem do processo
+ Configurações da versão do .NET CLR: mantém sua versão especificada do .NET Framework (v2.0, v4.0 ou Sem código gerenciado) para garantir a compatibilidade da aplicação
+ Modo de pipeline gerenciado: preserva as configurações do modo de pipeline integrado ou clássico para manter sua arquitetura de processamento de solicitações HTTP
+ Configurações avançadas: comprimento da fila, limites de CPU, limites de proteção contra falhas rápidas e limites de tempo de inicialização
O comando **eb migrate** preserva os mapeamentos entre sites e grupos de aplicações durante a migração para o ambiente do Elastic Beanstalk.  
Se seus pools de aplicativos usarem cronogramas de reciclagem personalizados (horários específicos ou limites de memória), eles serão implementados por meio de PowerShell scripts no pacote de implantação que definem as configurações apropriadas do IIS nas EC2 instâncias.

**Associações de sites**  
As associações de sites do IIS, que definem como os clientes acessam suas aplicações, são transformadas nas seguintes configurações do Application Load Balancer (ALB):  
+ As ligações de porta são mapeadas de acordo com as regras de receptores do ALB correspondentes
+ As configurações do cabeçalho do host são convertidas em regras de roteamento do ALB
+ Sites habilitados para SSL usam o AWS Certificate Manager (ACM) para gerenciamento de certificados

## Gerenciamento virtual de diretórios e caminhos de aplicações
<a name="dotnet-migrating-applications-mapping-virtual-dirs"></a>

Diretórios e aplicações virtuais do IIS fornecem mapeamento de caminhos de URL para diretórios físicos. O Elastic Beanstalk mantém esses relacionamentos por meio das seguintes construções:

**Diretórios virtuais**  
O processo de migração preserva os caminhos físicos dos seus diretórios virtuais no pacote de implantação.  
Os mapeamentos de caminho são configurados na configuração do IIS nas EC2 instâncias, garantindo que sua estrutura de URL permaneça intacta após a migração.

**Caminhos físicos que não são do sistema**  
Por padrão, os ambientes Windows do Elastic Beanstalk provisionam somente a unidade C:\$1 (volume raiz). Na versão atual, aplicações com conteúdo em unidades que não são do sistema (D:\$1, E:\$1 etc.) não têm suporte para migração.
O comando **eb migrate** detecta automaticamente caminhos físicos localizados em unidades que não são do sistema e avisa sobre possíveis problemas, como no exemplo a seguir:  

```
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:\.
```
Se a sua aplicação tiver dependências em unidades que não sejam do sistema, você precisará modificá-la para armazenar todo o conteúdo na unidade C:\$1 antes da migração.

**Aplicações aninhadas**  
Aplicações aninhadas em sites são implantadas com as configurações de caminho corretas e as atribuições apropriadas do grupo de aplicações. O processo de migração preserva todas as configurações de ` web.config`, garantindo que as configurações específicas da aplicação continuem funcionando conforme o esperado no ambiente de nuvem.

## Reescrita de URL e roteamento de solicitação de aplicação (ARR)
<a name="dotnet-migrating-applications-mapping-url-rewrite"></a>

Se sua implantação do IIS usa Regravação de URL ou Roteamento de Solicitações de Aplicações (ARR), **eb migrate** manipula essas configurações por meio das seguintes regras e configurações:

**Regras de reescrita de URL**  
As regras de reescrita de URL dos seus arquivos `web.config` são convertidas em regras de roteamento do ALB sempre que possível. Por exemplo, a entrada a seguir se torna uma regra de receptor do ALB que direciona o tráfego com base nos cabeçalhos do host e nos padrões de caminho. :  

```
<!-- 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>
```


**Roteamento de solicitações de aplicações**  
As configurações de ARR são preservadas por meio da instalação de recursos de ARR nas instâncias. EC2 O processo de migração conclui as seguintes tarefas:  
+ Define as configurações de proxy para corresponder ao seu ambiente de origem
+ Mantém as regras de regravação de URL associadas ao ARR

## Estrutura de artefatos de migração
<a name="dotnet-migrating-applications-mapping-artifacts"></a>

Quando você executa **eb migrate**, ele cria um diretório estruturado contendo todos os componentes de implantação necessários. A lista a seguir descreve a estrutura de diretórios:

```
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
```

O arquivo `aws-windows-deployment-manifest.json` é o arquivo de configuração principal que instrui o Elastic Beanstalk a implantar suas aplicações. Consulte a seguinte estrutura de exemplo:

```
{
    "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"
                    }
                }
            }
        ]
    }
}
```

Esse manifesto garante os seguintes resultados para sua migração:
+ As aplicações são implantadas para corrigir os caminhos do IIS
+ Configurações personalizadas são aplicadas
+ As configurações específicas do site são preservadas
+ A ordem de implantação é mantida

# Cenários avançados de migração
<a name="dotnet-migrating-applications-advanced-scenarios"></a>

Esta seção aborda cenários avançados de migração para implantações complexas do IIS.

## Migrações de vários sites com Roteamento de solicitações de aplicações (ARR)
<a name="dotnet-migrating-applications-advanced-scenarios-arr"></a>

O comando **eb migrate** detecta e preserva automaticamente as configurações do ARR durante a migração. Ao identificar as configurações de ARR em seu IIS`applicationHost.config`, ele gera os PowerShell scripts necessários para reinstalar e configurar o ARR nas instâncias de destino. EC2 

### Detecção de configuração do ARR
<a name="dotnet-migrating-applications-advanced-scenarios-arr-detection"></a>

O processo de migração examina três seções principais de configuração no IIS:
+ `system.webServer/proxy`: configurações principais do proxy do ARR
+ `system.webServer/rewrite`: regras de reescrita de URL
+ `system.webServer/caching`: configuração de cache

Por exemplo, considere uma configuração ARR comum em que um `RouterSite` em execução na porta 80 encaminha solicitações para `APIService` e `AdminPortal` em execução nas portas 8081 e 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>
```

O diagrama a seguir mostra como essas regras estão ocultas atrás da porta 80 no servidor IIS e não são expostas por meio dos grupos EC2 de segurança. Somente a porta 80 pode ser acessada pelo Application Load Balancer, e todo o tráfego dela é roteado para o grupo-alvo na porta 80.

![\[Arquitetura do Elastic Beanstalk com Roteamento de solicitações de aplicações (ARR)\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/architecture-diagram-with-arr.png)


O comando a seguir pode migrar essa configuração:

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

### O processo de migração ARR
<a name="dotnet-migrating-applications-advanced-scenarios-arr-process"></a>

O processo de migração preserva sua configuração do ARR por meio de várias etapas.

Exportação de configuração  
A ferramenta exporta suas configurações do ARR existentes das três seções principais de configuração para arquivos XML separados armazenados no diretório `ebmigrateScripts`:  

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

Scripts de instalação  
Dois PowerShell scripts são gerados para lidar com a configuração do ARR:  

1. `arr_msi_installer.ps1`: baixa e instala o módulo ARR

1. `arr_configuration_importer_script.ps1`: importa sua configuração do ARR exportada

Integração de manifesto de implantação  
Os scripts são integrados ao processo de implantação por meio de entradas em `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"
                    }
                }
            }
        ]
    }
}
```

### Integração do balanceador de carga
<a name="dotnet-migrating-applications-advanced-scenarios-arr-lb"></a>

O processo de migração traduz suas regras de ARR em regras de receptor do Application Load Balancer (ALB) sempre que possível. Por exemplo, a configuração de ARR acima resulta em regras de ALB que roteiam o tráfego com base nos padrões de caminho de URL, mantendo o roteamento interno nas instâncias. EC2 

O ambiente resultante mantém sua lógica de roteamento do ARR enquanto aproveita a infraestrutura elástica da AWS. Suas aplicações continuam funcionando como antes, com o ARR gerenciando o roteamento interno enquanto o Application Load Balancer gerencia a distribuição do tráfego externo.

## Migrações de vários sites sem ARR usando roteamento baseado em host
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr"></a>

Embora o Roteamento de solicitações de aplicações (ARR) seja uma abordagem comum para gerenciar vários sites no IIS, você também pode migrar implantações de vários sites diretamente para o Elastic Beanstalk sem ARR, aproveitando os recursos de roteamento baseado em host do Application Load Balancer. Essa abordagem pode reduzir a complexidade e melhorar a performance ao eliminar uma camada adicional de roteamento.

### Visão geral do roteamento baseado em host
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-overview"></a>

Nessa abordagem, cada site do IIS é exposto fora da EC2 instância, e o Application Load Balancer encaminha o tráfego diretamente para a porta apropriada com base no cabeçalho do host. Isso elimina a necessidade de ARR e, ao mesmo tempo, mantém a separação entre suas aplicações.

Considere uma configuração do IIS de vários sites com três sites, cada um com sua própria associação de nome 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>
```

Esses sites são expostos nas portas 8081, 8082 e 8083 por meio dos EC2 grupos de segurança. O Application Load Balancer encaminha até eles com base na configuração da regra do receptor do Balancador de carga.

![\[Arquitetura do Elastic Beanstalk sem Roteamento de solicitações de aplicações (ARR)\]](http://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/images/architecture-diagram-without-arr.png)


### Processo de migração
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-migration"></a>

Para migrar essa configuração para o Elastic Beanstalk sem usar o ARR, use o comando **eb migrate** no exemplo a seguir:

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

O processo de migração configura automaticamente o Application Load Balancer com regras de roteamento baseadas em host que direcionam o tráfego para o grupo-alvo apropriado com base no cabeçalho do host. Cada grupo-alvo encaminha o tráfego para a porta correspondente em suas EC2 instâncias:

1. Cabeçalho do host www.example.com → Grupo-alvo na porta 8081

1. Cabeçalho do host api.internal → Grupo-alvo na porta 8082

1. Cabeçalho do host reports.internal → Grupo-alvo na porta 8083

### Configuração de SSL/TLS
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-ssl"></a>

Para proteger seus aplicativos, SSL/TLS siga as seguintes etapas:

1. Solicite certificados para seus domínios por meio do AWS Certificate Manager(ACM).

1. Configure receptores HTTPS em seu Application Load Balancer usando esses certificados.

1. Atualize a configuração do seu ambiente para incluir receptores HTTPS com as seguintes opções de configuração.

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

Com essa configuração, o encerramento do SSL ocorre no balanceador de carga, e o tráfego é encaminhado para suas instâncias por HTTP. Isso simplifica o gerenciamento de certificados enquanto mantém conexões seguras com os clientes.

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

Grupos de segurança  
Configure grupos de segurança para permitir tráfego de entrada apenas nas portas usadas pelos sites do IIS (8081, 8082, 8083 neste exemplo) do grupo de segurança do Application Load Balancer.

Verificações de integridade  
Configure verificações de integridade para cada grupo-alvo para garantir que o tráfego seja roteado apenas para instâncias íntegras. Crie endpoints de verificação de integridade para cada aplicação se eles ainda não existirem.

Monitoramento   
Configure CloudWatch alarmes para monitorar a saúde e o desempenho de cada grupo-alvo separadamente. Isso permite a identificação de problemas específicos de aplicações individuais.

Escalabilidade  
Considere os requisitos de recursos de todas as aplicações ao configurar políticas de ajuste de escala automático. Se uma aplicação tiver necessidades de recursos significativamente diferentes, considere migrá-la para um ambiente separado.

## Gerenciamento de diretórios virtuais
<a name="dotnet-migrating-applications-advanced-scenarios-vdir"></a>

O comando **eb migrate** preserva as estruturas de diretórios virtuais ao migrar suas aplicações IIS para o Elastic Beanstalk.

### Configuração padrão de permissões
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-default"></a>

Ao migrar diretórios virtuais, **eb migrate** estabelece um conjunto básico de permissões concedendo acesso a: ReadAndExecute 
+ IIS\$1IUSRS
+ IUSR
+ Usuários autenticados

Por exemplo, considere uma estrutura de diretório virtual típica:

```
<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>
```

### Diretórios virtuais protegidos por senha
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-password"></a>

Quando **eb migrate** encontra diretórios virtuais protegidos por senha, ele emite avisos e requer intervenção manual. 

O exemplo de configuração a seguir causará a resposta de aviso que segue o exemplo.

```
<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 manter a proteção por senha, crie um script de implantação personalizado como o seguinte:

```
# 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
```

Adicione esse script à sua implantação incluindo-o no manifesto:

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

### Gerenciamento de permissões personalizado
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-custom"></a>

O comando **eb migrate** fornece uma estrutura para scripts de permissão personalizados para acomodar aplicações que exigem permissões diferentes das padrões. 



```
$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áticas recomendadas
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-best"></a>

Siga essas melhores práticas para planejar, executar, monitorar e verificar sua migração.

Planejamento pré-migração  
Documente as permissões e os requisitos de autenticação existentes antes da migração. Teste scripts de permissão personalizados em um ambiente de desenvolvimento antes de implantá-los na produção.

Gerenciamento de conteúdo compartilhado  
Para diretórios de conteúdo compartilhado, certifique-se de que todas as permissões necessárias do sistema de arquivos estejam configuradas adequadamente por meio de scripts personalizados. Considere usar o [Amazon FSx para Windows File Server](https://aws.amazon.com/fsx/windows/) para atender aos requisitos de armazenamento compartilhado.

Monitoramento e verificação  
Monitore os logs de aplicação após a migração para verificar o acesso adequado aos diretórios virtuais. Preste atenção especial às seguintes áreas:  
+ Acesso à identidade do grupo de aplicações
+ Permissões personalizadas da conta de serviço
+ Conectividade de compartilhamento de rede
+ Falhas de autenticação

## Configurações personalizadas do grupo de aplicações
<a name="dotnet-migrating-applications-advanced-scenarios-apppool"></a>

Por padrão, o comando **eb migrate** não copia as configurações personalizadas do grupo de aplicações. Para preservar as configurações personalizadas do grupo de aplicações, siga este procedimento para criar e aplicar uma seção de manifesto personalizada.

1. Crie um arquivo de seus artefatos de migração.

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

1. Crie um PowerShell script personalizado para configurar grupos de aplicativos.

   ```
   # 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. Atualize o arquivo `aws-windows-deployment-manifest.json` para incluir seu 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. Crie um ambiente com o diretório de arquivamento atualizado.

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

O argumento `--archive-dir` instrui o **eb migrate** a usar o código-fonte que ele criou anteriormente, evitando a criação de novos arquivos.

## Implantar versões anteriores
<a name="dotnet-migrating-applications-advanced-scenarios-previous"></a>

O mantém **eb migrate** um histórico das suas migrações por meio de diretórios com data e hora e versões de aplicações no Elastic Beanstalk. Cada migração cria um arquivo zip exclusivo que pode ser implantado se necessário.

```
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
```

O link simbólico `latest` sempre aponta para o diretório de artefatos de migração criado mais recentemente. Além dos logs relevantes de aplicações e erros, cada diretório de artefatos de migração também contém um arquivo `upload_target.zip` que você pode implantar no 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
```

Você pode implantar o arquivo `upload_target.zip` usando **eb migrate**:

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

# Solução de problemas e diagnóstico
<a name="dotnet-migrating-applications-troubleshooting"></a>

**Experimente a Amazon Q Developer CLI para solução de problemas assistida por IA**  
 A Amazon Q Developer CLI pode ajudar a solucionar problemas de ambiente rapidamente. A Q CLI fornece soluções verificando o status do ambiente, analisando eventos, analisando logs e fazendo perguntas esclarecedoras. Para obter mais informações e orientações detalhadas, consulte Solução de problemas de [ambientes do Elastic Beanstalk com o Amazon](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/) Q Developer CLI nos blogs. AWS 

Esta seção fornece orientação para solucionar problemas comuns que podem surgir durante a migração de aplicações IIS para o Elastic Beanstalk.

## Associando um EC2 par de chaves ao seu ambiente
<a name="dotnet-migrating-applications-troubleshooting-keypair"></a>

Você pode fazer login com segurança nas instâncias do Amazon Elastic Compute Cloud (Amazon EC2) provisionadas para seu aplicativo Elastic Beanstalk com um par de chaves da Amazon. EC2 Para obter instruções sobre como criar um par de chaves, consulte [Como criar um par de chaves usando a Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair) no *Guia EC2 do usuário da Amazon*.

Especificar um nome de chave para **eb migrate** tem o efeito de fazer seu ambiente Elastic Beanstalk estar associado ao par de chaves. Por motivos de segurança, isso não abrirá a porta 3389 no grupo de segurança de suas EC2 instâncias. Você pode associar grupos EC2 de segurança adicionais que permitam o tráfego na porta 3389 até **eb config** depois da migração inicial.

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

Quando você cria um par de chaves, a Amazon EC2 armazena uma cópia da sua chave pública. Se você não precisar mais usá-lo para se conectar a nenhuma instância do ambiente, poderá excluí-lo da Amazon EC2. Para obter detalhes, consulte [Excluindo seu par de chaves](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair) no *Guia do EC2 usuário da Amazon*.

Para obter mais informações sobre como se conectar às EC2 instâncias do Windows Amazon, consulte [Conectando-se à instância do Windows](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html).

## Acesso a logs
<a name="dotnet-migrating-applications-troubleshooting-logs"></a>

O EB CLI fornece um **eb logs** recurso que você pode usar para recuperar registros de um ambiente do Elastic Beanstalk sem fazer login em suas instâncias. EC2 Após a execução de **eb migrate**, você pode emitir o comando **eb logs --zip** que baixará e salvará os logs no diretório `.elasticbeanstalk\logs`.

Como alternativa, você pode visualizar os registros por meio do console do AWS Elastic Beanstalk. Para obter mais informações, consulte [Visualizar logs de instâncias do Amazon EC2 no ambiente do Elastic Beanstalk](using-features.logging.md).

## Acessar artefatos no lado do cliente
<a name="dotnet-migrating-applications-troubleshooting-artifacts"></a>

O comando **eb migrate** armazena registros de aplicações e erros gerados por **msdeploy** dentro de diretórios de artefatos de migração internos.

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

## Monitorar a integridade do ambiente
<a name="dotnet-migrating-applications-troubleshooting-health"></a>

O Elastic Beanstalk ajuda você a monitorar a integridade usando os recursos aprimorados de monitoramento da integridade. É um sistema automatizado de monitoramento de integridade que rastreia continuamente o status operacional de instâncias de aplicaçãos, aproveitando métricas integradas, como utilização da CPU, latência, contagem de solicitações e códigos de resposta.

O sistema de monitoramento de integridade utiliza uma abordagem baseada em agentes para coletar dados em nível de instância e se integra com logs e alertas em tempo real. O Elastic Load Balancing (ELB) e o Auto Scaling respondem dinamicamente às mudanças no status de integridade, garantindo alta disponibilidade e tolerância a falhas. Os modos avançados de monitoramento, incluindo relatórios de integridade aprimorados, fornecem visibilidade granular do comportamento da aplicação, permitindo a solução proativa de problemas e mecanismos de recuperação automática.

Execute o comando **eb health** da EB CLI para exibir a integridade do ambiente. A informação a seguir será exibida.
+ Status de integridade da instância
+ Métricas de resposta da aplicação
+ Utilização dos recursos do sistema
+ Eventos recentes de implantação

## EC2 otimização de desempenho
<a name="dotnet-migrating-applications-troubleshooting-performance"></a>

Por padrão, **eb migrate** seleciona o tipo de instância [c5.2xlarge](https://aws.amazon.com/ec2/instance-types/c5/) para fornecer uma ótima experiência inicial com o Elastic Beanstalk. É possível substituir esse comportamento pelo argumento **--instance-type**:

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

Em ambientes de produção, considere os seguintes fatores ao selecionar um tipo de instância:
+ Requisitos de memória das suas aplicações
+ Requisitos de CPU para processar workloads
+ Necessidades de performance da rede
+ Metas de otimização de custos

## Configuração de volumes do EBS
<a name="dotnet-migrating-applications-troubleshooting-ebs"></a>

Por padrão, o Elastic Beanstalk criará somente um volume de dispositivo de bloco raiz (`C:\`) para seu ambiente. Você pode transmitir volumes adicionais de snapshot do Amazon Elastic Block Store com a opção **--ebs-snapshots**:

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

Para ver exemplos de como configurar mapeamentos de dispositivos de blocos com o Elastic Beanstalk, consulte o artigo do blog [Personalizar volumes efêmeros e do EBS em ambientes do Elastic Beanstalk](https://aws.amazon.com/blogs/devops/customize-ephemeral-and-ebs-volumes-in-elastic-beanstalk-environments/).

Para aplicações com altos requisitos de armazenamento, considere as seguintes opções:
+ Usar volumes do EBS para dados persistentes
+ Implementar o Amazon S3 para conteúdo estático
+ Usando o Amazon FSx para Windows File Server para sistemas de arquivos compartilhados

## Problemas e soluções comuns de
<a name="dotnet-migrating-applications-troubleshooting-common"></a>

**Evento:** *Instalação ausente do Web Deploy*

Se você encontrar erros relacionados ao Web Deploy não ser encontrado, instale o Web Deploy 3.6 ou posterior a partir do [Microsoft Web Platform Installer](https://www.iis.net/downloads/microsoft/web-deploy). O exemplo a seguir exibe uma possível mensagem de erro.

```
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 permissão durante a migração*

Se você encontrar erros relacionados à permissão, verifique se está executando a EB CLI com privilégios administrativos. O exemplo a seguir exibe uma possível mensagem de erro.

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

**Evento:** *problemas de identidade do grupo de aplicações*

Se a aplicação falhar ao iniciar devido a problemas de identidade do grupo de aplicações, crie um script personalizado para configurar as identidades do grupo de aplicações, conforme mostrado em [Configurações personalizadas do grupo de aplicações](dotnet-migrating-applications-advanced-scenarios.md#dotnet-migrating-applications-advanced-scenarios-apppool).

**Evento:** *Erros de configuração do certificado SSL*

Se associações HTTPS não funcionarem, certifique-se de ter especificado um ARN de certificado do ACM válido utilizando o parâmetro `--ssl-certificates` da opção **eb mibrate**.

**Evento:** *Tempo limite para criação do ambiente*

Se a criação do ambiente expirar, verifique se há falhas específicas na criação de recursos nos CloudFormation eventos no AWS Management Console. As causas comuns incluem problemas de configuração da VPC ou limites de serviços.

## Obter suporte
<a name="dotnet-migrating-applications-troubleshooting-support"></a>

Se você encontrar problemas que não consegue resolver, antes de entrar em contato, AWS Support colete as seguintes informações:
+ ID do ambiente (`eb status`)
+ Registros do aplicativo (`eb logs --zip`)
+ Artefatos de migração de `.\migrations\latest\`
+ Configuração do IIS de origem (saída de `eb migrate explore --verbose`)
+ Mensagens de erro detalhadas

Para obter mais informações sobre solução de problemas com o Elastic Beanstalk, consulte [Solucionar problemas com o ambiente Elastic Beanstalk](troubleshooting.md).

# Comparando as opções de migração: EB CLI vs. AWS Application Migration Service
<a name="dotnet-migrating-applications-comparison"></a>

AWS oferece vários caminhos para migrar aplicativos do Windows para a nuvem. Esta seção compara duas opções principais: o **eb migrate** comando na CLI do EB AWS Application Migration Service e (MGN). Compreender as diferenças entre essas abordagens ajudará você a escolher a estratégia de migração mais adequada para as suas necessidades específicas.


**Comparação das opções de migração**  

| Recurso | EB CLI (**eb migrate**) | AWS Application Migration Service (MGN) | 
| --- | --- | --- | 
| Foco principal | Migração em nível de aplicação de sites e aplicações do IIS | Nova hospedagem em nível de servidor de máquinas inteiras (servidores físicos, virtuais ou em nuvem) | 
| Mais adequado para | Aplicações do IIS que você deseja migrar diretamente para o Elastic Beanstalk com o mínimo de reconfiguração | Migrações em grande escala envolvendo muitos servidores ou infraestrutura complexa | 
| Abordagem de descoberta | Detecção em nível de aplicação de sites, aplicações e configurações do IIS | Replicação em nível de servidor de máquinas inteiras, incluindo sistema operacional e aplicações | 
| Ambiente de destino | Cria e configura diretamente ambientes do Elastic Beanstalk otimizados para aplicações Windows | Cria EC2 instâncias que exigem configuração adicional para funcionar com o Elastic Beanstalk | 
| Preservação de configuração | Preserva automaticamente as configurações específicas do IIS (sites, grupos de aplicações, vinculações) | Preserva toda a configuração do servidor, que pode incluir componentes desnecessários | 
| Modelo de implantação. | Cria um ambiente limpo do Elastic Beanstalk com suas aplicações implantadas usando as melhores práticas do Elastic Beanstalk | Cria uma réplica do seu servidor de origem que pode exigir otimização para operações na nuvem | 
| Escala de migração | Ideal para migrações direcionadas de aplicações específicas | Projetado para migrações em grande escala de muitos servidores | 
| Etapas de pós-migração | Mínimo; o ambiente está pronto para uso com as ferramentas de gerenciamento do Elastic Beanstalk | Requer etapas adicionais para integração com o Elastic Beanstalk, como a execução de ações de pós-lançamento do SSM | 

## Quando usar cada opção de migração
<a name="dotnet-migrating-applications-comparison-when"></a>

**Escolha o **eb migrate** quando tiver os seguintes requisitos necessários:**  
+ Você deseja migrar aplicações IIS específicas em vez de servidores inteiros
+ Seu objetivo é adotar o Elastic Beanstalk como sua plataforma de gerenciamento de aplicações
+ Você quer aproveitar os recursos da plataforma gerenciada do Elastic Beanstalk, como fácil escalabilidade, implantação e monitoramento
+ Você prefere uma implantação limpa que siga as AWS melhores práticas para operações nativas em nuvem
+ Você deseja minimizar o trabalho de configuração pós-migração

**Escolha AWS Application Migration Service quando você tem os seguintes requisitos:**  
+ Você precisa migrar um grande número de servidores
+ Você tem configurações de servidor complexas que devem ser preservadas com exatidão
+ Suas aplicações têm problemas de compatibilidade que exigem a manutenção do ambiente exato do servidor
+ Você deseja “levantar e deslocar” com o mínimo de alterações nas suas aplicações
+ Você planeja refatorar ou otimizar suas aplicações após a migração

## Comparação de fluxos de trabalho de migração
<a name="dotnet-migrating-applications-comparison-workflow"></a>

**Fluxo de trabalho da EB CLI (**eb migrate**):**

1. Instale a EB CLI no seu servidor IIS de origem ou em um bastion host.

1. Execute **eb migrate** para descobrir aplicações do IIS.

1. O comando empacota suas aplicações e configurações.

1. Um ambiente do Elastic Beanstalk é criado com os recursos apropriados.

1. A implantação das suas aplicações ocorre no novo ambiente.

1. Você pode gerenciar imediatamente suas aplicações usando as ferramentas do Elastic Beanstalk.

**AWS Application Migration Service fluxo de trabalho:**

1. Instale o Agente AWS de Replicação nos servidores de origem.

1. Configure e teste a replicação de dados.

1. Inicie instâncias de teste para verificar a funcionalidade.

1. Agende a transição para. AWS

1. Inicie instâncias de produção.

1. Execute ações pós-lançamento para otimizar para a nuvem.

1. Se o Elastic Beanstalk for a plataforma de destino, será necessária uma configuração adicional para a integração com o Elastic Beanstalk.

## Conclusão
<a name="dotnet-migrating-applications-comparison-conclusion"></a>

O Elastic Beanstalk é o destino preferido para AWS aplicativos da plataforma Windows, oferecendo um ambiente gerenciado que simplifica a implantação, o dimensionamento e o gerenciamento. O comando **eb migrate** fornece um caminho direto para o Elastic Beanstalk para aplicações IIS, com descoberta e configuração automáticas que preservam as configurações da sua aplicação.

Embora AWS Application Migration Service ofereça recursos poderosos para migrações de servidores em grande escala, ele requer etapas adicionais para se integrar ao Elastic Beanstalk. Para a maioria das migrações de aplicações do IIS, nas quais o Elastic Beanstalk é a plataforma de destino, **eb migrate** oferece uma abordagem mais simplificada que se alinha ao modelo de serviço gerenciado do Elastic Beanstalk.

Escolha a abordagem de migração que melhor atenda às suas necessidades específicas, considerando fatores como escala, complexidade e a arquitetura de estado final desejada na AWS.

Para obter mais informações sobre AWS Application Migration Service, consulte [O que é AWS Application Migration Service?](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) no Guia do AWS Application Migration Service usuário.