當您在 AWS 上部署 Eclipse Dataspace Components (EDC) 連接器時，首先面臨的挑戰之一是預測和控制所需基礎設施的成本。若缺乏明確的基準，則難以就工作負載規模調整、環境組態以及長期投資做出明智的決策。

本系列部落格共分三部分，第 1 部分介紹了資料空間架構的基礎以及 IDSA（International Data Space Association）標準所定義的 EDC。第 2 部分探討了在 Amazon Web Services (AWS) 上部署 EDC 連接器的生產就緒架構模式，討論了卓越營運、安全性與可靠性原則。本篇最終文章將涵蓋剩餘三個 AWS Well-Architected Framework 支柱：效能效率、成本優化以及永續性。

在本篇文章中，您將了解在 EDC 連接器部署中哪些 AWS 服務會驅動成本、如何估算業務關鍵與非關鍵工作負載的每月成本，以及如何應用最高可節省 58% 支出的優化策略。

了解資料空間部署中的成本驅動因素

資料空間是安全且主權的資料環境，能讓獨立組織之間共享資料。透過這些架構，您可以在與外部組織協作的同時，維持對資料的完整控制，並符合資料主權原則。您的基礎設施成本可能會有顯著差異。主要因素包括效能與可靠性需求，以及跨網路的資料量與資料速度。區分兩種基礎設施也很重要。資料空間治理機構 (DSGA) 集中建立管理、身分識別與探索功能等元件。參與者則自行託管其他元件，包括連接器。本篇文章僅探討與參與者（即資料提供者與資料消費者端）部署 EDC 連接器相關的成本。

虛構的使用假設

在深入探討數字之前，以下是您可作為自己估算基準的技術與營運假設。

技術假設

類別 假設 理由
資料量 每位參與者 5 GB 包含 6 個月歷史資料與備份
網路流量 每位參與者每月 20 GB 參與者之間的資料傳輸
API 呼叫 每位參與者每月 100,000 次 目錄查詢、合約協商與資料傳輸
OAuth Token 請求 每位參與者每月 1,000 次 資料平面操作的機器對機器驗證

表 1：EDC 連接器成本估算的技術假設

營運假設

  • 單一 AWS 區域：西班牙 (eu-south-2)
  • 運作時間：全年無休 24/7/365。
  • 成長率：基準估算未納入。
  • 災難復原：僅自動備份（無跨區域複寫）

部署架構與情境

圖 1 顯示在 AWS 上部署生產就緒 EDC 連接器的參考架構，系列第 2 部分已深入探討。

顯示包含 Amazon ECS、Amazon Aurora、Network Load Balancer 與支援服務的生產就緒 EDC 連接器部署架構圖

圖 1：生產就緒 EDC 連接器部署

本文根據工作負載的關鍵性考量兩種成本情境：

  • 業務關鍵工作負載：針對支援關鍵業務功能的高可用性、效能與可靠性使用案例所設計。
  • 非關鍵工作負載：針對可容忍中斷的使用案例、測試環境，或可接受短暫中斷的生產工作負載所設計。

兩種情境皆遵循第 2 部分所述的架構模式，主要差異在於運算與資料庫資源的規模調整。

成本估算：業務關鍵工作負載

注意：這些估算使用上述假設，說明各項服務的相對成本貢獻。您的實際成本可能因特定使用模式、資料量與區域定價而有所不同。本文將重點說明哪些元件是最高成本驅動因素，因此具有最高優化潛力。

AWS 服務 組態 每月成本 (USD)
Amazon Aurora PostgreSQL-Compatible Edition db.r6g.large (2 vCPU, 16 GB)，20 GB 儲存空間 + 10 GB 備份 276.00
Amazon Elastic Container Service (Amazon ECS) with AWS Fargate 2 vCPU, 4 GB RAM，永遠開啟 83.00
Network Load Balancer 20 GB 已處理資料 20.00
AWS Secrets Manager 10 個密鑰 4.00
Amazon Cognito 1K 機器對機器 (M2M) token 請求 2.25
Amazon Elastic Container Registry (Amazon ECR) 2 GB 儲存空間，10 GB 傳輸 1.00
Amazon API Gateway 100K REST API 呼叫 0.40
Amazon Simple Storage Service (Amazon S3) 5 GB Standard 層級 0.10
總計 387.00

表 2：業務關鍵 EDC 連接器部署的每月估算成本

這些估算有助於識別您的預算流向以及優化影響最大的地方。在業務關鍵情境中，主要成本驅動因素為 Amazon Aurora PostgreSQL。選擇 db.r6g.large 組態是為了應對需要高記憶體與效能的持續工作負載，以確保可靠性和速度。Amazon ECS with AWS Fargate 是第二大成本貢獻者，因為它會持續執行容器以維持環境可用性。Network Load Balancer 是第三個值得注意的成本元件，其餘服務僅占總成本的一小部分。

成本估算：非關鍵工作負載

若您執行開發、測試或實驗環境，可透過適當調整規模並使用 Amazon EC2 Spot 容量，最多可降低 58% 的成本。

AWS 服務 組態 每月成本 (USD)
Amazon Aurora PostgreSQL-Compatible db.t4g.medium (2 vCPU, 4 GB)，20 GB 儲存空間 + 10 GB 備份 110.00
Amazon ECS with AWS Fargate Spot 2 vCPU, 4 GB RAM，永遠開啟 26.00
Network Load Balancer 20 GB 已處理資料 20.00
AWS Secrets Manager 10 個密鑰 4.00
Amazon Cognito 1K M2M token 請求 2.25
Amazon ECR 2 GB 儲存空間，10 GB 傳輸 1.00
Amazon API Gateway 100K REST API 呼叫 0.40
Amazon S3 5 GB Standard 層級 0.10
總計 164.00

表 3：非關鍵 EDC 連接器部署的每月估算成本

這些數字顯示，非關鍵組態可在維持相同資料吞吐量與 API 容量的情況下，顯著降低成本。成本降低來自使用更小且更具彈性的資源。Amazon Aurora PostgreSQL 仍為主要成本驅動因素，但較小的執行個體類型 (db.t4g.medium) 已大幅降低成本。從運算角度來看，使用 Amazon ECS with AWS Fargate Spot 容量可比業務關鍵設定降低近 70% 的成本。總體而言，此組態每月成本約可降低 58%，同時維持資料吞吐量、API 呼叫與儲存的相同假設。

成本優化的關鍵重點

此比較顯示，兩種情境的主要成本貢獻者皆為資料庫、運算與負載平衡資源，這些屬於基礎設施基準成本，而非依使用量計費的費用。Amazon S3、API Gateway 與資料傳輸費用等服務在此資料量下對總成本的貢獻極小。此成本結構表示架構可隨使用量增加而有效擴展。當您新增更多使用案例並提高資料量與速度時，您可從現有基礎設施投資獲得更多價值，而無需按比例增加成本。

Well-Architected 支柱：效能效率、成本優化與永續性

系列第 2 部分已涵蓋 EDC 在 AWS Well-Architected Framework 卓越營運、安全性與可靠性支柱的最佳實務。本節將探討其餘三個支柱在 EDC 部署中的應用。

效能效率

適當調整運算資源：將 Amazon ECS 任務定義與實際工作負載需求相匹配。從較小的組態開始，根據觀察到的指標進行擴展，而非一開始就過度配置。Amazon CloudWatch Container Insights 可提供做出明智規模調整決策所需的能見度。

運用 Amazon Aurora 的彈性：對於需求模式多變的工作負載，可考慮使用 Amazon Aurora Serverless v2，它會根據應用程式需求自動調整資料庫容量。這可消除為尖峰容量進行佈建的需求，同時在高需求期間維持效能。

最佳化資料傳輸模式：設計資料平面操作以減少不必要的資料移動。對於跨地理距離的大量傳輸，可使用 Amazon S3 Transfer Acceleration，並在適當時考慮資料壓縮，以減少傳輸時間與成本。

成本優化

降低容錯工作負載的運算成本：透過 AWS Fargate Spot，您可為可容忍中斷的工作負載節省高達 70%。非關鍵環境、批次處理與開發工作負載是理想的候選對象。實作妥善關閉處理以有效管理 Spot 中斷。

隨著時間降低儲存成本：設定 Amazon S3 Lifecycle 政策，以自動將不常存取的資料轉移至較低成本的儲存類別，例如 S3 Intelligent-Tiering 或 S3 Glacier Instant Retrieval。對於 EDC 連接器部署，歷史傳輸日誌與封存資產是分層儲存的良好候選對象。

監控非預期的成本增加：使用 AWS Cost Explorer 並設定 AWS Budgets 警示，以協助偵測非預期的成本增加。持續為 EDC 相關的 AWS 資源加上標籤，以便準確分配成本並找出優化機會。

為可預測的工作負載鎖定較低費率：對於具有可預測、穩定狀態用量的業務關鍵連接器，Amazon Aurora 與 AWS Fargate 的 Savings Plans 可提供相較於隨需定價的顯著折扣。

永續性

最佳化資源利用率：提高已佈建資源的利用率代表減少浪費。使用自動擴展政策以需求匹配容量，並在可能的情況下於非營業時間關閉非生產環境。

選擇高效能執行個體類型：AWS Graviton 為基礎的執行個體（例如範例中使用的 r6g 與 t4g 系列）相較於同等 x86 執行個體，可提供更好的價格效能比與能源效率。AWS Graviton 處理器可提升每瓦能源使用的效能。

減少資料移動：每次資料傳輸都會消耗能源。設計您的資料空間整合以避免冗餘傳輸，使用 Federated Catalog 在本地端快取經常存取的對等目錄資料，並在可能的情況下批次處理操作，以減少網路往返總次數。

摘要

透過將 AWS 基礎設施適當調整規模以符合實際運算與資料庫容量需求，資料空間參與者可在不影響資料安全性與主權的前提下，達成顯著的成本節省，而資料安全性與主權正是資料空間的價值所在。業務關鍵與非關鍵工作負載組態的比較，展示了如何有效結合 Amazon Aurora、AWS Fargate Spot 與 Amazon S3 等 AWS 服務，以平衡資料主權、效能與成本效率。

隨著資料空間在各產業與地區的採用率提升，了解這些成本動態在規劃網路參與時變得越來越重要。本系列文章中的模式與估算為規劃跨組織資料策略與 AWS 上的資料空間之旅提供了基礎。

若要開始，請評估您的工作負載關鍵性，以決定業務關鍵或非關鍵組態是否符合您的需求。然後使用 AWS Pricing Calculator 估算您特定資料量、區域與使用模式的成本。若需端對端參考實作，請探索 Dataspace Connector on AWS 專案，該專案結合 Infrastructure-as-Code、自訂 EDC 擴充功能與 AI 工具整合。

參考資料

關於作者