簡介
本 AWS 基礎知識課程旨在介紹有關在 AWS 中高效工作所需的核心概念。
首次啟動時，AWS 似乎勢不可擋。建置基礎架構的雲端原生模式可與傳統的內部部署操作方式完全脫離。而且，無論這是您首次使用基礎架構，還是在過去十年一直在最佳化 Linux 內核，都很難知道從何處開始選擇 AWS 超過 175 多項服務。
無論您的經驗如何，AWS 基礎知識課程都旨在協助您開始使用 AWS。在本課程中，我們將向您介紹 AWS 的五大支柱，這是考慮雲端時要使用的心理模型，也是適用於最終使用的任何服務的主要概念。
結構
AWS 基礎知識課程將分為五個單元。每個單元將遵循以下格式：
- 簡介：專注於支柱的簡短描述
- 心理模型：指導性心理模型，可協助您理解每個支柱中引入的概念
- 概念：涵蓋每個支柱廣泛基礎知識主題的主要概念
- 結論：我們討論的內容摘要
- 進一步閱讀：其他連結和資源
五大支柱
AWS 基礎知識課程涵蓋的五大支柱源於 AWS Well-Architected 架構。AWS Well-Architected 架構是對在雲端建置可擴展應用程式十多年來的經驗總結。
五大支柱由以下方面組成：
- 安全性
- 效能效率
- 可靠性
- 卓越營運
- 成本最佳化
安全性
安全性支柱側重於如何保護雲端上的基礎架構。安全與合規是 AWS 和客戶的共同責任。在此共用責任模型中，AWS 負責雲端的安全性。這包括 AWS 雲端服務的實體基礎架構、軟體和網路功能。客戶負責雲端中的安全性。這包括特定雲端服務、應用程式軟體的組態，以及敏感資料的管理。
若您的工作負載必須滿足 FedRAMP、DoD SRG、ITAR、CJIS 或其他嚴格的合規性要求，或者它們包含歸類為受控未分類資訊 (CUI) 的資料，請參閱課程的 AWS GovCloud (US) 部分。
心理模型
在思考雲端中的安全性時，採用零信任模型非常有用。
在此模型中，所有應用程式元件和服務都被視為離散且潛在的惡意實體。這涉及基礎網路結構，有權存取您的資源的所有代理程式，以及服務中執行的軟體。
概念
當我們從零信任的角度來思考安全性時，這意味著我們需要在系統的所有級別上套用安全措施。以下是在雲端零信任安全系統中涉及的三個重要概念：
- Identity and Access Management (IAM)
- 網路安全
- 資料加密
-
Identity and Access Management (IAM)
IAM 是負責追蹤系統中身份和存取的服務。透過適當命名的 IAM 服務在 AWS 上對其進行管理。使用 IAM 政策來管理存取權，該政策對 AWS 內的代理程式強制執行存取邊界。IAM 政策包含三個基本組成部份：
- 主題指定向誰授予許可
- 操作指定要執行什麼操作
- 資源指定正在存取哪些屬性
將零信任模型套用至 IAM 意味著採用最低權限原則。這意味著每個代理程式應僅具有完成其功能所需的最小許可。
IAM 政策可以套用至 AWS 主體或 AWS 資源。與主體關聯的政策稱為身份政策。與資源關聯的政策稱為資源政策。請注意，只有某些服務 (例如 S3、KMS、SES) 具有資源政策。
主體是否具有對特定資源執行操作的許可，取決於該主體的身份政策是否允許其這樣操作，以及該資源的資源政策 (若存在) 是否禁止其這樣操作。
請注意，這是 IAM 許可模型的主要簡化。還有許多其他政策類型會影響是否可以授予存取權。這些可以包括許可邊界、組織服務控制政策、存取控制清單和工作階段政策。這些其他政策類型超出了本課程範圍。如需有關這些政策更多詳細資訊，請參閱本單元的進一步閱讀部份。
關鍵點
- IAM 政策聲明 AWS 中實體的存取邊界
- IAM 政策由主題、操作和資源組成
- IAM 政策可用於強制執行最低權限原則
- IAM 具有許多政策類型 - 例如身份政策和資源政策
- IAM 根據評估適用於指定資源的所有政策類型來評估存取權
進一步閱讀
-
網路安全
網路安全涉及可保障網路及網路可存取資源的存取權與可用性的任何系統、組態或程序。無論是網路層級還是資源層級，AWS 均提供廣泛的功能來保護您的網路。
網路安全零信任方法涉及深度防禦方法，可將安全控制套用於網路的所有層 (而不僅僅是最外層)。
網路層級安全性
AWS 中的基本網路層級基元是 Amazon Virtual Private Cloud (VPC)。這是您定義的邏輯網路，並且可佈建資源資訊。
以下是組成 VPC 的一些元件：
- 子網路：VPC 中的一系列 IP 地址
- 路由表：一組確定流量定向位置的規則
- 網際網路閘道：允許 VPC 內部資源與網際網路之間通訊的元件
為了保護 VPC 中的流量，您可以將資源分為面向公眾的資源和內部資源。為了減少攻擊面，您可以使用 Application Load Balancer (ALB) 等代理服務，來處理所有面向網際網路的流量。然後，可以在內部子網路中佈建所有內部服務，例如伺服器和資料庫，這些子網路與直接的公有網際網路存取無關。
除了 VPC，您還可以使用 AWS Web Application Firewall (WAF)，進一步限制進入網路的流量。
資源層級安全性
個別 AWS 資源還具有您可以設定的網路安全控制。最常見的控制稱為安全群組。安全群組即您可以用於強制流量流入和流出資源的虛擬防火牆。使用安全群組，僅允許從特定連接埠和信任來源至您的執行個體的流量。您可以將安全群組附加至資源，例如 EC2 執行個體、RDS 執行個體和 Lambda。
關鍵點
- 網路安全涉及可保障網路及網路可存取資源的存取權與可用性的專門機制
- 零信任網路安全方法涉及在網路所有層進行深度防禦
- VPC 和 WAF 允許您在網路層級套用安全措施
- 安全群組允許您在資源級別套用安全措施
進一步閱讀
-
資料加密
資料加密是對資訊進行編碼的程序，這種方式對於任何不具備解密資料所需金鑰的第三方來說都無法了解。
對資料採用零信任模型，意味著在傳輸中和靜態時能隨時隨地對我們的資料進行加密。
傳輸中加密
傳輸中加密涉及在系統之間傳輸資料時對其進行加密。AWS 內的所有儲存和資料庫服務均提供 HTTPS 端點，其支援對傳輸中資料進行加密。AWS 還提供網路服務，可協助您針對自己的服務在傳輸中強制執行加密。例如，您可以使用 Application Load Balancer (ALB)，來強制透過 HTTPS 與您的端點建立連線。
靜態加密
靜態加密涉及對系統內的資料進行加密。所有 AWS 儲存和資料庫服務均支援靜態加密。大多數這些服務都預設處於開啟狀態。加密不收取額外費用，且加密資料的效能開銷可忽略不計。
大多數儲存和資料庫服務還直接與 Amazon Key Management Service (KMS) 整合。這是一項中央金鑰管理服務，讓您能夠建立客戶受管金鑰 (CMK) 來對資料加密。
使用 CMK 可為您提供加密以外的其他功能。這包括能夠使用自己的自訂金鑰存放區，能夠透過與 AWS CloudTrail 整合，來為加密資源建立稽核追蹤，以及強制執行自動金鑰輪換。
關鍵點
- 加密是對資訊進行編碼的程序，這種方式只有擁有正確金鑰的各方才能解密資訊
- 透過在傳輸中和靜態時進行加密來保護資料
- AWS 上的所有儲存和資料庫服務都可在靜態時和傳輸中提供加密
- 您可以使用 ALB 等 AWS 網路服務，來為自己的服務在傳輸中強制執行加密
- 您可以使用 CMK 解鎖進階功能，例如建立稽核追蹤，使用您自己的自訂金鑰，以及自動金鑰輪換
進一步閱讀
結論
在本單元中，您已了解 AWS 的安全性支柱。您已經了解零信任的心理模型。您已經了解 IAM 和最小權限原則。您已深入了解 AWS 網路安全性和防禦原理。您已了解資料加密，以及在傳輸和靜止狀態下如何套用資料加密。
進一步閱讀
效能效率
效能效率支柱側重於如何在雲端中高效、可擴展地執行服務。雖然雲端為您提供了處理任何流量的方式，但它需要您在選擇和設定服務時要考慮到規模。
心理模型
在思考雲端中的效能效率時，將服務視為牛而非寵物是很有用的。
在內部部署伺服器模型中，伺服器十分昂貴，並且通常採用手動部署和設定。實際交付伺服器並以實體方式裝入資料中心可能需要數週時間。因此，對待伺服器就像寵物 - 每個伺服器都是唯一的，並且需要大量維護。其中一些甚至有名字。
在雲端則把伺服器作為牛來思考。伺服器是可在幾秒內自動佈建的商品資源。在服務運作中，沒有任務單一伺服器是必不可少的。
概念
將伺服器作為牛來思考，可以給我們帶來許多與效能相關的好處。在管理伺服器的「寵物模型」中，將相同類型的伺服器 (甚至同一伺服器) 用於多個工作負載是很常見的 - 訂購和佈建不同的機器太麻煩了。而在「牛模型」中，佈建既實惠又快捷，這讓我們能夠自由選擇最適合我們工作負載的伺服器類型。
此外「牛模型」也能讓我們輕鬆擴展服務。因為每個伺服器都可互換，並且部署快捷，所以我們可以新增更多伺服器來快速擴展容量。
我們將專注於以下兩個概念，以實現效能效率：
- 選擇
- 擴展
-
選擇
在 AWS 上選擇能夠選擇與您的工作負載最接近的服務。AWS 擁有最廣泛的服務選擇，涵蓋超過兩打類別的 175 多種服務。透過選擇來實現效能，意味著能夠為任務選擇適當的工具。
典型的工作負載通常需要在 AWS 的四個主要服務類別中進行選擇：運算、儲存、資料庫和網路。
- 運算處理將處理您的資料服務 (例如，虛擬機器)
- 儲存處理資料的靜態儲存 (例如，物件儲存)
- 資料庫處理資料的有序儲存 (例如，關聯式資料庫)
- 網路處理您的資料移動方式 (例如，內容交付網路)
在本單元中，我們將介紹如何在前三個類別中做出正確選擇。請參考進一步閱讀部份，獲取有關在不同聯網選項中進行選擇的指南。
無論您選擇哪種服務，都需要考慮三件事。
- 服務類型
- 管理程度
- 組態
服務類型
在類別中進行選擇時，AWS 為您提供了許多可供使用的服務類型選項。該類型對於每個類別都是唯一的。
選擇運算服務時，請確定是以 VM、容器，還是以無伺服器運算為基礎。
- VM 型運算是大多數人最熟悉的心理模型，但價格可能更高，並且需要更多維護
- 容器型運算可以更好地劃分工作負載，並且可以快速擴展，但會帶來額外的組態和協調複雜性
- 無伺服器型運算可消除大多數管理和擴展複雜性，但存在嚴格的系統限制，需要採用新的工具鏈和程序
選擇儲存服務時，請確定是否需要檔案存放區、區塊存放區、物件存放區或存檔存放區。
- EBS 這類區塊儲存服務非常適合持久儲存單一 EC2 執行個體資料的情況
- EFS 這類檔案系統非常適合讓多個用戶端存取同一資料的情況
- 物件存放區，例如 S3，非常適合需要由任意數量的用戶端存取大型資料區塊的情況
- S3 Glacier 這類存檔儲存非常適合需要不常存取大量資料的情況
選擇資料庫服務時，請確定您是需要關聯式資料庫、非關聯式資料庫、資料倉儲解決方案，還是資料索引和搜尋解決方案。
- 關聯式資料庫具有聯接和 ACID 屬性，但對效能和資料儲存具有上限
- 非關聯式資料庫具有更靈活的結構描述，並且可以擴展至比其關聯式對應資料庫更高的限制，但通常缺少聯接和完整的 ACID 功能
- 資料倉儲解決方案透過快速存取 PB 級結構化資料來實現大規模分析
- 資料索引和搜尋解決方案可讓您索引和搜尋各種來源的資料
管理程度
確定服務類型後，需要進一步縮小至特定服務範圍 - AWS 有時會提供跨特定服務類型的多種服務。在相同類型的各種 AWS 服務之間，主要區別在於其管理程度。
使用運算服務並確定 VM 類型後，需要在 EC2、Lightsail 和 Elastic Beanstalk 之間進行選擇。直接使用 EC2 可為您提供最大的控制權，但管理卻最少，而選擇 Lightsail 則需要一些自訂以換取更多的受管體驗。Elastic Beanstalk 介於兩者之間 – 它為您的服務架構提供固定框架，但允許您透過組態來進行自訂。
在您使用儲存服務時，選擇服務比較容易，因為對於任何指定類型 (例如，物件存放區為 S3，檔案存放區為 EFS)，往往只有一項服務。
使用資料庫服務並確定關聯式類型時，需要在 RDS 和 Aurora 之間做出選擇。RDS 使您能夠更好地控制基礎資料庫，並且可用於大多數關聯式資料庫。Aurora 僅適用於某些版本的 MySQL 和 PostgreSQL，但負責管理基礎儲存並具有內建的叢集支援。
歸根結底，特定服務的選擇很大程度上取決於您對基礎技術的熟悉程度，以及您對或多或少受管體驗的偏好。
組態
確定服務後，您將需要進一步決定設定方式。組態設定取決於您希望實現的特定效能特徵，每種服務類別各不相同。
在評估運算服務的效能特徵時，查看記憶體和運算需求是不錯的開始：
- 若您使用 VM 型運算，則記憶體和 CPU 會受到執行個體大小 (例如 t3.small vs t3.xlarge) 和執行個體系列 (例如r3.small vs c5.small) 的影響
- 若您使用容器型運算，則可個別設定記憶體和 CPU
- 若您使用無伺服器型運算，則只能直接設定記憶體 - 運算值 (以及其他系統資源) 會線性增加至可用記憶體大小
請注意，根據您的工作負載，您可能會擔心額外的資源限制，例如網路容量和執行個體儲存體這類資源的可用性。
在評估儲存服務的效能特徵時，請考慮您的延遲、輸送量和 IOPS 要求：
- 若您使用區塊儲存服務
- 延遲受磁碟區類型選擇的影響 (例如，固態磁碟機與硬碟磁碟機)
- 對於大多數磁碟區類型，輸送量與磁碟區大小成比例
- 對於大多數磁碟區類型，IOPS 容量與磁碟區大小成比例
- 若您使用檔案系統服務
- 延遲和 IOPS 受您選擇的效能模式的影響
- 輸送量受您選擇使用的佈建輸送量的影響
- 若您使用物件存放區
- 延遲受儲存貯體端點的地理距離的影響
- 輸送量受輸送量最佳化 API 使用情況的影響，例如分段上傳
- IOPS 不可設定
- 若您使用存檔存放區
- 延遲受儲存貯體端點的地理距離和擷取方法選擇的影響
- 輸送量受輸送量最佳化 API 使用情況的影響，例如分段上傳
- IOPS 不可設定
在評估資料庫服務的效能特徵時，請考慮資源需求 (例如，CPU、記憶體、儲存體等)：
- 若您使用關聯式資料庫
- 資源功能取決於您選擇的 EC2 執行個體
- 若您使用非關聯式資料庫，例如 DynamoDB
- 資源功能由組態選項確定，例如佈建容量
- 若您使用資料倉儲解決方案，例如 Redshift
- 資源功能取決於您選擇的基礎 EC2 執行個體
- 若您使用 Elasticsearch Service 等索引解決方案
- 資源功能取決於您選擇的 EC2 執行個體
關鍵點
- AWS 提供許多服務和多種方式來實現目標
- 在 AWS 上實作工作負載涉及跨運算、儲存、資料庫和網路類別選擇服務
- 在每個類別中，您可以根據使用案例選擇正確的服務類型
- 在每種類型中，您可以根據所需的管理程度選擇特定的服務
- 在每項服務中，您可以根據要實現的特定效能特徵選擇特定的組態
進一步閱讀
-
擴展
雖然選擇正確的服務是入門的關鍵，但選擇服務的擴展方式對於持續效能很重要。
AWS 有兩種主要的擴展方式：
- 垂直擴展
- 水平擴展
垂直擴展
垂直擴展涉及將基礎運算升級至更大的執行個體類型。例如，假設您正在執行 t3.small 執行個體。垂直擴展此執行個體可能會將其升級至 t3.large。
垂直擴展通常更容易實現，而無須叢集服務。缺點是與水平擴展相比，上限要低得多 (等於您的運算執行個體的大小上限)。它還表現出單點故障，因為執行個體中斷可能導致您的服務完全不可用。
水平擴展
水平擴展涉及增加基礎執行個體的數量。例如，假設您正在執行 t3.small 執行個體。水平擴展此執行個體將涉及提供兩個額外的 t3.small 執行個體。
水平擴展在實現方面涉及更多的開銷。這是因為您需要代理服務才能將流量路由至您的服務機群。您還需要執行運作狀態檢查，以將不良執行個體從路由集區中刪除，並選擇最適合您工作負載的特定路由演算法。作為交換，您最終獲得的服務具有更大的彈性，並且可以擴展至比垂直擴展服務更高的限制。
關鍵點
- 垂直擴展在操作上更簡單，但存在可用性風險且限制更低
- 水平擴展需要更大開銷，但可靠性更佳、限制更高
進一步閱讀
結論
在本單元中，您已了解 AWS 的效能效率支柱。您已了解將伺服器視為牛而非寵物的心理模型。您已了解如何根據效能目標選擇正確的服務及其組態。您已了解擴展服務以及垂直和水平擴展之間的權衡。
進一步閱讀
可靠性
可靠性支柱側重於如何建置可抵抗服務和基礎架構中斷的服務。與效能效率非常相似，雖然雲端為您提供了建置可承受中斷的彈性服務的方式，但它需要您在設計服務時要考慮到可靠性。
心理模型
思考雲端中的可靠性時，考慮影響範圍很有用。您可以將影響範圍視為系統發生故障時可能承受的最大影響。為了建置可靠的系統，您想要最小化任何個別元件的影響範圍。
概念
在思考影響範圍時，失敗問題不再是假設問題，而是時間問題。為了在發生失敗時進行處理，可以使用以下技術來限制影響範圍：
- 故障隔離
- 限制
-
故障隔離
故障隔離使用透過故障隔離區分隔的冗余獨立元件，來限制事件的影響範圍。故障隔離區包含任何故障對隔離區內區域的影響。
AWS 具有三個級別的故障隔離區：
- 資源與請求
- 可用區域
- 區域
資源與請求
AWS 服務在指定維度，如資源 ID，分割所有資源與請求。這些分區稱為單元。單元採用獨立設計，並在單一單元內包含故障。幕後故事︰AWS 使用隨機分區等技術來限制影響範圍。每次您發出請求或建立資源時，所有這些均以透明方式發生，並且無須您執行任何其他操作。
可用區域
AWS 可用區域 (AZ) 是完全獨立的設施，具有專用電源、服務和網路功能。它們在地理上與其他可用區域相距較遠，以免因火災和洪水等環境危害而導致相關故障。
透過在多個可用區域中部署服務的冗餘執行個體，能夠在可用區域級別實現故障隔離。這樣做意味著一個可用區域發生的電源事件，不會影響您在另一個可用區域中的流量。
關於延遲的注意事項 - 雖然可用區域在地理位置上是分隔的，但它們之間的距離足夠近，從而使可用區域之間的網路延遲降至最低。如此一來，某些功能便可在可用區域之間發揮作用，例如同步資料複寫。
區域
AWS 區域提供最終隔離。每個區域都是一個完全自主的資料中心，由兩個或多個可用區域組成。透過在不同 AWS 區域之間部署服務的冗余複本，能夠在區域級別實現故障隔離 (這正是 AWS 對其自身服務所做的)。
如您需要極高的可用性，請考慮部署至多個區域。請注意，由於區域間沒有共用的基礎架構，因此跨多個區域運作服務會產生大量開銷。各種服務和功能可協助您進行多區域擴展。例如，您可以使用 AWS 的可擴展 DNS 服務 Route53，在不同區域之間路由流量。您還可以使用 DynamoDB 全域表和 S3 跨區域複寫等功能，來跨區域複寫資料。
關鍵點
- 使用故障隔離區來限制服務影響範圍或基礎架構中斷
- 在設計每項 AWS 服務時均已內建資源與請求級別的故障隔離，因此您無須執行任何其他操作
- 透過在多個可用區域中部署您的服務，能夠在可用區域級別實現故障隔離，這可將對延遲的影響降至最低
- 透過跨多個區域部署服務來實現區域級別的故障隔離，這需要大量的營運開銷
進一步閱讀
-
限制
限制是為保護您的服務免於過多負載而套用的約束。它們是限制外部 (例如 DDoS 攻擊) 和內部 (例如軟體設定錯誤) 事件影響範圍的有效方式。
AWS 服務在每個帳戶每個區域都具有服務特定限制。這些限制也稱為服務配額。這些是您的 AWS 帳戶中某些資源、操作和項目的最大值。
限制有兩種：
- 軟限制可透過向 AWS 請求提升服務限額來增加
- 硬限制則不能增加
每種服務都具有不同的限制。若要追蹤您的限制和請求提升服務限額情況，可以使用 Service Quotas 服務。
務必監控服務限制並知道何時接近服務限制，這樣可以避免服務中斷。對於某些資源，例如並行 Lambda 執行，可以透過 CloudWatch 進行追蹤。其他資源，如 EC2 執行個體數目，則需要手動或透過指令碼進行追蹤。若您有業務支援或企業支援計劃，則可以使用 AWS Trusted Advisor 服務來追蹤您的限制。此外，還可以使用 awslimitchecker 等開放原始碼工具來自動化程序。
關鍵點
- 限制是為保護服務免於過多負載而套用的約束
- 可以使用 Service Quota 服務來追蹤和管理 AWS 服務限制
- 具有可以增加的軟限制和不能增加的硬限制
- 監控正在使用的服務限制，並規劃相應的提升服務限額，以避免服務中斷
進一步閱讀
結論
在本單元中，您已了解 AWS 的可靠性支柱。您已了解思考影響範圍的心理模型。您已了解如何使用故障隔離區來限制影響範圍。您已了解服務限制，以及如何提升服務限額以避免服務中斷。
進一步閱讀
卓越營運
卓越營運支柱專注於如何不斷提高系統執行能力，建立更好的程序並獲得洞見。
心理模型
在思考雲端中的卓越營運時，從自動化的角度來考慮是很有用的。
人為錯誤是造成缺陷和營運事件的主要原因。自動化營運程度越高，發生人為錯誤的機率就越少。
除了防止錯誤，自動化還可協助您不斷改善內部程序。他們可促進執行一套可重複的最佳實務，這可套用於整個組織。
概念
當您將營運作為自動化來思考時，您會希望將精力集中在目前需要最多人工操作，且可能導致最大錯誤後果的領域。您還將希望設置程序來追蹤、分析和改善您的營運工作。
我們將專注於以下兩個概念，以實現卓越營運：
- Infrastructure as Code
- 可觀察性
-
Infrastructure as Code
Infrastructure as Code (IaC) 是透過機器可讀的組態檔案來管理基礎結構的程序。IaC 是實現基礎架構自動化的基礎。
您並非手動佈建服務，而是建立描述所需資源的範本。然後，IaC 平台會代您處理資源的佈建和設定。
IaC 為您提供一種宣告式及自動化的基礎架構佈建方式。它讓您能夠為基礎架構套用相同的工具 (例如，git) 和程序 (例如，程式碼審查)，就像您已經為程式碼所做的那樣。
傳統上已使用 CloudFormation 實作 IaC on AWS。CloudFormation 需要使用 JSON 或 YAML 宣告您的資源。若不需要這些組態語言，AWS 還提供 Cloud Development Kit (CDK)，這讓您能夠使用 JavaScript、Python 和 Java 等本機程式設計語言來編寫 CloudFormation 範本。
關鍵點
- IaC 是指透過機器可讀的組態檔案來管理基礎結構的程序
- IAC 是佈建基礎架構的一種宣告式及自動化的方式
- 您可以對基礎架構套用與操作程式碼時類似的工具和程序
- 使用 CloudFormation 和 CDK 等服務實作 IaC on AWS
進一步閱讀
-
可觀察性
可觀察性是衡量系統內部狀態的程序。通常，這樣做是為了將其最佳化為某個所需最終狀態。
當談及卓越營運時，您無法改善自己無法衡量的部份。建立堅實的可觀察性基礎，這讓您能夠追蹤自動化的影響，並不斷做出改進。
實作可觀察性涉及以下步驟：
- 集合
- 分析
- 操作
集合
集合是在評估系統狀態時彙總所有必要指標的程序。
這些指標可分為以下幾類：
- 基礎架構級指標
- 這些指標由 AWS 服務自動發出，並透過 CloudWatch 服務收集
- 某些服務還會發出可透過 CloudWatch Logs 啟用和收集的結構化日誌
- 這些指標由 AWS 服務自動發出，並透過 CloudWatch 服務收集
- 應用程式級指標
- 這些指標由您的軟體產生，可透過 CloudWatch 自訂指標收集
- 可以使用 CloudWatch Logs 儲存軟體日誌或將其上傳至 S3
- 帳戶級指標
- 這些指標由您的 AWS 帳戶記錄，可透過 CloudTrail 服務收集
分析
若要分析收集的指標，您可以使用 AWS 提供的眾多資料庫和分析解決方案之一。
根據您的使用案例選擇一個合適選項：
- 若要分析儲存在 CloudWatch Logs 中的日誌，請考慮使用 CloudWatch Logs Insight，該服務讓您能夠以互動方式搜尋和分析 Cloudwatch 日誌資料
- 若要分析儲存在 S3 中的日誌，請考慮使用 Athena，這是一項無伺服器查詢服務
- 若要分析結構資料，請考慮使用 RDS，這是一種受管的關聯式資料庫服務
- 若要分析大量結構化資料，請考慮使用 RedShift，這是一種受管的 PB 級資料倉儲服務
- 若要分析日誌型資料，請考慮使用 Elasticsearch Service，這是常用開放原始碼分析引擎 Elasticsearch 的受管版本
操作
在收集並分析指標之後，就可以用其來實現特定結果或程序。
以下是結果和程序範例：
- 監控與警示
- 當系統違反特定指標的安全閾值時，可使用 CloudWatch 警示來通知您
- 該警示可以觸發手動或自動減少。
- 儀表板
- 您可以使用 Cloudwatch 儀表板來建立指標的儀表板
- 您可以使用這些儀表板來追蹤和改善服務效能
- 資料驅動型決策
- 您可以追蹤效能和業務 KPI 來制定資料驅動型產品決策
關鍵點
- 可觀察性是衡量系統內部狀態以實現某些所需最終狀態的程序
- 可觀察性包括收集、分析指標並採取操作
- 您可以在服務、應用程式和帳戶級收集指標
- 您可以使用 CloudWatch Log Insight、Athena、Elasticsearch Service、RDS 和 Redshift 等服務來分析指標
- 您可以透過建立監控，警示和儀表板，以及追蹤效能和業務 KPI 來執行指標
進一步閱讀
結論
在本單元中，您已了解卓越營運支柱。您已了解將營運作為自動化來思考的心理模型。您已經了解 IaC，及如何採用與目前用於程式碼的相同工具和程序，將其用於自動佈建服務。您已經了解可觀察性，以及如何收集、分析指標及採取操作，來不斷改善您的營運成果。
進一步閱讀
成本最佳化
成本最佳化支柱可協助您在最小化成本的同時實現業務成果。
心理模型
在思考雲端中的成本最佳化時，從 OpEx 而不是 CapEx 的角度來考慮雲端支出是很有用的。OpEx 是一種持續的按用量付費模式，而 CapEx 是一次性購買模式。
內部部署資料中心的傳統 IT 成本主要是 CapEx。無論您是否最終使用，都需要為所有容量支付預付費用。購買新伺服器可能是一個漫長的程序，需要獲得多方的簽核。這是因為 CapEx 成本通常高昂，而錯誤造成的損失也非常大。購買後，實際的伺服器可能仍需要數週才能投入使用。
在 AWS 中，您的成本為 OpEx。您只需持續為所用的容量付費。透過工程設計可即時佈建新伺服器，而無須冗長的核准程序。這是因為 OpEx 成本要小得多，而且若需求發生變化，可以收回。因為您只需為用量付費，所以任何多餘容量都可以輕鬆停止和終止。在您決定使用服務時，可以按秒和分鐘訂購量來完成佈建。
概念
從 CapEx 模型轉變為 OpEx 模型，從根本上改變了您的基礎架構成本估算方法。您無須考慮大量的預付固定成本，而只需考慮較小的持續可變費用。
此按用量付費模型對成本最佳化程序做出以下變更：
- 按用量付費
- 成本最佳化生命週期
-
按用量付費
AWS 服務具有按用量付費模型，您只需為使用的容量付費。以下是在按用量付費時最佳化雲端支出的四種常用方法：
- 適當的大小
- 無伺服器
- 預留
- Spot 執行個體
適當的大小
適當的大小是指將服務佈建和組態與您的工作負載相符。對於 EC2 服務，這意味著選擇正確的執行個體大小和系列。若您的運算資源大部份閒置，考慮使用較小的 EC2 執行個體。若您的工作負載需要大量特定的系統資源，考慮切換至針對該資源最佳化的執行個體系列。
為了協助完成此程序，可以使用 AWS Compute Optimizer，根據過去的系統指標獲得最佳的 EC2 規模調整建議。
無伺服器
在使用 Lambda 等無伺服器技術時，您只需為用量付費。若您的 Lambda 未執行，則不會向您收費。無伺服器是按用量付費的終極範例。在您的使用案例允許的情況下，選擇無伺服器可能是建置服務最具經濟高效的方式。
預留
請求預留是指承諾支付一定容量以換取大額折扣。對於 EC2，這可為您的運算帶來多達 72% 的折扣。
若要為您的運算預留空間，可以使用 Savings Plans。您可以註冊 1 年或 3 年期，並承諾使用特定量的運算來節省 EC2、Fargate 和 Lambda 的費用。
請注意，預留並非 EC2 獨有，因為您還可以請求其他服務，例如 RDS、DynamoDB 和 CloudFront。
Spot 執行個體
相較於隨需價格，EC2 Spot 執行個體能讓您利用未使用的 EC2 容量，以高達 90% 的折扣來執行各種執行個體。這可為您的容錯工作量節省大量資金。
使用 Spot 執行個體時的權衡是 EC2 可以隨時回收容量。在此之前，您的應用程式將收到終止兩分鐘的通知。
關鍵點
- AWS 服務按用量付費 - 您只需為使用的容量付費
- 您可以調整執行個體大小，以節省與您的工作量不相符的服務成本
- 您可以使用無伺服器技術，來確保僅在客戶使用服務時才付費
- 您可以使用預留獲得折扣以換取預付承諾
- 您可以使用 Spot 執行個體來獲得執行容錯工作負載的折扣
進一步閱讀
-
成本最佳化生命週期
成本最佳化生命週期是改善您一段時間內雲端支出的持續程序。
它涉及以下三個步驟的工作流程：
- 審查
- 追蹤
- 最佳化
審查
在最佳化雲端支出之前，您首先需要了解其來源。
AWS Cost Explorer 可協助您直觀地查看和審查一段時間內的雲端支出。您可以按服務和類別等不同方面細分支出。使用 Cost Explorer 可以獲取有關帳單的高階概觀和詳細報告。
若您需要更多精細資料，可以使用 AWS 成本和用量報告，獲取每小時的明細項目。
追蹤
總體了解雲端支出後，即可按照您關注的維度對其進行分組。使用成本分配標籤完成此操作。這需要對您想要追蹤的每個項目開啟標籤。
以下是標籤類別的常見範例：
- 應用程式 ID – 識別與特定應用程式相關的資源，以便在專案結束時輕鬆追蹤支出變化並關閉。
- 自動化選擇加入/退出 – 指示是否應將資源包含在自動化活動中，例如啟動、停止或調整執行個體大小。
- 成本中心/業務部門 – 識別與資源關聯的成本中心或業務部門，通常用於成本分配和追蹤。
- 擁有者 – 識別資源負責人。這通常是技術擁有者。如有需要，可以新增單獨的業務擁有者標籤。您可以將擁有者指定為電子郵件地址。藉助電子郵件地址，視需提供自動通知技術和業務擁有者的相關支援 (例如，若資源是彈性或適當大小的備用資源)。
除標籤外，您還可以使用 AWS 預算來建立預算目標。使用預算，您可以監控自己關注的各個維度的支出。預算會根據您設置的篩選器，來追蹤並建立您目前 AWS 支出的預測。
最佳化
在審查並追蹤支出之後，可以對其進行最佳化。最佳化支出涉及實作我們在按用量付費中討論的技術。這種最佳化通常是總體預算目標的一部份。
以下是最佳化目標的範例：
- Cost Savings Plan 涵蓋的 EC2 執行個體百分比 – 您的組織應爭取 80%-90% 的覆蓋率
- 閒置資源百分比 – 閒置的定義和確切百分比將因您的業務而異
關鍵點
- 成本最佳化生命週期是改善您一段時間內雲端支出的持續程序
- 成本最佳化生命週期包括審查、追蹤和最佳化支出
- 審查您的支出涉及使用 Cost Explorer 等工具以及成本和用量報告，以了解您的支出
- 追蹤支出涉及使用成本分配標籤和預算，按業務相關維度篩選資料
- 最佳化支出涉及將上述技術用作總體預算目標的一部份
進一步閱讀
結論
在本單元中，您已了解成本最佳化支柱。您已了解如何將專注於 OpEx 的模型應用於您的雲端支出。您已了解成本最佳化技術，例如適當的大小、無伺服器、預留和 Spot 執行個體。您已了解如何使用 Cost Explorer、標籤和預算等服務來審查、追蹤和最佳化預算。
進一步閱讀
AWS GovCloud (US)
此部分適用於以下情況的使用者︰工作負載必須滿足 FedRAMP、DoD SRG、ITAR、CJIS 或其他嚴格的合規性要求，或者它們包含歸類為受控未分類資訊 (CUI) 的資料。
AWS GovCloud (US) 有助於滿足聯邦、州和地方各級美國政府機構，以及在航空航天、國防製造、執法、醫療保健、金融服務、能源以及其他受嚴格管制產業的美國商業組織的特定合規性和管制要求。AWS GovCloud (US) 區域專為在雲端託管敏感資料和管制工作負載而設計，是由美國本土的美國公民員工負責營運的隔離 AWS 區域。
AWS GovCloud (US) 為政府客戶及其合作夥伴帶來了靈活性，以建構符合 FedRAMP High 基準、美國司法部刑事司法資訊系統（ (CJIS) 安全政策、國際武器販運條例 (ITAR)、出口管理條例 (EAR)、國防部 (DoD) 針對影響級別 2、4 和 5 的雲端運算安全要求指南 (SRG)、FIPS 140-2、IRS-1075 及其他合規制度的安全雲端解決方案。
從受控非保密資訊 (CUI)、個人身份資訊 (PII)、敏感的患者病歷、財務資料到執法資料、匯出受控資料及其他形式的 CUI，AWS GovCloud (US) 區域可協助客戶解決其雲端之旅各個階段的合規性問題。
進一步閱讀
恭喜您！
您現在已經完成了 AWS 基礎知識課程。在本課程中，您學習了以下內容：
- AWS Well-Architected 架構的五大支柱
- 重要的心理模型代表對五大支柱的雲端原生思維方式
- 五大支柱中每個支柱的主要概念
至此，您已經學習了在雲端建置安全性、效能效率、可靠性、卓越營運及成本最佳化服務的基礎知識。雖然只是初步了解一些知識，但現在您已為 AWS 剩餘旅程奠定了堅實的起點。現在，您已經完成 AWS 基礎知識課程，繼續並運用您所學的知識，在 AWS 上建置您的下一個出色服務。