본문 바로가기

Infrastructure/Cloud Computing

[AWS] AWS Organizations

AWS Organizations

이번 장에서는 AWS 관리 및 거버넌스 SaaS중 하나인 AWS Organizations에 대해서 알아본다.


AWS Organizations

  • AWS 리소스를 확장할 때 중앙 집중식으로 환경을 관리할 수 있게 해주는 완전관리형 서비스다.
  • AWS의 많은 사용자들이 다양한 이유로 리소스를 확장하고 여러 AWS 계정의 운영 오버헤드로 인해 운영에 어려움을 겪는 문제를 해결하기 위해 탄생하였다.
  • AWS Organizations 서비스를 사용하면 AWS 계정을 추가 비용 없이 생성할 수 있으며, 조직 내 계정을 사용하여 리소스를 손쉽게 할당하고 계정을 그룹화하며 계정 또는 거버넌스 정책을 적용할 수 있다.

AWS Organizations Feature

AWS 계정 관리

  • AWS 계정은 권한, 보안, 비용 및 워크로드에 대한 자연스러운 경계 역할을 한다.
  • 클라우드 환경을 확장할 때 다중 계정 환경을 사용하는 것이 권장되는 모범 사례이다.
  • AWS 명령줄 인터페이스(CLI), SDK 또는 API를 통해 프로그래밍 방식으로 새 계정을 생성하여 계정 생성을 간소화하고 AWS CloudFormation StackSets를 통해 이러한 계정에 권장되는 리소스 및 권한을 중앙 집중적으로 프로비저닝할 수 있다.

조직 정의 및 관리

  • 새 계정을 생성할 때 단일 애플리케이션 또는 서비스를 지원하는 OU(Organization Unit) 또는 계정 그룹으로 그룹화할 수 있다.
  • 조직에서 리소스를 분류하거나 추적하기 위해 태그 정책을 적용하고 사용자 또는 애플리케이션에 대한 속성 기반 액세스 제어를 제공한다.
  • 지원되는 AWS 서비스에 대한 책임을 계정에 위임하여 사용자가 조직을 대신하여 관리할 수 있다.

액세스 및 권한 제어

  • AWS IAM Identity Center(AWS SSO의 후속 서비스)를 설정하여 Active Directory를 통해 AWS 계정 및 리소스에 대한 액세스를 제공하며, 별도의 작업 역할에 따라 권한을 사용자 지정한다.
  • 사용자, 계정 또는 OU에 서비스 제어 정책(SCP)을 적용하여 조직 내에서 AWS 리소스, 서비스 및 리전에 대한 액세스를 제어할 수 있다.

계정에서 리소스 공유

  • AWS Resource Access Manager(RAM)를 사용하여 조직 내에서 AWS 리소스를 공유할 수 있다.
    예를 들어, AWS VPC 서브넷을 한 번 생성한 후 조직에서 공유할 수 있다.
  • AWS License Manager을 통해 중앙 위치에서 소프트웨어 라이선스에 동의하고, AWS Service Catalog를 통해 여러 계정에서 IT 서비스 및 사용자 지정 제품의 카탈로그를 공유할 수 있다.

규정 준수를 위해 환경 감사

  • 여러 계정에서 AWS CloudTrail을 활성화하면 멤버 계정에서는 수정하거나 끌 수 없는 모든 활동 로그를 클라우드 환경에서 생성할 수 있다.
  • AWS Backup을 통해 지정된 케이던스에서 백업을 시행하는 정책을 설정하거나, AWS Config를 통해 여러 계정 및 AWS 리전에서 리소스에 대해 권장되는 구성 설정을 정의할 수 있다.

중앙 집중식으로 결제 및 비용 관리

  • 조직에서는 하나의 통합된 결제 방식을 제공한다.
  • AWS Cost Explorer를 사용하여 여러 계정에서 리소스 사용을 보고 비용을 추적하며, AWS Compute Optimizer를 사용하여 컴퓨팅 리소스 사용을 최적화할 수 있다.

모범 사례

다중 계정 AWS 환경을 설정해야 하는 이유

  • AWS를 통해 가장 유연하고 안전한 클라우드 환경에서 더 빠르게 실험하고, 혁신하고 크기를 조정할 수 있다.
  • AWS가 애플리케이션의 보안을 보장하는 중요한 수단은 AWS 계정이다.
  • AWS 계정은 AWS 리소스에 대한 자연 보안, 액세스 권한 및 결제를 제공하고 리소스 독립성과 격리를 달성할 수 있도록 한다. 예를 들어, 계정 외부의 사용자는 기본적으로 리소스에 액세스할 수 없다.
  • 마찬가지로 사용하는 AWS 리소스 비용은 계정에 할당된다.
  • 단일 계정으로 AWS를 사용할 수 있지만 AWS에서는 워크로드의 규모와 복잡성이 증가함에 따라 여러 계정을 설정할 것을 권장한다.
  • 다중 계정 환경을 사용하는 것은 AWS 모범 사례로 아래와 같은 여러 이점을 제공한다.
    • 다양한 요구 사항에 대한 신속한 혁신: 회사 내 여러 팀, 프로젝트 또는 제품에 AWS 계정을 할당하여 각자의 보안 요구 사항을 허용하면서 빠르게 혁신하도록 보장할 수 있다.
    • 간소화된 결제: 여러 AWS 계정을 사용하면 AWS 요금이 부과된 제품 또는 서비스 라인을 식별할 수 있어서 AWS 비용을 할당하는 방법이 간소화된다.
    • 유연한 보안 제어: 여러 AWS 계정을 사용하여 특정 보안 요구 사항이 있거나 HIPAA 또는 PCI와 같은 규정 준수에 대한 엄격한 지침을 충족해야 하는 워크로드 또는 애플리케이션을 격리할 수 있다.
    • 비즈니스 프로세스에 쉽게 적응: 다양한 운영, 규제 및 예산 요구 사항이 있는 회사 비즈니스 프로세스 상의 다양한 요구 사항을 가장 잘 반영하는 방식으로 여러 AWS 계정을 쉽게 구성할 수 있다.
  • 궁극적으로 다중 계정 AWS 환경을 사용하면 클라우드를 통해 더 빠르게 이동하고 차별화된 제품 및 서비스를 구축하는 동시에 안전하고 확장 가능하며 탄력적인 방식으로 이를 수행할 수 있다.
  • “랜딩 존”은 AWS에서 권장하는 안전하고 생산적인 다중 계정 AWS 환경 구축 요소를 안내한다. 이는 AWS 워크로드가 증가함에 따라 유연성을 허용하면서 초기 프레임워크를 구축하는 데 사용할 수 있는 모범 사례를 나타낸다.

다중 계정 AWS 환경 설정을 위한 모범 사례

  • 잘 설계된 다중 계정 AWS 환경 기반은 여러 계정을 중앙에서 관리하고 통제할 수 있는 AWS 서비스인 “AWS Organizations”다.
  • 조직 단위(OU, Organization Unit)는 AWS Organization에 있는 계정의 논리적 그룹이며, 이를 사용하여 계정을 계층 구조로 구성하고 관리 제어를 더 쉽게 적용할 수 있다. “AWS Organizations 정책”은 이러한 제어를 적용하는 데 사용된다.
  • SCP(서비스 제어 정책)은 조직의 계정에서 수행할 수 있는 Amazon EC2 실행 인스턴스와 같은 AWS 작업을 정의하는 정책이다.
  • OU는 회사의 보고 구조를 반영하기보다는 기능 또는 공통 제어 집합을 기반으로 해야 하며, AWS에서는 보안과 인프라를 염두에 두고 시작하는 것을 권장한다.
  • 대부분의 기업에는 전체 조직에 이러한 요구 사항에 대한 서비스를 제공하는 중앙 집중식 팀이 있다. 따라서 특정 기능에 대한 기본 OU 세트를 만드는 것이 권장된다.
    • 인프라: 네트워킹 및 IT 서비스와 같은 공유 인프라 서비스에 사용한다. 필요한 인프라 서비스 유형별 계정을 생성한다.
    • 보안: 보안 서비스에 사용한다. 로그 아카이브, 보안 읽기 전용 액세스, 보안 도구 및 비상용 계정을 생성한다.
  • 대부분의 회사가 프로덕션 워크로드에 대해 여러 정책 요구 사항을 가지고 있다는 점을 감안할 때 인프라 및 보안에는 비프로덕션(SDLC) 및 프로덕션(Prod)에 대한 중첩 OU가 있을 수 있다.
  • SDLC OU 계정은 비프로덕션 워크로드를 호스팅하므로 다른 계정에 프로덕션 종속성이 없어야 한다.
  • 수명 주기 단계 간 OU 정책에 변동이 있는 경우 SDLC를 여러 OU(예: 개발 및 사전 프로덕션)로 분할할 수 있다.
  • Prod OU 계정은 프로덕션 워크로드를 호스팅한다.
  • OU 수준에서 정책을 적용하여 요구 사항에 따라 “Prod” 및 “SDLC” 환경을 관리한다. 일반적으로 OU 수준에서 정책을 적용하는 것이 정책 관리 및 잠재적인 문제 해결을 단순화하므로 개별 계정 수준보다 더 나은 방법이다.

  • 중앙 서비스가 배치되면 제품이나 서비스를 구축하거나 실행하는 것과 직접적으로 관련된 OU를 만드는 것이 좋다.
    • 샌드박스: 개별 개발자가 AWS 서비스를 실험하는 데 사용할 수 있는 AWS 계정을 보유한다. 이러한 계정이 내부 네트워크에서 분리될 수 있는지 확인하고 과도한 사용을 방지하기 위해 사용 상한선을 설정한다.
    • 워크로드: 외부용 애플리케이션 서비스를 호스팅하는 AWS 계정을 포함한다. 프로덕션 워크로드를 격리하고 엄격하게 제어하려면 SDLC 및 Prod 환경(기본 OU 환경과 유사)에서 OU를 구성해야 한다.
  • 기본 OU와 프로덕션 지향 OU가 모두 설정되면, 특정 요구 사항에 따라 유지 관리 및 지속적인 확장을 위해 OU를 추가하는 것이 좋다. 아래는 사례를 기반으로한 몇 가지 공통 주제다.
    • 정책 준비: 제안된 정책 변경 사항을 조직에 광범위하게 적용하기 전에 테스트할 수 있는 AWS 계정을 보유한다. 의도한 OU 계정 수준에서 변경 사항을 구현하여 시작하고 다른 계정, OU 및 나머지 조직 전반에 천천히 적용한다.
    • 일시 중지됨: 해지되어 조직에서 삭제되기를 기다리는 AWS 계정을 포함한다. 모든 작업을 거부하는 SCP를 이 OU에 연결한다. 계정을 복원해야 하는 경우 추적 가능성에 대한 세부 정보를 통해 계정에 태그를 지정했는지 확인한다.
    • 개별 비즈니스 사용자: 비즈니스 생산성 관련 애플리케이션 생성(예: 보고서 또는 파일을 파트너와 공유하기 위해 S3 버킷을 설정)이 필요할 수 있는 비즈니스 사용자를 위한 AWS 계정이 포함된 제한된 액세스 OU다.
    • 예외: 워크로드 OU에 정의된 것과 다른, 고도로 맞춤화된 보안 또는 감사 요구 사항이 있는 비즈니스 사용 사례에 사용되는 AWS 계정을 보유한다. 예를 들어, 비공개의 새 애플리케이션 또는 기능을 위해 특별히 AWS 계정을 설정한다. 계정 수준에서 SCP를 사용하여 맞춤형 요구 사항을 충족한다. CloudWatch Events 및 AWS Config 규칙을 사용한 탐지 및 대응 시스템 설정을 고려해야 한다.
    • 배포: CI/CD 배포용 AWS 계정을 포함한다. 워크로드 OU(Prod 및 SDLC)의 계정과 비교하여 CI/CD 배포에 대한 다른 거버넌스 및 운영 모델이 있는 경우 이 OU를 생성할 수 있다. CI/CD 배포는 중앙 팀에서 운영하는 공유 CI/CD 환경에 대한 조직의 종속성을 줄이는 데 도움이 된다. 워크로드 OU 애플리케이션에 대한 각 SDLC/Prod AWS 계정 세트에 대해 배포 OU에 CI/CD용 계정을 생성한다.
    • 과도기: 기존 계정 및 워크로드를 조직의 표준 영역으로 이동하기 전에 임시 보관 영역으로 사용된다. 이는 계정이 인수된 회사의 일부이거나, 이전에 서드 파티에서 관리되었거나, 이전 조직 구조의 레거시 계정이기 때문일 수 있다.

결론

  • 잘 설계된 다중 계정 전략은 보안 및 확장성 요구 사항을 충족하는 동시에 AWS에서 더 빠르게 혁신하는 데 도움이 된다.

  • AWS Organizations 시작 가이드를 참조하여 자체적으로 다중 계정 AWS 환경을 구축하거나, AWS Control Tower를 사용하여 클릭 몇 번으로 안전한 초기 AWS 환경을 빠르게 설정할 수 있다.

참고 사항

용어 정리

  • 조직(Organization): AWS 계정 집합을 결합하여 생성하는 엔티티를 나타낸다. 이러한 모든 회원 계정은 조직 내에서 관리된다.
  • 루트(Root): 조직에 통합된 모든 계정을 보유하는 상위 컨테이너다. 루트 사용자 계정은 조직을 생성할 때 AWS에서 자동으로 생성된다.
  • 조직 단위(Organization Unit): 루트 내의 계정에 대한 컨테이너 역할을 한다. OU는 다른 OU를 포함할 수도 있으므로 계층 구조를 만들 수 있다. 계층 구조는 맨위에 “루트”가 있다.
  • 계정(Account): 모든 AWS 리소스를 포함하는 일반 AWS 계정이다. 사용자는 새 계정을 만들거나 조직에 가입하도록 다른 사람을 초대할 수 있다. 조직을 생성하는 계정을 “마스터 계정”이라고 하고 다른 계정을 “멤버 계정”이라 한다.
  • 초대(Invitation): 다른 계정을 조직에 초대하는 프로세스를 설명하는 데 사용된다. “마스터 계정 사용자”만 초대를 발행할 수 있다. 초대된 계정은 초대를 수락하면 회원 계정이 된다. 조직에서 모든 기능 활성화와 같은 변경 사항을 원할 때 현재 구성원에게 초대장을 보낼 수도 있다.
  • 핸드셰이크(Handshake): 두 당사자(개시자와 수신자)가 정보를 교환하는 프로세스다.

서비스 제어 정책(SCP, Service Control Policy)

  • 서비스 제어 정책(SCP)는 조직에서 권한을 관리하는 데 사용할 수 있는 조직 정책 유형이다. 조직의 모든 계정에 대해 사용 가능한 최대 권한에 대한 중앙 제어를 제공한다.

  • SCP는 아래와 같은 요점을 가지고 있다.
    • 화이트리스트 또는 블랙리스트 IAM 작업을 한다.
    • OU 또는 계정 수준에서 적용된다.
    • 마스터 계정에는 적용이 불가능하다.
    • SCP는 “루트 사용자”를 포함하여 계정의 모든 사용자 및 역할에 적용된다.
    • SCP는 서비스 연결 역할에 영항을 미치지 않는다.
    • 서비스 연결 역할은 다른 AWS 서비스가 AWS Organizations와 통합할 수 있도록 하며 SCP에 의해 제한될 수 있다.
    • SCP는 기본적으로 아무 것도 허용하지 않기 때문에, 명시적 허용이 있어야 한다.
    • 사용 사례
      • 특정 서비스에 대한 액세스 제한(예: EMR을 사용할 수 없음)
      • 서비스를 명시적으로 비활성화하여 PCI 규정 준수 시행

AWS Organizations의 기능

  • 계정 관리: AWS Organization이 제공하는 주요 이점은 “마스터 계정”이라고도 하는 단일 AWS 계정에서 여러 계정을 중앙에서 관리할 수 있는 기능이다. 사용자는 서비스에 직접 새 계정을 생성하여 기존 계정을 조직에 연결하고 앞으로 나아갈 수 있다.
  • AWS 환경에 대한 제어력: 항상 루트(마스터 계정), 조직 단위 또는 개별 계정에 연결된 서비스 제어 정책(SCP)을 사용하여 마스터 계정의 관리자는 특정 API에 이르기까지 어떤 서비스와 기능에 대한 완전한 데어 권한을 얻는다. 사용자의 자격 증명 기반 또는 리소스 기반 권한에 관계없이 해당 계정 내의 IAM 사용자가 사용할 수 있는 호출.
  • 통합 결제: AWS 조직의 루트 계정은 AWS 계정의 모든 구성원의 청구서 및 비용을 통합하는 데 사용할 수 있다. 이를 통해 개별 AWS 계정에 대한 전반적인 비용 관리를 높일 수 있다.
  • 계정 분류 및 그룹화: 조직 단위를 사용하면 각 OU와 연결된 서로 다른 SCP를 적용하여 특정 AWS 계정을 함께 분리하고 그룹화할 수 있다. 예를 들어, 분석 서비스에 액세스할 수 없는 AWS 계정이 여러 개 있는 경우다. 이 경우 이러한 계정을 단일 OU에 배치하고 이 기능을 거부하는 SCP를 할당할 수 있다.

조직 생성 및 구성

  • 조직 생성: 현재 AWS 계정을 마스터 계정으로 사용하여 조직을 생성한다. 또한 하나의 AWS 계정을 초대하여 조직에 가입하고 두 번째 계정을 멤버 계정으로 생성한다.
  • OU 생성: 새 조직에 두 개의 OU를 만들고 해당 OU에 구성원 계정을 배치한다.
  • SCP 생성: SCP를 사용하여 멤버 계정의 사용자 및 역할에 위임할 수 있는 작업에 제한을 적용할 수 있다. 이미지에서는 두 개의 SCP를 만들어 조직의 OU에 연결한다.
  • 조직의 정책: 각 테스트 계정에서 사용자로 로그인하여 SCP가 계정에 미치는 영향을 확인할 수 있다.

AWS Organizations SCP와 IAM 정책의 차이점

  • AWS Organizations의 SCP는 AWS 계정 내 연결 IAM(Identity and Access Management) 정책을 대체하지 않는다.
  • IAM 정책은 IAM과 함께 작동하는 AWS 서비스 또는 API 작업에 대한 액세스를 허용하거나 거부할 수 있다. IAM 정책은 IAM 자격 증명(사용자, 그룹 또는 역할)에만 적용할 수 있다. IAM 정책은 AWS 계정 루트 또는 마스터 사용자를 제한할 수 없다.
  • SCP를 사용하여 AWS Organizations 계정이 있는 개별 AWS 계정 또는 OU내의 계정 그룹에 대해 AWS 서비스에 대한 액세스를 허용하거나 거부할 수 있다. 연결된 SCP 지정된 작업은 루트 또는 마스터 계정을 포함한 모든 IAM 자격 증명에 영항을 미친다.
  • AWS 계정 또는 상위 OU와 연결된 SCP에서 명시적으로 허용하지 않은 AWS 서비스는 SCP와 연결된 AWS 계정 또는 OU에 대한 액세스가 거부된다. OU와 연결된 SCP는 해당 OU의 모든 AWS 계정에 상속된다.

참고 자료

'Infrastructure > Cloud Computing' 카테고리의 다른 글

[AWS] Landing Zone 개념  (0) 2022.12.16
[AWS] AWS Organizations 관련 서비스  (0) 2022.12.16
[Well-Architected] Tools  (0) 2022.11.15
[Well-Architected] Reviews  (0) 2022.11.15
[Well-Architected] Cost Optimization Pillar  (0) 2022.11.15