

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 将 IIS 应用程序迁移到 Elastic Beanstalk
<a name="dotnet-migrating-applications"></a>

AWS Elastic Beanstalk 为在互联网信息服务 (IIS) 上运行的 Windows 应用程序提供了简化的迁移路径。相比云迁移，本章中描述的迁移功能通常可显著缩短时间和降低复杂性，帮助您在向 AWS迁移期间保持应用程序功能和配置的完整性。

****eb migrate** 操作**  
使用 Elastic Beanstalk 命令行界面（EB CLI）中的 **eb migrate** 命令自动发现、打包您的 IIS 应用程序并将其部署到 AWS 云。该过程会保持应用程序功能并保留您的配置，包括绑定、应用程序池和身份验证设置。

以下步骤概述了 `eb migrate` 操作将您的应用程序迁移到 AWS 云执行的过程：

1. 发现 IIS 站点及其配置。

1. 打包应用程序内容和配置。

1. 创建 Elastic Beanstalk 环境和应用程序。

1. 使用保留的设置部署应用程序。

**工作流程和位置执行选项**  
**eb migrate** 命令提供多种选项，方便实现灵活的迁移工作流程和执行位置。默认情况下，在目标服务器（其中包含要迁移到 Elastic Beanstalk 的应用程序）上运行该命令。如果您无法直接在应用程序服务器上运行命令，请使用 `remote` 选项在连接到目标服务器（其中包含您的应用程序和配置）的堡垒主机上运行命令。要分两步完成迁移，您也可以使用 `archive-only` 选项生成迁移程序包，但不进行部署，然后使用 `archive` 选项在稍后方便时进行部署。

有关 **eb migrate** 的更多信息，请参阅 [**eb migrate**](eb3-migrate.md)。

**主题**  
下列主题提供有关将 IIS 应用程序迁移到 Elastic Beanstalk 的详细信息：
+ [先决条件](dotnet-migrating-applications-prerequisites.md)：了解将 Windows 应用程序迁移到 AWS Elastic Beanstalk 环境所需的软件、访问权限和权限。
+ [迁移词汇表](dotnet-migrating-applications-glossary.md)：了解 IIS 组件如何映射到 Elastic Beanstalk 资源
+ [了解 IIS 到 Elastic Beanstalk 的迁移映射](dotnet-migrating-applications-mapping.md)：了解 IIS 组件如何映射到 Elastic Beanstalk 资源
+ [执行基本 IIS 迁移](dotnet-migrating-applications-basic-migration.md)：了解如何执行基本迁移
+ [高级迁移场景](dotnet-migrating-applications-advanced-scenarios.md)：处理复杂的迁移场景
+ [安全配置和 IAM 角色](dotnet-migrating-applications-security.md)：配置迁移期间的安全设置
+ [网络配置和端口设置](dotnet-migrating-applications-network.md)：管理网络和端口配置
+ [故障排除和诊断](dotnet-migrating-applications-troubleshooting.md)：对常见的迁移问题进行故障排除
+ [比较迁移选项：EB CLI vs. AWS Application Migration Service](dotnet-migrating-applications-comparison.md)：比较两个主要迁移选项的异同。

# 先决条件
<a name="dotnet-migrating-applications-prerequisites"></a>

使用 **eb migrate** 命令之前，请确保您的环境满足以下要求：

**IIS 安装和版本**  
要从中进行迁移的服务器必须运行 Internet Information Services（IIS）版本 7.0 或更高版本。Windows Server 2016 或更高版本上的 IIS 10.0 可为迁移提供最兼容的环境。  
要验证 IIS 版本，请运行以下命令：  

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

**Windows Server 要求**  
为了获得最佳兼容性，源环境应运行 Windows Server 2016 或更高版本。Elastic Beanstalk 支持将以下 Windows Server 版本作为目标平台：  
+ Windows Server 2025
+ Windows Server 2022
+ Windows Server 2019
+ Windows Server 2016

**EB CLI 安装**  
+ *默认工作流程（不使用 `--remote` 选项）*：
  + Python 和 Elastic Beanstalk 命令行界面（EB CLI）安装所在的服务器必须包含要迁移到 Elastic Beanstalk 的应用程序。虽然这不是必需的，但我们建议按[在虚拟环境中安装 EB CLI](eb-cli3.md#eb-cli3-install-virtualenv) 中所述，将 EB CLI 安装在 `virtualenv` 沙盒中。
+ *使用 `--remote` 选项*：
  + Python 和 Elastic Beanstalk 命令行界面（EB CLI）必须安装在堡垒主机上。虽然这不是必需的，但我们建议按[在虚拟环境中安装 EB CLI](eb-cli3.md#eb-cli3-install-virtualenv) 中所述，将 EB CLI 安装在 `virtualenv` 沙盒中。

**所需权限**  
您需要以下凭证和权限：  
+ 源 IIS 服务器或堡垒主机的管理员权限（如果使用 `--remote` 选项）。
+ AWS 有权创建和管理 Elastic Beanstalk 资源的证书

**Web 部署 3.6**  
Microsoft Web 部署工具（3.6 版或更高版本）必须安装在源服务器或堡垒主机上（如果使用 `--remote` 选项）。**eb migrate** 使用此工具打包应用程序。  
要验证的安装，请运行以下命令：  
:  

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

InstallPath  : C:\Program Files\IIS\Microsoft Web Deploy V3\
...
```
有关安装说明，请参阅 Microsoft Windows 产品文档网站上的 [Installing and Configuring Web Deploy on IIS 8.0 or Later](https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy-on-iis-80-or-later)。

**网络要求**  
+ *默认工作流程（不使用 `--remote` 选项）*：
  + 您的源服务器必须具有 AWS 服务的出站互联网访问权限。
+ *使用 `--remote` 选项*：
  + 您的源服务器必须具有 AWS 服务的出站互联网访问权限。
  + 配置适当的安全组入口规则，这些规则允许来自堡垒主机的传出网络连接以及与远程计算机的传入连接。确保通过端口 22 上的 TCP，将堡垒主机的 IP 列入允许名单，以便访问远程计算机。
  + 确保远程计算机和堡垒主机上已安装并运行 SSH 客户端。
  + 确保防火墙配置包含能够打开端口 22 或允许连接到客户端的相应规则。
  + 在尝试迁移之前，从堡垒主机手动 SSH 连接到远程主机，用于测试连接。

# 迁移词汇表
<a name="dotnet-migrating-applications-glossary"></a>

本词汇表提供了与 IIS、Elastic Beanstalk 以及将 IIS 应用程序迁移到 Elastic Beanstalk 相关的关键术语和概念的定义。

## Windows、IIS 和 .NET 术语
<a name="dotnet-migrating-applications-glossary-windows"></a>

****IIS****  
Internet Information Services，Microsoft 开发的用于与 Windows Server 搭配使用的 Web 服务器软件。IIS 托管网站、Web 应用程序和 Web 服务，提供用于运行 ASP.NET 和其他 Web 技术的平台。在迁移到 Elastic Beanstalk 期间，IIS 站点及其配置会被打包并部署到云中的 Windows 服务器实例。 AWS   
支持使用 IIS 7.0 及更高版本进行迁移，同时 Windows Server 2016 或更高版本上的 IIS 10.0 提供最兼容的环境。

****.NET 框架****  
Microsoft 开发的软件开发平台，用于构建和运行 Windows 应用程序。它提供了一个名为 Framework 类库（FCL）的大型类库，并支持多种编程语言之间的语言互操作性。  
迁移到 Elastic Beanstalk 时，基于 .NET 框架构建的应用程序将继续在云环境中的相同版本框架上运行。Elastic Beanstalk 在其 Windows Server 平台上支持多个 .NET Framework 版本（4.x）。

****.NET 内核****  
.NET Framework 的跨平台开源后继者，旨在更加模块化和轻量化。.NET Core（现简称 .NET 5 及更高版本）使开发人员能够构建在 Windows、Linux 和 macOS 上运行的应用程序。  
将基于 .NET Core 构建的应用程序迁移到 Elastic Beanstalk 时，您可以根据应用程序的要求和依赖关系，在 Windows Server 平台或基于 Linux 的平台之间进行选择。

****公共语言运行时（CLR）****  
.NET Framework 的虚拟机组件，用于管理 .NET 程序的执行。CLR 提供诸如内存管理、类型安全、异常处理、垃圾回收和线程管理等服务。  
迁移到 Elastic Beanstalk 时，相应的 CLR 版本将在您选择的 Windows Server 平台上自动可用，从而确保与应用程序要求兼容。

****站点****  
IIS 中的逻辑容器，表示 Web 应用程序或服务，由 IP 地址、端口和主机标头的唯一绑定进行标识。每个 IIS 站点都有自己的应用程序池、绑定和配置设置，并且可包含一个或多个应用程序。

****应用程序****  
IIS 站点内的一组内容和代码文件，用于处理对特定 URL 空间的请求。IIS 中的应用程序可以有自己的配置设置，这些设置通常存储在 `web.config` 文件中。  
迁移到 Elastic Beanstalk 时，应用程序会保留其路径结构和配置设置。迁移过程可确保嵌套应用程序在云环境中保持其层次结构和 URL 路径。

****ApplicationPool****  
一项 IIS 功能，可隔离 Web 应用程序，以提升安全性、可靠性并改进性能管理。应用程序池定义应用程序的运行时环境，包括 .NET Framework 版本、管道模式和身份设置。

****VirtualDirectory****  
IIS 中的目录映射，可允许从站点根目录之外的位置提供内容。虚拟目录能让您跨不同的物理位置组织内容，同时向用户提供统一的 URL 结构。  
迁移到 Elastic Beanstalk 时，虚拟目录及其路径映射都会保留。**eb migrate** 命令会在云环境中创建必要的目录结构和配置，以保持相同的 URL 路径。

****ARR****  
应用程序请求路由，这是一种 IIS 扩展，可为 Web 服务器提供负载均衡和代理功能。ARR 支持基于 URL 的路由、HTTP 请求转发和跨多个服务器的负载分配。  
在迁移到 Elastic Beanstalk 期间，系统会在 EC2 实例上安装 ARR 功能并配置适当的路由规则，从而保留 ARR 配置。对于复杂的路由方案，迁移过程也可以利用应用程序负载均衡器规则来实现类似的功能。

****URL 重写****  
一个 IIS 模块，可在请求到达 Web 应用程序之前 URLs 根据定义的规则对其进行修改。URL 重写支持基于模式和条件的 URL 操作、重定向和内容分发。  
迁移到 Elastic Beanstalk 时，`web.config` 文件中的 URL 重写规则会尽可能转换为 ALB 路由规则，或者保留在 EC2 实例上的 IIS 配置中。这可确保 URL 模式和重定向在云环境中继续按预期运行。

****msdeploy.exe****  
用于将 Web 应用程序和网站部署到 IIS 服务器的命令行工具。它也称为 Web Deploy，可提供打包、同步和部署 Web 应用程序、网站和服务器配置的方法。  
在迁移到 Elastic Beanstalk 期间，**eb migrate** 命令使用 Web 部署（3.6 或更高版本）来打包应用程序。此工具必须安装在源服务器上，迁移过程才能正常运行。

****物理路径****  
存储 IIS 站点或应用程序内容文件的实际文件系统位置。物理路径可以指向 IIS 服务器可以访问的本地目录、网络共享或其他存储位置。  
在迁移到 Elastic Beanstalk 期间，物理路径会映射到您环境中 EC2 实例上的相应位置。迁移过程会保留内容结构，同时确保所有文件都正确部署到云环境中。

****applicationHost.config****  
IIS 的根配置文件，用于定义服务器范围的设置，并包含所有站点、应用程序和虚拟目录的配置。此文件位于 `%windir%\System32\inetsrv\config` 目录中，并且可控制 IIS 服务器的整体行为。  
迁移到 Elastic Beanstalk 时，系统会从 `applicationHost.config` 中提取相关设置并将其应用于您环境中 EC2 实例上的 IIS 配置。这样可以确保在迁移期间保留服务器范围的设置。

****web.config****  
ASP.NET 应用程序中使用的基于 XML 的配置文件，用于控制应用程序级或目录级的应用程序设置、安全性和行为。`web.config` 文件可以包含用于身份验证、授权、会话状态、编译和自定义应用程序参数的设置。  
在迁移到 Elastic Beanstalk 期间，`web.config` 文件会得以保留并与应用程序一起部署。迁移过程可确保特定于应用程序的配置在云环境中继续按预期运行。

****DefaultDocument****  
一项 IIS 功能，当用户在不指定文件名的情况下请求目录时，该功能会指定要提供的默认文件。默认情况下，默认文档处于启用状态，IIS 7 会将 `applicationHost.config` 文件中的以下默认文档文件定义为服务器范围的默认文档：Default.htm、Default.asp、Index.htm、Index.html、Iisstart.htm。  
迁移到 Elastic Beanstalk 时，默认文档设置将保留在 EC2 实例的 IIS 配置中，从而确保在云环境中以一致的方式处理目录请求。

****system.webServer****  
`web.config` 或 `applicationHost.config` 中的配置部分，其中包含各个模块、处理程序和其他服务器行为的 IIS 特定设置。此部分控制 IIS 如何处理请求、管理模块和配置服务器功能。  
在迁移到 Elastic Beanstalk 期间，system.webServer 的配置将保留在应用程序的 `web.config` 文件中，并应用于环境中 EC2 实例上的 IIS 安装。这可确保在云环境中维持特定于 IIS 的行为。

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

****平台****  
操作系统、编程语言运行时、Web 服务器、应用程序服务器和 Elastic Beanstalk 组件的组合，用于定义应用程序运行所用的软件堆栈。  
对于 Windows 迁移，Elastic Beanstalk 提供基于 Windows Server 2016、2019 和 2022 的平台，包括 IIS 和各种 .NET Framework 版本，以确保与您的源环境兼容。

****SolutionStack****  
Elastic Beanstalk 中的预定义平台配置，用于指定应用程序运行所需的操作系统、运行时和其他组件。在概念上与平台相同，可以互换使用来操作环境。  
在迁移过程中，**eb migrate** 命令会根据源环境的配置选择适当的解决方案堆栈，从而确保与 IIS 应用程序的兼容性。

****CreateEnvironment****  
一种 Elastic Beanstalk API 操作，用于创建用来托管应用程序版本的新环境。**eb migrate** 命令使用此 API 为已迁移的应用程序配置必要的 AWS 资源。  
迁移过程会根据源 IIS 环境配置相应的环境参数，包括实例类型、环境变量和选项设置。

****CreateApplicationVersion****  
一种 Elastic Beanstalk API 操作，用于根据存储在 Amazon S3 中的源包创建新的应用程序版本。**eb migrate** 命令使用此 API 将已打包的 IIS 应用程序注册为 Elastic Beanstalk 中的一个版本。  
迁移期间，应用程序文件和配置会经过打包并上传到 Amazon S3，并在部署前注册为应用程序版本。

****DescribeEvents****  
一种 Elastic Beanstalk API 操作，用于检索环境的事件列表，包括部署、配置更改和操作问题。**eb migrate** 命令使用此 API 监控迁移进度。  
您还可以在迁移后使用 **eb events** 命令来查看环境事件历史记录。

****DescribeEnvironmentHealth****  
一种 Elastic Beanstalk API 操作，用于提供有关实例和环境其他组件的详细运行状况信息。此 API 用于在部署后验证迁移的应用程序的运行状况。  
迁移后，您可以使用 **eb health** 命令检查环境的状态并确定需要注意的任何问题。

****HealthD****  
Elastic Beanstalk 中的一种监控代理，用于收集环境中 EC2 实例的指标、监控日志并报告运行状况。HealthD 为迁移应用程序提供增强型运行状况报告。  
迁移后，HealthD 会监控应用程序的性能、资源利用率和请求成功率，从而帮助您全面了解环境运行状况。

****捆绑日志****  
Elastic Beanstalk 中的一项功能，用于从 EC2 实例压缩日志并将其上传到 Amazon S3 以进行集中存储和分析。此功能可帮助您对与迁移应用程序相关的问题进行故障排除。  
迁移后，您可以使用 **eb logs** 命令从环境中检索和查看日志。

****aws-windows-deployment-manifest.json****  
一种文件，用于描述软件包或应用程序的内容、依赖关系和配置。此清单将在迁移过程中生成，用于定义应如何在 Elastic Beanstalk 上部署您的 IIS 应用程序。

****自定义清单部分****  
`aws-windows-deployment-manifest.json` 中的部分，用于提供对应用程序部署的自定义控制。本节包含在部署过程中执行的 PowerShell脚本和命令。  
在迁移过程中，系统会生成自定义清单部分来处理 IIS 配置的特定方面，例如虚拟目录设置、权限管理和应用程序池配置。

****EB CLI****  
一种命令行工具，其提供用于创建、配置和管理 Elastic Beanstalk 应用程序和环境的命令。EB CLI 包含专门用于将 IIS 应用程序迁移到 Elastic Beanstalk 的 **eb migrate** 命令。  
迁移后，您可以继续使用 EB CLI 管理环境、部署更新、监控运行状况和执行其他管理任务。

****选项设置****  
用于定义 Elastic Beanstalk 如何在您的环境中配置 AWS 和配置资源的配置值。选项设置按命名空间进行组织，这些命名空间代表环境的不同组件，例如负载均衡器、实例和环境进程。  
在迁移过程中，**eb migrate** 命令会根据您的 IIS 配置生成相应的选项设置，以确保云环境与源环境的功能相匹配。有关更多信息，请参阅《Elastic Beanstalk 开发人员指南》中的[配置选项](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html)。

****aws: elbv2: listener: default****  
应用程序负载均衡器上默认侦听器的 Elastic Beanstalk 配置命名空间。在迁移过程中，此命名空间将根据您的 IIS 站点绑定进行配置，以确保正确的流量路由。  
默认侦听器通常处理端口 80 上的 HTTP 流量，然后这些流量会根据路由规则转发到您的应用程序实例。

****aws: elbv2: listener: listener\$1port****  
应用程序负载均衡器上特定侦听器端口的 Elastic Beanstalk 配置命名空间。此命名空间可用于为迁移的应用程序配置其他侦听器，例如端口 443 上的 HTTPS。  
在迁移过程中，系统将基于 IIS 站点的端口绑定创建侦听器，从而确保您的应用程序在与源环境相同的端口上仍可访问。

****aws: elbv2: listenerRule: rule\$1name****  
用于为应用程序负载均衡器侦听器定义路由规则的 Elastic Beanstalk 配置命名空间。这些规则决定如何根据路径模式或主机标头，将传入的请求路由到不同的目标组。  
在迁移过程中，系统将创建侦听器规则以匹配 IIS 应用程序的 URL 结构，从而确保将请求路由到正确的应用程序路径。

****aws: elasticbeanstalk: 环境:进程:默认****  
环境中默认进程的 Elastic Beanstalk 配置命名空间。此命名空间定义了默认 Web 应用程序进程的配置方式，包括运行状况检查设置、端口映射和代理设置。  
在迁移过程中，系统将根据主 IIS 站点的设置配置默认进程，从而确保适当的运行状况监控和请求处理。

****aws: elasticbeanstalk: 环境:进程:process\$1name****  
环境中具有特定名称的进程的 Elastic Beanstalk 配置命名空间。此命名空间允许您定义具有不同配置的多个进程，相当于在 IIS 中拥有多个应用程序池。  
在迁移过程中，系统可能会创建其他进程来表示与源环境不同的站点绑定。

**注意**  
有关本主题所述某些术语的更多信息，请参阅以下资源：  
Elastic Beanstalk API 操作：《[AWS Elastic Beanstalk API 参考](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/)》
Elastic Beanstalk 平台，包括支持的平台版本：《AWS Elastic Beanstalk 平台》**指南中的[支持的平台](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html)
Elastic Beanstalk 配置命名空间：本指南中的[面向所有环境的常规选项](command-options-general.md)
EB CLI 或特定 EB CLI 命令：本指南中的[设置 EB 命令行界面（EB CLI）来管理 Elastic Beanstalk](eb-cli3.md)

## Python 术语
<a name="dotnet-migrating-applications-glossary-python"></a>

****pip****  
Python 的软件包安装程序，用于安装和管理用 Python 编写的软件包。EB CLI 使用 pip 安装和更新。  
在迁移过程中，pip 用于在源服务器上安装 EB CLI 包及其依赖关系，从而提供迁移所需的工具。

****PyPI****  
Python 包索引，第三方 Python 软件包的官方存储库，pip 从中检索和安装软件包。EB CLI 及其依赖项托管在 PyPI 上。  
安装用于迁移的 EB CLI 时，pip 会连接到 PyPI 以下载和安装必要的软件包。

****virtualenv****  
一种用于创建隔离 Python 环境的工具，这能让不同的项目在不冲突的情况下拥有自己的依赖关系和软件包。建议在安装 EB CLI 时使用 virtualenv，以免与其他 Python 应用程序发生冲突。  
在安装 EB CLI 之前创建虚拟环境可确保为迁移工具提供干净的隔离环境，并具有正确的依赖关系。

****pywin32****  
一组 Python 扩展，提供对许多 Windows 的访问权限 APIs，从而实现与 Windows 操作系统及其组件的交互。在迁移期间，EB CLI 使用 pywin32 与 Windows 特定的功能进行交互。  
在迁移过程中，系统使用 pywin32 访问正确打包和迁移应用程序所需的 IIS 配置、Windows 注册表设置及其他系统信息。

****pythonnet****  
一个软件包，用于实现 Python 代码与 .NET 框架和 .NET Core 应用程序的交互。这种集成能在迁移过程中实现 EB CLI 与 .NET 组件的搭配使用。  
在分析和打包应用程序以部署到 Elastic Beanstalk 时，迁移过程可能会使用 pythonnet 以与 .NET 程序集和组件进行交互。

# 执行基本 IIS 迁移
<a name="dotnet-migrating-applications-basic-migration"></a>

本节将指导您如何使用 **eb migrate** 命令将 IIS 应用程序迁移到 Elastic Beanstalk。

## 浏览 IIS 环境
<a name="dotnet-migrating-applications-basic-migration-exploring"></a>

在进行任何更改之前，您需要了解服务器上存在哪些资源。先通过运行 **eb migrate explore** 来浏览您的 IIS 站点，如以下示例所示：

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

此命令会显示您的 IIS 站点。请参阅以下列表：

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

要详细查看每个站点的配置（包括绑定、应用程序和虚拟目录），请添加 `--verbose` 选项，如以下示例所示：

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

以下列表显示了该命令提供的与环境有关的全面信息：

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

### 了解发现输出
<a name="dotnet-migrating-applications-basic-migration-exploring-output"></a>

详细输出为迁移规划提供以下关键信息：

站点  
发现输出列出了服务器上的所有 IIS 站点。每个网站都由其名称（例如“Default Web Site”、“Intranet”、“API.Internal”）进行标识，并按顺序编号。当服务器上存在多个站点时，`eb migrate` 命令可以根据您的迁移策略，单独或一起打包和部署每个站点。

绑定  
协议绑定显示您的网站使用哪些协议（HTTP/HTTPS）以及它们在哪些端口上运行。绑定信息包括主机标头要求，其用于定义基于域的路由配置。

应用程序  
应用程序路径显示 IIS 配置中的根和嵌套应用程序结构。应用程序池分配表明应用程序如何相互隔离，以确保安全性并便于资源管理。

虚拟目录  
物理路径映射表明您的内容在文件系统上的位置。身份验证设置显示迁移后需要维护的特殊访问要求。

## 准备迁移
<a name="dotnet-migrating-applications-basic-migration-preparing"></a>

了解环境后，请确保您的服务器满足先决条件。首先，使用以下 PowerShell 命令验证您的 IIS 版本：

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

需要 IIS 7.0 或更高版本。迁移工具使用 Web 部署 3.6 来打包应用程序。使用以下命令验证是否已安装：



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

如果您的服务器上未安装 Web 部署，可以从 [Microsoft Web 平台安装程序](https://www.iis.net/downloads/microsoft/web-deploy)下载页面进行下载。

## 首次迁移
<a name="dotnet-migrating-applications-basic-migration-first"></a>

我们从 Default Web Site 的基本迁移开始。以下示例显示了最简单的命令：**eb migrate**。

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

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

迁移工具会创建一个包含部署构件的结构化目录。下方列表显示了目录结构：

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

## 控制迁移
<a name="dotnet-migrating-applications-basic-migration-controlling"></a>

为了更好地控制迁移过程，您可以使用以下命令准确指定要迁移的站点：

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

您还可以自定义环境名称和应用程序名称，如以下示例命令所示：

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

有关选项的完整列表，请参阅 [**eb migrate**](eb3-migrate.md)。

## 监控进度
<a name="dotnet-migrating-applications-basic-migration-monitoring"></a>

在迁移期间，**eb migrate** 可提供实时状态更新。请参阅以下输出示例：

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

## 验证迁移
<a name="dotnet-migrating-applications-basic-migration-verifying"></a>

环境准备就绪后，Elastic Beanstalk 将提供多种方法来验证部署。

访问应用程序  
在 Web 浏览器中打开应用程序 URL（CNAME），验证其是否正常运行。

检查环境运行状况  
使用 **eb health** 命令查看环境的运行状况。  

```
PS C:\migrations_workspace> eb health
```
以下屏幕图像显示了实例运行状况、应用程序响应指标和系统资源利用率。  

![\[eb 运行状况命令的输出显示了实例运行状况、应用程序响应指标和系统资源利用率。\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/images/eb-health-after-migration.png)


使用 **eb logs** 命令访问日志，从而对所有问题进行故障排除：  

```
PS C:\migrations_workspace> eb logs --zip
```
**eb logs** 命令可将日志下载到 `.elasticbeanstalk/logs` 目录中。有关更多信息，请参阅 [将 Elastic Bean CloudWatch stalk 与亚马逊日志一起使用](AWSHowTo.cloudwatchlogs.md)。

连接到实例  
如果您在迁移期间指定了密钥对，则可以使用 RDP 连接到实例进行直接故障排除。

访问 Elastic Beanstalk 控制台  
您可以通过该环境的[环境管理控制台](environments-console.md)来查看其运行状况、日志和配置属性。

## 管理迁移构件
<a name="dotnet-migrating-applications-basic-migration-cleanup"></a>

**eb migrate** 命令可在迁移过程中创建本地构件。这些构件包含敏感信息，并且随着时间的推移，可能会占用大量磁盘空间。使用 **cleanup** 子命令管理这些构件，如以下示例所示：

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

要在不确认的情况下强制清理，请使用 **--force** 选项：

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

清理过程会将最近成功的迁移保留在 `./migrations/latest` 目录中，并删除较旧的迁移目录

# 网络配置和端口设置
<a name="dotnet-migrating-applications-network"></a>

本节介绍 IIS 迁移的网络配置选项，包括 VPC 设置、端口配置和多站点部署。

## VPC 配置
<a name="dotnet-migrating-applications-network-vpc"></a>

**eb migrate** 命令可为 Elastic Beanstalk 环境提供灵活的 VPC 配置选项。该工具既可以检测来自源 EC2 实例的 VPC 设置，也可以通过命令行参数接受自定义 VPC 配置。查看[将 Elastic Beanstalk 和 Amazon VPC 结合使用](vpc.md)，了解如何使用 VPC 配置 Elastic Beanstalk。

### 自动 VPC 检测
<a name="dotnet-migrating-applications-network-vpc-auto"></a>

在 EC2 实例上运行 **eb migrate** 时，该命令会自动发现并使用源环境 EC2 实例中的 VPC 配置。以下示例输出说明了检测到的配置信息：

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

检测到的配置包括：
+ VPC 标识符
+ 公有 IP 分配设置
+ 负载均衡器方案（公共/私有）
+ EC2 实例子网分配
+ 安全组关联
+ 负载均衡器子网分配

### 本地或非AWS 云主机
<a name="dotnet-migrating-applications-network-vpc-onprem"></a>

在本地服务器或非AWS 云主机上**eb migrate**运行时，Elastic Beanstalk 服务将使用您账户中的默认 VPC。 AWS 下方列表显示了命令和输出的示例：

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

查看[将 Elastic Beanstalk 和 Amazon VPC 结合使用](vpc.md)，了解 Elastic Beanstalk 如何为环境配置默认 VPC。

### 自定义 VPC 配置
<a name="dotnet-migrating-applications-network-vpc-custom"></a>

对于需要特定 VPC 设置的任何源环境（EC2、本地环境或非AWS 云环境），请提供与以下示例类似的 VPC 配置文件：

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

使用下面的命令应用此配置：

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

**注意**  
VPC 配置文件需要用于指定 VPC ID 的 `id` 字段。所有其他字段均为可选字段，如有任何未指定的字段，Elastic Beanstalk 将使用默认值。

**重要**  
*当您指定* `--vpc-config` *参数时，迁移将忽略源环境中的任何现有 VPC 设置。*使用此参数时，迁移将仅使用您传入的配置文件中指定的 VPC 设置。使用此参数会覆盖发现源实例 VPC 配置或使用默认 VPC 的默认行为。

在以下场景中使用 `--vpc-config` 参数：
+ 迁移没有可发现的 VPC 设置的非 EC2 环境时
+ 迁移到与源环境所使用的 VPC 不同的 VPC 时
+ 需要自定义子网选择或安全组配置时
+ 自动发现无法正确识别所需的 VPC 设置时
+ 从本地迁移，并且不想使用默认 VPC 时

### 安全网络配置
<a name="dotnet-migrating-applications-network-vpc-security"></a>

默认情况下，**eb migrate** 会在目标实例上打开端口 80，但不会从源计算机复制其他 Windows 防火墙规则。要包含所有防火墙配置，请使用以下命令：

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

此命令执行以下操作：
+ 识别 IIS 站点绑定使用的端口
+ 检索相应的防火墙规则
+ 生成 PowerShell 脚本以在目标实例上重新创建规则
+ 保留源计算机端口 80 的所有 DENY 规则（否则，默认情况下会允许端口 80）

假设在使用案例中，源计算机具有以下示例中指定的防火墙规则：

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

迁移会创建包含以下配置的脚本 (`modify_firewall_config.ps1`)：

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

迁移工具会自动执行以下操作：
+ 从所有 IIS 站点绑定中提取 HTTP/HTTPS 端口
+ 使用 Windows 防火墙 [INetFwPolicy2](https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwpolicy2) 接口枚举防火墙规则
+ 筛选规则，以便仅包括明确引用指定端口的规则
+ 仅处理 HTTP 和 HTTPS 站点绑定及其关联的防火墙规则
+ 保留规则属性，包括显示名称、操作、协议和已启用状态
+ 同时处理防火墙规则中的单个端口和端口范围
+ 将防火墙配置脚本添加到部署清单

### 负载均衡器配置
<a name="dotnet-migrating-applications-network-vpc-lb"></a>

您可以通过 `--vpc-config` 参数指定负载均衡器配置。以下示例对参数进行了演示。

方案选择  
在公有负载均衡器和私有负载均衡器方案之间进行选择：  

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

子网分布  
为了实现高可用性，请将负载均衡器子网跨可用区分布：  

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

**注意**  
虽然 Elastic Beanstalk 支持使用应用程序负载均衡器、网络负载均衡器和经典负载均衡器创建环境，但 **eb migrate** 命令仅支持应用程序负载均衡器。有关负载均衡器类型的更多信息，请参阅 [Elastic Beanstalk 环境的负载均衡器](using-features.managing.elb.md)。

## 使用端口配置进行多站点部署
<a name="dotnet-migrating-applications-network-multi"></a>

**eb migrate** 命令可处理复杂的多站点 IIS 部署，在这些部署中，应用程序可能共享依赖关系或使用非标准端口。考虑以下示例，其中的典型企业设置具有多个站点：

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

要迁移此配置，请使用以下示例命令和参数：

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

**eb migrate** 命令会创建部署包，用于保留每个站点的身份和配置。该命令会生成 `aws-windows-deployment-manifest.json`，用于定义应如何部署这些站点。以下示例展示了生成的 json 文件：

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

迁移过程会创建以下应用程序负载均衡器侦听器规则，其中保留了原始路由逻辑：
+ 端口 80 流量路由到 Default Web Site
+ 端口 8081 流量路由到 InternalAPI
+ 8082 端口的交通路线 ReportingPortal

## 共享配置和依赖关系
<a name="dotnet-migrating-applications-network-shared"></a>

多个站点共享配置或依赖关系时，**eb migrate** 会适当地处理这些关系。参考以下示例，其中多个站点共享一个通用配置：

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

迁移过程会完成以下任务：

1. 识别跨站点的共享配置

1. 生成相应的 PowerShell 脚本来应用这些设置

1. 维护配置层次结构和继承

## 最佳实践
<a name="dotnet-migrating-applications-network-best"></a>

我们建议您遵循迁移应用程序网络配置的最佳实践。以下分组提供了摘要指南。

VPC 设计  
+ 遵循 AWS VPC 设计最佳实践
+ 为负载均衡器和 EC2 实例使用单独的子网
+ 实施正确的路由表和 NACLs
+ 考虑使用 AWS 服务的 VPC 终端节点

高可用性  
+ 跨多个可用区进行部署
+ 针对负载均衡器使用至少两个子网
+ 跨配置自动缩放 AZs
+ 实施适当的运行状况检查

安全性  
+ 遵守安全最佳实践
+ 使用安全组作为主访问控制
+ 实施网络访问控制列表 (ACLs) 以提高安全性
+ 监控 VPC 流日志

## 问题排查
<a name="dotnet-migrating-applications-network-troubleshooting"></a>

常见的网络配置问题包括以下方面。每个主题后面均提供了示例命令，可用于获取有关环境网络配置和运行状况的更多信息。

子网配置  

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

安全组访问  

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

负载均衡器运行状况  

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

# 安全配置和 IAM 角色
<a name="dotnet-migrating-applications-security"></a>

该**eb migrate**命令通过 IAM 角色、实例配置文件和服务角色管理 AWS 安全配置。了解这些组件可确保在迁移期间实现适当的访问控制和安全合规。

## 实例配置文件配置
<a name="dotnet-migrating-applications-security-instance"></a>

实例配置文件用作 IAM 角色（即 Elastic Beanstalk 附加到您环境中 EC2 实例的角色）的容器。执行 **eb migrate** 时，您可以指定自定义实例配置文件：

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

如果不指定实例配置文件，**eb migrate** 会使用以下权限创建默认配置文件：

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

****  

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

------

## 服务角色管理
<a name="dotnet-migrating-applications-security-service"></a>

服务角色允许 Elastic Beanstalk 代表你管理资源 AWS 。使用以下命令指定迁移期间的自定义服务角色：

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

如果不指定，**eb migrate** 会创建名为 `aws-elasticbeanstalk-service-role` 的默认服务角色，而且该服务角色具有允许 Elastic Beanstalk 担任服务角色的信任策略。要让 Elastic Beanstalk 监控环境运行状况和执行托管平台更新，此服务角色必不可少。该服务角色需要两个受管策略：
+ `AWSElasticBeanstalkEnhancedHealth`：允许 Elastic Beanstalk 使用增强型运行状况报告系统监控实例和环境运行状况
+ `AWSElasticBeanstalkManagedUpdates`：允许 Elastic Beanstalk 执行托管平台更新，包括在有新平台版本可用时更新环境资源

使用这些策略，服务角色有权执行以下操作：
+ 创建并管理自动扩缩组
+ 创建并管理应用程序负载均衡器
+ 将日志上传到亚马逊 CloudWatch
+ 管理 EC2 实例

有关服务角色的更多信息，请参阅《Elastic Beanstalk 开发人员指南》中的 [Elastic Beanstalk 服务角色](concepts-roles-service.md)。

## 安全组配置
<a name="dotnet-migrating-applications-security-sg"></a>

**eb migrate** 命令会根据您的 IIS 站点绑定情况自动配置安全组。例如，如果您的源环境中有使用端口 80、443 和 8081 的站点，则配置结果如下：

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

迁移过程会完成以下操作：
+ 创建负载均衡器安全组，允许端口 80 和 443 上来自互联网（0.0.0.0/0）的入站流量
+ 创建 EC2 安全组，允许来自负载均衡器的流量
+ 配置其他端口，例如 8081（如果 `--copy-firewall-config` 已指定）

默认情况下，应用程序负载均衡器会配置为可通过互联网进行公共访问。如果您需要自定义此行为，例如限制对特定 IP 范围的访问或使用私有负载均衡器，则可以使用 `--vpc-config` 参数覆盖默认 VPC 和安全组配置：

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

例如，下列 `vpc-config.json` 配置会在私有子网中创建私有负载均衡器：

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

有关 VPC 配置选项的更多信息，请参阅 [VPC 配置](dotnet-migrating-applications-network.md#dotnet-migrating-applications-network-vpc)。

## SSL 证书集成
<a name="dotnet-migrating-applications-security-ssl"></a>

迁移具有 HTTPS 绑定的网站时，请通过 AWS Certificate Manager (ACM) 集成 SSL 证书：

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

此配置会完成以下操作：
+ 将证书与应用程序负载均衡器进行关联
+ 在负载均衡器上维持 HTTPS 终止
+ 保留负载均衡器与 EC2 实例之间的内部 HTTP 通信

## Windows 身份验证
<a name="dotnet-migrating-applications-security-windows"></a>

对于使用 Windows 身份验证的应用程序，**eb migrate** 会按如下方式保留应用程序 `web.config` 中的身份验证设置：

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

**重要**  
**eb migrate** 命令不会将用户配置文件或账户从您的源环境复制到目标 Elastic Beanstalk 实例。迁移后，您在源服务器上创建的所有自定义用户账户或组均需要在目标环境中重新创建。

默认情况下，目标 Windows 服务器实例中会包含内置 Windows 账户（例如 `IIS_IUSRS`）和组（例如 `IUSR`）以及所有其他内置账户和组。有关内置 IIS 账户和组的更多信息，请参阅 Microsoft 文档中的[了解 IIS 7 中的内置用户和组帐户](https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis)。

如果您的应用程序依赖自定义 Windows 用户账户或 Active Directory 集成，则需要在迁移完成后单独配置这些方面。

## 最佳实践和故障排除
<a name="dotnet-migrating-applications-security-best"></a>

### 角色管理
<a name="dotnet-migrating-applications-security-best-role"></a>

在管理您的 Elastic Beanstalk 环境的角色时实施 AWS IAM 最佳实践：

角色创建和管理  
+ 尽可能使用 AWS 托管策略创建角色
+ 遵循 [IAM 安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ 使用 [AWS 策略生成器](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)生成自定义策略
+ 实施[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)，提高安全性

监控和审计  
启用 AWS CloudTrail 以监控角色使用情况：  
+ 遵循《AWS CloudTrail User Guide》[https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ 配置 CloudWatch 日志集成以进行实时监控
+ 针对未经授权的 API 调用设置提醒

定期审查流程  
建立季度审查周期，执行以下任务：  
+ 使用 [IAM 访问权限分析器](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)审计未使用的权限
+ 移除已过时的权限
+ 根据最低权限原则更新角色

### 证书管理
<a name="dotnet-migrating-applications-security-best-cert"></a>

在 Elastic Beanstalk 环境中对 SSL/TLS 证书实施以下做法：

证书生命周期  
+ 使用 [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) 进行证书管理
+ 为 ACM 颁发的证书启用[自动续订](https://docs.aws.amazon.com/acm/latest/userguide/check-certificate-renewal-status.html)
+ 设置[到期通知](https://docs.aws.amazon.com/acm/latest/userguide/notifications-for-ACM.html)

安全标准  
+ 使用 TLS 1.2 或更高版本
+ 遵守 HTTPS 侦听器的 [AWS 安全策略](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies)
+ 实施 HTTP 严格传输安全（HSTS）（如需要）

### 安全组管理
<a name="dotnet-migrating-applications-security-best-sg"></a>

实施以下安全组最佳实践：

规则管理  
+ 记录所有自定义端口要求
+ 使用 [VPC 流日志](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)监控流量
+ 尽可能使用[安全组参考规则](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)而不是 IP 范围

定期审计  
建立每月审核以完成以下任务：  
+ 识别并删除未使用的规则
+ 验证 source/destination 需求
+ 检查是否有重叠的规则

### 日志记录和监控
<a name="dotnet-migrating-applications-security-best-logging"></a>

为了进行有效的安全监控，请配置以下日志：

EC2 实例上的 Windows 事件日志  

```
# 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 日志集成  
将 CloudWatch Logs 代理配置为将 Windows 事件日志流式传输到以 CloudWatch 进行集中监控和警报。

对于持续存在的问题，请收集这些日志并联系 AWS 支持 以获取以下信息：
+ 环境 ID
+ 部署 ID（如果适用）
+ 相关的错误消息
+ 安全变更时间表

# 了解 IIS 到 Elastic Beanstalk 的迁移映射
<a name="dotnet-migrating-applications-mapping"></a>

从 IIS 迁移到 Elastic Beanstalk 涉及将您的本地 Windows 服务器配置映射到云资源。 AWS 了解此映射对于成功迁移和迁移后管理至关重要。

## Elastic Beanstalk 中的 IIS 站点和应用程序
<a name="dotnet-migrating-applications-mapping-sites"></a>

在 IIS 中，网站代表一组拥有自身配置和内容的 Web 应用程序和虚拟目录。迁移到 Elastic Beanstalk 时，这些组件将按如下方式进行转换：

**IIS 网站**  
IIS 网站将转换成 Elastic Beanstalk 中的应用程序。每个网站的配置，包括其绑定、应用程序池和身份验证设置，都通过 Elastic Beanstalk 的部署清单 (`aws-windows-deployment-manifest.json`) 保留。  
例如，如果您有多个站点，例如*默认网站*和 *IntranetSite*，则会将每个网站的内容和配置**eb migrate**打包，同时保持其隔离。  
该命令会创建相应的应用程序负载均衡器（ALB）侦听器规则，以处理对应用程序的路由请求。它还会配置安全组，以确保根据原始 IIS 绑定进行适当的端口访问。

**应用程序池**  
IIS 应用程序池为应用程序提供工作线程隔离、运行时管理和回收功能。在 Elastic Beanstalk 中，它们映射到通过命名空间定义并`aws:elasticbeanstalk:environment:process`通过 IIS 在实例上配置的环境进程。 EC2   
迁移会保留关键的应用程序池设置，包括以下设置：  
+ 流程模型配置-身份（ApplicationPoolIdentity NetworkService、或自定义帐户）、空闲超时设置和进程回收间隔
+ .NET CLR 版本设置：维护指定的 .NET Framework 版本（v2.0、v4.0 或无托管代码）以确保应用程序兼容性
+ 托管管道模式：保留集成或经典管道模式设置，以维护 HTTP 请求处理架构
+ 高级设置：队列长度、CPU 限制、快速故障保护阈值和启动时间限制
在迁移到 Elastic Beanstalk 环境期间，**eb migrate** 命令会保留站点和应用程序池之间的映射。  
如果您的应用程序池使用自定义回收计划（特定时间或内存阈值），则这些计划是通过部署包中的 PowerShell 脚本实现的，这些脚本在 EC2 实例上配置相应的 IIS 设置。

**网站绑定**  
用于定义客户端如何访问应用程序的 IIS 网站绑定会转换为以下应用程序负载均衡器（ALB）配置：  
+ 端口绑定映射到相应的 ALB 侦听器规则
+ 主机标头配置转换为 ALB 路由规则
+ 启用 SSL 的网站使用 Certifice Manager (ACM) 进行 AWS 证书管理

## 虚拟目录和应用程序路径管理
<a name="dotnet-migrating-applications-mapping-virtual-dirs"></a>

IIS 虚拟目录和应用程序提供到物理目录的 URL 路径映射。Elastic Beanstalk 通过以下构造来维护这些关系：

**虚拟目录**  
迁移过程会将虚拟目录的物理路径保留在部署包中。  
路径映射是在 EC2 实例上的 IIS 配置中配置的，可确保迁移后您的 URL 结构保持不变。

**非系统驱动器物理路径**  
默认情况下，Elastic Beanstalk Windows 环境仅预置 C:\$1 驱动器（根卷）。在当前版本中，不支持迁移在非系统驱动器（D:\$1、E:\$1 等）中存储了内容的应用程序。
**eb migrate** 命令会自动检测位于非系统驱动器中的物理路径，并警告您可能出现的问题，如以下示例所示：  

```
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:\.
```
如果您的应用程序依赖于非系统驱动器，则在迁移之前，您需要修改应用程序，将所有内容存储在 C:\$1 驱动器中。

**嵌套应用程序**  
嵌套在网站下的应用程序将根据正确的路径配置和适当的应用程序池分配进行部署。迁移过程会保留所有 ` web.config` 设置，从而确保特定于应用程序的配置在云环境中继续按预期运行。

## URL 重写和应用程序请求路由（ARR）
<a name="dotnet-migrating-applications-mapping-url-rewrite"></a>

如果您的 IIS 部署使用 URL 重写或应用程序请求路由（ARR），**eb migrate** 会通过以下规则和配置来处理这些配置：

**URL 重写规则**  
如果可能，`web.config` 文件中的 URL 重写规则会转换为 ALB 路由规则。例如，以下条目将转换为 ALB 侦听器规则，根据主机标头和路径模式引导流量：  

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


**应用程序请求路由**  
通过在 EC2实例上安装 ARR 功能来保留 ARR 配置。迁移过程会完成以下任务：  
+ 配置代理设置以匹配源环境
+ 维护与 ARR 关联的 URL 重写规则

## 迁移构件结构
<a name="dotnet-migrating-applications-mapping-artifacts"></a>

运行 **eb migrate** 时，该命令会创建一个结构化目录，其中包含所有必需的部署组件。下方列表描述了目录结构：

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

`aws-windows-deployment-manifest.json` 文件是核心配置文件，用于指示 Elastic Beanstalk 如何部署应用程序。请参阅以下示例结构：

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

此清单可确保迁移结果如下：
+ 部署应用程序，以更正 IIS 路径
+ 应用自定义配置
+ 保留特定于站点的设置
+ 维持部署顺序

# 高级迁移场景
<a name="dotnet-migrating-applications-advanced-scenarios"></a>

本节介绍复杂 IIS 部署的高级迁移场景。

## 使用应用程序请求路由（ARR）进行多站点迁移
<a name="dotnet-migrating-applications-advanced-scenarios-arr"></a>

**eb migrate** 命令会在迁移期间自动检测并保留 ARR 配置。当它识别出您的 IIS 中的 ARR 设置时`applicationHost.config`，它会生成必要的 PowerShell 脚本，以便在目标 EC2 实例上重新安装和配置 ARR。

### ARR 配置检测
<a name="dotnet-migrating-applications-advanced-scenarios-arr-detection"></a>

迁移过程会检查 IIS 中的三个关键配置部分：
+ `system.webServer/proxy`：Core ARR 代理设置
+ `system.webServer/rewrite`：URL 重写规则
+ `system.webServer/caching`：缓存配置

例如，考虑常见的 ARR 配置，其中在端口 80 代理上运行的 `RouterSite` 向分别在端口 8081 和 8082 上运行的 `APIService` 和 `AdminPortal` 发出请求：

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

下图描述了这些规则如何隐藏在 IIS 服务器的端口 80 后面，而不是通过 EC2 安全组公开。应用程序负载均衡器只能访问端口 80，来自该端口的所有流量都通过端口 80 路由到目标组。

![\[使用应用程序请求路由（ARR）的 Elastic Beanstalk 架构\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/images/architecture-diagram-with-arr.png)


下面的命令可迁移此配置：

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

### ARR 迁移过程
<a name="dotnet-migrating-applications-advanced-scenarios-arr-process"></a>

迁移过程通过几个步骤保留 ARR 配置。

配置导出  
该工具将您现有的 ARR 设置从三个关键配置部分导出到存储在 `ebmigrateScripts` 目录中的单独 XML 文件中：  

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

安装脚本  
生成了两个 PowerShell 脚本来处理 ARR 设置：  

1. `arr_msi_installer.ps1`：下载并安装 ARR 模块

1. `arr_configuration_importer_script.ps1`：导入已导出的 ARR 配置

部署清单集成  
脚本会通过 `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"
                    }
                }
            }
        ]
    }
}
```

### 负载均衡器集成
<a name="dotnet-migrating-applications-advanced-scenarios-arr-lb"></a>

迁移过程会尽可能将您的 ARR 规则转换为应用程序负载均衡器（ALB）侦听器规则。例如，上述 ARR 配置生成 ALB 规则，这些规则基于 URL 路径模式路由流量，同时在 EC2 实例上维护内部路由。

由此产生的环境可维护 ARR 路由逻辑，同时充分利用 AWS弹性基础架构。您的应用程序可以继续像以前一样运行，由 ARR 处理内部路由，由应用程序负载均衡器管理外部流量分配。

## 使用基于主机的路由在无 ARR 的情况下完成多站点迁移
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr"></a>

虽然应用程序请求路由（ARR）是在 IIS 中管理多个站点的常用方法，但您也可以利用应用程序负载均衡器的基于主机的路由功能，将多站点部署直接迁移到无 ARR 的 Elastic Beanstalk。这种方法可以省去额外的路由层，从而降低复杂性并提高性能。

### 基于主机的路由概述
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-overview"></a>

在这种方法中，每个 IIS 站点都暴露在 EC2 实例之外，Application Load Balancer 会根据主机标头将流量直接路由到相应的端口。这样一来便不再需要 ARR，同时保持应用程序之间互相分离。

考虑使用包含三个站点的多站点 IIS 配置，每个站点都有自己的主机名绑定：

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

这些站点通过安全组在端口 8081、8082 和 8083 上 EC2 公开。应用程序负载均衡器根据负载均衡器侦听器规则配置路由到这些站点。

![\[不使用应用程序请求路由（ARR）的 Elastic Beanstalk 架构\]](http://docs.aws.amazon.com/zh_cn/elasticbeanstalk/latest/dg/images/architecture-diagram-without-arr.png)


### 迁移过程
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-migration"></a>

要在不使用 ARR 的情况下将此配置迁移到 Elastic Beanstalk，请使用以下示例中的 **eb migrate** 命令：

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

迁移过程会自动使用基于主机的路由规则配置应用程序负载均衡器，这些规则会根据主机标头将流量引导到相应的目标组。每个目标组将流量转发到您的 EC2 实例上的相应端口：

1. 主机标头 www.example.com → 端口 8081 上的目标组

1. 主机标头 api.internal → 端口 8082 上的目标组

1. 主机标头 reports.internal → 端口 8083 上的目标组

### SSL/TLS 配置
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-ssl"></a>

要使用保护您的应用程序， SSL/TLS 请执行以下步骤：

1. 通过 AWS Certificate Manager(ACM) 为您的域名申请证书。

1. 使用这些证书在应用程序负载均衡器上配置 HTTPS 侦听器。

1. 更新您的环境配置，使其包含具有以下配置选项设置的 HTTPS 侦听器。

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

使用此配置，负载均衡器上会发生 SSL 终止，流量将通过 HTTP 转发到您的实例。这简化了证书管理，同时确保与客户端的安全连接。

### 最佳实践
<a name="dotnet-migrating-applications-advanced-scenarios-no-arr-best"></a>

安全组  
将安全组配置为仅允许来自应用程序负载均衡器安全组的 IIS 站点使用的端口（本示例中为 8081、8082、8083）上的入站流量。

运行状况检查  
为每个目标组配置运行状况检查，以确保流量仅路由到运行状况良好的实例。如果尚不存在运行状况检查端点，则为每个应用程序创建运行状况检查端点。

监控  
设置 CloudWatch 警报以分别监控每个目标组的运行状况和性能。这样就能识别出单个应用程序特有的问题。

扩展  
在配置自动扩缩策略时，应考虑所有应用程序的资源需求。如果一个应用程序的资源需求明显不同，可以考虑将其迁移到独立的环境。

## 虚拟目录管理
<a name="dotnet-migrating-applications-advanced-scenarios-vdir"></a>

在将 IIS 应用程序迁移到 Elastic Beanstalk 时，**eb migrate** 命令可以保留虚拟目录结构。

### 默认权限配置
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-default"></a>

迁移虚拟目录时，通过授予对以下内容的 ReadAndExecute 访问权限来**eb migrate**建立一组基准权限：
+ IIS\$1IUSRS
+ IUSR
+ 经过身份验证的用户

例如，假设一个典型的虚拟目录结构：

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

### 受密码保护的虚拟目录
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-password"></a>

当 **eb migrate** 遇到受密码保护的虚拟目录时，系统会发出警告并需要手动干预。

以下配置示例将导致示例之后出现的警告响应。

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

要维持密码保护，请创建如下所示的自定义部署脚本：

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

通过将此脚本包含在清单中，将其添加到部署中：

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

### 自定义权限管理
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-custom"></a>

**eb migrate** 命令会为自定义权限脚本提供框架，以便适应需要默认权限以外的权限的应用程序。



```
$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"
}
```

### 最佳实践
<a name="dotnet-migrating-applications-advanced-scenarios-vdir-best"></a>

遵循这些最佳实践来规划、执行、监控和验证您的迁移。

迁移前规划  
迁移之前，记录现有权限和身份验证要求。部署到生产环境之前，先在开发环境中测试自定义权限脚本。

共享内容管理  
对于共享内容目录，请确保已通过自定义脚本正确配置所有必需的文件系统权限。考虑使用[ FSx 适用于 Windows 的 Amazon 文件服务器](https://aws.amazon.com/fsx/windows/)来满足共享存储需求。

监控和验证  
迁移后监控应用程序日志，以验证对虚拟目录的访问是否正确。请特别注意以下方面：  
+ 应用程序池身份访问权限
+ 自定义服务账户权限
+ 网络共享连接
+ 身份验证失败次数

## 自定义应用程序池设置
<a name="dotnet-migrating-applications-advanced-scenarios-apppool"></a>

默认情况下，**eb migrate** 命令不会复制自定义应用程序池设置。要保留自定义应用程序池配置，请按照以下过程创建并应用自定义清单部分。

1. 创建迁移构件的存档。

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

1. 创建用于配置应用程序池的自定义 PowerShell 脚本。

   ```
   # 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. 更新 `aws-windows-deployment-manifest.json` 文件以包含自定义脚本。

   ```
   {
       "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. 使用更新的存档目录创建环境。

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

`--archive-dir` 参数会让 **eb migrate** 使用之前创建的源代码，从而避免创建新的存档。

## 部署先前版本
<a name="dotnet-migrating-applications-advanced-scenarios-previous"></a>

**eb migrate** 会在 Elastic Beanstalk 中通过带有时间戳的目录和应用程序版本来维护迁移历史记录。每次迁移都会创建一个唯一的 zip 文件，此文件可根据需要进行部署。

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

`latest` 符号链接始终指向最近创建的迁移构件目录。除了相关的应用程序和错误日志外，每个迁移构件目录还包含可以部署到 Elastic Beanstalk 的 `upload_target.zip` 文件。

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

可以使用 **eb migrate** 部署 `upload_target.zip` 文件：

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

# 故障排除和诊断
<a name="dotnet-migrating-applications-troubleshooting"></a>

**尝试使用 Amazon Q 开发者版 CLI 进行人工智能辅助故障排除**  
 Amazon Q 开发者版 CLI 可以帮助您针对环境问题快速进行故障排除。Q CLI 可通过检查环境状态、审核事件、分析日志和询问澄清问题来提供解决方案。有关更多信息和详细演练，请参阅博客中的使用 [Amazon Q Developer CLI 对 Elastic Beanstalk 环境进行故障排除](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/)。 AWS 

本节提供有关对 IIS 应用程序迁移到 Elastic Beanstalk 期间可能出现的常见问题进行故障排除的指导。

## 将 EC2 密钥对与您的环境相关联
<a name="dotnet-migrating-applications-troubleshooting-keypair"></a>

您可以使用亚马逊密钥对安全地登录为您的 Elastic Beanstalk 应用程序预配置的亚马逊弹性计算云 (Amazon EC2) 实例。 EC2 有关创建密钥对的说明，请参阅亚马逊* EC2 用户指南 EC2*中的[使用亚马逊创建密钥对](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair)。

将 keyname 指定为 **eb migrate** 的效果是，将 Elastic Beanstalk 环境与密钥对相关联。出于安全考虑，这不会在您的 EC2 实例安全组上打开端口 3389。您可以关联其他 EC2 安全组，允许端口 3389 上的流量在初始迁**eb config**移后通过。

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

当您创建密钥对时，Amazon 会 EC2 存储您的公钥副本。如果您不再需要使用它来连接任何环境实例，可以将其从 Amazon 中删除 EC2。有关详情，请参阅《*Amazon EC2 用户指南》*中的[删除您的密钥对](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair)。

有关连接到 Windows 亚马逊 EC2 实例的更多信息，请参阅[连接到 Windows 实例](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html)。

## 访问日志
<a name="dotnet-migrating-applications-troubleshooting-logs"></a>

EB CLI 提供了一种**eb logs**工具，您无需登录其实例即可使用该工具从 Elastic Beanstalk 环境中检索日志。 EC2 执行 **eb migrate** 后，您可以发出 **eb logs --zip** 命令，该命令会下载日志并将其保存到 `.elasticbeanstalk\logs` 目录中。

或者，您可以通过 E AWS lastic Beanstalk 控制台查看日志。有关更多信息，请参阅 [查看您的 Elastic Beanstalk 环境中的 Amazon EC2 实例的日志](using-features.logging.md)。

## 访问客户端构件
<a name="dotnet-migrating-applications-troubleshooting-artifacts"></a>

**eb migrate** 命令存储由迁移构件目录内 **msdeploy** 生成的应用程序和错误日志。

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

## 监控环境运行状况
<a name="dotnet-migrating-applications-troubleshooting-health"></a>

Elastic Beanstalk 通过增强型运行状况监控功能，帮助您监控运行状况。这是一个自动的运行状况监控系统，利用诸如 CPU 利用率、延迟、请求计数和响应代码之类的内置指标，持续跟踪应用程序实例的运行状态。

运行状况监控系统利用基于代理的方法来收集实例级数据，并与实时日志和警报集成。弹性负载均衡（ELB）和自动扩缩会动态响应运行状况变化，从而确保高可用性和容错能力。高级监控模式（包括增强型运行状况报告）可针对应用程序行为提供精细可见性，从而实现主动故障排除和自动恢复机制。

运行 EB CLI **eb health** 命令显示环境运行状况。将显示以下信息：
+ 实例运行状况
+ 应用程序响应指标
+ 系统资源利用率
+ 近期部署事件

## EC2 性能优化
<a name="dotnet-migrating-applications-troubleshooting-performance"></a>

默认情况下，**eb migrate** 会选择 [c5.2xlarge](https://aws.amazon.com/ec2/instance-types/c5/) 实例类型以提供最佳的 Elastic Beanstalk 首次使用体验。您可以用 **--instance-type** 参数覆盖此行为：

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

对于生产环境，请在选择实例类型时考虑以下因素：
+ 应用程序的内存要求
+ 针对处理工作负载的 CPU 要求
+ 网络性能需求
+ 成本优化目标

## EBS 卷配置
<a name="dotnet-migrating-applications-troubleshooting-ebs"></a>

默认情况下，Elastic Beanstalk 将仅为环境创建根块设备卷 (`C:\`)。您可以通过 **--ebs-snapshots** 选项传递其他 Amazon Elastic Block Store 快照卷：

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

有关如何使用 Elastic Beanstalk 配置块设备映射的示例，请参阅博客文章 [Customize Ephemeral and EBS Volumes in Elastic Beanstalk Environments](https://aws.amazon.com/blogs/devops/customize-ephemeral-and-ebs-volumes-in-elastic-beanstalk-environments/)。

如果是对存储要求较高的应用程序，请考虑以下选项：
+ 使用 EBS 卷存储持久性数据
+ 为静态内容实施 Amazon S3
+ 将 Amazon f FSx or Windows 文件服务器用于共享文件系统

## 常见问题和解决方案
<a name="dotnet-migrating-applications-troubleshooting-common"></a>

**事件：***Missing Web Deploy installation*

如果出现关于找不到 Web 部署的错误，请从 [Microsoft Web 平台安装程序](https://www.iis.net/downloads/microsoft/web-deploy)中安装 Web 部署 3.6 或更高版本。以下示例显示了可能出现的错误消息。

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

**事件：***Permission issues during migration*

如果出现关于权限的错误，请确保以管理权限运行 EB CLI。以下示例显示了可能出现的错误消息。

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

**事件：***Application pool identity issues*

如果应用程序由于应用程序池标识问题而无法启动，请创建自定义脚本来配置应用程序池身份，如[自定义应用程序池设置](dotnet-migrating-applications-advanced-scenarios.md#dotnet-migrating-applications-advanced-scenarios-apppool)中所示。

**事件：***SSL certificate configuration errors*

如果 HTTPS 绑定无法正常工作，请确保已使用 **eb mibrate** 选项 `--ssl-certificates` 参数指定有效的 ACM 证书 ARN。

**事件：***Environment creation timeout*

如果环境创建超时，请在 AWS 管理控制台中检查 CloudFormation 事件以了解特定的资源创建失败。常见原因包括 VPC 配置问题或服务限制。

## 获取支持
<a name="dotnet-migrating-applications-troubleshooting-support"></a>

如果您遇到无法解决的问题，请在联系之前 AWS 支持 收集以下信息：
+ 环境 ID (`eb status`)
+ 应用程序日志 (`eb logs --zip`)
+ `.\migrations\latest\` 中的迁移构件
+ 源 IIS 配置（`eb migrate explore --verbose` 输出）
+ 详细错误消息

有关 Elastic Beanstalk 故障排除的更多信息，请参阅[排查 Elastic Beanstalk 环境的问题](troubleshooting.md)。

# 比较迁移选项：EB CLI vs. AWS Application Migration Service
<a name="dotnet-migrating-applications-comparison"></a>

AWS 为将 Windows 应用程序迁移到云端提供了多种途径。本节比较了两个主要选项：EB CLI 中的**eb migrate**命令和 AWS Application Migration Service (MGN)。了解这些方法之间的差异有助于您根据自己的特定需求，选择最合适的迁移策略。


**迁移选项对比**  

| 功能 | EB CLI (**eb migrate**) | AWS Application Migration Service (MGN) | 
| --- | --- | --- | 
| 主要关注点 | IIS 网站和应用程序的应用程序级迁移 | 整台计算机（物理、虚拟或云服务器）的服务器级重新托管 | 
| 最适合 | 想要以最少的重新配置，直接迁移到 Elastic Beanstalk 的 IIS 应用程序 | 涉及多台服务器或复杂基础架构的大规模迁移 | 
| 发现方法 | 对 IIS 站点、应用程序和配置的应用程序级发现 | 对整台计算机（包括操作系统和应用程序）的服务器级复制 | 
| 目标环境 | 直接创建和配置针对 Windows 应用程序优化的 Elastic Beanstalk 环境 | 创建需要额外配置才能与 Elastic Beanstalk 配合使用的 EC2 实例 | 
| 配置保留 | 自动保留特定于 IIS 的配置（站点、应用程序池、绑定） | 保留整个服务器配置，其中可能包括不必要的组件 | 
| 部署模式 | 使用 Elastic Beanstalk 最佳实践创建干净的 Elastic Beanstalk 环境，并部署应用程序 | 创建源服务器的副本，但其可能需要针对云操作进行优化 | 
| 迁移规模 | 非常适合特定应用程序的定向迁移 | 专为多台服务器的大规模迁移而设计 | 
| 迁移后步骤 | 最小；环境已准备就绪，可与 Elastic Beanstalk 管理工具配合使用 | 需要其他步骤才能与 Elastic Beanstalk 集成，例如执行 SSM 发布后操作 | 

## 何时使用各个迁移选项
<a name="dotnet-migrating-applications-comparison-when"></a>

**有以下要求时，选择 **eb migrate**：**  
+ 您想要迁移特定的 IIS 应用程序，而不是整个服务器
+ 您的目标是采用 Elastic Beanstalk 作为应用程序管理平台
+ 您想利用 Elastic Beanstalk 的托管平台功能，例如轻松扩展、部署和监控
+ 您更喜欢遵循云原生操作 AWS 最佳实践的干净部署
+ 您想尽量减少迁移后的配置工作

** AWS Application Migration Service 当你有以下要求时，请选择：**  
+ 您需要迁移大量服务器
+ 您采用了必须精确保留的复杂服务器配置
+ 您的应用程序存在兼容性问题，因此需要维护精确的服务器环境
+ 您想在对应用程序进行最少更改的情况下进行直接迁移
+ 您计划在迁移后重构或优化应用程序

## 迁移工作流程对比
<a name="dotnet-migrating-applications-comparison-workflow"></a>

**EB CLI (**eb migrate**) 工作流程：**

1. 在源 IIS 服务器或堡垒主机上安装 EB CLI。

1. 运行 **eb migrate** 以发现 IIS 应用程序。

1. 该命令会打包应用程序和配置。

1. 系统会使用适当的资源创建 Elastic Beanstalk 环境。

1. 应用程序将部署到新环境。

1. 您可以使用 Elastic Beanstalk 工具立即管理应用程序。

**AWS Application Migration Service 工作流程：**

1. 在源服务器上安装 AWS 复制代理。

1. 配置并测试数据复制。

1. 启动测试实例以验证功能。

1. 安排转换到. AWS

1. 启动生产实例。

1. 执行发布后操作以针对云进行优化。

1. 如果 Elastic Beanstalk 是目标平台，则需要进行额外的配置才能与 Elastic Beanstalk 集成。

## 结论
<a name="dotnet-migrating-applications-comparison-conclusion"></a>

Elastic Beanstalk 是 Windows 平台 AWS应用程序的首选目的地，它提供了一个可简化部署、扩展和管理的托管环境。**eb migrate** 命令可为 IIS 应用程序提供通往 Elastic Beanstalk 的直接路径，并且具有自动发现和配置功能，可保留应用程序设置。

虽然为大规模服务器迁移 AWS Application Migration Service 提供了强大的功能，但它还需要额外的步骤才能与 Elastic Beanstalk 集成。对于大多数以 Elastic Beanstalk 为目标平台的 IIS 应用程序迁移而言，**eb migrate** 提供了一种与 Elastic Beanstalk 的托管服务模型保持一致的更简化的方法。

请在考虑规模、复杂性和 AWS上所需的最终状态架构等因素的前提下，选择最适合您特定要求的迁移方法。

有关的更多信息 AWS Application Migration Service，请参阅[什么是 AWS Application Migration Service？](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) 在《 AWS Application Migration Service 用户指南》中。