AWS Organizations 용어 및 개념
이 주제에서는 AWS Organizations의 몇 가지 주요 개념을 설명합니다.
다음 다이어그램은 루트 아래에 4가지 조직 단위(OU)로 구분되는 계정 5개로 구성된 조직을 보여줍니다. 또 조직에는 일부 OU에 연결되거나 계정에 직접 적용되는 다양한 정책이 있습니다.
각 항목에 대한 설명은 이번 주제에 나오는 정의를 참조하세요.
사용 가능한 기능 모음
- 모든 기능(권장)
-
모든 기능은 AWS Organizations에서 사용할 수 있는 기본 기능 세트입니다. 전체 조직에 대한 중앙 정책 및 구성 요구 사항을 설정하고, 조직 내에서 사용자 지정 권한 또는 기능을 생성하고, 단일 청구서로 계정을 관리 및 구성하고, 조직을 대신하여 다른 계정에 책임을 위임할 수 있습니다. 다른 AWS 서비스와의 통합을 사용하여 조직의 모든 멤버 계정에서 중앙 구성, 보안 메커니즘, 감사 요구 사항 및 리소스 공유를 정의할 수도 있습니다. 자세한 내용은 다른 AWS 서비스와 함께 AWS Organizations 사용 단원을 참조하십시오.
모든 기능 모드는 관리 기능과 함께 통합 결제의 모든 기능을 제공합니다.
- Consolidated billing
-
통합 결제는 공유 결제 기능을 제공하지만 AWS Organizations의 추가적인 고급 기능은 포함하지 않는 기능 세트입니다. 예를 들어 조직에 통합할 다른 AWS 서비스를 모든 계정에서 작동하도록 하거나, 정책을 사용하여 다른 계정의 사용자 및 역할이 수행할 수 있는 작업을 제한할 수 없습니다.
원래 통합 결제 기능만 제공하는 조직에 대해 모든 기능을 활성화할 수 있습니다. 모든 기능을 활성화하려면 초대받은 멤버 계정 모두가 관리 계정이 과정을 시작하면서 전송한 초대를 수락해 변경 사항을 승인해야 합니다. 자세한 내용은 를 사용하여 조직의 모든 기능 활성화 AWS Organizations 단원을 참조하십시오.
조직 구조
- 조직
-
조직은 중앙에서 관리할 수 있으며, 최상단에 루트가 있고 그 아래에는 조직 단위가 중첩된 트리형 계층 구조로 구성할 수 있는 AWS 계정의 모음입니다. 각 계정은 루트에 바로 배치하거나, 계층 구조 내의 OU 중 하나에 배치할 수 있습니다.
각 조직은 다음으로 구성됩니다.
조직은 사용자가 설정하는 기능 모음으로 결정되는 다양한 기능을 보유합니다.
- 루트
-
관리 루트(루트)는 관리 계정에 포함되어 있으며 AWS 계정을 구성하기 위한 시작점입니다. 루트는 조직의 계층 구조에서 가장 위에 있는 컨테이너입니다. 이 루트 아래에 조직 단위(OU)를 생성하여 계정을 논리적으로 그룹화하고 이러한 OU를 필요에 가장 적합한 계층 구조로 구성할 수 있습니다.
관리 정책을 루트에 적용하면 해당 정책은 모든 조직 단위(OU)와 조직의 관리 계정을 포함한 모든 계정에 적용됩니다.
권한 부여 정책(예: 서비스 제어 정책(SCP))을 루트에 적용하는 경우 조직의 모든 조직 단위(OU)와 멤버 계정에 적용됩니다. 조직 내 관리 계정에는 적용되지 않습니다.
참고
루트는 하나만 가질 수 있습니다. AWS Organizations는 사용자가 조직을 생성할 때 루트를 자동으로 생성합니다.
- 조직 단위(OU)
-
조직 단위(OU)는 조직 내의 AWS 계정 그룹입니다. OU에는 계층을 생성할 수 있는 다른 OU도 포함될 수 있습니다. 예를 들어 동일한 부서에 속한 모든 계정을 부서별 OU로 그룹화할 수 있습니다. 마찬가지로 보안 서비스를 실행하는 모든 계정을 보안 OU로 그룹화할 수도 있습니다.
OU는 조직 내 계정 하위 집합에 동일한 제어를 적용해야 할 때 유용합니다. OU를 중첩하면 더 작은 단위로 관리할 수 있습니다. 예를 들어 각 워크로드에 대해 OU를 생성한 다음 각 워크로드 OU에 중첩된 OU를 두 개 생성하여 사전 프로덕션 워크로드와 프로덕션 워크로드를 나눌 수 있습니다. 이러한 OU는 팀 수준 OU에 직접 할당된 제어 외에도 상위 OU에서 정책을 상속합니다. 최하위 OU에서 생성된 루트 및 AWS 계정을 포함하여 계층 구조의 깊이는 5단계까지 될 수 있습니다.
- AWS 계정
-
AWS 계정은 AWS 리소스의 컨테이너입니다. AWS 계정에서 AWS 리소스를 생성하고 관리하며, AWS 계정은 액세스 및 결제를 위한 관리 기능을 제공합니다.
여러 AWS 계정을 사용하는 것은 비용에 대한 결제 경계를 제공하고, 보안을 위해 리소스를 격리하고, 새로운 프로세스에 적응할 수 있을 뿐만 아니라 개인과 팀에 유연성을 제공하므로 환경을 확장하는 데 가장 좋은 방법입니다.
참고
AWS 계정은 사용자와 다릅니다. 사용자는 AWS Identity and Access Management(IAM)를 사용하여 생성하는 자격 증명으로서, 장기 자격 증명을 갖는 IAM 사용자 또는 단기 자격 증명을 갖는 IAM 역할의 형태를 취합니다. 하나의 AWS 계정은 많은 사용자와 역할을 포함할 수 있으며, 일반적으로도 그러합니다.
조직에는 두 가지 유형의 계정이 있습니다. 하나는 관리 계정으로 지정된 단일 계정이며 다른 하나는 하나 이상의 멤버 계정입니다.
- 관리 계정
-
관리 계정은 조직을 생성하는 데 사용하는 AWS 계정입니다. 관리 계정에서는 다음을 수행할 수 있습니다.
조직 내에서 다른 계정 생성
조직에 가입하도록 다른 계정 초대 및 초대 관리
-
위임된 관리자 계정 지정
조직에서 계정 제거
-
지원되는 AWS 서비스와의 통합을 지원하여 조직의 모든 계정에 서비스 기능 제공
관리 계정은 조직의 최종 소유자로, 보안, 인프라 및 재무 정책을 최종적으로 제어할 수 있습니다. 이 계정은 지급인 계정의 역할을 하며 조직의 계정에서 발생한 모든 요금을 지불할 책임이 있습니다.
참고
조직 내 어떤 계정이 관리 계정인지 변경할 수 없습니다.
- 구성원 계정
-
멤버 계정은 조직에 속한 관리 계정이 아닌 AWS 계정입니다. 조직의 관리자인 경우 조직에서 멤버 계정을 생성하고 기존 계정을 조직에 가입하도록 초대할 수 있습니다. 멤버 계정에 정책을 적용할 수도 있습니다.
참고
멤버 계정은 한 번에 하나의 조직에만 속할 수 있습니다. 멤버 계정을 위임된 관리자 계정으로 지정할 수 있습니다.
- 위임된 관리자
-
관리 계정과 그 사용자 및 역할은 해당 계정으로 수행해야 하는 작업에 대해서만 사용하는 것이 좋습니다. AWS 리소스를 조직의 다른 멤버 계정에 저장하고 관리 계정에는 저장하지 않는 것이 좋습니다. 이는 Organizations 서비스 제어 정책(SCP)과 같은 보안 기능이 관리 계정의 사용자나 역할을 제한하지 않기 때문입니다. 관리 계정에서 리소스를 분리하면 인보이스의 요금을 파악하는 데도 도움이 될 수 있습니다. 조직의 관리 계정에서 하나 이상의 멤버 계정을 위임된 관리자 계정으로 지정하면 이 권장 사항을 구현하는 데 도움이 됩니다. 위임된 관리자에는 다음 두 가지 유형이 있습니다.
Organizations의 위임된 관리자: 이 계정에서는 조직 정책을 관리하고 조직 내 엔터티(루트, OU 또는 계정)에 정책을 연결할 수 있습니다. 관리 계정은 세분화된 수준에서 위임 권한을 제어할 수 있습니다. 자세한 내용은 AWS Organizations에 위임된 관리자 단원을 참조하십시오.
AWS 서비스의 위임된 관리자: 이 계정에서는 Organizations과 통합되는 AWS 서비스를 관리할 수 있습니다. 관리 계정은 필요에 따라 여러 멤버 계정을 여러 서비스에 위임된 관리자로 등록할 수 있습니다. 이러한 계정에는 특정 서비스에 대한 관리 권한과 함께 Organizations 읽기 전용 작업에 대한 권한이 있습니다. 자세한 내용은 Organizations와 연동되는 AWS 서비스의 위임된 관리자 단원을 참조하세요.
초대 및 핸드셰이크
- 초대
-
초대는 다른 계정에 조직 가입을 요청하는 과정입니다. 초대는 조직의 관리 계정에서만 발행할 수 있습니다. 초대는 계정 ID 또는 초대된 계정과 연결된 이메일 주소로 확장됩니다. 초대받은 계정이 초대를 수락하면, 해당 계정은 조직의 멤버 계정이 됩니다. 조직이 모든 멤버가 통합 결제 기능 지원에서 모든 기능 지원으로 전환하는 일을 승인해야 한다면, 현재 존재하는 모든 멤버 계정에 초대를 전송해야 합니다. 초대를 이용하려면 계정이 핸드셰이크를 교환해야 합니다. AWS Organizations 콘솔에서 작업할 때는 핸드셰이크가 표시되지 않을 수 있습니다. 그러나 AWS CLI 또는 AWS Organizations API를 사용하는 경우 핸드셰이크로 직접 작업해야 합니다.
- 핸드셰이크
-
핸드셰이크는 두 당사자 간에 정보를 교환하는 여러 단계로 구성된 과정입니다. AWS Organizations에서 이 핸드셰이크가 주로 사용되는 경우 중 하나는 초대를 위한 기본 작업을 구현할 때입니다. 핸드셰이크 메시지는 핸드셰이크 개시자와 받는 사람 간에 전달되고 응답됩니다. 메시지는 양 당사자가 현재 상태를 알 수 있도록 전달됩니다. 또한 핸드셰이크는 조직이 통합 결제 기능만 지원하는 데서 가 제공하는 모든 기능AWS Organizations을 지원하도록 변경할 때도 사용합니다. 일반적으로는 AWS Organizations API나 AWS CLI 같은 명령줄 도구를 사용할 때에만 핸드셰이크와 직접 상호 작용해야 합니다.
조직 정책
정책은 AWS 계정 그룹에 적용하려는 제어를 정의하는 하나 이상의 문이 포함된 “문서”입니다. AWS Organizations는 관리 정책 및 권한 부여 정책을 지원합니다.
관리 정책
관리 정책은 조직 전체에서 AWS 서비스 및 해당 기능을 중앙에서 구성하고 관리하는 데 도움이 됩니다.
- 백업 정책
-
백업 정책은 조직의 모든 계정에서 리소스에 대한 백업 전략을 표준화하고 구현하는 데 도움을 주는 정책 유형입니다. 백업 정책에서 리소스에 대한 백업 계획을 구성하고 배포할 수 있습니다.
- 태그 정책
-
태그 정책은 조직의 모든 계정에서 리소스 전반의 태그를 표준화하는 데 도움을 주는 정책 유형입니다. 태그 정책에서 특정 리소스에 대한 태그 지정 규칙을 지정할 수 있습니다.
- 챗봇 정책
-
챗봇 정책은 Slack 및 Microsoft Teams와 같은 채팅 애플리케이션에서 조직의 계정에 대한 액세스를 제어하는 데 도움을 주는 정책 유형입니다. 챗봇 정책에서는 액세스를 특정 워크스페이스(Slack) 및 팀(Microsoft Teams)으로 제한합니다.
- AI 서비스 옵트아웃 정책
-
AI 서비스 옵트아웃 정책은 조직의 모든 계정에서 AWS AI 서비스에 대한 옵트아웃 설정을 표준화하는 데 도움을 주는 정책 유형입니다. 특정 AWS AI 서비스는 Amazon AI 서비스 및 기술의 개발과 지속적인 개선을 위해 해당 서비스에서 처리한 고객 콘텐츠를 저장하고 사용할 수 있습니다. AI 서비스 옵트아웃 정책에서는서비스 개선을 위해 자신의 콘텐츠가 저장되거나 사용되지 않도록 옵트아웃할 수 있습니다.
권한 부여 정책
권한 부여 정책은 조직 전체에서 AWS 계정 보안을 중앙에서 관리하는 데 도움을 줍니다.
- 서비스 제어 정책
-
서비스 제어 정책은 SCP가 영향을 미치는 계정에서 사용자와 역할이 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. SCP는 권한을 부여하지 않는다는 점을 제외하고 IAM 권한 정책과 비슷합니다. 대신 SCP는 조직, 조직 단위(OU) 또는 계정에 대한 최대 권한을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 SCP는 멤버 계정의 엔터티에 대한 권한을 제한합니다.
- 허용 목록 및 거부 목록
-
허용 목록과 거부 목록은 SCP를 적용하여 계정에 사용 가능한 권한을 필터링할 수 있는 보완적인 전략입니다.
-
허용 목록 전략 – 허용되는 액세스를 명시적으로 지정합니다. 다른 모든 액세스는 묵시적으로 차단됩니다. 기본적으로 AWS Organizations는
FullAWSAccess
라는 AWS 관리형 정책을 모든 루트, OU 및 계정에 연결합니다. 따라서 조직을 구축할 때 사용자가 원하기 전까지는 무엇도 차단되지 않도록 합니다. 다시 말해서, 기본적으로 모든 권한이 허용됩니다. 권한을 제한할 준비가 끝났다면,FullAWSAccess
정책을 더욱 제한적이고 원하는 권한 모음만 허용하는 정책과 교체하면 됩니다. 이렇게 하면 영향받는 계정의 사용자와 역할은 IAM 정책이 모든 작업을 허용하더라도 지정된 수준의 액세스만 이용할 수 있습니다. 루트의 기본 정책을 교체하면, 조직의 모든 계정이 제한의 적용을 받게 됩니다. SCP는 권한을 부여하지 않으며 필터링만하기 때문에 계층 구조의 낮은 수준에 다시 권한을 추가할 수는 없습니다. -
거부 목록 전략 – 허용되지 않는 액세스를 명시적으로 지정합니다. 다른 액세스는 모두 허용됩니다. 이 시나리오에서는 명시적으로 차단하지 않는 이상 모든 권한이 허용됩니다. 이는 AWS Organizations의 기본 동작입니다. 기본적으로 AWS Organizations는
FullAWSAccess
라는 AWS 관리형 정책을 모든 루트, OU 및 계정에 연결합니다. 따라서 모든 계정은 AWS Organizations가 적용한 제한을 받지 않고 모든 서비스와 작업에 액세스할 수 있습니다. 위에서 설명한 허용 목록 기술과 달리, 거부 목록을 사용할 때는 “모두” 허용하는 기본FullAWSAccess
정책을 그대로 둡니다. 그런 다음 원치 않는 서비스와 작업에 대한 액세스를 명시적으로 거부하는 추가 정책을 연결합니다. IAM 권한 정책과 마찬가지로, 서비스 작업의 명시적 거부는 해당 작업에 대한 모든 허용을 무시하게 됩니다.
-