範例 1：允許子政策只覆寫標籤值範例 2：將新值附加到繼承的標籤範例 3：從繼承的標籤中移除值範例 4：限制對子政策的變更範例 5：與子控制運算子衝突範例 6：與相同階層層級上附加的值衝突

繼承範例

這些範例顯示父標籤和子標籤政策如何合併成為帳戶的有效標籤政策，以示範政策繼承的運作方式。

這些範例假設您有如下圖所示的組織結構。

範例

範例 1：允許子政策只覆寫標籤值
範例 2：將新值附加到繼承的標籤
範例 3：從繼承的標籤中移除值
範例 4：限制對子政策的變更
範例 5：與子控制運算子衝突
範例 6：與相同階層層級上附加的值衝突

範例 1：允許子政策只覆寫標籤值

下列標籤政策定義 CostCenter 標籤鍵和兩個可接受的值 (Development 和 Support)。如果您將此政策連接至組織根，則會對組織中的所有帳戶產生效果。

政策 A – 組織根標籤政策


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

假設您希望中的使用者針對金鑰OU1使用不同的標籤值，而且您希望針對特定資源類型強制執行標籤政策。因為政策 A 未指定允許哪些子控制運算子，所以允許所有運算子。您可以使用 @@assign 運算子並建立標籤政策，如下所示以連接至 OU1。

政策 B – OU1標籤政策


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Sandbox"
                ]
            },
            "enforced_for": {
                "@@assign": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

當政策 A 和政策 B 合併以形成帳戶的有效標籤政策時，為標籤指定 @@assign 運算子會執行以下操作：

政策 B 覆寫父政策 (政策 A) 中指定的兩個標籤值。結果是 Sandbox 是 CostCenter 標籤鍵的唯一合規值。
新增的 enforced_for 指定在所有 Amazon Redshift 資源和 Amazon DynamoDB 資料表上，CostCenter 標籤必須使用指定的標籤值。

如圖表所示， OU1包含兩個帳戶：111111111111 和 222222222222。

帳戶 111111111111 和 222222222222 所產生的有效標籤政策

注意

您無法直接使用顯示的有效政策的內容作為新政策的內容。語法不包括控制與其他子政策和父政策合併所需的運算子。顯示有效政策僅用於了解合併的結果。


{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Sandbox"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

範例 2：將新值附加到繼承的標籤

在某些情況下，您希望組織中的所有帳戶以簡短的可接受值清單來指定標籤鍵。對於一個 OU 中的帳戶，在建立資源時，您可能想要允許只有這些帳戶才可以指定的額外值。此範例指出如何利用 @@append 運算子來這樣做。@@append 運算子是進階功能。

與範例 1 一樣，此範例一開始也以政策 A 當作組織根標籤政策。

政策 A – 組織根標籤政策


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

在此範例中，將政策 C 連接至 OU2。此範例的差異在於，在政策 C 中使用 @@append 運算子會新增至 (而非覆寫) 可接受的值清單和 enforced_for 規則。

政策 C – 附加值的OU2標籤政策


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@append": [
                    "Marketing"
                ]
            },
            "enforced_for": {
                "@@append": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

當政策 A 和政策 C 合併以形成帳戶的有效標籤政策時，將政策 C 連接至 OU2會產生下列影響：

因為政策 C 包含 @@append 運算子，所以允許新增至 (而非覆寫) 政策 A 中指定的可接受標籤值清單。
與政策 B 一樣，新增的 enforced_for 指定在所有 Amazon Redshift 資源和 Amazon DynamoDB 資料表上，CostCenter 標籤必須做為指定的標籤值。如果父政策不含子控制運算子來限制子政策可指定的內容，則覆寫 (@@assign) 和新增 (@@append) 有相同的效果。

如圖表所示， OU2包含一個帳戶：999999999999。政策 A 和政策 C 合併，為帳戶 999999999999 建立有效的標籤政策。

帳戶 999999999999 的有效標籤政策

注意


{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Development",
                "Support",
                "Marketing"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

範例 3：從繼承的標籤中移除值

在某些情況下，連接至組織的標籤政策所定義的標籤值，可能超過您希望帳戶使用的數量。此範例說明如何使用 @@remove 運算子修訂標籤政策。@@remove 是進階功能。

與其他範例一樣，此範例一開始也以政策 A 當作組織根標籤政策。

政策 A – 組織根標籤政策


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

在此範例中，將政策 C 連接至帳戶 999999999999。

政策 D – 帳戶 999999999999 標籤政策，用於移除值


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@remove": [
                    "Development",
                    "Marketing"
                ],
                "enforced_for": {
                    "@@remove": [
                        "redshift:*",
                        "dynamodb:table"
                    ]
                }
            }
        }
    }
}

當政策 A、政策 C 和政策 D 合併形成有效的標籤政策時，將政策 D 連接至帳戶 999999999999 會產生下列效果：

假設您執行了上述所有範例，政策 B、C 和 C 是 A 的子政策。政策 B 只連接到 OU1，因此對帳戶 9999999999999 沒有影響。
對於帳戶 9999999999999，CostCenter 標籤鍵唯一可接受的值是 Support。
不強制 CostCenter 標籤鍵合規。

帳戶 999999999999 新的有效標籤政策

注意


{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Support"
            ]
        }
    }
}

如果您稍後將更多帳戶新增至 OU2，其有效的標籤政策將不同於帳戶 999999999999。這是因為更嚴格的政策 D 只在帳戶層級連接，而不是連接至 OU。

範例 4：限制對子政策的變更

在某些情況下，您可能想要限制子政策中的變更。此範例說明如何利用子控制運算子來這樣做。

此範例從新的組織根標籤政策開始，並假設標籤政策尚未連接至組織實體。

政策 E – 組織根標籤政策，用於限制子政策中的變更


{
    "tags": {
        "project": {
            "tag_key": {
                "@@operators_allowed_for_child_policies": ["@@none"],
                "@@assign": "Project"
            },
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance",
                    "Escalations"
                ]
            }
        }
    }
}

當您將政策 E 連接至組織根時，政策即可防止子政策變更 Project 標籤鍵。不過，子政策可以覆寫或附加標籤值。

假設您接著將下列政策 F 連接至 OU。

政策 F – OU 標記政策


{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "PROJECT"
            },
            "tag_value": {
                "@@append": [
                    "Escalations - research"
                ]
            }
        }
    }
}

合併政策 E 和政策 F 會對 OU 的帳戶產生下列效果：

政策 F 是政策 E 的子政策。
政策 F 試圖變更大小寫處理，但無法這樣做。這是因為政策 E 在標籤鍵中包含 "@@operators_allowed_for_child_policies": ["@@none"] 運算子。
不過，政策 F 可以為索引鍵附加標籤值。這是因為政策 E 在標籤值中包含 "@@operators_allowed_for_child_policies": ["@@append"]。

OU 中帳戶的有效政策

注意


{
    "tags": {
        "project": {
            "tag_key": "Project",
            "tag_value": [
                "Maintenance",
                "Escalations",
                "Escalations - research"
            ]
        }
    }
}

範例 5：與子控制運算子衝突

子控制運算子可以存在於組織階層中相同層級上連接的標籤政策中。在此情況下，政策合併形成帳戶的有效政策時會使用允許運算子的交集。

假設政策 G 和政策 H 連接至組織根。

政策 G – 組織根標籤政策 1


{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance"
                ]
            }
        }
    }
}

政策 H – 組織根標籤政策 2


{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
            }
        }
    }
}

在此範例中，組織根上的一個政策定義只能附加標籤鍵的值。連接至組織根的其他政策允許子政策附加和移除值。這兩個許可的交集用於子政策。結果是子政策可以附加值，但不能移除值。因此，子政策可以將值附加至標籤值清單，但無法移除 Maintenance 值。

範例 6：與相同階層層級上附加的值衝突

您可以將多個標籤政策連接至每個組織實體。當您這麼做時，連接至相同組織實體的標籤政策可能包含衝突的資訊。這些政策是根據連接至組織實體時的順序來評估。若要變更先評估哪個政策，您可以分離政策，再重新連接。

假設政策 J 最先連接至組織根，然後政策 K 才連接至組織根。

政策 J – 連接至組織根的第一個標籤政策


{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "PROJECT"
            },
            "tag_value": {
                "@@append": ["Maintenance"]
            }
        }
    }
}

政策 K – 連接至組織根的第二個標籤政策


{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "project"
            }
        }
    }
}

在此範例中，有效的標籤政策中會使用標籤鍵 PROJECT，因為定義此標籤鍵的政策最先連接至組織根。

政策 JK – 帳戶的有效標籤政策

帳戶的有效政策如下。

注意


{
    "tags": {
        "project": {
            "tag_key": "PROJECT",
            "tag_value": [
                "Maintenance"
            ]
        }
    }
}

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

繼承運算子

檢視有效政策