EC2 인스턴스 목록은 잘 보이는데 '인스턴스 시작'을 누르자 권한이 없다고 한다. 같은 콘솔에서 버튼까지 보이니 더 헷갈린다. 하지만 IAM은 화면에 들어갈 권한과 리소스를 만들 권한을 따로 판단한다. 이번에는 사용자에게 읽기 전용 정책이 있고, 나중에 그룹 정책이 추가되는 한 가지 사례로 그 차이를 보자.
EC2 목록은 보이는데 인스턴스 생성은 왜 거부될까?
예시의 IAM 사용자 reader에게는 AmazonEC2ReadOnlyAccess만 연결돼 있다. 현재 이 관리형 정책은 EC2의 Describe 계열 조회 작업 등을 허용하지만, 인스턴스 생성에 쓰는 ec2:RunInstances를 허용하지 않는다. AWS가 공개한 정책 문서에서 기본 버전의 작업 목록을 확인할 수 있다.
reader에게 적용되는 정책 | ec2:DescribeInstances | ec2:RunInstances |
|---|---|---|
사용자에게 AmazonEC2ReadOnlyAccess만 연결 | 허용 | 허용 규칙이 없어 암묵적으로 거부 |
위 정책 + 소속 그룹에 AmazonEC2FullAccess 연결 | 허용 | 그룹 정책의 허용 규칙과 일치 |
첫 줄의 거부는 Deny 문장이 꼭 있어서가 아니다. 요청을 허용하는 규칙이 없으면 기본적으로 거부된다. '읽기 전용'이라는 이름을 보고 모든 EC2 화면의 버튼까지 실행될 것이라 생각하기 쉽지만, IAM이 보는 것은 버튼이 아니라 요청한 작업이다.
IAM 그룹에 정책을 연결하면 사용자 권한은 어떻게 달라질까?
같은 reader를 ec2-operators 그룹에 넣고, 그 그룹에 AmazonEC2FullAccess가 연결됐다고 가정하자. 이 정책의 ec2:* 허용 규칙은 ec2:RunInstances에도 해당한다. 사용자의 읽기 전용 정책을 지우거나 바꾸지 않아도 사용자 정책과 소속 그룹 정책을 함께 평가하므로, 이제 생성 작업을 허용하는 규칙이 생긴다.
요청 한 건을 따라가면 다음과 같다. 여기의 결과는 공개된 정책 정의를 바탕으로 한 설명용 판정이며 실제 AWS 계정에서 인스턴스를 생성한 기록은 아니다.
요청: reader → ec2:RunInstances
그룹 가입 전 사용자 ReadOnly: 해당 Allow 없음 → 기본 거부
그룹 가입 후 사용자 ReadOnly: 해당 Allow 없음
그룹 EC2 Full: ec2:* Allow 있음 → 이 작업의 허용 조건 충족이 차이는 EC2 콘솔을 새로고침해서 생긴 '운 좋은 성공'이 아니다. 요청에 적용되는 정책 집합이 달라진 것이다. 다만 그룹에 정책이 붙었다는 사실만으로 모든 인스턴스 생성이 반드시 성공한다고 단정하면 안 된다. 리소스·조건, 권한 경계, 조직 정책, 역할 전달에 필요한 추가 권한 같은 다른 제한이 요청을 막을 수 있다.
그룹에서 허용했는데도 AccessDenied라면 무엇을 볼까?
먼저 오류의 작업 이름을 본다. ec2:RunInstances가 거부됐는지, 시작 과정의 다른 작업이 거부됐는지를 구분해야 한다. 다음으로 로그인한 주체가 예상한 reader인지, 그 사용자가 실제로 해당 그룹에 속했는지, 그룹에 연결된 정책의 기본 버전이 무엇인지 확인한다. 비슷한 이름의 사용자나 그룹을 보고 있으면 정책 JSON을 오래 읽어도 답이 안 나온다.
RunInstances에 허용이 있어도 다른 곳의 명시적 거부는 그 허용보다 우선한다. 권한 경계나 조직의 서비스 제어 정책이 허용 범위를 좁힐 수도 있다. AWS의 IAM 정책 평가 순서는 사용자·그룹 정책의 허용, 기본 거부, 명시적 거부를 구분해 설명한다. 오류가 계속된다면 '그룹 정책을 더 크게 주기'보다 어떤 작업이 어느 경계에서 막혔는지 좁히는 편이 빠르다.
학습용 비교에서는 AmazonEC2FullAccess가 권한 변화의 모습을 선명하게 보여 준다. 실제 운영 권한으로는 범위가 넓다. 필요한 작업·리소스·조건만 허용하는 최소 권한 정책을 설계하고, 사람의 상시 작업에는 가능하면 장기 IAM 사용자 키보다 임시 자격 증명과 역할을 사용한다.
핵심 요약
EC2 조회가 된다는 사실은 생성 권한의 증거가 아니다. 거부된 작업 이름 → 사용자 정책의 허용 여부 → 그룹을 통해 추가된 허용 → 명시적 거부와 권한 경계 순서로 보면 된다. 그룹의 허용이 추가되면 판정이 바뀔 수 있지만, 그 결과를 '계정의 모든 EC2 작업이 무조건 성공한다'로 확대하지 않는 것이 핵심이다.
작성자
기초 개념을 구현과 검증, 실제 운영 판단까지 연결해 기록합니다.

