[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Establishing Enterprise Architecture on AWS (2018, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 2부로 구성되어 있으며 이 글은 1부입니다.
1부 링크 : AWS에서 엔터프라이즈 아키텍처 구성하기 1/2
Organizational Model
AWS Organizations를 사용하면 AWS 계정을 비즈니스 조직 모델을 반영하는 OU (조직 구성 단위)라는 그룹으로 배열 할 수 있습니다. 이러한 OU 내에서 그리고 중앙에서 관리되는 정책을 정의하고 동일한 방식으로 적용 할 수 있습니다. 조직에서 계정을 만들고 제거하는 방법을 정의 할 수도 있습니다. AWS Organizations를 통해 다음을 수행 할 수 있습니다.
· 클라우드 환경에서 조직 구조 복제
· 글로벌 거버넌스를 유지하면서 비즈니스 단위에 자율성을 부여
· 클라우드 환경 (계정 생성 및 삭제) 및 글로벌 지출 관리
클라우드 환경에서 조직 구조 복제
AWS Organizations에서 루트는 조직의 모든 계정에 대한 상위 컨테이너입니다. OU는 루트 아래에 중첩됩니다. 기존 또는 대상 조직 모델을 반영하도록 OU를 정의 할 수 있습니다. OU에는 계정 또는 다른 OU가 포함될 수 있으며 OU 계층을 만들 수 있습니다.
그림 3은 루트 아래 9 개의 OU로 구성된 14 개의 AWS 계정 (Ax)으로 구성된 조직의 예를 보여줍니다.
이 예에서 OU는 기업의 글로벌 HR (HR), 보안 및 재무 부서, 뉴욕 및 런던 위치 및 4 개의 사업 단위 (BUx)를 나타내며, 이는 기업의 조직 모델을 반영하는 AWS 클라우드 계정 구조를 유지합니다.
비즈니스 단위 및 자율성
글로벌 거버넌스 관행을 유지하면서 비즈니스 단위 자율성을 제공하고 부서와 팀이 새로운 기술과 기술을 탐색 할 수 있는 자율성을 제공하면서도 조직 개요를 유지하는 것은 엔터프라이즈 아키텍처 거버넌스의 두 가지 과제입니다. SCP (Service Control Policies)를 통해 이러한 문제를 해결할 수 있습니다.
SCP는 SCP가 영향을 주는 계정에서 사용자와 역할이 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. 조직의 모든 계층에서 SCP를 적용 할 수 있습니다. 동일한 조직 예를 사용하여 그림 4는 루트 및 HR, 보안, 런던 및 BU1 OU에 적용되는 정책을 보여줍니다.
정책을 루트에 적용하면 조직의 모든 OU 및 계정에 적용됩니다. 예를 들어, 건강 관리 기업의 루트 수준에서 적용된 SCP는 HIPAA를 준수하지 않는 AWS 서비스 7의 사용을 거부하거나 금융 조직에서 PCI-DSS 재무 표준을 준수하지 않는 서비스에 대한 액세스를 거부 할 수 있습니다 . OU는 루트 수준에서 적용된 SCP에 정의 된 비준수 서비스를 사용할 수 없습니다. 서비스가 AWS 리전에서 규격이 되면 정책에 추가 할 수 있습니다.
마찬가지로 비즈니스 기능에 따라 조직 계층 전체에 SCP를 연결할 수 있습니다. 예를 들어 그림 4와 같이 다양한 기능 (HR 및 보안), 현지 시장 (런던) 및 현지 사업부 (BU1)를 기반으로 정책을 첨부 할 수 있습니다.
계층의 노드 중 하나에 정책을 연결하면 모든 OU와 그 아래 계정에 영향을 줍니다. HR, 보안 및 런던 OU와 관련된 SCP는 모든 하위 OU에 적용됩니다. 하위 AWS 계정 또는 OU와 연결된 SCP는이 동작을 변경할 수 없으며 해당 정책의 범위 내에서만 작동 할 수 있습니다.
OU에 SCP를 적용하면 글로벌 거버넌스를 유지하면서 업무 부서에 자율권을 부여 할 수 있습니다.
새 AWS 계정과 기존 AWS 계정을 OU에 추가하고 OU에서 계정을 제거 할 수도 있습니다. 새 계정을 만들 수 있는 OU를 지정할 수도 있습니다. 이러한 계정은 해당 OU의 이전에 정의 된 정책과 동작을 상속합니다.
클라우드 환경 및 글로벌 지출 관리
엔터프라이즈 아키텍트는 또한 조직의 IT 환경의 총 소유 비용에 대해 우려하고 있습니다. 이 활동에서 AWS Organizations가 지원합니다.
AWS Organizations에서는 통합 결제를 통해 조직의 모든 AWS 계정에 대해 단일 결제 방법을 설정할 수 있습니다. 통합 결제를 사용하면 모든 계정에서 발생한 요금에 대한 종합적인보기를 볼 수 있으며 Amazon Elastic Compute Cloud (Amazon EC2) 및 Amazon Simple Storage Service (Amazon S3)에 대한 대량 할인과 같은 집계 사용으로 인한 가격 혜택을 활용할 수 있습니다.
역할과 행위자
비즈니스 아키텍처 도메인에는 행위자와 역할이 있습니다. 행위자는 활동을 시작하거나 상호 작용하는 역할을 는 사람, 조직 또는 시스템 일 수 있습니다. 액터는 엔터프라이즈에 속하며 역할과 함께 비즈니스 기능을 수행합니다.
조직의 행위자를 이해하면 IT 시스템의 사용자 및 소유자를 포함하여 IT와 상호 작용하는 모든 참가자의 명확한 목록을 만들 수 있습니다. 조직 변경 관리 및 조직 변환을 가능하게 하려면 행위자 대 역할 관계를 이해해야 합니다.
기업의 행위자와 역할은 두 가지 수준으로 모델링 할 수 있습니다. 일반적으로 조직에는 행위자와 역할을 반영하는 회사 디렉토리 (예 : Active Directory)가 있습니다. 다른 수준에서 AWS Identity and Access Management (IAM)를 사용하여 이러한 구성 요소를 시행 할 수 있습니다.
IAM은 AWS Organizations를 보완하면서 행위자 역할 관계를 달성합니다. IAM에서 액터는 사용자라고 합니다. OU 내의 AWS 계정은 해당 계정의 사용자와 사용자가 채택 할 수 있는 해당 역할을 정의합니다. IAM을 사용하면 사용자의 AWS 서비스 및 리소스에 대한 액세스를 안전하게 제어 할 수 있습니다. 또한 AWS 사용자 및 그룹을 생성 및 관리하고 권한을 사용하여 AWS 리소스에 대한 액세스를 허용 및 거부 할 수 있습니다.
SCP는 IAM 정책이 IAM 사용자 및 역할과 같은 계정의 엔티티에 부여 할 수 있는 권한을 제한합니다. AWS 계정은 OU에 정의되거나 OU에 상속 된 SCP를 상속합니다. 그런 다음 AWS 계정 내에서 더 세부적인 정책을 작성하여 사용자 또는 역할이 액세스 할 수 있는 방법과 대상을 정의 할 수 있습니다. 이러한 정책은 사용자 또는 그룹 수준에서 적용 할 수 있습니다.
이러한 방식으로 조직의 행위자와 역할에 대해 매우 세부적인 권한을 만들 수 있습니다. OU, 행위자 (사용자) 및 역할 간의 주요 비즈니스 관계를 IAM에 반영 할 수 있습니다.
응용 프로그램 포트폴리오
응용 프로그램 포트폴리오 관리는 엔터프라이즈 아키텍처에서 응용 프로그램 아키텍처 도메인의 중요한 부분입니다. 비즈니스 목표 또는 목표를 달성하는 데 사용되는 조직의 소프트웨어 응용 프로그램 및 소프트웨어 기반 서비스 모음을 관리합니다. 합의 된 응용 프로그램 포트폴리오를 통해 조직에서 표준 응용 프로그램 집합을 사용할 수 있습니다.
AWS Service Catalog를 사용하여 클라우드에서 기업의 애플리케이션 포트폴리오를 관리하고 일반적으로 배포되는 애플리케이션을 중앙에서 관리 할 수 있습니다. 일관성 있는 거버넌스를 달성하고 규정 준수 요구 사항을 충족하는 데 도움이 됩니다.
AWS Service Catalog는 조직이 애플리케이션 카탈로그를 중앙에서 관리 할 수 있는 단일 위치를 제공하여 회사 표준을 준수합니다. AWS Service Catalog를 사용하면 사용 가능한 애플리케이션 및 버전, 사용 가능한 서비스 구성 및 개인, 그룹, 부서 또는 비용 센터 별 권한 액세스를 제어 할 수 있습니다.
AWS 서비스 카탈로그를 통해 다음을 수행 할 수 있습니다.
· 고유 한 응용 프로그램 카탈로그 정의-조직의 최종 사용자는 셀프 서비스 포털을 사용하여 응용 프로그램을 신속하게 검색하고 배포 할 수 있습니다.
· 애플리케이션의 수명주기를 중앙에서 관리-제품을 시작할 수 있는 AWS 리전과 같은 제약 조건을 지정하여 필요에 따라 새로운 애플리케이션 버전을 추가하고 애플리케이션 사용을 제어 할 수 있습니다.
· 세분화 된 수준으로 액세스 권한 부여 — 사용자가 포트폴리오에 대한 액세스 권한을 부여하여 해당 사용자가 제품을 찾아보고 시작할 수 있도록 합니다.
· AWS 리소스 배포 방식 제한-제품에 특정 AWS 리소스를 배포 할 수 있는 방법을 제한 할 수 있습니다. 제약 조건을 사용하여 관리 또는 비용 관리를 위해 제품에 제한을 적용 할 수 있습니다. 예를 들어 마케팅 사용자가 캠페인 웹 사이트를 만들 수 있지만 기본 데이터베이스를 제공하기 위해 액세스를 제한 할 수 있습니다.
거버넌스 및 감사
AWS CloudTrail은 AWS 계정의 관리, 규정 준수, 운영 감사 및 위험 감사를 지원하는 서비스입니다 . CloudTrail을 사용하면 모든 API 호출을 기록 할 수 있습니다. 이를 통해 조직 내부 및 외부의 통제 기관을 준수 할 수 있습니다. CloudTrail은 전체 AWS 환경에서 조직의 투명성을 제공합니다. CloudTrail은 AWS Management Console, AWS SDK, 명령 줄 도구 및 기타 AWS 서비스를 통해 수행 된 작업을 포함하여 AWS 계정 활동의 이벤트 기록을 제공합니다. 이 이벤트 기록은 보안 분석, 리소스 변경 추적 및 문제 해결을 간소화합니다.
Amazon CloudWatch는 AWS 클라우드 리소스 및 AWS에서 실행하는 애플리케이션에 대한 모니터링 서비스입니다 . CloudWatch를 사용하여 지표 수집 및 추적, 로그 파일 수집 및 모니터링, 경보 설정 및 AWS 리소스 변경에 자동으로 대응할 수 있습니다. CloudWatch는 애플리케이션 환경의 동작을 모니터링하고 기록합니다. CloudWatch는 애플리케이션의 동작에 따라 이벤트를 트리거 할 수도 있습니다.
CloudTrail이 AWS 사용을 추적하는 동안 CloudWatch는 애플리케이션 환경을 모니터링합니다. 이 두 서비스를 결합하면 아키텍처 거버넌스 및 감사 기능에 도움이 됩니다.
변경 관리
엔터프라이즈 아키텍트는 전환 아키텍처를 관리합니다. 전환 아키텍처는 현재 상태를 대상 상태 아키텍처로 가져 오는 프로덕션의 증분 릴리스입니다. 전환 아키텍처의 목표는 진화하는 아키텍처가 목표 비즈니스 전략을 지속적으로 제공하도록하는 것입니다.
따라서 아키텍처에 대한 변경 사항을 일관된 방식으로 관리해야 합니다.
AWS Config는 AWS 리소스의 구성을 평가, 감사 및 평가할 수 있는 서비스입니다. AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록하며 원하는 구성에 대해 기록 된 구성의 평가를 자동화 할 수 있습니다. AWS Config를 사용하면 구성 변경 사항을 검토하고 내부 지침에 지정된 구성과 비교하여 전반적인 규정 준수를 결정할 수 있습니다. 이를 통해 컴플라이언스 감사, 보안 분석, 변경 관리 및 운영 문제 해결을 단순화 할 수 있습니다.
엔터프라이즈 아키텍처 리포지토리
엔터프라이즈 아키텍처 저장소는 조직의 현재 및 대상 IT 환경을 설명하는 아티팩트 모음입니다. 엔터프라이즈 아키텍처 리포지토리의 목표는 조직의 기술, 데이터, 응용 프로그램 및 비즈니스 아티팩트 인벤토리를 반영하고 이러한 구성 요소 간의 관계를 보여주는 것입니다.
전통적으로 클라우드 환경이 아닌 환경에서 조직은 엔터프라이즈 아키텍처 저장소 요구를 충족시키기 위해 값 비싼 상용 제품을 선택해야했습니다. AWS 서비스를 통해 이러한 비용을 피할 수 있습니다.
AWS 태깅 및 리소스 그룹을 사용하면 서로 다른 수준으로 태그를 적용하여 AWS 환경을 구성 할 수 있습니다. 태그를 사용하면 서비스 내의 리소스 및 구성 요소에 레이블을 지정하고 수집 및 구성 할 수 있습니다.
태그 편집기를 사용하면 서비스 및 AWS 리전에서 태그를 관리 할 수 있습니다. 이 접근 방식을 사용하면 대상 환경의 모든 응용 프로그램, 비즈니스, 데이터 및 기술 구성 요소를 전체적으로 관리 할 수 있습니다.
자원 그룹은 하나 이상의 태그를 공유하는 자원 모음입니다. 이를 통해 IT 환경에 대한 엔터프라이즈 아키텍처 “보기”를 생성하여 AWS 리소스를 프로젝트 (즉, 대상 환경을 실현하는 진행중인 프로그램), 엔터티 (즉, 기능, 역할, 프로세스) 및 도메인 별 (즉, 비즈니스, 응용 프로그램, 데이터, 기술)보기.
AWS Config, Tagging 및 Resource Groups를 사용하여 회사에서 현재 사용중인 클라우드 자산을 정확하게 확인할 수 있습니다. 이러한 서비스를 통해 대상 프로덕션 환경에 불량 서버 또는 섀도 응용 프로그램이 나타나는 시기를 쉽게 감지 할 수 있습니다.
기존 라이센스 계약 또는 레거시 프로세스로 인해 기존 리포지토리 도구를 계속 사용하고 싶을 수도 있습니다. 이 시나리오에서 엔터프라이즈 리포지토리는 EC2 인스턴스에서 기본적으로 실행되며 이전과 같이 유지 관리 할 수 있습니다.
결론
엔터프라이즈 아키텍트의 역할은 조직이 혁신적이고 변화하는 고객 행동에 신속하게 대응할 수 있도록 하는 것입니다. 엔터프라이즈 아키텍트는 조직의 장기적인 비즈니스 비전을 보유하고 있으며 이 목표 환경에 도달하는 데 필요한 여정을 담당합니다. 그들은 모든 영역에서 성공적으로 진화함으로써 목표를 달성 할 수 있도록(비즈니스, 응용 프로그램, 기술 및 데이터) 조직을 지원합니다.
클라우드로 이동할 때도 마찬가지입니다. 엔터프라이즈 아키텍트 역할은 성공적인 클라우드 채택의 핵심입니다. 엔터프라이즈 아키텍트는 AWS 서비스를 아키텍처 빌딩 블록으로 사용하여 기업의 비즈니스 비전을 실현하기 위해 조직의 기술 결정을 안내 할 수 있습니다.
엔터프라이즈 아키텍트는 온-프레미스 아키텍처로 목표를 측정하고 그 가치를 입증하기가 어려웠습니다. AWS 클라우드 도입을 통해 엔터프라이즈 아키텍트는 AWS 서비스를 사용하여 엔터프라이즈 아키텍처 도메인에서 추적 성과 관계를 생성 할 수 있으므로 아키텍처가 조직의 변화와 개선을 정확하게 추적 할 수 있습니다. 엔터프라이즈 아키텍트는 AWS를 통해 엔드 투 엔드 추적 성, 운영 모델링 및 거버넌스를 처리 할 수 있습니다. 조직이 대상 상태로 이동할 때 클라우드에서 전환 아키텍처에 대한 데이터를 수집하는 것이 더 쉽습니다.
광범위한 AWS 서비스와 민첩성으로 인해 아키텍처 편차가 확인되고 변경이 필요할 때 건축가와 애플리케이션 팀이 보다 신속하게 대응할 수 있습니다.
AWS 서비스를 사용하면 엔터프라이즈 아키텍처 사례의 가치를 보다 쉽게 실행하고 실현할 수 있습니다.
AWS는 IT 인프라 비용을 절감하고 기업의 핵심가치에 더욱 집중할 수 있도록 합니다.
AWS에 대한 자세한 문의사항은 여기를 눌러 주세요.
빌드업웍스는 AWS 컨설팅 파트너로 고객 비즈니스를 최우선으로 하며 고객의 클라우드의 성공적인 시작과 운영을 지원합니다.
