考試策略

CloudFront + S3 OAC 是標準的全球影片串流架構：① CloudFront CDN 在全球 400+ Edge Location 快取影片，實現低延遲；② OAC（Origin Access Control）確保 S3 只接受來自 CloudFront 的請求，無法直接存取 S3；③ Signed URLs 或 Signed Cookies 控制哪些用戶可以存取（付費用戶）。Global Accelerator 適合需要 TCP/UDP 低延遲的應用（不是 HTTP 快取）。

高可用三層架構標準答案：① Web 層：ALB + ASG 跨多 AZ（ALB 自動在健康的 AZ 分配流量）；② App 層：同樣 ASG 跨多 AZ；③ DB 層：RDS Multi-AZ（備用在另一個 AZ，自動 Failover）。這樣任一 AZ 故障時，其他 AZ 的實例繼續服務，RDS 自動切換到備用實例。所有層都在同一 AZ 是單點故障。

Spot Instance 是處理短期、可中斷、非關鍵工作負載的最低成本方案（比 On-Demand 便宜 90%）。使用 ASG Spot Fleet（混合多種實例類型和 AZ），即使某個 Spot 被回收，ASG 自動從其他地方補充。黑色星期五只有 2 天，Reserved Instance 至少要 1 年才划算；On-Demand 可行但比 Spot 貴很多；Dedicated Host 更貴且不適合彈性擴展。

SSE-KMS with CMK（Customer Managed Key）讓公司完全控制金鑰：① 可以設定金鑰旋轉週期；② 可以查看金鑰使用記錄（CloudTrail）；③ 可以隨時停用或刪除金鑰（刪除後資料無法解密）；④ 可以設定細粒度的 IAM 政策控制誰能用金鑰。SSE-S3 是 AWS 管理金鑰，公司無法控制；SSE-C 公司提供金鑰但管理複雜（每次請求都要附上金鑰），且 AWS 不保存金鑰。

在兩個服務之間加入 SQS 佇列是解耦的經典方案：服務 A 把任務放進 SQS 就立即返回（非同步），不需要等待服務 B 完成。服務 B 以自己的速度消費 SQS 佇列中的訊息。好處：① 服務 A 不受服務 B 的速度影響；② SQS 可以緩衝突發流量；③ 若服務 B 故障，訊息還在 SQS 中等待，服務恢復後繼續處理（不會遺失）。

AWS IAM Identity Center（原 AWS SSO）是企業 SSO 的標準方案：① 可以直接整合 On-Premises Active Directory（透過 AD Connector 或 AWS Managed Microsoft AD）；② 員工用現有的公司帳號密碼登入 AWS Console 和 CLI；③ 支援多帳號（Organizations）的統一存取管理；④ 不需要為每個人建立 IAM User（難以管理，且不符合最佳實踐）。Cognito 是為應用程式終端用戶設計的，不適合內部員工。

兩層優化：① RDS Read Replica：讓讀取查詢分散到 Read Replica（最多 5 個），分攤主實例壓力；② ElastiCache Redis 前置快取：熱點查詢結果快取在記憶體中（毫秒延遲），命中快取就不需要查 RDS（大幅降低 DB 負載）。注意：RDS Multi-AZ 的備用實例不對外提供讀取服務（只用於 Failover），不能解決讀取瓶頸。

當 Lambda 需要同時存取 VPC 內資源（RDS）和互聯網時的正確架構：① Lambda 設定加入 VPC 的私有子網路（這樣可以存取同 VPC 的 RDS）；② 私有子網路的 Route Table 設定 NAT Gateway（在公有子網路）的路由；③ Lambda 透過 NAT Gateway 連接外部 API。注意：Lambda 放在公有子網路並不能直接連互聯網，Lambda 在 VPC 中需要 NAT Gateway，即使在公有子網路也一樣（這是常見陷阱！）。

全球『多區低延遲讀寫 + 自動同步 + 區域容錯』正是 DynamoDB Global Tables 的定位（多區多主動）。RDS Read Replica 只能異地讀不能各區寫；單區方案無法讓各洲就近寫入。

事件驅動 + Serverless：S3 事件通知在物件建立時觸發 Lambda 處理縮圖，隨用量自動擴展、閒置不計費，最適合不固定流量的非同步處理。常駐 EC2/ECS 在閒置時仍付費且需管理。

File Gateway 讓地端以熟悉的 NFS/SMB 存取，背後把檔案存到 S3 並本地快取熱資料，適合『混合雲、逐步上雲』而不改動應用。DataSync/Snowball 偏一次性遷移；EBS 不能被地端當檔案共享。

分析型（OLAP）大量聚合查詢應交給列式儲存的 Redshift，與線上交易（OLTP）的 RDS 分離：生產 RDS 專心處理交易，定期 ETL 到 Redshift 跑報表。放大機型或加索引治標不治本；DynamoDB 不適合複雜分析。

需要嚴格順序 + 精確一次（去重）→ SQS FIFO（用 Message Group ID 保序、Deduplication ID 去重）。Standard 佇列不保證順序且可能重複（對扣款是災難）；SNS/Firehose 不是交易佇列。

Organization Trail 自動涵蓋組織下所有帳號與 Region（含新帳號），集中輸出中央 S3；再開日誌完整性驗證確保不可竄改，滿足集中稽核與合規。逐帳號設定易漏；CloudWatch Logs 不是 API 稽核來源。

對『重複讀取的熱點資料』，在資料庫前加 ElastiCache（Redis/Memcached）快取可大幅降低資料庫負載、將延遲降到毫秒/微秒級。放大機型成本高且有上限；Redshift 是分析用；EBS 與此無關。

當資料量大（數十 TB 以上）且網路頻寬不足時，Snowball 這類離線實體裝置把資料寄送到 AWS 匯入 S3，遠比走網路快。Direct Connect 雖穩定但建置久且仍受頻寬與時間限制；純網路上傳數月不切實際。

Lambda 最長只能跑 15 分鐘，25 分鐘的任務直接出局（陷阱 #1）。不想管伺服器又不限執行時間 → ECS／EKS 搭 Fargate（陷阱 #9：Fargate 也是 Serverless 容器）。常駐 EC2 要自己管且閒置也計費；Step Functions 是編排工作流程，本身不執行轉檔。

Windows + SMB + Active Directory → FSx for Windows File Server。EFS 走 NFS，是給 Linux 用的（陷阱 #2）；FSx for Lustre 是 HPC／ML 的高效能檔案系統；EBS 是單一 EC2 的區塊儲存，不是共用檔案系統。

EC2 預設指標只看得到 Hypervisor 層的數據（CPU、網路、磁碟 I/O），記憶體與磁碟使用率屬於作業系統內部，必須在實例上安裝 CloudWatch Agent 才會回報（陷阱 #3）。詳細監控只是把預設指標的頻率從 5 分鐘改成 1 分鐘，不會多出記憶體指標。

Zone Apex（根網域）依 DNS 規範不能設 CNAME（陷阱 #6）。Route 53 的 Alias 記錄可以在根網域指向 CloudFront、S3 網站、ELB 等 AWS 資源，而且查詢免費。CloudFront 的 IP 會變動，寫死 A 記錄的 IP 不可行；MX 是郵件記錄。

S3 與 DynamoDB 的 VPC Endpoint 是 Gateway 類型，而且免費（陷阱 #10）。在 Route Table 加上 Gateway Endpoint 後，往 S3 的流量不再經過 NAT Gateway，資料處理費直接消失。Interface Endpoint 要按時數與流量付費；把 EC2 搬到公有子網路會犧牲安全性。

SQS 的訊息被消費後就刪除，多個消費者無法讀同一則訊息，也不能重播（陷阱 #8）。Kinesis Data Streams 把資料保留一段時間，多個消費者可各自從不同位置讀取，也能倒回去重播。SNS 可以一對多推送，但訊息不持久化，同樣不能重播。

關鍵字是「自動旋轉」→ Secrets Manager，它內建與 RDS 等資料庫整合的密碼輪替。SSM Parameter Store 適合存一般設定值，不提供內建的自動旋轉；環境變數與 S3 檔案都得自己手動換密碼。

在 S3 中自動發現 PII（個人可識別資訊）等敏感資料 → Amazon Macie。GuardDuty 偵測帳號的異常行為（挖礦、入侵）；WAF 過濾 HTTP 請求；Inspector 掃描 EC2／容器的軟體弱點，都不會去讀 S3 物件的內容。