Amazon SAA-C03: 資料傳輸與遷移 — 學習指南

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

屬於 AWS SAA-C03 — 完整學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

頻寬 vs. 實體運送的決策

每個遷移專案都始於算術。在選擇工具之前，先計算理論上的傳輸時間：

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 線路的佈建時間還要長。

一個合理的經驗法則：

在遷移情境中，最常見的錯誤答案就是選擇一個在數學上不可能在時間範圍內完成的 WAN 傳輸。其必然的陷阱——「我們只要每晚透過 WAN 執行它就好」——不僅僅是速度較慢而已。它會消耗生產環境的頻寬，有部分或損毀傳輸而需要重新上傳的風險，且一旦計入頻寬費用和工程師時間，通常成本更高。一個 Snowball 裝置的費用加上運費，是一個固定且可預測的費用項目。

用於離線大量傳輸的 Snow Family

Snowball Edge 裝置有兩種變體：

Snowcone 是小型規格（約 8 TB SSD）、堅固耐用且可透過快遞運送的裝置，適用於空間有限的站點，並預載了 DataSync 代理程式以進行邊緣同步。Snowmobile——一個可運載高達 100 PB 的 45 英尺貨櫃——目標是 EB 等級的資料中心撤離，但在大多數區域已被淘汰，改用平行的 Snowball Edge 裝置群。對於任何小於 PB 等級的資料量選擇 Snowmobile，都是一個干擾選項。

Compute 變體不僅僅是個更大的硬碟。它可以在本機執行 EC2 AMI、Lambda 函數和 Greengrass 工作負載，這使得當資料在擷取前必須進行轉換、篩選或移除個人識別資訊 (PII) 時，它成為正確的選擇；當工作負載在擷取後必須立即在 AWS 中恢復運作時；或者當站點處於離線或間歇性連線狀態時（例如船隻、遠端採礦、戰術部署、遠端研究）。當需要裝置上處理時，選擇 Compute Optimized；當工作負載是純粹的大量複製時，選擇 Storage Optimized。

每個 Snow 裝置都使用永不離開 AWS 的 KMS 金鑰，對靜態資料執行 256 位元加密。其外殼具有防竄改設計，配備 E Ink 電子墨水運送標籤和硬體信賴平台模組 (Trusted Platform Module)。裝置上的資料是透過 Snowball 用戶端、與 S3 相容的端點或 NFS 掛載點寫入的；TLS 在擷取和運送清單交換期間保護傳輸中的資料。裝置歸還後，內容會被擷取到 S3，然後裝置會根據 NIST 800-88 標準進行加密清除。

對於每個站點達 PB 等級的工作，平行作業是標準模式。一個擁有 1–2 Gbps 鏈路容量的辦公室，仍需要數個月的持續滿載才能在線上移動 1 PB；而每個站點約 13 個 Storage Optimized 裝置（每個 80 TB）的裝置群平行運送，則可以在四週的期限內完成，同時不佔用辦公室的網際網路鏈路。對於一個在 100 Mbps 滿載鏈路上、期限為兩週的 600 TB 工作，一個小型的平行裝置群是唯一正確的答案——即使不考慮成本，物理定律也使得 DataSync 或新的 Direct Connect 變得不可能。

DataSync：用於線上、已驗證、增量式傳輸

當頻寬充足，但工作負載的特性——例如數百萬個小檔案、深層的目錄樹、持續的增量同步，或跨檔案系統的遷移——會讓天真的工具癱瘓時，DataSync 就是正確的工具。一個包含 2000 萬個 4 KB 檔案的目錄若使用 aws s3 cp 來複製，瓶頸會是來回延遲，而不是吞吐量；每個 PutObject 都會產生一次 TLS/HTTP 的來回傳輸和一次 API 請求費用。將檔案打包成壓縮檔雖可行，但會喪失對單一檔案的定址能力。DataSync 的代理程式 (agent) 會跨多個 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 介面端點，以避免使用公用網際網路。

一個關鍵細節：DataSync 對於本地端的 NFS/SMB 來源需要一個代理程式 (agent)。此代理程式以 VM 的形式在 VMware、Hyper-V 或 KVM 上執行、在 EC2 上執行，或在 Snowcone 上執行。認為 DataSync 對於本地端是無代理程式 (agentless) 的，這是一個常見的陷阱——只有當兩個端點都是 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 上，當使用者持續讀寫時，排程重複性任務是標準模式：初始的全面掃描會傳輸大部分資料，後續的增量執行會捕捉差異量 (delta)，即使在部分利用率下，也能在遠少於一週的時間內完成 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 也不會向本地端用戶端呈現一個持續性的共用。

File Gateway 是主力。寫入 \\gateway\share\reports\2024\report.pdf 會產生 s3://bucket/reports/2024/report.pdf——可由 Athena、Lambda、EMR 或任何 S3 用戶端原生取用。這種一對一的檔案對物件對應關係，是相較於黑箱備份目標的一大優勢。本地快取意味著熱門檔案以區域網路 (LAN) 速度回傳；冷門檔案則依需求從 S3 串流傳輸。

快取是此設備的重點。熱門資料的讀取由本地提供；寫入會先存到本地磁碟，然後再非同步上傳。一個常見的設計錯誤是假設由 S3 支援就意味著每次讀取都會產生網際網路的來回延遲——其實不然，前提是工作集能容納於快取中。反之，快取空間過小會導致持續的快取未命中 (cache miss)，工作負載會顯得「很慢」。經驗法則：快取大小 = 總資料集的 20% 或熱門工作集的 100%，取其較大者。

快取模式 vs. 儲存模式的陷阱值得特別注意。快取模式將主要複本保存在 S3，熱門區塊則在本地——便宜、有彈性，但一次快取未命中就是一次廣域網路 (WAN) 的來回傳輸。儲存模式將主要複本保存在本地磁碟，並以 EBS 快照的形式非同步快照至 S3——每次讀取都是本地且低延遲的，但整個資料集必須能容納於本地端。對於「在資料備份到 AWS 的同時，仍需在本地存取所有資料」這樣的備份替代需求，儲存模式是正確的；快取模式則會違反此需求。為需要整個資料集低延遲的工作負載選擇快取模式，會違背設計初衷；當站點無法容納完整資料集時，選擇儲存模式根本是不可能的。

Tape Gateway 回應了一個非常具體的需求：汰換實體磁帶櫃，同時透過 iSCSI 呈現一個 VTL (虛擬磁帶櫃)，讓 Veeam、NetBackup 或 Commvault 的工作流程保持不變，並讓資料從 S3 依生命週期規則移轉到 Glacier 或 Deep Archive。當法規保留要求是以磁帶媒體來定義，且現有的備份軟體無法變更時，它就顯得非常寶貴。

AWS Transfer Family

Transfer Family 提供由 S3 或 EFS 支援的全託管 SFTP、FTPS、FTP 與 AS2 端點。其價值主張在於維護與合作夥伴之間的協定合約：那些只能透過 SFTP 傳送檔案的供應商系統可以維持原樣，而接收端則是原生的 S3——具備生命週期政策、Lambda 觸發器與分析整合等功能。

這裡的陷阱是假設舊有供應商可以「直接改用 S3 API」。許多供應商系統是應用裝置、醫院 HL7 資訊流、銀行批次處理系統或 B2B EDI 管道，其 SFTP 客戶端是寫死在韌體或簽署的二進位檔中。對這些系統進行變更所涉及的變更管理、安全審查與重新認證的成本，往往超過整個 AWS 遷移的費用。Transfer Family 完全避開了這個問題。此外，AS2 支援還能啟用具備 MDN 回條以及訊息簽署/加密的 EDI 工作負載，以符合 B2B 合規性要求。

身份驗證支援服務託管的使用者、AWS Directory Service (Managed 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，而非檔案系統或資料庫時，它才是正確的工具。

資料庫遷移：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 適合吞吐量已知的穩定狀態遷移；Serverless 則適合無法預測的遷移。

對於一個需要在兩週時間內完成且停機時間非常緊湊的 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 中一個低成本的準備區 (staging area) — 由小型的 T3 執行個體和掛載的 EBS 磁碟區組成 — 然後以非同步方式持續複製區塊層級的變更。因為複製是區塊層級且持續不斷的，所以切換（cutover）時間是以分鐘計算：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 會從目前的複製狀態啟動隔離的測試執行個體，而不會中斷正在進行的複製。您可以驗證應用程式行為、捨棄測試、反覆進行，並只在測試通過後才啟動切換 — 切換會停止複製、啟動最終的執行個體，並將該遷移波次標記為完成。

錯誤的方法是手動將 VM 匯出為 OVF 格式，透過 aws ec2 import-image 上傳，然後在全新佈建的 EC2 執行個體上重新安裝應用程式。這種方式緩慢、容易出錯、每個 VM 的停機時間等於匯出所需時間、不提供差異複製，也無法進行非中斷性測試。MGN 消除了所有這些問題 — 來源伺服器會一直運行到最後切換的那一秒，來源和目標之間的差異基本上為零。

一般的組合策略指導方針是先 rehost，然後在 Region 內進行 re-platform 或 refactor，因為在 Region 內反覆修改的成本較低。同時進行重構和遷移會倍增風險，卻沒有相應的好處。

混合雲連線：Direct Connect 和 VPN

AWS Direct Connect 提供從本地端路由器到 Direct Connect 位置的專用 Layer 2 線路，提供一致的頻寬（1、10、100 Gbps 專用線路；透過合作夥伴託管的連線提供低於 1 Gbps 的頻寬）和可預測的延遲。虛擬介面（Virtual Interfaces）將線路進行分割：

• Private VIF — 透過 Virtual Private Gateway 存取單一 VPC。
• Transit VIF — 透過連接到 Transit Gateway 的 Direct Connect Gateway 存取多個 VPC。這是大型、多 VPC、多站點環境的標準模式。
• Public VIF — 存取 AWS 公共服務端點（S3、DynamoDB），而無需經過網際網路。

DX 本身並不具備高可用性：單一 DX 位置的單一線路依賴於單一的光纖路徑。兩種彈性模式很重要：

1. DX + 透過網際網路的 Site-to-Site VPN 備援 是最低可行的高可用性方案。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 將 AWS 基礎設施以全託管機櫃（或 1U/2U Outposts 伺服器）的形式延伸到客戶的設施中。它在本地端運行一組精選的服務 — EC2、EBS、ECS、EKS、RDS、S3 on Outposts、EMR — 並使用與其父 Region 相同的 API。控制平面操作會透過由備援加密通道組成的服務連結 (service link) 回傳到父 Region；廣域網路中斷會暫時阻止啟動新的執行個體，但不會停止正在運行的工作負載。

責任共擔模式的分界 是讓維運人員掉入的陷阱。AWS 負責交付和維護硬體、虛擬化層 (hypervisor) 和託管服務。客戶負責：

• 符合 Outposts 規格的實體空間、電力、冷卻和網路（備援電源、上游交換器、合適的 PDU）。
• 設施的實體安全。
• 本地網路設定 — 用於本地流量的 Local Gateway (LGW) 和服務連結的上行鏈路。
• 工作負載的作業系統和應用程式問題，與在 Region 中完全相同。
• 回到父 Region 的足夠的廣域網路連線。

Outposts 並沒有消除維運工作 — 它只是轉移了抽象層。假設 AWS 負責資料中心的電力或上游網路是一個根本性的誤解。它也不是「在本地端運行任何 AWS 服務」：支援的服務清單是有限的，像 Route 53 或 IAM 這樣的服務仍然是基於 Region 的。

對於因法規要求資料必須保留在本地的 Hadoop/Spark 現代化專案，EMR on Outposts 是正確的模式 — 託管的、彈性的 Spark 叢集，具備 Region 內的工具集和本地資料駐留性。Storage Gateway 或 DataSync 無法滿足資料駐留要求；直接遷移到 Region 內的 EMR 則無法滿足合規性。

將內容分發到邊緣機群

當 Outposts 伺服器、零售店或邊緣裝置重複地拉取相同的大型負載（例如，每晚的軟體發布）時，直接從單一 Region 的 S3 儲存貯體拉取會使上行鏈路飽和並拉長部署時間。正確的模式是使用 CloudFront 搭配 S3 origin 和 signed URLs：

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

某個區域中的第一台裝置會預熱邊緣快取；之後的每台裝置都以邊緣延遲的速度拉取。Signed URLs 可防止未經授權的下載，無需為每台裝置設定 IAM 憑證，而且也無需管理區域性的複本機群。

有兩種應避免的反面模式：將發布版本託管在單一 EC2 網頁伺服器上（這是一場擴展性和延遲的災難），以及為了降低下載延遲而透過 Cross-Region Replication 將 S3 儲存貯體複製到每個 Region（這會帶來不必要的儲存成本和操作複雜性，而 CloudFront 快取可以免費解決這些問題）。

決策摘要

← 儲存與資料生命週期 · 所有領域 · 網路與連線 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →