支持SFTP接入且可挂载至Windows机器的Azure存储方案咨询

目前没有单一Azure原生存储服务可同时原生满足两个核心需求：对外提供SFTP服务接收客户每日文件推送、支持直接挂载到Windows机器供厚客户端访问。你初步设计的「SFTP接收入Blob Storage + 同步到Azure NetApp Files供Windows挂载」的方案是生产环境验证过的可行路径，没有架构硬伤。

• Azure Blob Storage：其SFTP功能当前确实处于预览状态，仅支持通过SFTP协议读写Blob内容，不原生支持SMB协议挂载，无法直接映射为Windows本地盘符供厚客户端调用，且预览阶段不承诺SLA，不适合直接作为客户端访问的存储层，但作为SFTP接收端、持久化冷存储层完全够用，存储成本远低于Premium级的NetApp Files。
• Azure NetApp Files：原生支持SMB 3.x/2.x协议，可直接作为网络驱动器挂载到Windows实例，文件权限、IO性能、访问延迟完全匹配厚客户端的本地磁盘访问要求，不存在第三方挂载工具的兼容性问题，但服务本身不内置SFTP服务端能力，无法直接对外暴露SFTP端口接收客户推送的文件。

你原来的方案可以做几处细节调整，降低运维成本：

• SFTP接收层直接启用Blob Storage的SFTP预览功能即可，不需要额外搭建虚机部署SFTP服务，配置好对应的SFTP账号、权限、存储冗余策略就行，这一层作为全量文件的持久化源站，成本更低。
• 文件同步环节不用自行开发脚本搬运，直接用Azure原生的AzCopy工具或者存储同步服务配置规则，支持实时/定时同步Blob内新增、修改的文件到NetApp Files的SMB共享卷，同步过程自带MD5校验，可避免文件损坏、传输中断的问题。
• Windows挂载层直接配置NetApp Files的SMB共享，按照厚客户端的权限要求分配对应NTFS权限即可，不需要额外做协议转换。

如果不想维护两层存储的同步链路，也可以选择在NetApp Files所属的VNet内部署轻量SFTP服务（可用Azure容器实例运行开源SFTP镜像），将SFTP服务的存储路径直接映射到NetApp Files的SMB卷，客户推送的文件直接写入NetApp Files，省掉同步步骤。但这个方案需要自行维护SFTP服务的高可用、账号鉴权、安全策略，运维成本比Blob中转方案高，仅适合单文件体积大、文件总量高、同步链路开销占比过高的场景。

内容的提问来源于stack exchange，提问作者youssef zmarou