Azure 企業 Scaffold：規範訂用帳戶治理

  • 發行項

注意

Azure 企業 Scaffolding 已整合到 Microsoft 雲端採用架構。 本文中的內容現在會以 架構的就緒方法 表示。 本文將于 2020 年初淘汰。 若要開始使用新的程式，請參閱 就緒方法概觀 、 Azure 登陸區域 和 登陸區域考慮 。

企業越來越採用公用雲端，使其靈活度和彈性。 他們依賴雲端的優勢來產生營收，並將企業的資源使用量優化。 Microsoft Azure 提供許多服務和功能，讓企業組合起來，例如建置組塊，以解決各種工作負載和應用程式。

決定使用 Microsoft Azure 只是達成雲端權益的第一個步驟。 第二個步驟是瞭解企業如何有效地使用 Azure，並找出需要就地的基準功能，以解決下列問題：

  • 「我擔心資料主權;如何確保我的資料和系統符合我們的法規需求？
  • 「如何?知道每個資源支援的專案，以便我可以加以考慮，並正確地向它計費？
  • 「我想確保我們在公用雲端中部署或執行的一切，先以安全性的心態開始，如何協助協助？

沒有護欄的空訂用帳戶的前景令人生畏。 此空白空間可能會妨礙您移至 Azure。

本文提供技術專業人員解決治理需求，並將其與靈活度需求平衡的起點。 它介紹企業 Scaffold 的概念，可引導組織以安全的方式實作和管理其 Azure 環境。 它提供開發有效且有效率控制項的架構。

控管的需求

移至 Azure 時，您必須儘早解決治理主題，以確保企業內雲端成功使用。 不幸的是，建立綜合治理系統的時間和官僚作風意味著一些商業團體直接前往提供者，而不需要涉及企業 IT。 如果資源未正確管理，此方法可能會讓企業保持開放，以遭到入侵。 公用雲端的特性—靈活度、彈性和以使用量為基礎的定價—對於需要快速滿足客戶需求（內部和外部）的商業群組而言非常重要。 但企業 IT 必須確保資料和系統受到有效保護。

建立建築物時，會使用 Scaffolding 來建立結構的基礎。 Scaffold 會引導一般大綱，並提供錨點，以便掛接更永久的系統。 企業 Scaffold 相同：一組彈性的控制項和 Azure 功能，可為環境提供結構，並為建置在公用雲端上的服務錨點。 它提供建置者（IT 和業務群組）建立和附加新服務的基礎，以保持傳遞速度。

Scaffold 是以我們與各種規模的用戶端進行許多互動所收集的做法為基礎。 這些用戶端的範圍從雲端中的小型組織開發解決方案，到正在移轉工作負載並開發雲端原生解決方案的大型跨國企業和獨立軟體廠商。 企業 Scaffold 是「目的建置」，可彈性地支援傳統 IT 工作負載和敏捷式工作負載，例如開發人員根據 Azure 平臺功能建立軟體即服務 （SaaS） 應用程式。

企業 Scaffold 可作為 Azure 內每個新訂用帳戶的基礎。 它可讓系統管理員確保工作負載符合組織的最低治理需求，而不會防止商務群組和開發人員快速達成自己的目標。 我們的經驗顯示，這會大幅加速公用雲端成長，而不是妨礙公用雲端成長。

注意

Microsoft 已推出預覽稱為 Azure 藍圖的 新功能，可讓您跨訂用帳戶和管理群組封裝、管理及部署通用映射、範本、原則和腳本。 這項功能是 Scaffold 作為參考模型，並將該模型部署至組織之間的橋樑。

下圖顯示 Scaffold 的元件。 基礎依賴管理階層和訂用帳戶的穩固計畫。 這些要素包含 Resource Manager 原則和強式命名標準。 Scaffold 的其餘部分是核心 Azure 功能與功能，可啟用及連線安全且可管理的環境。

Enterprise scaffold

定義階層

Scaffold 的基礎是透過訂用帳戶和資源群組進行Enterprise 合約註冊的階層和資源關聯性。 註冊會從合約觀點定義公司內 Azure 服務的形狀和使用方式。 在Enterprise 合約中，您可以將環境進一步細分為部門、帳戶、訂用帳戶和資源群組，以符合您組織的結構。

Hierarchy

Azure 訂用帳戶是包含所有資源的基本單位。 它也會在 Azure 中定義數個限制，例如核心數目、虛擬網路和其他資源。 資源群組可用來進一步精簡訂用帳戶模型，並啟用更自然的資源群組。

每個企業都不同，上圖中的階層可讓您在公司內組織 Azure 的方式有顯著的彈性。 將階層模型化以反映貴公司的計費、資源管理和資源存取需求，是您在公用雲端中啟動時做出的第一個最重要的決策。

部門和帳戶

EA 註冊的三種常見模式如下：

  • 功能 模式：

    Diagram of the functional pattern.

  • 業務單位 模式：

    Diagram of the business unit pattern.

  • 地理 模式：

    Diagram of the geographic pattern.

雖然這些模式有其位置， 但業務單位 模式越來越適用于其彈性，以模型化組織的成本模型，以及反映控制範圍。 Microsoft 的核心工程和營運群組已建立以聯邦 、 州 和 地方 為基礎的 有效業務單位 模式子集 。 如需詳細資訊，請參閱 組織您的訂用帳戶和資源群組 。

Azure 管理群組

Microsoft 現在提供另一種方式來建立階層的模型： Azure 管理群組 。 管理群組比部門和帳戶更有彈性，而且可以巢狀最多六個層級。 管理群組可讓您建立與計費階層分開的階層，只為了有效率地管理資源。 管理群組可以鏡像計費階層，而且企業通常會以這種方式開始。 不過，管理群組的強大功能是當您使用這些群組來建立組織模型、將相關的訂用帳戶分組在一起（不論其位於計費階層中的位置為何），以及指派一般角色、原則和計畫。 這些範例包含：

  • 生產環境與非生產環境。 有些企業會建立管理群組，以識別其生產和非生產訂閱。 管理群組可讓這些客戶更輕鬆地管理角色和原則。 例如，非生產訂用帳戶可能會允許開發人員「參與者」存取，但在生產環境中，他們只有「讀取者」存取權。
  • 內部服務與外部服務。 企業對於內部服務與面向客戶的服務，通常會有不同的需求、原則和角色。

設計良好的管理群組，以及Azure 原則和原則計畫，是有效治理 Azure 的骨幹。

訂用帳戶

決定部門和帳戶（或管理群組）時，您主要評估如何安排 Azure 環境以符合您的組織。 不過，訂用帳戶是實際工作發生的地方，而這裡的決策會影響安全性、延展性和計費。 許多組織會使用下列模式作為其指南：

  • 應用程式/服務： 訂用帳戶代表應用程式或服務（應用程式組合）
  • 生命週期： 訂用帳戶代表服務的生命週期，例如 Production 或 Development 。
  • 部門： 訂用帳戶代表組織中的部門。

前兩個模式最常使用，而且強烈建議使用這兩種模式。 生命週期方法適用于大部分的組織。 在此情況下，一般建議是使用兩個基底訂用帳戶和 ， ProductionNonproduction 然後使用資源群組進一步分隔環境。

資源群組

Azure Resource Manager 可讓您將資源組織成有意義的群組，以進行管理、計費或自然親和性。 資源群組是具有通用生命週期或共用屬性的資源容器，例如 All SQL servers 或 Application A 。

資源群組無法巢狀化，而且資源只能屬於一個資源群組。 某些動作可以針對資源群組中的所有資源採取行動。 例如，刪除資源群組會移除資源群組內的所有資源。 和訂用帳戶一樣，建立資源群組時有常見的模式，而且會因傳統 IT 工作負載而異，以敏捷式 IT 工作負載：

  • 傳統 IT 工作負載 通常會依相同生命週期內的專案分組，例如應用程式。 依應用程式分組允許個別的應用程式管理。
  • 敏捷式 IT 工作負載 往往著重于外部客戶面向的雲端應用程式。 資源群組通常會反映部署層級（例如 Web 層或應用層）和管理。

注意

瞭解您的工作負載可協助您開發資源群群組原則。 這些模式可以混合和比對。 例如，共用服務資源群組可以位於與敏捷式工作負載資源群組相同的訂用帳戶中。

命名標準

Scaffold 的第一個支柱是一致的命名標準。 設計完善的命名標準可讓您在入口網站、帳單和腳本內識別資源。 您可能已經有內部部署基礎結構的現有命名標準。 將 Azure 新增至您的環境時，您應該將這些命名標準延伸至您的 Azure 資源。

提示

針對命名慣例：

  • 請盡可能檢閱並採用 雲端採用架構命名和標記指引 。 本指南可協助您決定有意義的命名標準，並提供廣泛的範例。
  • 使用 Resource Manager 原則來協助強制執行命名標準。

請記住，稍後很難變更名稱，所以幾分鐘後會讓您稍後省下麻煩。

將您的命名標準集中在較常用和搜尋的資源上。 例如，為了清楚起見，所有資源群組都應該遵循強式標準。

資源標籤

資源標籤與命名標準緊密對齊。 當資源新增至訂用帳戶時，邏輯上分類訂用帳戶的計費、管理和作業用途就愈來愈重要。 如需詳細資訊，請參閱 使用標籤來組織您的 Azure 資源 。

重要

標籤可以包含個人資訊，而且可能屬於 GDPR 的規定。 仔細規劃標籤的管理。 如果您要尋找 GDPR 的一般資訊，請參閱 Microsoft 服務信任入口網站的 GDPR 一節 。

標記在計費和管理之外有許多種使用方式。 它們通常用來作為自動化的一部分（請參閱後續章節）。 如果未在前面考慮，這可能會導致衝突。 最佳做法是識別企業層級的所有通用標籤（例如 ApplicationOwner 和 CostCenter ），並在使用自動化部署資源時一致地套用它們。

Azure 原則和計畫

Scaffold 的第二個要素包括使用 Azure 原則和計畫 來管理風險，方法是對訂用帳戶中的資源和服務強制執行規則（效果）。 Azure 原則計畫是旨在達成單一目標的原則集合。 接著，原則和計畫會指派給資源範圍，以開始強制執行這些原則。

當與稍早所述的管理群組搭配使用時，原則和計畫更為強大。 管理群組可讓您將方案或原則指派給整個訂用帳戶集。

Resource Manager 原則的常見用法

原則和計畫是功能強大的 Azure 工具。 原則可讓公司為傳統 IT 工作負載提供控制項，為企業營運應用程式提供穩定性，同時允許更敏捷的工作負載開發，例如開發客戶應用程式，而不會讓企業面臨額外的風險。 原則最常見的模式如下：

  • 地理合規性和資料主權。 Azure 擁有全球不斷成長的區域清單。 企業通常需要確保特定範圍中的資源會保留在地理區域中，以解決法規需求。
  • 避免公開伺服器。 Azure 原則可以禁止部署特定資源類型。 通常建立原則來拒絕在特定範圍內建立公用 IP，避免將伺服器意外暴露至網際網路。
  • 成本管理和中繼資料。 資源標籤通常用來將重要的計費資料新增至 資源和資源群組，例如 CostCenter 和 Owner 。 這些標籤對於準確計費和管理資源而言是無價的。 原則可以強制將資源標籤的應用程式套用至所有已部署的資源，讓您更容易管理。

計畫常見用途

計畫可讓企業將邏輯原則分組，並將其追蹤為單一實體。 計畫可協助企業解決敏捷式和傳統工作負載的需求。 計畫的常見用法包括：

  • 在 適用於雲端的 Microsoft Defender 中啟用監視。 這是Azure 原則中的預設方案，也是哪些計畫的絕佳範例。 它可啟用原則，以識別未加密的 SQL 資料庫、虛擬機器 （VM） 弱點，以及更常見的安全性相關需求。
  • 法規特定方案。 企業通常會將法規需求（例如 HIPAA）通用的群組原則分組，以便有效率地追蹤這些控制項的控制和合規性。
  • 資源類型和 SKU。 建立一項計畫，限制可部署的資源類型，以及可部署的 SKU，有助於控制成本，並確保貴組織只會部署小組具備技能集和支援的資源。

提示

我們建議您一律使用方案定義，而不是原則定義。 將方案指派給範圍，例如訂用帳戶或管理群組之後，您可以輕鬆地將另一個原則新增至方案，而不需要變更任何指派。 這可讓瞭解套用的內容並追蹤合規性更為容易。

原則和計畫指派

建立原則並將其分組為邏輯計畫之後，您必須將原則指派給範圍，例如管理群組、訂用帳戶或資源群組。 指派可讓您也從原則指派中排除子範圍。 例如，如果您拒絕在訂用帳戶內建立公用 IP，您可以為連線到受保護 DMZ 的資源群組建立排除指派。

範例顯示如何在 GitHub 存放庫中 將 azure-policy 原則和計畫套用至 Azure 中的資源。

身分識別與存取管理

採用公用雲端時要問的關鍵問題是「神秘應該具有資源的存取權？」和「如何?控制此存取權？」控制Azure 入口網站和資源存取對於雲端中資產的長期安全性至關重要。

若要保護您的資源存取權，您必須先設定識別提供者，然後設定角色和存取權。 連線至您內部部署的 Active Directory的 Microsoft Entra ID 是 Azure 中身分識別的基礎。 不過，Microsoft Entra 識別碼與 內部部署的 Active Directory不同 ，請務必瞭解什麼是 Microsoft Entra 租使用者，以及它與您的註冊有何關聯。 檢閱 Azure 中的資源存取管理，以深入瞭解 Microsoft Entra 識別碼和內部部署的 Active Directory。 若要將內部部署目錄連線並同步處理至 Microsoft Entra ID，請安裝及設定 內部部署的 Microsoft Entra 連線工具 。

Diagram of an architecture that includes both Microsoft Entra ID and an on-premises Active Directory instance.

當 Azure 最初發行時，訂用帳戶的存取控制是基本的：使用者可以獲指派管理員istrator 或共同管理員istrator 角色。 存取此傳統模型中的訂用帳戶隱含存取入口網站中的所有資源。 這種缺乏精細的控制導致訂用帳戶激增，為註冊提供合理的存取控制層級。 不再需要此訂用帳戶的激增。 使用 Azure 角色型存取控制 （RBAC），您可以將使用者指派給標準角色，例如提供一般許可權的擁有者、參與者或讀者，或甚至建立您自己的角色。

實作 Azure 角色型存取控制時，強烈建議使用下列做法：

  • 控制訂用帳戶的 管理員istrator 和共同管理員istrator 角色，因為這些角色具有廣泛的許可權。 如果您需要管理 Azure 傳統部署，您只需要將訂用帳戶擁有者新增為共同管理員istrator。
  • 使用管理群組跨多個訂用帳戶指派 角色 ，並降低在訂用帳戶層級管理角色的負擔。
  • 將 Azure 使用者新增至 Active Directory 中的群組（例如 Application X Owners ）。 使用同步群組來提供群組成員適當的許可權，以管理包含應用程式的資源群組。
  • 遵循授 與執行預期工作所需的最低許可權 原則。

重要

請考慮使用 Microsoft Entra Privileged Identity Management 、 Azure 多重要素驗證 和 Microsoft Entra 條件式存取 功能，為您的 Azure 訂用帳戶中的系統管理動作提供更好的安全性和更可見度。 這些功能來自有效的 Microsoft Entra ID P1 或 P2 授權（視功能而定），可進一步保護您的身分識別及管理。 Microsoft Entra PIM 透過核准工作流程啟用 Just-In-Time 系統管理存取，以及系統管理員啟用和活動的完整稽核。 Azure 多重要素驗證是另一個重要功能，可啟用雙步驟驗證來登入Azure 入口網站。 與 Microsoft Entra 條件式存取控制結合時，您可以有效地管理危害的風險。

規劃及準備身分識別和存取控制，並遵循 Azure 身分識別管理最佳做法 是您可以採用的最佳風險風險降低策略之一，而且每個部署都應該視為必要。

安全性

傳統上，雲端採用的最大阻礙之一就是對安全性的擔憂。 IT 風險管理員和安全性部門需要確保 Azure 中的資源預設受到保護和保護。 Azure 提供可用來保護資源的功能，同時偵測並消除對這些資源的威脅。

適用於雲端的 Microsoft Defender

適用於雲端的 Microsoft Defender除了 進階威脅防護之外，還提供您環境中資源安全性狀態的統一檢視。 適用於雲端的 Defender是一個開放平臺，可讓 Microsoft 合作夥伴建立可插入並增強其功能的軟體。 免費層的基準功能適用於雲端的 Defender提供可增強安全性狀態的評量和建議。 其付費層可啟用額外且有價值的功能，例如 Just-In-Time 特殊許可權存取和調適型應用程式控制（allowlists）。

提示

適用於雲端的 Defender是一種功能強大的工具，可透過可用來偵測威脅和保護企業的新功能，定期加以改善。 強烈建議一律啟用適用於雲端的 Defender。

Azure 資源的鎖定

當您的組織將核心服務新增至訂用帳戶時，避免業務中斷變得越來越重要。 當在 Azure 訂用帳戶中執行的腳本或工具意外刪除資源時，就會發生一個常見的中斷。 鎖定會 限制高價值資源的作業，其中修改或刪除這些資源將產生重大影響。 您可以將鎖定套用至訂用帳戶、資源群組或個別資源。 將鎖定套用至基礎資源，例如虛擬網路、閘道、網路安全性群組和金鑰儲存體帳戶。

Secure DevOps Kit for Azure

Secure DevOps Kit for Azure （AzSK） 是一組腳本、工具、延伸模組和自動化功能，最初由 Microsoft 自己的 IT 小組所建立，並 透過 GitHub 發行為開放原始碼。 AzSK 可配合小組的端對端 Azure 訂用帳戶和資源安全性需求，使用廣泛的自動化，並將安全性順暢地整合到原生 DevOps 工作流程中，以下列六個重點領域達成安全的 DevOps：

  • 保護訂用帳戶
  • 啟用安全開發
  • 將安全性整合到 CI/CD
  • 持續保證
  • 警示和監視
  • 雲端風險治理

Overview diagram of the Secure DevOps Kit for Azure

AzSK 是一組豐富的工具、腳本和資訊，是完整 Azure 治理計畫的重要部分，並納入您的 Scaffold 對於支援組織風險管理目標至關重要。

Azure 更新管理

您可以執行的其中一項重要工作，以確保您的伺服器已使用最新的更新進行修補。 雖然有許多工具可達成此目的，但 Azure 會提供 Azure 更新管理解決方案 ，以解決重要 OS 修補程式的識別和推出。 本指南稍後的 <自動化 >一節會使用Azure 自動化。

監視和警示

收集和分析遙測，提供您跨 Azure 訂用帳戶使用之服務的活動、效能計量、健康情況和可用性，對於主動管理應用程式和基礎結構至關重要，而且是每個 Azure 訂用帳戶的基礎需求。 每個 Azure 服務都會以活動記錄、計量和診斷記錄的形式發出遙測。

  • 活動記錄 會描述訂用帳戶中資源上執行的所有作業。
  • 計量是由描述資源效能和健康情況的資源所發出的數值資訊。
  • 診斷記錄 是由 Azure 服務發出，並提供有關該服務作業的豐富、頻繁資料。

這項資訊可以在多個層級上檢視及採取行動，並持續改善。 Azure 透過下圖中所述的服務，提供 Azure 資源的共用、核心和深層監視功能。

Diagram that depicts deep application monitoring, deep infrastructure monitoring, core monitoring, and shared capabilities.

共用功能

  • 警示： 您可以從 Azure 資源收集每個記錄、事件和計量，但無法收到重大條件和動作的通知，此資料僅適用于歷史用途和鑒識。 Azure 警示會主動通知您所有應用程式和基礎結構所定義的條件。 您可以跨記錄、事件和計量建立警示規則，以使用動作群組來通知收件者集合。 動作群組也提供使用 Webhook 等外部動作將補救自動化的能力，以執行 runbook 和 Azure Functions Azure 自動化。

  • 儀表板： 儀表板可讓您匯總監視檢視，並將跨資源和訂用帳戶的資料合併，以讓您瞭解 Azure 資源的遙測資料。 您可以建立及設定自己的檢視，並與其他人共用。 例如，您可以建立包含各種磚的儀表板，讓資料庫管理員提供所有 Azure 資料庫服務的資訊，包括 Azure SQL 資料庫、適用於 PostgreSQL 的 Azure 資料庫和適用於 MySQL 的 Azure 資料庫。

  • 計量總管： 計量是由 Azure 資源產生的數值（CPU 百分比或磁片 I/O 計量），可提供資源的作業和效能見解。 使用計量總管，您可以定義並傳送您感興趣的計量給 Log Analytics 以進行匯總和分析。

核心監視

  • Azure 監視器： Azure 監視器是核心平臺服務，可提供單一來源來監視 Azure 資源。 Azure 監視器的Azure 入口網站介面提供跨 Azure 的所有監視功能的集中式跳躍點，包括 Application Insights、Log Analytics、網路監視、管理解決方案和服務對應的深層監視功能。 透過 Azure 監視器，您可以視覺化、查詢、路由、封存及處理來自整個雲端資產之 Azure 資源的計量和記錄。 除了入口網站之外，您還可以透過 Azure 監視器 PowerShell Cmdlet、跨平臺 CLI 或 Azure 監視器 REST API 來擷取資料。

  • Azure Advisor： Azure Advisor 會持續監視訂用帳戶和環境之間的遙測。 它也建議將 Azure 資源成本優化的最佳作法，並改善應用程式資源的效能、安全性和可用性。

  • Azure 服務健康狀態： Azure 服務健康狀態可識別可能影響您應用程式的 Azure 服務任何問題，並協助您規劃排程的維護時段。

  • 活動記錄： 活動記錄會描述訂用帳戶中資源的所有作業。 它會提供稽核線索， 以判斷資源上任何 CRUD 作業（建立、更新、刪除）作業的身 分 和時機 。 活動記錄事件會儲存在平臺中，並可供查詢 90 天。 您可以在 Log Analytics 中擷取活動記錄，以取得較長的保留期間，以及跨多個資源進行更深入的查詢和分析。

深層應用程式監視

  • Application Insights： Application Insights 可讓您收集應用程式特定的遙測資料，並監視雲端或內部部署應用程式中應用程式的效能、可用性和使用量。 藉由使用支援的 SDK 來檢測您的應用程式，包括 .NET、JavaScript、JAVA、Node.js、Ruby 和 Python。 Application Insights 事件會內嵌到支援基礎結構和安全性監視的相同 Log Analytics 資料存放區，讓您能夠透過豐富的查詢語言來相互關聯和匯總事件。

深層基礎結構監視

  • Log Analytics： Log Analytics 藉由從各種來源收集遙測和其他資料，並提供查詢語言和分析引擎，讓您深入瞭解應用程式和資源的作業，在 Azure 監視中扮演重要角色。 您可以透過快速記錄搜尋和檢視直接與 Log Analytics 資料互動，或者您可以使用其他 Azure 服務中的分析工具，將資料儲存在 Log Analytics 中，例如 Application Insights 或 適用於雲端的 Microsoft Defender。

  • 網路監視： Azure 的網路監視服務可讓您深入瞭解網路流量、效能、安全性、連線能力及瓶頸。 規劃良好的網路設計應該包括設定 Azure 網路監視服務，例如網路監看員和 ExpressRoute 監視器。

  • 管理解決方案： 管理解決方案是針對應用程式或服務封裝的邏輯、深入解析和預先定義的 Log Analytics 查詢集合。 他們依賴 Log Analytics 作為儲存和分析事件資料的基礎。 範例管理解決方案包括監視容器和 Azure SQL 資料庫分析。

  • 服務對應： 服務對應提供基礎結構元件的圖形檢視、其進程，以及其他電腦和外部進程的相互依存性。 它會整合 Log Analytics 中的事件、效能資料和管理解決方案。

提示

建立個別警示之前，請先建立並維護一組可在 Azure 警示中使用的共用動作群組。 這可讓您集中維護收件者清單、通知傳遞方法（電子郵件、SMS 電話號碼）和 Webhook 的外部動作生命週期（Azure 自動化 Runbook、Azure Functions 和 Logic Apps、ITSM）。

成本管理

當您從內部部署雲端移至公用雲端時，您將面臨的主要變更之一是從資本支出（購買硬體）切換到營運支出（隨使用時付費服務）。 此參數也需要更仔細地管理您的成本。 雲端的優點是，只要在不需要時關閉或調整大小，即可從根本上和正面影響您使用的服務成本。 刻意在雲端中管理成本是最佳做法，也是成熟客戶每天執行的最佳做法。

Microsoft 提供數個工具，可協助您視覺化、追蹤及管理成本。 我們也提供一組完整的 API，可讓您自訂成本管理並將其整合到您自己的工具和儀表板中。 這些工具會鬆散地分組為Azure 入口網站功能和外部功能。

Azure 入口網站功能

這些工具可讓您立即取得成本資訊，以及採取動作的能力。

  • 訂用帳戶資源成本： 位於入口網站中， Azure 成本管理 + 計費 檢視可讓您快速查看您的成本，以及資源或資源群組每日支出的相關資訊。
  • Azure 成本管理 + 計費： 這可讓您管理和分析您的 Azure 費用，以及您在其他公用雲端提供者上花費的內容。 有免費和付費層，功能豐富。
  • Azure 預算和動作群組： 瞭解成本及執行其相關動作的專案，直到最近為止，都是手動練習。 透過引進 Azure 預算及其 API，您 現在可以建立在成本達到閾值時執行的動作 。 例如，當資源群組的耗用量達到其預算的 100% 時，您可以關閉 test 資源群組。
  • Azure Advisor： 知道什麼成本只是戰鬥的一半;另一半是知道該資訊該怎麼做。 Azure Advisor 會提供建議，以節省成本、改善可靠性，或甚至提高安全性。

外部成本管理工具

  • Power BI Azure 使用量見解： 您要為組織建立自己的視覺效果嗎？ 如果是，則 Power BI Azure 使用量見解內容套件是您選擇的工具。 使用此內容套件和 Power BI，您可以建立自訂視覺效果來代表組織、對成本進行更深入的分析，並新增其他資料來源以進一步擴充。

  • Azure 使用量 API： 除了預算、保留實例和市集費用的相關資訊之外，取 用 API 還可讓您以程式設計方式存取成本和使用量資料。 這些 API 只能供 EA 註冊和某些 Web Direct 訂用帳戶存取，不過它們可讓您將成本資料整合到您自己的工具和資料倉儲中。 您也可以 透過 Azure CLI 存取這些 API。

長期且成熟的雲端使用者客戶遵循某些最佳做法：

  • 主動監視成本。 成熟 Azure 使用者的組織會持續監視成本，並在需要時採取動作。 有些組織甚至會奉獻人員進行分析並建議使用方式的變更，而這些人比他們第一次發現一個已執行數月的未使用的 HDInsight 叢集時支付更多費用。
  • 使用 Azure 保留的 VM 實例。 管理雲端成本的另一個重要原則是針對作業使用正確的工具。 如果您有必須維持在 24x7 上的 IaaS VM，則使用保留實例可節省大量資金。 在將 VM 關機與使用保留實例自動化之間找到正確的平衡，需要經驗和分析。
  • 有效地使用自動化。 許多工作負載不需要每天執行。 每天關閉 VM 4 小時的時間，可節省您 15% 的成本。 自動化會快速自行支付費用。
  • 使用資源標籤來取得可見度。 如本檔其他地方所述，使用資源標籤可讓您更妥善地分析成本。

成本管理是公用雲端有效且有效率執行的核心專業領域。 成功的企業可以控制成本，並將其與實際需求相符，而不是過度購買和希望需求。

自動化

使用雲端提供者來區分組織成熟度的許多功能之一，就是它們已納入的自動化層級。 自動化是永不結束的程式。 當您的組織移至雲端時，這是一個您需要投資資源和時間來建置的區域。 自動化有許多用途，包括一致的資源推出（其中它直接與另一個核心 Scaffold 概念、範本和 DevOps 連結），以補救問題。 自動化會將 Azure Scaffold 的每個區域系結在一起。

數個工具可協助您建置這項功能，從第一方工具，例如Azure 自動化、事件方格和 Azure CLI，到大量的協力廠商工具，例如 Terraform、Jenkins、Chef 和 Puppet。 核心自動化工具組括Azure 自動化、事件方格和 Azure Cloud Shell。

  • Azure 自動化可讓您在 PowerShell 或 Python 中撰寫 Runbook，以自動化程式、設定資源，甚至套用修補程式。 Azure 自動化有一組廣泛的跨平臺功能，這些功能對您的部署是不可或缺的，但過於廣泛，無法在此深入討論。
  • 事件方格 是完全受控的事件路由系統，可讓您回應 Azure 環境內的事件。 就像Azure 自動化成熟雲端組織的連接組織一樣， 事件方格 是良好的自動化連接組織。 您可以使用事件方格建立簡單的無伺服器動作，在建立新資源並將該資源記錄到資料庫時，傳送電子郵件給系統管理員。 相同的事件方格可以在刪除資源並從資料庫中移除專案時通知。
  • Azure Cloud Shell 是以瀏覽器為基礎的 互動式殼層 ，可用來管理 Azure 中的資源。 它提供 PowerShell 或 Bash 的完整環境，其會視需要啟動（並為您維護），以便您有執行腳本的一致環境。 Azure Cloud Shell 可讓您存取已安裝的其他重要工具，以自動化您的環境，包括 Azure CLI 、Terraform 和越來越多的其他 工具來 管理容器、 資料庫 （sqlcmd） 等等。

自動化是一項全職工作，它很快就會成為雲端小組中最重要的作業工作之一。 採用「先自動化」方法的組織在使用 Azure 方面有更大的成功：

  • 管理成本： 主動尋求機會並建立自動化以調整資源大小、相應增加或減少，以及關閉未使用的資源。
  • 作業彈性： 透過自動化（以及範本和 DevOps），您可以獲得可增加可用性、提高安全性，並讓您的小組專注于解決商務問題。

範本和 DevOps

如先前所強調，組織的目標應該是透過原始檔控制的範本和腳本布建資源，並將環境的互動式設定降到最低。 這種「基礎結構即程式碼」方法，以及持續部署的有紀律的 DevOps 程式，可確保環境的一致性並減少漂移。 幾乎每個 Azure 資源都可以透過 Azure Resource Manager JSON 範本 與 PowerShell 或 Azure 跨平臺 CLI 和工具一起部署，例如 HashiCorp 的 Terraform，其具有一流的支援，並與 Azure Cloud Shell 整合。

使用 Azure Resource Manager 範本 的最佳做法之類的 文章，提供使用 Azure DevOps 工具鏈將 DevOps 方法套用至 Azure Resource Manager 範本 所學到的最佳做法和教訓的絕佳討論。 花一些時間和精力開發組織需求專屬的核心樣板集，並使用 DevOps 工具鏈開發持續傳遞管線（例如 Azure DevOps、Jenkins、Bamboo、TeamCity 和 Concourse），特別是生產環境與 QA 環境。 GitHub 上有一個大型的 Azure 快速入門範本 程式庫，可用來作為範本的起點，而且您可以使用 Azure DevOps 快速建立雲端式傳遞管線。

作為生產訂用帳戶或資源群組的最佳做法，您的目標應該是使用 Azure RBAC 安全性來預設不允許互動式使用者，並根據服務主體使用自動化的持續傳遞管線來布建所有資源並傳遞所有應用程式程式碼。 系統管理員或開發人員不應接觸Azure 入口網站以互動方式設定資源。 此層級的 DevOps 會採取一致的努力，並使用 Azure Scaffold 的所有概念，提供一致且更安全的環境，以符合貴組織調整的需求。

提示

設計及開發複雜的 Azure Resource Manager 範本時，請使用 連結的範本 ，從整合型 JSON 檔案組織及重構複雜的資源關聯性。 這可讓您個別管理資源，並讓您的範本更容易閱讀、可測試且可重複使用。

Azure 是超大規模雲端提供者。 當您將組織從內部部署伺服器移至雲端時，依賴雲端提供者和 SaaS 應用程式所使用的相同概念，可協助您的組織更有效率地回應業務需求。

核心網路

Azure Scaffold 參考模型的最終元件是貴組織以安全方式存取 Azure 的核心。 存取資源可以是內部（在公司網路內）或外部（透過網際網路）。 貴組織中的使用者很容易不小心將資源置於錯誤的位置，並可能讓他們面臨惡意存取。 如同內部部署裝置，企業必須新增適當的控制項，以確保 Azure 使用者做出正確的決策。 針對訂用帳戶控管，我們會識別提供基本存取控制的核心資源。 核心資源包含：

  • 虛擬網路 是子網的容器物件。 雖然並非絕對必要，但通常會在將應用程式連線到內部公司資源時使用。
  • 使用者定義的路由 可讓您操作子網內的路由表，讓您能夠透過網路虛擬裝置或對等互連虛擬網路上的遠端閘道傳送流量。
  • 虛擬網路對等互連 可讓您順暢地連線 Azure 中的兩個或多個虛擬網路，建立更複雜的中樞和輪輻設計或共用服務網路。
  • 服務端點。 過去，PaaS 服務依賴不同的方法來保護從虛擬網路存取這些資源的安全。 服務端點可讓您只 從 連線的端點保護已啟用 PaaS 服務的存取，提高整體安全性。
  • 安全性群組 是一組廣泛的規則，可讓您允許或拒絕 Azure 資源的輸入和輸出流量。 安全性群組 包含可擴增 服務標籤 的安全性規則（定義常見的 Azure 服務，例如 Azure 金鑰保存庫或 Azure SQL 資料庫）和 應用程式安全性群組 （定義和應用程式結構，例如 Web 或應用程式伺服器）。

提示

使用網路安全性群組中的服務標籤和應用程式安全性群組來：

  • 增強規則的可讀性，這對了解影響至關重要。
  • 在較大的子網內啟用有效的微分類，減少蔓延並增加彈性。

Azure 虛擬資料中心

Azure 提供來自我們廣泛合作夥伴網路的內部和協力廠商功能，為您提供有效的安全性立場。 更重要的是，Microsoft 會以 Azure 虛擬資料中心 （VDC） 的形式 提供最佳做法和指引。 當您從單一工作負載移至使用混合式功能的多個工作負載時，VDC 指引會為您提供「配方」，讓您能夠彈性且隨著 Azure 工作負載成長而成長的網路。

下一步

治理對於 Azure 的成功至關重要。 本文的目標是企業 Scaffold 的技術實作，但只會觸及元件之間的更廣泛程式和關聯性。 原則治理流程由上而下，由企業想要達成的目標決定。 當然，為 Azure 建立治理模型包含來自 IT 的代表，但更重要的是，它應該具有來自業務群組領導者的強大代表，以及安全性和風險管理。 最後，企業 Scaffold 是關於降低商務風險，以利組織的使命和目標。

既然您已瞭解訂用帳戶治理，請檢閱 Azure 整備的 最佳做法，以實際查看這些建議。