# 永續性
在建置雲端工作負載時，永續性實務是關於了解所使用服務的影響、量化整體工作負載生命週期的影響，以及應用設計原則和最佳實務來減少這些影響。您可以在下列白皮書中找到規範指引： [永續性支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)。
**Topics**
+ [區域選擇](a-region-selection.md)
+ [因應需求](a-alignment-to-demand.md)
+ [軟體和架構](a-sus-software-architecture.md)
+ [資料](a-sus-data.md)
+ [硬體和服務](a-sus-hardware-and-services.md)
+ [程序和文化](a-sus-process-and-culture.md)
# 區域選擇
**Topics**
+ [SUS 1 如何為您的工作負載選取區域？](w2aac19c17b7b5.md)
# SUS 1 如何為您的工作負載選取區域？
您為工作負載選擇的區域會極大程度地影響其 KPI，包括效能、成本和碳足跡。若要有效改進這些 KPI，請根據您的業務要求和永續性目標，選擇工作負載的區域。
**Topics**
+ [SUS01-BP01 根據您的業務要求和永續性發展目標選擇區域](sus_sus_region_a2.md)
# SUS01-BP01 根據您的業務要求和永續性發展目標選擇區域
根據您的業務要求和永續性發展目標選擇工作負載的區域，以將其 KPI 最佳化，包括效能、成本和碳足跡。
**常見的反模式：**
+ 您可以根據自身所在位置選取工作負載的區域。
+ 您可以將所有工作負載資源合併到單一地理位置。
**建立此最佳實務的優勢：**將工作負載放在 Amazon 可再生能源專案附近或所公佈的碳強度較低的區域附近，有助於降低雲端工作負載的碳足跡。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
AWS 雲端 是會持續擴張的區域和連接點 (POP) 網路，並透過全球網路基礎設施彼此連結起來。您為工作負載選擇的區域會極大程度地影響其 KPI，包括效能、成本和碳足跡。若要有效改進這些 KPI，請根據您的業務要求和永續性發展目標，選擇工作負載的區域。
**實作步驟**
+ 請遵循這些步驟，根據您的業務要求 (包括合規、可用功能、成本和延遲) 評估工作負載的可能區域，並將這些區域列入候選清單：
+ 根據必須遵守的當地法規，確認這些區域符合規範。
+ 使用 [AWS 區域服務清單](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)來檢查區域是否有您執行工作負載時所需的服務和功能。
+ 使用 [AWS 定價計算工具](https://calculator.aws/) 計算工作負載在每個區域的成本。
+ 測試終端使用者所在位置和每個 AWS 區域 之間的網路延遲。
+ 選擇 Amazon 可再生能源專案附近的區域，以及電網公佈的碳強度低於其他位置 (或區域) 的區域。
+ 識別相關的永續性指導方針，根據[溫室氣體協定](https://ghgprotocol.org/) (市場型和位置型方法) 來追蹤和比較逐年的碳排放。
+ 根據您用來追蹤碳排放的方法來選擇區域。如需根據永續性指導方針來選擇區域的詳細資訊，請參閱[如何根據永續性目標來選取工作負載的區域](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)。
## 資源
**相關文件：**
+ [了解您的碳排放預估值](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html)
+ [全球 Amazon](https://sustainability.aboutamazon.com/about/around-the-globe?energyType=true)
+ [可再生能源方法](https://sustainability.aboutamazon.com/amazon-renewable-energy-methodology)
+ [為工作負載選取區域時應考慮的事項](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
**相關影片：**
+ [永續建構和降低您的 AWS 碳足跡](https://www.youtube.com/watch?v=jsbamOLpCr8)
# 因應需求
**Topics**
+ [SUS 2 如何根據您的需求取得適當的雲端資源？](sus-02.md)
# SUS 2 如何根據您的需求取得適當的雲端資源？
使用者和應用程式使用工作負載和其他資源的方式，可協助您找到改善的機會，以達成永續性目標。擴展基礎架構以持續符合需求，並確認您僅使用支援使用者所需的最低資源。讓服務層級符合客戶需求。妥善放置資源，以限制使用者和應用程式使用資源所需的網路。移除未使用的資產。為團隊成員提供滿足其需求的裝置，同時將對永續性的影響降至最低。
**Topics**
+ [SUS02-BP01 動態擴展工作負載基礎架構](sus_sus_user_a2.md)
+ [SUS02-BP02 讓 SLA 符合永續性目標](sus_sus_user_a3.md)
+ [SUS02-BP03 停止建立和維護未使用的資產](sus_sus_user_a4.md)
+ [SUS02-BP04 根據使用者的聯網要求優化其工作負載的地理位置](sus_sus_user_a5.md)
+ [SUS02-BP05 為執行的活動優化團隊成員資源](sus_sus_user_a6.md)
+ [SUS02-BP06 實作緩衝或調節使需求曲線趨於扁平化](sus_sus_user_a7.md)
# SUS02-BP01 動態擴展工作負載基礎架構
利用雲端的彈性動態擴展您的基礎架構，以達到雲端資源的供需平衡，避免工作負載出現過度佈建的容量。
**常見的反模式：**
+ 您不隨著使用者負載擴展基礎架構。
+ 您一律手動擴展基礎架構。
+ 您在擴展事件之後維持增加容量，而不是縮減規模。
**建立此最佳實務的優勢：**設定並測試工作負載彈性有助於有效達到雲端資源的供需平衡，並避免過度佈建的容量。您可以利用雲端中的彈性，在需求尖峰期間或之後自動擴展容量，以確保您使用的資源數量正好足以滿足業務所需。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
雲端提供的彈性可透過各種機制來動態擴展或減少資源，以滿足需求的變化。平衡供需關係可將工作負載受到的影響降到最低。
需求可為固定或可變，需要指標和自動化以確保該項管理不致成為繁重的工作。應用程式可藉由修改執行個體大小進行垂直調整 (縱向擴展或縮減規模)、藉由修改執行個體數目進行水平調整 (縮減或橫向擴展)，或進行兩者的合併調整。
您可以使用多種不同的方法達到資源的供需平衡。
+ **目標追蹤法：**監控您的擴展指標，並視需要自動增加或減少容量。
+ **預測擴展：**縮減每日和每週趨勢的預期。
+ **排程法：**根據可預測的負載變化設定您自己的擴展排程。
+ **服務擴展：** 挑選按設計原本就會擴展的服務 (例如無伺服器)，或提供自動擴展功能。
辨別使用率低或無使用率的時期，並調整資源規模以移除過剩容量、提高效率。
## 實作步驟
+ 彈性會比對您擁有的資源供應與這些資源的需求。執行個體、容器和函數提供了彈性機制，可與自動擴展功能結合使用，或是作為服務功能提供。AWS 提供了多種自動擴展機制，以確保工作負載可在使用者負載較低時迅速輕易地縮減規模。以下是自動擴展機制的幾個範例：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_user_a2.html)
+ 擴展常與 Amazon EC2 執行個體或 AWS Lambda 函數等服務一起討論。請考慮設定非運算服務 (例如 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 讀取和寫入容量單位或 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) 碎片) 以符合需求。
+ 確認會對要部署的工作負載類型驗證擴充或縮減規模的指標。如果您要部署影片轉碼應用程式，則預期為 100% CPU 使用率，且不應做為您的主要指標。您可以將[自訂指標](https://aws.amazon.com/blogs/mt/create-amazon-ec2-auto-scaling-policy-memory-utilization-metric-linux/) (例如記憶體使用率) 用於擴展政策 (如有必要)。若要選擇正確的指標，請考量 Amazon EC2 的下列指引：
+ 指標應為有效的使用率指標，並說明執行個體的忙碌程度。
+ 指標值必須根據 Auto Scaling 群組中的執行個體數量按比例增加或減少。
+ 對於 Auto Scaling 群組請使用[動態擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html)，而非[手動擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html)。我們也建議您在動態擴展中使用[目標追蹤擴展政策](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html)。
+ 確認工作負載部署可處理橫向擴展和縮減事件。建立縮減事件的測試案例，以確認工作負載的行為符合預期，且不會對使用者體驗造成影響 (例如失去黏性工作階段)。您可以使用[活動歷史](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html)來驗證 Auto Scaling 群組的擴展活動。
+ 評估工作負載以取得可預測模式，並在預計發生預測中的變化和隨需規劃變化時主動擴展。透過預測擴展，可以避免過度佈建容量的需求。如需詳細資訊，請參閱 [Amazon EC2 Auto Scaling 的預測擴展](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)。
## 資源
**相關文件：**
+ [Amazon EC2 Auto Scaling 入門](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [EC2 的預測擴展，採用機器學習技術](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [使用 Amazon OpenSearch Service、Amazon Data Firehose 和 Kibana 分析使用者行為](https://aws.amazon.com/blogs/database/analyze-user-behavior-using-amazon-elasticsearch-service-amazon-kinesis-data-firehose-and-kibana/)
+ [什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [在 Amazon RDS 上使用 Performance Insights 監控資料庫負載](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [介紹對於 Amazon EC2 Auto Scaling 預測擴展的原生支援](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [介紹 Karpenter - 一個開放原始碼的高效能 Kubernetes Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
+ [深入探討 Amazon ECS 叢集 Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
**相關影片：**
+ [打造兼具成本、能源和資源優勢的運算環境](https://www.youtube.com/watch?v=8zsC5e1eLCg)
+ [更好、更快、更便宜的運算：成本優化 Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw)
**相關範例：**
+ [實驗室：Amazon EC2 Auto Scaling 群組範例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples)
+ [實驗室：使用 Karpenter 實作自動擴展](https://www.eksworkshop.com/beginner/085_scaling_karpenter/)
# SUS02-BP02 讓 SLA 符合永續性目標
根據您的永續性目標審查並優化工作負載的服務水準協議 (SLA)，例如可用性或資料保留期，以盡可能減少支援工作負載所需的資源，同時繼續滿足商業需求。
**常見的反模式：**
+ 工作負載 SLA 不明或語意不清。
+ 您僅針對可用性和效能定義 SLA。
+ 您對所有的工作負載使用相同的設計模式 (例如多可用區域架構)。
**建立此最佳實務的效益：**讓 SLA 符合永續性目標，可達到最佳資源用量並滿足商業需求。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
SLA 會定義雲端工作負載應有的服務水準，例如回應時間、可用性和資料保留。其影響範圍涵蓋雲端工作負載的架構、資源用量和環境影響。請定期審查 SLA，並做出能大幅降低資源用量的取捨，換取可接受的服務水準降低。
**實作步驟**
+ 定義或重新設計支援永續性目標，同時正好滿足業務要求的 SLA。
+ 做出能大幅降低永續性影響的取捨，換取可接受的服務水準降低。
+ **永續性和可靠性：**高可用性的工作負載往往會耗用較多資源。
+ **永續性和效能：**使用較多資源以提升效能，可能會對環境造成較大的影響。
+ **永續性和安全性：**保護過度的工作負載可能會對環境造成較大的影響。
+ 使用優先執行業務關鍵功能的設計模式 (例如 [AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html))，對於非關鍵功能允許採用較低的服務水準 (例如回應時間或復原時間目標)。
## 資源
**相關文件：**
+ [AWS 服務水準協議 (SLA)](https://aws.amazon.com/legal/service-level-agreements/?aws-sla-cards.sort-by=item.additionalFields.serviceNameLower&aws-sla-cards.sort-order=asc&awsf.tech-category-filter=*all)
+ [服務水準協議對 SaaS 供應商的重要性](https://aws.amazon.com/blogs/apn/importance-of-service-level-agreement-for-saas-providers/)
**相關影片：**
+ [提供永續、高效能的架構](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [打造兼具成本、能源和資源優勢的運算環境](https://www.youtube.com/watch?v=8zsC5e1eLCg)
# SUS02-BP03 停止建立和維護未使用的資產
將您工作負載中未使用的資產除役，以降低支援您個人需求所需的雲端資源數量，並盡可能減少浪費。
**常見的反模式：**
+ 您未分析應用程式是否有冗餘或不再需要的資產。
+ 您未移除冗餘或不再需要的資產。
**建立此最佳實務的優勢：**移除未使用的資產可釋出資源，並改善工作負載的整體效率。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
未使用的資產會耗用儲存空間和運算能力等資源。識別這些資產並將其消除可以釋出這類資源，進而提升雲端架構的效能。定期分析應用程式資產 (例如預先編譯的報告、資料集和靜態影像) 和資產存取模式，找出冗餘、未充分利用和可以除役的目標。移除這類冗餘資產，避免工作負載中的資源浪費。
**實作步驟**
+ 使用監控工具識別不再需要的靜態資產。
+ 移除任何資產之前，均應先評估該移除對架構的影響。
+ 制定計劃並移除不再需要的資產。
+ 合併重疊產生的資產以消除冗餘處理。
+ 更新您的應用程式，使其不再產生及儲存不需要的資產。
+ 指示第三方停止生產和儲存代表您管理但不再需要的資產。
+ 指示第三方合併代表您生產的冗餘資產。
+ 定期審查您的工作負載以識別並移除未使用的資產。
## 資源
**相關文件：**
+ [優化您的 AWS 永續性基礎設施，第 II 部分：儲存](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage/)
+ [如何終止我的 AWS 帳戶 上不再需要的作用中資源？](https://aws.amazon.com/premiumsupport/knowledge-center/terminate-resources-account-closure/)
**相關影片：**
+ [如何檢查我的 AWS 帳戶 上是否有不再需要的作用中資源，並加以移除？](https://www.youtube.com/watch?v=pqg9AqESRlg)
# SUS02-BP04 根據使用者的聯網要求優化其工作負載的地理位置
為您的工作負載選取可減少網路流量傳輸距離的區域和服務，並減少支援工作負載所需的整體網路資源。
** 常見的反模式： **
+ 您可以根據自身所在位置選取工作負載的區域。
+ 您可以將所有工作負載資源合併到單一地理位置。
+ 通過現有資料中心的所有流量。
**建立此最佳實務的優勢：** 將工作負載分配到使用者附近的位置，可提供最低的延遲，同時減少網路間的資料移動，並降低環境影響。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
AWS 雲端 基礎設施是根據如下的位置選項而建置的：區域、可用區域、放置群組和邊緣節點，例如 [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) 和 [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/)。這些位置選項負責維護應用程式元件、雲端服務、邊緣網路和內部部署資料中心之間的連線。
分析工作負載中的網路存取模式，以識別如何使用這些雲端位置選項，以及減少網路流量必須輸送的距離。
## 實作步驟
+ 分析您工作負載中的網路存取模式，以識別使用者如何使用您的應用程式。
+ 使用監控工具，例如 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)，收集關於網路活動的資料。
+ 分析資料以識別網路存取模式。
+ 根據下列關鍵元素，為您的工作負載部署選取區域：
+ **您的永續目標：** 相關說明請見 [區域選擇](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/region-selection.html)。
+ **資料所在位置：** 對於資料密集型應用程式 (例如大數據和機器學習)，應用程式碼執行時應盡可能接近資料。
+ **使用者所在的位置：** 對於面向使用者的應用程式，請選擇接近工作負載使用者的一或多個區域。
+ **其他限制：** 請考量成本和合規性等限制，相關說明請見 [為工作負載選取區域時應考慮的事項](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)。
+ 使用本機快取或 [AWS 快取解決方案](https://aws.amazon.com/caching/aws-caching/) 取得常用的資產，以提升效能、減少資料移動，以及降低環境影響。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+ 使用可協助您在更接近工作負載使用者的位置執行程式碼的服務：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_user_a5.html)
+ 使用連線共用來支援連線重複使用，減少所需資源。
+ 使用不倚賴持續連線和同步更新的分散式資料存放區來實現一致性，以服務區域的人口。
+ 以共用動態容量取代預先佈建的靜態網路容量，與其他訂閱者分攤網路容量的永續性影響。
## 資源
**相關文件：**
+ [優化您的 AWS 永續性基礎架構，第 III 部分：聯網](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [Amazon ElastiCache 文件](https://docs.aws.amazon.com/elasticache/index.html)
+ [什麼是 Amazon CloudFront？](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Amazon CloudFront 主要功能](https://aws.amazon.com/cloudfront/features/)
**相關影片：**
+ [揭密 AWS 上的資料傳輸](https://www.youtube.com/watch?v=-MqXgzw1IGA)
+ [ 擴展新一代 Amazon EC2 執行個體的網路效能 ](https://www.youtube.com/watch?v=jNYpWa7gf1A)
**相關範例：**
+ [AWS 聯網研討會](https://catalog.workshops.aws/networking/en-US)
+ [ 永續性架構 - 盡可能減少跨網路的資料移動 ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS02-BP05 為執行的活動優化團隊成員資源
優化提供給團隊成員的資源，以盡量減少對環境永續性的影響，同時支援他們的需求。
**常見的反模式：**
+ 您忽略團隊成員所使用的裝置對雲端應用程式的整體效率產生的影響。
+ 您手動管理及更新團隊成員所使用的資源。
**建立此最佳實務的優勢：**優化團隊成員資源，可為具備雲端功能的應用程式改善整體效率。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
了解團隊成員用來使用您的服務的資源、其預期生命週期，以及財務和永續性的影響。實作將這些資源優化的策略。例如，在使用率高的可擴展基礎設施上執行複雜的操作 (例如轉譯和編譯)，而不是在使用率低的高功率單一使用者系統上執行。
**實作步驟**
+ 根據使用方式佈建工作站和其他裝置。
+ 使用虛擬桌面和應用程式串流來限縮升級與裝置要求。
+ 將大量使用處理器或記憶體的任務移至雲端，以運用其彈性。
+ 評估程序和系統對裝置生命週期的影響，並選擇在滿足業務需求的同時可將裝置更換需求降至最低的解決方案。
+ 為裝置實作遠端管理，以減少必要商務差旅時間。
+ [AWS Systems Manager Fleet Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet.html) 是一種整合式使用者介面 (UI) 體驗，可協助您從遠端管理在 AWS 內部部署環境執行的節點。
## 資源
**相關文件：**
+ [什麼是 Amazon WorkSpaces？](https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.html)
+ [Amazon WorkSpaces 的成本優化器](https://docs.aws.amazon.com/solutions/latest/cost-optimizer-for-workspaces/overview.html)
+ [Amazon AppStream 2.0 文件](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
**相關影片：**
+ [在 AWS 上管理 Amazon WorkSpaces 的成本](https://www.youtube.com/watch?v=0MoY31hZQuE)
# SUS02-BP06 實作緩衝或調節使需求曲線趨於扁平化
緩衝和調節可讓需求曲線趨於扁平化，並減少您的工作負載所需的已佈建容量。
**常見的反模式：**
+ 您非必要地立即處理用戶端要求。
+ 您未分析用戶端要求的需求。
**建立此最佳實務的優勢：**讓需求曲線趨於扁平化，可減少工作負載所需的已佈建容量。減少已佈建的容量意味著較低的能源耗用量和環境影響。
**未建立此最佳實務時的風險暴露等級：**低
使工作負載需求曲線扁平化，有助於減少工作負載所需的已佈建容量，以及降低對環境造成的影響。假設某個工作負載的需求曲線如下圖所示。此工作負載有兩個尖峰，為了處理這些尖峰，已佈建了資源容量 (以橙色線顯示)。用於此工作負載的資源和能源並非由需求曲線底下的區域表示，而是已佈建的容量底下的區域，因為這兩個尖峰必須用已佈建的容量處理。
![\[已佈建容量的波形圖，內含兩個需要大量已佈建容量的相異尖峰。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/provisioned-capacity-1.png)
您可以使用緩衝或調節來修正需求曲線，並使尖峰趨緩，意即減少已佈建的容量和耗用的能源。在用戶端可執行重試時實作調節。實作緩衝機制以儲存要求，並將處理的時間往後延遲。
![\[此波形圖顯示使用緩衝或調節讓尖峰趨緩的工作負載。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/images/provisioned-capacity-2.png)
**實作步驟**
+ 分析用戶端要求以判斷如何予以回應。應考量的問題包括：
+ 此要求是否可進行非同步處理？
+ 用戶端是否有重試能力？
+ 如果用戶端有重試功能，您可以實作調節，以告知來源若目前無法處理要求，則應稍後再試。
+ 您可以使用 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) 來實作調節。
+ 針對無法執行重試的用戶端，必須實作緩衝區使需求曲線扁平化。緩衝會延遲要求處理，讓以不同速率執行的應用程式能夠有效地通訊。緩衝為主方法使用佇列或串流來接受生產者傳出的訊息。消費者可讀取訊息並進行處理，允許以符合取用者業務要求的速度運作訊息。
+ [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) 是一個受管服務，可提供佇列，允許單一取用者讀取個別訊息。
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/) 可提供串流，允許許多取用者讀取相同訊息。
+ 分析整體需求、變更率及所需的回應時間，以適當調整所需的調節或緩衝區大小。
## 資源
**相關文件：**
+ [Amazon SQS 入門](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html)
+ [使用佇列和訊息進行應用程式整合](https://aws.amazon.com/blogs/architecture/application-integration-using-queues-and-messages/)
**相關影片：**
+ [為分散式應用程式選擇適當的傳訊服務](https://www.youtube.com/watch?v=4-JmX6MIDDI)
# 軟體和架構
**Topics**
+ [SUS 3 如何利用軟體和架構模式，來支持您的永續性發展目標？](sus-03.md)
# SUS 3 如何利用軟體和架構模式，來支持您的永續性發展目標？
實施可執行負載順暢並讓所部署資源保持一致高使用率的模式，將資源消耗降至最低。由於使用者行為隨時間改變，元件可能會因缺乏使用而閒置。修改模式和架構來整合未充分利用的元件，提高整體使用率。淘汰不再需要的元件。了解工作負載元件的效能，並最佳化消耗最多資源的元件。留意客戶用來存取服務的裝置，並實施盡量減少裝置升級需求的模式。
**Topics**
+ [SUS03-BP01 最佳化非同步與排程任務的軟體和架構](sus_sus_software_a2.md)
+ [SUS03-BP02 移除或重構使用量低或完全未使用的工作負載元件](sus_sus_software_a3.md)
+ [SUS03-BP03 優化程式碼中耗用最多時間或資源的部分](sus_sus_software_a4.md)
+ [SUS03-BP04 優化對裝置和設備的影響](sus_sus_software_a5.md)
+ [SUS03-BP05 使用最能支援資料存取和儲存模式的軟體模式和架構](sus_sus_software_a6.md)
# SUS03-BP01 最佳化非同步與排程任務的軟體和架構
使用有效率的軟體和架構模式 (例如佇列驅動)，讓所部署的資源一直保持高使用率。
**常見的反模式：**
+ 在雲端工作負載中過度佈建資源以滿足未預料到的突增需求。
+ 您的架構未透過傳訊元件將非同步訊息的傳送者與接受者分離。
**建立此最佳實務的優勢：**
+ 有效率的軟體和架構模式可盡量減少工作負載中的未使用資源，並改善整體效率。
+ 您可以將非同步訊息的處理與接收分開擴展。
+ 透過傳訊元件，可用性要求會比較寬鬆，不用太多資源即可滿足。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
使用有效率的架構模式 (例如[事件驅動架構](https://aws.amazon.com/event-driven-architecture/))，以便能平均地使用元件，並盡量避免工作負載過度佈建。使用有效率的架構模式可盡量地讓閒置資源不會因為需求隨時間發生變化而有乏人問津的情形。
了解工作負載元件的要求，並採用能夠提升整體資源使用率的架構模式。淘汰不再需要的元件。
**實作步驟**
+ 分析工作負載需求以判斷如何回應。
+ 如果請求或作業不需要同步回應，請使用佇列驅動的架構和 Auto Scaling 工作節點，以將使用率最大化。以下是您可能會考慮使用佇列驅動架構的一些範例：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+ 對於可以隨時處理的佇列或作業，請使用排程機制來批次處理作業，以提升效率。以下是 AWS 上排程機制的幾個範例：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_software_a2.html)
+ 如果您的架構中使用輪詢和 Webhook 機制，請將其更換為事件。使用[事件驅動的架構](https://docs.aws.amazon.com/lambda/latest/operatorguide/event-driven-architectures.html)可建置高效率的工作負載。
+ 利用 [AWS 上的無伺服器](https://aws.amazon.com/serverless/)來消除過度佈建的基礎設施。
+ 將架構的個別元件調整為適當大小，避免閒置資源等待輸入。
## 資源
**相關文件：**
+ [什麼是 Amazon Simple Queue Service？](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [什麼是 Amazon MQ？](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html)
+ [根據 Amazon SQS 擴展](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html)
+ [什麼是 AWS Step Functions？](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [什麼是 AWS Lambda？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [搭配 Amazon SQS 使用 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html)
+ [什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
**相關影片：**
+ [移至事件驅動型架構](https://www.youtube.com/watch?v=h46IquqjF3E)
# SUS03-BP02 移除或重構使用量低或完全未使用的工作負載元件
移除未使用且不再需要的元件，並重構使用率低的元件，以盡可能避免工作負載中的浪費。
**常見的反模式：**
+ 您未定期檢查個別工作負載元件的使用率水準。
+ 您未查看並分析 AWS 適當調整大小的工具 (例如 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)) 所提供的建議。
**建立此最佳實務的優勢：**移除未使用的元件可盡量避免浪費，並改善雲端工作負載的整體效率。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
審查您的工作負載以識別閒置或未使用的元件。有一個迭代改進程序可由需求的變更或新雲端服務的發行來觸發。例如，[AWS Lambda](https://docs.aws.amazon.com/lambda/) 函數執行時間的大幅下降可能意味著必須降低記憶體大小。此外，隨著 AWS 發行新的服務和功能，工作負載的最佳服務與架構可能會改變。
持續監控工作負載活動，並找機會改善個別元件的使用率水準。藉由移除閒置元件和執行適當調整大小的活動，您將可用最少的雲端資源達到業務要求。
**實作步驟**
+ 監控及擷取工作負載關鍵元件的使用率指標 (例如 [Amazon CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)中的 CPU 使用率、記憶體使用率或網路輸送量)。
+ 對於穩定的工作負載，請定期檢查 AWS 適當調整大小的工具 (例如 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/))，以識別閒置、未使用或未充分利用的元件。
+ 對於暫時性工作負載，請評估使用率指標以識別閒置、未使用或未充分利用的元件。
+ 淘汰不再需要的元件和相關聯的資產 (例如 Amazon ECR 映像)。
+ 重構或整合未充分利用的元件與其他資源，以提高利用效率。例如，您可將多個小資料庫佈建至單一 [Amazon RDS](https://aws.amazon.com/rds/) 資料庫執行個體，而不要在未充分利用的個別執行個體上執行資料庫。
+ 了解[您的工作量佈建以完成工作單位的資源](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/evaluate-specific-improvements.html)。
## 資源
**相關文件：**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ [什麼是 Amazon CloudWatch？](https://docs.aws.amazon.com/Amazon/latest/monitoring/WhatIs.html)
+ [自動清理 Amazon ECR 中未使用的映像](https://aws.amazon.com/blogs/compute/automated-cleanup-of-unused-images-in-amazon-ecr/)
**相關範例：**
+ [Well-Architected 實驗室：使用 AWS Compute Optimizer 適當調整大小](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [Well-Architected 實驗室 - 優化硬體模式和觀察永續性 KPI](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
# SUS03-BP03 優化程式碼中耗用最多時間或資源的部分
優化您的架構不同元件中執行的程式碼，將資源使用量降至最低，同時發揮最大效能。
**常見的反模式：**
+ 您略過資源用量的程式碼優化。
+ 您通常藉由增加資源來因應效能問題。
+ 您的程式碼審查和開發程序未追蹤效能變更。
**建立此最佳實務的優勢：** 使用有效率的程式碼可將資源用量壓到最低，並改善效能。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
請務必檢查各個功能領域 (包括雲端架構應用程式的程式碼)，以優化其資源用量和效能。持續監控您的工作負載在建置環境和生產環境中的效能，並找機會改進資源用量特別高的程式碼片段。採用定期審查程序，在您的程式碼內識別低效使用資源的錯誤或反模式。使用簡單有效的演算法為您的使用案例產生相同結果。
## 實作步驟
+ 在擬定工作負載時採用自動化程式碼審查程序，以改善品質並識別錯誤和反模式。
+ [ 使用 Amazon CodeGuru Reviewer 自動進行程式碼審查 ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ 使用 Amazon CodeGuru 偵測並行錯誤 ](https://aws.amazon.com/blogs/devops/detecting-concurrency-bugs-with-amazon-codeguru/)
+ [ 使用 Amazon CodeGuru 提升 Python 應用程式的程式碼品質 ](https://aws.amazon.com/blogs/devops/raising-code-quality-for-python-applications-using-amazon-codeguru/)
+ 在您執行工作負載時監控資源，以識別每個工作單元中具有高資源需求的元件，作為程式碼審查目標。
+ 在進行程式碼審查時，使用程式碼分析工具來識別程式碼中耗用最多時間或資源的部分，作為優化目標。
+ [ 透過 Amazon CodeGuru Profiler 降低組織的碳足跡 ](https://aws.amazon.com/blogs/devops/reducing-your-organizations-carbon-footprint-with-codeguru-profiler/)
+ [ 透過 Amazon CodeGuru Profiler 了解 Java 應用程式中的記憶體用量 ](https://aws.amazon.com/blogs/devops/understanding-memory-usage-in-your-java-application-with-amazon-codeguru-profiler/)
+ [ 透過 Amazon CodeGuru Profiler 改善客戶體驗並降低成本 ](https://aws.amazon.com/blogs/devops/improving-customer-experience-and-reducing-cost-with-codeguru-profiler/)
+ 使用針對工作負載最高效率的作業系統和程式設計語言。如需關於高能效程式設計語言 (包括 Rust) 的詳細資料，請參閱 [Rust 的永續性](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/)。
+ 將需要大量運算資源的演算法取代為會產生相同結果、但更簡單有效率的版本。
+ 移除不必要程式碼，例如排序和格式化。
## 資源
**相關文件：**
+ [什麼是 Amazon CodeGuru Profiler？](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [FPGA 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/fpga-getting-started.html)
+ [在 AWS 上建立的工具中的 AWS SDK](https://aws.amazon.com/tools/)
**相關影片：**
+ [ 使用 Amazon CodeGuru Profiler 改善程式碼效率 ](https://www.youtube.com/watch?v=1pU4VddsBRw)
+ [ 使用 Amazon CodeGuru 自動進行程式碼審查和應用程式效能建議 ](https://www.youtube.com/watch?v=OD8H63C0E0I)
# SUS03-BP04 優化對裝置和設備的影響
了解您的架構中使用的裝置和設備，並使用策略降低其用量。這樣可以盡量減輕對雲端工作負載的整體環境影響。
**常見的反模式：**
+ 您忽略了客戶使用的裝置所受到的環境影響。
+ 您手動管理及更新客戶所使用的資源。
**建立此最佳實務的優勢：**實作為客戶裝置優化的軟體模式和功能，可降低雲端工作負載的整體環境影響。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
實作為客戶裝置優化的軟體模式和功能，可透過數種方式降低環境影響：
+ 實作具回溯相容性的新功能，可減少硬體更換的數量。
+ 將應用程式優化以有效執行於裝置上，有助於降低其能源耗用量及延長電池使用壽命 (若是由電池供電)。
+ 優化裝置的應用程式也可減少網路上的資料傳輸。
了解客戶您的架構中使用的裝置和設備、其預期生命週期，以及更換這些元件的影響。實作適當的軟體模式和功能，以盡可能減少裝置能源耗用量，以及客戶更換裝置和手動加以升級的需求。
**實作步驟**
+ 清查您的架構中使用的裝置。裝置可以是行動裝置、平板裝置、IOT 裝置、智慧電燈，甚或是工廠的智慧裝置。
+ 優化在裝置上執行的應用程式：
+ 採用在背景執行任務之類的策略來降低能源耗用量。
+ 在建置承載時考慮網路頻寬和延遲，並實施可協助應用程式在低頻寬、高延遲連結上良好運作的功能。
+ 將承載和檔案轉換為裝置所需的優化格式。例如，您可以使用 [Amazon Elastic Transcoder](https://docs.aws.amazon.com/elastic-transcoder/) 或 [AWS Elemental MediaConvert](https://aws.amazon.com/mediaconvert/) 將較大的高品質數位媒體檔案轉換為使用者可在行動裝置、平板電腦、Web 瀏覽器和聯網電視上播放的格式。
+ 在伺服器端執行需要大量運算的活動 (例如影像渲染)，或使用應用程式串流來改善舊裝置的使用者體驗。
+ 對輸出進行分段和分頁，特別是對於互動式工作階段，以管理承載並限制本機儲存要求。
+ 使用自動化空中 (OTA) 機制將更新部署至一或多個裝置。
+ 您可以使用 [CI/CD 管道](https://aws.amazon.com/blogs/mobile/build-a-cicd-pipeline-for-your-android-app-with-aws-services/)更新行動應用程式。
+ 您可以使用 [AWS IoT Device Management](https://aws.amazon.com/iot-device-management/) 從遠端大規模管理連網裝置。
+ 若要測試新功能和更新，請使用具有代表性硬體集的受管 Device Farm，並迭代開發以最大化支援的裝置。如需詳細資訊，請參閱 [SUS06-BP04 使用受管 Device Farm 進行測試](sus_sus_dev_a5.md)。
## 資源
**相關文件：**
+ [什麼是 AWS Device Farm？](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html)
+ [Amazon AppStream 2.0 文件](https://docs.aws.amazon.com/appstream2/)
+ [NICE DCV](https://docs.aws.amazon.com/dcv/)
+ [在執行 FreeRTOS 的裝置上更新韌體的 OTA 教學](https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-ota-workflow.html)
**相關影片：**
+ [AWS Device Farm 簡介](https://www.youtube.com/watch?v=UiJo_PEZkD4)
# SUS03-BP05 使用最能支援資料存取和儲存模式的軟體模式和架構
了解資料在工作負載中的使用方式、使用者的使用方式、傳輸方式以及儲存方式。使用最能支援資料存取和儲存的軟體模式與架構，以盡可能減少支援工作負載所需的運算、聯網和儲存資源。
**常見的反模式：**
+ 您假設所有工作負載具有類似的資料儲存和存取模式。
+ 您只使用一個存儲層 – 假設所有工作負載都適合該層。
+ 您假設資料存取模式不會隨著時間改變。
+ 您的架構支援潛在的高資料存取爆量，這會導致資源在大部分的時間處於閒置狀態。
**建立此最佳實務的優勢：**根據資料存取和儲存模式選取及優化您的架構，有助於降低開發複雜性並提升整體使用率。了解何時使用全域表、資料分割和快取將協助您降低營運負擔，並根據您的工作負載需求進行擴展。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
使用與您的資料特性和存取模式最相符的軟體和架構模式。例如，使用 [AWS 上的現代資料架構](https://aws.amazon.com/big-data/datalakes-and-analytics/modern-data-architecture/) (可讓您使用針對個人獨特分析使用案例而優化的專用服務)。這些架構模式可實現高效資料處理以及降低資源用量。
**實作步驟**
+ 分析您的資料特性和存取模式，以識別雲端資源的正確組態。應考量的重要特性包括：
+ **資料類型：**結構化、半結構化、非結構化
+ **資料成長：**有界限、無界限
+ **資料耐用性：**持續性、暫時性、臨時
+ **存取模式：**讀取或寫入、更新頻率、尖峰或一致
+ 使用最能支援資料存取和儲存模式的架構模式。
+ [開始建構吧！ 現代資料架構](https://aws.amazon.com/blogs/architecture/lets-architect-modern-data-architectures/)
+ [AWS 上的資料庫：使用正確的工具完成任務](https://www.youtube.com/watch?v=-pb-DkD6cWg)
+ 利用可原生處理壓縮資料的技術。
+ 使用專用[分析服務](https://aws.amazon.com/big-data/datalakes-and-analytics/?nc2=h_ql_prod_an_a)進行架構中的資料處理。
+ 使用最能支援您主導查詢模式的資料庫引擎。管理您的資料庫索引，以確保高效率的查詢執行。如需詳細資訊，請參閱 [AWS 資料庫](https://aws.amazon.com/products/databases/)。
+ 選取可減少架構中網路容量消耗的網路通訊協定。
## 資源
**相關文件：**
+ [Athena 壓縮支援檔案格式](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html)
+ [使用 Amazon Redshift 從單欄資料格式複製](https://docs.aws.amazon.com/redshift/latest/dg/copy-usage_notes-copy-from-columnar.html)
+ [在 Firehose 中轉換您的輸入記錄格式](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html)
+ [AWS Glue 中 ETL 輸入和輸出的格式選項](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format.html)
+ [轉換為單欄格式，提高 Amazon Athena 的查詢效能](https://docs.aws.amazon.com/athena/latest/ug/convert-to-columnar.html)
+ [使用 Amazon Redshift 從 Amazon S3 載入壓縮的資料檔案](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [在 Amazon Aurora 上使用 Performance Insights 監控資料庫負載](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [在 Amazon RDS 上使用 Performance Insights 監控資料庫負載](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html)
+ [Amazon S3 Intelligent-Tiering 儲存類別](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/)
**相關影片：**
+ [在 AWS 上建置現代資料架構](https://www.youtube.com/watch?v=Uk2CqEt5f0o)
# 資料
**Topics**
+ [SUS 4 如何利用資料管理政策和模式來支持您的永續性目標？](sus-04.md)
# SUS 4 如何利用資料管理政策和模式來支持您的永續性目標？
實作資料管理實務來減少支援工作負載所需的佈建儲存，以及減少為了使用它所需的資源。了解您的資料，並使用更有效支援資料業務價值及其使用方式的儲存技術和組態。當需求減少時，將資料循環到效率較高、效能較低的儲存，並刪除不再需要的資料。
**Topics**
+ [SUS04-BP01 實作資料分類政策](sus_sus_data_a2.md)
+ [SUS04-BP02 使用支援資料存取和儲存模式的技術](sus_sus_data_a3.md)
+ [SUS04-BP03 使用政策來管理資料集的生命週期](sus_sus_data_a4.md)
+ [SUS04-BP04 使用彈性和自動化擴充區塊儲存或檔案系統](sus_sus_data_a5.md)
+ [SUS04-BP05 移除不需要或多餘的資料](sus_sus_data_a6.md)
+ [SUS04-BP06 使用共用檔案系統或儲存體存取通用資料](sus_sus_data_a7.md)
+ [SUS04-BP07 盡可能減少跨網路的資料移動](sus_sus_data_a8.md)
+ [SUS04-BP08 僅在難以重新建立時才備份資料](sus_sus_data_a9.md)
# SUS04-BP01 實作資料分類政策
將資料分類以了解其對業務成果的關鍵性，並選擇適當的 節能儲存層來儲存資料。
**常見的反模式：**
+ 您未以正在處理或已儲存的類似特性來識別資料資產 (例如敏感性、業務關鍵性或法規要求)。
+ 您未實作資料目錄以清查資料資產。
**建立此最佳實務的優勢：**實作資料分類政策，可讓您確認最節能的資料儲存層。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
資料分類的工作之一，是識別正在處理的資料類型，以及由組織擁有或操作的資訊系統中儲存的資料類型。此外也須確認資料的關鍵性，以及資料損毀、遺失或誤用可能造成的影響。
若要實作資料分類政策，請從資料的情境使用採取逆向思維，並建立適當的分類機制，將指定資料集的關鍵性程度納入組織操作的考量中。
**實作步驟**
+ 對您工作負載現有的各種資料類型執行清查。
+ 如需關於資料分類類別的詳細資料，請參閱[資料分類白皮書](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification.html)。
+ 根據組織面臨的風險，判定資料的關鍵性、機密性、完整性和可用性。使用這些要求，將資料分組為您採用的其中一個資料分類層。
+ 範例請見[分類資料及保護新創公司的四個簡單步驟](https://aws.amazon.com/blogs/startups/four-simple-steps-to-classify-your-data-and-secure-your-startup/)。
+ 定期稽核您的環境是否有未標記和未分類的資料，並對資料進行適當的分類和標記。
+ 範例請見 [AWS Glue 中的資料目錄和編目程式](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html)。
+ 建立提供稽核和管控能力的資料目錄。
+ 確認並記載每個資料類別的處理程序。
+ 使用自動化功能持續稽核環境以識別未標記和未分類的資料，並對資料進行適當的分類和標記。
## 資源
**相關文件：**
+ [使用 AWS 雲端 以支援資料分類](https://docs.aws.amazon.com/whitepapers/latest/data-classification/leveraging-aws-cloud-to-support-data-classification.html)
+ [標記來自 AWS Organizations 的政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)
**相關影片：**
+ [在 AWS 上實現敏捷性與資料管控](https://www.youtube.com/watch?v=vznDgJkoH7k)
# SUS04-BP02 使用支援資料存取和儲存模式的技術
使用最能支援您的資料存取和儲存方式的儲存技術，以在支援工作負載的同時，也將佈建的資源降至最低。
**常見的反模式：**
+ 您假設所有工作負載具有類似的資料儲存和存取模式。
+ 您只使用一個存儲層 – 假設所有工作負載都適合該層。
+ 您假設資料存取模式不會隨著時間改變。
**建立此最佳實務的優勢：** 根據資料存取和儲存模式來選取及優化您的儲存技術，可協助您降低達成商業需求所需的雲端資源，並改善雲端工作負載的整體效率。
**未建立此最佳實務時的曝險等級：** 低
## 實作指引
選擇最適合您的存取模式的儲存解決方案，或者考慮變更存取模式，以符合儲存解決方案，從而達到最大的效能效率。
+ 評估您的資料特性和存取模式，以收集儲存需求的重要特性。應考量的重要特性包括：
+ **資料類型：** 結構化、半結構化、非結構化
+ **資料成長：** 有界限、無界限
+ **資料耐用性：** 持續性、暫時性、臨時
+ **存取模式：** 讀取或寫入、頻率、尖峰或一致
+ 將資料遷移至支援您的資料特性和存取模式的適當儲存技術。以下提供 AWS 儲存技術及其重要特性的一些範例：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_data_a3.html)
+ 對於固定大小的儲存系統 (例如 Amazon EBS 或 Amazon FSx)，請監控可用儲存空間，並且在接近閾值時自動執行儲存空間分配。您可以利用 Amazon CloudWatch 來收集及分析下列項目的不同指標： [Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html) 和 [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html)。
+ Amazon S3 儲存類別可設定於物件層級，且單一儲存貯體可包含儲存在所有儲存類別間的物件。
+ 您也可以使用 Amazon S3 生命週期政策在儲存類別之間自動轉換物件或移除資料，而無須進行任何應用程式變更。在考量這些儲存機制時，您通常需要在資源效率、存取延遲與可靠性之間做出取捨。
## 資源
**相關文件：**
+ [Amazon EBS 磁碟區類型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)
+ [Amazon EC2 執行個體儲存體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)
+ [Amazon S3 Intelligent-Tiering](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html)
+ [ Amazon EBS I/O 特性 ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ebs-io-characteristics.html)
+ [ 使用 Amazon S3 儲存類別 ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html)
+ [什麼是 Amazon Glacier？](https://docs.aws.amazon.com/amazonglacier/latest/dev/introduction.html)
**相關影片：**
+ [AWS 上資料湖的架構模式](https://www.youtube.com/watch?v=XpTly4XHmqc&ab_channel=AWSEvents)
+ [ 深入探討 Amazon EBS (STG303-R1) ](https://www.youtube.com/watch?v=wsMWANWNoqQ)
+ [ 使用 Amazon S3 優化儲存效能 (STG343) ](https://www.youtube.com/watch?v=54AhwfME6wI)
+ [ 在 AWS 上建置現代化資料架構 ](https://www.youtube.com/watch?v=Uk2CqEt5f0o)
**相關範例：**
+ [ Amazon EFS CSI 驅動程式 ](https://github.com/kubernetes-sigs/aws-efs-csi-driver)
+ [ Amazon EBS CSI 驅動程式 ](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)
+ [ Amazon EFS 公用程式 ](https://github.com/aws/efs-utils)
+ [ Amazon EBS 自動擴展 ](https://github.com/awslabs/amazon-ebs-autoscale)
+ [ Amazon S3 範例 ](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/s3-examples.html)
# SUS04-BP03 使用政策來管理資料集的生命週期
管理所有資料的生命週期並自動執行刪除，將工作負載所需的儲存總量降至最低。
**常見的反模式：**
+ 您手動刪除資料。
+ 您未刪除任何工作負載資料。
+ 您未根據資料的保留和存取要求，將資料移至更節能的儲存層。
**建立此最佳實務的優勢：**使用資料生命週期政策可確保工作負載中的資料會以有效率的方式存取和保留。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
資料集在其生命週期內，通常會有不同的保留和存取要求。例如，應用程式可能需要在一段時間內頻繁存取某些資料集。這段時間過後，便不會頻繁存取這些資料集。
為了在資料集的完整生命週期內有效率地管理資料集，請設定生命週期政策，也就是定義了資料集處理方式的規則。
有了生命週期組態規則後，便能指示特定儲存服務將資料集轉移至更節能的儲存層、將其封存，或加以刪除。
**實作步驟**
+ [對工作負載內的資料集進行分類。](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_data_a2.html)
+ 定義每個資料類別的處理程序。Define handling procedures for each data class.
+ 設定自動生命週期政策以強制執行生命週期規則。下面幾個範例會說明如何為不同的 AWS 儲存服務設定自動化的生命週期政策：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_data_a4.html)
+ 請刪除已超過保留期間的未使用磁碟區、快照和資料。利用原生服務功能 (例如 Amazon DynamoDB Time To Live 或 Amazon CloudWatch 日誌保留) 來執行刪除作業。
+ 根據生命週期規則，在適用的情況下彙總和壓縮資料。
## 資源
**相關文件：**
+ [使用 Amazon S3 儲存類別分析將 Amazon S3 生命週期規則最佳化](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html)
+ [使用 AWS Config 規則 評估資源](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
**相關影片：**
+ [使用 Amazon S3 生命週期來簡化資料生命週期並將儲存成本最佳化](https://www.youtube.com/watch?v=53eHNSpaMJI)
+ [使用 Amazon S3 Storage Lens 降低儲存成本](https://www.youtube.com/watch?v=A8qOBLM6ITY)
# SUS04-BP04 使用彈性和自動化擴充區塊儲存或檔案系統
隨著資料的增長使用彈性和自動化擴充區塊儲存或檔案系統，以盡可能縮小整體的已佈建儲存。
**常見的反模式：**
+ 您為了日後的需求購買大型區塊儲存或檔案系統。
+ 您過度佈建了檔案系統的每秒輸入/輸出作業數 (IOPS)。
+ 您未監控資料磁碟區的使用率。
**建立此最佳實務的優勢：**盡可能減少儲存系統的過度佈建可減少閒置資源，並改善工作負載的整體效率。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
使用適合工作負載的大小分配、輸送量和延遲，建立區塊儲存和檔案系統。隨著資料的增長使用彈性和自動化擴充區塊儲存或檔案系統，而無須過度佈建這些儲存服務。
**實作步驟**
+ 對於固定大小的儲存體 (例如 [Amazon EBS](https://aws.amazon.com/ebs/))，請確認監控使用的儲存量佔整體儲存大小的比例，並在達到閾值時建立自動化 (如可能) 以增加儲存大小。
+ 使用彈性磁碟區和受管區塊資料服務，以在持久性資料增長時自動分配額外的儲存空間。例如，您可以使用 [Amazon EBS 彈性磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html)來變更磁碟區大小、磁碟區類型，或調整 Amazon EBS 磁碟區的效能。
+ 為您的檔案系統選擇適當的儲存類別、效能模式和輸送量模式以因應商業需求 (勿過量)。
+ [Amazon EFS 效能](https://docs.aws.amazon.com/efs/latest/ug/performance.html)
+ [Linux 執行個體上的 Amazon EBS 磁碟區效能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html)
+ 設定資料磁碟區的目標使用率水準，並調整超出預期範圍的磁碟區大小。
+ 根據資料適當調整唯讀磁碟區的大小。
+ 將資料遷移到物件存放區，避免從區塊儲存的固定磁碟區大小佈建多餘容量。
+ 定期審查彈性磁碟區和檔案系統以終止閒置磁碟區，並縮減過度佈建的資源以符合目前的資料大小。
## 資源
**相關文件：**
+ [Amazon FSx 文件](https://docs.aws.amazon.com/fsx/index.html)
+ [什麼是 Amazon Elastic File System？](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
**相關影片：**
+ [深入探討 Amazon EBS 彈性磁碟區](https://www.youtube.com/watch?v=Vi_1Or7QuOg)
+ [有助於提升效能和節省成本的 Amazon EBS 與快照優化策略](https://www.youtube.com/watch?v=h1hzRCsJefs)
+ [使用最佳實務優化 Amazon EFS 的成本與效能](https://www.youtube.com/watch?v=9kfeh6_uZY8)
# SUS04-BP05 移除不需要或多餘的資料
移除不需要或多餘的資料，以盡量降低儲存資料集時所需的儲存資源。
**常見的反模式：**
+ 您複製可以輕鬆取得或建立的資料。
+ 您備份所有資料，而不考慮該資料是否重要。
+ 您只會不定期地刪除資料、在發生營運事件時刪除資料，或完全不刪除資料。
+ 您重複儲存資料，而不理會儲存服務的耐用性。
+ 您在沒有任何商務理由的情況下啟用 Amazon S3 版本控制。
**建立此最佳實務的優勢：**移除不需要的資料會降低工作負載所需的儲存大小，以及工作負載環境所受到的影響。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
請勿儲存您不需要的資料。請自動刪除不需要的資料。使用會在檔案層級和區塊層級刪除重複資料的技術。利用服務原生的資料複寫和備援功能。
**實作步驟**
+ 評估您是否可以藉由使用 [AWS Data Exchange](https://aws.amazon.com/data-exchange/) 和 [AWS 上的開放資料登錄檔](https://registry.opendata.aws/)中現有的公開提供的資料集，以避免儲存資料。
+ 使用可在區塊和物件層級刪除重複資料的機制。下面幾個範例會說明如何在 AWS 上刪除重複資料：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_data_a6.html)
+ 分析資料存取以識別不需要的資料。將生命週期政策自動化。利用原生服務功能 (例如 [Amazon DynamoDB Time To Live](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)、[Amazon S3 Lifecycle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) 或 [Amazon CloudWatch 日誌保留](https://docs.aws.amazon.com/managedservices/latest/userguide/log-customize-retention.html)) 來執行刪除作業。
+ 使用 AWS 上的資料虛擬化功能將資料留在其來源上，並避免資料重複。
+ [AWS 上的雲端原生資料虛擬化](https://www.youtube.com/watch?v=BM6sMreBzoA)
+ [實驗室：使用 Amazon Redshift 資料共用來最佳化資料模式](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)
+ 使用可以進行增量備份的備份計數。
+ 利用 [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html) 的耐久性和 [Amazon EBS 的複寫功能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html)來滿足耐久性目標，而非利用自我管理的技術 (例如獨立硬碟冗餘陣列 (RAID))。
+ 集中日誌和追蹤資料、刪除重複的日誌項目，並建立根據需要微調詳細程度的機制。
+ 僅在合理的情況下才預先填入快取。
+ 建立快取監控和自動化，據以調整快取大小。
+ 推送工作負載新版本時，從物件存放區和邊緣快取移除過時的部署和資產。
## 資源
**相關文件：**
+ [變更 CloudWatch Logs 中的日誌資料保留](https://docs.aws.amazon.com/Amazon/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)
+ [Amazon FSx for Windows File Server 上的重複資料刪除](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-data-dedup.html)
+ [Amazon FSx for ONTAP 的功能，包括重複資料刪除](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is-fsx-ontap.html#features-overview)
+ [使 Amazon CloudFront 上的檔案無效](https://docs.aws.amazon.com/Amazon/latest/DeveloperGuide/Invalidation.html)
+ [使用 AWS Backup 來備份和還原 Amazon EFS 檔案系統](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [什麼是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/Amazon/latest/logs/WhatIsLogs.html)
+ [在 Amazon RDS 上使用備份](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
**相關影片：**
+ [使用 ML Transforms for AWS Lake Formation 來模糊比對資料和刪除重複資料](https://www.youtube.com/watch?v=g34xUaJ4WI4)
**相關範例：**
+ [我要如何使用 Amazon Athena 分析 Amazon S3 伺服器存取日誌？](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
# SUS04-BP06 使用共用檔案系統或儲存體存取通用資料
採用共用檔案系統或儲存體以避免資料重複，並且讓工作負載有更高效的基礎設施。
**常見的反模式：**
+ 您為每個用戶端佈建儲存體。
+ 您未從非作用中用戶端卸離資料磁碟區。
+ 您未提供跨平台和系統的儲存體存取。
**建立此最佳實務的優勢：**使用共用檔案系統或儲存裝置，無須複製資料即可與一或多個取用者共用資料。這有助於減少工作負載所需的儲存資源。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
如果有多個使用者或應用程式在存取相同的資料集，則務必要使用共用儲存技術，讓您的工作負載有高效的基礎設施。共用儲存技術提供了集中儲存和管理資料的位置，可避免資料重複。此外也可強制執行跨不同系統的資料一致性。再者，共用儲存技術可讓您更有效率地使用運算能力，因為多個運算資源可同時平行存取及處理資料。
請在必要時才從這些共用儲存服務擷取資料，且應卸離未使用的磁碟區以釋出資源。
**實作步驟**
+ 當資料有多個取用者時，將資料遷移到共用儲存體。以下是 AWS 共用儲存技術的一些範例：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_data_a7.html)
+ 有需要時才將資料複製到共用檔案系統或從中擷取資料。例如，您可以建立[由 Amazon FSx for Lustre 支援的 Amazon S3 檔案系統](https://aws.amazon.com/blogs/storage/new-enhancements-for-moving-data-between-amazon-fsx-for-lustre-and-amazon-s3/)，並僅將處理任務所需的資料子集載入至 Amazon FSx。
+ 根據您的使用模式適當刪除資料，如 [SUS04-BP03 使用政策來管理資料集的生命週期](sus_sus_data_a4.md) 中所述。
+ 將磁碟區與未積極使用它們的用戶端分開。
## 資源
**相關文件：**
+ [將檔案系統連結至 Amazon S3 儲存貯體](https://docs.aws.amazon.com/fsx/latest/LustreGuide/create-dra-linked-data-repo.html)
+ [在無伺服器應用程式中對 AWS Lambda 使用 Amazon EFS](https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/)
+ [Amazon EFS Intelligent-Tiering 優化變更存取模式的工作負載成本](https://aws.amazon.com/blogs/aws/new-amazon-efs-intelligent-tiering-optimizes-costs-for-workloads-with-changing-access-patterns/)
+ [將 Amazon FSx 用於內部部署資料儲存庫](https://docs.aws.amazon.com/fsx/latest/LustreGuide/fsx-on-premises.html)
**相關影片：**
+ [透過 Amazon EFS 進行儲存成本優化](https://www.youtube.com/watch?v=0nYAwPsYvBo)
# SUS04-BP07 盡可能減少跨網路的資料移動
使用共用檔案系統或物件儲存體存取通用資料，將支援工作負載資料移動所需的整體網路資源降至最低。
**常見的反模式：**
+ 無論資料使用者位於何處，您都將所有資料儲存在相同的 AWS 區域 中。
+ 您未優化資料大小和格式，便將其移至網路。
**建立此最佳實務的優勢：** 優化整個網路間的資料移動，可減少工作負載所需的整體網路資源，並降低其環境影響。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
要在您的組織移動資料，需要運算、聯網和儲存資源。使用相關技術盡可能減少資料移動，並改善工作負載的整體效率。
## 實作步驟
+ 選取工作負載的區域時，請將區域與資料或使用者的鄰近性視為 [決策因素](https://aws.amazon.com/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals/)。
+ 對區域性使用的服務進行分區，以便將區域專屬的資料存放在使用它的區域內。
+ 使用有效率的檔案格式 (例如 Parquet 或 ORC)，並在透過網路移動資料之前先壓縮資料。
+ 請勿移動未使用的資料。一些有助於避免移動未使用資料的範例：
+ 減少 API 回應 (僅回應相關資料)。
+ 彙總詳細的資料 (不需要記錄層級資訊)。
+ 請參閱 [Well-Architected 實驗室 - 使用 Amazon Redshift 資料共用來優化資料模式](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/)。
+ 考慮 [在 AWS Lake Formation 中使用跨帳戶資料共用](https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-permissions.html)。
+ 使用可協助您在更接近工作負載使用者的位置執行程式碼的服務。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_data_a8.html)
## 資源
**相關文件：**
+ [優化您的 AWS 永續性基礎架構，第 III 部分：聯網](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-iii-networking/)
+ [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/)
+ [Amazon CloudFront 主要功能，包括 CloudFront Global Edge Network](https://aws.amazon.com/cloudfront/features/)
+ [壓縮 Amazon OpenSearch Service 中的 HTTP 請求](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gzip.html)
+ [使用 Amazon EMR 進行中間資料壓縮](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-output-compression.html#HadoopIntermediateDataCompression)
+ [將壓縮的資料檔案從 Amazon S3 載入 Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/t_loading-gzip-compressed-data-files-from-S3.html)
+ [使用 Amazon CloudFront 提供壓縮檔案服務](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html)
**相關影片：**
+ [ 揭密 AWS 上的資料傳輸 ](https://www.youtube.com/watch?v=-MqXgzw1IGA)
**相關範例：**
+ [ 永續性架構 - 盡可能減少跨網路的資料移動 ](https://catalog.us-east-1.prod.workshops.aws/workshops/7c4f8394-8081-4737-aa1b-6ae811d46e0a/en-US)
# SUS04-BP08 僅在難以重新建立時才備份資料
避免備份沒有商業價值的資料，以盡可能降低工作負載的儲存資源需求。
**常見的反模式：**
+ 您沒有資料的備份策略。
+ 您備份了可輕易重新建立的資料。
**建立此最佳實務的優勢：**避免備份非關鍵資料可減少工作負載所需的儲存資源，並降低其環境影響。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
避免備份非必要的資料，有助於降低成本和工作負載所使用的儲存資源。僅備份具有商業價值或需要滿足合規要求的資料即可。檢查備份政策，並在復原案例中排除沒有價值的暫時性儲存。
**實作步驟**
+ 實作如 [SUS04-BP01 實作資料分類政策](sus_sus_data_a2.md) 所列的資料分類政策。
+ 根據您的[復原時間目標 (RTO) 和復原點目標 (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html) 使用資料分類的關鍵性，並設計備份策略。避免備份非關鍵資料。
+ 排除可輕易重新建立的資料。
+ 從備份排除暫時性資料。
+ 排除資料的本機副本，除非從共同位置還原資料所需的時間不符合服務水準協議 (SLA) 的要求。
+ 使用自動化解決方案或受管服務來備份業務關鍵資料。
+ [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 是一種全受管服務，可讓您在雲端和內部部署環境輕鬆集中化和自動化 AWS 服務的資料保護。如需如何使用 AWS Backup 建立自動化備份的實作指引，請參閱 [Well-Architected 實驗室 - 測試備份並還原資料](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)。
+ [使用 AWS Backup 自動進行 Amazon EFS 的備份及優化備份成本](https://aws.amazon.com/blogs/storage/automating-backups-and-optimizing-backup-costs-for-amazon-efs-using-aws-backup/)。
## 資源
**相關的最佳實務：**
+ [REL09-BP01 識別並備份所有需要備份的資料，或從來源複製資料](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_identified_backups_data.html)
+ [REL09-BP03 自動執行資料備份](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_automated_backups_data.html)
+ [REL13-BP02 使用定義的復原策略達到復原目標](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
**相關文件：**
+ [使用 AWS Backup 來備份和還原 Amazon EFS 檔案系統](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html)
+ [Amazon EBS 快照](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [在 Amazon Relational Database Service 上使用備份](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html)
+ [APN 合作夥伴：可以幫助備份的合作夥伴](https://partners.amazonaws.com/search/partners?keyword=Backup)
+ [AWS Marketplace：可用於備份的產品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [備份 Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [備份 Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Amazon ElastiCache (Redis OSS) 的備份和還原](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
**相關影片：**
+ [AWS re:Invent 2021 - 使用 AWS 進行備份、災難復原和勒索軟體防護](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup 示範：跨帳戶和跨區域備份](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019：深入探討 AWS Backup，ft.Rackspace (STG341) ](https://www.youtube.com/watch?v=av8DpL0uFjc)
**相關範例：**
+ [Well-Architected 實驗室 - 測試備份並還原資料](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected 實驗室 - 透過適用於分析工作負載的容錯回復進行備份和還原](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected 實驗室 - 災難復原 - 備份和還原](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# 硬體和服務
**Topics**
+ [SUS 5 如何選取雲端硬體和服務並在您的架構中使用，以支持您的永續性目標？](sus-05.md)
# SUS 5 如何選取雲端硬體和服務並在您的架構中使用，以支持您的永續性目標？
透過變更硬體管理實務，尋求降低工作負載永續性影響的機會。將佈建和部署所需的硬體量降至最低，並為個別工作負載選取最高效率的硬體和服務。
**Topics**
+ [SUS05-BP01 使用最低數量的硬體來滿足需求](sus_sus_hardware_a2.md)
+ [SUS05-BP02 使用影響最小的執行個體類型](sus_sus_hardware_a3.md)
+ [SUS05-BP03 使用受管服務](sus_sus_hardware_a4.md)
+ [SUS05-BP04 將硬體型運算加速器的使用方式最佳化](sus_sus_hardware_a5.md)
# SUS05-BP01 使用最低數量的硬體來滿足需求
使用最低數量的硬體讓您的工作負載有效達成商業需求。
**常見的反模式：**
+ 您未監控資源使用率。
+ 您的架構中有資源處於低使用率水準。
+ 您未審查靜態硬體的使用率以判斷是否應調整其大小。
+ 您未根據業務 KPI 設定運算基礎設施的硬體使用率目標。
**建立此最佳實務的優勢：**適當調整雲端資源大小有助於降低工作負載的環境影響、節省金錢並維護效能基準。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
建議選取您的工作負載所需的硬體總數，以改善其整體效率。AWS 雲端 提供的彈性可透過各種機制 (例如 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)) 動態擴充或減少資源數量，以因應需求的變化。此外也提供 [API 和 SDK](https://aws.amazon.com/developer/tools/)，讓修改資源變得非常輕鬆。使用這些功能可以頻繁變更工作負載實作。此外，使用 AWS 工具提供的適當調整大小指導方針可讓您有效操作雲端資源，而達到您的商業需求。
**實作步驟**
+ 選擇最符合您的需求的執行個體類型。
+ [如何為工作負載選擇適當的 Amazon EC2 執行個體類型？](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [Amazon EC2 機群的屬性型執行個體類型選取。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [使用屬性型執行個體類型選取建立 Auto Scaling 群組。](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html)
+ 針對變動工作負載，以較小的增量進行擴展。
+ 使用多種運算購買選項，以在執行個體的彈性、可擴展性和成本節省之間取得平衡。
+ [隨需執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html)最適用於新的有狀態尖峰工作負載 (其執行個體類型、位置或時間不具彈性)。
+ [Spot 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)很適合用來補強具有容錯能力和彈性的應用程式適用的其他選項。
+ 對於狀態穩定、允許隨著您的需求變更保有彈性 (例如 AZ、區域、執行個體系列或執行個體類型) 的工作負載，請使用 [Compute Savings Plans](https://aws.amazon.com/savingsplans/compute-pricing/)。
+ 利用執行個體和可用區域的多樣化達到最大的應用程式可用性，並在情況允許時充分運用過剩容量。
+ 使用 AWS 工具提供的適當調整大小建議，調整您的工作負載。
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)
+ 協商服務水準協議 (SLA)，允許暫時減少容量，同時自動化部署替換資源。
## 資源
**相關文件：**
+ [優化您的 AWS 永續性基礎設施，第 I 部分：運算](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [Amazon EC2 機群的 Auto Scaling 屬性型執行個體類型選取](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [AWS Compute Optimizer 文件](https://docs.aws.amazon.com/compute-optimizer/index.html)
+ [操作 Lambda：效能優化](https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-2/)
+ [Auto Scaling 文件](https://docs.aws.amazon.com/autoscaling/index.html)
**相關影片：**
+ [打造兼具成本、能源和資源優勢的運算環境](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**相關範例：**
+ [Well-Architected 實驗室 - 在 AWS Compute Optimizer 和記憶體使用率已啟用的情況下適當調整大小 (Level 200)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)
# SUS05-BP02 使用影響最小的執行個體類型
持續監控並使用新的執行個體類型，讓能源效率方面的改進充分發揮效用。
**常見的反模式：**
+ 您僅使用一個執行個體系列。
+ 您僅使用 x86 執行個體。
+ 您在 Amazon EC2 Auto Scaling 組態中指定了一個執行個體類型。
+ 您以不符合設計宗旨的方式使用 AWS 執行個體 (例如，您將運算優化的執行個體用於記憶體密集型工作負載)。
+ 您未定期評估新的執行個體類型。
+ 您未查看 AWS 適當調整大小的工具 (例如 [AWS Compute Optimizer) 提供的建議。](https://aws.amazon.com/compute-optimizer/)
**建立此最佳實務的優勢：** 藉由使用節能且適當調整大小的執行個體，將可大幅降低環境受到的影響以及工作負載成本。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
在雲端工作負載中使用高效執行個體，是降低資源用量和提高成本效益的關鍵。持續關注新執行個體類型的發佈，並運用能源效率改進，包括旨在支援特定工作負載 (例如機器學習訓練和推論以及影片轉碼) 的執行個體類型。
## 實作步驟
+ 了解並探索可降低工作負載環境影響的執行個體類型。
+ 訂閱 [AWS 最新消息](https://aws.amazon.com/new/) ，隨時掌握最新的 AWS 技術和執行個體。
+ 了解不同的 AWS 執行個體類型。
+ 觀看下列資源，了解 AWS Graviton 型執行個體如何在 Amazon EC2 中的能源使用提供最佳效能功耗比。 [re:Invent 2020 - 深入探討搭載 AWS Graviton2 處理器的 Amazon EC2 執行個體](https://www.youtube.com/watch?v=NLysl0QvqXU) 和 [深入探討 AWS Graviton3 和 Amazon EC2 C7g 執行個體](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents)。
+ 進行相關規劃，將工作負載轉移至影響程度最低的執行個體類型。
+ 定義一個程序來評估工作負載的新功能和執行個體。利用雲端的靈活性快速測試新功能類型對您的工作負載環境永續性有何改善。使用代理指標，測量您需要多少資源才能完成一個工作單位。
+ 如果可行，請修改工作負載，以使用不同數量的 CPU 和不同數量的記憶體，從而最大化您選擇執行個體類型的空間。
+ 考慮將您的工作負載轉移至 Graviton 型執行個體，以改善工作負載的效能效率。
+ [AWS Graviton Fast Start](https://aws.amazon.com/ec2/graviton/fast-start/)
+ [將工作負載轉移至 AWS Graviton 型 Amazon Elastic Compute Cloud 執行個體時所需考量的事項](https://github.com/aws/aws-graviton-getting-started/blob/main/transition-guide.md)
+ [AWS Graviton2 for ISVs](https://docs.aws.amazon.com/whitepapers/latest/aws-graviton2-for-isv/welcome.html)
+ 請考慮選取 AWS Graviton 選項 (在您要使用的 [AWS 受管服務中)。](https://github.com/aws/aws-graviton-getting-started/blob/main/managed_services.md)
+ 將工作負載遷移至有執行個體對永續性影響最小，且仍符合業務要求的區域。
+ 針對機器學習工作負載，請利用專供工作負載使用的專用硬體，例如 [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)、 [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)，和 [Amazon EC2 DL1。](https://aws.amazon.com/ec2/instance-types/dl1/) AWS Inferentia 執行個體 (例如 Inf2 執行個體) 所提供的效能功耗比最多會比同類 Amazon EC2 執行個體高出 50%。
+ 使用 [Amazon SageMaker AI Inference Recommender](https://docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html) 適當調整 ML 推論端點的大小。
+ 對於激增的工作負載 (不常需要額外容量的工作負載)，請使用 [高載效能執行個體。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ 對於無狀態和容錯工作負載，請使用 [Amazon EC2 Spot 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) 提高雲端整體使用率，並減少未使用資源的永續性影響。
+ 操作並優化您的工作負載執行個體。
+ 對於暫時性工作負載，請評估 [執行個體 Amazon CloudWatch 指標](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics) (例如 `CPUUtilization` )，以確認執行個體是否閒置或未充分利用。
+ 對於穩定的工作負載，請定期檢查 AWS 適當調整大小的工具 (例如 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) )，以找出對執行個體進行優化和適當調整大小的機會。
+ [ Well-Architected 實驗室 - 適當調整大小的建議 ](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [ Well-Architected 實驗室 - 使用 Compute Optimizer 適當調整大小 ](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [ Well-Architected 實驗室 - 優化硬體模式和觀察永續性 KPI ](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
## 資源
**相關文件：**
+ [優化您的 AWS 永續性基礎架構，第 I 部分：運算](https://aws.amazon.com/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-i-compute/)
+ [AWS Graviton](https://aws.amazon.com/ec2/graviton/)
+ [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/)
+ [Amazon EC2 容量保留機群](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cr-fleets.html)
+ [Amazon EC2 Spot 機群](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)
+ [函數：Lambda 函數組態](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration)
+ [ Amazon EC2 機群的屬性型執行個體類型選取 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html)
+ [在 AWS 上建置永續性、高效且成本優化的應用程式](https://aws.amazon.com/blogs/compute/building-sustainable-efficient-and-cost-optimized-applications-on-aws/)
+ [ Contino 永續性儀表板如何協助客戶優化其碳足跡 ](https://aws.amazon.com/blogs/apn/how-the-contino-sustainability-dashboard-helps-customers-optimize-their-carbon-footprint/)
**相關影片：**
+ [深入探討搭載 AWS Graviton2 處理器的 Amazon EC2 執行個體](https://www.youtube.com/watch?v=NLysl0QvqXU)
+ [深入探討 AWS Graviton3 和 Amazon EC2 C7g 執行個體](https://www.youtube.com/watch?v=WDKwwFQKfSI&ab_channel=AWSEvents)
+ [ 打造兼具成本、能源和資源優勢的運算環境 ](https://www.youtube.com/watch?v=8zsC5e1eLCg)
**相關範例：**
+ [ 解決方案：在 AWS 上優化深度學習工作負載以維持永續性的指引 ](https://aws.amazon.com/solutions/guidance/optimizing-deep-learning-workloads-for-sustainability-on-aws/)
+ [Well-Architected 實驗室 - 適當調整大小的建議](https://wellarchitectedlabs.com/cost/100_labs/100_aws_resource_optimization/)
+ [Well-Architected 實驗室 - 使用 Compute Optimizer 適當調整大小](https://wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/)
+ [Well-Architected 實驗室 - 優化硬體模式和觀察永續性 KPI](https://wellarchitectedlabs.com/sustainability/200_labs/200_optimize_hardware_patterns_observe_sustainability_kpis/)
+ [ Well-Architected 實驗室 - 將服務遷移至 Graviton ](https://www.wellarchitectedlabs.com/sustainability/100_labs/100_migrate_services_to_graviton/)
# SUS05-BP03 使用受管服務
使用受管服務以提高雲端中的操作效率。
**常見的反模式：**
+ 您使用具有低使用率的 Amazon EC2 執行個體來執行應用程式。
+ 您的內部團隊僅管理工作負載，而沒有時間專注於創新或簡化。
+ 您為在受管服務上可更高效執行的任務部署及維護技術。
**建立此最佳實務的優勢：**
+ 使用受管服務可將責任轉移給 AWS，他們擁有從數百萬客戶積累而成的洞察，可帶來新的創新和效率動能。
+ 基於多租用戶控制平面，受管服務將服務產生的環境影響分散到眾多使用者。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
受管服務可將維持已部署硬體的高使用率和永續性優化的責任轉移給 AWS。受管服務也免除了維護服務的營運和管理重擔，讓您的團隊有更多時間可專注於創新。
審查您的工作負載，以識別可能被 AWS 受管服務取代的元件。例如，[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/) 提供受管分析服務。
**實作步驟**
1. 清查工作負載中的服務和元件。
1. 評估並識別可能被受管服務取代的元件。以下舉例說明您可能會考慮使用受管服務的時機：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_hardware_a4.html)
1. 識別相依性並建立遷移計劃。據以更新執行手冊和程序手冊。
+ [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) 會自動收集並提供有關應用程式相依性和利用率的詳細資訊，協助您在計劃遷移時做出更明智的決定。
1. 在遷移至受管服務之前先測試服務。
1. 使用遷移計劃將自我託管服務取代為受管服務。
1. 在遷移完成後繼續監控服務，以便在必要時進行調整及優化服務。
## 資源
**相關文件：**
+ [AWS 雲端 產品](https://aws.amazon.com/products/)
+ [AWS 總體擁有成本 (TCO) 計算器](https://calculator.aws/#/)
+ [Amazon DocumentDB](https://aws.amazon.com/documentdb/)
+ [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](https://aws.amazon.com/msk/)
**相關影片：**
+ [使用 AWS Managed Services 大規模進行雲端操作](https://www.youtube.com/watch?v=OCK8GCImWZw)
# SUS05-BP04 將硬體型運算加速器的使用方式最佳化
將加速運算執行個體的使用方式最佳化，以降低工作負載的實體基礎設施需求。
**常見的反模式：**
+ 未監控 GPU 使用率。
+ 針對工作負載使用一般用途的執行個體，但專用執行個體可以提供更高的效能、較低的成本，以及更優異的效能功耗比。
+ 您使用硬體型運算加速器來執行任務，但使用 CPU 型運算加速器來執行時會更有效率。
**建立此最佳實務的優勢：** 將硬體型加速器的使用方式優化，可以降低工作負載的實體基礎設施需求。
**未建立此最佳實務時的曝險等級：** 中
## 實作指引
如果需要高處理能力，使用加速運算執行個體可讓您獲得好處，因為其可讓您存取硬體型運算加速器，例如圖形處理單元 (GPU) 和現場可程式化邏輯閘陣列 (FPGA)。這些硬體加速器在執行某些功能 (例如圖形處理或資料模式比對) 時，會比 CPU 型加速器更有效率。許多加速工作負載 (例如轉譯、轉碼和機器學習) 在資源用量方面極為變化不定。只在需要時執行此硬體，不需要時便將其自動除役，以將資源消耗降至最低。
## 實作步驟
+ 識別哪些 [加速運算執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html) 可以滿足您的要求。
+ 針對機器學習工作負載，請利用專供工作負載使用的專用硬體，例如 [AWS Trainium](https://aws.amazon.com/machine-learning/trainium/)、 [AWS Inferentia](https://aws.amazon.com/machine-learning/inferentia/)，和 [Amazon EC2 DL1](https://aws.amazon.com/ec2/instance-types/dl1/)。AWS Inferentia 執行個體 (例如 Inf2 執行個體) 最多可提供 [比同類 Amazon EC2 執行個體高出 50% 的效能功耗比](https://aws.amazon.com/machine-learning/inferentia/)。
+ 請收集加速運算執行個體的用量指標。例如，您可以使用 CloudWatch 代理程式來收集指標，像是 `utilization_gpu` 和 `utilization_memory` ，並將其用於您的 GPU，相關說明請見 [使用 Amazon CloudWatch 收集 NVIDIA GPU 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPU.html)。
+ 優化硬體加速器的程式碼、網路運作和設定，以確保系統會充分利用基礎硬體。
+ [優化 GPU 設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/optimize_gpu.html)
+ [Deep Learning AMI 中的 GPU 監控和優化](https://docs.aws.amazon.com/dlami/latest/devguide/tutorial-gpu.html)
+ [將 I/O 優化以針對 Amazon SageMaker AI 中的深度學習訓練進行 GPU 效能調校](https://aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/)
+ 使用最新的高效能程式庫和 GPU 驅動程式。
+ 使用自動化來釋出不使用的 GPU 執行個體。
## 資源
**相關文件：**
+ [加速運算](https://aws.amazon.com/ec2/instance-types/#Accelerated_Computing)
+ [ 開始建構吧！ 使用自訂晶片和加速器來進行建構 ](https://aws.amazon.com/blogs/architecture/lets-architect-custom-chips-and-accelerators/)
+ [ 如何為工作負載選擇適當的 Amazon EC2 執行個體類型？ ](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/)
+ [Amazon EC2 VT1 執行個體](https://aws.amazon.com/ec2/instance-types/vt1/)
+ [ 選擇最佳的 AI 加速器和模型編譯以 Amazon SageMaker AI 推斷電腦視覺 ](https://aws.amazon.com/blogs/machine-learning/choose-the-best-ai-accelerator-and-model-compilation-for-computer-vision-inference-with-amazon-sagemaker/)
**相關影片：**
+ [ 如何為深度學習選取 Amazon EC2 GPU 執行個體 ](https://www.youtube.com/watch?v=4bVrIbgGWEA)
+ [部署經濟實惠的深度學習推斷](https://www.youtube.com/watch?v=WiCougIDRsw)
# 程序和文化
**Topics**
+ [SUS 6 您的組織程序如何支持您的永續性目標？](sus-06.md)
# SUS 6 您的組織程序如何支持您的永續性目標？
透過變更開發、測試和部署實務來尋找降低永續性影響的機會。
**Topics**
+ [SUS06-BP01 採用可快速導入永續性改進的方法](sus_sus_dev_a2.md)
+ [SUS06-BP02 讓工作負載保持在最新狀態](sus_sus_dev_a3.md)
+ [SUS06-BP03 提高建置環境的使用率](sus_sus_dev_a4.md)
+ [SUS06-BP04 使用受管 Device Farm 進行測試](sus_sus_dev_a5.md)
# SUS06-BP01 採用可快速導入永續性改進的方法
採用相關方法和程序來驗證潛在改善、盡可能降低測試成本，以及提供小幅改善。
**常見的反模式：**
+ 審查應用程式的永續性是僅需在專案開始時執行一次的任務。
+ 您的工作負載已過時，因為發行程序太繁瑣而無法導入資源效率的小幅變更。
+ 您沒有改善工作負載以維持永續性的機制。
**建立此最佳實務的優勢：**建立導入和追蹤永續性改善的程序後，您將可持續採用新的特性和功能、消除問題，並改善工作負載效率。
**未建立此最佳實務時的風險暴露等級：**中
## 實作指引
在將潛在永續性改善部署到生產環境之前，先加以測試和驗證。在計算改善所帶來的未來潛在利益時，應考慮測試成本。開發低成本測試方法以提供小幅改善。
**實作步驟**
+ 在開發積存中新增永續性改善的要求。
+ 使用迭代[改善程序](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/improvement-process.html)對這些改善進行識別、評估、優先順序設定、測試及部署。
+ 持續改善並簡化您的開發程序。例如，[使用持續整合與持續交付 (CI/CD) 管道自動執行軟體交付程序](https://aws.amazon.com/getting-started/hands-on/set-up-ci-cd-pipeline/)，以測試及部署潛在改善，進而減少工作量和手動程序導致的錯誤。
+ 使用最低可行的代表元件開發並測試潛在改善，以降低測試成本。
+ 持續評估改善的影響，並視需要進行調整。
## 資源
**相關文件：**
+ [AWS 提供永續性解決方案](https://aws.amazon.com/sustainability/)
+ [以 AWS CodeCommit 為基礎的可擴展敏捷開發實務](https://aws.amazon.com/blogs/devops/scalable-agile-development-practices-based-on-aws-codecommit/)
**相關影片：**
+ [提供永續、高效能的架構](https://www.youtube.com/watch?v=FBc9hXQfat0)
**相關範例：**
+ [Well-Architected 實驗室 - 將成本和用量報告轉換為效率報告](https://www.wellarchitectedlabs.com/sustainability/300_labs/300_cur_reports_as_efficiency_reports/)
# SUS06-BP02 讓工作負載保持在最新狀態
將工作負載保持在最新狀態，以採用高效功能、去除問題，以及改善工作負載的整體效率。
**常見的反模式：**
+ 您假設目前的架構是靜態的，且不會隨著時間而更新。
+ 您沒有任何系統或定期規律可評估更新的軟體與套件是否與您的工作負載相容。
**建立此最佳實務的優勢：**建立讓工作負載保持在最新狀態的程序後，您將可採用新的特性和功能、解決問題，並改善工作負載效率。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
最新的作業系統、執行階段、中介軟體、程式庫和應用程式可改善工作負載效率，讓您更輕鬆地採用更有效率的技術。隨著供應商提供符合自身永續性目標的功能，最新軟體也可能包含更準確測量工作負載對永續性影響的功能。定期以最新的功能和版本將工作負載保持在最新狀態。
**實作步驟**
+ 定義相關程序和排程來評估工作負載的新功能和執行個體。利用雲端的靈活性快速測試新功能對您的工作負載有何改善，藉以：
+ 降低永續性的影響。
+ 獲得效能效率。
+ 消除已計劃改善的障礙。
+ 提升測量和管理永續性影響的能力。
+ 清查工作負載軟體和架構，並識別需要更新的元件。
+ 您可以使用 [AWS Systems Manager Inventory](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html)，從您的 Amazon EC2 執行個體收集作業系統 (OS)、應用程式和執行個體中繼資料，並快速了解哪些執行個體正在執行您的軟體政策所需的軟體與組態，以及哪些執行個體需要更新。
+ 了解如何更新工作負載的元件。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2023-10-03/framework/sus_sus_dev_a3.html)
+ 使用更新程序自動化，以減少部署新功能的工作量，並避免手動程序引起的錯誤。
+ 您可以使用 [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) 自動更新 AMI、容器映像，以及其他與您的雲端應用程式有關的成品。
+ 您可以使用 [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 之類的工具自動執行系統更新的程序，並使用 [AWS Systems Manager 維護時段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)來排程活動。
## 資源
**相關文件：**
+ [AWS 架構中心](https://aws.amazon.com/architecture)
+ [AWS 最新消息](https://aws.amazon.com/new/?ref=wellarchitected&ref=wellarchitected)
+ [AWS 開發人員工具](https://aws.amazon.com/products/developer-tools/)
**相關範例：**
+ [Well-Architected 實驗室 - 清查和修補程式管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/)
+ [實驗室：AWS Systems Manager](https://mng.workshop.aws/ssm.html)
# SUS06-BP03 提高建置環境的使用率
提高資源的使用率以開發、測試及建置您的工作負載。
**常見的反模式：**
+ 您以手動方式佈建或終止您的建置環境。
+ 您讓建置環境在測試、建置或發行活動以外執行 (例如，在開發團隊成員的非上班時間執行環境)。
+ 您為建置環境過度佈建資源。
**建立此最佳實務的優勢：**藉由提高建置環境的使用率，您將可改善雲端工作負載的整體效率，同時為建置人員配置有效開發、測試和建置所需的資源。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
使用自動化和基礎設施即程式碼，在需要時啟動建置環境，並在不使用時將其關閉。常見的模式是排程可用性時間，使之與開發團隊成員的工作時間一致。您的測試環境應該會與生產組態近似。不過，請找機會使用具有高載容量的執行個體類型、Amazon EC2 Spot 執行個體、自動調整規模資料庫服務、容器和無伺服器技術，以根據使用量調整開發和測試容量。將資料量限定為剛好達到測試要求。如果在測試中使用生產資料，請尋求從生產環境共用資料的可能性，而不要移動資料。
**實作步驟**
+ 使用基礎設施即程式碼佈建您的建置環境。
+ 使用自動化來管理開發和測試環境的生命週期，並且讓建置資源發揮最大效益。
+ 利用策略讓開發和測試環境達到最大的使用率。
+ 使用最低可行的代表環境來開發和測試潛在改善。
+ 在情況允許時使用無伺服器技術。
+ 使用隨需執行個體補充開發人員裝置。
+ 使用具有高載容量的執行個體類型、Spot 執行個體和其他技術，以根據使用量調整建置容量。
+ 採用原生雲端服務來獲得安全的執行個體 Shell 存取，而非部署堡壘主機機群。
+ 根據您的建置任務自動調整建置資源規模。
## 資源
**相關文件：**
+ [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)
+ [Amazon EC2 高載效能執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)
+ [什麼是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [什麼是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS 上的 Instance Scheduler](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
**相關影片：**
+ [持續整合最佳實務](https://www.youtube.com/watch?v=77HvSGyBVdU)
# SUS06-BP04 使用受管 Device Farm 進行測試
使用受管 Device Farm 有效測試代表性硬體集上的新功能。
**常見的反模式：**
+ 您在個別實體裝置上手動測試及部署應用程式。
+ 您未在真正的實體裝置上使用應用程式測試服務來測試及操作應用程式 (例如 Android、iOS 和 Web 應用程式)。
**建立此最佳實務的優勢：**使用受管 Device Farm 來測試具備雲端功能的應用程式有許多好處：
+ 將有更多功能可用來測試各種裝置上的應用程式。
+ 無須再以內部基礎設施進行測試。
+ 提供多種裝置類型 (包括較舊且較不熱門的硬體)，因而無須再進行不必要的裝置升級。
**未建立此最佳實務時的風險暴露等級：**低
## 實作指引
使用受管 Device Farm 有助於簡化對代表性硬體集上的新功能進行測試的程序。受管 Device Farm 提供多種裝置類型 (包括較舊且較不熱門的硬體)，並避免不必要的裝置升級對客戶的永續性造成影響。
**實作步驟**
+ 定義您的測試要求和計劃 (例如測試類型、作業系統和測試排程)。
+ 您可以使用 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 來收集和分析用戶端資料，並研擬您的測試計劃。
+ 選取可支援測試要求的受管 Device Farm。例如，您可以使用 [AWS Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/welcome.html) 來測試和了解您的變更對代表性硬體集有何影響。
+ 使用持續整合/持續部署 (CI/CD) 排程及執行您的測試。
+ [整合 AWS Device Farm 與您的 CI/CD 管道以執行跨瀏覽器 Selenium 測試](https://aws.amazon.com/blogs/devops/integrating-aws-device-farm-with-ci-cd-pipeline-to-run-cross-browser-selenium-tests/)
+ [使用 AWS DevOps 和行動服務建置及測試 iOS 和 iPadOS 應用程式](https://aws.amazon.com/blogs/devops/building-and-testing-ios-and-ipados-apps-with-aws-devops-and-mobile-services/)
+ 持續審查測試結果並進行必要的改進。
## 資源
**相關文件：**
+ [AWS Device Farm 裝置清單](https://awsdevicefarm.info/)
+ [檢視 CloudWatch RUM 儀表板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-view-data.html)
**相關範例：**
+ [Android 的 AWS Device Farm 範例應用程式](https://github.com/aws-samples/aws-device-farm-sample-app-for-android)
+ [iOS 的 AWS Device Farm 範例應用程式](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios)
+ [AWS Device Farm 的 Appium Web 測試](https://github.com/aws-samples/aws-device-farm-sample-web-app-using-appium-python)
**相關影片：**
+ [透過最終使用者洞察與 Amazon CloudWatch RUM 優化應用程式](https://www.youtube.com/watch?v=NMaeujY9A9Y)