升級推展政策語法和範例 - AWS Organizations
考量事項基本政策結構政策元件升級推展政策範例

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

升級推展政策語法和範例

升級推展政策定義 AWS 服務如何將自動升級套用至您的 資源。了解政策語法可協助您建立符合組織升級需求的有效政策。

考量事項

實作升級推展政策時，請考慮下列重要因素：

  • 政策名稱在您的組織中必須是唯一的，並且應該是清晰且描述性的。選擇反映政策目的和範圍的名稱。如需詳細資訊，請參閱最佳化營運效率。

  • 在廣泛部署之前，測試至關重要。首先驗證非生產環境中的新政策，並逐步擴展以確保所需的行為。如需詳細資訊，請參閱從小開始並逐漸擴展。

  • 政策變更可能需要幾個小時才能在您的組織中傳播。據以規劃您的實作，並確保有適當的監控。如需詳細資訊，請參閱監控和傳達變更。

  • JSON 格式必須是有效的，並保持在 5，120 個位元組的最大政策大小內。盡可能簡化政策結構，同時滿足您的需求。

  • 定期政策審查有助於維持有效性。排程政策的定期評估，以確保政策持續滿足您的組織需求。如需詳細資訊，請參閱建立審核程序。

  • 沒有指派升級順序的資源預設為「秒」順序。考慮明確設定關鍵資源的升級訂單，而不是依賴預設值。如需詳細資訊，請參閱有效驗證政策變更。

  • 手動升級優先於政策定義的升級訂單。確保您的變更管理程序同時考慮自動和手動升級案例。如需詳細資訊，請參閱建立審核程序。

注意

從管理帳戶實作標籤型升級推展政策時，請注意管理帳戶無法直接檢視或存取成員帳戶中的資源層級標籤。我們建議建立成員帳戶套用一致資源標籤的程序，然後建立參考這些標籤的組織層級政策。這可確保資源層級標記和組織政策強制執行之間的適當協調。您也可以使用 標籤政策 在跨組織標記資源時，協助維持一致的標籤。

基本政策結構

升級推展政策使用包含下列主要元素的 JSON 結構：

  • 政策中繼資料 （例如版本資訊）

  • 資源目標規則

  • 升級訂單規格

  • 選用例外狀況訊息

  • 服務特定的屬性

下列範例顯示基本升級推展政策結構：

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}

政策元件

升級推展政策由兩個關鍵元件組成，這些元件可共同運作，以控制如何跨資源套用升級。這些元件包含預設行為和標籤型覆寫的組態選項。了解這些元件的互動方式可協助您建立符合組織需求的有效政策。

預設修補程式順序設定

當您建立升級推展政策而不指定任何資源特定的覆寫時，所有資源都會預設為基本升級順序。您可以使用政策中的「預設」欄位來設定此預設值。沒有透過標籤明確升級順序指派的資源將遵循此預設順序。

注意

今天主控台體驗需要指定預設順序。

下列範例顯示如何將所有資源設定為在預設情況下持續接收升級，除非被標籤覆寫。當您想要在升級週期稍後確保大多數資源更新時，此方法非常有用：

"upgrade_rollout": {
    "default": {
        "patch_order": "last"
    }
}

透過標籤覆寫資源層級

您可以使用標籤覆寫特定資源的預設升級順序。這可讓您建立精細控制哪些資源會依順序接收升級。例如，您可以根據您的環境類型、開發階段或工作負載重要性來指派不同的升級訂單。

下列範例示範如何設定開發資源，先接收升級，最後接收生產資源。此組態可確保您的開發環境可以在達到生產環境之前驗證升級：

"upgrade_rollout": {
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                },
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}

升級推展政策範例

以下是常見的升級推展政策案例：

範例 1：開發環境優先

此範例示範如何設定開發環境中的資源，以先接收升級。透過以具有「開發」環境標籤的資源為目標，您可以確保開發環境是第一個接收和驗證新升級的環境。此模式有助於在升級到達更關鍵的環境之前識別潛在問題：

{
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "upgrade_order": "first"
                }
            }
        }
    }
}

範例 2：生產環境最後

此範例示範如何確保您的生產環境持續收到升級。透過將生產標記的資源明確設定為上次升級順序，您可以在生產環境中維持穩定性，同時在生產前環境中進行適當的測試。此方法對於具有嚴格變更管理要求的組織特別有用：

{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "upgrade_order": "last"
                }
            }
        }
    }
}

範例 3：使用標籤的多個升級訂單

下列範例示範如何使用具有不同值的單一標籤金鑰來指定所有三個升級訂單。當您想要透過單一標記機制管理升級訂單時，此方法非常有用：

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}