[AWS] OAI와 OAC의 차이점, 한 번에 이해하기

https://medium.com/@aperteda/serving-static-website-on-aws-with-private-s3-bucket-and-cloudfront-oac-origin-access-control-7b19292d82aa

 

OAI와 OAC 비교하기

OAI에 대해서

OAI(Origin Access Identity)는 CloudFront가 Amazon S3 버킷의 콘텐츠에 안전하게 액세스할 수 있도록 하는 기존 인증 방식이다.

CloudFront가 특정 S3 버킷에만 접근하도록 제한하며, 퍼블릭 액세스를 차단할 수 있다.

 

 

OAC에 대해서

OAC(Origin Access Control)는 OAI를 대체하는 최신 방식으로, 더 정교한 권한 제어를 제공한다.

IAM 역할 기반 서명 요청 (SigV4) 방식으로 CloudFront가 오리진(S3 포함)에 접근한다.

 

 

IAM 역할 기반 서명 요청 (SigV4, Signature Version 4)에 대해서

SigV4(Signature Version 4)는 AWS API 요청을 인증(Authenticate)하고 무결성(Integrity)을 보장하기 위해 사용하는 서명 방식이다. (=즉, AWS 서비스 간 요청의 무결성과 인증을 보장하는 서명 방식이다.)

요청자는 IAM 자격 증명(IAM Role, IAM User 등)을 기반으로 요청에 디지털 서명을 추가하며, 이 서명은 요청 메시지의 중요한 부분(헤더, 본문 등)을 해시화하여 생성된다.

흐름 : CloudFront → 서명 요청 → 오리진 → 서명 검증 후 응답

활용 사례 : CloudFront OAC, S3 Pre-Signed URL 등

 

OAI와 OAC 비교 표

항목	OAI(Origin Access Identity)	OAC(Origin Access Control)
출시 시기	오래된 방식 (기존 표준)	2022년 이후 도입된 최신 방식
지원 오리진	S3 전용	S3 및 커스텀 오리진(EC2, ALB 등) 모두 지원
보안 방식	S3 버킷 정책에 OAI ID로 접근 제어	SigV4 서명 기반 인증 요청
IAM 정책 연동	사용하지 않음	IAM 정책으로 직접 제어
권장 여부 (2025 기준)	비추천 (점진적 중단 예정)	AWS 권장 방식
버킷 정책 단순화	OAI 사용 시 별도 정책 필요	OAC는 IAM 정책으로 통합 가능
성능 차이	없음	없음 (보안과 관리 유연성 차이)
CloudFront 설정 위치	오리진 설정에서 OAI 추가	별도 OAC 리소스를 생성 후 연결

 

 

---

 

예제 문제

Amazon CloudFront 배포판에는 단일 Amazon S3 버킷이 원본으로 사용됩니다. 시스템 운영 관리자는 사용자가 CloudFront 엔드포인트의 요청을 통해서만 S3 버킷에 액세스할 수 있도록 해야 합니다.
이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

• A. S3 버킷에서 S3 퍼블릭 액세스 차단을 구성합니다. CloudFront 배포에서만 GetObject 작업을 허용하도록 S3 버킷 정책을 업데이트합니다.
• B. CloudFront 배포에서 Origin Shield를 구성합니다. 사용자 지정 Origin_Shield 헤더를 포함하도록 CloudFront 오리진을 업데이트합니다.
• C. 원본 액세스 ID(OAI)를 생성합니다. OAI를 CloudFront 배포에 할당합니다. S3 버킷 정책을 업데이트하여 OAI에 대한 액세스를 제한합니다.
• D. 원본 액세스 ID(OAI)를 생성합니다. OAI를 S3 버킷에 할당합니다. CloudFront 원본을 업데이트하여 OAI 값이 포함된 사용자 지정 원본 헤더를 포함합니다.

답 : C

이유 : CloudFront 엔드포인트로만 S3 버킷에 액세스할 수 있게 하기 위해서는 OAC(구. OAI)를 사용해야 한다. 

D가 틀린 이유 : OAI는 헤더를 사용한 기술이 아니라 S3 버킷 정책에 OAI ID로 접근을 제어한다.