AWS Organizations

AWS Organizations 는 글로벌 서비스 이다.

조직을 생성하여 여러 AWS 계정을 관리할 수 있는 서비스이다.

주 계정은 마스터 계정으로 부르며,

그 외 다른 계정은 모두 하위 계정이라고한다.

 

Organizations를 사용하면 통합 과금이 되므로 비용적 이점이 있다.

모든 계정에 대한 비용을 마스터 계정으로 통합해서 지불하기 때문에

한 번만 비용을 지불하면 끝이다.

그리고 모든 계정의 사용량을 통합하기 때문에 할인을 받을 수 있다.

 

예약형 인스턴스를 이용하는 경우에는 이를 공유하여

한 계정이 예약형 인스턴스를 사용하고 있지 않을 때에

다른 계정이 이를 사용함으로써 최대한 비용을 절감할 수 있다.

SCP(서비스 제어 정책)을 이용하여 계정의 권한을 제한할 수 있다.

 

 

Organizational Units(OU)

그러면 어떻게 여러 계정들을 조직화 할까?

 

예를 들어서 사업부별로 마스터 계정을 갖는다고 하면

영업OU, 소매OU, 재무OU가 있을 시

각 OU단위에 대해 계정이 생성된다.

 

 

예를 들어 아래와 같은 조직이 있다고 해보자.

모든 OU가 포함될 Root OU가 있다. 여기에는 마스터 계정이 있으므로

이를 통해 여러 OU 를 생성할 수 있다.

 

Develop OU에 두 계정이 있고

Product OU에도 두 개의 계정이 있는데

Product OU내에는 또 다른 OU가 있다.

Finance OU와 HR OU 인데 각각 두개의 계정씩 포함하고 있다.

 

 

 

Service Control Polices (SCP)

서비스 제어 정책(SCP)는 

IAM actions을 화이트리스트나 블랙리스트에 올리거나

OU 혹은 계정 수준으로 적용한다

그리고 마스터 계정에는 적용되지않는다.

SCP는 마스터 계정에 아무 영향을 줄 수 없다.

 

SCP는 루트를 포함한 계정의 사용자나 Roles에 적용될 수 있다.

예를들어 OU 내 계정에

EC2를 사용할 수 없다는 SCP를 적용한 경우

해당 계정의 관리자라고 하더라도 EC2를 사용할 수 없게된다.

단, SCP는 서비스 role에는 적용되지 않는다.

 

기본적으로 아무런 허용 권한이 없어서

SCP는 작업을 허용하기 위한 명시적 허용 권한이 필요하다.

 

위 그럼에서 Root OU에 FullAWSAccess 라는 SCP를 추가하여

모든 작업에 대한 모든 서비스의 이용이 가능하도록 정했다고 해보자.

이때 마스터 계정에 DenyAccessAthena SCP를 적용하면

마스터 계정은 RootOU로 부터 FullAWSAccess SCP를 상속받았기 때문에

전체 액세스가 가능하다.

그리고 마스터 계정에 DenyAccessAthena SCP를 주기는 했으나

마스터 계정은 Root에 속한 계정이기 때문에 해당 SCP는 적용되지 않는다.

마스터 계정에 적용한 SCP는 무효하다.

 

다음으로 Product OU에는 DenyRedshift SCP가 주어졌고

계정A에는 AuthorizeRedshift SCP 가 주어졌다.

계정A는 Root OU로 부터 FullAWSAccess SCP를 상속 받아 모든 작업이 가능하지만

Product OU에 적용된 DenyRedshift로 인해 Redshift에는 액세스가 불가능하다.

비록 계정A에 AuthorizeRedsift SCP를 부여했어도 OU 레벨에서 Redshift에 대한 거부가 있는 상태이므로

해당 SCP는 무효하다.

 

그 다음은 계정B이다.

Root OU에서 상속을 받고 Product OU에서 상속을 받아

Redshift를 제외한 모든 작업이 가능하고

HR OU에 속하기 때문에 DenyAWSLambda SCP를 적용 받아

Lambda에 액세스 하는것도 불가능하다.

 

계정 C는 Finance OU에 있지만 Finance OU에는 어떠한 SCP도 주어지지않아서

계정 A와 동일한 권한을 갖고 있다.