# AWS IAM과 Microsoft Entra ID의 사용자, 그룹, 역할 화면 나란히 비교하기

> 앞서 직접 열어 본 AWS IAM 화면과 Microsoft Entra ID 화면을 같은 질문으로 나란히 놓습니다. 사용자, 그룹, 역할, 앱의 신원, 자격 증명 점검, 기본 보호 설정이 두 서비스에서 어떻게 다르게 보였는지 정리하고, 직접 보지 못한 대응은 확인하지 않았다고 표시합니다.

- 주소: https://copyandrun.com/blog/aws-iam-vs-entra-id-identity-compare/
- 분야: 클라우드
- 발행일: 2026-10-19
- 태그: AWS, IAM, Microsoft Entra ID, 비교, ID 관리

AWS와 Azure를 함께 쓰는 조직에서는 "이 사람이 무엇을 할 수 있는가"라는 질문을 두 곳에서 따로 확인해야 합니다. 이 글은 새로 화면을 연 것이 아니라, 이미 올린 실습 글에서 직접 읽은 화면만 모아 같은 질문으로 나란히 놓은 비교입니다. 직접 보지 못한 항목은 `확인하지 않은 대응` 표에 따로 모았고, 문서에 근거한 설명은 그렇다고 적었습니다.

근거가 된 글은 다음과 같습니다.

- AWS: [IAM 정책 시뮬레이터 읽기](/blog/aws-iam-policy-simulator-read/), [EC2에 IAM 역할 연결](/blog/aws-iam-role-for-ec2-console/), [IAM 정책 JSON과 시뮬레이터](/blog/aws-iam-user-least-privilege-policy/), [IAM 비밀번호 정책과 보안 상태 읽기](/blog/aws-iam-password-policy-security-status-read/)
- Entra ID: [사용자와 그룹 읽기](/blog/entra-id-users-groups-structure/), [관리자 역할 읽기](/blog/entra-id-admin-roles-review/), [보안 기본값 읽기](/blog/entra-id-security-defaults-read/), [앱 등록과 자격 증명 만료 읽기](/blog/entra-id-app-registrations-secret-expiry-read/)

먼저 이름 문제가 있습니다. 같은 `역할`이라는 말이 AWS에서는 사람이나 서비스가 맡아 쓰는 신원(IAM 역할)이고, Entra ID에서는 관리 권한을 묶어 둔 목록(관리자 역할)이라 뜻이 다릅니다. 두 서비스는 제품 구조가 달라서 화면이 일대일로 대응하지 않습니다. 아래 표는 같은 질문에 답하는 화면을 짝지은 것이며, 기능이 똑같다는 뜻은 아닙니다.

## 1. 한눈에 보는 대응표

| 질문 | AWS IAM에서 본 것 | Entra ID에서 본 것 |
| --- | --- | --- |
| 사람 계정은 어디서 보는가 | `IAM 사용자` 목록. 마지막 활동, MFA, 암호 수명 열이 점검 단서였습니다 | `사용자` 목록. 사용자 계정 이름, 사용자 유형(구성원, 게스트), 온-프레미스 동기화 열이 있었습니다 |
| 계정 수 현황 | IAM 대시보드의 리소스 칸에 사용자 17, 역할 40, 사용자 그룹 0, 정책 1이 표시되었습니다 | 사용자 목록에 14행이 보였고 그룹은 26개로 표시되었습니다(서로 다른 환경의 값) |
| 권한을 묶는 단위 | 이 AWS 계정에는 사용자 그룹이 0개였습니다. 권한은 정책을 사용자나 역할에 붙이는 방식으로 보였습니다 | 그룹이 26개였고, 화면에 보인 12행은 유형이 `Microsoft 365`와 `보안`, 멤버십 유형이 `할당됨`이었습니다 |
| 권한을 부여하는 단위(층위가 다름) | 정책 JSON의 `Effect`, `Action`, `Resource`. 허용 문이 없으면 시뮬레이터에서 암묵적 거부로 표시되었습니다 | 관리자 역할 목록. 역할마다 이름, 설명, `권한 있음` 배지, 할당 수(과제)가 있었습니다. 권한을 적는 방식은 이 목록에서 보지 못했습니다 |
| 기계가 쓰는 신원(같은 종류가 아님) | IAM 역할. EC2에 역할을 붙이고 신뢰 정책과 권한 정책을 나눠 읽었습니다. 장기 액세스 키를 쓰는 IAM 사용자는 이 실습에서 열지 않았습니다 | 앱 등록. 인증서 및 암호 열에 `만료됨`, `-` 같은 표시가 있었습니다. 키 없이 쓰는 관리 ID는 이 실습에서 보지 않았습니다 |
| 자격 증명 점검 | 보안 인증 보고서 화면(보고서는 내려받지 않았습니다)과 IAM 대시보드의 보안 권장 사항 칸 | 앱 등록 목록의 인증서 및 암호 열, 사용자 상세의 인증 방법 메뉴(메뉴 이름만 확인) |
| 계정 전체 기본 보호(성격이 다름) | 계정 설정의 암호 정책. 기본 정책은 최소 8자, 만료 없음이었습니다 | 속성의 보안 기본값. 이 테넌트에서는 꺼져 있다는 경고가 있었습니다. Entra ID의 암호 정책 화면은 이 실습에서 보지 않았습니다 |

## 2. 사용자와 그룹

두 서비스 모두 사람 계정을 목록으로 보여 주고, 점검할 때 먼저 볼 열이 있습니다. AWS 쪽은 마지막 활동과 MFA, 암호 수명처럼 쓰임을 보여 주는 열이 중심이었고, Entra ID 쪽은 사용자 유형이 중심이었습니다. 사용자 유형은 조직 안의 계정인 `구성원`과 외부에서 초대한 `게스트`를 나눕니다. AWS IAM 사용자 목록에서 외부 사용자를 나누는 같은 열은 이 실습에서 보지 못했습니다. 반대로 Entra ID에서는 마지막 활동이나 MFA 열을 사용자 목록에서 읽지 못했고(인증 방법과 로그인 로그 메뉴는 이름만 확인했습니다), 두 서비스의 점검 열이 같지 않습니다.

그룹은 차이가 컸습니다. 이 실습의 AWS 계정은 사용자 그룹이 0개였고, 읽은 Entra ID 테넌트는 그룹이 26개였습니다. 두 환경은 규모와 구성이 서로 달라서 이 차이를 서비스 설계의 차이로 읽으면 안 됩니다. 확실히 말할 수 있는 것은 두 서비스 모두 그룹이라는 단위를 가지고 있고, 권한을 그룹에 붙이는 편이 사람이 팀을 옮길 때 관리하기 쉽다는 설명이 Entra ID 글(Microsoft 문서 기준)에 있다는 점까지입니다. AWS에서 정책을 그룹에 붙였을 때의 화면은 이 실습에서 확인하지 않았습니다.

## 3. 권한을 적는 방식

AWS에서는 정책 JSON이 권한의 본체입니다. 한 문장이 `Effect`(허용 또는 거부), `Action`, `Resource`로 이루어지고, 시뮬레이터에서 작업과 리소스를 넣어 보면 허용인지 암묵적 거부인지 계산해 줍니다. 허용 문이 없으면 거부된다는 기본 규칙을 화면으로 확인했습니다.

Entra ID에서 읽은 것은 관리자 역할이었습니다. 역할은 미리 정의된 `기본 제공` 역할이 목록으로 나오고, `권한 있음` 배지가 권한 상승으로 이어질 수 있는 역할을 표시했습니다. 사용자별 할당 화면에서 `적격 할당`과 `활성 할당` 탭 이름을 확인했고 활성 할당 탭은 비어 있었습니다(적격 할당은 PIM이 있어야 쓴다는 설명은 문서 기준이고 적격 할당 탭은 열지 않았습니다).

두 방식은 용도가 다릅니다. AWS 정책은 서비스와 리소스 단위로 허용 범위를 직접 쓰는 방식이고, 이 글에서 읽은 Entra ID 역할은 Entra ID와 Microsoft 365 일부 서비스의 관리 작업을 묶어 둔 목록입니다(문서 기준, 목록의 `가상 방문 관리자`는 Microsoft 365 쪽 역할로 보입니다). Azure 리소스(VM, 스토리지 등)에 대한 권한은 Azure의 역할 기반 접근 제어(RBAC)에서 따로 다루며, 이 실습에서는 그 화면을 열지 않았습니다. 따라서 "AWS 정책 대 Entra ID 역할"을 같은 층위로 비교하면 안 됩니다. 가장 가까운 대응은 AWS 정책과 Azure RBAC이지만, 이 글에서는 Azure 쪽을 직접 보지 못했습니다.

## 4. 기계가 쓰는 신원

AWS에서는 EC2 같은 서비스가 쓰는 신원을 IAM 역할로 만들고, 역할에 두 가지를 둡니다. 누가 이 역할을 맡을 수 있는지 정하는 신뢰 정책과, 맡은 뒤 무엇을 할 수 있는지 정하는 권한 정책입니다. 이 글들에서는 역할을 인스턴스에 연결해 액세스 키 없이 쓰도록 구성하는 과정을 읽었습니다. 인스턴스에서 실제로 S3를 읽는 것까지는 시험하지 않았습니다.

Entra ID에서는 앱 등록이 코드와 자동화의 신원입니다. 목록에서 읽을 수 있었던 핵심은 `인증서 및 암호` 열의 만료 상태였습니다. 28개 앱 중 일부에 `만료됨`이 붙어 있었습니다. 다만 이 둘은 같은 종류의 신원이 아닙니다. 키 없이 인스턴스가 맡아 쓰는 EC2 IAM 역할과 더 가까운 Entra ID 쪽 대응은 관리 ID(문서 기준)이고, 클라이언트 암호를 쓰는 앱 등록과 더 가까운 AWS 쪽은 장기 액세스 키를 가진 IAM 사용자로 알려져 있습니다. AWS에도 액세스 키의 교체 점검이 필요하며 보안 인증 보고서에 그 항목이 있다고 앞선 글에 적었습니다. 관리 ID 화면과 IAM 사용자의 액세스 키 화면은 이 실습에서 열지 않았으니 이 부분은 짝을 맞춘 비교가 아닙니다.

## 5. 기본 보호 설정

AWS 계정 설정의 암호 정책은 기본값이 최소 8자, 대문자와 소문자, 숫자, 영숫자 외 문자 중 3종류 이상, 만료 없음이었습니다. 사용자 지정으로 바꾸면 최소 길이와 문자 종류, 만료, 재사용 제한 같은 항목을 고를 수 있었습니다.

Entra ID의 보안 기본값은 테넌트 전체에 Microsoft 권장 보호를 한꺼번에 켜는 스위치로 보였습니다. 이 테넌트에서는 꺼져 있었고 패널의 선택지는 `사용(권장)`과 `비활성화(권장하지 않음)` 두 가지였습니다. 두 화면은 성격이 다릅니다. AWS 암호 정책은 비밀번호 규칙을 세부 항목으로 정하고, Entra ID 보안 기본값은 묶음 단위로 켜고 끕니다. Entra ID에도 비밀번호 관련 정책이 있는 것으로 알려져 있으나 이 실습에서 그 화면은 보지 않았으므로, 위 설명은 두 화면의 성격 차이만 말한 것입니다. AWS에서 MFA를 계정 전체에 강제하는 같은 스위치가 있는지는 이 실습에서 확인하지 않았습니다. 또 Entra ID 보안 기본값이 구체적으로 무엇을 요구하는지는 문서에서 확인해야 하며 이 글에서 시험하지 않았습니다.

## 6. 두 곳을 함께 점검할 때의 순서

직접 읽은 화면을 바탕으로 정리한 점검 순서입니다.

1. **계정 수와 구조**: AWS는 IAM 대시보드의 리소스 칸, Entra ID는 사용자와 그룹 목록에서 현황을 봅니다.
2. **사람 계정의 상태**: AWS는 마지막 활동과 MFA 열을 읽었습니다. Entra ID는 이 실습에서 같은 점검을 하지 못했고 사용자 유형과 동기화 열만 읽었습니다.
3. **관리자 권한**: AWS는 사용자에게 붙은 정책을 권한 탭에서 읽고 시뮬레이터로 평가하며, Entra ID는 관리자 역할 목록의 `권한 있음` 배지와 할당 수를 봅니다.
4. **기계가 쓰는 신원**: AWS는 역할의 신뢰 정책과 권한 정책, Entra ID는 앱 등록의 인증서 및 암호 열을 봅니다.
5. **전체 기본 보호**: AWS는 계정 설정의 암호 정책, Entra ID는 보안 기본값 상태를 봅니다.

## 확인하지 않은 대응

아래 항목은 직접 화면을 열지 못했거나 서로 대응하는 화면을 보지 못했습니다.

| 항목 | 이유 |
| --- | --- |
| Azure 리소스에 대한 RBAC 역할 할당 | 이 실습에서는 화면을 열지 않았습니다 |
| Entra ID 관리 ID와 AWS IAM 사용자의 액세스 키 | 두 화면 모두 이 실습에서 열지 않았습니다 |
| Entra ID 조건부 액세스와 AWS의 조건 키 | 조건부 액세스 화면은 접근 권한 오류로 열리지 않았습니다 |
| 로그인과 감사 기록의 대응 | Entra ID 로그인 로그와 감사 로그 메뉴는 메뉴 이름만 확인했고 내용 화면은 열지 않았습니다. AWS는 [CloudTrail 이벤트 기록 읽기](/blog/aws-cloudtrail-event-history-read/)에서 읽었습니다 |
| 외부 ID 연동(AWS IAM Identity Center와 Entra ID) | 이 실습에서 다루지 않았습니다 |
| 라이선스 등급에 따른 기능 차이 | Entra ID 라이선스는 정확한 값을 확인하지 않았습니다. 사용자 지정 역할이 P1 이상을 요구한다는 안내는 화면에서 읽었고, 그룹에 역할을 할당하는 기능의 요건은 문서에서 읽었습니다 |

## 읽을 때 주의할 점

- 이 비교는 서로 규모와 구성이 다른 실습 환경 두 곳에서 읽은 값을 놓은 것입니다. 숫자(사용자 수, 그룹 수 등)를 두 서비스의 우열로 읽으면 안 됩니다.
- 표의 `본 것`은 해당 글의 화면에서 직접 읽은 내용으로 한정했고, 문서 기준인 부분은 괄호로 표시했습니다. 화면 문구는 각 글의 실습 시점의 한국어 콘솔 기준입니다.
- 문서에 근거한 설명(적격 할당의 PIM 요건, 사용자 지정 역할의 라이선스 요건, 관리 ID 같은 대안)은 이 실습에서 직접 시험하지 않았습니다.

## 이어서 해 볼 것

- 두 서비스 모두에서 관리자 권한을 가진 계정이 MFA를 쓰는지 확인하는 점검표를 만들어 봅니다
- Azure RBAC 역할 할당 화면을 열 수 있으면 이 글의 `확인하지 않은 대응` 첫 줄을 채워 봅니다
- 같은 방식으로 네트워크 계층(보안 그룹과 네트워크 보안 그룹)과 로그 계층의 대응표도 만들어 봅니다