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

태그에 대해 @@assign 연산자를 지정하면 정책 A와 정책 B가 병합되어 계정의 유효 태그 정책을 형성할 때 다음이 수행됩니다.

정책 B는 상위 정책에서 지정된 두 개의 태그 값을 덮어씁니다. 따라서 Sandbox는 CostCenter 태그 키의 유일한 정책 준수 값입니다.
enforced_for를 추가하면 CostCenter 태그가 모든 Amazon Redshift 리소스와 Amazon DynamoDB 테이블에서 지정된 태그 값을 사용해야 합니다.

그림과 같이 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"
                ]
            }
        }
    }
}

정책 C를 OU2에 연결하면 정책 A와 정책 C가 병합되어 계정의 유효 태그 정책을 형성할 때 다음과 같은 효과가 발생합니다.

정책 C에는 @@append 연산자가 포함되어 있으므로 이 정책은 정책 A에서 지정된 허용 가능한 태그 값의 목록을 덮어쓰지 않고 이 목록에 값을 추가하도록 허용 합니다.
정책 B와 같이, enforced_for를 추가하면 CostCenter 태그가 모든 Amazon Redshift 리소스와 Amazon DynamoDB 테이블에서 지정된 태그 값으로 사용되어야 합니다. 상위 정책에 하위 정책이 지정할 수 있는 항목을 제한하는 하위 제어 연산자가 포함되지 않으면 덮어쓰기(@@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"
                ]
            }
        }
    }
}

이 예제에서는 계정 999999999999에 정책 D를 연결합니다.

정책 D - 값을 제거하는 계정 999999999999 태그 정책


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

정책 D를 계정 999999999999에 연결하면 정책 A, 정책 C 및 정책 D가 병합되어 유효 태그 정책을 형성할 때 다음과 같은 효과가 발생합니다.

이전의 예제를 모두 수행했다고 가정하면 정책 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 태그 키를 변경할 수 없습니다. 하지만 하위 정책은 태그 값을 덮어쓰거나 추가할 수 있습니다.

그런 다음 OU에 다음과 같은 정책 F를 연결한다고 가정합니다.

정책 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가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

상속 연산자

AI 서비스 옵트아웃 정책