# 經濟實惠的資源
為工作負載採用適當的服務、資源和組態，是節省成本的關鍵。建立經濟實惠的資源時，請考慮下列事項：
您可利用 AWS Solutions Architects、AWS Solutions、AWS Reference Architectures 和 APN Partners，依照您所了解，協助您選擇架構。
**Topics**
+ [選取服務時評估成本](evaluate-cost-when-selecting-services.md)
+ [選取正確的資源類型、大小和數量](select-the-correct-resource-type-size-and-number.md)
+ [選擇最佳定價模式](select-the-best-pricing-model.md)
+ [資料傳輸計劃](plan-for-data-transfer.md)
# 選取服務時評估成本
**Topics**
+ [COST05-BP01 識別組織的成本要求](cost_select_service_requirements.md)
+ [COST05-BP02 分析工作負載的所有元件](cost_select_service_analyze_all.md)
+ [COST05-BP03 對每個元件執行徹底的分析](cost_select_service_thorough_analysis.md)
+ [COST05-BP04 選取具成本效益授權的軟體](cost_select_service_licensing.md)
+ [COST05-BP05 選取此工作負載的元件，以按照組織優先事項來優化成本](cost_select_service_select_for_cost.md)
+ [COST05-BP06 對不同用量執行一段時間內的成本分析](cost_select_service_analyze_over_time.md)
# COST05-BP01 識別組織的成本要求
與團隊成員一起為此工作負載定義成本最佳化與其他支柱 (例如效能和可靠性) 之間的平衡。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
大多數組織的資訊技術 (IT) 部門會由多個小型團隊組成，每個團隊都有自己的議程和重點領域，而這會反映出其團隊成員的專業和技能。您需要了解組織的整體目標、優先順序、目標，以及每個部門或專案如何為這些目標做出貢獻。對於實現組織目標和全面預算規劃來說，將所有重要資源進行分類至關重要，這些資源包括人員、設備、技術、材料和外部服務。採用這種系統化方法來識別和了解成本，是為組織建立實際、可靠成本計畫的基礎。
為工作負載選取服務時，關鍵是了解組織的優先事項。在成本最佳化和其他 AWS Well-Architected Framework 支柱之間建立平衡，例如效能和可靠性。此流程應有系統且定期地進行，以反映組織目標、市場條件和營運動態的變化。完全成本優化的工作負載是最符合您組織需求的解決方案，不一定是成本最低的解決方案。與組織中的所有團隊 (例如產品、業務、技術和財務團隊) 會面以收集資訊。評估在相互衝突的利益或替代方法之間做出權衡的影響，以協助您在確認工作重點或選擇行動方案時做出明智的決定。
例如，新功能加速上市可能是成本優化所強調的重點，或您可為非關聯式資料選擇關聯式資料庫，以便更輕鬆地遷移系統，而非遷移至針對您的資料類型優化的資料庫並更新您的應用程式。
### 實作步驟
+ **確定組織的成本要求**與您組織的團隊成員開會，包括產品管理人員、應用程式擁有者、開發和營運團隊、管理層和財務部人員。排定此工作負載及其元件的 Well-Architected 支柱優先順序。輸出應為依序列出的支柱清單。您也可以為每個支柱新增加權，以指出相應支柱有多少個額外焦點，或兩個支柱之間的焦點有多相似。
+ **解決技術債務並將其記錄在案：**在工作負載檢閱期間，處理技術債務。記錄積存項目以在將來重新檢視工作負載，目標是重構或重新架構以將工作負載進一步最佳化。向其他利益相關者清楚傳達所做出的權衡至關重要。
## 資源
**相關的最佳實務：**
+ [ REL11-BP07 建構您的產品以滿足可用性目標和運作時間服務等級協議 （SLAs） ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_service_level_agreements.html)
+ [ OPS01-BP06 評估權衡 ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
**相關文件：**
+ [AWS 總擁有成本 （TCO） 計算器](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/)
+ [雲端產品](https://aws.amazon.com/products/)
# COST05-BP02 分析工作負載的所有元件
確認會分析每個工作負載元件，無論目前大小或目前成本為何。審查工作應反映潛在的效益，例如目前和預計的成本。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
旨在為組織提供商業價值的工作負載元件可能包含各種服務。對於每個元件，可以選擇特定的 AWS 雲端 服務來滿足業務需求。這個選擇可能會受到熟悉與否或之前使用這些服務的經驗等因素所影響。
在確定 [COST05-BP01 確定組織的成本要求](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_select_service_requirements.html)中所述的組織要求之後，請對工作負載中的所有元件執行徹底分析。考慮當前和預測的成本與大小來分析每個元件。針對工作負載生命週期中的任何潛在工作負載節省來考慮分析成本。在分析此工作負載的所有元件上所花費的努力應與最佳化該特定元件所預期的潛在節省或改進相當。例如，如果所提議資源的成本是每月 10 美元，而低於預測的負載不會超過每月 15 美元，則努力一天以減少 50% 成本 (每月 5 美元) 可能會超過系統生命週期內的潛在利益。使用更快速且更有效率的資料型估算，會為此元件建立最佳整體結果。
工作負載可能會隨時間改變，而且如果工作負載架構或用量變化，適當的服務組合可能並非最佳。選擇服務的分析必須納入目前和未來的工作負載狀態以及用量水平。為未來的工作負載狀態或用量實作服務，可減少或消除未來變更所需的工作量，藉此降低整體成本。例如，使用 EMR Serverless 最初可能是合適的選擇。但是，隨著該服務的取用量增加，轉換到 EMR on EC2 可以降低工作負載中該元件的成本。
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 和 AWS Cost and Usage Report ([CUR](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)) 可分析概念驗證 (PoC) 或執行環境的成本。也可以使用 [AWS 定價計算工具](https://calculator.aws/#/) 來估算工作負載成本。
撰寫工作流程，供技術團隊審核其工作負載。讓此工作流程保持簡單，同時也涵蓋所有必要步驟，以確保團隊了解工作負載的每個元件及其定價。然後，您的組織可以根據每個團隊的特定需求來遵循和自訂此工作流程。
1. **列出工作負載使用的每個服務：**這是一個很好的起點。確定目前使用的所有服務以及成本來源。
1. **了解這些服務的定價方式：**了解每項服務的[定價模式](https://aws.amazon.com/pricing/)。根據用量、資料傳輸和特定功能定價等因素，不同的 AWS 服務會有不同的定價模式。
1. **專注於具有非預期工作負載成本且與預期用量和業務結果不符的服務：**使用 AWS Cost Explorer 或 AWS Cost and Usage Report 識別成本與價值或用量不成比例的異常值或服務。將成本與業務成果相互關聯以優先考慮最佳化工作至關重要。
1. **使用 AWS Cost Explorer、CloudWatch Logs、VPC Flow Logs 和 Amazon S3 Storage Lens，了解這些高成本的根本原因：**這些工具有助於高成本的診斷。每項服務都可提供不同的視角來檢視和分析使用情況和成本。例如，Cost Explorer 可協助判斷整體成本趨勢，CloudWatch Logs 可提供營運洞察，VPC Flow Logs 可顯示 IP 流量，而 Amazon S3 Storage Lens 則適用於儲存分析。
1. **使用 AWS Budgets 為服務或帳戶的某些金額設定預算：**設定預算是管理成本的有效方式。使用 AWS Budgets 設定自訂預算閾值，並在成本超過這些閾值時接收提醒。
1. **設定 Amazon CloudWatch 警示以傳送帳單和用量提醒：**設定成本和用量指標的監控和提醒。CloudWatch 警示可在超出特定閾值時通知您，從而縮短干預回應時間。
透過對所有工作負載元件進行策略審查 (無論其目前屬性為何)，可隨著時間的推移帶來顯著的改進和財務方面的節省。在這個審查流程中所投入的努力應經過深思熟慮，並仔細考慮可能實現的潛在優勢。
### 實作步驟
+ **列出工作負載元件：**建立工作負載元件清單。使用此清單可確認是否已分析每個元件。所做的工作應反映貴組織優先事項所定義之工作負載的關鍵性。按功能將資源分組在一起以提高效率 (例如，生產資料庫儲存 (若有多個資料庫的話))。
+ **設定元件清單的優先順序：**取得元件清單並按照工作順序排列其優先順序。這通常是依最昂貴到最便宜的元件成本排序，或依貴組織優先事項所定義的關鍵性排序。
+ **執行分析：**對於清單上的每個元件，審核可用的選項和服務並選擇最適合您組織優先事項的選項。
## 資源
**相關文件：**
+ [AWS 定價計算工具](https://calculator.aws/#/)
+ [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)
+ [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/)
+ [AWS 雲端 產品](https://aws.amazon.com/products/)
**相關影片：**
+ [AWS 成本最佳化系列：CloudWatch](https://www.youtube.com/watch?v=6imTJUGEzjU)
# COST05-BP03 對每個元件執行徹底的分析
查看每個元件的組織整體成本。考量營運和管理成本以計算總體擁有成本，尤其是在使用雲端供應商的受管服務時。審查工作應反映潛在的效益 (例如，用於分析的時間與元件成本成正比)。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
考量如何節省時間，讓您的團隊能夠專注於淘汰技術負債、創新和附加價值功能，以及創造企業與眾不同之處。例如，您可能需要將內部部署環境中的資料庫盡快「平移」至雲端 (也稱為主機轉換)，然後進行優化。能否使用 AWS 上的受管服務以去除或降低授權成本，進而獲得節省的效益，是值得探討的。AWS 上的受管服務免除了維護服務的營運和管理重擔 (例如修補或升級作業系統)，讓您得以專注於創新和業務。
因為受管服務以雲端規模運作，可使每次交易或服務的成本較低。您可以進行可能的優化以獲得實際的好處，且無須變更應用程式的核心架構。例如，您可能希望透過遷移到諸如 [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) 等資料庫即服務平台，或將應用程式遷移到諸如 [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) 等全受管平台，以減少管理資料庫執行個體所花費的時間。
通常受管服務具有屬性，您可設定以確保備充足容量。您必須設定並監控這些屬性，使得額外的容量保持最低程度，並且獲得最大效能。您可使用 AWS 管理主控台 或 AWS API 和 SDK 來修改 AWS Managed Services 的屬性，使資源需求與持續變動的需求保持一致。例如，可將 Amazon EMR 叢集 (或 Amazon Redshift 叢集上) 節點的數量增加或減少，以便擴展或者縮減。
您也可將多個執行個體裝填到一項 AWS 資源上，啟動密度更高的使用。例如，可將多個小資料庫佈建至單一 Amazon Relational Database Service (Amazon RDS) 資料庫執行個體。隨著用量增長，可使用快照和恢復程序，將其中一個資料庫遷移至專用 Amazon RDS 資料庫執行個體。
將工作負載佈建至受管服務上時，您必須了解調整服務容量的要求。這些要求通常是時間、心力和對一般工作負載運作的影響。佈建的資源必須允許發生任何變更，佈建必要的額外開銷來實現。為了修改服務所需持續投注的心力，利用與系統和監控工具例如 Amazon CloudWatch 相整合的 API 和 SDK，可降低為幾乎是零。
[Amazon RDS](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/) 和 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) 可提供受管資料庫服務。[Amazon Athena](https://aws.amazon.com/athena/)、[Amazon EMR](https://aws.amazon.com/emr/) 和 [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) 可提供受管分析服務。
[AMS](https://aws.amazon.com/managed-services/) 是代表企業客戶和合作夥伴營運 AWS 基礎設施的服務。它提供安全且合規的環境，您可以將工作負載部署至其中。AMS 使用企業雲端營運模型與自動化，讓您符合組織需求、更快速地遷移至雲端，以及降低持續管理成本。
**實作步驟**
+ **執行徹底的分析：**使用元件清單，從最高優先順序到最低優先順序處理每個元件。對於優先順序更高且成本更高的元件，請執行額外的分析並評估所有可用選項及其長期影響。對於優先順序較低的元件，評估用量的變更是否會變更元件的優先順序，然後執行適當的工作分析。
+ **比較受管和非受管資源：**考慮您管理的資源的營運成本，並將其與 AWS 受管資源進行比較。例如，審查在 Amazon EC2 執行個體上執行的資料庫，並且與 Amazon RDS 選項 (AWS 受管服務) 比較，或將 Amazon EMR 相較於在 Amazon EC2 上執行 Apache Spark。從自我管理工作負載移轉至 AWS 全受管工作負載時，請仔細研究您的選項。要考慮的三個最重要的因素是您要使用的[受管服務類型](https://aws.amazon.com/products/?&aws-products-all.q=managed)、將用來[遷移資料](https://aws.amazon.com/big-data/datalakes-and-analytics/migrations/)的程序，以及了解 [AWS 共同責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)。
## 資源
**相關文件：**
+ [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/)
+ [AWS 雲端 產品](https://aws.amazon.com/products/)
+ [AWS 共同責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)
**相關影片：**
+ [為什麼要移至受管資料庫？](https://www.youtube.com/watch?v=VRFdc-MVa4I)
+ [什麼是 Amazon EMR 以及我該如何使用它來處理資料？](https://www.youtube.com/watch?v=jylp2atrZjc)
**相關範例：**
+ [為什麼要移至受管資料庫](https://aws.amazon.com/getting-started/hands-on/move-to-managed/why-move-to-a-managed-database/)
+ [使用 AWS DMS 將來自相同 SQL Server 資料庫的資料整合到單一的 Amazon RDS for SQL Server 資料庫](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/)
+ [將資料大規模交付到 Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/getting-started/hands-on/deliver-data-at-scale-to-amazon-msk-with-iot-core/?ref=gsrchandson)
+ [將 ASP.NET Web 應用程式遷移至 AWS Elastic Beanstalk](https://aws.amazon.com/getting-started/hands-on/migrate-aspnet-web-application-elastic-beanstalk/?ref=gsrchandson&id=itprohandson)
# COST05-BP04 選取具成本效益授權的軟體
開放原始碼軟體會剔除對工作負載增加大量成本的軟體授權費用。請在需要授權軟體時，避免繫結至任意屬性 (例如 CPU) 的授權，尋找繫結至輸出或成果的授權。這些授權的成本會更接近其提供的效益。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
開放原始碼源於軟體開發的背景，以指出該軟體符合某些免費發行條件。開放原始碼軟體會由任何人都可以檢查、修改和增強的原始程式碼組成。根據業務要求、工程師的技能、預測用量或其他技術相依性，組織可以考慮使用 AWS 上的開放原始碼軟體，以最大程度地降低其授權成本。換句話說，使用[開放原始碼軟體](https://aws.amazon.com/what-is/open-source/)可降低軟體授權的成本。隨著工作負載的大小擴展，這可能會對工作負載成本產生重大影響。
請根據總成本來測量授權軟體的效益，以將工作負載最佳化。模擬授權的任何變更以及這些變更對工作負載成本的影響。如果廠商變更資料庫授權的成本，調查這會如何影響工作負載的整體效率。考慮廠商的歷史定價公告，以了解其產品授權變更趨勢。授權成本也可能獨立於輸送量或用量，例如依硬體擴展的授權 (CPU 綁定授權)。應該避免這些授權，因為成本可能會快速增加，而不會帶來相應結果。
例如，相較於執行另一個在 Windows 上執行的 Amazon EC2 執行個體，使用 Linux 作業系統在 us-east-1 中操作 Amazon EC2 執行個體可讓您削減大約 45% 的成本。
[AWS 定價計算工具](https://calculator.aws/) 提供了一種全面的方法來比較具有不同授權選項的各種資源的成本，例如 Amazon RDS 執行個體和不同的資料庫引擎。此外，AWS Cost Explorer 還為現有工作負載的成本提供了寶貴的觀點，尤其是具有不同授權的工作負載的成本。對於許可證管理，[AWS License Manager](https://aws.amazon.com/license-manager) 提供一種簡化的方法來監督和處理軟體授權。客戶可以在 AWS 雲端 中部署和操作自己喜歡的開放原始碼軟體。
### 實作步驟
+ **分析授權選項：**審核可用軟體的授權條款。尋找具有所需功能的開放原始碼版本，以及授權軟體的效益是否超過成本。有利條款會使軟體成本符合其提供的效益。
+ **分析軟體供應商：**審核來自於廠商的任何歷史定價或授權變更。尋找不符合成果的任何變更，例如，在特定廠商硬體或平台上執行的懲罰性條款。此外，尋找他們執行稽核和可能施加的懲罰的方式。
## 資源
**相關文件：**
+ [AWS 的開放原始碼](https://aws.amazon.com/opensource/)
+ [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/)
+ [雲端產品](https://aws.amazon.com/products/)
**相關範例：**
+ [開放原始碼部落格](https://aws.amazon.com/blogs/opensource/)
+ [AWS 開放原始碼部落格](https://aws.github.io/)
+ [最佳化和授權評定](https://aws.amazon.com/optimization-and-licensing-assessment/)
# COST05-BP05 選取此工作負載的元件，以按照組織優先事項來優化成本
選取工作負載的所有元件時均應考量成本。這包括使用應用程式層級和受管服務或無伺服器、容器或事件驅動架構，以降低整體成本。使用開放原始碼軟體、無需授權費用的軟體或替代方案，藉以將授權成本降至最低。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
選取所有元件時均應考量服務和選項的成本。這包括使用應用程式層級和受管服務，例如 [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS)、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS) 以及 [Amazon Simple Email Service](https://aws.amazon.com/ses/) (Amazon SES)，以降低整體組織成本。
使用無伺服器和容器進行運算，例如 [AWS Lambda](https://aws.amazon.com/lambda/) 及針對靜態網站的 [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3)。如果可能，將您的應用程式容器化，並使用 AWS 受管容器服務，例如 [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS) 或 [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (Amazon EKS)。
使用開放原始碼軟體或沒有授權費用的軟體，將授權成本降到最低 (例如，用於運算工作負載的 Amazon Linux，或將資料庫遷移到 Amazon Aurora)。
您可以使用無伺服器或應用程式層級服務，例如 [Lambda](https://aws.amazon.com/lambda/)、[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/)、[Amazon SNS](https://aws.amazon.com/sqs/) 以及 [Amazon SES](https://aws.amazon.com/ses/)。這些服務讓您無須管理資源，並提供程式碼執行、佇列服務和訊息傳遞功能。另一個好處是，這些服務可隨用量擴展效能和成本，因此能夠有效率地分配成本和劃分歸屬。
無伺服器服務也可以使用[事件驅動型架構](https://aws.amazon.com/what-is/eda/)。事件驅動型架構是推送架構，因此一切都會在事件呈現於路由器時隨需進行。如此，您就無須付費持續進行輪詢以檢查事件。這表示網路頻寬耗用量、CPU 使用率、閒置機群容量和 SSL/TLS 交握都可降低。
如需有關無伺服器的詳細資訊，請參閱 [Well-Architected 無伺服器應用程式聚焦白皮書](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)。
### 實作步驟
+ **選取每個服務以最佳化成本：**使用您的優先順序清單和分析，選取最符合您組織優先事項的每個選項。與其增加容量以符合需求，您應考慮使用其他選項，以較低的成本獲得更好的效能。例如，您應審查資料庫在 AWS 上的預期流量，並考慮增加執行個體大小，或使用 Amazon ElastiCache 服務 (Redis 或 Memcached) 為資料庫提供快取的機制。
+ **評估事件驅動型架構：**使用無伺服器架構也可讓您為分散式微型服務應用程式建置事件驅動架構，以利設計可擴展、彈性、敏捷且符合成本效益的解決方案。
## 資源
**相關文件：**
+ [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/)
+ [AWS Serverless](https://aws.amazon.com/serverless/)
+ [什麼是事件驅動型架構](https://aws.amazon.com/what-is/eda/)
+ [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/)
+ [雲端產品](https://aws.amazon.com/products/)
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis)
**相關範例：**
+ [事件驅動型架構入門](https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/)
+ [事件驅動型架構](https://aws.amazon.com/event-driven-architecture/)
+ [Statsig 如何使用 Amazon ElastiCache (Redis OSS) 以 100 倍的成本效益運行](https://aws.amazon.com/blogs/database/how-statsig-runs-100x-more-cost-effectively-using-amazon-elasticache-for-redis/)
+ [使用 AWS Lambda 函數的最佳實務](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)
# COST05-BP06 對不同用量執行一段時間內的成本分析
工作負載可能隨時間變更。某些服務或功能在不同的用量層級上更具成本效益。按預計用量對每個元件執行一段時間內的分析，讓工作負載在其生命週期內保持成本效益。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
隨著 AWS 發佈新的服務和功能，工作負載的最佳服務可能會改變。所需的努力應與潛在效益相符。工作負載審核頻率取決於您的組織需求。如果成本高昂，則更快實作新的服務可節省最多成本，因此更頻繁的審核是有利的。另一個需要審核的方面是使用模式的變更。用量的重大變更可能表示替代服務更理想。
如果需要將資料移至 AWS 雲端 中，您可以選取 AWS 所提供的各種服務以及合作夥伴工具，以便遷移您的資料集，無論是檔案、資料庫、機器映像、區塊磁碟區甚或磁帶備份均可。例如，若要對 AWS 移入或移出大量資料，或是在邊緣處理資料，您可以使用其中一項 AWS 專用裝置，以符合成本效益的方式離線移動數以 PB 計的資料。另一個範例是，在資料傳輸速率較高時，直接連線服務可能會比 VPN 更便宜，為您的企業提供所需的連線能力。
根據對不同用量在一段時間內的成本分析，審查您的擴展活動。分析結果，確認是否可以調整擴展政策，以使用多個執行個體類型和購買選項新增執行個體。審查您的設定，確認是否可以降低最小值，以較小的機群大小處理使用者要求，以及新增更多資源以符合預期的高需求。
透過與組織中的利益相關者討論，針對不同使用情況執行成本分析，並使用 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) 的預測功能來預測服務變更的潛在影響。使用 AWS Budgets、CloudWatch 帳單警示和 AWS Cost Anomaly Detection 來監控用量等級發佈，以快速識別及實作最符合成本效益的服務。
**實作步驟**
+ **定義預測使用模式：**與您的組織 (例如行銷和產品擁有者) 合作，記錄工作負載的預期和預測使用模式。與利益相關者討論關於歷史和預測成本與用量增加的議題，並確定這類增加符合業務要求。識別您預期會有較多使用者使用 AWS 資源的日曆日、週或月，這表示您應增加現有資源的容量或採用其他服務，以降低成本並提升效能。
+ **根據預測用量執行成本分析：**使用定義的使用模式，在上述每個點執行分析。分析工作應反映潛在成果。例如，如果用量變化很大，則應執行徹底的分析以驗證任何成本和變化。換句話說，當成本增加時，企業的用量也應增加。
## 資源
**相關文件：**
+ [AWS 總體擁有成本 (TCO) 計算器](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 儲存類別](https://aws.amazon.com/s3/storage-classes/)
+ [雲端產品](https://aws.amazon.com/products/)
+ [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [雲端資料遷移](https://aws.amazon.com/cloud-data-migration/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)
**相關影片：**
+ [AWS OpsHub for Snow Family](https://www.youtube.com/watch?v=0Q7s7JiBCf0)
# 選取正確的資源類型、大小和數量
透過選取得最佳資源類型、大小和數量，您就能以最低成本資源滿足技術需求。精簡化活動會考量工作負載的所有資源、每個個別資源的所有屬性，以及精簡化操作所涉及的工作。精簡化可以是一個反覆程序，由用量模式改變和外在因素啟動，例如 AWS 降價或新增 AWS 資源類型。如果在工作負載生命週期內，精簡化的成本比潛在節省成本大，則精簡化也可能是一次性的。
在 AWS 中有若干種不同的方法：
**Topics**
+ [COST06-BP01 執行成本建模](cost_type_size_number_resources_cost_modeling.md)
+ [COST06-BP02 根據資料選取資源類型、大小及數目](cost_type_size_number_resources_data.md)
+ [COST06-BP03 根據指標自動選取資源類型、大小和數目](cost_type_size_number_resources_metrics.md)
+ [COST06-BP04 考慮使用共用資源](cost_type_size_number_resources_shared.md)
# COST06-BP01 執行成本建模
識別組織要求 (例如業務需求和現有承諾)，並對工作負載及其每個元件執行成本建模 (整體成本)。在不同預測負載下對工作負載執行基準測試活動，並比較成本。建模工作應反映潛在效益。例如，花費的時間與元件成本成正比。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
為您的工作負載及其每個元件執行成本建模，以了解資源之間的平衡，並根據特定效能等級，找出工作負載中每個資源的合適大小。了解成本考量，可在評估計劃性工作負載部署的價值實現成果時，傳達組織的商業案例和決策程序。
在不同預測負載下對工作負載執行基準測試活動，並比較成本。建模工作應反映潛在效益；例如，花費的時間與元件成本或預測的節省成正比。如需最佳實務，請參閱 [AWS Well-Architected 架構的效能達成效率支柱白皮書中的「審查」一節](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html)。
例如，若要為包含運算資源的工作負載建立成本建模，[AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 可協助執行中工作負載的成本建模。它根據歷史用量，提供運算資源的合適大小建議。請確定 CloudWatch Agent 已部署至 Amazon EC2 執行個體以收集記憶體指標，可在 AWS Compute Optimizer 內為您提供更精確的建議。這是運算資源的理想資料來源，因為它是免費服務，並使用機器學習根據風險等級提出多個建議。
您可以將[多種服務](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)搭配自訂日誌作為資料來源使用，以最適化調整其他服務和工作負載元件 (例如 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)) 的操作。AWS Trusted Advisor 會檢查資源並標記低使用率資源，以協助您最適化調整資源並建立成本建模。
以下是成本建模資料和指標的建議：
+ 監控必須精確反映使用者體驗。為時段選擇正確的精細度，並悉心選擇最大或 99%，而非平均值。
+ 為分析的時段選擇涵蓋任何工作負載週期所需的正確精細度。例如，假設所執行的是為期兩週的分析，您可能會忽略高利用率的每月週期，導致佈建不足。
+ 考量您現有的承諾、為其他工作負載選取的定價模式，以及加速創新和專注於核心業務價值的能力，藉此為您的計劃性工作負載選擇正確的 AWS 服務。
**實作步驟**
+ **針對資源執行成本建模：**將工作負載或概念驗證部署到具有要測試之特定資源類型和大小的獨立帳戶。使用測試資料執行工作負載，並記錄輸出結果以及測試執行時的成本資料。然後，重新部署工作負載或變更資源類型和大小，並再次執行測試。納入可能用於這些資源之任何產品的授權費用，以及在建立成本模型時部署和管理這些資源的預估營運 (勞工或工程師) 成本。考慮建立一段時間 (每小時、每日、每月、每月或三年) 的成本模型。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [找出機會進行適當調整](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [成本最佳化：Amazon EC2 調整大小](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [AWS 價格計算器](https://calculator.aws/#/)
**相關範例：**
+ [執行資料驅動的成本建模](https://aws.amazon.com/blogs/mt/how-to-use-aws-well-architected-with-aws-trusted-advisor-to-achieve-data-driven-cost-optimization/)
+ [預估計劃的 AWS 資源組態的成本](https://aws.amazon.com/premiumsupport/knowledge-center/estimating-aws-resource-costs/)
+ [選擇正確的 AWS 工具](https://www.learnaws.org/2019/09/27/choose-right-aws-tools/)
# COST06-BP02 根據資料選取資源類型、大小及數目
根據有關工作負載和資源特性的資料來選擇資源大小或類型。例如，運算、記憶體、輸送量或寫入密集。通常使用工作負載的先前 (內部部署) 版本、文件或其他有關工作負載的資訊來源來進行此選擇。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
Amazon EC2 提供各種執行個體類型，其各自具有不同等級的 CPU、記憶體、儲存和聯網容量，適合不同的使用案例。這些執行個體類型具有 CPU、記憶體、儲存和聯網功能的不同組合，可讓您在選取適合專案的資源組合時獲得多樣選擇。每個執行個體類型都有多種大小，因此您可以根據工作負載的需求調整資源。若要判斷您需要的執行個體類型，請收集有關您計劃在執行個體上執行之應用程式或軟體系統要求的詳細資訊。這些詳細資訊應包括以下內容：
+ 作業系統
+ CPU 核心數量
+ GPU 核心
+ 系統記憶體 (RAM) 數量
+ 儲存類型和空間
+ 網路頻寬要求
確定運算要求的目的以及需要的執行個體，然後探索各種 Amazon EC2 執行個體系列。Amazon 提供下列執行個體類型系列：
+ 一般用途
+ 運算最佳化
+ 記憶體最佳化
+ 儲存優化
+ 加速運算
+ HPC 最佳化
如需深入了解特定 Amazon EC2 執行個體系列可實現的特定目的和使用案例，請參閱 [AWS 執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)。
收集系統要求對於您選取最適合需求的特定執行個體系列和執行個體類型來說非常重要。執行個體類型的名稱由系列名稱和執行個體大小組成。例如，t2.micro 執行個體來自 T2 系列，並且是微型大小。
根據工作負載和資源特性選擇資源大小或類型 (例如，運算、記憶體、輸送量或寫入密集)。通常使用成本建模、工作負載的先前版本 (例如內部部署版本)、文件或其他有關工作負載的資訊來源 (白皮書或已發佈的解決方案) 來進行此選擇。使用 AWS 定價計算器或成本管理工具可協助您對執行個體類型、大小和組態做出明智的決策。
### 實作步驟
+ **根據資料選取資源：**使用成本建模資料來選取預期的工作負載用量層級，然後選擇指定的資源類型和大小。依據成本建模資料，決定虛擬 CPU 數目、總記憶體 (GiB)、本機執行個體儲存體磁碟區 (GB)、Amazon EBS 磁碟區和網路效能等級，並將執行個體所需的資料傳輸速率納入考量。一律根據詳細分析和準確的資料進行選取，以最佳化效能，同時有效地管理成本。
## 資源
**相關文件：**
+ [AWS執行個體類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [成本優化：EC2 調整大小](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html)
**相關影片：**
+ [為您的工作負載選擇合適的 Amazon EC2 執行個體](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [調整您的服務](https://youtu.be/wcp1inFS78A)
**相關範例：**
+ [探索和比較 Amazon EC2 執行個體類型變得更加容易](https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/)
# COST06-BP03 根據指標自動選取資源類型、大小和數目
使用目前執行的工作負載中的指標來選擇正確的大小和類型，以優化成本。為運算、儲存、資料和聯網服務適當地佈建輸送量、大小和儲存。這可透過回饋迴圈 (例如自動調整規模) 或工作負載中的自訂程式碼來完成。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
在工作負載中建立意見回饋迴圈，使用執行中工作負載的作用中指標來變更該工作負載。可以使用受管服務，例如 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)，您可以設定這項服務，以便執行精簡化操作。AWS 還提供 [API、SDK](https://aws.amazon.com/developer/tools/) 和功能，讓您以最小的努力修改資源。您可以設定工作負載來停止和啟動 Amazon EC2 執行個體，以允許變更執行個體大小或執行個體類型。這不僅帶來精簡化的效益，同時消除變更所需的幾乎所有營運成本。
有些 AWS 服務內建自動類型或大小選擇，例如 [Amazon Simple Storage Service Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)。Amazon S3 Intelligent-Tiering 會根據您的使用模式，自動在兩個存取層 (經常存取和不常存取) 之間移動您的資料。
**實作步驟**
+ **透過設定工作負載指標來提高您的可觀測性：**擷取工作負載的關鍵指標。這些指標提供客戶體驗 (例如工作負載輸出) 的指示，並符合資源類型和大小 (例如 CPU 和記憶體用量) 之間的差異。針對運算資源，請分析效能資料以將 Amazon EC2 執行個體調整到適當大小。識別閒置的執行個體，以及未充分使用的執行個體。要查找的關鍵指標是 CPU 使用率和記憶體利用率 (例如，90% 的時間為 40% 的 CPU 利用率，如[使用 AWS Compute Optimizer 正確調整大小和啟用記憶體使用率](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)中所述)。識別在四週期間內，CPU 使用率達到最大且記憶體使用率小於 40% 的執行個體。這些便是需要適當調整大小以降低成本的執行個體。對於 Amazon S3 等儲存資源，您可以使用 [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)，預設情況下，您可以在儲存貯體層級查看各種類別的 28 個指標，以及在儀表板中查看 14 天的歷史資料。您可以依摘要和成本最佳化或事件來篩選 Amazon S3 Storage Lens 儀表板，以分析特定指標。
+ **檢視適當調整大小的建議：**使用 AWS Compute Optimizer 中的適當調整大小的建議和成本管理主控台中的 Amazon EC2 適當調整大小工具，或審核 AWS Trusted Advisor 適當調整資源大小以對工作負載進行調整。不論是 Amazon EC2 執行個體、AWS 儲存類別還是 Amazon RDS 執行個體類型，在適當調整不同資源的大小時，請務必使用[正確的工具](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)，並遵循[適當調整大小準則](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)。針對儲存資源，您可以使用 Amazon S3 Storage Lens，以便能夠檢視物件儲存用量、活動趨勢並提出可行建議，以將成本最佳化並套用資料保護最佳實務。使用 [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/) 從整個組織的指標分析衍生出來的情境式建議，您可以立即採取步驟來最佳化儲存。
+ **根據指標自動選取資源類型和大小：**使用工作負載指標，手動或自動選取工作負載資源。針對運算資源，在應用程式內設定 AWS Auto Scaling 或實作程式碼，可在需要頻繁變更時減少所需的工作量，而且它可能比手動程序更快地實作變更。您可以在單一 Auto Scaling 群組內啟動和自動擴展隨需執行個體和 Spot 執行個體組成的機群。除了獲得使用 Spot 執行個體的折扣之外，您還可以使用預留執行個體或 Savings Plan，以獲得定期隨需執行個體定價的折扣費率。這些因素合在一起可協助您將 Amazon EC2 執行個體所能節省的成本最佳化，並確定應用程式所需的規模和效能。也可以在 [Auto Scaling 群組 (ASG)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 中使用[屬性型執行個體類型選取 (ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 策略，以透過一組屬性 (例如 vCPU、記憶體和儲存) 來表達您的執行個體要求。您可以自動使用新發行的較新一代執行個體類型，並使用 Amazon EC2 Spot 執行個體來存取更大範圍的容量。Amazon EC2 Fleet 和 Amazon EC2 Auto Scaling 會選取和啟動符合指定屬性的執行個體，您不必再手動挑選執行個體類型。對於儲存資源，您可以使用 [Amazon S3 Intelligent Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) 和 [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/) 功能，這些功能可讓您自動選取儲存類別，在資料存取模式變更時自動節省儲存成本，而不會影響效能或營運開銷。
## 資源
**相關文件：**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS 適當調整大小](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [Amazon CloudWatch 功能](https://aws.amazon.com/cloudwatch/features/)
+ [CloudWatch 開始設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingSetup.html)
+ [CloudWatch 發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
+ [Amazon S3 Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)
+ [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/)
+ [使用 SDK 來啟動 Amazon EC2 執行個體](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html)
**相關影片：**
+ [適當調整服務的大小](https://www.youtube.com/watch?v=wcp1inFS78A)
**相關範例：**
+ [Amazon EC2 Fleet 的 Auto Scaling 屬性型執行個體類型選取](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [使用已排程的擴展，針對成本最佳化 Amazon Elastic Container Service](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [Amazon EC2 Auto Scaling 的預測擴展](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [使用 Amazon S3 Storage Lens 將成本最佳化並了解使用情況](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
# COST06-BP04 考慮使用共用資源
對於已在組織層級針對多個業務單位部署的服務，請考慮使用共用資源來提高使用率並降低總體擁有成本 (TCO)。使用共用資源可能是一個具成本效益的選項，可透過使用現有解決方案、共用元件或兩者來集中化管理和成本。在帳戶界限內或專用帳戶中管理常用功能，例如監控、備份和連線。還可以透過實作標準化、減少重複及降低複雜性來降低成本。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
當多個工作負載導致相同的功能時，請使用現有的解決方案和共用元件來改善管理並最佳化成本。請考慮使用現有資源 (尤其是共用資源)，例如非生產資料庫伺服器或目錄服務，透過遵循安全性最佳實務和組織法規來降低雲端成本。為了實現最佳價值和效率，將成本 (使用回報 (showback) 和計費 (chargeback)) 分配到推動消費的相關業務領域至關重要。
*回報 (showback)* 是指將雲端成本分解為可歸因類別的報告，例如消費者、業務單位、總賬帳戶或其他負責實體。回報的目標是向團隊、業務單位或個人展示其所用雲端資源的成本。
*計費 (chargeback)* 是指根據適合特定財務管理程序的策略，將中央服務支出分配給成本單位。對於客戶而言，計費 (chargeback) 會將一個共用服務帳戶產生的成本計入適合客戶報告流程的不同財務成本類別。透過建立計費機制，可以報告不同業務單位、產品和團隊所產生的成本。
工作負載可以分類為關鍵和非關鍵。根據此分類，對於較不重要的工作負載，使用具有一般組態的共用資源。為了進一步最佳化成本，請僅為關鍵工作負載預留專用伺服器。共用資源或在多個帳戶之間佈建資源，以便有效地管理它們。即使在不同的開發、測試和生產環境中，安全共用也是可行的，而且不會影響組織結構。
為了提高您對容器化應用程式的了解並最佳化其成本和用量，請使用分割成本分配資料，它可幫助您根據應用程式使用共用運算和記憶體的方式，將成本分配給個別業務實體。分割成本分配資料可協助您在 Amazon Elastic Container Service (Amazon ECS) 或 Amazon Elastic Kubernetes Service (Amazon EKS) 上執行的容器工作負載中實現任務層級的回報和計費。
對於分散式架構，請建立共用服務 VPC，以集中存取每個 VPC 中工作負載所需的共用服務。這些共用服務可以包含目錄服務或 VPC 端點等資源。為了減少管理開銷和成本，請從中央位置共用資源，而不是在每個 VPC 中建置資源。
當您使用共用資源時，可以節省營運成本、最大化資源利用率並提高一致性。在多帳戶設計中，可以集中託管某些 AWS 服務，並在一個中心位置使用多個應用程式和帳戶來存取它們，以節省成本。您可以使用 [AWS Resource Access Manager (AWS RAM)](https://aws.amazon.com/ram/) 共用其他常用資源，例如 [VPC 子網路和 AWS Transit Gateway 附件](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc)、[AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall) 或 [Amazon SageMaker AI 管道](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker)。在多帳戶環境中，使用 AWS RAM 建立一次資源並與其他帳戶共用。
組織應有效地標記共用成本，並確認大部分成本已標記或分配。如果未有效地分配共用成本，而且沒有人負責共用成本管理，則共用雲端成本可能會螺旋式上升。您應該知道在資源、工作負載、團隊或組織層級產生了哪些成本，因為相較於達成的業務成果，這項知識可增強您對適用層級所提供的價值的了解。最終，組織可以從共用雲端基礎設施的成本節約中獲益。鼓勵共用雲端資源的成本分配，以最佳化雲端支出。
### 實作步驟
+ **評估現有資源：**審核針對工作負載使用類似服務的現有工作負載。視工作負載的元件而定，如果業務邏輯或技術需求允許，請考慮現有平台。
+ **在 AWS RAM 中使用資源共用並進行相應限制：**使用 AWS RAM 與組織內的其他 AWS 帳號共用資源。共用資源時，無需在多個帳戶中重複資源，這樣可將資源維護的作業負擔降到最低。此流程也可協助您安全地與帳戶中的角色和使用者以及其他 AWS 帳戶共用您所建立的資源。
+ **標記資源：**標記屬於成本報告的候選資源，並在成本分類中將其分類。啟動這些與成本相關的資源標籤以進行成本分配，從而了解 AWS 資源使用情況。專注於在成本和用量可見性方面建立適當的精細度級別，並透過成本分配報告和 KPI 追蹤來影響雲端消費行為。
## 資源
**相關的最佳實務：**
+ [SEC03-BP08 在組織內安全地共用資源](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**相關文件：**
+ [ 什麼是 AWS Resource Access Manager？](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)
+ [可與 AWS Organizations 搭配使用的 AWS 服務](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [可共用的 AWS 資源](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html)
+ [AWS 成本和用量 (CUR) 查詢](https://catalog.workshops.aws/cur-query-library/en-US)
**相關影片：**
+ [AWS Resource Access Manager - 具有受管權限的精細存取控制](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [如何設計 AWS 成本分配策略](https://pages.awscloud.com/aws-cfm-talks-how-to-design-your-AWS-cost-allocation-strategy-01122022.html)
+ [AWS Cost Categories](https://www.youtube.com/watch?v=84GYnBBM0Cg)
**相關範例：**
+ [如何計費共用服務：AWS Transit Gateway 範例](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/)
+ [如何使用 CUR 為 Savings Plans 建立計費/回報模式](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-build-a-chargeback-showback-model-for-savings-plans-using-the-cur/)
+ [使用 VPC 共用建立具成本效益的多帳戶微服務架構](https://aws.amazon.com/blogs/architecture/using-vpc-sharing-for-a-cost-effective-multi-account-microservice-architecture/)
+ [透過 AWS 分割成本分配資料提升 Amazon EKS 的成本可見性](https://aws.amazon.com/blogs/aws-cloud-financial-management/improve-cost-visibility-of-amazon-eks-with-aws-split-cost-allocation-data/)
+ [透過 AWS 分割成本分配資料提升 Amazon ECS 和 AWS Batch 的成本可見性](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)
# 選擇最佳定價模式
**執行工作負載成本建模：**考慮工作負載元件的需求，並了解潛在的定價模式。定義元件的可用性需求。判斷是否有多個獨立資源在工作負載中執行相同功能，以及隨時間工作負載需求的變化。比較使用預設隨需定價模式和其他適用的模式的資源成本。考量資源或工作負載元件的任何潛在變更。
**執行定期帳戶層級分析：**執行定期成本建模，可確保跨多個工作負載進行優化。例如，如果多個工作負載使用隨需，則在彙總層級變更的風險會更低，而且實作以承諾為基礎的折扣可獲得更低的整體成本。建議以兩週到一個月的頻率定期執行分析。此分析可讓您進行小幅的調整，因此定價模式的涵蓋範圍會隨著不斷變化的工作負載及其元件不斷演變。
使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 建議工具，尋找承諾折扣的機會。
若要尋找 Spot 工作負載的機會，可使用整體用量的每小時檢視，並尋找定期出現用量或彈性變化的時段。
**定價模式：**AWS 提供多種[定價模式](https://aws.amazon.com/pricing/)，可讓您以最經濟實惠的方式為資源付費，以符合組織需求。下一節說明各種購買模式：
+ 隨需執行個體
+ Spot 執行個體
+ 承諾折扣 – Savings Plans
+ 承諾折扣 – 預留執行個體/容量
+ 地理選擇
+ 第三方協議和定價
**隨需執行個體：**這是預設值，是依用量計費定價的定價模式。當您使用資源 (例如 EC2 執行個體或隨需 DynamoDB 等服務) 時，是支付固定的費率，您無長期承諾。您可基於應用程式的需求，增加或減少資源或服務的容量。隨需有小時費率，但根據服務而定，可以按 1 秒的增量計費 (例如 Amazon RDS 或 Linux EC2 執行個體)。隨需制推薦使用於工作負載期短 (例如四個月的專案) 而會定期出現高峰的應用程式，或是不容許中斷，工作負載無法預料的應用程式。隨需也適用於需要不中斷執行時間，但執行時期不足以獲得承諾折扣的工作負載 (Savings Plans 或預留執行個體)。
**Spot 執行個體：**[Spot 執行個體](https://aws.amazon.com/ec2/spot/)是備用 Amazon EC2 運算容量，可享受隨需價格 90% 的折扣，無需長期承諾。使用 Spot 執行個體，您可以大幅降低執行應用程式的成本，或以相同的預算擴展應用程式的運算容量。與隨需執行個體不同，如果 Amazon EC2 需要取回容量或 Spot 執行個體價格超過設定的價格，則在提前 2 分鐘警告後，Spot 執行個體會中斷。Spot 執行個體被中斷的時間平均少於 5%。
當存在佇列或緩衝，或是有多個資源獨立運作以處理請求 (例如 Hadoop 資料處理) 時，Spot 執行個體是理想選擇。這些工作負載通常具有容錯能力、無狀態和彈性，例如批次處理、大數據和分析、容器化環境和高效能運算 (HPC)。測試與開發環境等非關鍵工作負載也適合選擇 Spot。
也可將 Spot 執行個體整合到多項 AWS 服務中，例如 Amazon EC2 Auto Scaling 群組、Amazon EMR、Amazon Elastic Container Service (Amazon ECS) 以及 AWS Batch。
需要回收 Spot 執行個體時，Amazon EC2 會提前兩分鐘透過 CloudWatch Events 傳送 Spot 執行個體中斷通知，該通知也會記錄在執行個體中繼資料中。您的應用程式可以利用這兩分鐘，儲存其狀態、耗盡執行中容器、上傳最終記錄檔，或從負載平衡器將其本身移除。在這兩分鐘結束時，您可以選擇讓 Spot 執行個體休眠、停止或終止。
在您的工作負載中採用 Spot 執行個體時，請考慮下列最佳實務：
+ **靈活地使用盡可能多的執行個體類型：**靈活使用執行個體類型系列和大小，以提升滿足目標容量需求的可能性、取得可能的最低成本，並將中斷的影響降到最低。
+ **建立工作負載執行位置靈活性：**可用容量會因可用區域而異。透過利用多個備用容量集區，藉此提高實現目標容量的可能性，並取得可能的最低成本。
+ **持續性設計：**將您的工作負載設計為無狀態和具備容錯能力，如此一來，如果某些 EC2 容量中斷，也不會影響工作負載的可用性或效能。
+ 我們建議搭配使用 Spot 執行個體、隨需和 Savings Plans/預留執行個體，以實現最大工作負載成本優化及效能。
**承諾折扣 – Savings Plans：**AWS 提供多種方式，讓您透過保留或承諾使用特定數量的資源，以及獲得資源的折扣費率，來降低成本。[Savings Plan](https://aws.amazon.com/savingsplans/) 允許您簽訂一年或三年的每小時消費承諾，並獲得所有資源的折扣定價。Savings Plans 提供 Amazon EC2、AWS Fargate 和 AWS Lambda 等 AWS 運算服務的折扣。當您簽訂承諾時，您需每小時支付該承諾金額，然後以折扣費率從您的隨需用量中扣除。例如，您承諾一小時為 50 USD，而且每小時隨需用量為 150 USD。考量 Savings Plans 的定價，您的特定用量會有 50% 的折扣率。因此，50 USD 的承諾涵蓋 100 USD 的隨需用量。您將支付 50 USD (承諾) 和 50 USD 的剩餘隨需用量。
[Compute Savings Plans](https://aws.amazon.com/savingsplans/pricing/) 是最靈活的，並提供最高 66% 的折扣。它們會自動跨可用區域、執行個體大小、執行個體系列、作業系統、租用、區域和運算服務套用。
[Instance Savings Plans](https://aws.amazon.com/savingsplans/pricing/) 彈性稍低，但提供更高的折扣率 (最多 72%)。它們會自動跨可用區域、執行個體大小、作業系統和租用進行套用。
有三種付款選項：
+ **無預付款：**沒有預付款；您再每月依當月總時數支付調低的每小時費率。
+ **部分預付款：**提供比「無預付款」更高的費率折扣。部分用量預先支付；您再每月依當月總時數支付調低的每小時費率。
+ **全額預付款：**全期的用量預先付清，其餘期間承諾涵蓋的用量不會產生其他成本。
您可以在工作負載中使用這三個購買選項的任意組合。
Savings Plans 會先套用到所購買帳戶的用量，從最高折扣百分比到最低，然後套用到所有其他帳戶的合併用量，從最高折扣百分比到最低。
建議您在沒有用量或資源 (例如管理帳戶) 的帳戶中購買所有 Savings Plans。這可確 Savings Plan 適用於所有用量的最高折扣費率，獲得最大折扣金額。
工作負載和用量通常會隨時間變化。建議隨時間持續購買少量 Savings Plans 承諾。這可確保您維持高水準的涵蓋範圍，以獲得最大折扣，而且您的計畫隨時都符合工作負載和組織需求。
請勿在您的帳戶中設定目標涵蓋範圍，因為折扣可能會有變化。涵蓋範圍不一定表示高潛在節省。您的帳戶的涵蓋範圍可能很低，但如果您的用量是由小型執行個體所組成，並使用授權作業系統，則潛在節省可能只有百分之幾。您應該追蹤並監控 Savings Plan 建議工具提供的潛在成本節省。在 Cost Explorer 中經常審核 Savings Plans 建議 (執行定期分析) 並繼續購買承諾，直到估算的節省低於組織所需的折扣。例如，追蹤和監控您的潛在折扣是否低於 20%，如果超過此值，則必須進行購買。
監控使用率和涵蓋範圍，但僅偵測變更。請勿瞄準特定使用率百分比或涵蓋範圍百分比，因為這不一定會隨節省而擴展。確保購買 Savings Plans 會導致涵蓋範圍增加，如果涵蓋範圍或使用率減少，則確保這些計畫已量化且已知。例如，您將工作負載資源遷移到較新的執行個體類型，這會降低現有計畫的使用率，但效能效益超過節省的減少。
**承諾折扣 – 預留執行個體/承諾：**與 Savings Plans 類似，[預留執行個體](https://aws.amazon.com/ec2/pricing/reserved-instances/) (RI) 為執行最低資源量的承諾提供最高 72% 的折扣。預留執行個體可用於 Amazon RDS、Amazon OpenSearch Service、Amazon ElastiCache、Amazon Redshift 和 DynamoDB。Amazon CloudFront 和 AWS Elemental MediaConvert 也會在您做出最低用量承諾時提供折扣。預留執行個體目前可用於 Amazon EC2，但 Savings Plans 提供相同的折扣等級、更高的靈活性，而且沒有管理開銷。
預留執行個體提供相同的定價選項，包括無須預付、部分預付款和全部預付款，以及相同的一年或三年期。
預留執行個體可在區域或特定可用區域購買。在可用區域購買時，它們會提供容量保留。
Amazon EC2 具備可轉換的 RI，但由於彈性更高，營運成本更低，因此所有 EC2 執行個體都應使用 Savings Plans。
應該使用相同的程序和指標來追蹤和購買預留執行個體。建議不要追蹤您帳戶的 RI 涵蓋範圍。此外，建議不監控或追蹤使用率百分比，而是在 Cost Explorer 中檢視使用率報告，並使用表格中的淨節省欄。如果節省淨額為明顯較大的負值，則必須採取動作來修復未使用的 RI。
**EC2 Fleet：**[EC2 Fleet](https://aws.amazon.com/about-aws/whats-new/2018/04/introducing-amazon-ec2-fleet/) 是一項功能，它可讓您定義目標運算容量，接著指定執行個體類型以及叢集的隨需執行個體和 Spot 執行個體的平衡。EC2 Fleet 就會符合所定義的容量，自動啟動最低價格的資源組合。
**地理選擇：**當您建構解決方案時，一項最佳實務是盡量將運算資源置於接近使用者之處，以提供較低延遲和強大的資料主權。對於全球受眾，應使用多重位置以滿足這類需要。應選擇能使成本最低的地理位置。
AWS 雲端 基礎設施是以[區域與可用區域](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)為中心建置的。區域是世界上有多個可用區域的實體位置。可用區域由一或多個分散的資料中心所組成，每個都有備援電源、聯網和連線能力，且置放在不同的機構。
每個 AWS 區域在當地市場條件之下運作，各區域的資源定價不同。您可以選擇特定區域以操作解決方案的元件或全部，以便以最低價格於全球執行。您可以使用 AWS 每月成本簡易計算器，估算各個區域的工作負載成本。
**第三方協議和定價：**當您在雲端使用第三方解決方案或服務時，定價結構必須符合成本優化的成果。定價應根據其提供的結果和價值進行擴展。例如，軟體從節省的成本中提取一定比例，節省得 (成果) 越多，收費就越高。依帳單擴展的協議通常不符合成本優化，除非它們為特定帳單每個部分帶來成果。例如，對於提供 Amazon EC2 建議且收取整個帳單一定比例費用的解決方案，如果您使用其他服務，而該解決方案無法提供任何好處，則成本會上升。另一個範例是受管服務，依受管資源成本百分比計費。較大的執行個體大小不一定需要更多的管理工作，但收費更高。確保這些服務定價安排在其服務中包含成本優化計畫或功能，以提升效率。
**Topics**
+ [COST07-BP01 執行定價模式分析](cost_pricing_model_analysis.md)
+ [COST07-BP02 根據成本選擇區域](cost_pricing_model_region_cost.md)
+ [COST07-BP03 選取具成本效益條款的第三方協議](cost_pricing_model_third_party.md)
+ [COST07-BP04 針對此工作負載的所有元件實作定價模式](cost_pricing_model_implement_models.md)
+ [COST07-BP05 在管理帳戶層級執行定價模式分析](cost_pricing_model_master_analysis.md)
# COST07-BP01 執行定價模式分析
分析工作負載的每個元件。判斷元件與資源會執行較長期間 (針對承諾折扣)，還是動態短期執行 (針對 Spot 或隨需)。使用成本管理工具中的建議對工作負載執行分析，並且對這些建議套用商業規則，以達到高報酬。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
AWS 具有多種[定價模式](https://aws.amazon.com/pricing/)，可讓您以最經濟實惠的方式為資源付費，以滿足組織需求並取決於產品。請與您的團隊合作，確認最適當的定價模式。定價模式常會包含多種選項的組合，這取決於您的可用性
**隨需執行個體**可讓您按照時數或秒數 (最少 60 秒) 支付運算或資料庫容量的費用，視您執行的執行個體而定，且不需長期承諾或預付款。
**Savings Plans** 是一種靈活的定價模型，為 Amazon EC2、Lambda 和 AWS Fargate 用量提供較低價格，以換取一年或三年期限內一致用量 (以每小時美元計算) 的承諾。
**Spot 執行個體**是一種 Amazon EC2 定價機制，可讓您以折扣的小時費率 (最高可達隨需價格的 90%) 請求備用運算容量，而無須預先承諾。
透過預付容量，**預留執行個體**可讓您獲得高達 75% 的折扣。如需詳細資訊，請參閱[透過預留來最佳化成本](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html)。
您可能會選擇為生產、品質和開發環境的相關資源納入 Savings Plans。或者，由於沙盒資源僅在需要時開啟，因此您可以為該環境中的資源選擇隨需模型。使用 Amazon [Spot 執行個體](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#spot-instances)降低 Amazon EC2 成本，或使用 [Compute Savings Plans](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#savings-plans) 降低 Amazon EC2、Fargate 和 Lambda 成本。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 建議工具透過 Savings Plans 提供承諾折扣的機會。
如果您過去曾為 Amazon EC2 購買[預留執行個體](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/reserved-instances/?track=costop)，或者已在組織內部建立成本分配實務，則可以暫時繼續使用 Amazon EC2 預留執行個體。但我們建議應擬定相關策略，在未來使用 Savings Plans 作為更具彈性的節省成本機制。您可以隨時重新整理 AWS Cost Management 中的 Savings Plans (SP) 建議，以重新產生新的 Savings Plans 建議。使用預留執行個體 (RI) 來降低 Amazon RDS、Amazon Redshift、Amazon ElastiCache、Amazon OpenSearch Service 成本。有三個選項提供 Saving Plans 和預留執行個體：全額預付款、部分預付款和無預付款。使用 AWS Cost Explorer RI 和 SP 購買建議中提供的建議。
若要尋找 Spot 工作負載的機會，可使用整體用量的每小時檢視，並尋找定期出現用量或彈性變化的時段。您可以將 Spot 執行個體用於具備容錯能力和靈活性的各種應用程式。範例包括無狀態 Web 伺服器、API 端點、大數據和分析應用程式、容器化工作負載、CI/CD 與其他彈性工作負載。
分析您的 Amazon EC2 和 Amazon RDS 執行個體是否可在未使用時 (下班時間和週末) 關閉。相較於全年無休地使用，此方法可讓您降低成本達 70% 甚或更高。如果您有僅需在特定時間啟用的 Amazon Redshift 叢集，您可以暫停叢集，等稍後再繼續執行。當 Amazon Redshift 叢集或 Amazon EC2 和 Amazon RDS 執行個體停止時，運算計費也會隨之停止，而只會計算儲存費用。
請注意，[隨需容量保留](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html) (ODCR) 不是定價折扣。無論您是否以預留容量執行執行個體，都需要支付按隨需費率計算的容量保留費用。若需要為預計要執行的資源提供足夠的容量，就必須考量這些因素。ODCR 無須綁定長期承諾，您不再需要時即可取消，但也可適用 Savings Plans 或預留執行個體所提供的折扣。
**實作步驟**
+ **分析工作負載彈性：**使用 Cost Explorer 中的每小時精細度或自訂儀表板，分析工作負載的彈性。尋找正在執行的執行個體數量的定期變更。短期執行個體是 Spot 執行個體或 Spot 機群的候選項目。
+ [Well-Architected 實驗室：Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity)
+ [Well-Architected 實驗室：成本視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
+ **審核現有定價合約：**針對長期需求，審核目前的合約或承諾。分析您目前擁有的項目，以及有多少承諾正在使用中。運用既有的合約折扣或企業協議。[企業協議](https://aws.amazon.com/pricing/enterprise/)為客戶提供最符合其需求的專屬協議選項。針對長期承諾，請考慮特定執行個體類型、執行個體系列、AWS 區域 和可用區域的預留定價折扣、預留執行個體或 Savings Plans。
+ **執行承諾折扣分析**：在您的帳戶中使用 Cost Explorer，審核 Savings Plans 和預留執行個體建議。要驗證您是否以所需的折扣和風險實作了正確的建議，請遵循 [Well-Architected 實驗室](https://wellarchitectedlabs.com/cost/costeffectiveresources/)。
## 資源
**相關文件：**
+ [存取預留執行個體建議](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [AWS Enterprise](https://aws.amazon.com/pricing/enterprise/)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [Well-Architected 實驗室：Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity)
+ [Well-Architected 實驗室：成本視覺化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
+ [Well-Architected 實驗室：定價模型](https://wellarchitectedlabs.com/Cost/CostEffectiveResources.html)
# COST07-BP02 根據成本選擇區域
每個區域的資源定價可能不同。識別區域成本差異，並僅部署於具有較高成本的區域，以符合延遲、資料落地和資料主權要求。考量區域成本，有助於讓您針對此工作負載支付最低的總價。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
[AWS 雲端 基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/)是全球性的，託管在[世界各地的多個地點](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)，並圍繞 AWS 區域、可用區域、Local Zones、AWS Outposts 和 Wavelength Zones 而建置。區域是世界上的實體位置，每個區域各有一個地理區域，而 AWS 在其中有多個可用區域。可用區域是每個區域內的多個隔離位置，由一或多個分散的資料中心組成，各自有其備援電力、聯網和連線能力。
每個 AWS 區域 各在當地市場條件之下運作，且各區域的資源定價因土地、光纖設施、電力和稅賦等因素而有所差異。您可以選擇特定區域以操作解決方案的元件或全部，以便以最低價格於全球執行。使用 [AWS Calculator](https://calculator.aws/#/)，按位置類型 (區域、Wavelength Zone 和 Local Zone) 和區域搜尋服務，以預估您的工作負載在不同區域中的成本。
當您建構解決方案時，一項最佳實務是盡量將運算資源置於接近使用者之處，以提供較低延遲和強大的資料主權。根據您的業務、資料隱私權、效能和安全要求，選取適當的地理位置。對於全球各地都有使用者的應用程式，請使用多個位置。
如果您在資料隱私權、安全和業務要求方面不受約束，請使用提供較低 AWS 服務價格的區域來部署工作負載。例如，如果您的預設區域是亞太地區 (雪梨) (`ap-southwest-2`)，且沒有使用其他區域方面的限制 (例如資料隱私權、安全)，則將非關鍵性 (開發和測試) Amazon EC2 執行個體部署在美國東部 (維吉尼亞北部) (`us-east-1`) 區域，將可降低成本。
![\[此圖顯示不同區域的合規性、延遲、成本以及服務和功能。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/cost-optimization-pillar/images/region-feature-matrix.png)
上方的矩陣表顯示區域 6 是這種情況下的最佳選擇，因為與其他區域相比，其延遲很低、服務可供使用，並且是成本最低的區域。
## 實作步驟
+ **審核 AWS 區域 定價：**分析目前區域的工作負載成本。依服務和用量類型，從最高成本開始，計算其他可用區域的成本。如果預測儲存超過移動元件或工作負載的成本，請遷移至新區域。
+ **審核多區域部署的要求：**分析您的業務要求和義務 (資料隱私權、安全或效能)，確認是否有任何限制使您無法使用多個區域。如果沒有使用單一區域的限制，請使用多個區域。
+ **分析所需的資料傳輸：**選取區域時，請考慮資料傳輸成本。將資料存放在接近客戶與資源之處。選取資料流動成本較低、且資料傳輸最少的 AWS 區域。根據您對資料傳輸的業務需求，可以使用 [Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[AWS PrivateLink](https://aws.amazon.com/privatelink/)、[AWS Direct Connect](https://aws.amazon.com/directconnect/) 和 [AWS Virtual Private Network](https://aws.amazon.com/vpn/) 來降低聯網成本、改善效能並增強安全性。
## 資源
**相關文件：**
+ [存取預留執行個體建議](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [區域表](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [常見架構的資料傳輸成本概觀](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [全球部署的成本考量](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-considerations-for-global-deployments/)
+ [為工作負載選取區域時應考慮的事項](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
# COST07-BP03 選取具成本效益條款的第三方協議
具成本效益的協議和條款可確保這些服務的成本隨其提供的優勢而擴展。選擇可在為您的組織提供額外優勢時擴展的協議和定價。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
市場上有多種產品可以幫助您管理雲端環境的成本。它們在功能方面可能會有一些差異，而這取決於客戶要求，例如有些客戶專注於成本管控或成本可見性，其他客戶則專注於成本最佳化。有效成本最佳化和管控的一個關鍵因素是使用具有必要功能和合適定價模式的合適工具。這些產品具有不同的定價模式。有些產品會向您收取每月賬單的一定百分比，有些產品則收取所實現節省金額的百分比。理想情況下，請只為您需要的功能付費。
當您在雲端中使用第三方解決方案或服務時，定價結構務必要符合您想要的成果。定價應根據其提供的結果和價值進行擴展。例如，在會從節省的成本中提取一定比例的軟體中，節省的成本 (成果) 越多，收費就越高。會隨著開支增加而要支付更多費用的授權協議可能不會永遠對您的成本最佳化目標有利。但是，如果供應商能為您帳單的所有部分提供明確的效益，則此擴展費用可能是合理的。
例如，如果您使用其他無效益的服務，則會提供 Amazon EC2 建議並收取整個帳單一定比例的解決方案可能會變得更加昂貴。另一個範例是受管服務，其會依受管資源成本的一定百分比計費。較大的執行個體大小不一定需要更多的管理工作，但收費會更高。請確認這些服務定價安排在其服務中包含成本最佳化計劃或功能，以提升效率。
客戶可能會發現市場上的這些產品更先進或更易於使用。您需要考慮這些產品的成本，並考慮長遠的潛在成本最佳化成果。
### 實作步驟
+ **分析第三方協議與條款：**審核第三方協議中的定價。針對不同的用量等級執行建模，並將新成本納入考量，例如新服務用量，或因工作負載成長而產生的目前服務增加量。決定額外成本是否為您的企業提供所需的優勢。
## 資源
**相關文件：**
+ [存取預留執行個體建議](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
# COST07-BP04 針對此工作負載的所有元件實作定價模式
永久執行的資源應使用預留容量，例如 Savings Plans 或預留執行個體。設定短期容量以使用 Spot 執行個體或 Spot 機群。隨需執行個體僅用於無法中斷且執行時間不夠長，以及不適合使用預留容量的短期工作負載 (介於 25% 到 75% 之間的時間，視資源類型而定)。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
為了提高成本效率，AWS 會根據您過去的用量提供多個承諾建議。您可以使用這些建議來了解您可以節省的成本，以及如何使用承諾。您可以將這些服務作為隨需服務、Spot 服務，也可以承諾一定時間，並使用預留執行個體 (RI) 和 Savings Plans (SP) 降低隨需成本。您不僅需要了解每個工作負載元件和多項 AWS 服務，還需要了解這些服務的承諾折扣、購買選項和 Spot 執行個體，才能將工作負載最佳化。
考慮工作負載元件的要求，並了解這些服務的不同定價模式。定義這些元件的可用性要求。判斷是否有多個獨立資源在工作負載中執行相同功能，以及隨時間工作負載需求的變化。比較使用預設隨需定價模式和其他適用的模式的資源成本。考量資源或工作負載元件的任何潛在變更。
例如，讓我們看看 AWS 上的這個 Web 應用程式架構。此範例工作負載包含多種 AWS 服務，例如 Amazon Route 53、AWS WAF、Amazon CloudFront、Amazon EC2 執行個體、Amazon RDS 執行個體、負載平衡器、Amazon S3 儲存和 Amazon Elastic File System (Amazon EFS)。您需要審核這些服務中的每一項，並透過不同的定價模式找出潛在的成本節省機會。其中有些服務可能符合 RI 或 SP 的資格，有些則只能隨需提供。如下圖所示，部分 AWS 服務可以使用 RI 或 SP 來重諾。
![\[使用預留執行個體和 Savings Plans 承諾的 AWS 服務圖表\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/cost-optimization-pillar/images/ri-sp-services.png)
### 實作步驟
+ **實作定價模式：**使用分析結果，購買 Savings Plans、預留執行個體或實作 Spot 執行個體。如果是第一次購買承諾，請選擇清單中的前五項或前十項建議，然後監控和分析未來一兩個月的結果。AWS Cost Management Console 會引導您完成該過程。從主控台審核 RI 或 SP 建議、自訂建議 (類型、付款和期限)，並審核每小時承諾 (例如每小時 20 美元)，然後加入到購物車。折扣會自動套用到符合資格的用量。定期購買少量承諾折扣 (例如每 2 週或每月)。針對可能中斷或無狀態的工作負載，實作 Spot 執行個體。最後，選取隨需 Amazon EC2 執行個體，並為其餘要求配置資源。
+ **工作負載審查週期：**實作工作負載的審查週期，特別分析定價模型涵蓋範圍。一旦工作負載達到所需的涵蓋範圍，請部分購買額外的承諾折扣 (每隔幾個月)，或隨著組織用量的變更進行購買。
## 資源
**相關文件：**
+ [了解您的 Savings Plans 建議](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [存取預留執行個體建議](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [如何購買預留執行個體](https://aws.amazon.com/ec2/pricing/reserved-instances/buyer/)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [Spot 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)
+ [其他 AWS 服務的預留模型](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/reservation-models-for-other-aws-services.html)
+ [Savings Plans 支援的服務](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-services.html)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [購買 Savings Plans 前應考量哪些事項？](https://repost.aws/knowledge-center/savings-plans-considerations)
+ [如何使用 Cost Explorer 來分析我的支出和用量？](https://repost.aws/knowledge-center/cost-explorer-analyze-spending-and-usage)
# COST07-BP05 在管理帳戶層級執行定價模式分析
查看計費和成本管理工具，並檢視承諾和保留的建議折扣，在管理帳戶層級執行定期分析。
**未建立此最佳實務時的曝險等級：**低
## 實作指引
執行定期成本建模可讓您有機會進行多個工作負載間的優化。例如，如果多個工作負載使用隨需執行個體，則在彙總層級變更的風險會更低，而且實作以承諾為基礎的折扣能獲得更低的整體成本。建議以兩週到一個月的頻率定期執行分析。這可讓您進行小幅的調整，因此定價模式的涵蓋範圍會隨著不斷變化的工作負載及其元件不斷演變。
使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 建議工具，在您的管理帳戶中尋找承諾折扣的機會。管理帳戶層級的建議在計算過程中會考量您的 AWS 組織中已啟用預留執行個體 (RI) 或 Savings Plans (SP) 折扣分享的帳戶。計算過程也會在折扣分享啟用時啟動，以推薦可盡量節省整體帳戶成本的承諾。
雖然在許多情況下，在管理帳戶層級購買可省下最多成本，但在某些情況下，您可以考慮在連結帳戶層級購買 SP，例如，您希望先將折扣套用至該連結帳戶中的用量時。成員帳戶建議會在個別帳戶層級上進行計算，以盡可能節省各個獨立帳戶的成本。如果您的帳戶同時擁有 RI 和 SP 承諾，則會按以下順序套用這些承諾：
1. 區域 RI
1. 標準 RI
1. 可轉換 RI
1. Instance Savings Plan
1. Compute Savings Plan
如果您在管理帳戶層級購買 SP，則將根據最高到最低的折扣百分比來套用節省的金額。管理帳戶層級的 SP 會查看所有連結帳戶，並以最高的折扣套用節省的金額。如果您希望限定節省金額的套用項目，您可以在連結的帳戶層級購買 Savings Plan，如此，每當該帳戶執行符合資格的運算服務時，就會先為該項目套用折扣。當帳戶未執行符合資格的運算服務時，折扣將會分享到相同管理帳戶下的其他連結帳戶。折扣分享預設為開啟，但可視需要關閉。
在合併帳單系列中，Savings Plans 會先套用至擁有者帳戶的用量，然後套用至其他帳戶的用量。只有在折扣分享啟用時，才會執行此模式。您的 Savings Plans 會先套用至您最高的節省金額百分比。如果有多種用量具有相同的節省金額百分比，則 Savings Plans 會套用至第一個具有最低 Savings Plans 費率的用量。Savings Plans 將繼續套用，直至沒有剩餘用量或您的承諾用盡為止。任何剩餘用量均按隨需費率收費。您可以隨時重新整理 AWS Cost Management 中的 Savings Plans 建議，以重新產生新的 Savings Plans 建議。
分析執行個體的彈性後，您可以採納建議的承諾。使用可能的不同資源選項分析工作負載的短期成本、分析 AWS 定價模型，並使其符合您的業務要求，以找出總體擁有成本和[成本最佳化](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html)機會。
### 實作步驟
**執行承諾折扣分析**：在您的帳戶中使用 Cost Explorer，審核 Savings Plans 和預留執行個體建議。請確實了解 Saving Plan 建議，並估計您的每月支出和每個月節省的成本。審查管理帳戶層級的建議；其計算過程中考量到您的 AWS 組織中已啟用 RI 或 Savings Plans 折扣分享，以盡可能節省帳戶成本的所有成員帳戶間的整體用量。您可以依照 Well-Architected 實驗室的指示，確定在所需的折扣與風險方面，採用了正確的建議。
## 資源
**相關文件：**
+ [AWS 定價如何運作？](https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln)
+ [執行個體購買選項](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [Saving Plan 概觀](file:///Users/mergenf/Documents/WELL%20ARCHITECTED/COST%20OPT%20PILLAR/phase3a/COST06/•%09https:/docs.aws.amazon.com/savingsplans/latest/userguide/sp-overview.html)
+ [Saving Plan 建議](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [存取預留執行個體建議](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [了解 Savings Plans 建議](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [Savings Plans 如何套用於 AWS 使用情況](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html)
+ [具有合併帳單功能的 Savings Plans](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-consolidated-billing/)
+ [開啟共享的預留執行個體和 Savings Plans 折扣](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html)
**相關影片：**
+ [節省高達 90% 的成本並在 Spot 執行生產工作負載](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**相關範例：**
+ [在購買 Savings Plan 前，我應考量哪些事項？](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-considerations/)
+ [如何利用滾動 Savings Plans 降低承諾風險？](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-can-i-use-rolling-savings-plans-to-reduce-commitment-risk/)
+ [何時應使用 Spot 執行個體](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-leveraging-ec2-spot-instances/when-to-use-spot-instances.html)
# 資料傳輸計劃
雲端的一個優勢是它是受管網路服務。您不再需要管理和操作交換器、路由器和其他相關網路設備的叢集。雲端中的聯網資源消耗和支付方式與支付 CPU 和儲存費用相同，您只需按實際用量付費。在雲端進行成本優化時，必須有效率地使用聯網資源。
**Topics**
+ [COST08-BP01 執行資料傳輸建模](cost_data_transfer_modeling.md)
+ [COST08-BP02 選取元件以將資料傳輸成本最佳化](cost_data_transfer_optimized_components.md)
+ [COST08-BP03 實作可降低資料傳輸成本的服務](cost_data_transfer_implement_services.md)
# COST08-BP01 執行資料傳輸建模
收集組織要求並執行工作負載及其每個元件的資料傳輸建模。這可確定其目前資料傳輸要求的最低成本點。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
在設計雲端解決方案時，由於習慣使用內部部署資料中心來設計架構或缺乏知識，通常會忽略掉資料傳輸費用。AWS 中的資料傳輸費用會由來源、目的地和流量的數量來決定。在設計階段考慮這些費用能夠讓您省下成本。了解資料傳輸在工作負載中的發生位置、傳輸成本及其相關效益，對於準確估算總體擁有成本 (TCO) 來說非常重要。這可讓您做出明智的決策，以修改或接受架構決策。例如，您可能有一個多個可用區域組態，您在可用區域之間複寫資料。
您要為會在工作負載中傳輸資料的服務元件建模，並決定這是實現所需可靠性和彈性可接受的成本 (類似於在兩個可用區域中支付運算和儲存費用)。針對不同用量等級建立成本模型。工作負載用量會隨時間改變，在不同等級，不同的服務可能更經濟實惠。
在為資料傳輸建模時，請考慮所擷取的資料量以及資料的來源。此外，也請考慮所處理的資料量以及需要的儲存或運算容量。在建模期間，請遵循工作負載架構的聯網最佳實務，以將潛在的資料傳輸成本最佳化。
AWS 定價計算工具 可以幫助您查看特定 AWS 服務的預估成本和預期的資料傳輸。如果您的工作負載已經在執行 (用於測試目的或在生產前環境中)，請使用 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) 或 [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) 來了解資料傳輸成本並建模。設定概念驗證 (PoC) 或測試工作負載，並以逼真的模擬負載執行測試。您可以根據不同的工作負載需求建立成本模型。
### 實作步驟
+ **確定需求：**在來源與目的地之間規劃的資料傳輸的主要目標和業務需求是什麼？ 所預期的最終業務成果是什麼？ 收集業務要求並定義預期的成果。
+ **識別來源和目的地：**資料傳輸的資料來源和目的地是什麼，例如在 AWS 區域 內部、傳輸至 AWS 服務或傳出到網際網路？
+ [AWS 區域 內的資料傳輸](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-within-region)
+ [AWS 區域 之間的資料傳輸](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-between-regions)
+ [資料傳出到網際網路](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-out-internet)
+ **識別資料分類：**此資料傳輸的資料分類為何？ 這是什麼種類的資料？ 資料有多大？ 資料必須以何種頻率進行傳輸？ 資料敏感嗎？
+ **識別要使用的 AWS 服務或工具：**此資料傳輸使用哪些 AWS 服務？ 是否可將已佈建的服務用於其他工作負載？
+ **計算資料傳輸成本：**使用先前建立的資料傳輸模型 [AWS Pricing](https://aws.amazon.com/pricing/) 來計算工作負載的資料傳輸成本。針對工作負載用量的增加和減少，計算不同用量等級的資料傳輸成本。如果工作負載架構具有多個選項，請計算每個選項的成本進行比較。
+ **將成本與結果連結：**對於產生的每筆資料傳輸成本，請指定其為工作負載達到的結果。如果在元件之間傳輸，可能是用於解耦，如果在可用區域之間傳輸，則可能是用於備援。
+ **建立資料傳輸模型：**收集所有資訊後，為多個使用案例和不同的工作負載建立概念性基礎資料傳輸模型。
## 資源
**相關文件：**
+ [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/)
+ [AWS 定價](https://aws.amazon.com/pricing/)
+ [Amazon EC2 定價](https://aws.amazon.com/ec2/pricing/on-demand/)
+ [Amazon VPC 定價](https://aws.amazon.com/vpc/pricing/)
+ [了解資料傳輸費用](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html)
**相關影片：**
+ [監控和最佳化您的資料傳輸成本](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [S3 Transfer Acceleration](https://youtu.be/J2CVnmUWSi4)
**相關範例：**
+ [常見架構的資料傳輸成本概觀](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [用於聯網的 AWS 規範指引](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortDate&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23network&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)
# COST08-BP02 選取元件以將資料傳輸成本最佳化
選擇所有元件，並設計架構以降低資料傳輸成本。這包括使用廣域網路 (WAN) 最佳化和多可用區域 (AZ) 組態等元件
**未建立此最佳實務時的曝險等級：**中
## 實作指引
資料傳輸建構可將資料傳輸成本降至最低。這可能涉及使用內容交付網路以將資料靠近使用者放置，或從您內部至 AWS 使用專用網路連結。您也可以使用 WAN 優化和應用程式優化，來減少元件之間傳輸的資料量。
將資料傳輸到 AWS 雲端 或於其中傳輸資料時，重要的是根據不同的使用案例來了解目的地、資料性質和可用的網路資源，以便選取合適的 AWS 服務來將資料傳輸最佳化。AWS 提供了一系列針對各種資料遷移要求量身打造的資料傳輸服務。根據組織內的業務需求，選擇正確的[資料儲存](https://aws.amazon.com/products/storage/)和[資料傳輸](https://aws.amazon.com/cloud-data-migration/)選項。
在計劃或審核工作負載架構時，請考慮下列事項：
+ **在 AWS 中使用 VPC 端點**：VPC 端點允許您的 VPC 和支援的 AWS 服務之間建立私有連線。這可讓您避免使用可能會產生資料傳輸成本的公用網際網路。
+ **使用 NAT 閘道：**使用 [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)，以便私有子網路中的執行個體可以連線至網際網路或 VPC 外部的服務。檢查 NAT 閘道後方傳送最多流量的資源是否與 NAT 閘道位於相同的可用區域。如果沒有，請在與該資源相同的可用區域中建立新的 NAT 閘道，以降低跨 AZ 資料傳輸費用。
+ **使用 AWS Direct Connect** Direct Connect 繞過公用網際網路，並在內部部署網路與 AWS 之間建立直接、私有連線。這可能會比透過網際網路傳輸大量資料更具成本效益和一致性。
+ **避免跨區域界限傳輸資料：**在 AWS 區域 之間 (從一個區域到另一個區域) 傳輸資料通常會產生費用。請深思熟慮後再決定是否追求多區域路徑。如需詳細資訊，請參閱[多區域案例](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/multi-region-scenarios.html)。
+ **監控資料傳輸：**使用 Amazon CloudWatch 和 [VPC 流程日誌](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)擷取有關資料傳輸和網路使用情況的詳細資訊。分析 VPC 中擷取到的網路流量資訊，例如進出網路介面的 IP 位址或範圍。
+ **分析網路用量：**使用計量和報告工具 (例如 AWS Cost Explorer、CUDOS Dashboards 或 CloudWatch) 來了解工作負載的資料傳輸成本。
### 實作步驟
+ **選擇用於資料傳輸的元件：**使用 [COST08-BP01 執行資料傳輸建模](cost_data_transfer_modeling.md) 中所述的資料傳輸模型，專注於資料傳輸成本最高的位置或工作負載用量變更時資料傳輸成本最高的位置。尋找替代架構或其他元件，以消除或降低資料傳輸需求 (或降低其成本)。
## 資源
**相關的最佳實務：**
+ [COST08-BP01 執行資料傳輸建模](cost_data_transfer_modeling.md)
+ [COST08-BP03 實作可降低資料傳輸成本的服務](cost_data_transfer_implement_services.md)
**相關文件：**
+ [雲端資料遷移](https://aws.amazon.com/cloud-data-migration/)
+ [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/)
+ [使用 Amazon CloudFront 更快地交付內容](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/)
**相關範例：**
+ [常見架構的資料傳輸成本概觀](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [AWS 網路最佳化秘訣](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [使用 Apache Parquet 格式的 VPC 流程日誌，最佳化效能並降低網路分析成本](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/)
# COST08-BP03 實作可降低資料傳輸成本的服務
實作服務以減少資料傳輸。例如，使用邊緣節點或內容交付網路 (CDN) 將內容提供給終端使用者、在應用程式伺服器或資料庫前面建置快取層，以及使用專用網路連線而非 VPN 來連線至雲端。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
有許多 AWS 服務可以協助您最佳化網路資料傳輸用量。根據您的工作負載元件、類型和雲端架構，這些服務可以協助您在雲端上壓縮、快取、共用和分配流量。
+ [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 是全球內容交付網路，在低延遲和高傳輸速度之下遞送資料。其快取位於全球節點的資料，能減輕您的資源所受的負載。藉由 CloudFront，在最低延遲之下交付內容給全球大量使用者方面，您可減少管理所費的心力。如果您計劃隨著時間的推移增加用量，[安全節省服務包](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/?sc_channel=em&sc_campaign=Launch_mult_OT_awsroadmapemail_20200910&sc_medium=em_whats_new&sc_content=launch_ot_ot&sc_country=mult&sc_geo=mult&sc_category=mult&sc_outcome=launch)可以幫助您節省高達 30% 的 CloudFront 使用率。
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/) 可讓您建立連接至 AWS 的專用網路連線。如此可降低網路成本，增加頻寬，並且比網際網路連線提供更一致的網路體驗。
+ [Site-to-Site VPN](https://aws.amazon.com/vpn/) 可讓您在私有網路和 AWS 全球網路之間建立安全且私有的連線。它非常適合小型辦公室或商業合作夥伴，因為它提供簡便的連線，而且是全受管的彈性服務。
+ [VPC 端點](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html)允許透過私有網路連接各 AWS 服務，可用於降低公有聯網的資料傳輸量和 [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)的成本。[閘道 VPC 端點](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html)不收取小時費用，且支援 Amazon S3 和 Amazon DynamoDB。[介面 VPC 端點](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)由 [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) 提供，收取小時費用和每 GB 使用費。
+ [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)提供內建擴展和管理功能，與獨立 NAT 執行個體相比，成本更低。將 NAT 閘道放置在與高流量執行個體相同的可用區域中，並考慮為需要存取 Amazon DynamoDB 或 Amazon S3 的執行個體使用 VPC 端點，來降低資料傳輸和處理成本。
+ 使用具有運算資源的 [AWS Snow Family](https://aws.amazon.com/snow/) 裝置在邊緣收集和處理資料。AWS Snow Family 裝置 ([Snowball Edge](https://aws.amazon.com/snowcone/)、[Snowball Edge](https://aws.amazon.com/snowball/) 和 [Snowmobile](https://aws.amazon.com/snowmobile/)) 讓您能夠以成本效益高且離線的方式將 PB 規模的資料移至 AWS 雲端。
### 實作步驟
+ **實作服務：**使用資料傳輸建模並審核 VPC Flow Logs，根據您的服務工作負載類型選擇適用的 AWS 網路服務。查看成本最高和磁碟區流量最大的情況。審核 AWS 服務，並評估是否有可減少或移除傳輸的服務，特別是聯網和內容交付方面。另請尋找可重複存取資料或大量資料的快取服務。
## 資源
**相關文件：**
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ [AWS 探索我們的產品](https://aws.amazon.com/)
+ [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/)
+ [Amazon CloudFront](https://aws.amazon.com/cloudfront/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)
+ [Amazon CloudFront 安全防護優惠組合](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/)
**相關影片：**
+ [監控和最佳化您的資料傳輸成本](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [AWS 成本最佳化系列：CloudFront](https://www.youtube.com/watch?v=k8De2AfAN3k)
+ [如何降低 NAT 閘道的資料傳輸費用？](https://www.youtube.com/watch?v=hq4KtPRezus)
**相關範例：**
+ [如何退款共享服務：AWS Transit Gateway 範例](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/)
+ [使用 Athena 查詢和 QuickSight，從成本和用量報告深入了解 AWS 資料傳輸詳細資訊](https://aws.amazon.com/blogs/networking-and-content-delivery/understand-aws-data-transfer-details-in-depth-from-cost-and-usage-report-using-athena-query-and-quicksight/)
+ [常見架構的資料傳輸成本概觀](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [使用 AWS Cost Explorer 分析資料傳輸成本](https://aws.amazon.com/blogs/mt/using-aws-cost-explorer-to-analyze-data-transfer-costs/)
+ [利用 Amazon CloudFront 功能，針對您的 AWS 架構進行成本最佳化](https://aws.amazon.com/blogs/networking-and-content-delivery/cost-optimizing-your-aws-architectures-by-utilizing-amazon-cloudfront-features/)
+ [如何降低 NAT 閘道的資料傳輸費用？](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-reduce-nat-gateway-transfer-costs/)