애플리케이션 계정의 ec2가 s3 버킷에 안전하게 접근하는 표준 패턴
1. 컴포넌트 하나씩 짚기
(1) OU – Workloads & Application account
- 상단의 OU – Workloads 는 AWS Organizations에서 “업무용 워크로드 계정들을 모아둔 조직 단위(OU)”라고 보면 됨.
- 그 안의 Application account 하나가 그려져 있고, 여기 안에 VPC, EC2, S3 버킷이 있는 구조.
(2) VPC, Private Subnet, EC2 instance
- 보라색 박스 = VPC
- 안쪽 파란 박스 = Private subnet
- 그 안의 주황색 칩 = EC2 인스턴스
포인트:
- Private subnet이라 인터넷 게이트웨이 없이 외부 인터넷으로 직접 나갈 수 없음.
- 애플리케이션 서버, 백엔드 서버 같은 “내부 전용” EC2를 여기에 둔다고 생각하면 됨.
(3) IAM (Roles / Permissions)
-
EC2 인스턴스에는 IAM Role이 붙어 있음 (Instance profile).
-
이 Role 안에는
- “어떤 S3 버킷에 어떤 작업을 할 수 있다” 는 권한(Policy) 가 써 있음.
-
사용자는 Access Key / Secret Key 를 코드에 넣지 않고,
- EC2가 자동으로 임시 자격증명을 받아서 S3에 접근.
(4) Amazon S3 endpoint + Amazon S3 data bucket
- Amazon S3 endpoint
= VPC 안에서 S3로 가는 VPC 엔드포인트 (Gateway/Interface)
→ 인터넷을 안 타고, 내부 네트워크 경로로 S3에 접근하는 관문. - Amazon S3 data bucket
= 실제 데이터를 저장하는 S3 버킷.
실무에서 자주 쓰는 버킷 예:
myapp-prod-user-data-bucketlog-archive-bucketml-training-dataset-bucket등등.
2. 번호 순서로 요청 흐름 이해하기
① EC2 → IAM : “나한테 쓸 수 있는 임시 열쇠 좀 줘”
EC2 인스턴스가 부팅될 때, 이미 EC2에 IAM Role이 붙어 있음.
애플리케이션(예: Python 코드, AWS SDK 사용)이 S3를 호출하려고 할 때 이런 일이 일어난다.
- EC2 안의 SDK(AWS CLI, boto3 등)가
인스턴스 메타데이터 서비스(IMDS) 를 통해
“내가 가진 role에 대한 credentials 알려줘” 라고 요청. - 이 요청은 내부적으로 IAM / STS 로 전달되어,
- 해당 Role에 대한 임시 보안 자격증명(AccessKey, SecretKey, SessionToken) 이 발급됨.
② IAM → EC2 : Temporary role credential 전달
-
IAM/STS가 생성한 임시 키:
- Access key ID
- Secret access key
- Session token
- 만료 시간(예: 1시간)
-
이 값들을 EC2 내부의 SDK가 자동으로 받아서 메모리에 들고 있음.
- 개발자가 코드에 키를 적을 필요 없음.
- 시간이 지나 만료되면 SDK가 다시 알아서 새로 발급.
③ EC2 → S3 endpoint → S3 data bucket
이제 EC2 앱이 S3에 파일 업로드/다운로드를 하려고 할 때:
-
애플리케이션이 S3 SDK를 호출
→ 요청 헤더에 아까 받은 임시 자격증명이 포함됨. -
트래픽은 VPC 안에서 S3 VPC Endpoint 로 향함.
→ 인터넷 게이트웨이나 NAT Gateway를 거치지 않음. -
S3는 그 임시 자격증명이
- 어떤 IAM Role에서 나온 것인지
- 그 Role Policy에 해당 버킷/객체에 대한 허용 권한이 있는지
- 버킷 정책에서 추가로 제한한 것 없는지
를 확인한 뒤,
-
권한이 맞으면 S3 data bucket에서 실제 작업 수행 (GET/PUT/LIST 등).
