# 架構的六大支柱
建立軟體系統很像是在興建大樓。若基礎不牢固，結構問題可能會逐漸影響建築物的完整性和功能。建構技術解決方案時，若您忽略卓越營運、安全性、可靠性、效能效率、成本最佳化和永續性這六大支柱，那麼建置滿足您期望與需求的系統將成為一項挑戰。將這些支柱納入您的架構，可協助您產出穩定又高效的系統。如此可允許您聚焦在設計的其他面向，例如功能要求。
**Topics**
+ [操作效能](operational-excellence.md)
+ [安全](security.md)
+ [可靠性](reliability.md)
+ [效能效率](performance-efficiency.md)
+ [成本最佳化](cost-optimization.md)
+ [永續性](sustainability.md)
# 操作效能
卓越營運 (OE) 是一項承諾，代表致力於妥善設計軟體，同時持續提供絕佳的客戶體驗。卓越營運支柱包括組織團隊、設計工作負載、大規模運作工作負載及促使其進化的最佳實務。
卓越營運支柱概述了設計原則、最佳實務和相關問題。您可以在[卓越營運支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)中找到實作指引。
**Topics**
+ [設計原則](oe-design-principles.md)
+ [定義](oe-definition.md)
+ [最佳實務](oe-bp.md)
+ [資源](oe-resources.md)
# 設計原則
下列設計原則有助於實現雲端中的卓越營運：
+ **圍繞業務成果組織團隊：**團隊實現業務成果的能力來自於領導力願景、高效運營以及與業務保持一致的運營模式。領導力應該充分投入，並致力於使用合適的雲端作業模式進行 CloudOps 轉型，以鼓勵團隊以最有效的方式營運並達成業務成果。正確的營運模式會利用人員、流程和技術能力來擴展、最佳化生產力，並透過敏捷性、回應性和適應性來實現差異化。組織的長期願景轉化為目標，並在整個企業內傳達給雲端服務的利益相關者和消費者。目標和營運 KPI 在各個層面都一致。這種做法維持了實作下列設計原則所帶來的長期價值。
+ **實作可觀測性以獲得可採取行動的見解：**全面了解工作負載的行為、效能、可靠性、成本和運作狀態。建立關鍵績效指標 (KPI)，並利用可觀測性遙測來做出明智的決策，並在業務成果有風險時迅速採取行動。根據可採取行動的可觀測性資料，主動改善效能、可靠性和成本。
+ **盡可能安全地自動化：**在雲端，您可以在整個環境中套用與您應用程式程式碼所用相同的工程原則。可以將整個工作負載及其操作 (應用程式、基礎設施、組態和程序) 定義為程式碼，然後進行更新。然後，可以透過回應事件來啟動工作負載操作，從而將其自動化。在雲端中，可以透過設定防護機制來採用自動化安全性，包括速率控制、錯誤閾值和核准。透過有效的自動化，可以實現對事件的一致回應，限制人為錯誤並減少操作員的辛勞。
+ **進行頻繁、細微和可逆的變更：**設計可擴展且鬆散耦合的工作負載以允許定期更新元件。自動化部署技術加上較細微的增量變更可縮減影響範圍，並在發生故障時更快地反轉情況。這增加了信心，可以為您的工作負載提供有益的變化，同時保持品質並快速適應市場情況的變化。
+ **經常改進營運程序：**隨著工作負載的進化，適當地發展您的營運。在使用營運程序時，尋找機會予以改善。定期審查並驗證所有程序是否有效以及團隊是否熟悉這些程序。如果發現差距，請相應地更新程序。向所有利益相關者和團隊傳達程序更新。將營運遊戲化以分享最佳實務並教導團隊。
+ **預料失敗：**透過推動故障情境來了解工作負載的風險狀況及其對業務成果的影響，從而最大程度提高營運成功率。針對這些模擬失敗，測試程序的有效性和團隊的回應。制定明智的決策，以管理您的測試所識別的開放式風險。
+ **從所有營運事件和指標中學習**：透過從所有營運事件和失敗中學習的經驗來推動改進。跨團隊及在整個組織中分享獲得的經驗。學習應強調有關營運如何為業務成果做出貢獻的資料和軼事。
+ **使用受管服務：**盡可能地使用 AWS 受管服務以降低營運負擔。圍繞與這些服務的互動建置營運程序。
# 定義
雲端有四種最佳實務領域可實現卓越營運：
+ **組織**
+ **準備**
+ **營運**
+ **演進**
組織的領導階層定義業務目標。您的組織必須了解需求和優先順序，並使用這些來組織和執行工作以支援業務成果的實現。您的工作負載必須提供支援工作負載所需的資訊。透過自動化重複程序，實作服務以實現工作負載的整合、部署和交付將為生產帶來更多有利的變更。
工作負載的操作本質上就可能存在著風險。了解這些風險，並做出明智的決策才能進入生產階段。您的團隊必須能夠支援您的工作負載。從所需業務成果衍生的業務和營運指標，將允許您了解工作負載的運作狀態、營運活動，並回應事件。您的優先事項會隨著業務需求和業務環境的變化而改變。運用這些方面做為回饋迴圈，以持續改善貴組織和工作負載的運作。
# 最佳實務
**注意**
所有卓越營運問題都有 OPS 字首作為支柱的速記。
**Topics**
+ [組織](oe-organization.md)
+ [準備](oe-prepare.md)
+ [操作](oe-operate.md)
+ [演進](oe-evolve.md)
# 組織
您的團隊必須對您的整個工作負載以及團隊成員在其中的作用達成共識，並且擁有共同的業務目標，以便設定能實現業務成功的優先事項。明確定義的優先事項將實現工作的最大收益。評估內部與外部客戶需求，並讓關鍵利益相關者 (包括業務、開發和營運團隊) 參與進來，以確定工作的重點領域。評估客戶需求將驗證您對實現業務成果所需的支援有透徹的了解。確保您了解由貴組織管控所定義的、可能要求或強調特定重點的準則或義務以及外部因素，例如法規合規要求和產業標準。確認您是否設有識別內部管控和外部合規要求變更的機制。如果未識別要求，請確保您已對此決定進行盡職調查。定期審查您的優先事項，以便在需求變更時更新優先事項。
評估對業務的威脅 (例如，業務風險和負債以及資訊安全威脅)，並將此資訊保存在風險登記表內。評估風險的影響，以及利益衝突或替代方法之間的權衡。例如，新功能加速上市可能是成本最佳化所強調的重點，或您可為非關聯式資料選擇關聯式資料庫，以簡化系統遷移工作而無須重構。管理收益和風險，以便在確定工作重點時做出明智的決定。某些風險或選擇可能在一段時間內是可以接受的，相關風險可能得以減輕，也可能出現無法接受風險存在的事實，在此情況下，您將需要採取動作來解決風險。
您的團隊必須了解其在達成業務成果中所扮演的角色。團隊必須了解自己在促成其他團隊成功的過程中所扮演的角色、其他團隊在促進其成功的過程中所扮演的角色，以及擁有共同目標。了解責任、擁有權、決策方式，以及誰有權制定決策，將有助於找到工作重點，並充分發揮團隊的優勢。團隊的需求將由其所支援的客戶、組織、團隊組成，以及工作負載的特性形塑而成。合理來說，無法要求單一操作模式支援貴組織中的所有團隊及其工作負載。
驗證每個應用程式、工作負載、平台和基礎設施元件都有已識別擁有者，而且每個流程和程序都有負責其定義的已識別擁有者，以及負責其執行的擁有者。
透過了解每個元件、流程和程序的商業價值、為何部署這些資源或為何執行活動，以及該擁有權為何存在，有助於團隊成員採取適當動作。明確界定團隊成員的責任，以便他們可以採取適當行動，並具有識別責任和擁有權的機制。擁有請求增加、變更和例外狀況的機制，這樣您就不會限制創新。定義團隊之間的協議，說明他們如何協同合作以互相支援並實現業務成果。
為您的團隊成員提供支援，讓他們能夠更有效地採取動作以及支援業務成果。參與的高階領導層應設定期望並衡量成功。資深領導階層應是採用最佳實務和組織演進的發起者、倡導者和推動者。當成果出現風險時，讓團隊成員採取行動，將影響降到最低，同時鼓勵他們在遇到風險時，向決策者和利益相關者呈報，以便處理問題並避免事故。針對已知風險和計劃事件進行及時、明確且可採取動作的溝通，讓團隊成員能夠及時採取適當的動作。
鼓勵試驗以加速學習，讓團隊成員保持興趣並積極參與。團隊必須發展自己的技能集，以採用新技術，並支援需求和責任的變更。提供專門的結構化時間用於學習，以支援並鼓勵這一舉措。驗證團隊成員擁有可取得成功並進行擴展的資源 (包括工具和團隊成員)，以協助達成您的業務成果。利用跨組織的多樣性，尋求多種獨特的觀點。使用此觀點來增加創新、挑戰假設，並降低確認偏差的風險。在團隊中增加包容性、多樣性和可及性，以獲得有益的觀點。
若有適用於貴組織的外部法規或合規要求，則您應使用 [AWS 雲端合規](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)提供的資源來協助教育您的團隊，以便他們可以判斷對您的優先事項的影響。Well-Architected 架構強調學習、衡量和改善。它為您提供可評估架構並實作將隨時間擴展之設計的一致方法。AWS 提供 AWS Well-Architected Tool 以協助您在開發前審核您的方法、生產前的工作負載狀態以及生產中工作負載的狀態。您可以將工作負載與最新的 AWS 架構最佳實務做比較、監控工作負載的整體狀態，以及深入了解潛在風險。AWS Trusted Advisor 是一款可存取核心檢查集的工具，這些檢查提出了優化建議，可能有助您確定優先事項。商業和企業支援客戶可存取針對安全性、可靠性、效能、成本優化以及永續性的其他檢查，從而進一步協助確定他們的優先事項。
AWS 可以協助您教育您的團隊有關 AWS 及其服務的知識，從而增進他們對自己的選擇會如何影響工作負載的了解。使用 AWS 支援 (AWS 知識中心、AWS 論壇和 AWS 支援 中心) 和 AWS 文件中的資源來教育您的團隊。請透過 AWS 支援 Center 聯絡 AWS 支援，尋求 AWS 相關問題的協助。AWS 還分享了我們透過在 Amazon 建置者資料中心的 AWS 操作中學到的最佳實務和模式。您可透過 AWS 部落格和官方 AWS 播客獲得其他各種實用資訊。AWSTraining and Certification 透過 AWS 基礎原理中的自主進度數位課程提供一些培訓。您還可以報名參加講師指導下的培訓，以進一步協助開發團隊的 AWS 技能。
使用能集中管控跨帳戶環境的工具或服務，例如 AWS Organizations，以便協助您管理操作模式。AWS Control Tower 等服務會擴大此管理功能，允許您定義帳戶設定的藍圖 (支援您的操作模式)、使用 AWS Organizations 套用持續管控，以及自動化新帳戶的佈建作業。AWS Managed Services、AWS Managed Services 合作夥伴等受管服務供應商，或 AWS 合作夥伴網路中的受管服務供應商，都會提供實作雲端環境的專業知識，並支援您的安全和合規要求及業務目標。將受管服務加入操作模式後，便可節省時間和資源，讓您的內部團隊精簡並專注於將使您的企業脫穎而出的策略性成果，而非開發新技能和功能。
下列問題著重於卓越營運方面的這些考量。(如需卓越營運問題清單和最佳實務，請參閱[附錄](a-organization.md))。
| OPS 1：如何決定您的優先事項？ |
| --- |
| 每個人都必須了解自己在實現商業成功中的角色。擁有共同目標以設定資源優先順序。這會充分發揮您所做努力的優勢。 |
| OPS 2：如何建構組織以支援業務成果？ |
| --- |
| 您的團隊必須了解其在達成業務成果中所扮演的角色。團隊必須了解自己在促成其他團隊成功的過程中所扮演的角色、其他團隊在促進其成功的過程中所扮演的角色，以及擁有共同目標。了解責任、擁有權、決策方式，以及誰有權制定決策，將有助於找到工作重點，並充分發揮團隊的優勢。 |
| OPS 3：您的組織文化如何支援您的業務成果？ |
| --- |
| 為您的團隊成員提供支援，讓他們能夠更有效地採取動作以及支援業務成果。 |
您可能會發現，您在某個時間點會想要強調一小部分的優先事項。長期利用平衡的方法，以驗證開發所需的功能和管理風險。定期審查優先事項，並隨需求的變更進行更新。如果責任和擁有權未定義或未知，則您會面臨風險，不僅無法及時執行必要的動作，在解決這些需求時還會出現冗餘和可能相互衝突的工作。組織文化對團隊成員工作滿意度和留任率有直接影響。讓團隊成員參與其中並習得能力，以實現業務成功。必需要經由試驗才能實現創新，並讓想法轉化為成果。辨識不想要的結果是代表這是一場成功的試驗，因為可以判斷出不會通往成功途徑。
# 準備
要為卓越營運做好準備，您必須了解您的工作負載及其預期行為。然後，您就能將其設計出來，以了解它們的狀態並建置可提供支援的程序。
設計您的工作負載，使其提供必要資訊，讓您了解所有元件的內部狀態 (例如，指標、日誌、事件和追蹤)，以支援可觀測性和調查問題。可觀測性不僅是單純的監控，還可根據系統的外部輸出全面了解系統的內部運作狀況。基於指標、日誌和追蹤，可觀測性為系統行為和動態提供深刻的見解。透過有效的可觀測性，團隊可以辨別模式、異常情況和趨勢，讓他們能夠主動解決潛在問題並維持最佳的系統運作狀態。確定關鍵績效指標 (KPI) 對於確保監控活動與業務目標之間的一致性至關重要。這種一致性可確保團隊使用真正重要的指標來做出資料驅動的決策，從而最佳化系統效能和業務成果。此外，可觀測性使企業能夠主動出擊，而不是被動應對。團隊可以了解系統內的因果關係，預測和預防問題，而不僅僅是對問題做出反應。隨著工作負載的演進，務必重新檢視並改進可觀測性策略，以保持相關性和有效性。
採用的方法需能夠改善變更進入生產環境的流程，並實現重構、快速品質意見回饋及錯誤修復。這會加快有助益的變更進入生產環境的速度、限制部署問題，並快速識別和修復部署活動所導致或在您的環境中所發現的問題。
採用可快速提供品質意見回饋，並從成果不盡理想的改變中快速復原的方法。使用這些實務可緩解部署變更所帶來問題的影響。為變更失敗做好規劃，以便在必要時能夠快速回應，同時測試並驗證所做變更。了解環境中的計劃內活動，以便管理會影響計劃內活動的變更風險。強調頻繁、細微、可逆的變更，以限制變更範圍。透過回復變更，可以更快地進行疑難排解和修復。這也表示您從有價值變更中受益的頻率會提高。
評估工作負載、流程、程序及人員的營運準備度，以了解與工作負載相關的營運風險。使用一致的程序 (包括手動或自動檢查清單) 來獲悉工作負載或變更執行就緒的時間。這樣也有助於尋找您必須制定計畫以解決問題的任何領域。具備可記錄例行活動的執行手冊，以及可指引問題解決程序的程序手冊。了解收益和風險，以做出明智決策，讓變更順利進入生產環境。
AWS 允許您以程式碼檢視您的整個工作負載 (應用程式、基礎設施、原則、管控和營運)。這表示您可以將用於應用程式程式碼的相同工程規則套用到堆疊的每個元素，並在團隊或組織之間分享這些元素，以擴大開發工作的優勢。在雲端以程式碼執行營運，並利用安全進行試驗的能力，開發工作負載、營運程序以及實務失敗案例。使用 CloudFormation 允許您擁有一致的範本化沙盒開發、測試和生產環境，同時還能提高營運控制等級。
下列問題著重於卓越營運方面的這些考量。
| OPS 4：如何在工作負載中實作可觀測性？ |
| --- |
| 在工作負載中實作可觀測性，以便了解其狀態，並根據業務需求做出資料驅動的決策。 |
| OPS 5：您如何減少缺陷、幫助輕鬆修復，以及改善生產流程？ |
| --- |
| 採用可改進生產變更流程的方法，從而重構快速的品質回饋及錯誤修復。這些方法會加快有助益的改變發揮作用的速度、限制部署問題，並快速識別和修復部署活動造成的問題。 |
| OPS 6：您如何緩解部署風險？ |
| --- |
| 採用可快速提供品質意見回饋，並從成果不盡理想的改變中快速復原的方法。使用這些實務可緩解部署變更所帶來問題的影響。 |
| OPS 7：您如何知道自己準備好支援工作負載？ |
| --- |
| 評估工作負載、流程和程序及人員的營運準備度，了解工作負載相關營運風險。 |
對以程式碼形式實作營運活動進行投資，從而最大程度地提高營運人員的生產力，將錯誤率降至最低以及實現自動回應。使用「事前剖析」可預測失敗並適時建立程序。依照一致的標記策略，使用資源標籤和 AWS Resource Groups 來套用中繼資料，以識別您的資源。標記您的資源，以用於組織、成本會計、存取控制，以及將自動執行營運活動設為目標。採用可利用雲端彈性的部署實務，以促進開發活動和系統的預部署，進而加快實作速度。變更您用於評估工作負載的檢查清單時，請計劃如何處理不再合規的即時系統。
# 操作
可觀測性讓您能夠專注於有意義的資料，並了解工作負載的互動和結果。透過專注於基本洞察並消除不必要的資料，可以維持一種簡單的方法來了解工作負載效能。不僅要收集資料，還要正確解譯資料，這至關重要。定義明確的基準，設定適當的警示閾值，並主動監控任何偏差。關鍵指標的變化，特別是與其他資料相關時，可以查明特定的問題區域。有了可觀測性，您就具備更優異的預測能力，並且能應付潛在的挑戰，進而確保工作負載順利運行並滿足業務需求。
我們可根據業務和客戶成果的實現情況，衡量是否成功運作工作負載。定義預期成果，確定如何衡量成功，並識別可用於這些計算的指標，以確定工作負載和營運是否成功。運作狀態包括工作負載的運作狀態以及為支援工作負載而執行的營運活動的運作狀態和成功情況 (例如，部署和事故回應)。建立指標基準以便進行改善、調查和介入；收集並分析指標；然後，驗證您對營運成功及其隨著時間的變化情況的理解。使用收集的指標來確定您是否滿足客戶和業務需求，並識別有待改善的領域。
要實現卓越營運，必須高效且有效地管理營運事件。這適用於計劃和非計劃中的營運事件。使用已建立的執行手冊處理眾所周知的事件，並使用程序手冊協助調查和解決問題。根據事件對業務和客戶的影響來確定回應事件的優先順序。驗證如因回應事件而發出提醒，則將由明確識別的擁有者執行關聯程序。事先定義解決事件所需的人員，並納入向上呈報程序，以在必要時根據緊迫性和影響力，在其中新增額外的參與人員。識別並邀請具有權限的個人來決定行動方案，該方案將受到先前未解決的事件回應的業務影響。
透過針對目標受眾 (例如，客戶、業務、開發人員、營運) 量身定制的儀表板和通知來傳達工作負載的運行狀態，以便他們能採取適當的動作，進而管理他們的期望並在恢復正常營運時得到通知。
在 AWS 中，您可以產生從工作負載或以原生方式從 AWS 收集的指標的儀表板視圖。您可以利用 CloudWatch 或第三方應用程式來彙總和呈現營運活動的業務、工作負載和營運層級檢視。AWS 透過 AWS X-Ray、CloudWatch、CloudTrail 以及 VPC Flow Logs 等日誌記錄功能來提供工作負載洞見，以識別工作負載問題，支援根本原因分析和修復。
下列問題著重於卓越營運方面的這些考量。
| OPS 8：如何在組織中利用工作負載可觀測性？ |
| --- |
| 利用可觀測性確保最佳的工作負載運作狀況。利用相關指標、日誌和追蹤，全面掌握工作負載效能並有效解決問題。 |
| OPS 9：您如何了解營運狀況？ |
| --- |
| 定義、擷取和分析營運指標，掌握營運事件，以便採取適當行動。 |
| OPS 10：您如何管理工作負載和營運事件？ |
| --- |
| 準備和驗證回應事件的程序，大幅降低工作負載中斷情形。 |
您收集的所有指標都應該符合業務需求及其支援的結果。開發針對已充分了解之事件的指令碼式回應，並自動化其效能以回應事件辨識。
# 演進
學習、分享和持續改善以維持卓越營運。將工作週期用於進行幾乎持續的逐漸改善。針對所有影響客戶的事件執行事件後分析。確定促成因素和預防措施，以限制或防止再次發生。適當地與受影響的社區溝通促成因素。定期評估改進機會 (例如，功能請求、問題修復和合規要求) 並確定其優先順序，包括工作負載和營運程序。
在您的程序中納入回饋迴圈，以快速識別有待改善的領域並從正在執行的營運中獲得經驗。
在遊戲日內，可跨團隊分享獲得的經驗，進而分享這些經驗的益處。分析經驗教訓中的趨勢，並對運營指標執行跨團隊回顧性分析，以確定改進的機會和方法。實作旨在帶來改善的變更，並評估結果以判斷是否成功。
在 AWS 中，您可以將日誌資料匯出至 Amazon S3 或直接將日誌傳送至 Amazon S3，以便長期儲存。您可以使用 AWS Glue，在 Amazon S3 中探索和準備日誌資料以進行分析，並將相關聯的中繼資料儲存在 AWS Glue Data Catalog 中。Amazon Athena，透過與 AWS Glue 的原生整合，可用來分析日誌資料，並使用標準 SQL 進行查詢。您可以使用 Amazon Quick 這類商業智慧工具來視覺化、探索和分析資料。探索可能推動改善的感興趣趨勢和事件。
下列問題著重於卓越營運方面的這些考量。
| OPS 11：您如何改善營運？ |
| --- |
| 投入時間和資源，盡量持續逐漸改善，以加強營運的效果和效率。 |
成功的營運演進基於：頻繁、細微的改善；提供安全的環境和時間來試驗、開發和測試改善；鼓勵營造從失敗中學習的環境。隨著營運控制等級的提高，對沙盒、開發、測試和生產環境的營運支援可促進開發，並提高將變更部署至生產中後取得成功結果的可預測性。
# 資源
請參閱下列資源，進一步了解我們卓越營運的最佳實務。
## 文件
+ [DevOps 和 AWS](https://aws.amazon.com/devops/?ref=wellarchitected-wp)
## 白皮書
+ [卓越運作支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html?ref=wellarchitected-wp)
## 影片
+ [Amazon 的 DevOps](https://www.youtube.com/watch?v=esEFaY0FDKc&ref=wellarchitected-wp)
# 安全
安全支柱包含能夠保護資料、系統和資產，以利用雲端技術來改善安全性。
安全支柱概述了設計原則、最佳實務和相關問題。可以在[安全支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp)中找到實作指引。
**Topics**
+ [設計原則](sec-design.md)
+ [定義](sec-def.md)
+ [最佳實務](sec-bp.md)
+ [資源](sec-resources.md)
# 設計原則
雲端中有一些原則能協助您強化工作負載的安全：
+ **實作堅實的身分識別基礎：**實作最低權限原則，並對於每個與 AWS 資源的互動強制執行職責與適當的授權分離。集中進行身分管理，旨在消除對長期靜態憑證的倚賴。
+ **維持可追蹤性**：即時監控、提醒和稽核您環境中發生的動作和變更。將日誌和指標收集與系統進行整合，以自動調查並採取動作。
+ **在所有層級套用安全**：透過多個安全控制，套用深度防禦方法。套用至所有層級 (例如，網路邊緣、VPC、負載平衡、每個執行個體和運算服務、作業系統、應用程式和程式碼)。
+ **將安全最佳實務自動化**：將基於軟體的安全機制自動化，以提高您安全、快速和以具成本效益的方式擴展的能力。建立安全架構 (包括實作控制) 在版本控制的範本中作為程式碼定義和管理。
+ **保護傳輸中和靜態資料**：將您的資料分為不同的敏感性等級，並使用適當的機制，例如加密、記號化及存取控制。
+ **讓人員遠離資料**：使用機制和工具，來降低或消除對直接存取或手動處理資料的需要。在處理敏感資料時，這降低了處理不當或修改以及人為錯誤的風險。
+ **為安全事件作準備：**為事故做好萬全準備，建立與您組織的要求吻合的事件管理和調查政策與程序。執行失敗回應模擬和使用工具與自動化，以提高偵測、調查和復原的速度。
# 定義
雲端安全有七個最佳實務領域：
+ 安全基礎
+ 身分與存取管理
+ 偵測
+ 基礎設施保護
+ 資料保護
+ 事件回應
+ 應用程式安全
在架構任何工作負載之前，您需要採取影響安全性的實務。您會希望控制誰可以做什麼。另外，您需要能夠識別安全事故、保護系統和服務，並透過資料保護維持資料的保密與完整。您應當具備界定完善且經過演練的程序，以因應安全事故。這些工具和技術之所以重要，因為能支援諸多目的，例如防止財務損失或遵循法規義務。
AWS 共同責任模型可幫助採用雲端的組織能夠達成安全與合規目標。AWS 能實體上地保護支援本公司雲端服務的基礎設施，好讓作為 AWS 戶的您專心使用服務以達成目標。AWS 雲端還提供對安全資料更好的存取，並有自動方式可回應安全事件。
# 最佳實務
**Topics**
+ [安全基礎](sec-security.md)
+ [身分與存取管理](sec-iam.md)
+ [偵測](sec-detection.md)
+ [基礎設施保護](sec-infrastructure.md)
+ [資料保護](sec-dataprot.md)
+ [事件反應](sec-incresp.md)
+ [應用程式安全](sec-appsec.md)
# 安全基礎
下列問題著重於這些安全方面的考量。(如需安全問題和最佳實務的清單，請參閱[附錄](a-security.md)。)
| SEC 1：如何安全地操作工作負載？ |
| --- |
| 若要安全地操作工作負載，您必須將整體的最佳實務套用到每個安全區域。採用您在組織和工作負載層級於卓越營運中定義的要求和程序，並將其應用於所有區域。 透過 AWS 和產業建議與威脅情報持續取得最新資訊，可協助您發展威脅模型和控制目標。將安全程序、測試和驗證自動化可讓您擴展安全操作。 |
在 AWS 中，建議根據不同的功能和合規或資料敏感性等要求，依帳戶分隔不同的工作負載。
# 身分與存取管理
Identity and Access Management 是資訊安全計畫的關鍵部分，可確保只有經過授權和身分驗證的使用者和元件，才能以您想要的方式存取您的資源。例如，您應定義主體 (即為可在您的帳戶內執行動作的帳戶、使用者、角色和服務)，建立與這些主體一致的政策，並實作強勢憑證管理。這些權限管理元素構成身份驗證與授權的核心。
在 AWS 中，權限管理主要由 AWS Identity and Access Management (IAM) 服務支援，它讓您可以控制對 AWS 服務和資源的使用者和程式設計存取。您應該套用精細的政策，將權限分配給使用者、群組、角色或資源。您還可以要求使用強式密碼，例如要求複雜性等級、避免重複使用以及強制執行多重要素驗證 (MFA)。您可以將聯合身分驗證與現有目錄服務一起使用。對於要求系統有權存取 AWS 的工作負載，IAM 可以透過角色、執行個體描述檔、聯合身分和臨時登入資料來實現安全存取。
下列問題著重於安全方面的這些考量。
| SEC 2：如何管理人員和機器的身分？ |
| --- |
| 處理安全的 AWS 工作負載時，您需要管理兩種身分類型。了解您需要管理和授予存取權的身分類型，有助於確認正確的身分在適當的條件下存取正確的資源。 人員身分：管理員、開發人員、操作員及終端使用者需要身分才能存取 AWS 環境和應用程式。這些是貴組織的成員或與您協作的外部使用者，以及透過 Web 瀏覽器、用戶端應用程式或互動式命令列工具與 AWS 資源互動的外部使用者。 機器身分：您的服務應用程式、操作工具和工作負載需要身分，才能向 AWS 服務發出請求，例如讀取資料。這些身分包括在 AWS 環境 (例如 Amazon EC2 執行個體或 AWS Lambda 函數) 中執行的機器。您也可以為需要存取權的外部各方管理其機器身分。此外，您可能還有 AWS 外部機器需要存取 AWS 環境。 |
| SEC 3：如何管理人員和機器的許可？ |
| --- |
| 管理許可，以控制對需要存取 AWS 和工作負載的人員和機器身分的存取。許可控制誰可以在何種條件下存取哪些內容。 |
登入資料不得在任何使用者或系統之間共用。應使用最低權限的方法以及最佳實務 (包括密碼要求和強制執行 MFA) 來授予使用者存取權限。包括對 AWS 服務的 API 呼叫在內的程式設計存取應使用臨時和有限權限的登入資料 (例如由 AWS Security Token Service 發出的登入資料) 執行。
若使用者想要與 AWS 管理主控台 之外的 AWS 互動，則需要程式化存取權。授與程式化存取權的方式取決於存取 AWS 的使用者類型。
若要授予使用者程式設計存取權，請選擇下列其中一個選項。
****
| 哪個使用者需要程式設計存取權？ | 到 | 根據 |
| --- | --- | --- |
| IAM | (建議事項) 將主控台憑證用作臨時憑證來簽署對 AWS CLI、AWS SDK 或 AWS API 的程式設計請求。 | 請依照您要使用的介面所提供的指示操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/sec-iam.html) |
| 人力資源身分 (IAM Identity Center 中管理的使用者) | 使用臨時憑證簽署對 AWS CLI、AWS SDK 或 AWS API 的程式設計請求。 | 請依照您要使用的介面所提供的指示操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/sec-iam.html) |
| IAM | 使用臨時憑證簽署對 AWS CLI、AWS SDK 或 AWS API 的程式設計請求。 | 請遵循《IAM 使用者指南》中[使用臨時憑證搭配 AWS 資源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)中的指示。 |
| IAM | (不建議使用)使用長期憑證簽署 AWS CLI、AWS SDK 或 AWS API 的程式設計要求。 | 請依照您要使用的介面所提供的指示操作。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/framework/sec-iam.html) |
AWS 提供了可以幫助您進行身分和存取管理的資源。若要協助學習最佳實務，請探索我們的實作實驗室，了解如何[管理憑證和驗證](https://wellarchitectedlabs.com/Security/Quest_Managing_Credentials_and_Authentication/README.html?ref=wellarchitected-wp)、[控制人員存取](https://wellarchitectedlabs.com/Security/Quest_Control_Human_Access/README.html?ref=wellarchitected-wp)以及[控制程式設計式存取](https://wellarchitectedlabs.com/Security/Quest_Control_Programmatic_Access/README.html?ref=wellarchitected-wp)。
# 偵測
您可以使用偵測控制來識別潛在的安全威脅或事故。它們是管控框架的重要組成部分，可用於支援品質流程、法律或合規義務以及用於威脅識別和回應工作。偵測控制有不同的類型。例如，建立資產及其詳細屬性的詳細目錄可促進更有效的決策 (和生命週期控制)，以幫助建立營運基準。您還可以使用內部稽核，即檢查與資訊系統相關的控制，以確認實務符合政策和要求，並確保已根據定義的條件設定正確的自動提醒通知。這些控制是重要的反應式因素，可以幫助您的組織識別和了解異常活動的範圍。
在 AWS 中，您可以透過處理日誌、事件和監控來實作偵測控制，以進行稽核、自動分析和警示。CloudTrail 日誌、AWS API 呼叫和 CloudWatch 可監控指標並發出警示，AWS Config 可提供組態歷史。Amazon GuardDuty 是受管威脅偵測服務，可持續監控惡意或未經授權的行為，協助您保護 AWS 帳戶和工作負載。也提供服務層級日誌。例如，您可以使用 Amazon Simple Storage Service (Amazon S3) 記錄存取請求。
下列問題著重於這些安全方面的考量。
| SEC 4：您如何偵測和調查安全事件？ |
| --- |
| 從日誌和指標中擷取並分析事件，以獲得可見性。請針對安全事件和潛在威脅採取行動，以協助保護工作負載。 |
日誌管理對 Well-Architected 工作負載至關重要，原因包括安全/鑑識，以及法規或法律要求等。分析日誌並對其進行回應，以便可以識別潛在的安全事故，這一點至關重要。AWS 提供了讓您能夠定義資料保留生命週期或定義將在何處儲存、存檔或最終刪除資料的功能，從而使日誌管理更易於實作。這使得可預測和可靠的資料處理更加簡單，且更具成本效益。
# 基礎設施保護
基礎設施保護包括符合最佳實務和組織或監管義務所必需的控制方法，例如深度防禦。這些方法的使用對於雲端或內部部署成功持續營運至關重要。
在 AWS 中，您可以透過使用 AWS 原生技術或透過 AWS Marketplace 獲得的合作夥伴產品和服務，來實作有狀態和無狀態封包檢查。您應該使用 Amazon Virtual Private Cloud (Amazon VPC) 建立一個私有、安全且可擴展的環境，您可以在其中定義拓撲，包括閘道、路由表以及公有和私有子網路。
下列問題著重於安全方面的這些考量。
| SEC 5：如何保護您的網路資源？ |
| --- |
| 任何具有某種網路連線能力的工作負載，無論是網際網路或私有網路，都需要多層防禦來協助保護其不受外部和內部網路威脅的影響。 |
| SEC 6：您如何保護運算資源？ |
| --- |
| 工作負載中的運算資源需要多層防禦，以協助防範外部和內部威脅。運算資源包括 EC2 執行個體、容器、AWS Lambda 函數、資料庫服務、IoT 裝置等。 |
不管是何種類型的環境，建議使用多層防禦。就基礎設施保護而言，許多概念和方法在雲端和內部部署均有效。加強邊界保護、監控入口和出口以及全面的日誌記錄、監控和提醒，對於有效的資訊安全計畫均很重要。
AWS 客戶能夠量身訂製或強化 Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS) 容器或 AWS Elastic Beanstalk 執行個體的組態，並將組態持久保留到一個不變的 Amazon Machine Image (AMI)。然後，無論是由 Auto Scaling 啟動還是手動啟動，使用此 AMI 啟動的所有新虛擬伺服器 (執行個體) 都將獲得此強化組態。
# 資料保護
在設計任何系統之前，應建立影響安全性的基礎實務。例如，資料分類可基於敏感層級將組織的資料分類，加密則能對未經授權的存取將資料呈現為無法辨識，以保護資料。這些工具和技術之所以重要，因為能支援諸多目的，例如防止財務損失或遵循法規義務。
在 AWS 中，以下實務有助於保護資料：
+ 作為 AWS 客戶，您可完全控管資料。
+ AWS 讓您可以更輕鬆地加密資料和管理金鑰，包括常規的金鑰輪換。這些可以透過 AWS 輕鬆地自動化或由您手動維護。
+ 提供了包含重要內容 (例如檔案存取和變更) 的詳細日誌記錄。
+ AWS 設計的儲存系統具有卓越彈性。例如，Amazon S3 Standard、S3 Standard-IA、S3 One Zone-IA 和 Amazon Glacier 都在給定年份內提供 99.999999999% 的物件耐用性。此耐用性等級相當於 0.000000001% 物件年平均預期損失率。
+ 版本控制可以作為更大的資料生命週期管理過程的一部分，可以防止意外的覆寫、刪除和類似損害。
+ AWS 永遠不會主動移動區域之間的資料。除非您明確使用相關功能或利用提供相關功能的服務，否則放置在某個區域中的內容將保留在該區域中。
下列問題著重於安全方面的這些考量。
| SEC 7：您如何分類資料？ |
| --- |
| 資料分類可讓您根據關鍵性和敏感度將資料分類，協助判定適當的保護和保留控制。 |
| SEC 8：您如何保護靜態資料？ |
| --- |
| 實作多重控制來保護靜態資料，以降低未經授權存取或處理不當的風險。 |
| SEC 9：您如何保護傳輸中資料？ |
| --- |
| 實作多重控制來保護傳輸中的資料，以降低未經授權存取或遺失的風險。 |
AWS 提供多種加密靜態資料和傳輸中資料的方法。我們將功能內建到我們的服務中，讓您可以更輕鬆地加密資料。例如，我們為 Amazon S3 實作了伺服器端加密 (SSE)，讓您可以更輕鬆地以加密形式儲存資料。您還可以安排由 Elastic Load Balancing (ELB) 處理整個 HTTPS 加密和解密過程 (通常稱為 SSL 終止)。
# 事件反應
即使採用了非常成熟的預防和偵測控制，您的組織仍應建立適當的流程，來回應和緩和安全事故的潛在影響。工作負載的架構嚴重影響團隊在事故期間有效執行、隔離或控制系統，以及將營運恢復到已知良好狀態的能力。在發生安全事故之前布置好工具和存取權限，然後在演練日期間例行練習事故回應，將幫助您確認架構可以適應即時調查和復原。
在 AWS 中，以下實務有助於有效地回應事故：
+ 提供了包含重要內容的詳細日誌記錄，例如檔案存取和變更。
+ 可以自動處理事件並啟動工具，以透過使用 AWS API 來自動執行回應。
+ 您可以使用 AWS CloudFormation 預先佈建工具和「無塵室」。這樣一來，您就可以在安全、隔離的環境中進行鑑識。
下列問題著重於這些安全方面的考量。
| SEC 10：您如何預估、回應事件以及從事件中復原？ |
| --- |
| 準備對於及時且有效的調查、回應事件以及從事件中復原至關重要，有助於將對組織的干擾降到最低。 |
確認您有一種方法可以快速授予安全團隊存取權限，並自動隔離執行個體以及為鑑識收集資料和狀態。
# 應用程式安全
應用程式安全 (AppSec) 介紹如何為開發工作負載的安全屬性進行設計、建置與測試的整體過程。您應該安排組織成員接受適當訓練，了解您的建置與發佈基礎結構的安全屬性，以及應用自動化來識別出安全問題。
採用應用程式安全測試做為軟體開發生命週期 (SDLC) 與發佈後程序中的常規部分，有助於驗證您可建立一套結構化機制，專門識別、修正應用程式安全問題，以及防止這些問題進入您的生產環境。
您的應用程式開發方法應該在設計、建置與操作工作負載期間納入安全控制。過程當中，可以調整程序，達到持續減少缺陷和最低技術負債。例如，在設計階段中應用威脅建模有助於提早發現設計瑕疵，修正更加簡單，成本節省更多，而不需要等到日後才能進行緩解。
解決瑕疵的成本與複雜性通常比過去在 SDLC 中來得低。最簡單的解決問題方法就是別讓問題發生，因此從使用威脅模型開始，有助於您專注在設計階段的正確成果。隨著 AppSec 計畫逐漸成熟，您可以自動化方式提高測試量，改善意見回饋對建置人員的準確性 (保真度)，同時縮短安全審核所需要的時間。這些動作全都可以改善所建置軟體的品質，並且加快功能進入生產階段。
這些實作準則著重於四個領域：組織與文化、管道*的*安全性、管道*中*的安全性以及相依性管理。每個區域都會提供一組可實作原則，並針對設計、建置與操作工作負載的做法提供端對端檢視。
在 AWS 中，您可以使用許多方法來解決應用程式安全計畫問題。當中有一些方法依賴技術，而其他方法則著重在應用程式安全計畫的人員和組織層面。
下列問題著重於這些應用程式安全方面的考量。
| SEC 11：如何在橫跨應用程式設計、開發和部署的整個生命週期內融入安全屬性並進行驗證？ |
| --- |
| 人員培訓、使用自動化測試、了解相依性，以及驗證工具和應用程式的安全屬性，有助於減少生產工作負載中發生安全問題的機率。 |
# 資源
請參閱以下資源，進一步了解我們的安全最佳實務。
## 文件
+ [AWS 雲端安全](https://aws.amazon.com/security/?ref=wellarchitected-wp)
+ [AWS 合規](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)
+ [AWS 安全部落格](http://blogs.aws.amazon.com/security/?ref=wellarchitected-wp)
+ [AWS 安全成熟度模型](https://maturitymodel.security.aws.dev/en/0.-introduction/)
## 白皮書
+ [安全支柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html?ref=wellarchitected-wp)
+ [AWS 安全概觀](https://d1.awsstatic.com/whitepapers/Security/AWS%20Security%20Whitepaper.pdf?ref=wellarchitected-wp)
+ [AWS 風險與合規](https://d1.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf?ref=wellarchitected-wp)
## 影片
+ [AWS 聯盟的安全狀態](https://youtu.be/Wvyc-VEUOns?ref=wellarchitected-wp)
+ [共同責任概觀](https://www.youtube.com/watch?v=U632-ND7dKQ&ref=wellarchitected-wp)
# 可靠性
可靠性支柱包括工作負載如預期般正確、一致地執行其預期功能的能力。包括在整個生命週期中執行及測試工作負載。本白皮書深入說明在 AWS 上實作可靠工作負載的相關事項，提供最佳實務指引。
可靠性支柱概述了設計原則、最佳實務和相關問題。可以在[可靠性支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)中找到實作指引。
**Topics**
+ [設計原則](rel-dp.md)
+ [定義](rel-def.md)
+ [最佳實務](rel-bp.md)
+ [資源](rel-resources.md)
# 設計原則
雲端可靠性有五個基本的設計原則：
+ **自動從故障中復原**：透過監控工作負載的關鍵績效指標 (KPI)，您可在達到閾值時啟動自動化。這些 KPI 應為業務價值的衡量指標，而非服務營運的技術方面。如此一來，即可自動通知和追蹤失敗，以及自動化可解決或修復失敗的復原程序。藉助更複雜的自動化功能，您可以在發生失敗前進行預測和修補。
+ **測試復原程序：**在內部部署環境中，經常執行測試以證明工作負載可在特定情況下正常工作。測試通常不可用於驗證復原策略。在雲端，您可測試工作負載會發生哪些失敗情境，同時可驗證復原程序。您可使用自動化來模擬不同的失敗情境或重新建立會導致之前失敗的情境。此方法會在實際的失敗情境發生前公開您可以測試和修正的失敗路徑，從而降低風險。
+ **水平擴展，以增加彙總工作負載的可用性：**使用多個小資源取代一個大資源，以降低整體工作負載上發生單一失敗時造成的影響。將請求分散到多個較小的資源，以確認其不會有共同的失敗點。
+ **停止猜測容量：**內部部署工作負載失敗的一個常見原因是資源飽和，即當對工作負載的需求超出該工作負載的容量時發生的情況 (這通常為阻斷服務攻擊的目標)。在雲端，您可以監控需求和工作負載利用率，並自動新增或刪除資源，以保持可滿足需求的更有效水平，而不會過度佈建或佈建不足。仍然存在限制，但是某些配額可以控制，而其他限制則可管理 (請參閱管理服務配額和限制)。
+ **透過自動化管理變更：**應透過自動化來執行對基礎架構的變更。必須管理的變更包括之後可以追蹤和審查的自動化變更。
# 定義
雲端可靠性有四個最佳實務領域︰
+ 基礎
+ 工作負載架構
+ 變更管理
+ 故障管理
若要實現可靠性，您必須先從基礎開始，即服務配額和網路拓撲能適應工作負載的環境。分散式系統的工作負載架構在設計上必須能防止失敗並減輕失敗的影響。工作負載必須處理需求或要求的變更，且在設計上須能偵測失敗並自動進行自我修復。
# 最佳實務
**Topics**
+ [基礎](rel-found.md)
+ [工作負載架構](rel-workload-arch.md)
+ [變更管理](rel-chg-mgmt.md)
+ [故障管理](rel-failmgmt.md)
# 基礎
基礎要求是其範圍超過單一工作負載或專案的要求。在建立任何系統架構之前，應確立會影響可靠性的基本要求。例如，您必須為資料中心提供足夠的網路頻寬。
藉助 AWS，這些基礎需求中的大多數已予以納入或可以按需要進行處理。設計的雲端近乎無限，因此 AWS 有責任滿足足夠的聯網和運算容量的要求，允許您根據需要自由變更資源大小和分配。
下列問題著重於可靠性方面的這些考量。(如需可靠性問題清單和最佳實務，請參閱[附錄](a-reliability.md))。
| REL 1：您如何管理服務配額和限制？ |
| --- |
| 雲端型工作負載架構具有服務配額 (也稱為服務限制)。這些配額的存在是為了防止意外佈建超出所需數量的資源，並限制 API 操作的請求率，以保護服務免於遭到濫用。另外還有一些資源限制，例如可將位元下推到光纖纜線的速率，或實體磁碟的儲存量。 |
| REL 2：如何規劃您的網路拓撲？ |
| --- |
| 工作負載通常存在於多個環境中。其中包括多個雲端環境 (可公開存取與私有)，也可能包含您現有的資料中心基礎設施。這些計畫必須包含網路考量事項，例如系統內部與系統間連線能力、公有 IP 位址管理、私有 IP 位址管理以及網域名稱解析。 |
# 工作負載架構
可靠的工作負載始於對軟體和基礎設施的前期設計決策。您的架構選擇會對所有 Well-Architected 支柱的工作負載行為產生影響。為求可靠性，您必須依循特定模式。
藉助 AWS，工作負載開發人員可以選擇要使用的語言和技術。AWSSDK 透過為 AWS 服務提供特定語言 API，讓編碼不再如此複雜。這些開發套件加上各種語言選項，允許開發人員實作本文列出的可靠性最佳實務。開發人員也可在 [Amazon 建置者資料中心](https://aws.amazon.com/builders-library/?ref=wellarchitected-wp)中閱讀並學習 Amazon 如何構建和操作軟體。
下列問題著重於可靠性方面的這些考量。
| REL 3：如何設計您的工作負載服務架構？ |
| --- |
| 使用服務導向架構 (SOA) 或微型服務架構，建置擴展性與可靠性高的工作負載。服務導向架構 (SOA) 是透過服務界面讓軟體元件可重複使用的做法。微型服務架構則進一步讓元件變得更小、更簡單。 |
| REL 4：如何在分散式系統中設計防止失敗的互動？ |
| --- |
| 分散式系統仰賴通訊網路將伺服器或服務等元件互相連線。儘管這些網路中出現資料遺失或延遲，但工作負載仍必須可靠地運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。這些最佳實務可防止故障，並改善平均故障間隔時間 (MTBF)。 |
| REL 5：如何設計分散式系統中的互動以緩解或承受故障？ |
| --- |
| 分散式系統倚賴通訊網路來互連元件 (例如，伺服器或服務)。即使這些網路上的資料遺失或延遲，您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。這些最佳實務讓工作負載能夠承受壓力或故障，更快速地從其中復原，並減輕這類受損的影響。最終縮短平均復原時間 (MTTR)。 |
# 變更管理
必須預期並因應工作負載或其環境的變更，才能實現可靠的工作負載操作。變更包括對工作負載強加的變更，例如需求峰值，以及內部的變更，例如功能部署和安全性修補程式。
您可以使用 AWS 監控工作負載的行為，並自動化對 KPI 的回應。例如，隨著工作負載的使用者增加，您的工作負載可能會新增其他伺服器。您可以控制有權作出工作負載變更的人員，並稽核這些變更的歷史紀錄。
下列問題著重於可靠性方面的這些考量。
| REL 6：如何監控工作負載資源？ |
| --- |
| 日誌和指標是可深入洞察工作負載運作狀態的強大工具。您可以設定工作負載以監控日誌和指標，並在超過閾值或發生重大事件時傳送通知。監控可讓您的工作負載識別何時會超過低效能閾值或發生故障，以便自動復原來回應。 |
| REL 7：如何設計工作負載以適應需求變更？ |
| --- |
| 可擴展的工作負載提供可自動新增或移除資源的彈性，讓資源能夠在任何特定時間點充分滿足目前的需求。 |
| REL 8：您如何實作變更？ |
| --- |
| 變更須在受控的情況下，才能部署新功能，並確認工作負載和運作環境執行已知的軟體，且能夠以可預測的方式修補或取代。如果這些變更不受控制，那麼就很難預測這些變更的影響，也很難解決由於這些變更而產生的問題。 |
當您建立工作負載架構以根據需求的變更自動新增和刪除資源時，其不僅可以提高可靠性，而且還能驗證企業成功不會成為負擔。在適當監控下，當 KPI 偏離預期規範時，您的團隊將會自動收到提醒。自動日誌記錄對環境的變更，允許您進行稽核並快速識別可能影響可靠性的動作。對變更管理的控制將確保您能執行交付所需可靠性的規則。
# 故障管理
在任何合理複雜的系統中，均有可能會發生失敗。為達可靠性要求，您的工作負載應在發生失敗時察覺此情況，並採取行動以免影響可用性。工作負載必須能夠承受失敗並自動修復問題。
藉助 AWS，您可以利用自動化對監控資料作出反應。例如，當特定指標超過閾值時，您可以啟動可修補問題的自動化動作。此外，您無需嘗試診斷和修正生產環境中的失敗資源，而是可以用新的資源取代它，並對失敗的頻外資源執行分析。由於雲端可讓您以低成本建立整個系統的臨時版本，因此您可以使用自動化測試來驗證完整的復原程序。
下列問題著重於可靠性方面的這些考量。
| REL 9：您如何備份資料？ |
| --- |
| 備份資料、應用程式和組態以满足您對復原時間點目標 (RTO) 和復原點目標 (RPO) 的要求。 |
| REL 10：如何使用故障隔離來保護您的工作負載？ |
| --- |
| 故障隔離會將元件或系統故障的影響侷限在定義的界限內。藉由適當的隔離，界限外部的元件就不會受到故障影響。只要能跨多個故障隔離界限執行工作負載，就可更靈活地應對故障。 |
| REL 11：如何設計工作負載以承受元件失敗？ |
| --- |
| 須架構具高可用性和低平均復原時間 (MTTR) 需求的工作負載以實現彈性。 |
| REL 12：如何測試可靠性？ |
| --- |
| 在將工作負載設計為可彈性應對生產壓力之後，進行測試是確認其依設計運作並提供預期之彈性的唯一方法。 |
| REL 13：您如何規劃災難復原 (DR)？ |
| --- |
| 備妥備份和冗餘工作負載元件是 DR 策略的開始。[RTO 和 RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 是您還原工作負載的目標。根據業務需求設定這些目標。實作策略以滿足這些目標，考量工作負載資源和資料的位置和功能。發生中斷的可能性和復原成本也是重要因素，可反映為工作負載提供災難復原的商業價值。 |
定期備份資料並測試備份檔案，從而確認您可以從邏輯和實際錯誤復原。管理失敗的關鍵是對導致失敗的工作負載頻繁進行自動化測試，然後觀察其可如何復原。定期執行此操作，並確認在出現重大工作負載變更後也能啟動此類測試。主動追蹤 KPI、復原時間點目標 (RTO) 和復原點目標 (RPO)，以評估工作負載的彈性 (尤其是在失敗測試情境下)。追蹤 KPI 將能助您識別和減輕單一失敗點。其目標是徹底測試您的工作負載復原程序，以便您確信即使面對持續問題，您也可以復原所有資料並繼續為客戶提供服務。應與執行正常生產程序一樣執行復原程序。
# 資源
請參閱以下資源，進一步了解我們的可靠性最佳實務。
## 文件
+ [AWS 文件](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp)
+ [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure?ref=wellarchitected-wp)
+ [AWS Auto Scaling：擴展計畫的運作方式](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html?ref=wellarchitected-wp)
+ [什麼是 AWS Backup？](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html?ref=wellarchitected-wp)
## 白皮書
+ [可靠性支柱：AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html?ref=wellarchitected-wp)
+ [實作 AWS 上的微型服務](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html?ref=wellarchitected-wp)
# 效能效率
效能效率支柱包括能夠有效率地使用雲端資源，以滿足效能需求，並隨著需求變更與技術發展來保持該效率需求。
效能達成效率支柱概述了設計原則、最佳實務和相關問題。可以在[效能達成效率支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)中找到實作指引。
**Topics**
+ [設計原則](perf-dp.md)
+ [定義](perf-def.md)
+ [最佳實務](perf-bp.md)
+ [資源](perf-resources.md)
# 設計原則
雲端有五個設計原則來維持效能達成效率：
+ **讓進階技術變得更普及：**將複雜的任務委派給雲端廠商，讓團隊更順暢地實作進階技術。與其要求 IT 團隊了解新技術的託管和執行方式，不如考慮使用技術即服務。例如，沒有任何SQL資料庫、媒體轉碼和機器學習都是需要專業知識的技術。在雲端，這些技術成為團隊可以使用的服務，讓團隊能夠專注於產品開發，而非資源佈建及管理。
+ **幾分鐘內即可全球化：**在全球多個 AWS 區域中部署工作負載可讓您以最低成本為客戶提供更低的延遲和更好的體驗。
+ **使用無伺服器架構**：採用無伺服器架構，您便無需執行和維護實體伺服器來完成傳統運算活動。例如，無伺服器儲存服務可以充當靜態網站 (因此無需 Web 伺服器)，而事件服務可以為您託管程式碼。如此一來，即可減輕管理實體伺服器的營運負擔，而且由於這些受管服務是在雲端規模上運行，因此還可以降低交易成本。
+ **提高試驗頻率**：使用虛擬及可自動化的資源，您可以使用不同類型的執行個體、儲存設備或組態，迅速完成比較測試。
+ **考慮機械同感**：了解雲端服務的使用方式，並一律使用符合工作負載目標的技術方法。例如，在您選擇資料庫或儲存方法時，請考慮資料存取模式。
# 定義
維持雲端效能達成效率的最佳實務有五個領域：
+ **架構選取**
+ **運算與硬體**
+ **資料管理**
+ **聯網與內容交付**
+ **程序和文化**
採取資料驅動的方法來建置高效能架構。從高階設計到選取和設定資源類型，收集架構各方面的資料。
定期檢閱您的選擇可驗證您是否利用不斷發展的 AWS 雲端。監控可確保您能察覺預期效能發生的任何偏差情形。在架構中做出權衡以改進效能，例如使用壓縮或快取，或放寬一致性要求。
# 最佳實務
**Topics**
+ [架構選擇](perf-arch.md)
+ [運算與硬體](perf-compute.md)
+ [資料管理](perf-data.md)
+ [聯網與內容交付](perf-networking.md)
+ [程序和文化](perf-process.md)
# 架構選擇
適用於特定工作負載的最佳解決方案各不相同，而解決方案通常會結合多種方法。Well-Architected 工作負載會使用多種解決方案，並採用不同的功能以提升效能。
AWS 資源提供多種類型和組態，讓您更輕鬆地找到最符合您需求的方法。您還可以發現使用內部部署基礎設施不易實現的選項。例如，諸如 Amazon DynamoDB 的受管服務提供完全受管的無SQL資料庫，在任何規模下都具有單位數毫秒延遲。
下列問題著重於效能達成效率方面的這些考量。(如需效能達成效率問題和最佳實務的清單，請參閱[附錄](a-performance-efficiency.md)。)
| PERF 1：如何為工作負載選取適當的雲端資源和架構模式？ |
| --- |
| 欲讓工作負載達到更有效的效能通常需要採用多種方法。Well-Architected 系統會使用多重解決方案和功能以提升效能。 |
# 運算與硬體
特定工作負載的最佳運算選擇會根據應用程式設計、使用模式和組態設定而有所不同。架構會針對不同元件使用不同運算選擇，並採用不同功能以提升效能。若選錯運算資源，可能使架構的效能達成效率降低。
在 中 AWS，運算有三種形式：執行個體、容器和函數：
+ **執行個體**是虛擬化伺服器，可讓您使用按鈕或API呼叫來變更其功能。由於在雲端中，資源決策不是固定的，您可以使用不同的伺服器類型進行試驗。在 AWS中，這些虛擬伺服器執行個體具有不同的系列和大小，且提供廣泛的功能，包括固態硬碟 （SSDs） 和圖形處理單元 （）GPUs。
+ **容器**是一種作業系統虛擬化方法，可讓您在資源隔離的程序中執行應用程式及其相依性。如果您需要控制運算環境的安裝、組態和管理，EC2則可以使用容器或 Amazon 的無 AWS Fargate 伺服器運算。您也可以從多個容器協調平台中選擇：Amazon Elastic Container Service （ECS） 或 Amazon Elastic Kubernetes Service （EKS）。
+ **函數**則從您想套用的程式碼中將執行環境抽象化。例如， AWS Lambda 允許您在不執行執行個體的情況下執行程式碼。
下列問題著重於效能達成效率方面的這些考量。
| PERF 2：如何在工作負載中選取和使用運算資源？ |
| --- |
| 工作負載的更高效解決方案會根據應用程式設計、使用模式和組態設定而有所不同。架構可針對不同元件使用不同運算解決方案並開啟不同功能，以提升效能。為架構選錯運算解決方案，可能使效能達成效率降低。 |
# 資料管理
特定系統的最佳資料管理解決方案會根據資料類型 （區塊、檔案或物件）、存取模式 （隨機或循序）、必要的輸送量、存取頻率 （線上、離線、封存）、更新頻率 （WORM、動態），以及可用性和耐久性限制而有所不同。Well-Architected 工作負載會使用專用資料存放區，這些存放區採用不同的功能以提升效能。
在 中 AWS，儲存有三種形式：物件、區塊和檔案：
+ **物件儲存**提供可擴展且耐用的平台，以利從任何網際網路位置存取資料，例如使用者產生的內容、作用中存檔、無伺服器運算、大數據儲存或備份與復原。Amazon Simple Storage Service (Amazon S3) 是一項物件儲存服務，提供領先業界的可擴展性、資料可用性、安全性和效能。Amazon S3 旨在提供 99.999999999% 的耐久性，並為全球公司存放數百萬個應用程式的資料。
+ **區塊式儲存**為每個虛擬主機提供高可用性、一致、低延遲的區塊式儲存，類似於直接連接的儲存 （DAS） 或儲存區域網路 （）SAN。Amazon Elastic Block Store （Amazon EBS） 專為需要EC2執行個體可存取持久性儲存的工作負載而設計，可協助您調整具有適當儲存容量、效能和成本的應用程式。
+ **檔案儲存**可讓您跨多個系統存取共用檔案系統。Amazon Elastic File System （Amazon EFS） 等檔案儲存解決方案非常適合使用案例，例如大型內容儲存庫、開發環境、媒體存放區或使用者主目錄。Amazon FSx讓啟動和執行熱門檔案系統更有效率且符合成本效益，因此您可以利用廣泛使用的開放原始碼和商業授權檔案系統的豐富功能集和快速效能。
下列問題著重於效能達成效率方面的這些考量。
| PERF 3：如何在工作負載中儲存、管理和存取資料？ |
| --- |
| 系統更有效率的儲存解決方案會根據存取操作類型 （區塊、檔案或物件）、存取模式 （隨機或循序）、必要的輸送量、存取頻率 （線上、離線、封存）、更新頻率 （WORM、動態），以及可用性和耐久性限制而有所不同。Well-Architected 系統使用多重儲存解決方案，並開啟不同功能以提升效能並有效使用資源。 |
# 聯網與內容交付
工作負載的最佳聯網解決方案會根據延遲、輸送量需求、抖動和頻寬而有所不同。實體限制 (例如使用者或內部部署資源) 會決定位置選項。這些限制可能隨著邊緣節點或資源位置而有所差異。
在 上 AWS，聯網是虛擬化的，並提供多種不同的類型和組態。這可讓您更輕鬆地符合聯網需求。 AWS 提供產品功能 （例如增強型網路、Amazon EC2 網路最佳化執行個體、Amazon S3 傳輸加速和動態 Amazon CloudFront） 來最佳化網路流量。 AWS 也提供聯網功能 （例如 Amazon Route 53 延遲路由、Amazon VPC端點 AWS Direct Connect和 AWS Global Accelerator），以減少網路距離或抖動。
下列問題著重於效能達成效率方面的這些考量。
| PERF 4：如何在工作負載中選取和設定聯網資源？ |
| --- |
| 此問題包括在雲端中設計、設定和操作高效聯網和內容交付解決方案的指引和最佳實務。 |
# 程序和文化
在架構工作負載時，您可以採取一些原則和實務來協助您更有效率地執行高效能雲端工作負載。為了培養高效能雲端工作負載的文化，請考慮下列重要原則和實務。
打造這類文化時，請考慮以下重要原則：
+ **基礎設施為程式碼：**使用 AWS CloudFormation 範本等方法將基礎設施定義為程式碼。使用範本可讓您將基礎設施與應用程式程式碼和組態一起置於原始檔控制中。這可讓您在基礎設施中套用開發軟體時所使用的相同做法，進而快速進行迭代。
+ **部署管道：**使用持續整合/持續部署 (CI/CD) 管道 (例如，原始程式碼儲存庫、建置系統、部署和測試自動化) 來部署您的基礎架構。這樣您就可以在反覆執行的過程中，採用可重複、一致且低成本的方式進行部署。
+ **定義明確的指標：**設定和監控指標，以擷取關鍵績效指標 （KPIs）。我們建議您同時使用技術和業務指標。對於網站或行動應用程式，關鍵指標正在擷取 time-to-first-byte或轉譯。其他一般適用的指標包括執行緒計數、垃圾回收率和等待狀態。業務指標 (例如每個請求的彙總累計成本) 會提示您降低成本的方法。仔細考慮您計劃如何解釋指標。例如，您可以選擇最大值或第 99 個百分位數，而非平均值。
+ **自動執行效能測試：**在部署程序中，在成功通過快速執行測試之後，會自動啟動效能測試。自動化應建立一個新的環境，設定如測試資料之類的初始條件，然後執行一系列基準測試和負載測試。這些測試的結果應與組建版本綁定，方便您追蹤長時間的效能變化。對於長期執行的測試，您可以讓管道的這個部分與組建版本的其餘部分不同步。或者，您可以使用 Amazon EC2 Spot 執行個體在夜間執行效能測試。
+ **負載產生：**您應建立一系列的測試指令碼來複寫綜合性或預錄的使用者旅程。這些指令碼應該是冪等及非耦合的形式，而且您可能需要納入*預熱型*指令碼才能產生有效的結果。您的測試指令碼應盡可能地複寫生產環境中的使用行為。您可以使用軟體或 software-as-a-service （SaaS ） 解決方案來產生負載。可以考慮使用 [AWS Marketplace](https://aws.amazon.com/marketplace/) 解決方案和 [Spot 執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) — 這些可能是經濟實惠的負載產生方式。
+ **效能可見度：**關鍵指標應對您的團隊可見，尤其是針對每個組建版本的指標。這可讓您查看隨時間變化出現的任何顯著的正面或負面趨勢。您也應顯示錯誤或例外狀況數量的指標，以確保您測試的是可運作的系統。
+ **視覺化：**使用視覺化技術可以清楚指出何處出現效能問題、熱點、等待狀態或較低的利用率。在架構圖上重疊效能指標 — 呼叫圖表或程式碼有助於快速識別問題。
+ **定期審查程序：**架構效能不佳通常是效能審查程序不存在或中斷的結果。如果您的架構效能不佳，則實作效能審查程序可讓您不斷反覆進行改善。
+ **持續優化：**培養文化以持續優化雲端工作負載效能達成效率。
下列問題著重於效能達成效率方面的這些考量。
| PERF 5：您使用什麼程序來支援工作負載的更多效能效率？ |
| --- |
| 在架構工作負載時，您可以採取一些原則和實務來協助您更有效率地執行高效能雲端工作負載。為了培養高效能雲端工作負載的文化，請考慮下列重要原則和實務。 |
# 資源
請參閱以下資源，進一步了解我們的效能達成效率最佳實務。
## 文件
+ [Amazon S3 效能最佳化](https://docs.aws.amazon.com/AmazonS3/latest/dev/PerformanceOptimization.html?ref=wellarchitected-wp)
+ [Amazon EBS磁碟區效能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html?ref=wellarchitected-wp)
## 白皮書
+ [效能達成效率支柱](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html?ref=wellarchitected-wp)
## 影片
+ [AWS re：Invent 2019：Amazon EC2基礎 （CMP211-R2）](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected-wp)
+ [AWS re：Invent 2019：領導工作階段：工會的儲存狀態 STG2（01-L）](https://www.youtube.com/watch?v=39vAsGi6eEI&ref=wellarchitected-wp)
+ [AWS re：Invent 2019：領導工作階段： AWS 用途建置的資料庫 DAT2（09-L）](https://www.youtube.com/watch?v=q81TVuV5u28&ref=wellarchitected-wp)
+ [AWS re：Invent 2019：與 AWS 混合 AWS 網路架構的連線能力 （NET317-R1）](https://www.youtube.com/watch?v=eqW6CPb58gs&ref=wellarchitected-wp)
+ [AWS re：Invent 2019：推動新一代 AmazonEC2：深入探索 Nitro 系統 （CMP303-R2）](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected-wp)
+ [AWS re：Invent 2019：擴展到前 1，000 萬使用者 （ARC211-R）](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected-wp)
# 成本最佳化
成本最佳化支柱包括以最低價格執行系統來產生商業價值的能力。
成本最佳化支柱概述了設計原則、最佳實務和相關問題。您可以在[成本最佳化支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)中找到有關實作的規定性指引。
**Topics**
+ [設計原則](cost-dp.md)
+ [定義](cost-def.md)
+ [最佳實務](cost-bp.md)
+ [資源](cost-resources.md)
# 設計原則
雲端成本最佳化有五個設計原則：
+ **實作雲端財務管理：**為了達成財務成功並加速在雲端實現商業價值，請投資雲端財務管理和成本最佳化。您的組織應投入時間和資源，在這個新的技術與使用管理領域中打造能力。與安全或卓越營運能力類似，您需要透過知識累積、計畫、資源和程序打造能力，以成為具成本效率的組織。
+ **採用消費模式**：僅為您需要的運算資源付費，依照業務要求增減用量，不必倚賴複雜的預測。例如，開發與測試環境通常僅於一週工作日的一天八小時當中使用。您可在不使用這些資源時加以停止，有潛力可節省 75% 成本 (40 小時相對於 168 小時)。
+ **衡量整體效率**：測量工作負載的商業輸出和遞送的相關成本。以此測量值可得知您從增加輸出與降低成本獲取的增益。
+ **停止將金錢花在差異不大的繁重工作上：**AWS 會處理資料中心營運的繁重工作，例如架設伺服器。通過受管服務，它也免除了管理作業系統和應用程式這些營運負擔。這可讓您專注於客戶和業務專案，而非 IT 基礎設施。
+ **分析和歸因支出**：雲端可讓您輕鬆準確識別系統的用量和成本，繼而允許將 IT 成本透明化地歸因至個別工作負載擁有者。如此有助於測量投資報酬率 (ROI)，並且讓工作負載擁有者有機會優化資源和降低成本。
# 定義
雲端成本最佳化的最佳實務有五個方面：
+ **實作雲端財務管理**
+ **支出和用量感知**
+ **具有經濟效益的資源**
+ **管理需求與供應資源**
+ **隨時間最佳化**
如同 Well-Architected 架構內的其他支柱，有權衡事項需要考量，例如，該針對上市速度還是成本進行最佳化。在某些情況下，更有效的方式是針對速度來最佳化，例如快速上市、推出新功能，或滿足截止日期，而不是投資預付成本最佳化。設計決策有時會因倉促而不是資料來引導，因為總是會有「以防萬一」過度補償的趨向，而不是花時間為最經濟實惠的部署做基準化分析測試。這恐怕會導致過度佈建和最佳化不足的部署。不過，若必須將內部部署環境內的資源「平移」至雲端，然後再實施最佳化，這是理性的選擇。前期對成本最佳化策略進行適當投資，並達成一致奉行最佳實務，避免不必要的過度佈建，可讓您更穩當地體現雲端的經濟效益。以下各節提供初始和持續實作工作負載雲端財務管理和成本最佳化的技術和最佳實務。
# 最佳實務
**Topics**
+ [實作雲端財務管理](cost-cfm.md)
+ [了解支出和用量](cost-aware.md)
+ [具有經濟效益的資源](cost-cereso.md)
+ [管理需求與供應資源](cost-mandem.md)
+ [隨時間優化](cost-opti.md)
# 實作雲端財務管理
採用雲端之後，技術團隊因核准、採購和基礎設施部署週期縮短而加快創新速度。實現商業價值和財務成功需要新的雲端財務管理方法。此方法為雲端財務管理，透過在整個組織實作知識建置、計畫、資源和程序，打造整個組織的能力。
許多組織是由許多不同的單位組成，每個單位都具有不同的優先事項。以下能力將協助建立更高效的組織：讓您的組織與一系列約定的財務目標保持一致，並為組織提供達成這些目標所需的機制。有能力的組織將更快速地創新和建立，且面對任何內部或外部因素時更靈活、適應性更強。
在 AWS 中，您可以使用 Cost Explorer、Amazon Athena (選用)、搭配成本和用量報告 (CUR) 的 Amazon QuickSight，在整個組織中提供成本和用量感知。AWSBudgets 可針對成本和用量提供主動通知。AWS 部落格提供新服務和功能的相關資訊，可確認您能夠隨時掌握最新的服務版本。
下列問題著重於成本最佳化方面的這些考量。(如需成本最佳化問題清單和最佳實務的清單，請參閱[附錄](a-cost-optimization.md)。)
| COST 1：如何實作雲端財務管理？ |
| --- |
| 透過實作雲端財務管理，就可幫助組織最佳化成本和用量，並且在 AWS 上進行規模調整，進而實現商業價值和財務上的成功。 |
建立成本最佳化職能部門時，使用團隊成員，並在團隊中增加 CFM 和成本最佳化方面的專家。現有的團隊成員將會了解組織目前的運作方式，以及如何快速實作改善。同時也考慮納入具有輔助或專業技能集的人員，例如分析和專案管理方面的人員。
在組織中實作成本感知時，改善現有的計畫和程序或在此基礎是上進行建置。在現有的程序和計畫中新增內容會比建立新的程序和計畫快得多。這會更快實現結果。
# 了解支出和用量
雲端提供的增強彈性和敏捷性，可促進創新和快節奏開發和部署。它減少了與佈建內部部署基礎設施相關的手動程序和時間，包括識別硬體規格、協商價格報價、管理採購訂單、安排裝運以及部署資源。然而，欲享有易用性和幾乎無限制的隨需容量，對於支柱需要換上新思維。
許多企業是以各種團隊執行多個系統之下所組成。能將資源成本歸因至個別組織或產品擁有者，能帶動高效使用的行為模式，有助於減少浪費。準確的成本歸因可讓您知道哪些產品具有真正的獲利能力，並就預算分配做出更明智的決策。
在 AWS 中，您可以使用 AWS Organizations 或 AWS Control Tower 來建立帳戶結構，如此可實現區隔並協助您分配成本和用量。您也可以對資源使用標記，利用商業和組織資訊確定用量和成本情況。使用 AWS Cost Explorer 查看您的成本和用量，或使用 Amazon Athena 和 Amazon QuickSight 建立自訂儀表板和分析。透過 AWS Budgets 的通知，以及使用 AWS Identity and Access Management (IAM) 和 Service Quotas 的控制，來控制成本和用量。
下列問題著重於成本最佳化方面的這些考量。
| COST 2：您如何管控用量？ |
| --- |
| 制訂政策和機制以驗證產生合理的成本，同時達成目標。您可以運用相互制衡的方法，在不超支的情況下進行創新。 |
| COST 3：您如何監控用量和成本？ |
| --- |
| 制訂政策和程序以監控並適當分配成本。這樣能夠讓您衡量並改善此工作負載的成本效益。 |
| COST 4：如何進行資源除役？ |
| --- |
| 從啟動到結束專案期間，控制變更並管理資源。這有助於關閉未使用的資源，以減少浪費。 |
您可以使用成本分配標籤為 AWS 用量和成本進行分類和追蹤。當您對 AWS 資源 (例如 EC2 執行個體或 S3 儲存貯體) 加上標籤時，AWS 就能以您的用量和標籤產生成本和使用報告。您可加上代表組織類別 (例如成本中心、工作負載名稱或擁有者) 的標籤，以便跨多項服務安排成本。
確認您在成本與用量報告和監控中使用正確的詳細資訊和精細度層級。如需高層級的洞察和趨勢，請透過 AWS Cost Explorer 使用每日精細度。如需更深入的分析和檢查，請使用 AWS Cost Explorer 中的每小時精細度，或 Amazon Athena 和搭配成本和用量報告 (CUR) 的 Amazon Quick 中的每小時精細度。
將加有標籤的資源結合實體生命週期追蹤 (員工、專案)，可識別不再為組織產生價值且應當除役的孤立資源或專案。您可以設定帳單提醒，通知您預測的超支。
# 具有經濟效益的資源
為您的工作負載使用適當的執行個體和資源，是節約成本的關鍵。例如，假設報告程序在較小的伺服器上執行時要花五小時，但在兩倍昂貴的較大伺服器上執行只需一小時。這兩種伺服器產出的結果相同，但較小的伺服器經過一段時間會形成較高成本。
架構完善的工作負載會用最具成本效益的資源，帶來明顯正面的經濟影響。您並有機會可利用受管服務來降低成本。例如，與其維護伺服器以遞送電子郵件，可使用以訊息為單位收費的服務。
AWS 備有各種具有彈性且經濟的定價選項，讓您以更有效地符合需要的方式獲取 Amazon EC2 和其他服務的執行個體。*隨需**執行個體*可讓您按時數為運算容量付費，無最低承諾的要求。*Savings Plans 和預留執行個體*可提供高達 75% 的隨需定價折扣。使用 Spot 執行個體，您可善用未用的 Amazon EC2 容量，與隨需定價相較可節省高達 90% 的成本。*Spot 執行個體*適合用在系統能耐受使用伺服器機群之處，其中個別伺服器能動態性地來去，例如無狀態 Web 伺服器、批次處理，或使用 HPC 和大數據時。
選擇適當的服務也能降低用量和成本；例如 CloudFront 能將資料傳輸降至最低或降低成本，例如在 Amazon RDS 上利用 Amazon Aurora 免於昂貴的資料庫授權成本。
下列問題著重於成本最佳化方面的這些考量。
| COST 5：您選取服務時如何評估成本？ |
| --- |
| Amazon EC2、Amazon EBS 和 Amazon S3 是基礎的 AWS 服務。Amazon RDS 和 Amazon DynamoDB 等受管服務為更高等級或應用程式等級的 AWS 服務。選取適當的基礎和受管服務，就可最佳化此工作負載的成本。舉例來說，您可以使用受管服務減少或省下大部分管理和營運開銷，讓您從事應用程式或企業相關活動。 |
| COST 6：您選取資源類型、大小和數量時，如何達成成本目標？ |
| --- |
| 確認您為手邊的任務選取適當的資源大小和數量。選取最具成本效益的類型、大小和數量，就能盡量減少浪費。 |
| COST 7：您如何使用定價模式降低成本？ |
| --- |
| 使用最適合您資源的定價模式，就能盡量減少支出。 |
| COST 8：您如何規劃資料傳輸費？ |
| --- |
| 確實規劃和監控資料傳輸費，以便做出盡量減少成本的架構決策。小規模而有效的架構變更能夠隨時間大幅減少營運成本。 |
透過在選擇服務時考慮成本因素，並以 Cost Explorer 和 AWS Trusted Advisor 等工具定期審查 AWS 的使用情形，您可積極監測使用率，並隨之調整部署。
# 管理需求與供應資源
待您移至雲端後，即可僅為所需付費。您可以在需要時供應資源以符合工作負載需求，減少因過度佈建付出高昂成本和造成浪費。您也可以使用調節、緩衝區或佇列來修改需求，以讓需求變得平緩，並以較少的資源來滿足需求，從而降低成本，或稍後使用批次服務來處理。
在 AWS 中，您可自動佈建資源以符合工作負載需求。Auto Scaling 使用基於需求或時間的方法，可讓您視需要新增和移除資源。若您能預期需求變更，則可省下更多成本，並驗證資源符合工作負載需求。您可以使用 Amazon API Gateway 實作限流，或使用 Amazon SQS 在工作負載中實作佇列。這兩者都可讓您修改工作負載元件的需求。
下列問題著重於成本最佳化方面的這些考量。
| COST 9：如何管理需求和供應資源？ |
| --- |
| 針對支出和效能達到平衡的工作負載，確認您購買的每一個項目都用到，並避免極少使用執行個體。往任一端傾斜的使用指標，對您組織在營運成本 (因過度使用而降低效能) 或浪費的 AWS 花費 (因過度佈建) 方面會造成負面影響。 |
在設計修改需求與供給資源時，請主動思考用量模式、佈建新資源所需的時間，以及需求模式的可預測性。管理需求時，確認您的佇列或緩衝區大小正確，而且在所需的時間內回應工作負載需求。
# 隨時間優化
隨著 AWS 推出新服務和功能，最佳實務是檢視現有架構決策，以確認其持續發揮最大成本效益。隨著您的要求變更，請主動將不再需要的資源、整項服務和系統加以除役。
透過實作新功能或資源類型可逐步最佳化工作負載，同時盡量減少實作變更所需的工作量。這可隨著時間持續提高效率，並讓您持續使用最新的技術來降低營運成本。您也可以使用新的服務來取代工作負載中的元件，或將新元件新增至工作負載中。這可以大幅提高效率，因此定期審核工作負載並實作新服務和功能至關重要。
下列問題著重於成本最佳化方面的這些考量。
| COST 10：您如何評估新服務？ |
| --- |
| 隨著 AWS 推出新服務和功能，最佳實務是檢視現有架構決策，以確認其持續發揮最大成本效益。 |
在定期審查您的部署時，請評估較新的服務能如何為您節省成本。例如，Amazon RDS 上的 Amazon Aurora 能降低關聯式資料庫的成本。使用 Lambda 等無伺服器函數時，無需操作和管理執行個體來執行程式碼。
| COST 11：如何評估工作的成本？ |
| --- |
| 評估雲端維運的工作成本，審核耗時的雲端維運，並透過採用相關 AWS 服務、第三方產品或自訂工具將其自動化，以減少人力和成本。 |
# 資源
請參閱以下資源，進一步了解我們成本最佳化的最佳實務。
## 文件
+ [AWS 文件](https://docs.aws.amazon.com/index.html?ref=wellarchitected-wp)
## 白皮書
+ [成本最佳化支柱](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html?ref=wellarchitected-wp)
# 永續性
永續性支柱的重點在於環境影響，尤其是能源消耗和效率，因為這方面是架構師採取直接行動來減少資源使用的重要手段。可以在[永續性支柱白皮書](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)中找到實作指引。
**Topics**
+ [設計原則](sus-design-principles.md)
+ [定義](sus-def.md)
+ [最佳實務](sus-bp.md)
+ [資源](sus-resources.md)
# 設計原則
在雲端中實現永續性有六個設計原則：
+ **了解您的影響：**衡量您雲端工作負載的影響，並建立工作負載未來影響的模型。包含所有影響來源，包括客戶使用您產品所產生的影響，以及產品最後除役和淘汰所產生的影響。審視每個工作單元所需的資源和排放量，將生產輸出與雲端工作負載的總體影響進行比較。使用此資料來建立關鍵績效指標 （KPIs）、評估提高生產力同時降低影響的方法，以及估算提議變更隨著時間的影響。
+ **建立永續性目標：**對於每個雲端工作負載，建立長期永續性目標，例如減少每項交易所需的運算和儲存資源。針對改進現有工作負載永續性的投資回報建立模型，並為業主提供必須投資於永續性目標所需的資源。針對成長著手規劃，以及建構您的工作負載，讓成長導致的每個使用者或每項交易 (根據適當的單位測量) 影響強度降低。這些目標有助於支持貴企業或組織更廣泛的永續性發展目標、識別迴歸，以及排定潛在改進領域的優先順序。
+ **最大化使用率：**調整合適的工作負載規模並實作高效率設計，以確認高使用率，並將底層硬體的能源效率發揮到最大。由於每部主機會有基準耗電量，因此兩部以 30% 使用率執行的主機效率，會低於一部以 60% 執行的主機效率。在此同時減少或最小化閒置資源、處理和儲存，以減少為工作負載供電所需的能源總量。
+ **預測並採用新的、更有效率的軟硬體產品：**支援合作夥伴和供應商進行上游改進，以協助您減少雲端工作負載的影響。持續監控和評估更有效率的新軟硬體產品。針對靈活性進行設計，以允許快速採用高效率的新技術。
+ **使用受管服務：**在廣泛的客戶群中共用服務，有助於最大化資源利用，進而減少支援雲端工作負載所需的基礎設施數量。例如，客戶可以將工作負載遷移至 AWS 雲端 並採用受管服務，例如 AWS Fargate for serverless Container，其中 會大規模 AWS 運作，並負責其高效操作，以共享電力和聯網等常見資料中心元件的影響。使用 受管服務，有助於將影響降至最低，例如使用 Amazon S3 生命週期組態或 Amazon EC2 Auto Scaling 自動將不常存取的資料移至冷儲存，以調整容量以符合需求。
+ **減少雲端工作負載的下游影響：**減少使用您的服務所需的能源或資源量。減少客戶為了使用您的服務而升級裝置的需求。使用 Device Farm 進行測試以了解預期影響，並與客戶進行測試以了解使用您服務的實際影響。
# 定義
雲端永續性有六個最佳實務領域︰
+ 區域選擇
+ 因應需求
+ 軟體和架構
+ 資料
+ 硬體和服務
+ 程序和文化
雲端中的永續性是一項近乎持續的工作，主要專注於透過從佈建的資源中實現最大效益並最大限度地減少所需的總資源，來減少工作負載所有元件的節能和效率。此工作的範圍包括最初選擇高效的程式設計語言、採用現代演算法、使用高效的資料儲存技術、部署至正確大小和高效的運算基礎設施，以及最大限度地減少對高效能最終使用者硬體的要求。
# 最佳實務
**Topics**
+ [區域選擇](sus-region-selection.md)
+ [因應需求](sus-user-behavior-patterns.md)
+ [軟體和架構](sus-software-architecture-patterns.md)
+ [資料管理](sus-data-patterns.md)
+ [硬體和服務](sus-hardware-patterns.md)
+ [程序和文化](sus-development-deployment-patterns.md)
# 區域選擇
工作負載的 區域選擇會大幅影響其 KPIs，包括效能、成本和碳足跡。若要改善這些 KPIs，您應該根據業務需求和永續性目標，為工作負載選擇區域。
下列問題著重於這些永續性方面的考量。(如需永續性問題清單和最佳實務，請參閱[附錄](a-sustainability.md)。)
| SUS 1：如何為工作負載選取區域？ |
| --- |
| 工作負載的 區域選擇會大幅影響其 KPIs，包括效能、成本和碳足跡。若要改善這些 KPIs，您應該根據業務需求和永續性目標，為工作負載選擇區域。 |
# 因應需求
使用者和應用程式使用工作負載和其他資源的方式，可協助您找到改善的機會，以達成永續性目標。擴展基礎架構以持續符合需求，並確認您僅使用支援使用者所需的最低資源。讓服務層級符合客戶需求。妥善放置資源，以限制使用者和應用程式使用資源所需的網路。移除未使用的資產。為團隊成員提供滿足其需求的裝置，同時將對永續性的影響降至最低。
下列問題著重於永續性方面的考量：
| SUS 2：如何根據需求調整雲端資源？ |
| --- |
| 使用者和應用程式使用工作負載和其他資源的方式，可協助您找到改善的機會，以達成永續性目標。擴展基礎架構以持續符合需求，並確認您僅使用支援使用者所需的最低資源。讓服務層級符合客戶需求。妥善放置資源，以限制使用者和應用程式使用資源所需的網路。移除未使用的資產。為團隊成員提供滿足其需求的裝置，同時將對永續性的影響降至最低。 |
隨使用者負載擴展基礎設施：識別使用率低或無使用率的時期，並調整資源規模以減少過剩容量、提高效率。
SLAs 與永續性目標保持一致：定義和更新服務層級協議 （SLAs），例如可用性或資料保留期，以盡可能減少支援工作負載所需的資源數量，同時繼續滿足業務需求。
停止建立和維護未使用的資產：分析應用程式資產 (例如預先編譯的報告、資料集和靜態影像) 和資產存取模式，識別冗餘、未充分利用和可以除役的目標。合併具有冗餘內容的產生資產 (例如，具有重疊或通用資料集與輸出的每月報告)，以減少重複輸出時消耗資源。將未使用的資產除役 (例如不再販售產品的影像) 以釋放消耗的資源，並減少用於支援工作負載的資源數量。
針對使用者位置最佳化工作負載的地理位置：分析網路存取模式，識別客戶的地理連接位置。選取可減少網路流量傳輸距離的區域和服務，以減少支援工作負載所需的總網路資源。
為執行的活動最佳化團隊成員資源：最佳化提供給團隊成員的資源，以盡量減少對永續性的影響，同時支援他們的需求。例如，在使用率高的共用雲端桌面上執行複雜的操作 (例如渲染和編譯)，而不是在使用率低的高功率單一使用者系統上執行。
# 軟體和架構
實施可執行負載順暢並保持已部署資源一致高使用率的模式，將資源消耗降至最低。由於使用者行為隨時間改變，元件可能會因缺乏使用而閒置。修改模式和架構來整合未充分利用的元件，提高整體使用率。淘汰不再需要的元件。了解工作負載元件的效能，並最佳化消耗最多資源的元件。留意客戶用來存取服務的裝置，並實施盡量減少裝置升級需求的模式。
下列問題著重於這些永續性方面的考量：
| SUS 3：如何利用軟體和架構模式來支援永續性目標？ |
| --- |
| 實施可執行負載順暢並保持已部署資源一致高使用率的模式，將資源消耗降至最低。由於使用者行為隨時間改變，元件可能會因缺乏使用而閒置。修改模式和架構來整合未充分利用的元件，提高整體使用率。淘汰不再需要的元件。了解工作負載元件的效能，並最佳化消耗最多資源的元件。留意客戶用來存取服務的裝置，並實施盡量減少裝置升級需求的模式。 |
最佳化非同步與排程任務的軟體和架構：使用高效率的軟體設計和架構，將每個工作單元所需的平均資源降至最低。實作可平均利用元件的機制，減少任務之間的閒置資源，並將負載尖峰的影響降至最低。
移除或重構使用量低或完全未使用的工作負載元件：監控工作負載活動，識別各元件使用率隨時間的變化。移除未使用且不再需要的元件，並重構使用率低的元件，減少資源浪費。
最佳化程式碼中耗用最多時間或資源的區域：監控工作負載活動，識別消耗最多資源的應用程式元件。最佳化這些元件中執行的程式碼，將資源使用量降至最低，同時將效能發揮至最大。
最佳化對客戶裝置和設備的影響：了解客戶用來使用您服務的裝置和設備、其預期生命週期，以及更換這些元件對財務和永續性的影響。實作軟體模式和架構，將客戶更換裝置和升級設備的需求降至最低。例如，實作使用與較早硬體和作業系統版本向後相容的程式碼的新功能，或管理承載的大小，不讓其超過目標裝置的儲存容量。
使用最有效支援資料存取和儲存模式的軟體模式和架構：了解資料在工作負載中的使用方式、使用者的使用方式、傳輸方式以及儲存方式。選取可將資料處理和儲存要求降至最低的技術。
# 資料管理
下列問題著重於這些永續性方面的考量：
| SUS 4：如何利用資料管理政策和模式來支援永續性目標？ |
| --- |
| 實作資料管理實務來減少支援工作負載所需的佈建儲存，以及減少為了使用它所需的資源。了解您的資料，並使用最有效支援資料業務價值及其使用方式的儲存技術和組態。當需求減少時，將資料循環到效率較高、效能較低的儲存，並刪除不再需要的資料。 |
實作資料分類政策：將資料分類，以了解其對業務成果的重要性。使用此資訊來確定何時可將資料移動到更節能的儲存，或是可以安全刪除它。
使用支援資料存取和儲存模式的技術：使用最有效支援您的資料存取和儲存方式的儲存技術，以在支援工作負載的同時，也將佈建的資源降至最低。例如，固態裝置 （SSDs） 比磁性磁碟機更耗能，且應僅用於作用中的資料使用案例。針對不常存取的資料，使用節能的存檔類別儲存。
使用生命週期政策來刪除不需要的資料：管理所有資料的生命週期並自動執行刪除時間表，將工作負載的總儲存需求降至最低。
將區塊儲存中的過度佈建降至最低：若要最小化總佈建儲存，請建立具有適合工作負載之大小分配的區塊儲存。使用彈性磁碟區，隨著資料成長擴展儲存，無需調整連接到運算資源的儲存大小。定期審查彈性磁碟區，並縮減過度佈建的磁碟區以符合目前的資料大小。
移除不需要或多餘的資料：必要時才複製資料，將消耗的總儲存空間降至最低。使用在檔案和區塊層級刪除重複資料的備份技術。限制使用獨立磁碟機的備援陣列 （RAID） 組態，除非需要滿足 SLAs。
使用共用檔案系統或物件儲存體存取通用資料：採用共用儲存和單一真實來源，避免資料重複並降低工作負載的總儲存需求。僅在需要時從共用儲存體擷取資料。分離未使用的磁碟區以釋放資源。最小化跨網路的資料移動：使用共用儲存，並從區域資料存放區存取資料，將支援工作負載資料移動所需的總聯網資源降至最低。
僅在難以重新建立時才備份資料：為了將儲存消耗降至最低，僅備份具有業務價值或需要滿足合規要求的資料。檢查備份政策，並在復原案例中排除沒有價值的暫時性儲存。
# 硬體和服務
透過變更硬體管理實務，尋求降低工作負載永續性影響的機會。將佈建和部署所需的硬體量降至最低，並為個別工作負載選取最高效率的硬體和服務。
下列問題著重於這些永續性方面的考量：
| SUS 5：如何在架構中選擇並使用雲端硬體和服務來支援永續性目標？ |
| --- |
| 透過變更硬體管理實務，尋求降低工作負載永續性影響的機會。將佈建和部署所需的硬體量降至最低，並為個別工作負載選取最高效率的硬體和服務。 |
使用最低數量的硬體來滿足需求：使用雲端功能，您可以頻繁變更工作負載實作。隨著需求變更，更新已部署的元件。
使用影響最小的執行個體類型：持續關注新執行個體類型的發佈，並運用能源效率改進，包括旨在支援特定工作負載 (例如機器學習訓練和推論以及影片轉碼) 的執行個體類型。
使用 受管服務： 受管服務會將維持部署硬體高平均使用率和永續性最佳化的責任轉移到 AWS。使用受管服務，將服務的永續性影響分散給服務的所有租用戶，降低您的個人佔比。
最佳化您對 的使用GPUs：圖形處理單元 （GPUs） 可以是高耗電的來源，而且許多GPU工作負載具有高度可變性，例如轉譯、轉碼和機器學習訓練和建模。只在所需的時間內執行GPUs執行個體，並在不需要將耗用的資源降至最低時，透過自動化停用執行個體。
# 程序和文化
透過變更開發、測試和部署實務來尋找降低永續性影響的機會。
下列問題著重於這些永續性方面的考量：
| SUS 6：您的組織程序如何支援您的永續性目標？ |
| --- |
| 透過變更開發、測試和部署實務來尋找降低永續性影響的機會。 |
採用可快速導入永續性改進的操作：在將潛在改善部署到生產環境之前，先對其進行測試和驗證。在計算改善所帶來的未來潛在利益時，應考慮測試成本。開發低成本測試操作，以推動小改進的交付。
讓您的工作負載保持最新狀態： Up-to-date作業系統、程式庫和應用程式可以提高工作負載效率，並建立更有效率的技術採用。 Up-to-date 軟體也可能包含功能，以更精確地測量工作負載的永續性影響，因為廠商提供功能來滿足自己的永續性目標。
提高建置環境的使用率：使用自動化和基礎設施即程式碼，在需要時啟動生產前環境，並在不使用時將其關閉。常見的模式是排程可用性時間，使之與開發團隊成員的工作時間一致。休眠是一種有用的工具，可保留狀態，並在需要時快速讓執行個體上線。使用具有高載容量的執行個體類型、Spot 執行個體、彈性資料庫服務、容器和其他技術，以根據使用量調整開發和測試容量。
使用受管 Device Farm 進行測試：受管 Device Farm 可將硬體製造和資源使用的永續性影響分散給多個租用戶。受管 Device Farm 提供多種裝置類型，因此您可以支援較早且較不熱門的硬體，並避免不必要的裝置升級對客戶的永續性造成影響。
# 資源
請參閱下列資源，進一步了解我們的永續性最佳實務。
## 白皮書
+ [永續性支柱](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html?ref=wellarchitected-wp)
## 影片
+ [氣候承諾](https://www.youtube.com/watch?v=oz9iO0EOpI0&ref=wellarchitected-wp)