<div id="readability-page-1" class="page"><div><p id="f4a5"><strong>#2) 조직(Organization)</strong></p><p id="b3d2">개인 프로젝트나 간단한 프로젝트 정도의 구조라면 이전에 설명한 계정과 리소스에 대해서만 이해하면 되지만 조금 더 대규모 환경이 필요한 경우나 복잡한 기업형 프로젝트라면 일반적으로 AWS 와 Google cloud 모두 계층형 구조를 가질 수 있는 조직(Organization) 구성을 지원하며 권장합니다. 조직은 이름 그대로 AWS 입장에서 계정을, Google cloud 입장에서 프로젝트를 다수 활용할 수 있는 구조를 가지면서 관리 및 예산, 보안 및 규정 준수등 기업에서 필요한 다양한 추가 기능을 충족할 수 있게 지원됩니다. 다만 이러한 조직도 AWS 와 Google cloud 간의 차이가 약간 존재합니다. 기본적인 차이를 보기 쉽게 만들어 놓은 그림이 있어서 참고하시라고 먼저 공유드립니다. 도식화된 그림을 보시면 아시겠지만 조직 관점에서 AWS 와 Google cloud 구조는 상당히 유사합니다.</p><figure></figure><p id="69bb"><a href="https://levelup.gitconnected.com/aws-azure-gcp-resource-hierarchies-25b829127511" rel="noopener ugc nofollow" target="_blank">https://levelup.gitconnected.com/aws-azure-gcp-resource-hierarchies-25b829127511</a></p><p id="decc">우선 AWS 공식 매뉴얼에서 조직에 대해서 살펴보면 “AWS Organizations 은 생성한 여러 AWS 계정을 조직에 통합하고 중앙에서 관리할 수 있는 계정 관리 서비스입니다. AWS Organizations 의 계정 관리 및 통합 결제 기능을 활용하면 기업의 예산, 보안 및 규정 준수 요구 사항을 보다 잘 충족할 수 있습니다. 조직의 관리자로서 조직에서 계정을 생성하고 기존 계정을 조직에 초대할 수 있습니다.” 라고 되어 있습니다. 즉, AWS 는 계정이 리소스를 가지고 중심적인 역할을 수행하기 때문에 결국 조직도 계정에 대한 통합 및 중앙 관리할 수 있는 계정 관리 서비스 역할을 수행합니다.</p><figure></figure><p id="d159"><a href="https://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_getting-started_concepts.html" rel="noopener ugc nofollow" target="_blank">https://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_getting-started_concepts.html</a></p><p id="9319">AWS 조직은 통합적인 계정관리가 그 목적이기 때문에 조직을 만들때 관리 계정(Management account) 이 필요하며 기존 계정을 관리 계정으로 사용 가능합니다. Organization root 라는 조직 최상단의 개념 하위에는 관리를 좀 더 효율적으로 할 수 있도록 조직 단위(Organization Unit — OU) 를 사용할 수 있습니다. 조직 단위는 AWS 조직에 있는 계정의 논리적 그룹이며 이를 사용하면 계정을 계층 구조로 구성하고 관리 제어를 더 쉽게 적용할 수 있습니다. 조직이나 조직 단위 모두 논리적 그룹이기 때문에 결론적으로 실제 리소스는 조직 or 조직 단위의 하위에 속해있는 멤버 계정(Member account) 에 속하게 됩니다.(멤버 계정이 이전 파트에서 설명했던 계정을 의미하고 리소스가 속하는 위치입니다.)</p><p id="14cb">조직의 기본 구성이 되었다면 AWS 의 경우 조직에 추가적으로 서비스 제어 정책(Service control policy) 을 설정할 수 있습니다. 서비스 제어 정책은 이름 그대로 서비스 제어 정책의 영향을 받는 계정에서 사용자와 역할이 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. 예를 들어 “EC2 인스턴스가 특정 유형을 사용하도록 요구하도록” 서비스 제어 정책을 설정할 수 있으며 이렇게 설정하게 되면 조직 전체적으로 해당 정책이 적용되게 할 수 있습니다. 즉, 서비스 제어 정책을 통해서 조직에 대한 중앙 관리 기능을 보강 할 수 있습니다.(이상의 AWS 관련 내용은 상단에 첨부된 링크상 article을 기반으로 하였습니다)</p></div></div>

Stories by 이정운 (Jungwoon Lee) on Medium

[GCP]AWS 사용자를 위한 Google cloud 알아가기 — #2 조직(Organization)
안녕하세요 이정운 입니다.
“[GCP]AWS 사용자를 위한 Google cloud 알아가기 — #1 계정(Account) 및 자원(Resource)” 이라는 주제로 이전 파트에서 AWS 에는 익숙한 Google cloud 초심자를 위하여 AWS 에서 익숙한 구조와 조금 다른점 또는 용어 차이 때문에 혼동하는 부분들을 줄이기 위해서 AWS 와 Google cloud 에서의 계정과 자원에 대한 차이에 대해서 이야기를 했습니다. 이어서 대규모 환경에서 관리와 제어 목적으로 사용되는 조직(Organization)에 대한 측면에서 AWS 와 Google cloud 의 비슷한 점과 차이를 살펴보는 이야기를 시작해보도록 하겠습니다.
#2) 조직(Organization)
개인 프로젝트나 간단한 프로젝트 정도의 구조라면 이전에 설명한 계정과 리소스에 대해서만 이해하면 되지만 조금 더 대규모 환경이 필요한 경우나 복잡한 기업형 프로젝트라면 일반적으로 AWS 와 Google cloud 모두 계층형 구조를 가질 수 있는 조직(Organization) 구성을 지원하며 권장합니다. 조직은 이름 그대로 AWS 입장에서 계정을, Google cloud 입장에서 프로젝트를 다수 활용할 수 있는 구조를 가지면서 관리 및 예산, 보안 및 규정 준수등 기업에서 필요한 다양한 추가 기능을 충족할 수 있게 지원됩니다. 다만 이러한 조직도 AWS 와 Google cloud 간의 차이가 약간 존재합니다. 기본적인 차이를 보기 쉽게 만들어 놓은 그림이 있어서 참고하시라고 먼저 공유드립니다. 도식화된 그림을 보시면 아시겠지만 조직 관점에서 AWS 와 Google cloud 구조는 상당히 유사합니다.
https://levelup.gitconnected.com/aws-azure-gcp-resource-hierarchies-25b829127511
우선 AWS 공식 매뉴얼에서 조직에 대해서 살펴보면 “AWS Organizations 은 생성한 여러 AWS 계정을 조직에 통합하고 중앙에서 관리할 수 있는 계정 관리 서비스입니다. AWS Organizations 의 계정 관리 및 통합 결제 기능을 활용하면 기업의 예산, 보안 및 규정 준수 요구 사항을 보다 잘 충족할 수 있습니다. 조직의 관리자로서 조직에서 계정을 생성하고 기존 계정을 조직에 초대할 수 있습니다.” 라고 되어 있습니다. 즉, AWS 는 계정이 리소스를 가지고 중심적인 역할을 수행하기 때문에 결국 조직도 계정에 대한 통합 및 중앙 관리할 수 있는 계정 관리 서비스 역할을 수행합니다.
https://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_getting-started_concepts.html
AWS 조직은 통합적인 계정관리가 그 목적이기 때문에 조직을 만들때 관리 계정(Management account) 이 필요하며 기존 계정을 관리 계정으로 사용 가능합니다. Organization root 라는 조직 최상단의 개념 하위에는 관리를 좀 더 효율적으로 할 수 있도록 조직 단위(Organization Unit — OU) 를 사용할 수 있습니다. 조직 단위는 AWS 조직에 있는 계정의 논리적 그룹이며 이를 사용하면 계정을 계층 구조로 구성하고 관리 제어를 더 쉽게 적용할 수 있습니다. 조직이나 조직 단위 모두 논리적 그룹이기 때문에 결론적으로 실제 리소스는 조직 or 조직 단위의 하위에 속해있는 멤버 계정(Member account) 에 속하게 됩니다.(멤버 계정이 이전 파트에서 설명했던 계정을 의미하고 리소스가 속하는 위치입니다.)
조직의 기본 구성이 되었다면 AWS 의 경우 조직에 추가적으로 서비스 제어 정책(Service control policy) 을 설정할 수 있습니다. 서비스 제어 정책은 이름 그대로 서비스 제어 정책의 영향을 받는 계정에서 사용자와 역할이 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. 예를 들어 “EC2 인스턴스가 특정 유형을 사용하도록 요구하도록” 서비스 제어 정책을 설정할 수 있으며 이렇게 설정하게 되면 조직 전체적으로 해당 정책이 적용되게 할 수 있습니다. 즉, 서비스 제어 정책을 통해서 조직에 대한 중앙 관리 기능을 보강 할 수 있습니다.(이상의 AWS 관련 내용은 상단에 첨부된 링크상 article을 기반으로 하였습니다)
Google cloud 의 조직도 처음에 잠깐 언급했지만 AWS 와 거의 유사한 구조를 가지고 있습니다. 논리적인 개념으로 조직과 폴더(Folder) 를 가질 수 있고 조직과 폴더는 AWS 의 조직과 조직 단위(OU) 와 동일하게 관리를 좀 더 효율적이며 계층적으로 하기위한 목적을 가지며 리소스를 소유할 수는 없습니다. 논리적 개념인 조직이나 폴더는 말씀드린 것처럼 직접 리소스를 소유할 수는 없지만 프로젝트를 하위에 가질 수 있고 프로젝트가 리소스를 가지고 있는 구조를 가지며 계층화 되어있습니다. (다만, Google cloud 의 최상위 루트인 조직은 AWS 와는 다르게 조직 생성을 위해서 “abc.com” 과 같은 도메인 맵핑이 필요하며 필요한 사용자들을 Google cloud 에서 직접 생성하기 위해서 Cloud Identity 나 Google Workspace 등이 필요합니다. 상세 내용은 하단에 ‘추신 #2’ 의 참고 링크를 참고하시기 바라겠습니다.)
https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy
추신 #2) Google cloud 에서 조직을 생성하기 위해서는 Cloud Identity(무료) 나 Google Workspace 가 필요하며 해당 부분의 상세 설명과 조직을 만드는 방법이 궁금하신 분들은 하단에 블로그 글을 참고하시기 바라겠습니다.
[GCP]GCP 에서 조직(Organization) 활용하기 1부 — Cloud Identity
https://medium.com/google-cloud-apac/gcp-gcp-%EC%97%90%EC%84%9C-%EC%A1%B0%EC%A7%81-organization-%ED%99%9C%EC%9A%A9%ED%95%98%EA%B8%B0-1%EB%B6%80-cloud-identity-2b53e072bbc1
추신 #3) 과거의 경우에 조직을 만드실때 email 계정 필요에 대한 이슈가 있었지만 필수 연락처(essential contacts) 기능이 추가 지원되면서 해당 기능을 통해서 대부분의 알림(notification) 에 대한 연락처를 별도로 설정할 수 있습니다.
Managing contacts for notifications
https://cloud.google.com/resource-manager/docs/managing-notification-contacts
Google cloud 에서도 조직 구성 후 AWS 의 서비스 제어 정책에 매핑되는 기능이 존재하며 이를 조직 정책(Organization Policy) 이라고 부르고 있습니다. “리소스 위치 제약조건을 사용하여 새 리소스의 물리적 위치를 제한하거나”, “리소스 공유를 특정 조직의 리소스에 속하는 도메인 ID 로 제한하는” 등 좀 더 다양한 조건을 적용하거나 커스텀 제약 조건을 만들어서 조직 전체적으로 해당 정책을 적용되게 하여 조직 전반적으로 보안성을 높이거나 관리되어야 하는 부분을 정책으로 만들어 관리 할 수 있습니다.
https://cloud.google.com/resource-manager/docs/organization-policy/creating-managing-policies
추신 #4) 조직을 구성할때 Best Practices 가 있는데 이 부분을 읽어보시면 오히려 거꾸로 Google cloud 의 조직이나 계정에 대한 이해가 더 쉬울듯하여 해당 링크 내용 공유드리오니 참고하시기 바라겠습니다.
https://cloud.google.com/iam/docs/resource-hierarchy-access-control?hl=ko#best_practices
지금까지 AWS, Google cloud 의 계정과 리소스에 대해서, 그리고 조직에 대해서 어떠한 차이가 있고 유사한 점이 있는지 비교해서 설명을드렸고 이를 통해서 AWS 에 익숙하신 분들이 Google cloud 를 접하시는데 조금은 도움이 될만한 이야기를 가능한 쉽게 풀어서 해드렸습니다. 제일 중요하게 언급드린 것은 몇 번 반복해서 말씀드렸지만 AWS 는 계정 중심이고 Google cloud 는 프로젝트 중심이다라는 이야기 였는데 이 부분만 명확히 이해하면 AWS 에 익숙하신 분이라도 쉽게 Google cloud 를 활용할 수 있지 않을까 합니다. 그럼 이번 이야기는 여기서 마무리 하도록 하겠습니다.
Disclaimer: 본 글의 작성자는 Google 소속이지만, 본 글에 작성자 개인적 견해가 반영된 것으로서, 본 글은 Google 을 대변하지 않으며, Google의 공식적 입장이 아님을 밝힙니다.
참고 자료 #1
AWS, Azure, GCP: Resource Hierarchies
https://levelup.gitconnected.com/aws-azure-gcp-resource-hierarchies-25b829127511
AWS Organizations terminology and concepts
https://docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_getting-started_concepts.html
Resource hierarchy
https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy
[GCP]GCP 에서 조직(Organization) 활용하기 1부 — Cloud Identity
https://medium.com/google-cloud-apac/gcp-gcp-%EC%97%90%EC%84%9C-%EC%A1%B0%EC%A7%81-organization-%ED%99%9C%EC%9A%A9%ED%95%98%EA%B8%B0-1%EB%B6%80-cloud-identity-2b53e072bbc1
Using resource hierarchy for access control — Best Practices
https://cloud.google.com/iam/docs/resource-hierarchy-access-control#best_practices
[GCP]AWS 사용자를 위한 Google cloud 알아가기 — #2 조직(Organization) was originally published in google-cloud-apac on Medium, where people are continuing the conversation by highlighting and responding to this story.

[GCP]AWS 사용자를 위한 Google cloud 알아가기 — #2 조직(Organization)

댓글