本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 標記使用案例 **Topics** + [成本分配和財務管理的標籤](tags-for-cost-allocation-and-financial-management.md) + [操作和支援的標籤](tags-for-operations-and-support.md) + [資料安全、風險管理和存取控制的標籤](tags-for-data-security-risk-management-and-access-control.md) # 成本分配和財務管理的標籤 組織通常會處理的第一個標記使用案例之一，就是成本和用量的可見性和管理。這通常有幾個原因： + **這通常是眾所周知的案例，而需求也是眾所周知的。**例如，財務團隊想要查看跨多個服務、功能、帳戶或團隊之工作負載和基礎設施的總成本。實現此成本可見性的一種方法是透過一致的資源標記。 + **標籤及其值已明確定義。**通常，成本分配機制已存在於組織的財務系統中，例如，透過成本中心、業務單位、團隊或組織職能進行追蹤。 + **快速、可證明的投資回報。**當資源標籤一致時，可以追蹤一段時間內的成本最佳化趨勢，例如，針對已權利化、自動擴展或排程的資源。 了解您在 中產生成本的方式， AWS 可讓您做出明智的財務決策。與實現的業務成果相比，了解您在資源、工作負載、團隊或組織層級產生成本的位置可增強您對在適用層級交付價值的了解。 工程團隊可能沒有資源的財務管理經驗。連接具有 AWS 財務管理專業技能的人員，該人員可以針對 AWS 財務管理的基礎訓練工程和開發團隊，並在財務和工程之間建立關係，以培養 FinOps 的文化，將有助於實現業務的可衡量成果，並鼓勵團隊以成本為基礎來建置。Well-Architected Framework [的成本最佳化支柱](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html)會深入探討建立良好的財務實務，但我們將探討本白皮書中的幾個基本原則。 # 成本分配標籤 成本分配是指根據定義的程序，將產生的成本指派或分配給這些成本的使用者或受益者。在本白皮書的內容中，我們將成本分配分為兩種類型：*顯示*和*退款*。 *顯示*工具和機制有助於提高成本意識。*退稅*有助於成本復原並推動成本意識的實現。*顯示*是關於特定實體產生的費用的呈現、計算和報告，例如業務單位、應用程式、使用者或成本中心。例如：「基礎設施工程團隊負責上個月 \$1X 的 AWS 支出」。*退款*是有關透過組織的內部會計程序向這些實體實際收取產生的成本，例如財務系統或日誌憑證。例如：「從基礎設施工程團隊的 AWS 預算中扣除 \$1X。」 在這兩種情況下，適當地標記資源有助於將成本分配給實體，唯一的區別是是否預期有人付款。 您組織的財務控管可能需要透明地計算應用程式、業務單位、成本中心和團隊層級所產生的成本。執行 [Cost Allocation Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) 支援的成本歸因，可提供準確歸因實體從適當標記的資源所產生的成本所需的資料。 + **問責** — 確保將成本分配給負責資源使用的人員。單一服務或群組可能需要負責支出審查和報告。 + **財務透明度** — 透過為領導層建立有效的儀表板和有意義的成本分析，顯示對 IT 的現金配置的清晰觀點。 + **明智的 IT 投資** — 根據專案、應用程式或業務線追蹤投資報酬率，並授權團隊做出更好的業務決策，例如，將更多資金分配給產生收入的應用程式。 總而言之，成本分配標籤有助於告訴您： + 誰擁有支出並負責將其最佳化？ + 產生支出的工作負載、應用程式或產品為何？ 哪個環境或階段？ + 哪些支出區域成長速度最快？ + 根據過去的趨勢，可以從 AWS 預算中扣除多少支出？ + 在特定工作負載、應用程式或產品中，成本最佳化工作有何影響？ 啟用成本分配的資源標籤有助於定義組織內的測量實務，可用於提供 AWS 用量的可見性，以提高對支出責任的透明度。它還專注於在成本和用量可見性方面建立適當的精細程度，並透過成本分配報告和 KPI 追蹤影響雲端消耗行為。 # 建置成本分配策略 ## 定義和實作成本分配模型 為要部署的資源建立帳戶和成本結構 AWS。建立 AWS 支出成本、產生這些成本的方式，以及產生這些成本的人員或來源之間的關係。常見的成本結構是以組織內 AWS Organizations AWS 帳戶的環境和實體為基礎，例如業務單位或工作負載。成本結構可以基於多個屬性，以允許以不同方式或以不同精細程度檢查成本，例如將個別工作負載的成本累積到其服務的業務範圍。 選擇符合所需結果的成本結構時，請評估成本分配機制的*實作簡易*性與*所需準確性*。這可能包括有關責任、工具可用性和文化變更的考量。 AWS 客戶通常從中開始的三種熱門成本分配模型為： + **以帳戶為基礎** — 此模型需要最少的工作量，並為顯示和退款提供高準確性，適合具有已定義帳戶結構的組織 （並與[使用多個帳戶組織您的 AWS 環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)白皮書的建議一致）。這可提供每個帳戶清晰的成本可見性。如需成本可見性和分配，您可以使用 [AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)、[成本和用量報告](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)，以及[AWS 預算](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)進行成本監控和追蹤。這些工具依 提供篩選和分組選項 AWS 帳戶。從成本分配的角度來看，此模型不需要依賴個別資源的準確標記。 + **業務單位或團隊型** — 成本可分配給企業內的團隊、業務單位或組織。此模型需要中等程度的工作量、為表演和費用提供高準確度，並且適用於具有已定義帳戶結構 （通常使用 AWS Organizations) 的組織，並在各種團隊、應用程式和工作負載類型之間進行區隔。這可在團隊和應用程式之間提供清晰的成本可見性，而且由於額外的優勢可降低在單一 內達到[AWS 服務配額](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)的風險 AWS 帳戶。例如，每個團隊可能有五個帳戶 (`prod`、`staging`、`test``dev`、、`sandbox`)，而且沒有兩個團隊和應用程式共用相同的帳戶。然後，透過這種結構，[AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) 將提供將帳戶或其他標籤 (「中繼標記」) 分組為類別的功能，這些功能可以在上一個範例中提及的工具中追蹤。請務必注意， AWS Organizations 允許標記帳戶和組織單位 (OUs)，但這些標籤不適用於成本分配和帳單報告 （即您無法 AWS Cost Explorer 依 OU 在 中分組或篩選成本）。 AWS Cost Categories應該用於此目的。 + **標籤型** - 此模型比前兩個模型需要更多精力，並且會根據需求和最終目標提供高準確度的顯示和收費。雖然我們強烈建議您採用[使用多個帳戶組織 AWS 環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)白皮書中概述的實務，但逼真的客戶通常會發現自己具有混合且複雜的帳戶結構，需要一些時間才能遷移。在此案例中，實作嚴格且有效的標記策略是關鍵，接著在 Billing and Cost Management 主控台中[啟用成本分配的相關標籤](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) （在 中 AWS Organizations，只能從 Management Payer 帳戶針對成本分配啟用標籤）。為成本分配啟用標籤後，先前方法中提到的成本可見性和分配工具可用於顯示和退款。請注意，成本分配標籤不是回溯性的，而且只有在啟用成本分配之後，才會出現在帳單報告和成本追蹤工具中。 總而言之，如果您需要依業務單位追蹤成本，您可以使用 [AWS Cost Categories](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html) 對 AWS Organization 內的連結帳戶進行相應分組，並在帳單報告中檢視此分組。當您為生產環境和非生產環境建立個別帳戶時，您也可以在 等工具中篩選與環境相關的成本[AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html)，或使用 [AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html) 追蹤這些成本。最後，如果您的使用案例需要更精細的成本追蹤，例如個別的工作負載或應用程式，您可以相應地標記這些帳戶中的資源、[啟用這些標籤索引鍵以進行管理帳戶的成本分配](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)，然後依帳單報告工具中的標籤索引鍵篩選該成本。 ## 建立成本報告和監控程序 從識別對內部利益相關者重要的成本類型開始 （例如，每日支出、帳戶成本、X 成本、攤銷成本）。透過這樣做，您可以比等待最終 AWS 發票更快地減少與意外或異常支出相關的預算風險。標籤提供可啟用這些報告案例的屬性。從報告獲得的洞見可以通知您的動作，以減輕異常和意外花費對財務預算的影響。當成本意外激增時，請務必評估交付的值是否有意外激增，以便您判斷是否需要採取 和何種動作。 開發支援成本分配的標記策略時，請記住下列元素： + **AWS Organizations** - 多個帳戶中的成本分配可以透過帳戶、帳戶群組或為這些帳戶上的資源建立的標籤群組來執行。為位於 中個別帳戶中的資源建立的標籤， AWS Organizations 只能用於管理帳戶中的成本分配。 + **AWS 帳戶** - 一個內部的成本分配 AWS 帳戶 可以由服務或區域等其他維度執行。您可以進一步標記 帳戶中的資源，並使用這類資源標籤的群組。 + **成本分配標籤** - 如有必要，可以為成本分配啟用使用者建立的標籤和 AWS 產生的標籤。在帳單主控台 ( 管理帳戶的 AWS Organizations) 中啟用成本分配標籤，有助於處理顯示和退款。 + **Cost Categories** - AWS Cost Categories 允許在 AWS 組織內分組帳戶和分組標籤 (「中繼標記」)，這進一步提供了透過 AWS Cost Explorer AWS 預算和成本和用量報告等工具分析這些類別相關 AWS 成本的能力。 ## 為企業內的業務單位、團隊或組織執行顯示和收費 使用成本結構和成本分配標籤支援的成本分配程序來歸納成本。標籤可用來向不直接負責支付成本，但負責產生這些成本的團隊提供表演。此方法可讓您了解其對支出的貢獻，以及這些成本的產生方式。對直接負責成本的團隊執行退款，以回收他們已消耗的資源費用，並讓他們了解這些成本及其產生方式。 ## 測量和循環效率或價值 KPIs 同意一組單位成本或 KPI 指標，以衡量雲端財務管理投資的影響。本練習在技術和業務利益相關者之間建立通用語言，並告知以效率為基礎的案例，而不是僅專注於絕對、彙總支出的案例。如需詳細資訊，請參閱此部落格，討論[單位指標如何協助在業務職能之間建立一致性](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metrics-help-create-alignment-between-business-functions/)。 ## 分配無法配置的支出 根據組織的會計實務，不同的收費類型可能需要不同的處理方式。識別無法標記的資源或成本類別。根據所使用的服務和計劃使用的服務，同意如何處理和衡量此類不可配置支出的機制。例如，查看 [AWS Resource Groups 和 標籤使用者指南中的 和 標籤編輯器](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html)支援的資源清單。 *AWS Resource Groups * 無法標記的成本類別的常見範例是承諾型折扣的一些費用，例如預留執行個體 (RI) 和 Savings Plans (SP)。雖然訂閱費用和未使用的 SP 和 RI 費用無法在出現在帳單報告工具之前加上標籤，但您可以在事後追蹤 RI 和 SP 折扣如何套用至 中的 AWS Organizations 帳戶、資源及其標籤。例如， AWS Cost Explorer 您可以查看攤銷成本、依相關標籤索引鍵花費的群組，以及套用與您使用案例相關的篩選條件。在 AWS 成本和用量報告 (CUR) 中，您可以篩選出與 RI 和 SP 折扣涵蓋的用量對應的行 （在 [CUR 文件](https://docs.aws.amazon.com/cur/latest/userguide/use-cases.html)的使用案例區段中閱讀更多資訊），然後選取僅與您相關的欄。為成本分配啟用的每個標籤索引鍵都會在 CUR 報告結尾顯示在自己的個別資料欄中，類似於它在其他舊版帳單報告中呈現的方式，例如[每月成本分配報告](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/configurecostallocreport.html)。如需其他參考，請參閱 [AWS Well-Architected 實驗室](https://www.wellarchitectedlabs.com/cost/300_labs/300_cur_queries/)以取得從 CUR 資料取得成本和用量洞察的範例。 ## 報告 除了可用於協助進行表演和收費 AWS 的工具之外，還有一系列其他 AWS 建立和第三方解決方案，可協助監控標記資源的成本，並測量標記策略的有效性。根據組織的需求和最終目標，可以投入時間和資源來建置自訂解決方案，或購買其中一個 [AWS 雲端 管理工具能力合作夥伴](https://aws.amazon.com/products/management-tools/partner-solutions/?partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=%2Aall&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-use-case=%2Aall&awsf.partner-solutions-filter-partner-location=%2Aall)提供的工具。如果您決定使用與業務相關的控制參數建立自己的*單一事實*來源成本分配工具， AWS 成本和用量報告 (CUR) 會提供最詳細的成本和用量資料，並啟用建立自訂最佳化儀表板，允許依帳戶、服務、成本類別、成本分配標籤和多個其他維度篩選和分組。在 開發的 CUR 型解決方案 AWS 中，做為這些工具之一，請查看 AWS Well-Architected 實驗室網站上的[雲端智慧儀表板](https://www.wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/)。 # 操作和支援的標籤 AWS 環境會有多個具有不同操作需求的帳戶、資源和工作負載。標籤可用來提供內容和指引，以支援營運團隊來增強服務的管理。標籤也可以用來提供受管資源的操作控管透明度。 推動一致操作標籤定義的一些主要因素包括： + **在自動化基礎設施活動期間篩選資源。**例如，部署、更新或刪除 資源時。另一個是擴展資源以進行成本最佳化和減少非工作時間用量。如需工作範例，請參閱[AWS 執行個體排程器](https://aws.amazon.com/solutions/implementations/instance-scheduler/)解決方案。 + **識別隔離或棄用的資源。**超過定義生命週期或已被內部機制標記為隔離的資源應適當加上標籤，以協助支援人員進行調查。取代的資源應在隔離、封存和刪除之前加上標籤。 + **一組資源的支援需求。**資源通常有不同的支援需求，例如，這些需求可以在團隊之間協商，或設定為應用程式關鍵性的一部分。如需操作模型的進一步指引，請參閱[卓越營運支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html)。 + **增強事件管理程序。**透過使用在事件管理程序中提供更高透明度的標籤來標記資源，支援團隊和工程師以及主要事件管理 (MIM) 團隊可以更有效地管理事件。 + **備份。**標籤也可以用來識別您的資源需要備份的頻率，以及備份複本需要前往何處或要還原備份的位置。[備份和復原方法的規範性指引 AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/welcome.html)。 + **修補。**在 中執行的修補可變執行個體對於您的整體修補策略和零時差漏洞的修補 AWS 至關重要。如需更深入的修補策略指引，請參閱[方案指引](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html)。本[部落格](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)討論了零時差漏洞的修補。 + **操作可觀測性**。將營運 KPI 策略翻譯為資源標籤，將有助於營運團隊更好地追蹤是否達到目標，以增強業務需求。制定 KPI 策略是一個單獨的主題，但往往專注於穩定狀態或衡量變革影響和結果的業務。[KPI Dashboards](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/cost-usage-report-dashboards/dashboards/2c_kpi_dashboard/) (AWS Well-Architected 實驗室） 和 Operations KPI Workshop ([AWS Enterprise Support 主動式服務](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)) 都會測量穩定狀態的效能。 AWS 企業策略部落格文章[測量轉型的成功](https://aws.amazon.com/blogs/enterprise-strategy/measuring-the-success-of-your-transformation/)，探索轉型計畫的 KPI 測量，例如 IT 現代化或從內部部署遷移到內部部署 AWS。 # 自動化基礎設施活動 管理基礎設施時，標籤可用於各種自動化活動。例如，使用 [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/index.html) 可讓您管理您建立之已定義鍵值對所指定資源上的自動化和 Runbook。對於受管節點，您可以定義一組標籤，依作業系統和環境來追蹤或鎖定節點。然後，您可以為群組中的所有節點執行更新指令碼，或檢閱這些節點的狀態。[Systems Manager 資源](https://docs.aws.amazon.com/systems-manager/latest/userguide/taggable-resources.html)也可以加上標籤，進一步精簡和追蹤您的自動化活動。 自動化環境資源的開始和停止生命週期，可為任何組織大幅降低成本。[上的執行個體排程器 AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler/)是解決方案的範例，可在不需要時啟動和停止 Amazon EC2 和 Amazon RDS 執行個體。例如，使用週末不需要執行的 Amazon EC2 或 Amazon RDS 執行個體的開發人員環境，並未利用關閉這些執行個體可提供的成本節省潛力。透過分析團隊及其環境的需求，並正確標記這些資源以自動化其管理，您可以有效地利用預算。 *執行個體排程器在 Amazon EC2 執行個體上使用的範例排程標籤：* ``` { "Tags": [ { "Key": "Schedule", "ResourceId": "i-1234567890abcdef8", "ResourceType": "instance", "Value": "mon-9am-fri-5pm" } ] } ``` # 工作負載生命週期 **檢閱支援操作資料的準確性。**確保定期審查與您的工作負載生命週期相關聯的標籤，並且適當的利益相關者參與這些審查。 *表 7 – 在工作負載生命週期中檢閱操作標籤* | 使用案例 | 標籤索引鍵 | 理由 | 範例數值 | | --- | --- | --- | --- | | 帳戶擁有者 | example-inc:account-owner:owner | 帳戶的擁有者及其包含的資源。 | ops-center, dev-ops, app-team | | 帳戶擁有者檢閱 | example-inc:account-owner:review | 檢閱帳戶擁有權詳細資訊是最新且正確的。 | <以標記程式庫中定義的正確格式檢閱日期> | | 資料擁有者 | example-inc:data-owner:owner | 資料所在帳戶的資料擁有者。 | bi-team, logistics, security | | 資料擁有者檢閱 | example-inc:data-owner:review | 檢閱資料擁有權詳細資訊是最新且正確的。 | <以標記程式庫中定義的正確格式檢閱日期> | ## 將標籤指派給暫停帳戶，然後再遷移至暫停的 OU 如[使用多個帳戶組織您的 AWS 環境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)白皮書所述，暫停帳戶並移至暫停的 OU 之前，應將標籤新增至帳戶，以協助內部追蹤和稽核帳戶生命週期。例如，組織 ITSM 票證系統上的相對 URL 或票證參考，顯示暫停之應用程式的稽核線索。 *表 8 - 在工作負載生命週期進入新階段時新增操作標籤* | 使用案例 | 標籤索引鍵 | 理由 | 範例數值 | | --- | --- | --- | --- | | 帳戶擁有者 | example-inc:account-owner:owner | 帳戶的擁有者及其包含的資源。 | ops-center, dev-ops, app-team | | 資料擁有者 | example-inc:data-owner:owner | 資料所在帳戶的資料擁有者。 | bi-team, logistics, security | | 暫停日期 | example-inc:suspension:date | 帳戶被暫停的日期 | <以標記程式庫中定義的正確格式暫停日期> | | 暫停的核准 | example-inc:suspension:approval | 帳戶停用核准的連結 | workload/deprecation | # 事件管理 標籤可以在事件管理的所有階段扮演重要角色，從事件記錄、優先順序、調查、通訊、解決到關閉。 標籤可以詳細說明應記錄事件的位置、應通知事件的團隊或團隊，以及定義的呈報優先順序。請務必記住，標籤未加密，因此請考慮您在其中存放哪些資訊。此外，在組織、團隊和報告管道中，責任會變更，因此請考慮儲存安全入口網站的連結，以便更有效地管理此資訊。這些標籤不需要是唯一的。例如，應用程式 ID 可用來在 IT 服務管理入口網站中查詢呈報路徑。請確定您的操作定義中清楚此標籤正用於多個用途。 操作需求標籤也可以詳細說明，以協助事件管理員和操作人員進一步完善其目標，以回應事件或事件。 [執行手冊](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.runbook.en.html)和[程序手冊](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.playbook.en.html)的相對連結 （知識系統基礎 URL) 可以包含為標籤，以協助回應團隊識別對應的程序、程序和文件。 *表 9 - 使用操作標籤通知事件管理* | 使用案例 | 標籤索引鍵 | 理由 | 範例數值 | | --- | --- | --- | --- | | 事件管理 | example-inc:incident-management:escalationlog | 支援團隊用來記錄事件的系統 | jira, servicenow, zendesk | | 事件管理 | example-inc:incident-management:escalationpath | 呈報路徑 | ops-center, dev-ops, app-team | | 成本分配和事件管理 | example-inc:cost-allocation:CostCenter | 依成本中心監控成本。這是雙重使用標籤的範例，其中使用成本中心做為事件記錄的應用程式碼 | 123-\$1 | | 排程備份 | example-inc:backup:schedule | 資源的備份排程 | Daily | | 手冊/事件管理 | example-inc:incident-management:playbook | 已記錄的手冊 | webapp/incident/playbook | # 修補 組織可以使用 AWS Systems Manager Patch Manager 和 自動化其針對可變運算環境的修補策略，並使可變執行個體與該應用程式環境定義的修補基準保持一致 AWS Lambda。在這些環境中可變執行個體的標記策略可以透過將上述執行個體指派給**修補程式群組****和維護 Windows** 來進行管理。請參閱下列開發 → 測試 → 生產分割的範例。 AWS 規範指引可用於[可變執行個體的修補程式管理。](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html) *表 10 - 操作標籤可以是環境特定的* | 開發 | 安裝 | 生產 | | --- | --- | --- | | 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab111",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#1 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab222",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab333",
"ResourceType": "instance",
"Value": "WEBAPP-DEV-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab444",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#2 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab555",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab666",
"ResourceType": "instance",
"Value": "WEBAPP-TEST-AL2"
}
]
}
| 
{
"Tags": [
{
"Key": "Maintenance Window",
"ResourceId": "i-012345678ab9ab777",
"ResourceType": "instance",
"Value": "cron(30 23 ? * TUE#3 *)"
},
{
"Key": "Name",
"ResourceId": "i-012345678ab9ab888",
"ResourceType": "instance",
"Value": "WEBAPP"
},
{
"Key": "Patch Group",
"ResourceId": "i-012345678ab9ab999",
"ResourceType": "instance",
"Value": "WEBAPP-PROD-AL2"
}
]
}
| 零時差漏洞也可以透過定義標籤來補充修補策略來管理。如需詳細指引[，請參閱使用 AWS Systems Manager 避免具有同日安全修補的零時差漏洞](https://aws.amazon.com/blogs/mt/avoid-zero-day-vulnerabilities-same-day-security-patching-aws-systems-manager/)。 # 操作可觀測性 需要可觀測性，才能獲得對您環境效能的可行洞見，並協助您偵測和調查問題。它也有次要目的，可讓您定義和測量關鍵績效指標 (KPIs) 和服務水準目標 SLOs)，例如執行時間。對於大多數組織而言，重要的操作 KPIs是偵測的平均時間 (MTTD) 和從事件復原的平均時間 (MTTR)。 在整個可觀測性中，內容很重要，因為會收集資料，然後收集關聯的標籤。無論您專注於哪個服務、應用程式或應用程式層，都可以篩選和分析該特定資料集。標籤可用來自動加入 CloudWatch 警示，以便在違反特定指標閾值時提醒適當的團隊。例如，標籤索引鍵`example-inc:ops:alarm-tag`及其值可能表示建立 CloudWatch 警示。[使用標籤為 Amazon EC2 執行個體建立和維護 Amazon CloudWatch 警示Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/)中會說明示範此作法的解決方案。 設定太多警示可以輕鬆建立警示風暴 - 當大量警示或通知快速壓倒運算子，並在運算子手動分類和排定個別警示的優先順序時降低其整體效率。警示的其他內容可以標籤形式提供，這表示規則可以在 Amazon EventBridge 中定義，以協助確保將焦點放在上游問題，而不是下游相依性。 營運與 DevOps 的角色通常被忽略，但對於許多組織而言，中央營運團隊仍然在正常營業時間之外提供重要的第一個回應。（如需此模型的詳細資訊，請參閱[卓越營運白皮書](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html)。) 與擁有工作負載的 DevOps 團隊不同，他們通常沒有相同的知識深度，因此標籤在儀表板和警示中提供的內容，可以引導他們找到問題的正確 Runbook，或啟動自動化 Runbook （請參閱部落格文章[使用 自動化 Amazon CloudWatch 警示 AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/))。 # 資料安全、風險管理和存取控制的標籤 組織在適當處理資料儲存和處理方面，需要滿足不同的需求和義務。資料分類是數個使用案例的重要前綴，例如存取控制、資料保留、資料分析和合規。 # 資料安全和風險管理 在 AWS 環境中，您可能擁有具有不同合規和安全性需求的帳戶。例如，您可能有一個開發人員沙盒，以及託管高管制工作負載生產環境的帳戶，例如處理付款。透過將它們隔離到不同的帳戶中，您可以[套用不同的安全控制](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#apply-distinct-security-controls-by-environment)、[限制對敏感資料的存取](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#constrain-access-to-sensitive-data)，並減少受管制工作負載的稽核範圍。 對所有工作負載採用單一標準可能會導致挑戰。雖然許多控制項同樣適用於環境，但對於不需要符合特定法規架構的帳戶，以及沒有任何個人身分識別資料存在的帳戶 （例如，開發人員沙盒或工作負載開發帳戶），有些控制項是過多或不相關的。這通常會導致誤判安全問題清單，這些問題清單必須分類並關閉，無需採取任何動作，這需要努力擺脫應調查的問題清單。 *表 11 – 資料安全和風險管理標籤範例* | 使用案例 | 標籤索引鍵 | 理由 | 範例數值 | | --- | --- | --- | --- | | 事件管理 | example-inc:incident- management:escalationlog | 支援團隊用來記錄事件的系統 | jira, servicenow, zendesk | | 事件管理 | example-inc:incident- management:escalationpath | 呈報路徑 | ops-center, dev-ops, app-team | | 資料分類 | example-inc:data:classification | 分類資料以進行合規和控管 | Public, Private, Confidential, Restricted | | 合規 | example-inc:compliance:framework | 識別工作負載受制於的合規架構 | PCI-DSS, HIPAA | 手動管理整個 AWS 環境的不同控制項既耗時又容易出錯。下一個步驟是自動化部署適當的安全控制，並根據該帳戶的分類設定資源檢查。透過將標籤套用至帳戶和其中的資源，可以針對工作負載自動並適當設定控制項的部署。 **範例：** 工作負載包含具有 標籤的 Amazon S3 儲存貯體，`example-inc:data:classification`其值為 `Private`。安全工具自動化會部署 AWS Config 規則 `s3-bucket-public-read-prohibited`，以檢查 Amazon S3 儲存貯體的封鎖公開存取設定、儲存貯體政策和儲存貯體存取控制清單 (ACL)，確認儲存貯體的組態適合其資料分類。為了確保儲存貯體的內容與 分類一致，[Amazon Macie 可以設定為檢查個人身分識別資訊 (PII)](https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-macie-supports-criteria-based-bucket-selection-sensitive-data-discovery-jobs/)。部落格[使用 Amazon Macie 驗證 S3 儲存貯體資料分類](https://aws.amazon.com/blogs/architecture/using-amazon-macie-to-validate-s3-bucket-data-classification/)會更深入探索此模式。 某些法規環境，例如保險和醫療保健，可能受到強制性資料保留政策的約束。使用標籤以及 Amazon S3 生命週期政策進行資料保留，是將物件轉換範圍限制到不同儲存層的有效且簡單方式。Amazon S3 生命週期規則也可以在強制保留期間到期後，用來使資料刪除的物件過期。如需此程序的深入指南[，請參閱搭配 Amazon S3 生命週期使用物件標籤來簡化資料生命週期](https://aws.amazon.com/blogs/storage/simplify-your-data-lifecycle-by-using-object-tags-with-amazon-s3-lifecycle/)。 此外，在分類或解決安全調查結果時，標籤可以為調查人員提供重要的內容，協助降低風險，並協助適當的團隊調查或緩解調查結果。 # 身分管理和存取控制的標籤 使用 管理跨 AWS 環境的存取控制時 AWS IAM Identity Center，標籤可以啟用多種模式以進行擴展。可以套用數種委派模式，有些是以標記為基礎。我們會個別處理它們，並提供連結以進一步閱讀。 # 個別資源的 ABAC IAM Identity Center 使用者和 IAM 角色支援屬性型存取控制 (ABAC)，可讓您根據標籤定義對操作和資源的存取。ABAC 有助於減少更新許可政策的需求，並協助您從公司目錄基礎存取員工屬性。如果您已使用多帳戶策略，除了角色型存取控制 (RBAC) 之外，還可以使用 ABAC，為在同一帳戶中操作的多個團隊提供對不同資源的精細存取權。例如，IAM Identity Center 使用者或 IAM 角色可以包含限制存取特定 Amazon EC2 執行個體的條件，否則必須在每個政策中明確列出才能存取這些執行個體。 由於 ABAC 授權模型取決於存取操作和資源的標籤，因此請務必提供護欄以防止意外存取。SCPs僅允許在特定條件下修改標籤，可用於保護整個組織的標籤。部落格[使用 中的服務控制政策保護用於授權的資源標籤， AWS Organizations](https://aws.amazon.com/blogs/security/securing-resource-tags-used-for-authorization-using-service-control-policy-in-aws-organizations/)以及 [IAM 實體的許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)，提供如何實作這項操作的資訊。 如果長期 Amazon EC2 執行個體用於支援更傳統的操作實務，則可以使用此方法，部落格[為 Amazon EC2 執行個體設定 IAM Identity Center ABAC，Systems Manager Session Manager](https://aws.amazon.com/blogs/security/configure-aws-sso-abac-for-ec2-instances-and-systems-manager-session-manager/) 會更詳細地討論這種形式的屬性型存取控制。如前所述，並非所有資源類型都支援標記，而且並非所有資源類型都支援使用標籤政策強制執行，因此在 上開始實作此策略之前，最好先評估這一點 AWS 帳戶。 若要了解支援 ABAC 的服務，請參閱[AWS 使用 IAM 的服務](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。