翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

継承の例

これらの例は、親タグポリシーと子タグポリシーがマージされてアカウントの有効なタグポリシーになるのを示すことにより、ポリシーの継承がどのように機能するかを示しています。

この例では、次の図に示す組織構造があることを前提としています。

例 1: 子ポリシーによるタグ値のみの上書きを許可する

次のタグポリシーは、CostCenter タグキーと 2 つの許容値 (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"
                ]
            }
        }
    }
}

タグの @@assign 演算子を指定すると、ポリシー A とポリシー B が統合されてアカウントの有効なタグポリシーが形成された場合に、以下のようになります。

図に示すように、 には 111111111111 と 222222222222 の 2 つのアカウントOU1が含まれています。

アカウント 111111111111 および 222222222222 に対して有効な、結果として生じるタグポリシー

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

例 2: 継承されたタグに新しい値を追加する

組織内のすべてのアカウントで、許容値の短いリストでタグキーを指定する必要がある場合が考えられます。1 つの 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 OU2がマージしてアカウントの有効なタグポリシーを形成すると、ポリシー C を にアタッチすると次の効果があります。

図に示すように、 には 1 つのアカウント 999999999999 OU2が含まれます。ポリシー 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"
                ]
            }
        }
    }
}

この例では、ポリシー D をアカウント 999999999999 にアタッチします。

ポリシー D － 値を削除するためのアカウント 999999999999 のタグポリシー

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

ポリシー D をアカウント 999999999999 にアタッチすると、ポリシー A、ポリシー C、およびポリシー D をマージして有効なタグポリシーを形成した時点で、次の効果があります。

アカウント 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 のアカウントに次のような影響があります。

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"]
            }
        }
    }
}

この例では、組織ルートの 1 つのポリシーで、タグキーの値のみを追加できるということが定義されています。組織ルートにアタッチされたもう 1 つのポリシーは、子ポリシーが値の追加と削除の両方を行うことを許可します。これら 2 つのアクセス許可の共通部分が子ポリシーに使用されます。その結果、子ポリシーは値を追加できますが、値は削除できません。したがって、子ポリシーはタグ値のリストに値を追加できますが、Maintenance の値を削除することはできません。

例 6: 同じ階層レベルで値を追加した場合の競合

各組織エンティティに複数のタグポリシーをアタッチできます。これを行うと、同じ組織エンティティにアタッチされているタグポリシーに競合する情報が含まれる場合があります。ポリシーは、組織エンティティにアタッチされた順序に基づいて評価されます。最初に評価されるポリシーを変更するには、ポリシーをデタッチしてから再度アタッチします。

ポリシー J が最初に組織ルートにアタッチされ、その次にポリシー K が組織ルートにアタッチされると仮定します。

ポリシー J － 組織ルートにアタッチされた最初のタグポリシー

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

ポリシー K － 組織ルートにアタッチされた 2 番目のタグポリシー

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

この例では、PROJECT タグキーを定義したポリシーが最初に組織ルートにアタッチされたため、このタグキーが有効なタグポリシーで使用されます。

ポリシー JK － アカウントの有効なタグポリシー

アカウントの有効なポリシーは次のようになります。

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