[AWS][계정 분산 관리] 1. 계정 분산 관리의 필요성과 전체 구조

1. AWS 계정 분산 관리의 필요성

• AWS 클라우드 인프라를 사용하는 프로젝트나 각 프로젝트의 인스턴스 수가 많아질수록, 단일 AWS 계정으로 모든 자원을 관리하는 데에서 아래와 같은 불편함이 발생할 수 있습니다.

  1. 프로젝트별 비용 추적이 어려움
  2. 프로젝트별 권한 관리의 복잡성
  3. 리소스 충돌 (네이밍 충돌 등)
  4. 한번의 설정 오류로 인한 모든 리소스 노출 위험
  5. 운영 복잡성의 증가
  6. 서비스 한도 설정의 어려움

• 위와 같은 불편을 줄이기 위해 프로젝트별 계정을 생성해 독립성을 확보하고, 관리 효율성을 높이기 위해 통합 관리 계정을 두어 중앙 집중적으로 관리하는 방식입니다.

• AWS 계정 분산 관리를 위한 네 가지 단계에 대한 개요는 아래와 같습니다.

  1. VPC Peering: VPC 간의 접근
  서로 다른 VPC 간의 통신을 가능하게 하기 위해 Peering을 설정

  2. Bastion Host Server: 중앙 집중형 인스턴스 접근
  통합 관리 계정에 Bastion Host Server 생성해 프로젝트별 인스턴스에 대한 중앙 집중형 접근을 제공

  3. NAT Server & Port Forwarding: NAT Server를 사용해 프로젝트별 Private Subnet 접근
  프로젝트별 NAT Server를 구축하고 Port Forwarding을 설정하여 Private Subnet에 위치한 인스턴스에 접근

  관리 오버헤드 감소를 위해 AWS VPC NAT Gateway 사용을 고려하는 것이 권장되나, 비용 문제로 해당 글에서는 EC2 프리티어 인스턴스로 직접 NAT 서버를 구축합니다.

  4. Switch Role 활용: 통합 콘솔 관리
  하나의 IAM 계정을 통해 각 프로젝트별 AWS 콘솔에 접근하며, 필요한 역할에 따라 접근 권한을 부여

2. 전체 구조

Redis(ElastiCache) 관련 내용은 이해를 돕기위한 내용으로 해당 시리즈에선 다루지 않습니다.

3. 사전 조건

• 분산 관리를 구성하기 위해서는 최소한 다음의 사전 조건이 필요합니다.

  1. AWS 계정 1: 통합 관리 계정으로 사용할 Root격의 AWS 계정
  2. AWS 계정 2: 임의의 프로젝트에 사용할 AWS 계정
  3. 각 계정의 VPC: 계정 간 CIDR이 겹치지 않는 VPC
     (해당 시리즈의 글에선 통합 관리 계정은 10.0.0.0/16 , 프로젝트 계정은 10.100.0.0/16 을 사용합니다.)
  4. 리소스 네이밍 전략: 개발, 운영 등 환경의 구분과 리소스 타입의 구분 등

---

다음 글: [AWS][계정 분산 관리] 2. VPC Peering: VPC 간의 접근