이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
Amazon S3 소개
사용사례
- 백업과 스토리지, 파일용, 디스크용, 재해 복구 용도, 아카이브 용도, 하이브리드 클라우드 스토리지
- 애플리케이션 호스팅, 동영상/이미지 등 미디어 호스팅, 정적 웹사이트 호스팅
- 빅데이터 저장 분석
- Nasdap은 7년 간의 데이터를 S3 Glacier에 저장 -> Amazon S3의 아카이브 서비스와 유사
버킷
- S3는 파일을 버킷에 저장함.. 버킷은 상위 레벨 디렉토리로 표시
- 버킷 내 파일은 객체라고함
- 버킷은 계정 내에 생성됨. 버킷은 전역적으로 고유한 이름이 있어야함(모든 리전과 AWS 존재하는 모든 계정에서 유일해야함)
- 버킷은 리전 수준에서 정의됨(버킷 이름이 전역적인것과 무관)
버킷 명명 규칙
- 버킷 이름에는 대문자나 밑줄 X
- 3~63자 사이
- IP는 안됨
- 소문자나 숫자로 시작.. 문자 숫자 하이푼만 가능
- xn과 같은 접두사 제한
객체
- 객체의 키는 파일의 전체 경로가 됨
- 키는 접두사와 객체이름으로 구성됨... 접두사 이전 경로(폴더명)
- S3 그 자체로는 디렉토리의 개념은 없음... 핵심은 키
- 키는 긴 이름으로 접두사와 객체 이름으로 만들어지고 "/"로 구분됨
- 값은 본문의 내용으로 최대 크기는 5TB
- 5GB보다 파일이 크다면 '멀티파트 업로드'를 사용해서 파일을 쪼개서 업로드해야함
- 메타데이터 : 객체의 키-값 쌍 리스트 를 의미... 시스템이나 사용자에 의해 설정되어, 파일에 관한 요소나 메타데이터를 나타낼 수 있음
- 태그 : 유니코드 키-값 쌍으로 최대 10개까지 가능...보안과 수명주기에 사용됨
- 버전 ID : 버전 관리를 활성한 경우에 가지게됨
S3 보안
종류
사용자 기반
- IAM 정책으로 어떤 API 콜이 허용될지 승인해줌
- IAM 권한이 허용하거나 리소스 정책이 허용하는 경우에 특정 API 호출시 S3 객체에 액세스 할 수 있는 것.. 명백한 거부는 없음
- IAM 정책 내의 명시적인 부인(DENY)은 S3 버킷 정책보다 우선적으로 고려됨
리소스 기반
- 버킷 정책 : 가장 일반적으로 특정 사용자나 다른 계정의 사용자를 허용할 수 있음(교차 계정이라 함)
- 객체 ACL(객체 액세스 제어 목록) : 세밀한 보안 가능, 비활성화 가능
- 버킷 ACL : 덜 일반적, 비활성화 가능
암호 키
암호 키로 객체를 암호화함
블록 공개 액세스
- 기업 데이터 유출을 방지하기 위한 추가 보안 계층
- 버킷이 공개되어 있어도, 이 설정이 활성화 되어있다면 공개되지 않음
- 계정 레벨에서 설정가능
S3 버킷 정책
JSON 기반의 정책
- 리소스 : 정책이 적용되는 버킷과 객체
- 결과(Effect) : 허용/거부
- 작업(Action) : 허용하거나 거부할 수 있는 API 집합
- 원칙(Princial) : 정책을 적용할 계정 또는 사용자
사례
- 버킷에 대한 공개 액세스 설정
- 업로드 시 객체를 강제로 암호화
- 다른 계정으로의 액세스를 허용
정적 웹 사이트 호스팅
인터넷에서 접속 가능한 웹 사이트를 호스팅할 수 있음
웹 사이트 URL은 생성하는 AWS 리전에 따라 달라짐
공개를 허용하는 버킷에 html을 포함한 파일을 넣으면 됨
버전 관리
- 안전한 방법으로 업데이트할 방법
- 버킷 수준에서 '버전 관리' 설정을 활성화 시킬 수 있음
- 사용자가 파일을 업로드할 때마다 선택 키에서 버전이 관리됨.. 이때 동일 키를 업로드하고 덮어쓰면, 버전이 생성됨
- 의도치 않은 삭제를 보호해주고, 쉽게 롤백할 수 있음
주의사항
- 버전 관리가 활성화 되어 있지 않은 모든 파일은 Null 버전을 가짐
- 버전 관리를 중단해도 이전 버전을 삭제하지는 않음
- 버전 관리를 하면 삭제를 해도 delete marker를 남기고 soft delete 가능
S3 복제
- CRR(교차 리전 복제), SRR(동일 리전 복제)로 나뉨
- 소스 버킷과 복제 대상 버킷 둘다 버전 관리 활성화되어야함
- 서로 다른 AWS 계정간에도 사용할 수 있음
- 복제는 백그라운드에서 비동기식으로 이루어짐
- S3에 올바른 IAM 권한(읽/쓰기)이 있어야함
- 복제를 활성화한 후에는 새로운 객체만 복제 대상이 됨... 설정 전 객체는 기본적으로 복제안됨
- 기존 객체를 복제하려면 'S3 배치(batch) 복제 기능'을 사용해야함 <- 복제랑은 다른거임
- 기존 객체부터 복제에 실패한 객체까지 복제할 수 있는 기능
- 작업을 삭제시
- 소스 버킷에서 대상 버킷으로 삭제 마커를 복제하면됨
- 버전 ID로 삭제하는 경우 버전 ID는 복제되지 않음(악의적으로 다른 버킷으로 ID 삭제 마커 복제 방지)
- 체이닝 복제는 불가
ex) 1 -> 2 복제 2-> 3 복제 상황에서, 1이 3에 복제되지는 않음
`- 기본적으로 삭제 마커는 복제되지 않지만, '삭제 마커 복제 옵션'을 통해 삭제 마커도 복제 가능
사례
- CRR : 컴플라이언스(법규, 내부 체제 관리), 데이터가 다른 리전에 있어 발생하는 지연시간을 줄일 때 사용
- SRR : 다수의 S3 버킷간의 로그를 통합, 개발 환경이 별도로 있어 운영과 개발 환경간 실시간 복제가 필요할 때 사용
`S3 스토리지 클래스
객체를 생성할 때 클래스를 선택할 수 있고, 수동으로 수정할 수도 있음 & 수명주기를 설정해 스토리지 클래스 간 객체를 자동으로 이동할 수도 있음
내구성 : 객체가 손실되는 횟수(9가 11개 99.99999999% 내구성 보장)
가용성 : 서비스가 얼마나 용이하게 제공되는지.. 스토리지 클래스마다 다름
ex) S3 스탠다드는 99.99% 가용성 == 1년에 53분은 서비스를 사용할 수 없음
종류
1. Amazon S3 Standard - 범용적 사용
- 가용성 99.99%
- 자주 액세스하는 데이터에 사용
- 지연시간이 짧고 처리량이 많음
- 2개의 기능 장애를 동시에 버틸 수 있음
- 사례 : 빅데이터 분석, 모바일&게임 애플리케이션, 콘텐츠 배포
2. Amazon S3 Standard-Infrequent Access(IA)
- 가용성 99.9%
- 자주 사용하진 않지만 필요한 경우 빠르게 액세스해야하는 데이터
- S3 스탠다드보단 적은 비용.. 단 검색 비용이 발생함
- 재해복구와 백업에 사용
3. Amazon S3 One Zone-Infrequent Access(IA)
- 가용성 99.5%
- 단일 AZ내에서는 높은 내구성을 갖지만, AZ가 파괴되면 데이터를 잃게됨
- 온프레미스 데이터를 2차 백업하거나 재생성 가능한 데이터를 저장함
Amazon S3 Glacier
- 콜드 스토리지로 아카이빙과 백업을 위한 저비용 객체 스토리지
- 스토리지 비용과 검색 비용이 들어감
4. Amazon S3 Glacier Instant Retrieval
- 밀리초 단위로 검색(분기에 한번 액세스하는 데이터에 적합)
- 최소 보관 기간이 90일
5. Amazon S3 Glacier Flexible Retrieval
- 조회시간에 따라 3개의 옵션 Expedited(1~5분), Standard(3~5시간), Bulk(5~12시간, 무료임)
- 최소 보관 기간 90일
6. Amazon S3 Glacier Deep Retrieval
- 2개의 옵션 Standard(12시간), Bulk(48시간)
- 비용이 가장 저렴, 최소 보관 180일
7. Amazon S3 Intelligent Tiering
- 사용 패턴에 따라 액세스된 티어간 객체를 이동할 수 있게 해줌
- 소액의 월별 모니터링 비용과 티어링 비용 발생... 단, 검색 비용은 없음
- FrequentAccess 티어(자동) : 기본티어
- Infrequent Access 티어(자동) : 30일 동안 액세스하지 않는 객체 전용 티어
- Archive Instant Access 티어(자동) : 90일 동안 액세스 하지 않음
- Archive Access 티어(옵션) : 90~700일 이상 구성
- Deep Archive Access 티어(옵션) : 180~700일 이상 구성
알아서 객체를 이동시켜줘서 편하게 구성가능
고급 Amazon S3
스토리지 클래스 간 이동
- 자주 객체에 액세스하지 않을 걸 알고 있으면, Standard IA로 옮기고, 객체를 아카이브화 하려는 걸 알고 있다면 Glacier 티어나 Deep Archive 티어로 옮길 수 있음.
- 객체를 수작업으로 옮길 수도 있지만, 라이프사이클 규칙을 이용해서 자동으로 옮길 수도 있음
라이프 사이클 규칙
- Transition Actions : 다른 스토리지 클래스로 이전하기 위해 객체를 설정
- ex) 생성된지 얼마 뒤에 ~~로 옮겨라
- Expiration Actions : 일정한 시간 뒤에 만료되어서 객체를 삭제하도록 설정
- ex) 로그파일을 1년 뒤에 지우도록
- 모든 파일 버전을 삭제하도록 설정할 수도 있음
- 특정 기간뒤에 완료되지 않은 멀티파트 업로드를 삭제하도록 설정
규칙들은 버킷 전체나 특정한 객체 태그에 적용할 수도 있음
Amazon S3 Analytics
어떤 객체를 다른 클래스로 이전할 최적의 일 수를 결정하도록 도와줌
- Standard와 Standard IA에 대한 추천을 해줌
- One-Zone IA나 Glacier와는 호환되지 않음
- 리포트는 매일 업데이트 되며, 데이터 분석 결과는 24~48h 후 볼 수 있음
`S3 요청자 지불
기본적으로 버킷 소유자가 버킷과 관련된 S3 스토리지 및 데이터 전송 비용을 지불함
요청자 지불을 설정하면 버킷 소유자가 아닌 요청자가 객체 데이터 다운로드 비용을 지불
ㄴ 단, 요청자는 AWS에서 인증을 받은 사용자여야함
S3 이벤트 알림
* 이벤트 : 객체의 생성/삭제/복구/복제 등
- 사례 : S3에 일어나는 특정한 이벤트에 자동으로 반응하려는 경우
ex) S3에 업로드된 모든 이미지의 섬네일을 생성하려는 경우... 이벤트 알림을 만들고 대상에게 전송할 수 있음(SNS, SQS, 람다)
- 원하는 만큼 S3 이벤트를 만들수 있고, 어떤 타깃에도 전송 가능
- 통상적으로 몇 초 내에 적용되지만, 몇 분이 걸릴 수도 있음
IAM 권한
이벤트 알림이 작동하려면 IAM 권한이 필요함
S3 버킷이 원하는 대상에 메시지를 직접 전송하도록 IAM 정책 설정(각 대상의 리소스 액세스 정책을 정의)
Amazon EventBridge
- 모든 이벤트는 이미지 브릿지로 감
- 이미지 브릿지에서는 18가지 AWS 서비스로 이벤트 전송 가능
- 이를 이용하면 고급 필터 사용 가능 : 메타데이터, 객체 사이즈, 이름으로 필터링 후 다수의 대상에 전송 가능
- 아카이빙, 이벤트 중계, 안정적 전달 가능
S3 퍼포먼스
- 기본적으로 S3는 매우 높은 요청 수로 자동으로 스케일링됨
- S3에서 첫번째 바이트를 가져오는데 100~200ms의 지연시간을 가짐
- 버킷 내에서 prefix(접두사)당 초당 3,500개의 PUT/COPY/POST/DELETE 또는 5,500개의 GET/HEAD 요청을 받을 수 있음
- 버킷의 prefix 수에는 제한이 없음
ex) 객체 경로 -> prefix 버킷/?/?/?/파일이름 : 버킷과 파일이름 사이 모든 것이 prefix
즉 하나의 접두사마다 초당 5,500개 GET이기 때문에 접두사 모두에 균등하게 읽기를 분산하면 초당 22,000개도 읽어올 수 있다는 의미
`성능 최적화방법
1. 멀티파트 업로드
- 100MB 넘으면 권장됨, 5GB 넘으면 필수적...
- 업로드를 병렬화 시켜, 전송속도를 높이고 대역폭을 최대화할 수 있음
2. S3 전송 가속화
- 업로드 및 다운로드를 위한 것
- 파일을 AWS 엣지 위치로 전송하여 전송 속도를 높임... 그러면 데이터가 타겟 리전으로 전송됨
- 엣지 위치는 단순한 지역 이상으로, 200개 이상의 엣지 위치가 있으며 수가 늘어나고 있음
- 멀티파트 업로드와도 호환됨
ex) 한국에서 미국 S3 버킷에 파일을 넣을 때, 한국에 있는 Edge Location까지 공용인터넷으로 빠르게 옮기고, 엣지 위치에서 프라이빗 AWS 네트워크로 S3로 옮김
3. S3 바이트-범위 가져오기(Range Fetches)
- 파일의 특정 바이트 범위를 가져와 가져오기를 병렬화하는 것
- 특정 바이트 범위를 가져오는데 실패시, 더 작은 바이트 범위를 재시도함(복원력 향상)
- 다운로드 속도 향상
- 특정 파트만 필요할 때 빠르게 가져오기도 가능
S3 Select & Glacier Select
- S3에서 파일을 검색할 때, 검색한다음 필터링하면 너무 많은 데이터를 가져와야함... 서버 측 필터링을 활용해 해결 가능
- SQL문에서 행과 열을 사용해 간단한 필터링 가능
- 네트워크 전송도 줄어들고, 검색&필터링에 드는 클라이언트 측 CPU 비용도 줄어듬
- 속도 400% 향상, 비용 80% 절감
S3 Batch Operations
- 단일 요청으로 기존 S3 객체에서 대량 작업을 수행하는 서비스'
사례
- 한번에 많은 S3 객체의 메타데이터와 프로퍼티 수정 가능
- 배치 작업으로 S3 버킷 간 객체 복사 가능
`- 암호화되지 않은 모든 객체 암호화 가능
- ACL이나 태그 수정 가능
- S3 Glacier에서 한번에 많은 객체 복원 가능
- Lambda 함수를 호출해서, 사용자 지정작업 수행 가능
- 작업은 객체의 목록, 수행할 작업, 옵션 매개 변수로 구성
- 직접 스크립팅하는 것보다 재시도 관리할 수 있고, 진행상황 확인, 알림 생성, 보고서 생성이 가능함
- S3 Inventory라는 기능으로 객체 목록을 가져오고, S3 Select로 필터링하여, 배치 작업에 포함하려는 필터링된 객체 목록을 얻을 수 있음
S3 Storage Lens
- 스토리지 이해, 분석, 최적화에 도움을 줌
- 스토리지 렌즈를 통해 이상 징후 파악, 비용 효율성 파악, 모범 사례 적용 가능
- 30일 사용량과 메트릭이 제공되어, 조직 / 특정 계정 / 지역 / 버킷 / 접두사 별로 데이터 집계가능
- 대시보드와 보고서를 내줌 (기본 대시보드 삭제 불가.. 단 비활성화는 가능)
`- 기본 대시보드에는 여러 계정과 여러 지역에 걸쳐 데이터가 있음
- S3에 의해 사전 구성됨
매트릭 종류
1. 요약 매트릭
- 일반적인 인사이트 제공, 스토리지 바이트, 객체 크기/수 등
- 빠르게 성장하거나 사용하지 않는 버킷, 접두사 등 식별 가능
2. 비용 최적화 지표
- 최신 버전이 아닌 객체의 수, 실제로 차지하는 공간, 불완전한 멀티파트 업로드 등 파악 가능
- 어떤 객체를 더 저렴한 스토리지 클래스로 옮겨야하는지 파악 가능
3. 데이터 보호 지표
- 모든 버킷이 버전 관리가 활성화되었는지 확인 가능
- 데이터 보호 모범 사례를 따르지 않는 것 식별 가능
4. 액세스 관리 매트릭 : 어떤 객체 소유권이 지정되어 있는지 파악 가능
5. 이벤트 매트릭 : S3 이벤트 알림이 구성된 버킷의 수를 파악 가능
6. 성능 매트릭 : S3 전송 가속이 활성화된 버킷 수 확인 가능
7. 액티비티 매트릭 : 스토리지 별 허용된 요청 확인 가능
8. 세부 상태 코드 매트릭 : HTTP 상태에 대한 인사이트 제공, 버킷의 사용 유형 파악 가능
`무료 vs 유료
무료지표 : 28개의 사용량 지표 포함, 14일동안 조회 가능
유료지표 : 고급 지표, 비용 최적화, 데이터 보호, 상태 코드 등 포함, CloudWatch에 퍼블리쉬되어 추가 비용없이 조회 가능, 접두사 수준에서 메트릭 수집 가능, 15개월동안 조회 가능
Amazon S3 보안
S3 객체 암호화
1. 서버 측 암호화(SSE)
- S3-SSE : S3에서 관리하는 키를 이용한 서버 측 암호화 - 새 버킷/객체에 대해 기본값
우리는 키에 액세스 할 수 없고 AWS에서 소유하고 있음, AES-256 메커니즘을 사용
업로드시 헤더에 "x-amz-server-side-encryption":"AES256" 포함 필수
- SSE KMS : KMS 키를 이용해서 암호화 키를 관리
KMS는 사용자가 키를 통제 할 수 있음 + CloudTrail을 이용해 키 사용을 검사할 수 있음
업로드시 헤더에 "x-amz-server-side-encryption":"aws:kms" 포함 필수
업로드할 때 GenerateDataKey라는 자체 KMS API 존재
다운로드할 때 Decrypt KMS API로 복호화를 해야함
API 호출할 때마다 KMS의 초당 API 호출 쿼터에 합산되고, 리전에 따라 초당 5,000~30,000까지 가능
ㄴ `너무 요청수가 많으면 KMS 스로틀링을 야기할 수 있음
- SSE-C : 소비자가 제공하는 키를 이용함
키가 AWS 외부에서 관리됨.. 키를 AWS에 전송해주는 방식, S3는 제공받은 암호화키를 저장하지 않음
키를 S3로 전송하기에 HTTPS를 사용해야함
모든 요청에 HTTP 헤더의 일부로서 키를 전달해야함
2. 클라이언트 측 암호화
클라이언트 측에서 먼저 데이터를 암호화한 다음 S3에 전송한다는 개념
복호화도 클라이언트 측에서 수행
* 버저닝된 상태에서 암호화 방법을 바꾸면 새로운 버전의 파일이 생성됨
전송 중 암호화( SSL/TLS )
S3에는 2개의 엔드포인트가 있음
- HTTP 엔드포인트 : 암호화 X
- HTTPS 엔드포인트 : 암호화 O <- 권장사항.. SSE-C를 사용한다면 필수적
전송 중 암호화 강제 방법
- S3 버킷에 정책 설정 : Condition 탭에 추가해서 HTTPS 사용자만 허용 가능
기본 암호화 vs 버킷 정책
기본으로 버킷 생성시 SSE-S3 암호화가 됨.. 새로운 객체 저장시 SSE-S3로 됨
SSE-KMS 등 다른 암호화 방식을 기본 암호화로 바꿀 수 있음
버킷 정책을 이용해서 암호화를 강제하고, 올바른 암호화 헤더가 없으면 S3를 PUT하는 API 요청을 거절할 수 있음
버킷 정책은 항상 기본값 암호화 설정 이전에 평가됨 <- 기본값과 상관없이 암호화를 강제할 수 있는 것
S3 CORS
CORS란
교차 오리진 리소스 공유... 오리진 = 체계(프로토콜) + 호스트(도메인) + 포트
- CORS는 웹 브라우저 기반 보안 메커니즘으로 메인 오리진을 방문하는 동안, 다른 오리진에 대한 요청을 허용하거나 거부함
- 오리진이 같다? 프로토콜(https), 호스트(example.com), 포트(443)가 동일한 것
ㄴ 오리진이 다른 곳으로 요청을 보내려면... 다른 오리진이 CORS 헤더를 사용해서 요청을 허용하지 않는한 요청은 이행되지않음 (ex: Access-Control-Allow-Origin)
다른 오리진이 요청을 허용해두었다면, 사전 연결 확인때 보낸 요청으로 허용하는 origin과 메서드를 응답함
`S3에서 CORS 동작
정확한 CORS 헤더를 활성화 해야함... S3에서 특정 오리진을 허용하거나 * 로 모든 오리진을 허용해야함
S3 MFA Delete
MFA Delete를 활성화하면 위험한 작업에 대해서 추가로 보안을 강화할 수 있다.
버킷 소유자인 루트 계정만이 활성화/비활성화를 할 수 있음
MFA가 필요한 곳
- S3에서 객체 버전을 영구적으로 삭제할 때
- 버킷에서 버저닝을 중단할 때
버저닝을 시작하거나 삭제된 버전을 나열하는 작업은 MFA 없어도됨
S3 액세스 로그
- 감사 목적으로 S3 버킷에 대한 모든 액세스를 기록할 수 있음
- 승인/거부와 상관없이 S3로 온 모든 요청을 다른 S3 버킷(같은 AWS 리전에 있어야함)에 로깅
- 데이터 분석 도구로 분석할 수 있음
- 버킷 정책은 설정하면 자동으로 업데이트 됨
주의사항
- 로깅 버킷을 모니터링하는 버킷과 동일하게 설정X -> 무한 루프
사전 서명된 URL
- S3 콘솔, CLI, SDK를 사용하여 생성할 수 있는 URL
- 만료 기간 있음 : 콘솔 : 12h, CLI 168h
- URL을 생성할 때, URL을 받는 사용자는 URL을 생성한 사용자의 GET/PUT 권한을 상속받음
- 다운로드/업로드 시 특정 파일에 임시로 액세스할 때 널리 사용되는 방법
사례 : 로그인한 사용자만 액세스할 수 있는 비디오 다운로드, 접근가능한 사용자 목록이 변해서 URL을 동적으로 생성해야하는 상황, 일시적으로 사용자가 S3 특정위치에 업로드할 수 있도록 허용해야하는 상황
S3 잠금 정책 및 Glacier 볼트 잠금
S3 Glacier 볼트 잠금
- WORM(한 번쓰고, 여러번 읽는다) 모델을 채택하기 위해 Glacier 볼트를 잠그는 것
ㄴ 수정 삭제를 할 수 없도록 잠그는 것
- 볼트 잠금 정책을 생성하고, 정책을 잠그면 누구도 변경/삭제 불가
ㄴ 관리자나 AWS 서비스를 사용해도 삭제할 수 없음
- 규정 준수와 데이터 보존에 유용함, 법률적인 사항에 유용함
S3 객체 잠금
- 버저닝 활성화 필수
- WORM 모델을 채택하기 위해 사용
- 버킷 수준의 잠금이 아닌 모든 객체에 각각 적용할 수 있는 잠금
- 특정 시간동안 삭제되는 것을 차단할 수 있음
`종류
1. 규정 준수 모드 : S3 Glacier 볼트 잠금과 매우 유사, 사용자를 포함한 그 누구도 객체 버전을 덮어쓰거나 삭제할 수 없음. 보존 모드를 변경하거나 보존 기간을 변경할 수도 없음
2. 거버넌스 보존 모드 : 대부분 유저는 객체 버전을 덮어쓰거나 삭제하거나, 로그 설정을 변경할 수 없음
단, 일부 사용자는 IAM을 통해 부여받은 권한으로 깰 수 있음
둘다 보존 기간을 설정해야함.. 원하는 만큼 연장 가능
3. 법적 보존 : S3 버킷 내 모든 객체를 무기한으로 보호함.. 보존 기간과는 무관함.. 영구적으로 보호됨
단, 마찬가지로 IAM 권한으로 깰 수 있음
S3 액세스 포인트
- 액세스 포인트 정책을 사용해서 특정 접두어에 읽/쓰기 할 수 있는 권한 부여 가능
- 액세스 포인트는 각각의 보안 정책을 가짐... 적절한 IAM 권한이 있는 사용자들이 사용할 수 있음
- 고유의 DNS 이름을 가짐 (인터넷 오리진이나 VPC 오리진에 연결되도록 설정 가능)
- VPC 오리진을 프라이빗 액세스가 가능하도록 정의할 수 있음
- ex) VPC 내에 존재하는 EC2에서 퍼블릭 인터넷을 거치지 않고, 액세스 포인트로 S3 접근 가능
EC2 - VPC 엔드포인트 - Access Point VPC 오리진 - S3
S3 객체 람다
- S3 액세스 포인트의 활용 사례
- 호출자가 객체를 받기 직전에 그 객체를 수정하려는 경우
- 액세스 포인트를 만들고 람다 함수와 연결해서 1차 가공(추가/삭제) 후 객체 람다 액세스 포인트를 통해서 요청에 액세스할 수 있도록함
- 따로 객체가 추가/삭제 된 버킷을 만들지 않고서 한 버킷에서 원하는대로 객체를 수정한 뒤 내보낼 수 있음
- 사례 : 분석시 개인식별정보를 삭제하려는 경우, 즉석해서 이미지 크기를 조정하거나 워터마크를 추가하는 경우
