Amazon S3 與應用程式快取

S3 與應用程式快取是 DVA-C02 中開發者導向的最大考點，橫跨 Domain 1（使用 AWS 服務開發）、Domain 2（安全性）與 Domain 3（部署），幾乎每一場考試都會從中出 8 到 12 題。不同於 CLF-C02 的 S3 考點（重點是「S3 是什麼」），DVA-C02 的 S3 與應用程式快取考的是開發者如何將 S3、Amazon ElastiCache 與 Amazon CloudFront 串接進實際應用程式：如何可靠地上傳一支 20 GB 的影片、如何在不暴露 IAM 金鑰的情況下給瀏覽器一個臨時上傳網址、如何在 Auto Scaling group 跨機器保持登入 session，以及如何砍掉讀取路徑上 200 ms 的延遲。

本學習筆記完整涵蓋 S3 與應用程式快取的開發者面向——從分段上傳的門檻到 cache-aside 與 write-through 的差異，從 CloudFront 簽名網址到用 Redis 外部化 session 狀態。每個章節都指出 SDK 行為、失敗情境與考試陷阱。從頭讀到尾，「開發者工具箱」類的題目就會變成送分題。

什麼是 S3 與應用程式快取？

S3 與應用程式快取是把三個 AWS 服務綁進單一應用程式設計模式的總括概念：

• Amazon S3 — 物件儲存，應用程式用來存放使用者上傳、靜態資源、匯出檔案、備份、日誌與資料湖輸入。
• Amazon ElastiCache — 託管 Redis 或 Memcached，作為資料庫查詢結果、session 狀態、排行榜與 pub/sub 的低延遲記憶體快取。
• Amazon CloudFront — 全球 CDN，在邊緣節點快取 S3 物件與 API 回應。

DVA-C02 問到 S3 與應用程式快取時，真正的問題是：「給定這個讀寫模式，你該選哪種儲存加快取組合？」正確答案幾乎都是：S3 作為持久來源（durable origin）、ElastiCache 或 DynamoDB 作為熱層，CloudFront 做邊緣分發。將 S3 與應用程式快取理解為一個分層堆疊——持久來源、記憶體快取、邊緣快取——是考試獎勵的心智模型。

白話文解釋

用三個類比來拆解 S3 與應用程式快取，幫助各部分更容易記憶。

類比一：中央廚房、備料檯與便利商店

想像一間連鎖餐飲集團。位於郊區的中央倉庫冷凍庫是 Amazon S3：每一樣食材（物件）都安全保存在那裡，但每次去拿都要花時間。主廚旁邊的備料檯是 Amazon ElastiCache：本週最常用的 200 樣食材就放在伸手可及的地方，要什麼馬上拿到。散布在社區各處的便利商店是 Amazon CloudFront 邊緣節點：把最熱門的商品預先擺在離消費者最近的地方，住在三條街外的客人不必跑去中央倉庫就能拿到暢銷品。

在這個類比裡，「S3 與應用程式快取」就是把應用程式設計成：第一次讀取先去便利商店，沒有才走回備料檯，備料檯也沒有才開車去倉庫。**快取未命中（cache miss）**就是倉庫之旅——花錢、費時，但保證找得到東西。

類比二：餐廳廚房

餐廳就是你的應用程式。後場冷凍庫是 S3——保存餐廳採購過的所有食材，冷凍保鮮，但廚師每次都要走進去拿。爐台旁的備料盤是 ElastiCache——廚師把切好的蔥、磨好的起司、熱湯底就放在手邊，因為晚餐尖峰時段不能讓每道菜都去冷凍庫一趟。餐桌上的麵包籃是 CloudFront——麵包已經放在桌上，客人不必開口。

Cache-aside 模式是「廚師只有在備料盤空了時才補貨」。Write-through 是「每次採購新食材，立刻把一份分量放進備料盤」。Write-behind 是「廚師在便條紙上記下新食材，稍後才更新冷凍庫庫存」。

類比三：工具間與工作台抽屜

木工師傅的工具間是 S3——他擁有的每一樣工具都放在那裡。工作台旁的抽屜是 ElastiCache——每分鐘都用到的五樣工具放在抽屜裡隨手可得。圍裙口袋是程序內快取或 CloudFront——正在使用的那一樣工具已經在手上了。S3 與應用程式快取就是在決定哪樣工具放在哪一層，以及工具可以多舊才需要換掉。

重點只有一個：快取的本質永遠是把資料複製到離消費者更近的地方，每一層都有自己的過期時間與失效合約。DVA-C02 很喜歡出需要你指出正確層級與一致性模型的情境題。

S3 的開發者視角——進階基礎

DVA-C02 對開發者的 S3 考點不是「物件儲存概論」，考試要確認你能把 S3 整合進應用程式——正確使用 SDK、預簽名網址、處理大型上傳、安全地啟用版本控制、讓邊緣快取失效，以及把事件通知接進下游運算。

開發者必知的 S3 API 基本操作

每一道 DVA-C02 S3 題目都假設你能把主控台操作對應到 SDK 呼叫。核心 API 動詞：

• PutObject / GetObject / DeleteObject / HeadObject
• CreateMultipartUpload / UploadPart / CompleteMultipartUpload / AbortMultipartUpload
• GeneratePresignedUrl（SDK 端）→ 產生含時效性簽名的 HTTPS 網址
• CopyObject（伺服器端，單次呼叫上限 5 GB；更大的物件需要分段複製）
• SelectObjectContent（S3 Select）
• PutObjectAcl / PutBucketPolicy / PutBucketCors / PutBucketVersioning / PutBucketLifecycleConfiguration
• PutBucketNotificationConfiguration（事件通知）

這些操作底層都使用 Signature Version 4（SigV4），這也是為什麼複製一個請求五分鐘後仍然失敗——簽名有時效限制。

S3 請求速率與前綴分片

S3 每個前綴（prefix）至少支援 每秒 3,500 次 PUT/COPY/POST/DELETE 請求，以及每秒 5,500 次 GET/HEAD 請求。如果應用程式超過每個前綴的速率上限，就要把物件鍵分散到多個前綴（例如 logs/2026/04/20/shard=0/…、shard=1/…）。這是 DVA-C02 最愛的陷阱之一，因為考生常忘了 S3 是按前綴擴展，而非按儲存貯體（bucket）擴展。

S3 分段上傳——門檻與 SDK 自動行為

S3 分段上傳（multipart upload）是開發者可靠推送大型物件的方法。不是送一個 5 GB 的大塊，而是把它拆成多個分段，平行上傳，再請 S3 重新組合。

S3 分段上傳硬性規定

• 使用分段上傳的最小物件：任何物件皆可，但 AWS 建議大於 100 MB 的物件使用分段上傳。
• 物件超過 5 GB 時強制使用——PutObject 硬性上限為 5 GB。
• 物件最大尺寸：5 TB。
• 每個分段大小：最小 5 MB（最後一段除外），每段最大 5 GB，最多 10,000 段。
• 各分段可平行上傳並獨立重試。
• 未完成的分段上傳會持續佔用儲存空間，直到中止為止——因此一定要設定生命週期規則來清除。

開發者必知的 SDK 自動行為

高階 AWS SDK 傳輸管理器（例如 Java 的 TransferManager、boto3 s3.transfer 的 Upload、JavaScript v3 的 @aws-sdk/lib-storage Upload 類別）會在物件大於 SDK 定義的門檻（通常是 8 MB 或 16 MB，可設定）時自動切換為分段上傳，並平行化各分段，同時透明地重試失敗的分段。

如果考題說「應用程式使用預設 SDK 傳輸管理器上傳一支 2 GB 的影片」，正確假設是：分段上傳是自動的，開發者不需要逐段撰寫程式碼。

S3 預簽名網址與政策

S3 預簽名網址讓應用程式可以把對特定物件的短期存取權委派給匿名用戶端（通常是瀏覽器或行動 App），而不必暴露 IAM 憑證。

S3 預簽名網址的運作方式

1. 後端持有允許 s3:PutObject 或 s3:GetObject 的 IAM 角色或憑證。
2. 後端在 SDK 中呼叫 GeneratePresignedUrl，帶入動詞（GET、PUT）、儲存貯體/鍵，以及有效期限（SigV4 最長 7 天；若使用 Lambda 執行角色憑證，因為臨時 session 時效，最長為 1 小時）。
3. SDK 回傳一個 HTTPS 網址，簽名以 query parameter 的形式附在網址中。
4. 用戶端直接以該網址對 S3 端點執行 HTTP 動詞。S3 端點驗證簽名與有效期限。

預簽名網址 vs 儲存貯體政策 vs IAM

• 預簽名網址 — 暫時性，僅限單一物件加單一動詞。使用簽名主體的權限。
• 儲存貯體政策 — 資源型，套用到所有存取該儲存貯體的請求。用於跨帳號或公開讀取。
• IAM 政策 — 身分型，套用到發出請求的使用者/角色。

預簽名網址無法授予簽名者本身沒有的權限。如果後端角色缺少 s3:PutObject，用預簽名的 PUT 網址一樣沒用。

瀏覽器上傳用的 S3 Presigned POST

GeneratePresignedPost 產生表單欄位，讓瀏覽器的 <form method="POST" enctype="multipart/form-data"> 可以直接 POST 到 S3。你可以用政策文件限制大小、Content-Type 與鍵前綴。對於純粹「瀏覽器上傳檔案到 S3」的情境，presigned POST 通常是最乾淨的選擇。

S3 版本控制

S3 版本控制把你的儲存貯體變成一個只增不減的歷史紀錄。每次對同一個鍵執行 PutObject，都會建立一個新版本（帶有唯一的 versionId），而不是覆寫原本的物件。不帶 versionId 的 DeleteObject 會插入一個刪除標記（delete marker），但舊版本仍然保留。

版本控制狀態

• 未啟用（預設）— 沒有版本 ID。
• 已啟用版本控制 — 每次寫入都建立新版本。
• 已暫停版本控制 — 現有版本保留，新寫入的物件 versionId=null。

一旦啟用版本控制就無法回到未啟用狀態，只能暫停。可搭配 MFA Delete 對刪除操作加上寫入保護。

S3 版本控制對開發者的影響

• 讀取最新版本是透明的（GetObject 不帶 versionId）。
• 讀取特定歷史版本需要帶 versionId 參數。
• 生命週期規則可以讓非當前版本過期（例如「刪除 90 天以上的舊版本」）。
• CRR/SRR 需要來源與目的儲存貯體都啟用版本控制。

S3 生命週期規則

S3 生命週期規則可自動化儲存類別之間的轉換與物件過期作業。DVA-C02 預期你能把業務規則寫成生命週期政策 JSON。

生命週期動作

• Transition（轉換） — 把物件移至較便宜的類別（例如 Standard → Standard-IA → Glacier Flexible Retrieval）。
• Expiration（過期） — 在 N 天後永久刪除物件。
• 非當前版本轉換／過期 — 在有版本控制的儲存貯體中，針對舊版本的獨立設定。
• 中止未完成的分段上傳 — 必設的規則。

篩選條件

規則可依以下條件篩選：

• 前綴（logs/2026/）
• 標籤（tag:Classification=Archive）
• 物件大小（>128 KB，避免 Standard-IA 最小物件大小加收費用）

S3 事件通知到 Lambda、SQS、SNS 與 EventBridge

S3 事件通知是開發者把 S3 儲存貯體變成事件來源的方式。新物件上傳可以觸發 Lambda 函數產生縮圖、推送訊息到 SQS 進行批次處理，或發布到 SNS 做扇形傳播。

開發者常用的 S3 事件類型

• s3:ObjectCreated:*（以及個別動詞變體 Put、Post、Copy、CompleteMultipartUpload）
• s3:ObjectRemoved:*（Delete、DeleteMarkerCreated）
• s3:ObjectRestore:*（Glacier 還原完成）
• s3:Replication:*
• s3:LifecycleTransition、s3:LifecycleExpiration
• s3:ObjectTagging:*

傳送目標

原生通知 vs EventBridge

原生 S3 通知直接傳送到 Lambda/SQS/SNS，設定較簡單，但舊版設定對同一事件類型有單一目標的限制（新版已支援多個目標）。Amazon EventBridge 提供基於內容的篩選、封存/重播、跨帳號路由與單一事件匯流排模型——代價是略高的延遲。

事件傳送語意

• 傳送是至少一次（at-least-once），不是恰好一次。你的 Lambda 必須是冪等的。
• 通知是盡力而為的最終一致性——通常在幾秒內完成。
• 對於 Lambda，事件酬載帶有一個 records 陣列。請處理所有記錄，不要只處理 Records[0]。

S3 Select——就地查詢

S3 Select 讓你對單一物件（CSV、JSON 或 Parquet）執行 SQL SELECT，只回傳符合條件的列/欄，而不需要下載整個物件。這是開發者的「輕量級分析」工具。

S3 Select 的適用時機

• 物件很大（數百 MB 到 GB 級別），但你只需要其中一小部分。
• 格式是結構化的（CSV/JSON/Parquet）。
• 查詢很簡單（篩選加投影）——沒有 join、沒有需要跨多個物件的聚合。

與 Athena（使用完整 SQL 引擎掃描多個物件）和 Redshift Spectrum（資料倉儲規模）相比，S3 Select 是單一物件操作，對於窄幅投影而言成本低廉許多。

S3 Select API 呼叫

SELECT s.user_id, s.event
FROM S3Object s
WHERE s.event = 'purchase'

SDK 回傳一個串流 EventStream 的記錄。你為掃描的資料量與回傳的資料量付費。

S3 Transfer Acceleration

S3 Transfer Acceleration 透過把流量導向最近的 Amazon CloudFront 邊緣節點，再走 AWS 骨幹網路，而不是從公共網路一路連到儲存貯體所在的 Region，來加速來自全球分散用戶端的上傳速度。

重要事項

• 按儲存貯體啟用（PutBucketAccelerateConfiguration）。
• 透過 bucketname.s3-accelerate.amazonaws.com 端點存取。
• 在正常 S3 資料傳輸費用之上，每 GB 額外收費。
• 適用於用戶端距離儲存貯體 Region 較遠（例如亞洲用戶上傳到 us-east-1），且物件至少有數十 MB 的情況。
• AWS 提供 Transfer Acceleration Speed Comparison 工具，可驗證你特定地理位置的效益。

如果考題情境是「全球用戶上傳大型檔案到一個中央儲存貯體，且上傳時間無法接受」，Transfer Acceleration 幾乎一定是答案。

S3 CORS——跨來源資源共享

S3 CORS 是讓從 https://app.example.com 提供的瀏覽器能向 https://my-bucket.s3.amazonaws.com 發出 PUT 或 GET 請求的設定。沒有 CORS，瀏覽器會以 No 'Access-Control-Allow-Origin' header 錯誤封鎖請求。

CORS 設定結構

[
  {
    "AllowedOrigins": ["https://app.example.com"],
    "AllowedMethods": ["GET", "PUT", "POST"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

用 PutBucketCors 設定。開發者常踩的坑：

• 混淆 CORS 與儲存貯體政策 — CORS 是關於瀏覽器的，儲存貯體政策是關於授權的。通常兩個都要設。
• 忘記 ExposeHeaders: ETag — 分段上傳需要瀏覽器讀取每個分段的 ETag。
• 在生產環境使用萬用字元來源 — AllowedOrigins: ["*"] 可用，但等於把儲存貯體開放給網路上的每個網站。

S3 Object Lock

S3 Object Lock 是合規工作負載的 WORM（一寫多讀）保留機制。一旦你對某個物件版本設定保留期限，S3 在期限到期前就拒絕刪除或覆寫該版本——即使帳號 root 也無法移除它。

保留模式

• Governance 模式 — 具有 s3:BypassGovernanceRetention 權限的使用者仍然可以刪除。適合內部防護欄。
• Compliance 模式 — 任何人都無法刪除，包含 root。真正的不可變。
• Legal hold — 布林值旗標，無到期日，可獨立切換。

Object Lock 需要啟用版本控制，且必須在建立儲存貯體時開啟（或之後透過 Support ticket）。這是考試「SEC 17a-4 / HIPAA / FINRA WORM 儲存，不需要自行維護磁帶設備」情境的標準答案。

ElastiCache Redis 與 Memcached 的應用程式快取比較

Amazon ElastiCache 提供兩種引擎：Redis 與 Memcached。DVA-C02 很喜歡問哪個適合特定情境。選擇原則：

• 選 Redis，當你需要以下任何一個特性：持久化、複製、高可用性（Multi-AZ）、pub/sub、streams、地理空間查詢、有序集合、交易，或複雜資料型別。
• 選 Memcached，當你只需要簡單的多執行緒鍵值快取，並且要透過跨多個節點的分片來水平擴展。

功能比較表

Redis 持久化與高可用性

Redis 提供兩種持久化機制：

• RDB 快照 — 定期的時間點二進位轉儲。ElastiCache 可排程自動快照到 S3。
• AOF（Append-Only File） — 每次寫入都附加到日誌；重啟時重播。ElastiCache 預設不啟用，且在很大程度上已被 Multi-AZ 副本取代。

ElastiCache for Redis 的高可用性架構是主節點加副本，跨 AZ 自動容錯移轉。主節點故障時，副本在幾秒內被提升，叢集 DNS 端點同步更新。

Redis Streams 與 Pub/Sub

• Pub/Sub — 即丟即忘的頻道，無持久化，無消費者群組。
• Streams — 帶有消費者群組的只增日誌，類似小型 Kafka。適合在應用程式內部做輕量級事件串流。

Memcached 的優勢

• 多執行緒 — 單一節點可使用所有 CPU 核心，而單節點 Redis 每次只用一個核心。
• 操作更簡單 — 無持久化、無複製、無容錯移轉需要調整。
• 透過新增節點擴展 — 用戶端函式庫以一致性雜湊把鍵分散到節點池。

S3 與應用程式快取的快取模式

快取模式定義了你的應用程式在快取路徑上如何讀寫。DVA-C02 測驗四種經典模式。

Cache-Aside（延遲載入）

應用程式自己掌控快取邏輯。讀取時：

1. 在快取中查詢這個鍵。
2. 如果命中（hit），回傳快取值。
3. 如果未命中（miss），從資料庫讀取，填入快取，再回傳值。

寫入時，應用程式更新資料庫，並使快取鍵失效或更新。

優點：

• 只有被請求的資料才會被快取——記憶體使用效率高。
• 快取失敗不影響寫入路徑。

缺點：

• miss 後第一次讀取很慢（三個跳點：快取未命中、資料庫讀取、快取寫入）。
• 如果寫入路徑忘記失效，會有舊資料問題。

Cache-aside 是 S3 與應用程式快取的預設模式。不確定時就選它。

Write-Through

應用程式同時寫入快取與資料庫，把快取當成後續讀取的事實來源。

1. 寫入快取。
2. 快取寫穿到資料庫（或應用程式依序執行兩次寫入）。
3. 讀取的資料永遠是快取中的新鮮版本。

優點：

• 沒有舊資料；快取永遠與資料庫一致。
• 讀取延遲可預期。

缺點：

• 寫入延遲增加（兩次寫入）。
• 快取中可能充斥著永遠不會再被讀取的資料。

Write-Behind（Write-Back）

應用程式寫入快取；快取非同步地在稍後刷新到資料庫。

優點：

• 應用程式的寫入延遲最低。
• 平滑突發的寫入負載。

缺點：

• 資料遺失風險——若快取節點在刷新前故障。
• 一致性複雜；除非情境明確優先考慮寫入速度且可以接受遺失，否則很少是 DVA-C02 的答案。

基於 TTL 的過期

每個快取項目都帶有存活時間（TTL）。TTL 到期後，快取驅逐該項目；下一次讀取透過 cache-aside 觸發新的載入。

優點：

• 有界的資料舊度——你知道最壞情況。
• 自我修復——錯誤資料最終會老化失效。

缺點：

• TTL 太短降低命中率；TTL 太長增加資料舊度。

與任何其他模式搭配使用 TTL。在 ElastiCache Redis 中，SET key value EX 300 以一個指令設定 300 秒的 TTL。

快取失效策略

快取失效是電腦科學中兩個最難問題之一。S3 與應用程式快取的實用策略如下：

1. 基於 TTL 的失效

讓快取自行讓項目到期。簡單、有界的資料舊度、不需要額外程式碼——但在 TTL 視窗內錯誤資料會持續存在。

2. 寫入時明確刪除

每次寫入系統紀錄（DynamoDB、RDS、S3）時，刪除對應的快取鍵。即時一致性，但你必須觸及每一個寫入路徑。

3. Write-Through 更新

寫入時在同一個操作中更新快取。以較慢的寫入換取一致性保證。

4. 版本化鍵

在快取鍵中嵌入版本後綴（user:42:v17）。要失效時，遞增版本號；舊項目自然透過 LRU 驅逐消失。當你無法列舉所有相依的鍵時很有用。

5. 事件驅動失效

把資料庫串流（DynamoDB Streams、RDS 變更事件）或 S3 事件通知接到一個 Lambda 函數，由它刪除對應的快取鍵。把失效與寫入路徑解耦。

CloudFront 失效

CloudFront 在邊緣快取物件，所以失效有自己的工具：

• 建立失效請求（CreateInvalidation API），帶入路徑模式如 /images/product-42.jpg 或 /*。超過小額免費額度的失效請求需要付費，且需要數分鐘才能傳播完成。
• 版本化檔名 — 發布 product-42.v17.jpg 而非失效舊檔。這是業界首選模式，因為免費且即時生效。
• Cache-Control 標頭 — 在來源回應上設定合理的 max-age，避免過度依賴失效機制。

CloudFront 作為應用程式層 CDN

Amazon CloudFront 是 S3 與應用程式快取中的邊緣快取層。開發者把 CloudFront 放在 S3 前面（靜態資源）、放在 API Gateway 或 ALB 前面（動態 API），或放在 Lambda 函數 URL 前面。

開發者必知的 CloudFront 核心概念

• Distribution（分發） — CloudFront 的頂層物件；帶有 d123.cloudfront.net 這樣的域名。
• Origin（來源） — 後端（S3 儲存貯體、自訂 HTTP 來源、Lambda 函數 URL）。
• Behavior（行為） — 把請求對應到來源與快取政策的路徑模式規則（/images/* → S3 來源，/api/* → API Gateway 來源）。
• Cache policy（快取政策） — 控制什麼構成快取鍵（標頭、cookie、query string）以及 TTL。
• Origin request policy（來源請求政策） — 控制什麼被轉送到來源。
• Response headers policy（回應標頭政策） — 讓你注入 CORS、安全標頭，而不需要修改來源。

CloudFront 加 S3 的模式

• Origin Access Control（OAC） — 現代的方式，鎖定 S3 儲存貯體讓只有 CloudFront 能讀取。取代舊版的 Origin Access Identity（OAI）。
• Signed URLs / Signed Cookies — 限制 CloudFront 分發的存取權給已驗證用戶。Signed cookies 一次涵蓋多個檔案；signed URLs 涵蓋單一檔案。
• Field-Level Encryption — 在邊緣加密 POST 酬載中的特定欄位。
• Lambda@Edge / CloudFront Functions — 在邊緣執行程式碼，用於驗證、標頭操作、A/B 測試、URL 重寫。

快取鍵與命中率

每個請求都被雜湊成一個快取鍵，由 URL 加上你在快取政策中宣告的標頭/cookie/query string 組成。快取鍵的輸入越少，命中率越高。常見的錯誤是把所有標頭（包含 User-Agent）轉送到來源，這實際上讓每個請求都是唯一的，完全破壞了快取。

Session 狀態外部化

Session 狀態外部化是 S3 與應用程式快取中觸及應用程式擴展的部分。有狀態的 Web 應用程式把使用者的登入狀態、購物車與流程狀態保存在伺服器記憶體中——一旦放到 Auto Scaling group 或負載平衡器後面，這個做法就會失效。

DVA-C02 測驗的三個選項

1. 負載平衡器上的 Sticky session — Application Load Balancer 可以用 cookie 把用戶端固定到同一個目標。伺服器端程式碼保持簡單，但縮放事件與不健康的目標會丟失 session。
2. Amazon DynamoDB — 把 session 資料存在啟用 TTL 的資料表中；每個請求讀寫 session。持久、可跨 Region（搭配 Global Tables），但延遲是個位數毫秒，而非微秒。
3. Amazon ElastiCache for Redis — 把 session 資料存在 Redis 中並設定過期時間。微秒延遲，支援 Multi-AZ 容錯移轉，是高流量 Web 應用程式的參考架構。

決策矩陣

DVA-C02 通常把 session 狀態外部化框架成擴展問題：「Auto Scaling 終止執行個體時，使用者回報被登出。」正確做法是停止依賴本地記憶體，把 session 外部化——通常到 Redis 或 DynamoDB。

Redis 的 Session 範例模式

• 鍵：session:<sessionId>
• 值：JSON 編碼的使用者情境
• TTL：30 分鐘，每次請求時更新
• Multi-AZ 副本容錯移轉

DynamoDB 的 Session 範例模式

• 資料表：Sessions，分割鍵 sessionId
• 項目屬性：userId、createdAt、expiresAt
• TTL 屬性：expiresAt——DynamoDB 自動刪除過期項目
• 可選 GSI 在 userId 上，用來跨裝置登出使用者

整合 S3 與應用程式快取——參考架構

使用 S3 與應用程式快取的 DVA-C02 標準應用程式堆疊，端到端：

1. 用戶端 — 瀏覽器或行動 App。
2. CloudFront 分發 — 基於路徑的行為。
   • /static/* → 透過 OAC 存取 S3 儲存貯體，設定較長的 max-age。
   • /api/* → API Gateway 或 ALB，對可快取回應設定較短的 TTL。
3. API Gateway → Lambda — 處理動態呼叫。
4. ElastiCache Redis（Multi-AZ） — 以 session cookie 為鍵的 session 儲存；熱資料庫讀取使用 cache-aside。
5. DynamoDB — 使用者資料的主要儲存，DynamoDB Streams 觸發 Lambda，在寫入時使 Redis 鍵失效。
6. S3 儲存貯體（已啟用版本控制、必要時使用 Object Lock、生命週期規則轉移到 Glacier） — 透過 presigned POST 上傳使用者檔案，應用程式產生的報告、日誌、資料湖輸入。
7. S3 事件通知 — s3:ObjectCreated:* → Lambda（產生縮圖）→ 把衍生物件寫回 S3 → 通知 SNS 做下游扇形傳播。
8. S3 Transfer Acceleration — 在上傳儲存貯體上啟用，供全球用戶使用。

每道 S3 與應用程式快取的考題都是這個堆疊的子集。學會辨識題目在戳哪一層——邊緣、快取、來源，還是持久存檔——是 DVA-C02 獎勵的技能。

DVA-C02 常見的 S3 與應用程式快取陷阱

DVA-C02 在 S3 與應用程式快取題目中反覆出現的陷阱彙整：

• 預簽名網址與儲存貯體政策混淆 — 預簽名網址不能繞過簽名者本身缺少的權限。
• 生命週期規則缺少「中止未完成分段上傳」動作 — 孤立分段會永久計費。
• 應使用 Athena 時卻選了 S3 Select — S3 Select 是單一物件；Athena 是整個資料集。
• 情境需要持久化、pub/sub、Multi-AZ 或有序集合時卻選了 Memcached。
• 把 CloudFront 失效請求當作主要的快取爆破策略 — 版本化檔名才是首選。
• 轉送過多標頭/cookie 到 CloudFront 來源 — 破壞命中率。
• 假設 Standard-IA 對小型頻繁存取物件最便宜 — 取回費用與 128 KB 最低大小會讓算術反過來。
• 依賴 sticky session 解決 session 擴展問題 — 應該外部化到 Redis 或 DynamoDB。
• 對每秒超過萬次請求的情境使用單一 S3 前綴 — 需要按前綴分片。
• 忘記瀏覽器分段上傳需要在 CORS 中設定 ExposeHeaders: ETag。
• 混淆 S3 Object Lock 模式 — Governance 允許有 IAM 權限的用戶繞過；Compliance 不允許。
• 對超過 5 GB 的檔案使用 PutObject — 必須使用分段上傳。

常見問題

Q1. 瀏覽器直接上傳一支 2 GB 影片到 S3，不經過後端路由，最佳模式是什麼？

使用後端產生的 S3 presigned POST（或 presigned PUT），有效期設定為例如 15 分鐘，搭配限制鍵前綴、Content-Type 與最大大小的政策。瀏覽器直接把 multipart form POST 到 S3。瀏覽器端的 SDK（v3 @aws-sdk/lib-storage Upload）會自動把檔案拆成多個分段上傳。記得把 S3 CORS 的 AllowedOrigins 設為你的 App 域名，並在 ExposeHeaders 中包含 ETag。

Q2. 什麼時候應該選 ElastiCache for Redis 而不是 ElastiCache for Memcached？

只要你需要以下任何一個，就選 Redis：節點重啟後持久化、Multi-AZ 與自動容錯移轉、讀取副本、pub/sub、streams、有序集合（排行榜）、地理空間查詢，或交易。只有在你只需要簡單的多執行緒鍵值快取、節點故障遺失所有快取資料是可接受的，且你需要透過新增節點加用戶端雜湊來擴展時，才選 Memcached。實務上，約 80% 的新 AWS 快取部署選 Redis，這也是 DVA-C02 的傾向。

Q3. S3 前面的 CloudFront 分發顯示很差的快取命中率，我該先檢查什麼？

檢查快取政策中設定的快取鍵。如果你把許多標頭（特別是 User-Agent）、cookie 或 query string 加進快取鍵，每個細微變化都會產生一個唯一的快取項目。對靜態資源，把快取政策縮減到只包含 URL 路徑。然後確認你的來源發出合理的 Cache-Control: max-age 標頭——CloudFront 預設遵循來源 TTL。最後，確認資源使用版本化檔名，讓重新部署不需要發出失效請求。

Q4. 當 DynamoDB 中的資料列變更時，如何安全地使 ElastiCache Redis 中的快取資料列失效？

最乾淨的模式是事件驅動失效：在資料表上啟用 DynamoDB Streams，附加一個 Lambda 函數，對每筆變更記錄刪除（DEL）或更新對應的 Redis 鍵。搭配快取項目的 TTL 作為安全網，即使失效事件遺失，錯誤資料也會在有界的時間視窗內過期。避免只從應用程式的寫入路徑執行失效，因為這會把寫入者與快取的可用性耦合在一起。

Q5. 使用者抱怨 Auto Scaling 終止 EC2 執行個體時被登出，我該做什麼改變？

根本原因是 session 狀態存在執行個體的本地記憶體中。把 session 外部化到共享儲存。對大多數 Web 應用程式，Amazon ElastiCache for Redis（Multi-AZ）是正確答案，因為它提供微秒以下的讀取延遲，並支援用 EXPIRE 設定 session TTL。對無伺服器或行動 App，Amazon DynamoDB 搭配 TTL 屬性同樣有效，且消除了操作負擔。ALB 上的 sticky session 可以暫時掩蓋問題，但在目標故障時仍會丟失 session，所以當考題提到縮放事件或高可用性時，不是 DVA-C02 的答案。

Q6. 哪個 S3 功能可以阻止任何人——包括 root 帳號——在七年內刪除法規存檔？

S3 Object Lock 的 Compliance 模式，設定七年保留期限。Compliance 模式是唯一真正能封鎖 root 帳號的設定。Governance 模式允許具有 s3:BypassGovernanceRetention 的使用者刪除，因此對 SEC 17a-4 或 FINRA 等合規要求而言不夠充分。Object Lock 需要啟用版本控制，且通常在建立儲存貯體時設定。

Q7. S3 Transfer Acceleration 什麼時候真的值得那筆額外費用？

當用戶端全球分散且距離儲存貯體 Region 很遠、上傳大小達到數十 MB 以上，且上傳時間是瓶頸（而非 egress 成本）時。這個功能透過最近的 CloudFront 邊緣節點走 AWS 骨幹網路路由流量，繞過最慢的網路跳點。對小型物件或已在儲存貯體 Region 內的用戶端，額外的每 GB 費用不合算。AWS 發布了 Transfer Acceleration Speed Comparison 工具——在啟用前，請用你實際的用戶端地理分布測試。

Q8. S3 Select 與 Amazon Athena 對開發者來說有什麼差異？

S3 Select 對單一物件（CSV、JSON 或 Parquet）執行 SQL 投影/篩選，並串流回符合條件的記錄。它便宜、聚焦，設計目的是取代「下載整個物件再 grep」的做法。Amazon Athena 使用 AWS Glue Data Catalog 做為 schema，對一個或多個儲存貯體中的整個資料集的物件執行完整 ANSI SQL（join、聚合、視窗函數）。如果 DVA-C02 情境說「查詢一個檔案」，答案是 S3 Select；如果說「查詢一個資料集」或「查詢多個檔案」，答案是 Athena。

摘要——DVA-C02 的 S3 與應用程式快取

S3 與應用程式快取是 DVA-C02 開發者的基本功。考試獎勵能做到以下事情的考生：

• 超過 100 MB 時使用分段上傳，並永遠用生命週期規則清理未完成的上傳。
• 發出預簽名網址／POST供瀏覽器直接上傳，不洩漏 IAM 憑證。
• 使用版本控制加生命週期安全且經濟地保存歷史紀錄，並用 Object Lock 達到法規強制不可變性。
• 把 S3 事件通知接進 Lambda、SQS、SNS 或 EventBridge——搭配冪等消費者。
• 選擇 S3 Select 做單一物件投影、Transfer Acceleration 做全球上傳、CORS 做瀏覽器存取。
• 凡是需要持久化、pub/sub、streams 或 Multi-AZ 時選 ElastiCache Redis，只有簡單多執行緒鍵值水平擴展時才選 Memcached。
• 套用正確的快取模式——預設 cache-aside、需要讀寫一致性時 write-through、TTL 作為安全網、事件驅動失效確保正確性。
• 在前面放 CloudFront，搭配窄快取鍵、Origin Access Control，以及版本化檔名而非失效請求。
• 把 session 狀態外部化到 Redis 或 DynamoDB，讓 Auto Scaling 不再登出使用者。

把這些層視為一個堆疊——CloudFront 在邊緣、ElastiCache 在中間、S3 與 DynamoDB 作為持久來源——每道 S3 與應用程式快取的題目都會變成「這道題在戳哪一層？」光是這個框架就能拿到大部分的分數。