Amazon SAA-C03: 数据传输与迁移 — 学习指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

属于 AWS SAA-C03 — 完整学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

带宽与物理寄送决策

每次迁移都始于算术计算。在选择工具之前，请先计算理论上的传输时间：

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

数字是无情的。在持续 100 Mbps 的速率下，传输 1 TB 大约需要 24 小时；在 1 Gbps 速率下，大约需要 2.5 小时。一条 15 Mbps 的链路，如果利用率上限为 70%，每天只能传输约 113 GB，因此传输 20 TB 将需要超过 175 天。在夜间传输 150 TB（在 100 Mbps 的 80% 速率下持续 10 小时），每晚可产生约 360 GB，即每月 10.5 TB——这远未达到 30 天的最后期限。即使在 24/7 全饱和状态下，100 Mbps 的速率每天也只能移动约 1 TB，因此 150 TB 最少需要 150 天。在 PB 级别，情况会更糟：一条 500 Mbps 的链路，在实际效率下，理论吞吐量约为每天 5.4 TB，这意味着 10 PB 的数据需要超过五年的连续传输——这比大多数 Direct Connect 专线的预置时间还要长。

一个合理的经验法则：

在迁移场景中，最常见的错误答案就是选择一种在数学上无法在时间窗口内完成的广域网传输方式。其必然带来的陷阱——“我们每天晚上通过广域网运行它就行了”——并不仅仅是速度更慢。它会消耗生产带宽，有导致部分或损坏传输而需要重新上传的风险，并且一旦计入带宽费用和工程师时间，通常成本更高。一台 Snowball 设备的费用加上运费是一个固定的、可预测的成本项。

用于离线批量传输的 Snow Family

Snowball Edge 设备有两种型号：

Snowcone 是一种小尺寸（约 8 TB SSD）、坚固耐用且可通过快递运输的设备，适用于空间有限的站点，并预装了用于边缘同步的 DataSync 代理。Snowmobile——一个可运载高达 100 PB 数据的 45 英尺集装箱——曾用于 EB 级别的数据中心整体搬迁，但在大多数区域已被并行的 Snowball Edge 设备集群所取代。对于任何低于 PB 级别的数据量选择 Snowmobile 都是一个干扰选项。

计算优化型不仅仅是硬盘更大。它可以在本地运行 EC2 AMI、Lambda 函数和 Greengrass 工作负载，因此当数据在提取前必须进行转换、筛选或对个人身份信息（PII）进行脱敏时，当工作负载在提取后必须立即在 AWS 中恢复时，或者当站点处于离线或间歇性连接状态（如船舶、远程采矿、战术部署、远程研究）时，它都是正确的选择。当需要设备上处理时，选择计算优化型；当工作负载是纯粹的批量复制时，选择存储优化型。

每台 Snow 设备都使用永不离开 AWS 的 KMS 密钥对静态数据进行 256 位加密。设备外壳具有防篡改功能，配有电子墨水屏运输标签和硬件可信平台模块（TPM）。设备上的数据通过 Snowball 客户端、S3 兼容终端节点或 NFS 挂载写入；TLS 在数据提取和运输清单交换期间保护传输中的数据。设备返回后，其内容被提取到 S3，然后设备会根据 NIST 800-88 标准进行加密擦除。

对于每个站点 PB 级别的工作，并行处理是标准模式。一个拥有 1–2 Gbps 链路容量的办公室，要在线迁移 1 PB 数据仍需要数月的持续饱和传输；而一个由约 13 台存储优化型设备（每台 80 TB）组成的集群并行运送，可以在四周内完成任务，同时不占用办公室的互联网链路。对于一个在饱和的 100 Mbps 链路上需要在两周内完成的 600 TB 任务，一个小型并行设备集群是唯一正确的答案——即使不考虑成本，物理定律也使得使用 DataSync 或新建 Direct Connect 成为不可能。

DataSync：用于在线、经过验证的增量传输

当带宽充足，但工作负载特性——例如数百万个小文件、深度目录树、持续的增量同步或跨文件系统迁移——会让简单的工具不堪重负时，DataSync 就是正确的选择。一个包含 2000 万个 4KB 文件的目录，如果使用 aws s3 cp 进行复制，其瓶颈会是往返延迟，而不是吞吐量；每一次 PutObject 操作都会产生一次 TLS/HTTP 往返和一次 API 请求费用。将文件打包成归档虽然可行，但会丧失对单个文件的可寻址性。DataSync 的代理可以跨多个 TCP 流并行处理，原生处理元数据，使用 SHA-256 对每个文件进行端到端校验和验证，透明地重试，并向 CloudWatch 报告——每个代理最高可实现约 10 Gbps 的速度，并采用可预测的按 GB 定价。

源和目标涵盖 NFS、SMB、HDFS、自我管理的对象存储、S3、EFS、FSx for Windows File Server、FSx for Lustre、FSx for OpenZFS 以及 FSx for NetApp ONTAP。传输过程中使用 TLS 1.2 加密，并且可以通过 VPC 接口端点进行，以避免使用公共互联网。

一个关键细节：对于本地的 NFS/SMB 源，DataSync 需要一个代理。该代理可以作为虚拟机在 VMware、Hyper-V 或 KVM 上运行，也可以在 EC2 或 Snowcone 上运行。认为 DataSync 对于本地环境是无代理的是一个常见的陷阱——只有当源和目标两端都是 AWS 原生服务时，它才是无代理的。

一个最小化的部署：

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

有两个重要的操作特性。带宽限制 (BytesPerSecond) 可以防止占满共享链路——这直接应对了“与其它部门共享 1 Gbps 链路”这类场景。筛选和调度功能允许在非工作时间进行同步，并排除临时文件。在 10 Gbps 的 Direct Connect 上，当用户持续读写时，调度重复任务是典型的模式：首次扫描传输大部分数据，后续的增量运行捕获变更，即使在部分利用率下，也能在远少于一周的时间内完成 700 TB 的传输。

一个更隐蔽的陷阱与元数据保真度有关。DataSync 会保留一组精选的 POSIX 或 SMB 属性——例如 NFS 的 UID/GID/模式/时间戳，或 SMB 的所有权和 DACL——但它不会捕获所有专有的 NAS 属性。供应商特定的 ACL、协议暴露范围之外的扩展属性、快照和去重元数据都超出了其范围。当合规性要求一个包含供应商特性的精确 NAS 副本时，仅靠 DataSync 是不够的；需要一个能感知 NetApp 的路径，例如使用 SnapMirror 的 FSx for ONTAP，或者通过 Storage Gateway 进行的“直接迁移”(lift-and-shift)。

DataSync 也是 Snowball 的补充：Snowball 移动最初的 150 TB 数据，之后由 DataSync 处理每周 500 GB 工作集的持续增量变更。

Storage Gateway：混合云呈现层，而非迁移工具

Storage Gateway 不是一个迁移工具——它是一个混合云呈现层。本地应用程序继续使用 NFS、SMB、iSCSI 或 iSCSI-VTL 协议，而数据则落入 S3、S3 Glacier 或 EBS 快照中。将 Storage Gateway 与 DataSync 混淆是一个常见的错误：File Gateway 并非为快速移动 70 TB 数据而设计，而 DataSync 也不会为本地客户端提供一个持久化的共享。

文件网关是主力。写入 \\gateway\share\reports\2024\report.pdf 会生成 s3://bucket/reports/2024/report.pdf——可被 Athena、Lambda、EMR 或任何 S3 客户端原生使用。这种文件到对象的一对一映射是相比于黑盒备份目标的一大优势。本地缓存意味着热点文件以局域网速度返回；冷文件则按需从 S3 流式传输。

缓存是该设备的关键。热数据的读取在本地提供服务；写入首先落在本地磁盘上，然后异步上传。一个常见的设计错误是假设由 S3 支持就意味着每次读取都会产生互联网往返延迟——并非如此，前提是工作集能装入缓存。相反，缓存大小不足会导致持续的缓存未命中，工作负载会显得“慢”。经验法则：缓存大小 = 总数据集的 20% 或热工作集的 100%，取较大者。

缓存模式与存储模式的陷阱值得特别关注。缓存模式将主副本保存在 S3 中，热数据块保留在本地——成本低、弹性好，但缓存未命中意味着一次广域网往返。存储模式将主副本保存在本地磁盘上，并以 EBS 快照的形式异步快照到 S3——每次读取都是本地且低延迟的，但整个数据集必须能容纳在本地。对于“在数据备份到 AWS 的同时，本地可以访问所有数据”这样的备份替代需求，存储模式是正确的；缓存模式会违反该要求。为需要整个数据集低延迟的工作负载选择缓存模式会破坏设计初衷；当本地站点无法承载完整数据集时，根据定义，选择存储模式是不可能的。

磁带网关解决一个非常具体的需求：在淘汰物理磁带库的同时，通过 iSCSI 提供一个 VTL（虚拟磁带库）来保持 Veeam、NetBackup 或 Commvault 工作流的完整性，数据通过生命周期策略从 S3 转移到 Glacier 或 Deep Archive。当法规要求的保留期是以磁带介质定义的，且现有备份软件无法更改时，它就显得非常宝贵。

AWS Transfer Family

Transfer Family 提供完全托管的 SFTP、FTPS、FTP 和 AS2 端点，后端由 S3 或 EFS 支持。其价值主张在于保留面向合作伙伴的协议契约：那些只能通过 SFTP 发送文件的供应商系统可以保持原样继续运行，而接收端则是原生的 S3，从而可以利用生命周期策略、Lambda 触发器和分析集成。

这里的陷阱是想当然地认为遗留供应商可以“直接切换到 S3 API”。许多供应商系统是专用设备、医院的 HL7 数据流、银行的批处理系统，或是 B2B EDI 管道，它们的 SFTP 客户端被固化在固件或签名二进制文件中。对这些系统进行变更所涉及的变更管理、安全审查和重新认证的成本，往往超过了整个 AWS 迁移项目的费用。Transfer Family 完全规避了这个问题。AS2 支持还为 EDI 工作负载提供了 MDN 回执和消息签名/加密功能，以满足 B2B 合规性要求。

身份验证支持服务管理的用户、AWS Directory Service（托管的 Microsoft AD 或用于本地 AD 的 AD Connector），或通过 API Gateway/Lambda 实现的自定义身份提供商——从而允许现有的企业凭证继续作为信任的来源。Lambda 授权方可以为每个用户返回特定的 IAM 角色、主目录映射和会话策略，从而实现每个供应商之间的隔离，而无需为每个供应商部署独立的基础设施。

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow 是一个托管的集成层，用于将数据从 SaaS 移动到 AWS：支持将 Salesforce、ServiceNow、Google Analytics、Slack、Marketo、SAP OData、Zendesk 等几十种服务的数据流入 S3、Redshift 或 Snowflake。它能处理分页、增量提取、字段映射、筛选、脱敏和验证，无需手动编写 ETL 作业。

其安全关键特性是为支持的连接器（特别是 Salesforce）提供 PrivateLink 集成。数据流无需经由公共互联网访问 SaaS 租户再返回 AWS，而是通过一个私有的 VPC 端点进行传输——从而消除了提取的负载在公共互联网上的暴露风险，并简化了医疗、金融和 PII（个人身份信息）工作负载的审计态势。数据流可以按计划运行、由 SaaS 记录变更事件触发或按需运行，并且每次执行最多支持 100 GB 的数据量。

AppFlow 的运作层面高于 DataSync 或 Storage Gateway：当源是 API 驱动的 SaaS 而非文件系统或数据库时，AppFlow 是正确的工具。

数据库迁移：DMS 和 SCT

AWS Database Migration Service 可以在源数据库保持完全运行的情况下，将数据从源数据库复制到目标数据库。它支持同构（MySQL → RDS MySQL，Oracle → RDS Oracle）和异构（Oracle → Aurora PostgreSQL，SQL Server → MySQL）迁移，目标不仅限于 RDS，还包括 Aurora、Redshift、S3、DynamoDB 和 Kinesis。源数据库包括 Oracle、SQL Server、MySQL、PostgreSQL、MongoDB 和 Db2。

一个任务可以按以下三种模式之一运行：

实现最小停机时间切换的核心引擎是变更数据捕获 (Change Data Capture)。在“全量加载+CDC”模式下，DMS 会批量复制现有行，同时挖掘源数据库的事务日志——例如 Oracle 的 redo 日志、MySQL 的 binlog、SQL Server 的 MS-CDC 或 MS-Replication。一旦全量加载完成，CDC 会应用队列中的变更，并保持目标数据库持续更新，直到应用程序切换过去。当应用程序必须保持可写状态时，未能启用 CDC 是一个常见的架构错误：仅全量加载模式会在加载完成的那一刻就使目标数据变得陈旧。

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

对于异构迁移，AWS Schema Conversion Tool（或其云上版本 DMS Schema Conversion）可以转换 DDL、存储过程、视图和函数，并标记出需要手动重写的项目。DMS 负责迁移数据；SCT 负责转换模式。忽略 SCT 评估报告是导致迁移在切换前三天失败的常见原因。

如果忽略了特定于数据库引擎的前提条件和限制，后果会很严重。超过 64 KB 的 Oracle LOB 需要使用有固定最大值限制的 limited LOB mode；LONG RAW 类型也有一些注意事项。PostgreSQL 要求 wal_level=logical 并需要一个复制角色。MySQL 要求二进制日志为 ROW 格式，具有足够的 binlog_row_image 设置，并需要提升的 CDC 权限（REPLICATION CLIENT、REPLICATION SLAVE）。Oracle Spatial、RAC 特有的行为以及 SQL Server CLR 程序集通常不受支持。复制实例和端点之间强制执行 TLS，SSL 模式可以是 require、verify-ca 或 verify-full。

当工作负载特征不可预测或呈突发性时，DMS Serverless 是正确的选择——例如，一个本地 Oracle 系统，其负载在白天出现峰值，在夜间则很平静。您以 DCU（DMS 容量单位）为单位定义 MinCapacityUnits 和 MaxCapacityUnits，DMS 会根据 CPU 和内存压力来扩展复制容量：

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

一个常见的陷阱是认为预置的 DMS 实例（例如 dms.c5.4xlarge）会自动扩展。它不会——预置实例是固定大小的 EC2 主机。如果吞吐量超过容量，复制延迟会增加，您必须手动修改实例类并重启任务。预置型 DMS 适合吞吐量已知且稳定的迁移；无服务器型 DMS 适合不可预测的迁移。

对于一个有两周时间窗口和严格停机要求的 20 TB MySQL 迁移项目，使用 DMS 进行“全量加载+CDC”迁移到 Aurora MySQL 或 RDS MySQL 是最具成本效益的方案。使用原生的 mysqldump/mysqlpump 进行恢复会产生无法接受的停机时间；Snowball 会增加运输延迟和离线数据间隙。

DMS Fleet Advisor 可以发现本地的数据库清单，对于分批迁移规划非常有用。

服务器迁移：AWS Application Migration Service (MGN)

AWS Application Migration Service 是主要的直接迁移（“rehost”）服务，在大多数使用场景中已取代 CloudEndure Migration 和 Server Migration Service。MGN 在每个源服务器（物理、VMware、Hyper-V 或其他云）上安装一个轻量级的 AWS Replication Agent。该代理会执行一次初始的块级快照，存入目标 VPC 中的一个低成本暂存区（挂载了 EBS 卷的小型 T3 实例），然后异步地持续复制块级变更。由于复制是块级且持续的，切换过程以分钟计算：在切换时，MGN 会将暂存卷转换为目标实例类型的生产环境 EC2 实例。

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

测试启动至关重要，但常常被忽略。MGN 会从当前的复制状态启动隔离的测试实例，而不会中断正在进行的复制。您可以验证应用程序行为、丢弃测试、进行迭代，并仅在测试通过后才启动切换——切换会停止复制，启动最终实例，并将该迁移波次标记为完成。

错误的方法是手动将虚拟机导出为 OVF 格式，通过 aws ec2 import-image 上传，然后在全新预置的 EC2 实例上重新安装应用程序。这种方法速度慢、易出错、每个虚拟机都需要相当于导出时长的停机时间，不提供增量复制，也无法进行无中断测试。MGN 消除了所有这些问题——源服务器会一直运行到最终切换的那一秒，源和目标之间的偏差基本为零。

一般的组合策略指南是先进行 rehost（直接迁移），然后在迭代成本更低的 Region 内进行 re-platform（平台重构）或 refactor（重构）。同时进行重构和迁移会成倍增加风险，却没有相应的收益。

混合云连接：Direct Connect 和 VPN

AWS Direct Connect 提供一条从本地路由器到 Direct Connect 站点的专用第二层（Layer 2）线路，提供一致的带宽（1、10、100 Gbps 专用带宽；通过合作伙伴托管连接提供低于 1 Gbps 的带宽）和可预测的延迟。虚拟接口（Virtual Interface）对线路进行分区：

• 私有 VIF — 通过虚拟专用网关（Virtual Private Gateway）访问单个 VPC。
• 中转 VIF — 通过连接到 Transit Gateway 的 Direct Connect Gateway 访问多个 VPC。这是大型多 VPC、多站点环境的标准模式。
• 公有 VIF — 访问 AWS 公共服务端点（S3、DynamoDB），而无需经过互联网。

DX 本身并非高可用：单一 DX 站点的单一线路依赖于单一的光纤路径。两种弹性模式很重要：

1. DX + 通过互联网的 Site-to-Site VPN 备份是最低可行的高可用性（HA）方案。BGP 通过 AS-path prepending、MED 或 local-pref 来处理自动故障转移，以在稳定状态下优先选择 DX。
2. 在不同 DX 站点的双 DX 线路是任务关键型工作负载的最高弹性模式，并且是 DX 服务等级协议（SLA）的要求。

未配置任何备份路径是一个众所周知的陷阱：当 DX 发生故障且没有 VPN 时，混合云应用、DataSync 任务和 Storage Gateway 上传都会在运营商修复期间陷入停滞。对于吞吐量较低的工作负载，或者在 DX 部署期间（可能需要数周）作为过渡方案，纯 VPN 是可以接受的。

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

在强制要求物理层加密的情况下，选择支持 MACsec 的 DX 连接。结合使用 DX 以获得带宽、DataSync 进行编排以及 Storage Gateway 以维持本地访问，是处理无法容忍停机窗口的大型实时数据集的标准混合云模式。

用于本地 AWS 基础设施的 AWS Outposts

Outposts 以完全托管的机架（或 1U/2U Outposts 服务器）形式，将 AWS 基础设施延伸到客户的设施中。它在本地运行一组精选的服务——EC2、EBS、ECS、EKS、RDS、S3 on Outposts、EMR——并使用与父 Region 相同的 API。控制平面操作通过由冗余加密隧道组成的服务链路（service link）流回父 Region；广域网（WAN）中断会暂时阻止启动新实例，但不会停止正在运行的工作负载。

责任共担模型的划分是让运维人员掉入的陷阱。AWS 负责交付和维护硬件、虚拟机监控程序（hypervisor）和托管服务。客户负责：

• 满足 Outposts 规格的物理空间、电力、冷却和网络（冗余电源、上游交换机、合适的 PDU）。
• 设施的物理安全。
• 本地网络配置——用于本地流量的**本地网关（LGW）**和服务链路的上行链路。
• 工作负载的操作系统和应用问题，与在 Region 中完全相同。
• 到父 Region 的足够广域网连接。

Outposts 并没有消除运维工作，而是转移了抽象层。认为 AWS 负责数据中心的电力或上游网络是一种根本性的误解。它也不是“在本地运行任何 AWS 服务”：支持的服务列表是有限的，像 Route 53 或 IAM 这样的服务仍然是基于 Region 的。

对于因法规要求数据必须保留在本地的 Hadoop/Spark 现代化项目，EMR on Outposts 是正确的模式——它提供托管的、弹性的 Spark 集群，使用 Region 内的工具并实现本地数据驻留。Storage Gateway 或 DataSync 不满足数据驻留要求；直接迁移到 Region 内的 EMR 则不符合合规性。

向边缘设备群分发内容

当 Outposts 服务器、零售店或边缘设备需要重复拉取相同的大型负载（例如，夜间的软件发布版本）时，直接从单个区域的 S3 存储桶中拉取会使上行链路饱和并增加部署时间。正确的模式是使用 CloudFront，以 S3 为源站，并结合签名 URL：

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

某个区域中的第一台设备会预热边缘缓存；之后的每台设备都能以边缘延迟进行拉取。签名 URL 可以防止未经授权的下载，无需为每台设备配置 IAM 凭证，并且无需管理区域副本集群。

需要避免的两种反模式：将发布版本托管在单个 EC2 Web 服务器上（这是扩展性和延迟方面的灾难），以及仅仅为了降低下载延迟而通过跨区域复制 (Cross-Region Replication) 将 S3 存储桶复制到每个区域（这会带来不必要的存储成本和运维复杂性，而 CloudFront 缓存可以免费解决这个问题）。

决策摘要

← 存储与数据生命周期 · 所有领域 · 网络与连接 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →