Azure Blob 存储 对 SSH 文件传输协议（SFTP）的支持可使存储帐户直接通过 22 端口响应请求，因此你无需在其后端运行服务器，也能使用你的用户已在使用的同一种协议。 如果你今天在虚拟机（VM）上托管SFTP服务器，这意味着没有操作系统需要打补丁，没有容量和体积，也没有复制任务把文件从着陆盘上移开，因为你上传的数据会自动变成blob。
本文比较了自托管SFTP服务器与Azure Blob 存储 SFTP，从成本、性能、运营和安全方面。 它还包括如何在迁移前检查兼容性，以及如何用单一工作负载验证变更。
文件如何到达存储账户
自托管服务器时，传输会经过你拥有和管理的多个组件。 下图展示了典型传输的模式。
文件会到达磁盘，然后你构建的进程会把它移动到需要的地方。 每一环都由你负责：虚拟机、操作系统、SSH 守护进程、磁盘及其保留策略、复制任务，以及围绕这一切的监控。 在复制完成之前，数据存在于两个地方，且都不是记录系统。
而 Azure Blob 存储 SFTP 则是存储账户自行终止协议。 下图展示了这种转移模式。
上传的内容就是该二进制大型对象。 没有着陆盘，也没有复制任务，因为没有什么可复制的。 一旦传输完成，文件即可被 Blob REST API、Azure Data Lake Storage、Network File System （NFS） 3.0、Azure 事件网格 以及任何已经指向该账户的处理程序访问。
只有主机名会变。 对于连接和传输数据的用户来说，其他一切都保持不变。 如果你想要，它们使用相同的协议、相同的客户端工具和相同的凭证模型。
如果你的目标是在考虑成本和安全的前提下将文件传输迁移到云端，这种方法是一个实用的起点。 你并不是在采用一种新的传输模式；你是在移除当前已在运行的那套系统所依托的底层基础设施。
Cost
启用 SFTP 会产生按小时计费的费用；只要 SFTP 处于启用状态，无论是否有人连接，都会收费。 其他所有费用按标准账户费率计费，包括静止容量、交易和出口。 所有SFTP命令都会转换为账户上的读、写或其他交易。 通过SFTP传输的数据没有按每GB单独收费。
如果你的转账是在固定窗口内运行，你可以只在需要时启用SFTP，避免中间的费用。
注释
要查找当前的小时费率，请参见 Azure Blob 存储 定价页面。 只有在文件结构下拉列表中选择层级命名空间（NFS v3.0，SFTP 协议）时，该费用才会在该页面显示。
下表说明了根据你今天运行的内容，你可以预期会得到的结果：
| 您今天运行的内容 | Blob 存储 SFTP 很可能会 | 为什么 |
|---|---|---|
| 单个具有 1 个或 2 个 vCPU 的虚拟机 | 成本更高 | 按小时端点收费超过小型虚拟机的计算成本。 如果你的整体规模也就这么大，成本就不是迁移的理由。 不过，运营效率可能是搬迁的理由之一。 您可以在本文的 运营 部分了解更多关于这些效率的信息。 |
| 一个为持续吞吐量设计的虚拟机，配备管理磁盘和备份 | 差不多 | 端点电荷抵消计算、磁盘和备份。 |
| 多个实例以实现高可用性，或使用另一个区域进行灾难恢复 | 显著减少 | 你不再为冗余计算和第二个区域付费。 |
| 上述任一行，在计入工程时间后 | Less | 打补丁、密钥轮换和待命值班时间都不会出现在任一账单上。 |
为了公平比较每个选项，在估算中包含计算成本、操作系统和登陆盘成本以及备份费用。 只有在部署了这些区域时，才添加负载均衡器、公共IP地址或第二个区域，因为许多SFTP服务器作为单一虚拟机运行，没有这些功能。
有两个成本很容易被忽视。 首先，数据通常会在保留窗口期间停留在着陆盘 和 目的地，所以你要为两者付费。 其次，修补、按键轮换和维护复印工作的工程时间根本不会出现在发票上。
用现有资源组的成本 分析 ，而不是用价格计算器，这样你就能从实际收费的基础上分析。 有关当前费率，请参见 Azure Blob 存储 定价和 Azure Blob 存储 的计划与管理成本。
Performance
虚拟机的上限由其自身的SKU决定：网络带宽、磁盘吞吐量以及用于SSH加密的CPU容量。 存储账户的上限是账户的进出和请求速率上限，这些上限明显更高，且你无需额外努力即可达到。
吞吐量会随着并发连接数的增加而提升，并且在单个客户端下，高级块 Blob 帐户的带宽约为标准常规用途 v2 帐户的 2.3 倍。 关于调校指导，请参见 SFTP性能考虑。
Operations
Azure Blob 存储 SFTP 提供了更高的运营效率。
因为存储账户会终止SFTP，虚拟机、着陆盘和复制工作都会消失，维持它们运行的工作也随之消失。 你不再需要打补丁、加固SSH守护进程、规划容量、构建和测试自己的高可用性和灾难恢复，或支持将文件迁移到存储的流水线。
主机密钥管理就是一个例子。 重建虚拟机会改变其 SSH 主机密钥，除非你有意保留该密钥；而客户端工具会将主机密钥的意外变更视为可能的中间人攻击。 因此，日常维护变成了与所有连接者的协调练习。 相比之下，Azure 发布其 SFTP 主机密钥，客户端工具可以根据文档来源验证。 请参见 SFTP的主机密钥。
安全性
自托管的OpenSSH服务器支持密码和公钥认证。 你拥有账户、 sshd 配置、密钥分发和轮换。
Azure Blob 存储 SFTP 支持这两种方法，并增加了 Microsoft Entra ID。 你可以为每个用户选择合适的方法：
| 方法 | 工作原理 | 最适用于 |
|---|---|---|
| Password | Azure 生成密码并显示一次。 你不能设置自定义密码，所以无法使用弱密码或重复使用。 | 快速入门 |
| SSH 密钥对 | 你提供或生成一个公钥，每个本地用户最多可获得10个。 | 自动化、无人值守的传输 |
| Microsoft Entra ID | 用户通过 Entra ID 认证，并获得一份有效期为 65 分钟的证书，该证书由 Azure 基于角色的访问控制（RBAC）、Azure 属性访问控制（ABAC）和 POSIX 访问控制列表（ACL）授权。 | 凡是重视身份治理的场景，均推荐使用 |
Microsoft Entra ID 是这两种方法之间最显著的区别。 无论是在虚拟机还是存储账户中，任何本地凭证的秘密都具有长效性，并且不受你对遗产其他部分应用的身份控制。
Entra ID 证书在 65 分钟后过期，因此错误的凭证会自行失效。 多因素认证和条件访问对文件传输的适用方式与其他所有内容相同。 当账户被禁用时，SFTP访问会在同一时刻终止。 通过使用 外部身份，你交换文件的组织可以从自己的租户进行认证，因此你不再代表他们发放或存储凭证。
本地用户依然完全支持，所以你可以按自己的节奏采用 Entra ID。
除了身份之外，存储帐户还提供了一些控制功能，否则这些功能就需要你自行构建和维护：
仅接受Microsoft 安全开发生命周期批准的算法，因此不允许基于SHA-1的密钥交换等弱选项
ssh-dss。私有端点将 流量保留在你的虚拟网络上。
静态加密、客户管理密钥、不可篡改策略和诊断日志，对通过SFTP上传的文件适用，与其他blob同样适用。
欲了解更多信息，请参见 SFTP 权限模型和通过 Microsoft Entra ID 授权访问 Blob 存储 over SFTP。
迁移前先检查兼容性
大多数工作负载无需更改即可迁移，Azure Blob 存储 支持多种 SFTP 客户端工具。 要确认你自己的情况，请查看 已知支持的客户端 以及 SFTP的限制和已知问题。
请尽早检查这些项，因为它们是工作负载无法按原样迁移的最常见原因：
访问路径中的现有ACL配置。
一个被其他组织列入允许名单的静态出站 IP 地址。
这是管理文件传输工作流程或AS2的需求。
用一个工作负载试试吧
在非生产存储帐户上启用 SFTP，并让一个低风险馈送与现有服务器并行运行两周。 你从自己的工作负载中获得吞吐量、兼容性和成本数据，这些数据比估算更有用。