IAM 사용자 대신 IAM Identity Center를 쓰는 이유, 여러 계정 로그인을 한 곳에서

AWS를 처음 쓸 때는 사람마다 IAM 사용자를 만들고, 비밀번호와 액세스 키를 나눠 주는 방식으로 시작하는 경우가 많습니다. 계정이 하나이고 사람이 몇 명뿐일 때는 이 방식도 큰 불편이 없습니다. 그런데 계정이 개발·운영으로 나뉘고 사람이 늘어나면, 계정마다 사용자를 만들고 퇴사자를 계정마다 찾아 지우는 일이 금세 버거워집니다.

 

AWS IAM Identity Center(예전 이름 AWS Single Sign-On)는 사람의 로그인을 한 곳에 모으는 서비스입니다. 사용자는 접근 포털 한 곳에 로그인해서 자신에게 허용된 계정과 역할을 골라 들어가고, 관리자는 사용자와 권한을 한 곳에서 관리합니다. AWS는 이 서비스를 추가 요금 없이 제공합니다.

 

이 글은 IAM 사용자 방식과 Identity Center 방식을 나란히 비교하고, 권한 세트로 권한을 나누는 방법과 처음 설정하는 순서를 정리합니다.

 

IAM 사용자 대신 IAM Identity Center를 쓰는 이유, 여러 계정 로그인을 한 곳에서

 

두 방식 한눈에 비교

구분	계정마다 IAM 사용자	IAM Identity Center
로그인 위치	계정마다 따로	접근 포털 한 곳
사람 추가·삭제	계정마다 반복	한 번
자격 증명	오래 유지되는 비밀번호·액세스 키	로그인할 때마다 발급되는 임시 자격 증명
권한 관리	계정마다 정책 연결	권한 세트를 만들어 여러 계정에 배포
CLI 사용	액세스 키를 PC에 저장	aws configure sso로 로그인, 자격 증명 60분 유효
추가 요금	없음	없음

 

가장 큰 차이는 오래 유지되는 자격 증명이 사라진다는 점입니다. IAM 사용자의 액세스 키는 누군가 지우기 전까지 계속 유효해서, PC나 코드 저장소에 남은 키가 유출되면 바로 사고로 이어집니다. Identity Center에서 CLI로 받는 자격 증명은 60분 동안만 유효하고, 필요할 때마다 다시 받습니다.

 

권한 세트로 직무별 권한을 나눕니다

Identity Center에서 권한은 권한 세트라는 묶음으로 관리합니다. "관리자", "개발자", "읽기 전용"처럼 직무별 권한 세트를 만들고, 사용자나 그룹을 특정 계정에 이 권한 세트로 배정하면 해당 계정에 역할이 자동으로 만들어집니다.

 

사람이 늘고 계정이 나뉘면, 로그인을 한 곳에 모으는 쪽이 관리와 보안 모두 쉬워집니다

 

권한 세트 예	들어갈 정책	배정 예
Admin	AdministratorAccess	운영 담당 그룹 → 모든 계정
Developer	PowerUserAccess 또는 직접 만든 정책	개발자 그룹 → 개발 계정
ReadOnly	ReadOnlyAccess	개발자 그룹 → 운영 계정

 

같은 개발자라도 개발 계정에서는 개발 권한, 운영 계정에서는 읽기 권한만 갖도록 배정할 수 있습니다. 권한 세트는 계정 접근을 관리하는 조직 인스턴스에서 쓸 수 있는 기능이고, AWS는 운영 환경에서는 Organizations 관리 계정에 만드는 조직 인스턴스를 모범 사례로 권장합니다.

 

처음 설정하는 순서

1. Organizations 조직을 만들고, 관리 계정에서 IAM Identity Center를 켭니다.
2. 사용자를 직접 만들거나, 회사에서 쓰는 외부 ID 제공자(SAML 2.0)를 연결해 사용자와 그룹을 가져옵니다.
3. Admin, Developer, ReadOnly처럼 직무별 권한 세트를 만듭니다.
4. 그룹을 계정과 권한 세트에 배정합니다.
5. MFA를 켭니다. 보안 키나 지문·얼굴 인식 같은 WebAuthn 방식과 인증 앱의 일회용 비밀번호(TOTP)를 쓸 수 있습니다.
6. 사용자가 접근 포털로 로그인되는지 확인한 뒤, 기존 IAM 사용자의 액세스 키를 하나씩 정리합니다.

 

MFA는 처음부터 필수로

로그인이 한 곳으로 모이면 그 한 곳의 보안이 모든 계정의 보안이 됩니다. 그래서 Identity Center를 켤 때 MFA를 선택 사항이 아니라 로그인할 때마다 요구하는 필수 설정으로 두는 것이 좋습니다. 보안 키나 노트북의 지문 인식처럼 피싱에 강한 방식을 우선 쓰고, 인증 앱의 일회용 비밀번호는 보조 수단으로 등록해 두면 기기를 잃어버렸을 때도 대응할 수 있습니다. 사용자가 MFA 기기를 잃어버린 경우를 대비해, 관리자가 기기를 재설정하는 절차도 미리 정해 둡니다.

 

CLI와 개발 도구에서 쓰는 법

콘솔뿐 아니라 AWS CLI도 Identity Center로 로그인할 수 있습니다. 액세스 키를 PC에 저장하지 않아도 되는 것이 가장 큰 장점입니다.

 

1. 터미널에서 aws configure sso를 실행하고, 접근 포털 주소와 리전을 입력합니다.
2. 브라우저가 열리면 Identity Center 사용자로 로그인하고 요청을 승인합니다.
3. 사용할 계정과 권한 세트를 고르면 CLI 프로필이 만들어집니다.
4. 이후에는 aws sso login으로 다시 로그인하고, 명령마다 --profile로 프로필을 지정합니다.

 

이렇게 받은 자격 증명은 60분 동안 유효하고, 만료되면 다시 로그인하면 됩니다. 개발용 PC를 잃어버리거나 저장소에 설정 파일이 올라가더라도 오래 쓸 수 있는 키가 없으니 피해가 작습니다.

 

기존 IAM 사용자에서 옮길 때 확인할 것

확인 항목	보는 곳	판단
액세스 키 마지막 사용일	IAM 자격 증명 보고서	오래 쓰지 않은 키는 비활성화 후 삭제
콘솔 로그인 마지막 날짜	IAM 자격 증명 보고서	로그인하지 않는 사용자는 정리 대상
사람이 아닌 용도의 사용자	사용자 이름·태그	서버·배포 도구용이면 IAM 역할로 전환
그룹별 권한	IAM 그룹 정책	같은 묶음으로 권한 세트를 만듦

 

옮기는 동안에는 두 방식이 잠시 함께 있어도 괜찮습니다. 사람별로 Identity Center 로그인이 되는 것을 확인한 다음, 그 사람의 IAM 사용자 액세스 키를 비활성화하고 일정 기간 문제가 없으면 삭제하는 순서로 진행하면 업무가 끊기지 않습니다.

 

헷갈리기 쉬운 점

• IAM이 없어지는 것은 아닙니다 — Identity Center도 결국 각 계정에 IAM 역할을 만들어 권한을 줍니다. 사람이 직접 쓰는 IAM 사용자를 줄이는 것이지, IAM 정책과 역할은 그대로 씁니다.
• 애플리케이션이 쓰는 키는 별도로 봅니다 — 서버나 람다 함수처럼 사람이 아닌 주체는 Identity Center가 아니라 IAM 역할로 권한을 받는 것이 기본입니다.
• 루트 사용자는 따로 지킵니다 — Identity Center를 쓰더라도 각 계정의 루트 사용자는 MFA를 걸어 두고 거의 쓰지 않는 원칙이 그대로입니다.
• 로그인 기록은 사용자 기준으로 남습니다 — 누가 어느 계정에 어떤 권한 세트로 들어갔는지 CloudTrail에서 사람 단위로 추적할 수 있습니다.

 

Identity Center로 옮길 때 자주 묻는 것

계정이 하나뿐이어도 쓸 가치가 있나요?

계정 접근을 관리하는 조직 인스턴스는 Organizations 조직이 있어야 하므로, 계정이 하나라면 조직을 만들고 그 계정을 관리 계정으로 쓰는 구성이 됩니다. 사람이 여럿이고 앞으로 계정을 나눌 계획이 있다면 처음부터 이렇게 시작하는 편이 나중에 옮기는 것보다 쉽습니다.

 

회사 구글 계정이나 마이크로소프트 계정으로 로그인할 수 있나요?

SAML 2.0을 지원하는 외부 ID 제공자를 연결하면 회사 계정으로 로그인하게 할 수 있습니다. 이때 사람의 추가와 퇴사 처리는 회사 계정 쪽에서 하고, Identity Center는 그 정보를 받아 권한만 배정합니다.

 

권한 세트 설계 예시 — 직무 네 개로 시작하기

Identity Center는 사용자가 아니라 권한 세트를 먼저 설계해야 깔끔해집니다. 작은 팀이 처음 만드는 네 개의 권한 세트를 표로 정리했습니다. Identity Center 자체와 외부 디렉터리 연동에는 요금이 없습니다.

권한 세트	연결 정책	세션 시간	배정 계정
AdministratorAccess	관리형 정책 AdministratorAccess	1시간	전 계정, 2명만
PowerUser	PowerUserAccess (IAM·조직 변경 제외)	4시간	개발 계정
ReadOnly	ReadOnlyAccess + 결제 조회	8시간	전 계정, 전원
Billing	Billing 관리형 정책	4시간	관리 계정만, 회계 담당

권한 세트 하나를 여러 계정에 배정할 수 있으므로 계정이 늘어도 권한 세트 수는 그대로입니다. 관리자 권한은 세션을 짧게 두고, 평소에는 ReadOnly로 들어가 필요할 때만 상위 권한 세트를 고르는 습관이 사고를 줄입니다.

옮기는 날 체크 순서

1. Identity Center를 켜고 사용자를 만든 뒤 MFA를 필수로 설정합니다.
2. 위 표의 권한 세트 네 개를 만들고 계정별로 배정합니다.
3. 기존 IAM 사용자로 하던 일을 Identity Center 로그인으로 하루 동안 해 봅니다. CLI는 aws configure sso로 프로필을 만듭니다.
4. 문제가 없으면 IAM 사용자의 액세스 키를 비활성화하고 일주일 뒤 삭제합니다. 외부 시스템이 쓰던 키는 IAM 역할로 바꿉니다.

이럴 때 바꾸는 것을 권합니다

AWS 계정이 둘 이상이거나, 함께 쓰는 사람이 세 명 이상이거나, 액세스 키를 PC에 저장해 두고 쓰는 사람이 있다면 Identity Center로 옮길 때입니다. 한 번 설정해 두면 사람이 늘거나 줄어도 한 곳에서만 손보면 되고, 오래 남는 키가 줄어드는 만큼 사고 가능성도 줄어듭니다.

 

지금 쓰는 계정에서 IAM 사용자 목록을 열어, 마지막 사용일이 오래된 액세스 키가 있는지부터 확인해 보세요. 그런 키가 있다면 Identity Center로 옮길 이유가 이미 있는 셈입니다.

함께 읽으면 좋은 글: 루트 계정 MFA와 IAM 권한 분리 / 클라우드 공동 책임 모델

참고 자료: IAM Identity Center란, IAM Identity Center FAQ, 조직 인스턴스와 계정 인스턴스

※ 본 글은 2026년 10월 기준 AWS IAM Identity Center 사용 설명서와 FAQ를 참고해 작성했으며, 기능과 지원 방식은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.