Amazon SAA-C03: 分析、資料湖、ML 與特殊工作負載 — 學習指南

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

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

資料湖基礎：Lake Formation 與 Glue Data Catalog

AWS 分析服務的重心是 AWS Glue Data Catalog——一個與 Hive metastore 相容的中繼資料庫，Athena、Redshift Spectrum、EMR 和 Glue ETL 都會使用它。所有的資料表定義、分割區、欄位類型和 SerDe 設定都存放在這裡，每個下游引擎都會從中讀取。如果兩種資料擷取路徑（例如，一個 Glue crawler 和一個手動的 CREATE EXTERNAL TABLE 陳述式）對於同一個 S3 前綴的 schema 定義不一致，查詢會在沒有任何警告的情況下回傳錯誤的結果或直接失敗。正確的模式是為每個資料表指定單一的權威來源：要嘛由 crawler 擁有 schema 的定義權，要嘛由您的 ETL job 透過 glueContext.write_dynamic_frame.from_catalog 寫入，但絕不能在沒有合併策略的情況下兩者並存。當批次 ETL、Firehose 的 Parquet 轉換和手動 DDL 都寫入同一個資料表時，catalog 的漂移是個無聲的殺手。強制每個資料表只有一個擁有者，為串流資料的生產者使用 Glue Schema Registry，並在由 ETL job 擁有的資料表上以 LOG 模式（而非 UPDATE_IN_DATABASE）執行 crawler，這樣它們就能讓 schema 的漂移浮現出來，但又不會覆寫掉已經整理好的 schema。

AWS Lake Formation 位於 Data Catalog 之上，它用一個資料庫風格的權限層取代了粗顆粒度的 IAM/S3 儲存貯體政策模型。您不再需要對某個前綴授予 s3:GetObject 權限，而是執行 GRANT SELECT ON customers.orders TO role/AnalystRole，當 Athena 或 Redshift Spectrum 接觸到底層物件時，Lake Formation 會自動透明地提供短期的憑證。它真正的價值在於細顆粒度的授權：欄位層級的過濾、透過資料篩選器實現的資料列層級安全性，以及可以擴展到數千個資料表的基於標籤的存取控制 (LF-Tags)。一個在 customers 資料表中有個人可識別資訊 (PII) 的零售平台，可以授予分析師存取 customer_id、region、signup_date 的權限，同時封鎖 email 和 ssn——這是在查詢時強制執行的，不需要大量建立 view。

一個受治理的資料湖的標準設定：

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Lake Formation blueprints 是預先建置的工作流程範本，可以將 crawler、job 和觸發器串連起來，從 JDBC 來源或 S3 擷取資料到一個整理過的資料湖中——將原本需要數十個手動串接的 Glue 資源，簡化為一個由精靈引導的流程。

一個常見的錯誤是試圖單獨在 QuickSight 中強制執行欄位層級的限制。QuickSight 雖然有與資料集綁定的資料列和欄位層級安全性，但它只保護 QuickSight 的操作介面——任何能直接存取 Athena 或 S3 的人都可以繞過它。欄位層級的控制必須在資料層強制執行（透過 Lake Formation 的授權，或在 ETL 過程中實際分離欄位），而 QuickSight 則透過其 IAM role 繼承這種安全態勢。

Athena：在 S3 上運行的無伺服器 SQL

Athena 是一個無伺服器、按查詢付費的 Presto/Trino 引擎，可直接從 Amazon S3 讀取資料。無需佈建叢集，查詢前無需 ETL 步驟，閒置時不產生任何費用——您只需為掃描的位元組數付費（通常是每 TB 5 美元）。這使得 Athena 成為對已經存放在 S3 中的檔案進行臨時分析的標準選擇，無論是 JSON 應用程式日誌、CSV 匯出檔，還是 Parquet 事實表。Athena 需要 schema 和分割區的佈局，這些資訊存放在 Glue Data Catalog 中。

由於 Athena 是按掃描的 TB 數計費，儲存格式對成本和延遲有著不成比例的巨大影響。有兩個槓桿可以操作：格式和分割區：

• 欄式儲存格式 (Parquet, ORC) 讓 Athena 可以裁剪掉不必要的欄位和資料列群組。一個像 SELECT sum(amount) FROM orders WHERE region='us-east-1' 這樣的查詢，在 Parquet 格式上只會讀取被參考的兩個欄位；在 CSV 格式上則會讀取每一列的每一個位元組。
• 分割區 在高選擇性的欄位上（例如 dt=2024-03-11/）可以將全資料表掃描縮減為針對性的讀取。對於數 TB 大小的日誌（CloudFront、ALB、VPC Flow Logs），這可能是一個 0.15 美元查詢和一個 30 美元查詢之間的差別。

將原始的 JSON 或 CSV 轉換為有分割區、經過 Snappy 壓縮的 Parquet 格式，幾乎永遠是第一個可以著手的成本優化點。結合 LIMIT pushdown，Athena 可以在零基礎設施的情況下處理大部分在 S3 上的分析需求。

一個將 “readings” 資料表儲存為分割區 Parquet 的高成本效益模式：

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

跳過 crawler 是一個常見的錯誤。如果沒有 catalog 項目，您要嘛得手動撰寫 CREATE EXTERNAL TABLE DDL（這會隨著 schema 演變而變得很脆弱），要嘛就得使用在讀取時才定義 schema 的取巧作法，而這會掃描每個檔案。更糟的是，如果沒有 MSCK REPAIR TABLE 或 partition projection，Athena 在每次查詢時都會掃描整個前綴。Glue crawler 會按排程偵測新的分割區，並以原子化方式更新 catalog。

在加密的 S3 資料上使用 Athena。 Athena 支援 SSE-S3、SSE-KMS 和 CSE-KMS，但前提是呼叫者擁有正確的 KMS 權限，且工作群組或用戶端已針對所使用的加密模式進行設定。對於 CSE-KMS，檔案在上傳前於用戶端加密；執行查詢的 IAM 主體需要在 CMK 上擁有 kms:Decrypt 和 kms:GenerateDataKey 權限，且金鑰政策也必須對應地授予權限。一個常見的失敗模式是：載入 CSE-KMS 加密的 Parquet，只授予 Athena 的 role 讀取 S3 的權限，然後得到不明確的 AccessDenied 或 HIVE_CANNOT_OPEN_SPLIT 錯誤——物件本身是可讀的，但密文無法被解開。另一個常見的錯誤是用錯誤的加密模式註冊資料表（物件是用 CSE-KMS 寫入的，但在資料表屬性中設定為 SSE-KMS）；Athena 會在 GetObject 期間嘗試進行伺服器端解密，結果回傳的 payload 是原始密文，導致 Parquet 的 magic number 檢查失敗。

Athena 聯合查詢讓您無需移動資料，就能將 S3 資料與操作型資料儲存（如 DynamoDB、RDS）進行 join。將 Athena 保留用於以讀取為主的臨時分析；使用 Glue job 來排程對整理過的區域進行資料塑形。

Glue Crawler、ETL 任務與任務書籤 (Job Bookmark)

Glue crawler 會掃描 S3 路徑、推斷 schema (包含從 year=2024/month=01/ 這類的目錄結構推斷 partition key)，並在資料目錄中註冊或更新資料表。對於「我們把檔案丟到 S3，讓它們可以被查詢」這樣的需求，crawler 是低程式碼的解決方案。只要排程一個 crawler 每小時對 landing bucket 執行，Athena 就能立即看到新的分割區。

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Glue ETL 任務 (Spark、Python shell 或 Ray) 負責處理轉換的部分。Glue 是無伺服器的——您按 DPU 小時付費，最低計費一分鐘——且執行環境會自動擴展 worker。主流的模式是輸入 CSV/JSON，輸出分割後的 Parquet：

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

關鍵的維運功能是任務書籤 (job bookmark)：Glue 會持續保存關於它已處理過哪些檔案或分割區的狀態，因此後續的執行只會讀取新的資料。如果忘記啟用書籤，每次執行都會從頭開始重新處理整個資料集，導致成本和執行時間線性增長，且經常產生重複的輸出。書籤是依任務啟用的，且必須與支援它們的來源選項搭配使用 (透過 Glue DynamicFrame 讀取器的 S3 來源支援；任意的 Spark 讀取操作則不支援)。書籤要求每個來源都有一個 transformation_ctx 參數，並用 job.init(...) / job.commit() 將程式碼包起來：

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

對於沒有任何邏輯的純粹格式轉換，最省力的方法通常是在原始資料上執行一個 Glue crawler，再加上一個在視覺化編輯器中編寫的 Glue 任務 (或是一個 DataBrew 配方)——完全不需要 Spark 程式碼。自訂的 EMR 叢集或 Lambda 轉換器會增加維運開銷，而 Glue 的無伺服器模型正好消除了這些開銷。

一個典型的每日任務，負責整理 S3 資料並載入到 Redshift Serverless：

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Glue 安全組態與多租戶 ETL

Glue crawler 和任務需要與 Athena 相同的加密感知能力。Glue 安全組態 (security configurations) 是一些具名的組合包，用來指定 S3 目標、CloudWatch 日誌和任務書籤如何被加密——包含使用特定 CMK 的 CSE-KMS。一個附加了安全組態的任務，會透明地解密 CSE-KMS 輸入，並以同樣的方式加密輸出，前提是該任務的 IAM 角色擁有對所引用金鑰的 KMS 權限。

對於多租戶 ETL——例如一個 SaaS 平台用每個客戶自己的 CMK 來處理其資料——正確的模式是為每個客戶設定一個安全組態 (或用一個任務參數來選擇 CMK)，並搭配一個權限範圍僅限於該 CMK 的 IAM 角色。若用單一的共享金鑰在同一個任務中處理所有客戶的資料，就破壞了 CSE-KMS 旨在提供的隔離保證。

一個相關的準則：生產環境的分析資料表不應該成為探索性 Glue 任務或筆記本的直接目標。應該將快照匯出到 S3 的一個「analytics」前綴下，然後讓 Athena 或 Spark 指向該複本。在線上資料表上執行實驗性的轉換，會帶來分割區層級重寫、書籤損毀和鎖定競爭的風險，並且會模糊營運資料和分析衍生資料之間的稽核邊界。

AWS Glue DataBrew

對於無法或不應撰寫 Spark 程式碼的使用者，DataBrew 是 Glue 的低程式碼兄弟產品。它提供一個試算表風格的使用者介面，內建超過 250 種預建的轉換 (例如資料插補、PII 遮罩、離群值分箱、日期解析)。它的差異化特色是共享配方 (shared recipes)——可發布並在不同專案中重複應用的版本化 JSON 成品——以及資料血緣視覺化，可以追蹤欄位從來源資料集、經過配方和任務、一直到輸出位置的完整路徑。當轉換邏輯由分析師負責時，選擇 DataBrew；當由工程師負責，且 pipeline 需要自訂程式碼、串流或複雜的 join 時，則選擇 Glue Studio/腳本。

Amazon EMR：分散式批次處理與執行期角色

Amazon EMR 是一個託管的叢集平台，可執行 Spark、Hadoop、Hive、Presto、HBase 和 Flink。它的最佳應用場景是處理大型、可並行處理的批次或互動式工作負載，這些工作負載會讀取 PB 等級的 S3 資料集，並與另一個記錄系統 (通常是 Redshift) 進行 join 以擴充資料。EMR 可以執行暫時性叢集 (啟動、執行、終止)，也可以執行長期運行的叢集，並可透過執行個體叢集 (instance fleets) 混合使用 On-Demand、Spot 和 Reserved 執行個體。

一個典型模式：一個 Spark 任務從 S3 讀取 Parquet，透過 UNLOAD-to-S3 從 Redshift 拉取維度資料表，在各個 executor 之間進行 join，然後將擴充後的輸出寫回 S3：

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

EMR 在此勝出的原因是 Spark 將 join 分散到數十個節點上執行，而透過 S3 進行中繼則避免了單一執行緒的 JDBC 瓶頸。一個常見的陷阱是，每當需要查詢 S3 資料時就反射性地選擇 EMR。對於數十或數百 GB 資料的臨時性 SQL 查詢，佈建和調校一個 Spark 叢集是純粹的維運開銷——包含叢集規模設定、YARN 組態、自動擴展、日誌輪替、修補。只有當資料量、自訂程式碼的需求或執行引擎的彈性等因素證明其合理性時，EMR 才顯得物有所值。

EMR 執行期角色 (runtime roles)。 過去，叢集上的所有步驟都繼承 EC2 執行個體描述檔——一個附加到底層節點的角色——這意味著共享叢集的每個團隊都擁有所有團隊所需權限的聯集。執行期角色解決了這個問題：當使用者提交一個步驟時，他們可以傳遞 --execution-role-arn，EMR 就會在該步驟的執行期間擔任該角色。如此一來，A 團隊可以被限制在 s3://team-a/*，B 團隊則被限制在 s3://team-b/*。執行個體描述檔變成一個精簡的引導角色，僅用於擷取叢集成品。

執行期角色也是阻擋 IMDS 存取的機制。當啟用時 (EMR 6.7+ 搭配 YARN 上的 Spark/Hive)，使用者程式碼無法存取執行個體中繼資料服務 (IMDS)——包含 IMDSv2——因為平台會攔截這些呼叫。這就關閉了權限提升的路徑，否則任務可能會呼叫 http://169.254.169.254/latest/api/token 並擔任權限強大的 EC2 執行個體描述檔。

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

安全組態是啟用執行期角色強制執行和 IMDS 阻擋的關鍵。若沒有它，認為 EMR 工作負載會「自動使用最低權限角色」的想法是錯誤的——預設情況下，它們共享執行個體描述檔，且使用者程式碼可以存取 IMDS。

Amazon Redshift 與 Redshift ML

Redshift 是一個欄式 MPP (Massively Parallel Processing) 資料倉儲，專為持續性的分析工作負載而設計，這些工作負載要求亞秒級的儀表板回應、對數十億列資料進行複雜的聯結 (join)，以及在多個 BI 使用者同時存取下保持一致的延遲。RA3 節點將運算與託管儲存解耦；Redshift Serverless 則根據設定的基礎容量，以 RPU-秒 (RPU-seconds) 計費，並在負載下自動擴展，在閒置時暫停，從而消除了傳統的叢集規模調整問題。

Redshift 以兩種擴充模式參與分析管線：

• 作為來源： EMR 上的 Spark 透過 UNLOAD-to-S3 拉取維度資料，或 Glue 透過 Redshift Data API 讀取資料。
• 作為目標： Firehose 或 Glue 任務將擴充後的資料 COPY 進來。

Redshift Spectrum 擴展了此功能，它讓 Redshift SQL 可以透過 Glue Data Catalog 直接查詢 S3——這與 Athena 使用的是同一個目錄——這也是湖倉一體 (lake-house) 模式得以運作的原因。當您已經有一個 Redshift 叢集，並希望將倉儲中的事實資料與 S3 中的冷歷史資料進行聯結，而無需移動資料時，這是理想的選擇。

批次載入使用 COPY 從 S3 進行，並在運算節點之間平行化；為了實現平行處理，檔案應被分割成大致相等的大塊（為 slice 數量的倍數）：

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

串流擷取通常流經 Firehose（緩衝的 COPY）以實現零操作 (zero-ops) 的交付。

Redshift ML 讓 SQL 使用者可以透過 CREATE MODEL 建立、訓練和調用模型：

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

在底層，Redshift 將訓練集匯出到 S3，調用 SageMaker Autopilot（或像 XGBoost 這樣的指定演算法），並匯入編譯後的模型以進行資料庫內推論。當分析師已經習慣在 SQL 環境中工作時，這功能很強大，但它不能取代一個完整的機器學習平台：資料移動到 S3 和 SageMaker 訓練運算的費用是分開計算的，大型訓練集可能會產生可觀的出口流量和 Autopilot 執行時間費用，並且沒有內建的工作流程來支援特徵儲存 (feature stores)、實驗追蹤或 A/B 部署。應將 Redshift ML 視為在 Redshift 資料上進行的普及化推論，而非通用的訓練工具。

在 Athena 和 Redshift 之間做選擇

串流擷取：Kinesis Data Streams、Firehose 與 MSK

這三種 AWS 串流服務解決了重疊的問題，但提供了截然不同的保證：

Kinesis Data Streams 使用 shard（或隨選模式）；具有相同分割區索引鍵 (partition key) 的記錄會落在同一個 shard 上，並按順序被消費。消費者使用傳統的 GetRecords 或增強型扇出 (Enhanced Fan-Out)（每個消費者專用的 2 MB/s）。作為事件來源附加的 Lambda 函數會以每個 shard 的批次被調用，並保持順序。當下游邏輯不簡單、當多個獨立的消費者必須重播歷史記錄、或當點擊流 (clickstream) 資料量巨大時——例如，一個每天產生 30 TB 資料的網站會將資料流經 KDS 進入 Firehose，並存放在 S3 中以供 Athena/Spectrum 分析——這就是正確的選擇。

Kinesis Data Firehose 是「發後不理」(fire-and-forget) 的託管式交付：它按大小或時間（例如，5 MB / 300 秒）緩衝資料，可選擇性地調用 Lambda 進行轉換，可選擇性地使用 Glue 表的結構描述將 JSON 轉換為 Parquet/ORC，並寫入 S3、Redshift（透過 S3 + COPY）、OpenSearch 或 Splunk。在 Firehose 中開啟 Parquet 轉換是將串流資料以查詢優化格式存放的低成本方法，無需下游的 Glue 任務：

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

Firehose 沒有端到端的順序保證，無法支援多個可重播的消費者，且其目的地是固定的接收端 (sinks)。當需求是「按順序處理每筆記錄」或「多個獨立消費者」時，選擇 Firehose 在這兩點上都是錯誤的。同樣地，期望單靠 Firehose 來執行複雜的轉換是一個陷阱——它唯一的轉換掛鉤 (transform hook) 是為每個緩衝批次調用的 Lambda。任何涉及外部擴充、多記錄彙總或條件式路由的操作，都必須在該 Lambda 中實現，或移至上游的 Managed Service for Apache Flink。

Amazon MSK 是託管的 Apache Kafka。當您已經有 Kafka 生產者/消費者、需要 Kafka 特有的功能（例如壓縮主題 (compacted topics)、事務 (transactions)、Kafka Streams、Connect），或需要超過 shard-based Kinesis 所能輕鬆提供的吞吐量時，請選擇它。

使用 SQS 或 EventBridge 作為分析擷取路徑是個錯誤：SQS 不保證每個串流的順序且缺乏重播功能；EventBridge 是為事件路由而優化，而非持續性的每秒數 MB (multi-MB/s) 擷取。

即時搜尋：KDS + Firehose + OpenSearch + QuickSight

地端 Elasticsearch+Logstash 堆疊的典型替代方案是：

Firehose 會緩衝串流紀錄，並將它們直接交付到 OpenSearch 網域，同時處理重試、S3 備份和可選的 Lambda 轉換。OpenSearch Dashboards 內嵌於網域中且免費，適合監看即時串流的操作人員。QuickSight 則為此補充了面向業務的分析功能——它可以直接查詢 Athena、Redshift、RDS 和 OpenSearch，其 SPICE 記憶體內欄式引擎 (in-memory columnar engine) 會快取處理過的資料集，以實現儀表板的亞秒級效能。

典型的分工是：操作人員使用 OpenSearch Dashboards；高階主管則使用 QuickSight 來檢視來自 Athena/Glue 資料湖的彙總、策劃過的資料集。兩者都必須被授予 IAM 讀取權限，並在適用情況下，授予對保護底層儲存的 CMK 的 KMS Decrypt 權限——否則，視覺化層將顯示空白面板，並在查詢日誌中隱藏權限錯誤。

QuickSight 存取控制

QuickSight 會先建立 datasets (資料集，即邏輯查詢加上計算欄位和資料列層級安全性)，然後在資料集之上建立 analyses (分析)，最後發佈 dashboards (儀表板，即唯讀的可分享視圖)。存取控制是分層的，必須在正確的層級上應用。常見的陷阱是在儀表板層級授予過於寬鬆的存取權限——例如，當只有一部分人應該看到底層資料時，卻將儀表板分享給整個組織的群組。

在 QuickSight 中，最小權限原則意味著：

• 僅與需要它的使用者/群組分享 dataset (資料集)。
• 透過一個權限資料集來應用 資料列層級安全性 (row-level security)，該資料集根據使用者名稱或群組來篩選資料列。
• 應用 資料欄層級安全性 (column-level security) 來隱藏敏感欄位。
• 與特定的使用者、群組或 (對於嵌入式分析) 命名空間分享 dashboards (儀表板)。

將儀表板設為公開或全帳戶分享，會繞過資料集層級控制的意圖，因為儀表板的檢視者會繼承對視覺化資料的讀取權限，無論底層來源的權限如何。請記住，QuickSight 的資料欄層級安全性只保護 QuickSight 的介面；任何能直接存取 Athena 或 S3 的人都可以繞過它，因此敏感的控制應放在 Lake Formation 或 ETL 中，而不僅僅是在 QuickSight 裡。

QuickSight 的 角色——Admin (管理員)、Author (作者)、Reader (讀者)——控制使用者可以做什麼，這與控制他們可以看什麼的分享權限是不同的。Reader (讀者) 的每次會話成本比 Author (作者) 授權低，因此檢視者群體預設應為 Readers，且存取權限應透過群組成員資格而非個別指派來授予。

用於圖形工作負載的 Amazon Neptune

Neptune 是一個受管的圖形資料庫，支援屬性圖模型 (property-graph model) (Gremlin, openCypher) 和 RDF (SPARQL)。它專為高度關聯的資料而建——例如社交關係、詐騙集團、知識圖譜、推薦引擎——在這些情境中，關聯式資料庫中的遞迴性聯結 (recursive joins) 會變得不切實際。一個包含使用者、追蹤、按讚和貼文的社交平台，可以自然地對應到頂點 (vertices) 和邊 (edges)，而 Neptune 可以在毫秒內回答多跳遍歷 (multi-hop traversals) 的問題（例如「喜歡 X 的朋友的朋友」）。

Neptune Streams 會公開一個有序的、基於時間的日誌，記錄對圖形的每一次變動。輪詢此串流的 Lambda 或應用程式可以對變更做出反應——例如重新計算推薦、更新搜尋索引、觸發詐騙警報——而無需一個客製化的變更資料擷取 (change-data-capture) 管線。要在 Aurora 或 DynamoDB 上重現這一點，需要應用程式層級的圖形遍歷，外加獨立的 CDC 機制。當問題陳述同時包含「分析關係」和「監控變更」時，帶有 Streams 的 Neptune 就是最直接的選擇。

SageMaker：端到端的客製化機器學習

SageMaker 提供了完整的生命週期：Studio 筆記本、受管的訓練任務 (支援 Spot 執行個體)、Model Registry、即時和無伺服器端點、批次轉換以及用於 MLOps 的 Pipelines。一個典型的流程是將訓練資料上傳到 S3，啟動一個指定內建演算法或自訂容器的訓練任務，然後 SageMaker 會佈建暫時的執行個體、將日誌串流到 CloudWatch，並將模型產出物 (model artifact) 寫回 S3。部署只需一個 API 呼叫：

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

無需管理 Kubernetes、GPU 驅動程式或模型伺服器。對於需求是「訓練並公開一個模型」的團隊來說，相較於自己動手打造 ECS/EC2 推論環境，SageMaker 幾乎總是管理開銷最低的答案。

SageMaker Savings Plans 承諾在 1 年或 3 年內，對符合條件的元件 (Studio、訓練、處理、即時推論) 投入每小時一定金額的費用，可獲得高達 64% 的隨需折扣。它們在執行個體系列、大小、區域和元件之間具有彈性——但不涵蓋 Ground Truth、儲存或資料傳輸。當基準的 ML 使用量可預測時，請使用 Savings Plans；將突發的訓練任務留在 Spot 執行個體上，以複合節省成本。

託管式 AI 服務與自訂 ML 之比較

Amazon Rekognition (影像/影片：物件與場景偵測、人臉分析、內容審核)、Textract (OCR 加上表單與表格擷取) 和 Comprehend (NLP：實體辨識、情緒分析、PII 偵測、自訂分類) 皆透過簡單的 API 提供預先訓練好的模型。Comprehend 的 DetectEntities 會回傳具類型的實體，其中包含一個 COMMERCIAL_ITEM 類別——這非常適合從食譜文本中提取食材名稱，並將其饋送至 DynamoDB 進行查詢，完全無需訓練資料、無需託管，且採用按請求付費的定價模式：

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

常見的失敗模式是過度設計——當託管式服務已經能以極低的營運成本滿足需求時，卻仍建立 SageMaker 訓練任務、用 Ground Truth 標註資料，並託管端點。只有在針對特定領域資料的準確度顯著更高、所需的實體類型與託管服務的結構不符 (Comprehend Custom Classification/Entity Recognition 仍比直接使用 SageMaker 便宜)，或延遲和資料落地限制要求使用私有模型時，自訂 ML 才有其正當性。

HPC 儲存與網路：FSx for Lustre 和 EFA

緊密耦合的 HPC 工作負載——例如 CFD、分子動力學、地震成像、大規模訓練——有兩個不可或缺的要求：極低的節點間通訊延遲和高吞吐量的共享儲存。

Elastic Fabric Adapter (EFA) 是一種可在特定 EC2 執行個體系列 (hpc7a、hpc6id、c6in、p4d/p5 等) 上使用的網路介面。它使用 OS-bypass Libfabric 來繞過核心的 TCP/IP 堆疊，讓 MPI 和 NCCL 能在數百個節點上達到微秒級的延遲。EFA 要求執行個體位於同一個可用區域內，並且為了達到最大頻寬，要放在叢集置放群組 (cluster placement group) 中。

FSx for Lustre 是一個託管式平行檔案系統，提供每秒數百 GB 的吞吐量和亞毫秒級的延遲。它與 S3 原生整合：一個 FSx 檔案系統可以連結到一個儲存貯體，讓物件以 POSIX 檔案的形式呈現，而寫入 Lustre 的結果可以匯出回 S3。Persistent SSD 部署適合長期存在的暫存空間；Scratch2 對於暫時性的任務資料來說更便宜。

錯誤的模式是將 EFS 用於 HPC。EFS 是基於 NFS 的，針對大量小型用戶端執行通用檔案 I/O 進行了最佳化；它無法承受一個 500 節點的 MPI 任務所需的彙總吞吐量或中繼資料 IOPS，且其多可用區的設計會增加延遲。使用標準 ENA 而非 EFA 會將 MPI 的延遲限制在 TCP 的水準，會讓大量使用 allreduce 的執行時間增加數倍。正確的組合是在叢集置放群組中，啟用 EFA 的執行個體掛載 FSx for Lustre，並以 S3 作為連結到該檔案系統的持久性冷儲存。

← 資料庫與快取 · 所有領域 · 應用程式整合、訊息傳遞與串流 →

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

瀏覽 Amazon →