[AWS] 클라우드와 AWS 기본 개념 이해하기
AWS를 공부하기 시작하면 가장 먼저 마주치는 문제가 있다. 서비스가 너무 많다는 것이다. EC2, S3, RDS, IAM, VPC, Lambda 등 처음 보는 이름이 계속 등장한다. 각각의 정의부터 외우기 시작하면 금방 복
daniellee09.tistory.com
지난 글에서는 클라우드와 AWS의 기본 구조, Region과 Availability Zone, AWS Resource에 대해 살펴봤다.
이제 실제 AWS 서비스를 하나씩 살펴보자.
가장 먼저 볼 서비스는 IAM(Identity and Access Management)이다.
AWS를 사용하다 보면 여러 사람이 하나의 AWS 환경을 사용하기도 하고
EC2 같은 AWS 서비스가 다른 서비스에 접근해야 하는 경우도 생긴다.
이때 반드시 필요한 것이 인증과 권한 관리다.
IAM을 짧게 정리하면 다음과 같다.
IAM은 누가 AWS에 접근할 수 있고, 어떤 AWS Resource에 어떤 작업을 할 수 있는지를 관리하는 서비스다.
IAM은 왜 필요한가
AWS 계정을 하나 만들었다고 해보자.
이 AWS 계정을 회사에서 여러 사람이 함께 사용한다면 다음과 같은 상황이 생길 수 있다.
AWS Account
│
├─ 개발자 A
├─ 개발자 B
├─ DB 관리자
└─ 인턴
이 사람들에게 모두 동일한 권한을 줄 필요는 없다.
예를 들어 개발자는 EC2를 사용할 수 있지만 RDS를 삭제하지 못하게 하고, DB 관리자는 RDS를 관리할 수 있지만 IAM 설정은 변경하지 못하게 할 수 있다.
개발자 A
→ EC2 사용 가능
→ S3 사용 가능
DB 관리자
→ RDS 관리 가능
인턴
→ Resource 조회만 가능
이처럼 사용자의 역할에 따라 접근 가능한 AWS Resource와 작업 범위를 다르게 설정하는 것이 IAM의 역할이다.
핵심은 다음 세 가지 질문이다.
누가?
어떤 Resource에?
무엇을 할 수 있는가?
예를 들어 다음과 같은 규칙을 만들 수 있다.
개발자 A가
↓
my-service-images라는 S3 Bucket에
↓
파일을 업로드할 수 있다.
IAM은 이러한 규칙을 관리한다.
Root User와 IAM
AWS 계정을 처음 생성하면 Root User가 생성된다.
Root User는 해당 AWS Account에 대한 가장 강력한 권한을 가진 사용자다.
AWS Account
│
↓
Root User
Root User는 AWS 계정 설정부터 결제 정보, IAM, EC2, S3, RDS 등 거의 모든 Resource를 관리할 수 있다.
예를 들어 다음과 같은 작업이 가능하다.
AWS Account 설정 변경
IAM 설정
EC2 생성 / 삭제
RDS 생성 / 삭제
S3 Bucket 삭제
결제 정보 관리
권한이 매우 강력하기 때문에 일반적인 개발 작업에 Root User를 계속 사용하는 것은 좋지 않다.
실제 환경에서는 Root User는 중요한 계정 관리 작업에만 사용하고, 일상적인 AWS 작업은 IAM을 통해 관리하는 것이 좋다.
Root User
│
│ 최초 설정
↓
IAM
│
├─ 개발자
├─ 관리자
└─ AWS 서비스
또한 Root User에는 MFA를 적용하는 것이 중요하다.
IAM을 구성하는 핵심 요소
IAM에서 가장 많이 등장하는 개념은 다음과 같다.
IAM
│
├─ User
├─ Group
├─ Role
└─ Policy
각각의 역할을 먼저 간단하게 정리해보자.
| 개념 | 역할 |
| IAM User | AWS를 사용하는 개별 사용자 |
| IAM Group | 여러 User를 묶어서 관리 |
| IAM Role | 특정 사용자나 서비스가 맡아 사용하는 권한 |
| IAM Policy | 어떤 작업을 허용하거나 거부할지 정의 |
이 중에서도 User, Role, Policy 세 가지가 가장 중요하다.
IAM User
IAM User는 AWS를 사용하는 개별 사용자를 의미한다.
예를 들어 회사에 개발자가 세 명 있다면 다음과 같이 IAM User를 만들 수 있다.
AWS Account
│
├─ IAM User: developer-a
├─ IAM User: developer-b
└─ IAM User: admin
각 사용자에게 서로 다른 권한을 부여할 수도 있다.
developer-a
→ EC2 사용
developer-b
→ S3 사용
admin
→ 대부분의 Resource 관리
즉 IAM User를 간단하게 표현하면 다음과 같다.
AWS를 사용하는 개별 사용자
IAM Group
사용자가 많아지면 각각의 User에 권한을 하나씩 부여하는 것이 불편해진다.
예를 들어 개발자가 20명 있다고 생각해보자.
developer1
developer2
developer3
...
developer20
모든 개발자에게 동일하게 EC2와 S3 권한을 부여해야 한다면 각 User마다 Policy를 설정하는 것은 비효율적이다.
이때 IAM Group을 사용한다.
Developers Group
│
├─ developer1
├─ developer2
├─ developer3
└─ developer4
그리고 Group에 권한을 부여한다.
Developers Group
│
├─ EC2 사용 권한
└─ S3 사용 권한
그러면 해당 Group에 속한 User들은 Group에 부여된 권한을 사용할 수 있다.
즉,
IAM Group은 여러 User에게 동일한 권한을 효율적으로 적용하기 위한 그룹이다.
IAM Policy
IAM에서 가장 중요한 개념 중 하나가 Policy다.
Policy는 간단히 말하면 다음과 같다.
AWS Resource에 어떤 작업을 허용하거나 거부할지를 정의한 규칙
예를 들어 어떤 개발자에게 S3 파일 조회 권한만 부여하고 싶다고 해보자.
IAM User
│
↓
Policy
│
↓
S3 파일 조회 가능
Policy에는 이러한 권한 규칙이 정의되어 있다.
IAM Policy는 JSON 형태로 작성된다.
예를 들어 다음과 같은 Policy가 있다고 해보자.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
처음 보면 복잡해 보이지만 핵심은 세 가지다.
Effect
Action
Resource
Effect
Effect는 해당 작업을 허용할지 거부할지를 결정한다.
두 가지 값이 있다.
Allow
→ 허용
Deny
→ 거부
예를 들어 다음과 같다.
"Effect": "Allow"
이는 해당 작업을 허용한다는 의미다.
Action
Action은 어떤 작업을 할 수 있는지를 나타낸다.
예를 들어 다음과 같다.
s3:GetObject
→ S3 Object 조회
s3:PutObject
→ S3 Object 업로드
s3:DeleteObject
→ S3 Object 삭제
ec2:StartInstances
→ EC2 Instance 시작
ec2:StopInstances
→ EC2 Instance 중지
Action은 일반적으로 다음과 같은 형태다.
서비스 : 작업
예를 들어:
s3:GetObject
는 S3 서비스에서 Object를 조회하는 작업을 의미한다.
Resource
Resource는 해당 권한을 어느 AWS Resource에 적용할 것인지 지정한다.
예를 들어 다음과 같은 S3 Bucket이 있다고 해보자.
my-service-images
다음과 같이 지정하면 해당 Bucket 내부의 Object에만 권한을 적용할 수 있다.
"Resource": "arn:aws:s3:::my-service-images/*"
즉 Policy는 자연어로 읽으면 다음과 같다.
Allow
→ 허용한다.
s3:GetObject
→ S3 Object를 조회하는 것을
my-service-images/*
→ 이 Bucket 안에서만
따라서 전체 의미는 다음과 같다.
my-service-images Bucket 안에 있는 Object를 조회하는 것을 허용한다.
IAM Policy를 볼 때는 항상 Effect → Action → Resource 순서로 읽으면 이해하기 쉽다.
ARN이란
Resource를 지정할 때 자주 등장하는 것이 ARN(Amazon Resource Name)이다.
ARN은 AWS Resource를 고유하게 식별하기 위한 이름이다.
예를 들어 S3 Bucket은 다음과 같은 형태를 가진다.
arn:aws:s3:::my-service-images
EC2 Instance의 경우 다음과 비슷한 형태가 된다.
arn:aws:ec2:ap-northeast-2:123456789012:instance/i-xxxxxxxx
쉽게 말하면 ARN은 AWS 안에서 Resource를 정확하게 가리키기 위한 Resource 주소라고 생각하면 된다.
IAM Role
IAM에서 가장 헷갈리기 쉬운 개념이 Role이다.
IAM Role도 권한을 가진다는 점에서는 IAM User와 비슷하다.
하지만 특정 사용자에게 영구적으로 속하는 계정은 아니다.
Role은 사용자나 AWS 서비스가 필요한 순간에 맡아서 사용하는 권한의 집합이다.
예를 들어 EC2에서 실행되는 Spring Boot가 S3에 이미지를 업로드해야 한다고 생각해보자.
EC2
│
↓
S3
EC2가 아무 권한 없이 S3를 사용할 수 있는 것은 아니다.
S3 Object를 업로드하려면 다음 권한이 필요하다.
s3:PutObject
이때 EC2에 IAM Role을 연결할 수 있다.
EC2
│
↓
IAM Role
│
↓
S3 접근 Policy
│
↓
S3
예를 들어 다음과 같은 Role을 만들 수 있다.
WebServerRole
│
└─ s3:PutObject
그리고 해당 Role을 EC2에 연결한다.
EC2 Instance
│
↓
WebServerRole
│
↓
S3 Bucket
그러면 EC2에서 실행되는 애플리케이션이 Role의 권한을 이용해 S3에 접근할 수 있다.
IAM User와 Role의 차이
User와 Role은 둘 다 권한과 관련되어 있기 때문에 헷갈릴 수 있다.
차이를 간단하게 정리하면 다음과 같다.
| IAM User | IAM Role |
| 특정 사용자를 나타냄 | 필요한 순간 맡는 역할 |
| 사람에게 많이 사용 | AWS 서비스에도 많이 사용 |
| 장기 자격 증명 사용 가능 | 임시 자격 증명 사용 |
| 개발자 계정 등 | EC2 → S3 접근 등 |
쉽게 기억하면 다음과 같다.
IAM User
→ 나는 누구인가?
IAM Role
→ 지금 어떤 역할을 수행하고 있는가?
Access Key
AWS CLI나 SDK를 사용하다 보면 Access Key라는 것이 등장한다.
일반적으로 다음 두 값으로 구성된다.
Access Key ID
Secret Access Key
이 자격 증명을 사용하면 프로그램이나 AWS CLI에서 AWS API를 호출할 수 있다.
다만 Secret Access Key는 매우 중요한 인증 정보다.
따라서 다음과 같은 곳에 직접 넣는 것은 피해야 한다.
GitHub
소스 코드
공개 문서
공개 저장소
예를 들어 다음처럼 애플리케이션 코드에 직접 넣는 것은 좋지 않다.
accessKey = "..."
secretKey = "..."
특히 EC2에서 다른 AWS 서비스를 사용해야 하는 상황이라면 Access Key를 직접 코드에 넣기보다는 IAM Role을 사용하는 것이 일반적이다.
Spring Boot
│
↓
EC2
│
↓
IAM Role
│
↓
S3
이 방식이라면 애플리케이션 코드에 장기 자격 증명을 직접 저장할 필요가 없다.
최소 권한 원칙
IAM을 사용할 때 매우 중요한 원칙이 있다.
Principle of Least Privilege, 즉 최소 권한 원칙이다.
의미는 간단하다.
사용자나 서비스에게 필요한 권한만 부여한다.
예를 들어 Spring Boot 서버가 특정 S3 Bucket에 이미지를 업로드하기만 하면 된다고 해보자.
필요한 권한은 다음과 같은 수준일 수 있다.
s3:GetObject
s3:PutObject
그런데 편하다는 이유로 다음과 같은 권한을 부여하면 문제가 생긴다.
AdministratorAccess
이렇게 하면 해당 서버가 필요하지 않은 다른 AWS Resource까지 변경할 수 있는 권한을 갖게 된다.
좋지 않은 구조
Spring Boot
│
↓
AWS 전체 관리자 권한
대신 필요한 작업만 허용하는 것이 좋다.
Spring Boot
│
↓
S3 읽기 / 업로드 권한만
AWS 환경에서 권한을 설계할 때는 항상 다음 질문을 하는 것이 좋다.
이 사용자 또는 서비스가 정말 이 권한까지 필요한가?
IAM의 기본 권한 판단 방식
IAM에서는 기본적으로 권한이 없으면 요청을 허용하지 않는다.
개념적으로 다음과 같다.
기본 상태
→ Deny
명시적으로 허용된 작업만 수행할 수 있다.
Policy
Effect: Allow
Action: s3:GetObject
이런 Policy가 있어야 해당 작업을 수행할 수 있다.
또한 명시적인 Deny가 존재하면 해당 작업은 거부된다.
개념적으로 정리하면 다음과 같다.
기본
→ Deny
명시적 Allow
→ 허용 가능
명시적 Deny
→ 거부
따라서 IAM은 기본적으로 필요한 권한을 하나씩 열어주는 방식이라고 이해하면 좋다.
실제 웹 서비스에서 IAM은 어떻게 사용될까
Spring Boot 서버를 EC2에서 운영하면서 사용자가 업로드한 이미지를 S3에 저장한다고 해보자.
전체 구조는 다음과 같다.
사용자
│
↓
Spring Boot
│
↓
EC2 Instance
│
↓
IAM Role
│
↓
S3 Bucket
IAM Role에는 다음 정도의 권한을 줄 수 있다.
s3:GetObject
s3:PutObject
그러면 EC2에서 실행되는 Spring Boot는 다음 작업을 수행할 수 있다.
이미지 조회
→ 가능
이미지 업로드
→ 가능
이미지 삭제
→ 불가능
Bucket 삭제
→ 불가능
RDS 삭제
→ 불가능
이렇게 필요한 작업만 허용하는 것이 최소 권한 원칙이다.
IAM의 전체 구조
지금까지 살펴본 내용을 하나의 구조로 정리하면 다음과 같다.
AWS Account
│
┌───────────────┴───────────────┐
│ │
사람 AWS 서비스
│ │
↓ ↓
IAM User IAM Role
│ │
└──────────────┬────────────────┘
│
↓
IAM Policy
│
┌──────────────┼──────────────┐
│ │ │
Effect Action Resource
│ │ │
Allow s3:GetObject S3 Bucket
│
↓
AWS Resource
결국 IAM이 해결하려는 문제는 하나다.
누가 어떤 AWS Resource에서 어떤 행동을 할 수 있는가?
정리
IAM의 핵심 개념을 다시 정리하면 다음과 같다.
IAM
→ AWS의 인증 및 권한 관리 서비스
IAM User
→ AWS를 사용하는 개별 사용자
IAM Group
→ 여러 User를 묶어서 권한 관리
IAM Policy
→ 허용하거나 거부할 작업을 정의
IAM Role
→ 사용자나 AWS 서비스가 맡아 사용하는 권한
ARN
→ AWS Resource를 식별하는 이름
Access Key
→ 프로그램이나 CLI에서 사용하는 인증 정보
MFA
→ 추가 인증 수단
Least Privilege
→ 필요한 최소한의 권한만 부여
특히 IAM Policy는 다음 세 가지를 기준으로 읽으면 된다.
Effect
→ 허용할 것인가?
Action
→ 무엇을 할 수 있는가?
Resource
→ 어디에서 할 수 있는가?
예를 들어:
Allow
+
s3:PutObject
+
my-service-images Bucket
이라면 다음 문장으로 해석할 수 있다.
my-service-images Bucket에 Object를 업로드하는 것을 허용한다.
IAM까지 이해하면 이제 실제 AWS 서버를 만들어보자.
다음 글에서는 AWS에서 가장 많이 사용되는 서비스 중 하나인 EC2(Elastic Compute Cloud)를 살펴본다.
EC2가 무엇인지부터 시작해 AMI, Instance Type, EBS, Key Pair, SSH, Security Group이 각각 어떤 역할을 하는지 하나씩 정리해본다.
'개발 > AWS' 카테고리의 다른 글
| [AWS] 클라우드와 AWS 기본 개념 이해하기 (0) | 2026.08.23 |
|---|