여러 AWS 계정에서 IAM 사용자를 효율적으로 관리하기

비즈니스 규모가 확장되고, 시스템 규모에 따라 AWS 계정을 여러개 소유하는 것을 고려할 수 있다. 주로 다음과 같은 이유로 여러 계정을 사용하게 된다.

 

  • 보안 격리
    민감한 데이터나 중요 시스템을 별도의 계정으로 분리함으로써, 보안 사고 발생 시 피해를 최소화할 수 있다.
    ex. 운영(Production) 계정과 개발(Development) 계정을 분리하여 권한 접근을 제한함.
  • 비용 분리 및 청구 관리
    부서나 프로젝트별로 계정을 분리하면, 비용 추적이 명확해지고 예산 관리를 체계적으로 할 수 있다.
    ex. 마케팅, 데이터 분석, 서비스 운영 계정을 분리하여 각 부서별 비용 리포팅이 가능함.
  • 정책 및 거버넌스 적용 용이성
    계정 단위로 조직 정책(예: SCP, IAM 정책)을 적용하면 일관된 거버넌스와 보안 정책을 유지하기 쉽다.
  • 서드파티 접근 또는 파트너 협업 용이성
    외부 업체 또는 협력사가 필요한 리소스만 접근할 수 있도록 별도 계정을 구성할 수 있다.
  • 리스크 분산 및 장애 대응
    하나의 계정에 모든 시스템을 몰아넣을 경우 단일 장애 지점(SPOF)이 생길 수 있다. 이를 계정 분리로 방지할 수 있다.

하지만, AWS 계정 개수가 늘어나면 늘어날수록 관리가 복잡해지고, 보안 위험도 커지게 된다. 해당 경우, 역할 전환(Switch Role)을 활용하여 효율적으로 관리할 수 있다. 

 

역할 전환(Switch Role)

역할 전환이란 IAM 사용자를 각 AWS 계정에 따로 만들지 않고, 중앙의 하나의 계정(점프 계정) 에서 로그인하여, 다른 계정의 역할(Role)을 전환하여 접근하는 방식이다. 역할 전환을 이용하면 IAM 사용자로 로그인할 AWS 계정은 한 개로도 충분하다. 이러한 계정은 점프 계정(Jump Account)라고 한다.

 

그럼, 직접 점프 계정을 만들어보고 실습까지 해보도록 하자.

 

1. 점프 계정에 IAM 사용자 생성

 AWS IAM 서비스에 접속하여 사용자 생성 버튼을 클릭한다.

 

다음과 같이 작성해준다.

 

 

점프 계정에서 로그인하고 싶은 대상 계정의 sts:AssumeRole을 허용해야하기 때문에 직접 정책 연결을 선택해주고, 정책 생성 버튼을 눌러 정책을 생성해줘야 한다.

 

아래와 같은 정책을 생성해준다. 아래 정책은 점프 계정의 Jump-user가 대상 계정의 JumpRole 역할로 전환할 수 있도록 sts:AssumeRole 권한을 부여하는 정책이다. Resoruce에는 이따가 2번에서 생성할 역할의 ARN 값을 넣어주면 된다.

sts:AssumeRole이란?
다른 AWS 계정의 IAM 역할(Role)을 일시적으로 사용(전환)하도록 허용하는 권한이다.
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": <2번에서 생성하는 대상 계정에서 생성한 역할의 ARN>
  }
}

 

아래와 같이 정책 이름을 설정해주고 생성 버튼을 클릭한다.

 

다시 IAM 사용자 권한 설정 창으로 돌아온 후 권한 정책에 방금 생성한 정책을 검색해주고 선택해준다.

 

사용자 생성 버튼을 눌러 IAM 사용자를 생성해준다.

 

아래와 같이 성공적으로 생성된 것을 확인한다.

 

2. 대상 계정에 역할 생성

 

이제 접속 대상의 계정에서 IAM 역할을 생성해줘야 한다.

 

아래와 같이 신뢰할 수 있는 엔터티로 AWS 계정을 선택해주고, 점프 계정의 ID 값을 입력하여 점프 계정이 해당 계정의 역할을 사용할 수 있도록 설정한다. 설정한 후 우측 하단 다음 버튼을 클릭한다.

 

테스트용이기 때문에 Admin 권한을 할당해준다. 실제로는 해당 점프 계정의 최소 권한 만큼만 할당해줘야 한다. 권한을 할당 후 다음을 클릭해준다.

 

역할 이름을 입력하고, 여태 지정한 설정들을 확인해준 후 역할 생성 버튼을 클릭한다.

 

생성한 역할의 ARN을 확인해준다.

이 ARN 값을 위 1번의 점프 계정 정책의 Resource 값에 넣어주면 된다.

 

Jump 계정 테스트

1번에서 생성한 IAM 사용자(Jump-user)로 로그인해준 뒤, 우측 상단에 계정을 클릭해준다.

 

[세션 추가]를 클릭해준다. 

 

역할 전환을 클릭해준다.

 

아래 내용들을 입력하고 역할 전환을 클릭해준다. 주의할 점은 두번째 IAM 역할 이름란에는 대상 계정에서 생성한 JumpRole 역할의 ARN 값이 아니라 '역할의 이름'(JumpRole)을 기입해줘야한다. 각자 설정한 역할의 이름으로 잘 기입해주자.

 

아래와 같이 성공적으로 JumpRole로 역할 전환이 되었고, 점프 계정으로 adminRole을 갖고 대상 계정을 이용할 수 있게 되었다. 

 

마무리

여태까지 점프 계정을 통해 다른 계정을 이용할 수 있는 방법을 살펴보았다. 우리가 기존에 흔히 알고 있는 베스천 서버(Bastion Server)의 개념이랑 비슷하다고 보면 되겠다. 베스천 서버도 하나의 단일 진입점을 통해 여러 서버에 접속을 하게 되는데, 점프 계정도 마찬가지이기 때문이다.

 

점프 계정에서 각 AWS 계정으로 역할 전환은 IAM 정책으로 제어하게 된다. 하지만, 사용자가 많아질수록 위와 같은 방식으로 각 점프계정마다 정책을 등록해주는 것도 한계가 있을 것이다.

 

그래서 실제 운영 환경에서는 각 점프 계정마다 정책을 부여하지 않고, IAM 그룹에 권한을 부여한 뒤 사용자만 넣고 빼며 역할을 제어하는 방식으로 운영하는 것이 효율적이다. 그러면 IAM 그룹을 통해 점프 계정을 관리하는 과정은 다음과 같이 될 것이다.

  1. 점프 계정에 IAM 그룹을 여러 개 생성
    • ex. 운영계정_읽기전용, 운영계정_전체권한, 개발계정_읽기전용 등
  2. 각 IAM 그룹에 sts:AssumeRole 권한 정책을 부여
    • 그룹마다 접근 대상 역할(다른 계정의 Role ARN)이 다름.
  3. 사용자는 해당 그룹에만 추가/제거
    • 특정 계정으로의 역할 전환 권한 부여 또는 제거는 그룹 소속으로 제어됨.

 

오늘은 점프 계정을 통해 AWS 계정들을 효율적으로 운영할 수 있는 방법을 알아보았다. 하지만 조직의 규모가 커지고, 계정 수가 수십 개 이상으로 확장되는 시점에서는 AWS Organizations의 도입이 더 적합한 경우가 많다. 현업에서는 다음과 같은 기준으로 두 방식을 선택하거나 병행해서 사용하는 경우가 많다.

  • 소규모 스타트업 / 초기 단계 팀
    → Jump 계정 + IAM 그룹 방식으로 시작
    → 관리가 단순하고 빠르게 접근 제어가 가능하기 때문
  • 계정 수가 많고, 보안/예산/정책 통제가 필요한 조직
    → AWS Organizations 기반의 통합 거버넌스 체계 구축
    → SCP, 통합 청구, SSO, 계정 자동화 등 활용

실제로는 Jump 계정 구조를 그대로 유지하면서, AWS Organizations을 도입해 하이브리드 구조로 운영하는 사례도 많다.
예를 들어, Identity Center(구 SSO)를 도입하여 Jump 계정 사용자 인증을 관리하고, Organizations 내 계정들을 정책적으로 제어하는 방식도 있다.

 

결국 중요한 것은 우리 조직의 현재 규모와 목적에 따라 적절한 방식을 선택하는 것이다. Jump 계정은 빠르고 유연한 접근 통제에 강점이 있고, Organizations는 보안 정책 통제와 장기적인 확장성에서 유리하다. 두 구조의 차이를 명확히 이해하고, 필요에 따라 적절히 결합하여
안정적이면서도 확장 가능한 멀티 계정 운영 구조를 만드는 것이 가장 중요하다고 생각한다.

티스토리툴바