AWS Organizations
Organizations 개요
Organizations는 글로벌 서비스로 조직을 생성하여 여러 AWS 계정을 관리할 수 있는 서비스이다.
계정
주 계정은 마스터 계정이라 부르고, 그 외의 계정은 모두 하위 계정이라고 한다.
비용 절감
Organizations를 사용하면 모든 계정에 대한 비용을 마스터 계정으로 지불하기 때문에 한 번만 대금을 지불하면 되기 때문에 비용적 이점이 있다.
또한 종합 사용량에 대한 가격 혜택이 있다. EC2나 S3 등 유독 더 많이 사용하는 서비스에 대해서는 할인을 받을 수 있다. Organizations에선 대금이 모두 통합되는 것처럼 사용량도 종합 사용량으로 통합된다.
예약형 인스턴스를 이용하는 경우 이를 공유하여 한 계정이 예약형 인스턴스를 사용하고 있지 않을 때 다른 계정이 이를 사용함으로써 비용을 절감할 수 있다.
자동화 지원 API
AWS 계정 생성을 자동으로 수행할 수 있는 자동화 지원 API도 있다. 샌드박스 계정과 같이 다른 사람을 위해 계정을 생성하도록 프로그래밍 할 수 있는 것이다.
서비스 제어 정책
서비스 제어 정책 혹은 SCP를 이용하여 계정의 권한을 제한할 수 있다.
굵게 표시된 부분이 중요
다중 계정 전략
AWS에서는 다중 계정 전략을 수립할 수 있다. 다중 계정 전략은 원하는 계정의 유형에 따라 각 조직에서 다르게 나타날 수 있다. 따라서 다중 계정을 이용하거나 단일 계정에 다중 VPC를 함께 이용할 수 있다.
대금 청구 목적으로 모든 계정에 대해 tagging 표준을 사용할 수 있고, 모든 계정에 대해 CloudTrail을 활성화하여 중앙 S3 계정에 로그를 전송할 수 있고, CloudWatch Logs에 대해서도 중앙 로깅 계정에 로그를 모두 전송할 수 있다.
예시
- 부서별, 가격 중점별, 환경별, 혹은 규제 제한에 근거해
dev,test,prod별로 계정을 생성할 수 있음 - 계정을 생성하지 않도록 서비스를 설정할 땐 SCP를 사용하거나 리소스를 더 잘 격리할 수 있도록 다른 계정마다 다른 VPC를 갖도록 하여 계정별 서비스 제한을 더 잘 관리할 수 있음
- 로깅으로부터 계정을 격리시킬 수도 있음
계정을 조직화하는 방법
영업 기관 조직, 소매 기관 조직, 재무 기관 조직이 있을 때 각 조직 단위에 대해 다중의 계정이 생성된다. 혹은 환경(개발, 테스트, 프로덕션)이나 프로젝트 별로 나눌 수도 있다.
- 모든 단위가 포함될 Root OU가 있다
- 마스터 계정이 있고, 이를 통해 여러 OU를 생성할 수 있다
- Dev OU와 Prod OU에도 두 개의 계정이 있다
- Prod OU 내에는 또 다른 OU가 있다
- Finance OU와 HR OU이 있고 각각 개별적인 계정을 가진다
- Prod OU 내에는 또 다른 OU가 있다
서비스 제어 정책 (SCP)
- IAM 작업을 화이트나 블랙 리스트에 올리거나 OU 혹은 계정 수준에는 적용되지만 마스터 계정에는 적용되지 않는다
- SCP는 루트를 포함하여 계정의 사용자나 역할에만 적용할 수 있다
- 내 계정에 SCP를 적용했을 때 EC2를 사용할 수 없다고 정하면 해당 계정의 관리자라고 해도 EC2를 사용할 수 없게 된다.
- SCP는 서비스 역할에는 적용되지 않는다
- 서비스 역할은 다른 서비스를 조직에 통합할 때 사용
- SCP는 작업을 허용하기 위한 명시적 허용 권한이 필요하다
- 기본적으로는 아무런 허용 권한이 없음
사용 사례 및 시험 관련
SCP는 특정 서비스에 대한 액세스를 제한할 때 쓰인다.
- 프로덕션 계정에서 EMR을 사용할 수 없다거나 PCI 규정 준수를 시행할 때 AWS 내에서 PCI를 준수하지 않는 서비스를 명시적으로 비활성화하는 것이다.
- Root OU에 FullAWSAccess SCP를 추가했다고 가정해보자.
- 마스터 계정에 DenyAccessAthena를 적용해도 FullAWSAccess SCP를 상속받았기 때문에 전체 액세스가 가능하다.
- Prod OU에는 DenyRedshift SCP가 적용돼있고, 계정 A에는 AuthorizeRedshift가 적용돼있다.
- 바로 상위항목에 DenyRedshift가 적용되어 있기 때문에 A 계정으로 모든 작업이 가능하지만 Redshift 액세스는 불가능하다.
- A 계정은 속한 OU 수준에서도 SCP를 상속받고, Root OU에서도 상속받는다.
- Finance OU에 있는 계정 B는 전체 액세스가 가능하지만 Redshift 액세스와 AWSLambda 액세스가 불가능하다.
- HR OU의 경우 DenyAWSLambda는 적용되지 않는다.
AWS Organization - Consolidated Billing
기관 통합 결제를 활성화하면 두 가지 사항이 제공된다.
- 결합 사용량을 볼 수 있다.
- 단일 청구서
결합 사용량을 볼 수 있음
이는 모든 계정에 대한 사용량을 하나로 결합하여 두 가지 작업을 가능하도록 한다.
- 볼륨 가격을 공유
- S3를 예시로 사용 데이터가 5TB를 초과하면 다음 서비스는 좀 더 가격이 저렴해지는 방식
- 총 6개의 계정을 이용하고 있고, 전체 계정을 결합하면 각 계정이 1TB의 데이터를 사용할 경우 할인 혜택을 받게 된다.
- 결합 사용량이 중요
- 하나의 계정에 대한 예약형 인스턴스와 절감형 플랜에 있어서도 모든 계정에 걸쳐 공유가 가능하기 때문에 할인과 비용 절감을 극대화할 수 있음
단일 청구서
조직 내 모든 계정에 대한 청구서를 하나만 받으면 회계 부서에 큰 도움이 되며 이는 AWS 내에 생성한 계정의 수에 제한받지 않는다.
- 두 개의 계정이 있는 조직이 있을 때 A 계정은 예약형 인스턴스가 없고, B에는 5개가 있다.
- 예약형 인스턴스가 가용 영역 수준에 존재하므로 두 계정이 동일한 가용 영역에 있다고 했을 때 총 9개의 EC2 인스턴스가 생기는데 이 중 3개는 B, 6개는 A에서 생성된다.
- B 계정에 예약형 EC2 인스턴스가 총 5개 존재하므로 EC2 인스턴스 중 3개는 예약형 인스턴스일 것이다.
- 현재 예약형 인스턴스 공유를 활성화한 상태이므로 A 계정에 있는 2개의 인스턴스도 남은 2개의 예약형 인스턴스 가격을 적용받아서 비용을 절감할 수 있다.
- B 계정을 이용하는 Susan이 5개의 예약형 EC2 인스턴스 중 3개만 실행했더라도, 결과적으로 5개의 예약형 인스턴스 가격과 4개의 비예약형 인스턴스를 사용하는 사례인 것이다.
공유하는 방식을 알아 둬야 하고, 예약형 인스턴스 할인 공유는 조직 내 관리 계정과 주 계정을 포함하여 모든 계정에 대해 이를 해제하도록 설정할 수 있다
AWS Control Tower
Control Tower는 모범 사례를 바탕으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 쉽게 설정하고 제어할 수 있도록 지원한다. 수동으로 조직을 생성하고, 보안 작업을 일일이 적용하는 수고로움 대신 Control Tower를 이용하여 클릭 몇 번으로 간편하게 여러 계정이 있는 AWS 환경을 구축할 수 있다.
가드레일을 이용하여 지속적인 정책 관리를 자동화할 수도 있고, 정책 위반을 탐지하여 이를 해결하고, 대화형 대시보드를 통해 규정 준수 여부를 모니터링할 수 있다.
Control Tower는 조직보다 상위에서 실행되는데 이는 사용자의 계정을 관리하기 위해 자동으로 조직을 설정하고 SCP(서비스 제어 정책)를 실행한다는 뜻이다.
- 가드레일이 제대로 작동하는지 확인하기 위함
AWS Resource Access Manager
개요
AWS Resource Access Manager(이하 RAM)은 계정에서 소유하고 있는 리소스를 다른 AWS 계정과 공유할 수 있게 해준다. 아무 계정 또는 조직 내의 다른 계정에 가능하다.
이렇게 하면 리소스 중복을 피할 수 있다. 지원되는 리소스는 다음과 같다.
- Aurora DB
- VPC Subnet
- Transit Gateway
- Route 53
- …
리소스를 외울 필요는 없고, RAM 서비스의 기본 개념만 익히면 된다.
예시
- 클라우드 계정이 있고, 그 클라우드 계정 내에 VPC가 있다고 가정할 때 해당 VPC를 다른 계정과 공유할 수 있다.
- VPC 내에 프라이빗 서브넷이 있고, 서로 다른 계정인 계정 1과 계정 2가 있을 때 계정은 동일한 VPC와 서브넷에 액세스 할 수 있다.
- 계정 1에서 EC2 인스턴스를 만들고 VPC 내에서 로드 밸런서를 만들면 자체 EC2 인스턴스가 있는 계정 2는 네트워크에서 직접 액세스할 수 있다
- 중요한 점은 VPC를 공유했기 때문에 VPC 내의 모든 리소스가 네트워크 관점에서 서로 연결할 수 있어서 배포를 간소화할 수 있다
AWS Service Catalog
Service Catalog의 관리자는 제품을 만들 수 있다. Service Catalog를 사용하는 이유는 AWS를 처음 사용하는 사용자의 경우, 사용자가 만든 것이 조직의 나머지 부분과 일치하지 않을 수 있고, 일부 사용자는 셀프 서비스 포털에 액세스 하여 승인된 제품들로 시작하길 바라기 때문에 이런 것들을 관리자가 미리 정의해두기 위함이다.
관리자 작업
- 제품은 적절한 매개 변수가 있는 CloudFormation 템플릿이다.
- 그 템플릿들을 포트폴리오(
=제품들의 모음)에 넣을 수 있다. - 포트폴리오 내에서 누가 어떤 제품을 출시할 수 있는지 정의한다.
사용자 작업
- 사용자가 서비스 카탈로그의 포털에 로그인하면, 권한에 따라 포트폴리오에 있는 제품 중 사용할 수 있는 모든 제품이 표시된다.
- 사용자가 제품을 시작하면 자동으로 CloudFormation에서 프로비저닝된다.
- 제품은 적절하게 구성 및 태그가 지정되어 있으며 조직의 업무 방식을 따름
예를 들어, 사용자가 빠르게 RDS 데이터베이스에 액세스하고 싶지만 데이터베이스를 제대로 생성하는 방법을 모른다면, Service Catalog 내에서 서비스로 제공할 수 있다.
