Azure Well-Architected Framework 檢視 Azure Blob 記憶體
Azure Blob 儲存是 Microsoft 用於雲端的物件儲存解決方案。 Blob 記憶體已優化，可儲存大量的非結構化數據。 非結構化數據是不符合特定數據模型或定義的數據，例如文字或二進位數據。
本文假設身為架構設計人員，您已檢閱 記憶體選項， 並選擇 [Blob 記憶體] 作為執行工作負載的記憶體服務。 本文中的指引提供架構建議，這些建議會對應至 Azure Well-Architected Framework 的
重要
如何使用本指南
每個區段都有一個 設計檢查清單，，裡面列出了需要關注的架構領域以及相應的設計策略。
此外，也包括 建議， 可協助實作這些策略的技術功能。 建議並不代表 Blob 儲存及其相依性可用之所有組態的完整清單。 相反地，他們會列出對應至設計觀點的主要建議。 使用建議來建置概念證明或優化現有的環境。
可靠性
可靠性支柱的目的是藉由 建置足夠的復原能力，以及從失敗快速復原的能力，來提供持續的功能。
可靠性設計原則 提供適用於個別元件、系統流程和整個系統的高階設計策略。
設計檢查清單
根據可靠性的
使用失敗模式分析：考慮內部相依性，例如虛擬網路、Azure Key Vault 或 Azure 內容傳遞網路或 Azure Front Door 端點的可用性，將失敗點降到最低。 如果用於工作負載存取 Blob 儲存體的認證從 Key Vault 中遺漏，或如果工作負載使用的端點是基於已被移除的內容傳遞網路，就會發生失敗。 在這些情況下，工作負載可能需要使用替代端點進行連線。 如需失敗模式分析的一般資訊，請參閱 執行失敗模式分析的建議。
定義可靠性與復原目標：檢閱 Azure 服務等級協定 （SLA）。 制定儲存體帳戶的服務等級目標 (SLO)。 例如，SLO 可能會受到您選擇的備援組態影響。 請考慮區域性中斷、數據遺失的可能性，以及中斷后還原存取所需的時間。 也請考慮您在失敗模式分析中識別的任何內部相依性的可用性。
設定數據備援：如需最大持久性，請選擇跨可用性區域或全域區域複製數據的設定。 如需最大可用性，請選擇可讓用戶端在主要區域中斷期間從次要區域讀取數據的組態。
設計應用程式：設計應用程式，使其在主要區域因任何原因無法使用時，能夠順暢地從次要區域讀取資料。 這隻適用於異地備援記憶體 （GRS） 和異地區域備援記憶體 （GZRS） 組態。 設計應用程式來處理中斷，可減少終端使用者的停機時間。
探索功能，以協助您達成復原目標：讓 Blob 可還原，以便在 Blob 因損毀、誤編輯或誤刪除時加以復原。
建立復原方案：請考慮數據保護功能、備份和還原作業或故障轉移程式。 準備潛在的
數據遺失和數據不一致 以及故障轉移的時間和成本。 如需詳細資訊，請參閱 設計災害復原策略的建議。 監控潛在的可用性問題：訂閱 Azure Service Health 儀錶板，以便監控潛在的可用性問題。 使用 Azure 監視器和診斷記錄中的記憶體計量來調查警示。
建議
| 建議 | 效益 |
|---|---|
| 設定您的帳戶來實現冗餘。 如需最大可用性和持久性，請使用 區域備援記憶體 （ZRS） 或 GZRS來設定您的帳戶。 |
備援可保護您的數據免於發生非預期的失敗。 ZRS 和 GZRS 設定選項會在不同的可用性區域進行資料複製，並讓應用程式在中斷期間能繼續讀取資料。 如需詳細資訊，請參閱 持久性和可用性中斷案例 和 持久性和可用性參數。 |
| 在執行故障轉移或故障恢復之前，通過檢查 上次同步處理時間 屬性的值，評估數據遺失的可能性。 此建議僅適用於 GRS 和 GZRS 設定。 | 此屬性可協助您藉由起始帳戶故障轉移來預估可能遺失的數據量。 在上次同步處理時間之前寫入的所有數據和元數據都可在次要區域上使用，但上次同步處理時間之後寫入的數據和元數據可能會遺失，因為它不會寫入次要區域。 |
| 在您的備份和復原策略中，啟用 容器軟刪除、Blob 軟刪除、版本控制以及 時間點還原 選項。 | 儲存體帳戶的軟刪除選項能夠讓已刪除的容器和 Blob 復原。 版本設定選項會自動追蹤對 Blob 所做的變更。 此選項可讓您將 Blob 還原至先前的狀態。 時間點還原選項可防止意外刪除或損毀 Blob，並可讓您將區塊 Blob 數據還原到先前的狀態。 如需詳細資訊，請參閱 資料保護概觀。 |
| 將 Azure Blob 的保存庫備份 設定為備份策略的一部分。 | 保存庫備份可讓您保護區塊 Blob 資料免於勒索軟體、其他惡意攻擊或源數據遺失。 數據會複製並儲存在備份保存庫中（異地數據復本），最多可保留 10 年。 如果來源帳戶發生任何數據遺失，您可以觸發還原至替代帳戶並取得數據的存取權。 深入瞭解 Azure 備份支援保存庫備份的可支援性 |
安全
安全性要素的目的是為工作負載提供 機密性、完整性和可用性 保證。
安全性設計原則 藉由將方法套用至 Blob 記憶體組態的技術設計，為達成這些目標提供高階的設計策略。
設計檢查清單
根據安全性的
檢閱 Azure 記憶體的安全性基準：若要開始使用，請先 檢閱記憶體的安全性基準。
使用網路控制來限制輸入和輸出流量：停用記憶體帳戶的所有公用流量。 使用帳戶網路控制來授與用戶和應用程式所需的最低存取層級。 如需詳細資訊，請參閱 如何處理記憶體帳戶的網路安全性。
減少受攻擊面：防止匿名存取、帳戶密鑰存取或透過非安全 （HTTP） 連線存取，可以減少受攻擊面。 要求用戶端使用最新版的傳輸層安全性 （TLS） 通訊協議來傳送和接收數據。
授權存取而不使用密碼或密鑰：Microsoft Entra ID 相較於共用密鑰和共用存取簽章，提供更高的安全性和易於使用性。 只授與安全性主體執行其工作所需的許可權。
保護敏感性資訊：保護敏感性資訊，例如帳戶密鑰和共用存取簽章令牌。 雖然通常不建議使用這些形式的授權，但您應該務必輪替它們，設置到期時間，並安全地儲存。
啟用安全傳輸必要選項：針對所有記憶體帳戶啟用此設定可確保對記憶體帳戶發出的所有要求都必須透過安全連線進行。 透過 HTTP 發出的任何要求都失敗。
保護重要物件：套用 不變性原則 來保護重要物件。 政策會保護儲存用於法律、合規性或其他商業用途的 Blob，以防其被修改或刪除。 設置保留時段，或直到系統管理員解除限制為止。
偵測威脅：啟用 Microsoft Defender for Storage 來偵測威脅。 當活動異常發生時，就會觸發安全性警示。 警示會透過電子郵件通知訂用帳戶管理員，其中包含可疑活動的詳細數據，以及有關如何調查和補救威脅的建議。
建議
| 建議 | 效益 |
|---|---|
| 停用容器和 Blob 的匿名讀取權限。 | 當記憶體帳戶允許匿名存取時，具有適當許可權的使用者可以修改容器的匿名存取設定，以啟用該容器中數據的匿名存取。 |
| 在記憶體帳戶上套用 Azure Resource Manager 鎖定。 | 鎖定帳戶可防止它遭到刪除，並導致數據遺失。 |
| 停用記憶體帳戶 公用端點的流量。 為在 Azure 中執行的用戶端建立 私人端點。 只有在 Azure 外部的用戶端和服務需要直接存取記憶體帳戶時，才啟用公用端點。 啟用防火牆規則，限制對特定虛擬網路的存取。 | 從零存取開始，然後以累加方式授權客戶端和服務所需的最低存取層級，以將為攻擊者建立不必要的開啟風險降到最低。 |
| 使用 Azure 角色型存取控制 （RBAC） 授權存取權。 | 使用 RBAC 時，沒有任何密碼或金鑰可能會遭到入侵。 安全性主體（使用者、群組、受控識別或服務主體）會由 Microsoft Entra ID 驗證，然後傳回 OAuth 2.0 令牌。 令牌是用來授權對 Blob 記憶體服務的要求。 |
| 不允許共享金鑰授權。 這不僅會停用帳戶密鑰存取，也會停用服務和帳戶共用存取簽章令牌，因為它們是以帳戶密鑰為基礎。 | 只有使用 Microsoft Entra ID 授權的安全請求才被允許。 |
| 我們建議您不要使用帳戶密鑰。 如果您必須使用帳戶密鑰，則 將它們儲存在 Key Vault中，並確定您定期重新產生金鑰。 | Key Vault 可讓您在運行時間擷取密鑰，而不是使用您的應用程式加以儲存。 Key Vault 也可讓您輕鬆地輪替密鑰，而不會中斷應用程式。 定期輪替帳戶密鑰可降低將數據公開至惡意攻擊的風險。 |
| 我們建議您不要使用共用存取簽章令牌。 評估您是否需要共用存取簽章令牌，以保護 Blob 記憶體資源的存取。 在建立和散發共用存取簽章之前，若您必須建立一個，請先檢閱此清單：共用存取簽章最佳做法。 | 最佳做法可協助您防止共用存取簽章令牌流失，並在發生外泄時快速復原。 |
| 設定記憶體帳戶，讓用戶端可以使用 TLS 1.2 的最低版本來傳送和接收數據。 | TLS 1.2 比不支援新式密碼編譯演算法和加密套件的 TLS 1.0 和 1.1 更安全且更快。 |
| 請考慮使用您自己的加密金鑰來保護記憶體帳戶中的資料。 如需詳細資訊，請參閱 客戶管理的 Azure 記憶體加密金鑰。 | 客戶管理的金鑰可提供更大的彈性和控制。 例如，您可以將加密金鑰儲存在 Key Vault 中，並自動輪替它們。 |
成本優化
成本優化著重於 偵測支出模式、將投資放在重要領域，以及優化其他，以符合組織的預算和商務需求。
成本優化設計原則 提供高階設計策略，以達成這些目標，並在與 Blob 記憶體及其環境相關的技術設計中視需要進行取捨。
設計檢查清單
根據投資成本優化
識別用來計算帳單的計量：計量可用來追蹤儲存在帳戶中的數據量（數據容量）以及用來寫入和讀取數據的作業數目和類型。 也有與使用選擇性功能相關聯的計量，例如 Blob 索引標籤、Blob 清查、變更摘要支援、加密範圍，以及 SSH 檔案傳輸通訊協定 （SFTP） 支援。 如需詳細資訊，請參閱 Blob 儲存的收費方式。
瞭解每個計量的價格：請務必使用適當的定價頁面，並在該頁面中套用適當的設定。 如需更多訊息，請參閱 查找每米的單價。 請考慮與每個價格相關聯的操作數目。 例如，與寫入和讀取作業相關聯的價格適用於每10,000次作業。 若要判斷個別作業的價格，請將列出的價格除以 10,000。
估計容量和作業的成本：您可以使用 Azure 定價計算機，將與數據記憶體、輸入和輸出相關聯的成本模型化。 使用字段來比較與各種區域、帳戶類型、命名空間類型和備援組態相關聯的成本。 在某些情況下，您可以使用Microsoft檔中提供的範例計算和工作表。 例如，您可以 估計封存數據的成本，或 使用 AzCopy 命令來傳輸 blob的成本。
選擇容量的計費模型：評估使用 承諾型模型 是否比使用以耗用量為基礎的模型更有成本效益。 如果您不確定您需要多少容量，您可以從以耗用量為基礎的模型開始，監視容量計量，然後稍後進行評估。
選擇帳戶類型、備援層級和預設存取層：建立記憶體帳戶時，您必須為每個設定選取一個值。 所有值都會影響交易費用和容量費用。 除了帳戶類型之外，所有這些設定都可以在帳戶建立之後變更。
選擇最符合成本效益的預設存取層：除非每個 Blob 上傳時都指定層級，否則 Blob 會依據預設存取層設定推斷其層級。 變更儲存體帳戶預設存取層設定會套用至尚未明確設定存取層的帳戶內所有 Blob。 如果您已收集大量 blob，則此成本可能相當可觀。 如需階層變更如何影響每個現有 Blob 的詳細資訊，請參閱 變更 blob 的存取層。
將數據直接上傳至最符合成本效益的存取層：例如，如果您帳戶的預設存取層設定為熱層，但您上傳檔案以供封存之用，請將檔案上傳作業指定到較冷的冷層或封存層。 上傳 Blob 之後，請使用生命週期管理原則，根據使用量計量，例如上次存取時間，將 Blob 移至最符合成本效益的層。 選擇最理想的層級可以降低成本。 如果您變更已上傳的 Blob 資料塊層，則在您首次上傳 Blob 時，需支付寫入至初始層的成本，接著還需支付寫入至所需層的成本。
規劃管理數據生命週期：利用存取層和生命週期管理來優化交易和容量成本。 較不常使用的數據應該放在較冷的存取層中，而經常存取的數據應該放在較暖的存取層中。
決定您需要的功能：某些功能，例如版本控制和 Blob 軟刪除，會產生額外的交易和容量成本以及其他費用。 請務必檢閱文章中的定價和計費區段，這些區段會在您選擇要新增至帳戶的功能時描述這些功能。
例如，如果您啟用 Blob 清查功能，則會針對掃描的物件數目計費。 如果您使用 Blob 索引標籤，則會根據索引標籤的數量向您收取費用。 如果您啟用 SFTP 支援，則即使沒有 SFTP 傳輸，您仍需支付每小時費用。 如果您決定不使用某個功能，請確認該功能已被停用，因為當您建立帳戶時，可能會自動啟用某些功能。
建立護欄 ：根據訂用帳戶和資源群組 建立預算。 使用治理原則來限制資源類型、組態和位置。 此外，使用 RBAC 來封鎖可能導致超支的動作。 監視成本：確保成本保持在預算內、比較成本與預測，並查看發生超支的位置。 您可以使用 Azure 入口網站中的 [成本分析] 窗格來監視成本。 您也可以將成本數據匯出至記憶體帳戶，並使用 Excel 或 Power BI 分析該數據。
監視使用量：持續監視使用模式，並偵測未使用或使用量過低的帳戶和容器。 使用 儲存洞察 來識別沒有或使用量低的帳戶。 啟用 Blob 清查報告，並使用 Azure Databricks 或 Azure Synapse Analytics 和 Power BI 等工具來分析成本數據。 請注意容量的意外增加，這可能表示您正在收集許多日誌檔案、Blob 版本或已軟刪除的 Blob。 制定過期或轉移物件至更具成本效益的存取層的策略。規劃過期的物件或將物件轉移到更便宜的存取層。
建議
| 建議 | 效益 |
|---|---|
| 將小型檔案封裝成較大的檔案，，再將其移至較冷層。 您可以使用 TAR 或 ZIP 等檔案格式。 | 較冷層的數據傳輸成本較高。 藉由擁有較少的大型檔案，您可以減少傳輸數據所需的作業數目。 |
| 從封存記憶體重新凍結 Blob 時，請使用標準優先順序的解除凍結。 僅針對緊急數據還原情況使用高優先順序解除凍結。 如需詳細資訊，請參閱 將封存的 Blob 解除凍結至在線層 | 封存層的高優先順序解除凍結可能會導致高於一般帳單。 |
| 藉由選擇適當的記錄記憶體位置，以及管理記錄保留期間，降低使用資源記錄的成本。 如果您只打算偶爾查詢記錄（例如，查詢記錄以進行合規性稽核），請考慮將資源記錄傳送至記憶體帳戶，而不是將它們傳送至 Azure 監視器記錄工作區。 您可以使用無伺服器查詢解決方案，例如 Azure Synapse Analytics 來分析記錄。 如需詳細資訊，請參閱 針對不常查詢優化成本。 使用生命週期管理原則來刪除或封存記錄。 | 將資源記錄儲存在記憶體帳戶中以供稍後分析可能是更便宜的選項。 使用生命週期管理原則來管理儲存體帳戶中的日誌保留，可防止隨著時間累積大量的日誌文件，這可能會導致不必要的容量費用。 |
| 如果您啟用版本控制，請使用生命週期管理原則來自動刪除舊的 Blob 版本。 | 對 Blob 的每個寫入作業都會建立新版本。 這會增加容量成本。 您可以移除不再需要的版本來控制成本。 |
| 如果您啟用版本控制，則應將經常覆寫的 Blob 放進沒有啟用版本控制的帳戶中。 | 每次覆寫 Blob 時，都會新增一個新版本，進而增加儲存容量費用。 若要降低容量費用，請將經常覆寫的數據儲存在已停用版本設定的個別記憶體帳戶中。 |
| 如果您啟用軟刪除，請將經常覆寫的 Blob 放在未啟用軟刪除的帳戶中。 設定保留期間。 請考慮從短期保留期間開始，以進一步瞭解此功能如何影響您的帳單。 建議的最小保留期限為七天。 | 每次覆寫 Blob 時，都會建立新的快照。 容量費用增加的原因可能難以查明，因為這些快照的建立不會出現在日誌中。 若要降低容量費用，請將經常覆寫的數據儲存在已停用虛刪除的個別記憶體帳戶中。 保留期間可防止虛刪除的 Blob 堆積，從而減少容量成本的增加。 |
| 只有在用來傳輸數據時，才啟用SFTP支援。 | 啟用SFTP端點會產生每小時成本。 藉由深思熟慮地停用 SFTP 支援，然後視需要啟用它，您可以避免被動費用在您的帳戶中累積。 |
| 停用任何不需要的加密範圍，以避免不必要的費用。 | 加密範圍會產生每月費用。 |
營運卓越績效
卓越營運主要著重於 開發實務、可觀察性和發行管理。
營運卓越設計原則 提供高階設計策略，以達成工作負載作業需求的目標。
設計檢查清單
根據 設計檢查清單建立您的設計策略，以達成卓越運營，並定義與 Blob 儲存體配置相關的可觀測性、測試和部署程序。
建立維護和緊急復原計劃：請考慮數據保護功能、備份和還原作業，以及故障轉移程式。 準備面對潛在的
數據遺失、 數據不一致，以及故障轉移的時間和成本。 監視儲存帳戶的健康情況：建立 存儲深入解析 儀錶板來監控可用性、效能和復原能力指標。 設定警示，以在客戶注意到問題之前，先識別並解決系統中的問題。 使用診斷設定將資源記錄路由傳送至 Azure Monitor 日誌工作區。 然後您可以查詢記錄，以更深入地調查警示。
啟用 blob 清查報告：啟用 Blob 清查報告，以檢閱記憶體帳戶內容的保留、法律保留或加密狀態。 您也可以使用 Blob 清查報告來了解資料的總大小、存留期、階層分佈或其他數據屬性。 使用 Azure Databricks 或 Azure Synapse Analytics 以及 Power BI 等工具，以更清楚地可視化庫存數據，並為利害關係人建立報告。
設定政策，以刪除 Blob，或將它們移至具成本效益的存取層：建立一個具備初始條件集的生命週期管理原則。 根據您定義的條件，政策執行會自動刪除 Blob 或設定其存取層級。 使用監控指標和 Blob 清單報告定期分析容器使用情況，以便調整條件以優化成本效益。
建議
| 建議 | 好處 |
|---|---|
| 使用基礎結構即程序代碼 （IaC） 在 Azure Resource Manager 範本 （ARM 範本）、Bicep或 Terraform中定義記憶體帳戶的詳細數據。 | 您可以使用現有的 DevOps 程式來部署新的記憶體帳戶，並使用 Azure 原則 來強制執行其設定。 |
| 使用儲存體洞察來追蹤儲存帳戶的健康情況和效能。 儲存體分析提供有關所有儲存體帳戶的失敗、效能、可用性和容量的統一視圖。 | 您可以追蹤每個帳戶的健康情況和作業。 輕鬆建立儀錶板和報表，利害關係人可用來追蹤儲存帳戶的狀態。 |
效能效率
效能效率與 維護用戶體驗有關，即使藉由管理容量來增加負載 也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。
效能效率設計原則 提供針對預期使用量達成這些容量目標的高階設計策略。
設計檢查清單
根據效能效率的
規劃規模：瞭解儲存體帳戶的規模目標。
選擇最佳的記憶體帳戶類型：如果您的工作負載需要高交易速率、較小的物件，以及一致的低交易延遲，請考慮使用進階區塊 Blob 儲存器帳戶。 在大部分情況下，標準一般用途 v2 帳戶最適合使用。
減少客戶端與伺服器之間的移動距離：將數據放在最接近連接客戶端的區域（在相同區域中理想情況下）。 使用物件復寫或內容傳遞網路，針對遠離區域的用戶端進行優化。 默認網路組態提供最佳效能。 僅修改網路設定以改善安全性。 一般而言，網路設定不會降低行進距離，也不會改善效能。
選擇有效率的命名配置：使用最接近 Blob 數據分割索引鍵開頭的哈希標籤前置詞來減少清單、清單、查詢和讀取作業的延遲（帳戶、容器、虛擬目錄或 Blob 名稱）。 此方案的受益者主要是擁有平面命名空間的帳戶。
優化數據用戶端的效能：選擇最適合您工作負載之數據大小、傳輸頻率和頻寬的數據傳輸工具。 某些工具，例如 AzCopy 已針對效能優化，而且不需要介入。 檢閱每個工具發行的效能優化指引，以考慮影響延遲的
因素，並微調效能。 優化自定義程式碼的效能：請考慮使用記憶體 SDK，而不是為 Blob REST 作業建立您自己的包裝函式。 Azure SDK 已針對效能進行優化，並提供微調效能的機制。 建立應用程式之前，請檢閱 Blob 記憶體的
效能和延展性檢查清單。 請考慮在記憶體要求期間使用 查詢加速 來篩選掉不必要的數據，並讓客戶端無法不必要地透過網路傳輸數據。 收集效能數據：監視儲存帳戶，以找出由於節流而產生的效能瓶頸。 如需詳細資訊，請參閱 使用 Monitor 儲存洞察監控您的儲存服務。 同時使用計量和記錄。 計量會提供數位，例如節流錯誤。 記錄描述活動。 如果您看到節流計量，您可以使用記錄來識別哪些用戶端正在接收節流錯誤。 如需詳細資訊，請參閱 稽核數據平面作業。
建議
| 建議 | 效益 |
|---|---|
| 在放置相依資源的相同區域中布建記憶體帳戶。 針對未載入在 Azure 上的應用程式，例如行動裝置應用程式或內部部署企業服務，請在接近這些客戶端的區域中找到記憶體帳戶。 如需詳細資訊，請參閱 Azure 地理位置。 如果來自不同區域的用戶端不需要相同的數據，請在每個區域中建立個別的帳戶。 如果來自不同區域的用戶端只需要一些數據，請考慮使用對象複寫原則，以異步方式將相關物件複製到另一個區域中的記憶體帳戶。 |
減少記憶體帳戶與 VM、服務和內部部署用戶端之間的實體距離，可以改善效能並減少網路等待時間。 減少實體距離也會降低裝載在 Azure 中的應用程式成本，因為單一區域內的頻寬使用量是免費的。 |
| 若要將串流視訊、音訊或靜態網站內容廣泛提供給網路用戶端，請考慮使用 Azure Front Door 提供的內容傳遞網路。 | 內容經由 Microsoft 的全球邊緣網路更快速地傳遞至客戶端，因為它在世界各地擁有數以百計的全球及本地節點。 |
| 儘快在 Blob 的數據分割索引鍵中新增哈希字元序列（例如三位數）。 分割區索引鍵是帳戶名稱、容器名稱、虛擬目錄名稱和 Blob 名稱。 如果您打算在名稱中使用時間戳，請考慮在該戳記的開頭加上秒值。 如需詳細資訊，請參閱 分區。 | 使用最接近分區鍵開頭的哈希碼或秒數值有助於減少列出查詢和讀取 Blob 所需的時間。 |
| 上傳 Blob 或區塊時，請使用大於 256 KiB 的 Blob 或區塊大小。 | 超過 256 KiB 的 Blob 或區塊大小能夠獲得平臺中專為較大 Blob 和區塊大小設計的效能提升功能。 |
Azure 原則
Azure 提供一組與 Blob 記憶體及其相依性相關的大量內建原則。 您可以透過 Azure 原則稽核上述一些建議。 例如，您可以檢查是否：
- 未啟用容器和 Blob 物件的匿名公共讀取存取。
- Blob 記憶體的診斷設定會設定為將資源記錄串流至 Azure 監視器記錄工作區。
- 只接受來自安全連線 （HTTPS） 的要求。
- 已啟用共用存取簽章到期原則。
- 跨租戶物件複寫已停用。
- 共用金鑰授權已停用。
- 網路防火牆規則會套用至帳戶。
如需全面治理，請檢閱記憶體 和其他可能會影響計算層安全性的 Azure 原則內建定義
Azure Advisor 建議
Azure Advisor 是個人化雲端顧問，可協助您遵循最佳做法來優化 Azure 部署。 以下是一些建議，可協助您改善 Blob 記憶體的可靠性、安全性、成本效益、效能和營運卓越。
下一步
如需 Blob 記憶體的詳細資訊，請參閱 Blob 記憶體檔。