AWS, Azure, OCI의 구조 비교

고객사는 AWS, Azure, OCI를 사용하는 멀티 클라우드 환경이다.

각 클라우드 서비스 제공자(CSP)마다 구조와 액세스 제어 방법이 다르기 때문에, 비교를 통해 개념을 명확화하고자 했다.

리소스 구조

AWS Oragnizations

AWS Organizations는 여러 개의 AWS 계정을 조직에 통합하여 중앙에서 관리하는 계정 관리 서비스이다.

AWS는 계정 단위로 리소스를 관리하고, AWS 조직으로 여러 계정들을 중앙에서 관리한다.

AWS 리소스 관리 체계: [Root > OU Units > Accounts]

Root: 최상위 관리자 계정. 조직 내 모든 리소스와 계정을 관리할 수 있는 최상위 권한을 가진다. Root 계정은 보안 목적으로 최소한의 사용을 권장하며, 관리 작업은 주로 하위 관리 계정을 통해 수행한다.
Organization: 여러 AWS 계정들의 정책, 보안, 청구 관리 중앙에서 통합 관리하기 위한 서비스
- Organizations 계정 종류
  - Root/Management Account: 멤버 계정에게서 발생하는 통합 요금을 지불하는 Payer 계정
  - Member Account: 나머지 모든 계정
Organization Units (OUs): OU는 다른 OU를 포함할 수 있어서 Tree 구조를 가진다. 상위 OU의 정책이 하위 OU와 계정에 상속된다. 조직 내에 속한 계정들을 논리적으로 그룹화하여 조직 하위의 그룹 별로 정책을 적용하고 관리할 수 있는 단위이다.
- OU 구조
  - Branches (OUs): 정책 적용
  - Leaves (Accounts): 정책을 상속 받음
Account(과금 단위): AWS 리소스를 보유하고 사용하는 사용자 단위
- Account 계정 종류
  - Management 계정: 조직의 관리 계정으로 조직에서 계정을 생성하고 다른 계정을 조직에 초대 관리하는 계정이다.
  - Account 계정: 나머지 모든 계정. 하나의 계정은 하나의 조직의 멤버로 속할 수 있다. (조직:계정=1:1 관계)

Azure Subscriptions

Azure 구독은 리소스의 비용 관리 단위이다.

리소스 그룹은 애져 리소스를 구성하고 관리하는 기본 단위이다.

Azure 리소스 관리 체계: [Tenant > Management Group > Subscriptions > Resource groups > Resources]

Tenant: 회사, 조직 단위로 Azure AD에서 사용자 및 그룹에게 권한 할당
Management Group: 여러 구독을 그룹화하여 관리. 구독의 액세스, 정책, 규정 준수 관리. 관리 그룹의 정책을 연결된 구독들이 상속 받는다.
Subscription (과금 단위): Azure 리소스를 사용하고 관리하는 단위 (하나의 구독은 하나의 테넌트에만 연결되는 1:1 관계)
Resource group: 리소스를 논리적으로 그룹화하여 관리하는 단위
- 그룹 단위로 액세스 제어 및 정책 적용 가능
- 모든 리소스는 리소스 그룹에 속하며, 여러 개의 리소스 그룹에 속할 수 없음 (N:1 불가))
리소스(Resource): Azure 서비스 자체. Azure에서 Entity라고 부름

OCI Compartment

OCI는 컴파트먼트 단위로 리소스를 관리한다. 컴파트먼트는 리소스를 논리적으로 그룹화하고, 접근 제어 및 권한 설정을 적용할 수 있는 단위이다.

OCI 리소스 관리 체계: [Tenant > Compartments > Users]

Tenant: OCI 리소스를 구성 및 관리할 수 있는 격리된 파티션, 사용자 기준의 최상위 계층
Compartment: 리소스를 논리적으로 그룹화하여 관리하는 단위. 모든 리소스를 배포할 때 컴파트먼트에 할당 (필수 설정). 컴파트먼트 단위로 접근 제어, 권한 설정 가능
- Root Compartment: 최상위 컴파트먼트 ( /, 기본적으로 모든 테넌트에 하나씩 존재 )
- 새로운 Comprtment: 루트 컴파트먼트 아래에 추가하여 별도의 논리적 그룹으로 리소스를 관리
User: OCI 리소스에 접근하고 관리할 수 있는 계정

액세스 제어

AWS IAM

AWS IAM: AWS 리소스에 대한 접근 권한을 관리하기 위한 서비스. 이를 위해 사용자에게 역할(Role) 및 정책(Policy)을 부여하여 사용자의 접근 권한을 세밀하게 제어하는 서비스

User: AWS 리소스에 접근하는 개별 사용자 계정
Group: 그룹 내 유사한 권한이 필요한 사용자들을 지정해서 공통 권한을 부여하여 관리 효율성 높임
Role: 특정 작업을 수행하기 위해 일시적으로 권한을 부여받는 엔터티
Policy: 사용자, 그룹, 역할을 접근 제어하는 JSON 형식의 정책 문서. 정책은 명시적으로 작성하여 IAM 사용자, 그룹, 역할에 연결할 수 있다. 정책 유형에는 관리형 정책(Managed Policies)과 인라인 정책(Inline Policies)이 있다.
- 어떤 행동(Action)이 어떤 리소스(Resource)에 대해 허용(Allow) 또는 거부(Deny)되는지 정의

AWS SCP

SCP (Service Control Policy; 서비스 제어 정책): 조직 내 모든 계정에 서비스 사용 권한을 중앙에서 제어하는 서비스이다. 관리 계정을 제외하고 하위의 Root 계정을 포함한 모든 사용자와 역할에 적용한다.

Organizations의 기본 구성은 'FullAWSAccess'라는 관리형 SCP를 연결해서 Deny list 방식을 사용한다.

기본 구성

Deny list : 기본적으로 모든 actions에 대하여 허용, 특정 서비스 및 actions을 금지
Allow list : 기본적으로 모든 actions에 대하여 금지, 특정 서비스 및 actons을 허용

Azure Entra ID

Azure Entra ID: AD 기반으로 액세스 관리하는 서비스. Entra ID는 Azure 리소스를 관리하는 권한을 제어하는 기능이다.. 클라우드와 온프레미스 환경에서 단일 ID를 제공하여 사용자와 애플리케이션의 접근을 관리한다.. Azure 서비스 구독자는 자동으로 Microsoft Entra ID에 액세스 가능하다.

Azure RBAC (Role Based Access Control; 역할 기반 액세스 제어): Azure Entra ID는 Azure 리소스에 대한 접근 권한을 세밀하게 제어. RBAC를 통해 사용자가 리소스에 접근할 수 있는 권한을 역할 기반으로 할당한다. 사용자에게 역할(권한)을 제공하여 리소스에 대한 액세스를 관리하거나 리소스로 수행할 수 있는 작업과 영역을 제어하는 서비스이다.

Azure 기본 역할 종류:

Reader: 모든 리소스를 볼 수 있지만 변경할 수는 없음. (보안 감사, 모니터링)
Contributor: 모든 리소스를 관리할 수 있지만, 역할 할당, Azure Blueprints 할당 관리, 이미지 갤러리 공유는 불가.
Owner: 모든 리소스를 관리하고, 역할 할당을 포함한 모든 권한을 가짐. (관리자)
Entra ID > [새 사용자] 생성 > Azure Subscription > Resource Group > Access Control(IAM) > 역할 할당

OCI IAM

IAM: 사용자 별로 OCI 서비스의 인증과 액세스 권한을 설정하는 기능

User: Oracle Cloud 리소스에 접근하는 개별 사용자. 각 사용자에게 고유한 자격 증명(예: 사용자명, 비밀번호)이 할당됨. 역할과 정책에 따라 리소스 접근 권한이 부여
Group: 유사한 권한이 필요한 사용자들의 집합. 그룹에 정책을 할당하여 그룹에 속한 모든 사용자에게 동일한 권한을 부여. 그룹 관리를 통해 일관된 접근 제어를 쉽게 수행
Compartment: Oracle Cloud 리소스를 논리적으로 분리하고 관리하기 위한 컨테이너. 각 컴파트먼트 별로 별도의 정책을 정의하여 세분화된 접근 제어를 가능하게 하여 리소스의 접근 제어 및 관리를 효율적
Policy: 사용자 및 그룹이 특정 리소스에 대해 수행할 수 있는 작업을 정의한 규칙

Identity Domain

Domain: 사용자, 그룹, 역할, 정책 관리를 위해 논리적으로 그룹화한 단위이다.
- Default Domain: 테넌시 생성 시 자동 생성되는 기본 도메인. 기본 도메인은 초기 설정 시 모든 사용자와 그룹, 정책을 포함. 별도의 구성이 없을 경우 기본 도메인을 사용하여 모든 관리를 수행.
- 새로운 Domain: 기본 도메인 외의 모든 도메인. OCI에서는 도메인을 사용하여 조직 내에서 부서 또는 프로젝트 별로 독립적인 IAM 관리를 한다.

어려웠던 점 🐹

Azure Resource Group 구조

문제: Resource Group의 의해

해결: Azure Resource Group Docs와 AWS Region을 검색해서 구조 비교

AWS는 Region 하위에 Subnets이 있는데 Azure는 Resource group 하위에 Region 등의 리소스들이 위치한다는 차이가 있다.

애져 리소스 그룹은 생성 시, default region을 생성한다. 리소스 그룹 내의 리소스들은 리소스 그룹의 기본 리전 외에 다른 리전에도 리소스를 생성할 수 있다. 리소스를 다른 리소스 그룹으로 이동을 시킬 수도 있다.

리소스 그룹의 특징:

리소스 그룹에서 다른 그룹으로 리소스 이동이 가능하다.
리소스 그룹과 하위 리소스는 다른 지역에 위치할 수 있다.
리소스 그룹 내 모든 리소스는 수명주기, 보안 설정, 액세스 제어 등을 그룹화하여 관리한다. 즉, 동일한 수명 주기를 공유해야 한다.
리소스 그룹을 삭제하면 리소스 그룹에 포함된 모든 리소스가 삭제된다.

리소스 그룹에서 설정한 모든 설정은 하위 리소스에 상속된다.

AWS/Azure의 장점 비교

문제: 처음 접한 CSP가 AWS여서 AWS 기준으로 Azure를 비교하게 된다.

해결:

CSP 마다 구조와 컨셉이 다르다는 것을 이해하는 것이 중요하다. AWS를 기준으로 생각하는 것은 위험하다.

AWS는 계정 단위로, Azure는 리소스 단위로 리소스를 제어한다.

AWS/Azure 장점 정리:

Azure의 장점: 빌링 세분화
AWS의 장점: 다양한 기능, 높은 내구성

Azure의 장점: 빌링 세분화

AWS는 발생 비용을 하나의 계정에서 통합 결제하는 기능을 가진다. 통합 결제하는 계정은 Payer 계정이고, 하위에 Linked 계정에서 발생하는 비용의 상세 데이터를 제공하여 이를 통해 빌링을 CUR(Cost and Usage Report)로 관리한다.

현재 AWS Organization이 도입되고 Payer 계정을 Master 계정이라고 부른다.

계정별로 발생하는 비용을 관리하는 단일 방법만을 제공하기 때문에 태그를 이용해서 Project, Creator, 사용 목적을 세분화한다.

Azure는 하나의 계정에서 리소스 그룹 별로 발생 비용을 과금하기 때문에 용도 별로 관리하기 편하다.

각 관리 그룹(부서) 내에서도 리소스 그룹(프로젝트 또는 기능)별로 나누어 관리할 수 있기 때문에 정책과 액세스를 중앙에서 제어하며 비용과 리소스를 효과적으로 관리할 수 있다.

Azure 리소스 관리 체계: [Tenant > Management Group(부서) > Subscriptions > Resource groups(프로젝트) > Resources]

Management Group: 조직의 상위 정책 및 액세스를 관리
Subscription: 부서별로 비용 및 리소스를 추적하고 관
Resource Group: 프로젝트별로 관련 리소스를 그룹화하여 관리

AWS의 장점: 다양한 기능, 높은 내구성

AWS는 클라우드 컴퓨팅 시장에서 가장 오래되고 점유율 1위의 플랫폼이다. 다양한 서비스를 제공하기 때문에 거의 모든 IT 요구 사항을 충족시킬 수 있다.

전 세계 여러 지역에 걸쳐 데이터 센터를 운영하여 높은 가용성과 내구성을 보장한다. Azure VM을 통해 서비스 제공 중 애져 내부 이슈로 컴퓨팅 다운 이슈 등이 발생한 적이 있는데 AWS는 비용이 가장 비싸지만 높은 내구성을 보장하기 때문에 아직도 점유율 1위를 유지 중이다.

AWS IAM과 SCP의 역할 차이

문제: AWS IAM와 SCP는 둘 다 리소스의 보안 관리를 하는 기능인데 둘의 차이를 이해하기 어려웠다.

정리:

IAM과 SCP는 2개를 동시에 사용하지 않으며, 각각의 목적과 역할이 다르다.

IAM (Identity and Access Management): 사용자 단위로 권한을 할당하고 부여하는 방식이다. 각 사용자나 역할에 대해 세부적인 권한을 관리할 수 있습니다.
SCP (Service Control Policy): 사용자보다 더 큰 단위인 AWS 계정 단위로 권한을 제어하는 방식이다. 유저보다 더 큰 범위에서 정책을 적용하여, 조직 내의 모든 계정에 대해 서비스 사용 권한을 제어할 수 있다.

결론:

IAM은 개별 사용자 또는 역할 단위로 권한을 세밀하게 관리한다.
SCP는 계정 단위로 권한을 제한하거나 허용하여, 조직 전체의 보안을 강화한다.
따라서 IAM 권한에서 사용 가능하지만 SCP에서 제어한다면 리소스를 사용할 수 없다.