AWS IAM 권한 설정 처음 할 때 제가 헷갈렸던 부분과 해결법

AWS IAM 권한 설정을 처음 하다 보니 막상 어디서부터 시작해야 할지, 무슨 권한을 줘야 할지 엄청 헷갈리더라고요. 특히 IAM 정책 문법도 낯설고, 잘못 설정했다가 서비스에 영향이 갈까 봐 부담도 컸어요. 저도 처음엔 여러 시행착오를 겪었는데, 이 글에 그 과정을 차근차근 정리해봤습니다.

처음 AWS 계정에 로그인해서 IAM 사용자 만들기부터, 그룹과 역할 설정, 권한 정책 붙이는 단계까지 제가 했던 절차별로 구체적인 화면 흐름과 CLI 명령어도 포함해서 설명할게요. 저처럼 이제 막 시작하는 분들이라면 차례대로 따라 하면서 헷갈렸던 포인트도 명확해질 거예요.

AWS IAM 기본 환경과 버전

제가 사용한 환경은 AWS 관리 콘솔 2024년 5월 기준 버전과 AWS CLI v2.14.0 버전이었어요. 콘솔 UI는 종종 업데이트 되니 실제 화면과 약간 다를 수 있지만 개념은 동일합니다.

AWS IAM 권한 설정 처음 할 때 헷갈렸던 부분 관련 정보

1. IAM 사용자 만들기부터 시작했습니다

사실 이 부분이 가장 기본인데 저도 처음에 "루트 계정으로 계속 작업해도 되나?" 하다가 보안상 문제라는 걸 알고 바로 IAM 사용자부터 만들었거든요. 콘솔 상단 검색창에 'IAM'을 입력해서 IAM 대시보드로 들어갔습니다.

IAM 사이드바에서 '사용자' 메뉴 클릭 후 "사용자 추가" 버튼을 눌렀어요. 여기서 '프로그래밍 방식 액세스'와 'AWS 관리 콘솔 액세스' 둘 다 활성화해서 사용자 로그인과 CLI 사용이 가능하도록 했습니다.

가장 헷갈렸던 게 권한 부여 단계였는데요, 일단 저는 처음이라 '기존 정책 직접 연결'에서 AdministratorAccess를 붙였어요. 물론 실제 운영 환경에서는 권한 최소화 원칙을 지켜야 합니다.

# AWS CLI로 사용자 생성하는 명령어 예시
aws iam create-user --user-name myUser

# 액세스키 생성
aws iam create-access-key --user-name myUser

# 권한 연결
aws iam attach-user-policy --user-name myUser --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

이렇게 콘솔과 CLI 모두에서 손쉽게 사용자와 권한을 설정할 수 있다는 걸 확인했어요.

2. 그룹과 역할을 만들어서 권한 관리했습니다

그런데 사용자마다 직접 권한을 붙이면 관리가 어렵잖아요? 그래서 저는 '개발자' 그룹을 만들어서 공통 권한을 집중적으로 관리하기로 했어요. IAM 콘솔 → 그룹 → 그룹 생성 버튼을 누르고, 그룹 이름을 쓰고, 권한 정책을 붙였죠.

예를 들어 EC2만 조작 가능한 권한을 주고 싶을 땐 AmazonEC2FullAccess 정책을 선택하면 됩니다. 이렇게 그룹에 권한을 붙이고 나서 사용자를 그룹에 할당하니 관리가 훨씬 편했어요.

# 그룹 생성과 권한 연결 CLI 예시
aws iam create-group --group-name Developers
aws iam attach-group-policy --group-name Developers --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess

# 사용자 그룹에 추가
aws iam add-user-to-group --user-name myUser --group-name Developers

역할(Role)은 EC2 인스턴스가 권한을 갖고 AWS 서비스에 접근할 때 많이 썼는데요, 역할 생성할 때 신뢰 정책(Trust Policy)과 권한 정책(Policy)을 분리해서 설정하는 부분이 헷갈렸어요.

역할 만들 때 "AWS 서비스"가 이 역할을 사용할 수 있도록 신뢰 관계를 잘 설정해야 한다는 점 기억하세요. 예를 들어 EC2가 사용할 역할이라면 신뢰 정책에 EC2 서비스가 포함돼야 합니다.

AWS IAM 권한 설정 처음 할 때 헷갈렸던 부분 관련 정보

3. 정책 문법 직접 작성해보면서 헷갈렸던 점

정책을 직접 JSON으로 작성할 일이 있었는데, 여기서 진짜 많이 헤맸어요. AWS IAM 정책 문법이 조금 까다로운 게, Action, Resource, Effect, Condition 등 각각 위치와 값이 정확해야 하거든요.

특히 Condition 영역에서 문자열 비교 같은 걸 넣을 때 따옴표 위치나 대소문자 구분 실수로 정책이 적용 안 되는 걸 나중에 알았습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-example-bucket"
    },
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-example-bucket/*"
    }
  ]
}

이런 식으로 명확하게 리소스와 액션을 구분해서 써야 하고, 와일드카드(*)를 적절히 써야 원하는 권한만 딱 떨어지더라고요.

4. 실제 권한 문제 해결하며 배운 점

한 번은 EC2에서 S3 버킷에 접근하려고 하는데 계속 권한 부족 에러가 났어요. 콘솔에서 역할과 붙인 정책을 확인해보니, 리소스 ARN 경로를 정확히 지정 안 해서 생긴 문제였더라고요.

그래서 정책 내 리소스 경로에 와일드카드(*)를 적절히 넣어주고, S3 GetObject, PutObject 등 필요한 액션을 모두 포함해서 문제를 해결했습니다.

또, 테스트할 때는 권한을 넉넉히 줘서 체크하다가, 실제 서비스에 적용할 땐 꼭 필요 최소한으로 줄이는 게 보안상 중요하다는 것도 알게 됐어요.

AWS IAM 권한 설정 처음 할 때 헷갈렸던 부분 관련 정보

5. CLI로 권한 설정 빠르게 확인하는 팁

AWS CLI를 통해 사용자나 역할에 붙은 정책을 빠르게 조회할 수 있는데, 저는 이 명령어를 자주 썼어요.

# 사용자에 붙은 정책 확인
aws iam list-attached-user-policies --user-name myUser

# 역할에 붙은 정책 확인
aws iam list-attached-role-policies --role-name myRole

# 특정 정책 내용 보기
aws iam get-policy-version --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess --version-id v1

이렇게 하면 콘솔에 일일이 들어가지 않아도 CLI로 권한 상태를 빠르게 파악할 수 있어서 편리하더라고요.

6. 제가 겪었던 실수와 해결 과정

한 가지 웃긴 에피소드는, 사용자 생성 후 콘솔 로그인 URL을 잘못 썼던 적이에요. 기본 로그인 화면에서 루트 계정 이메일 입력 후 IAM 사용자 이름과 비밀번호를 따로 써야 하는데, 이걸 헷갈려서 로그인 자체가 안 됐거든요.

AWS 관리 콘솔 로그인 URL은 https://{계정ID}.signin.aws.amazon.com/console 형식이어야 하고, 여기서 생성한 IAM 사용자 이름과 비밀번호를 넣어야 했어요.

아울러, 정책 내에서 "Action"과 "Resource"를 제대로 매치하지 못한 것도 한동안 삽질을 했던 부분입니다.

7. 이렇게 하면 IAM 권한 설정 어렵지 않습니다

제가 추천하는 순서는 다음과 같아요.

• 먼저 루트 계정으로 로그인해서 IAM 사용자 생성
• ‘프로그래밍 방식 액세스’와 ‘콘솔 액세스’ 옵션 선택
• 권한은 처음엔 관리형 정책 AdministratorAccess 붙이고 테스트
• 그룹 생성 후 역할과 권한 관리 집중화
• 직접 정책 작성 시 JSON 문법과 ARN 이해하기
• CLI로 권한 상태 수시로 체크하기
• 문제 있을 땐 오류 메시지 읽고 권한 정책 수정

이렇게 천천히 따라 하다 보면 헷갈렸던 부분들이 자연스럽게 해결될 거예요. 저도 직접 해보면서 한 뼘씩 늘었거든요.

자주 물어보시는 것들

Q. 루트 계정과 IAM 계정의 차이는 뭔가요?

A. 루트 계정은 AWS 계정을 만들 때 등록한 이메일과 비밀번호로 접근하는 관리자 계정입니다. 모든 권한이 다 있으니 보안상 사용을 자제하고, IAM 사용자를 만들어 최소 권한으로 작업하는 게 안전해요.

Q. 정책 작성 시 와일드카드(*)를 어디까지 허용해도 괜찮나요?

A. 필요한 리소스에만 권한을 집중시키는 게 좋습니다. 와일드카드를 너무 남발하면 권한이 과도해질 수 있으므로, 리소스별 ARN을 정확히 지정하는 게 보안에 유리해요.

Q. 역할(Role)은 언제 쓰는 게 좋나요?

A. EC2 인스턴스, Lambda 함수 등 AWS 서비스가 다른 서비스에 접근할 때 역할을 사용합니다. 사용자 권한과 분리해 서비스별 권한 관리가 가능하죠.

IAM 권한 처음 설정할 때 절차 중심으로 꼼꼼히 따라 해보면 생각보다 어렵지 않으니 꼭 하나씩 손으로 직접 해보시길 추천합니다.

📌 함께 보면 좋은 글

• AWS SES로 이메일 발송할 때 제가 겪은 문제와 해결 방법들
• AWS RDS와 EC2 MySQL 직접 써보며 결정한 선택 기준과 세팅 절차