Day 5 - S3 고급 기능 + Week 5 종합 복습

회사의 의료 영상 데이터를 규정상 10년 보존해야 한다. 처음 1년은 자주 접근하고, 이후 접근이 거의 없다가 감사 시 즉시 조회가 필요하다. 가장 비용 효율적인 수명 주기 설계는?

• A10년 내내 Standard에 그대로 보관해 항상 즉시 조회를 보장 — 즉시성은 충족하나 거의 접근 없는 9년 구간까지 최고가 클래스라 비용 최적화에 정반대
• BStandard로 1년 보관 후 Glacier Deep Archive로 전환해 장기 보관 비용을 최소화 — Deep Archive는 복구에 12~48시간 걸려 감사 시 "즉시 조회" 요건을 위반
• CStandard → 30일 후 Standard-IA → 1년 후 Glacier Instant Retrieval → 10년 후 삭제
• DIntelligent-Tiering으로 10년간 자동 티어링에 맡겨 접근 패턴 변화에 대응 — 자동이지만 객체당 모니터링 비용이 10년 누적되고 Archive 티어가 켜지면 즉시 조회가 깨질 수 있음

모바일 앱 사용자가 프로필 사진을 업로드해야 한다. 서버가 대용량 파일 데이터를 처리하는 부하를 피하고 싶다. 가장 적합한 아키텍처는?

• A클라이언트가 서버로 파일을 보내면 서버가 받아 S3에 다시 올리는 순차 프록시 업로드 — 모든 바이트가 서버를 거쳐 피하려던 대역폭·부하가 그대로 서버에 집중
• B서버에서 PUT Presigned URL 생성 → 클라이언트가 해당 URL로 S3에 직접 업로드
• CS3 Transfer Acceleration 엔드포인트로 클라이언트가 직접 업로드해 전송 속도를 가속 — 원거리 전송은 빨라지나 인증·권한 통제 수단이 아니며 가속 요금이 추가됨
• DCloudFront 배포를 업로드 경로로 두어 엣지에서 S3로 전달 — CloudFront는 주로 다운로드 캐싱·배포용이라 사용자 업로드 부하 제거 패턴으로는 부적합

AWS Organizations에서 모든 S3 버킷에서 Block Public Access를 강제로 유지하고 싶다. 어떤 서비스를 사용하는가?

• A각 계정에서 버킷마다 수동으로 Block Public Access 4개 옵션을 켜 둔다 — 강제력이 없어 누군가 끄면 그대로 풀리고 조직 전체 일관성을 보장하지 못함
• BSCP(Service Control Policy)로 Block Public Access 비활성화 작업 거부
• CLambda + EventBridge로 BPA 비활성화 이벤트를 감지하면 즉시 재활성화하는 자동 교정을 구성 — 사후 탐지·수정이라 변경과 복구 사이에 공개 노출 공백이 생김
• DAWS Config 관리형 규칙으로 BPA 미준수 버킷을 탐지하고 대시보드에 보고 — 탐지만 할 뿐 자동 차단·교정에는 별도 Remediation Lambda가 필요

S3 이벤트 알림을 통해 객체 업로드 시 Lambda를 호출하는 아키텍처에서, 같은 파일이 짧은 시간 내에 두 번 Lambda를 트리거했다. 이 현상의 원인과 해결책은?

• ALambda 동시성 설정 오류로 같은 이벤트가 중복 실행됨 — Reserved Concurrency를 늘린다 — 동시성은 병렬 실행 수일 뿐 같은 이벤트의 중복 전달과 무관
• BS3 이벤트 알림은 at-least-once 전달이므로 정상 동작 — Lambda 내 멱등 처리 구현
• C버킷 정책이 이벤트 알림을 두 대상에 중복 등록해 두 번 호출됨 — 버킷 정책을 정리한다 — 버킷 정책은 접근 제어일 뿐 이벤트 알림 등록·중복과 관련 없음
• DObjectCreated 와일드카드 필터가 PUT·COPY를 모두 잡아 중복됨 — ObjectCreated:Put만 필터링한다 — 이벤트 타입을 좁혀도 단일 PUT의 중복 전달 자체는 막지 못함

글로벌 서비스를 제공하는 회사가 S3에서 정적 웹 애플리케이션을 호스팅한다. HTTPS 필수, 글로벌 최적화, SEO를 위한 커스텀 도메인이 요구사항이다. 어떤 아키텍처가 맞는가?

• AS3 정적 웹사이트 엔드포인트에 Route 53 alias만 연결해 커스텀 도메인으로 서빙 — 웹사이트 엔드포인트는 HTTP만 지원해 HTTPS 필수 요건을 충족하지 못함
• B웹사이트 호스팅을 켠 퍼블릭 S3 버킷 + CloudFront + ACM + Route 53 — HTTPS·도메인은 되지만 버킷을 퍼블릭으로 열어 OAC 방식보다 보안이 약함
• CS3 버킷 (OAC) + CloudFront + ACM + Route 53
• DEC2 웹 서버에서 정적 파일을 서빙하고 S3는 원본 저장만 사용 — 상시 인스턴스 운영·패치·스케일링이 필요해 정적 사이트에 과도한 복잡도

S3 버킷에서 수명 주기 정책이 "30일 후 Standard-IA로, 90일 후 Glacier Flexible로 전환"으로 설정되어 있다. 50일째 되는 날 객체를 삭제했다. 청구되는 요금은?

• A30일치 Standard + 실제 IA 저장 20일치 Standard-IA — 일수만 보면 그럴듯하나 IA의 30일 최소 보관 과금을 빠뜨려 20일만 청구하는 오답
• B50일치 Standard + 30일치 Standard-IA (IA 최소 보관 30일)
• C전환 후에도 원래 클래스 기준으로 50일치 Standard만 청구 — IA 전환·최소 보관 과금을 무시한 오답
• DGlacier 전환 조건(90일) 충족 전 삭제이므로 90일치 Standard-IA가 청구 — 존재하지 않는 Glacier 최소 보관 소급 과금을 가정한 오답

개발팀이 S3에 저장된 Lambda 배포 패키지를 다른 AWS 계정의 Lambda가 접근해야 한다. S3 버킷을 퍼블릭으로 열지 않고 가장 안전하게 접근 권한을 부여하는 방법은?

• A배포 패키지마다 GET Presigned URL을 생성해 다른 계정 Lambda에 전달 — 동작은 하나 URL이 만료되고 배포 버전마다 재발급해야 해 자동화 파이프라인에 부적합
• B버킷 정책에서 다른 계정 ARN을 Principal로 지정해 Allow
• C버킷을 퍼블릭으로 열고 다른 계정 NAT IP만 화이트리스트로 허용 — 퍼블릭 노출 + IP 스푸핑 위험이 있어 "퍼블릭 비공개" 요건을 위반
• DCRR로 패키지를 다른 계정이 소유한 버킷·리전에 복제해 로컬에서 읽게 함 — 데이터를 복제·중복 저장할 뿐 접근 권한 부여 메커니즘이 아니며 버전 관리 등 추가 설정 필요

2024년 기준 모든 S3 신규 버킷의 기본 설정으로 올바른 것은?

• A퍼블릭 접근 허용 + 암호화 비활성화 + ACL 활성화 — 편의를 위해 개방형으로 출고된다는 가정이지만 현재는 secure-by-default 원칙과 정반대
• BBlock Public Access 4개 모두 비활성화 + SSE-S3 기본 암호화 + ACL 활성화 — 암호화는 맞지만 BPA가 꺼진 채 출고된다는 부분이 틀림
• CBlock Public Access 4개 모두 활성화, SSE-S3 기본 암호화, Bucket Owner Enforced(ACL 비활성화)
• DBlock Public Access 4개 중 1개만 활성화 + 암호화는 선택 + Object Writer 소유권 — 부분 활성화·선택적 암호화·구식 소유권 모델로 현재 기본값과 불일치

S3 버킷에 수십억 개의 객체가 있고, 전체 객체 중 SSE-KMS 암호화가 적용되지 않은 객체를 찾아서 일괄 암호화 적용해야 한다. 어떤 방법이 적합한가?

• ALambda로 ListObjects를 페이지네이션하며 객체마다 HeadObject로 암호화 상태를 확인하고 재암호화 — 동작은 하나 수십억 객체에 대한 API 호출·실행 시간·비용이 폭발해 비현실적
• BS3 Inventory로 암호화 상태 보고서 생성 → Athena로 미암호화 객체 필터링 → S3 Batch Operations로 SSE-KMS 복사 적용
• CS3 Storage Class Analysis 보고서에서 객체별 암호화 상태를 추출해 대상 목록을 만든다 — Storage Class Analysis는 접근 패턴·스토리지 클래스 분석용이라 암호화 상태를 제공하지 않음
• DCloudTrail PUT 이벤트 로그를 역추적해 SSE 헤더 유무로 미암호화 객체를 식별 — CloudTrail 보존 기간 밖 객체를 놓치고 수십억 건 로그 분석이 비효율적

다음 시나리오에서 올바른 해결책을 선택하라. "회사는 파트너사가 특정 S3 버킷에 파일을 업로드해야 한다. 파트너는 AWS 계정이 없다."

• A파트너 전용 IAM 사용자를 만들고 PutObject만 허용한 Access Key를 전달 — 권한은 좁혀도 외부에 장기 자격증명을 넘기게 되어 키 관리·회전 부담이 큼
• B버킷을 퍼블릭 쓰기 가능으로 설정해 누구나 업로드하게 함 — 인증 없는 공개 쓰기는 데이터 오염·악용 위험이 큰 심각한 보안 사고
• C파트너용 PUT Presigned URL을 주기적으로 생성하여 전달
• D파트너 네트워크와 VPC Peering을 맺어 프라이빗 경로로 업로드하게 함 — 파트너가 AWS 계정·VPC를 보유해야 성립하므로 "계정 없음" 전제와 모순

S3 버킷 A(us-east-1)에서 버킷 B(ap-northeast-2)로 CRR을 설정했다. 버킷 A에서 객체를 삭제 마커 없이 직접 영구 삭제(버전 ID 명시)했다. 버킷 B에서는?

• A영구 삭제가 복제 파이프라인을 통해 전파되어 버킷 B의 해당 버전도 자동으로 삭제된다 — CRR은 기본적으로 버전 영구 삭제를 복제하지 않아 전파되지 않음
• B해당 객체는 버킷 B에 그대로 유지된다
• C영구 삭제 대신 삭제 마커가 버킷 B로 복제되어 최신 버전이 가려진다 — 버전 ID 명시 영구 삭제이지 삭제 마커 생성이 아니며, 삭제 마커 복제도 기본 비활성
• D원본 버전이 사라져 정합성 검사에 실패하고 복제 실패 이벤트·알림이 발생한다 — 삭제는 복제 대상이 아니라 실패로 처리되지 않음

다음 중 S3 Access Point에 대한 올바른 설명으로 모두 맞는 것은?

• AAccess Point는 기존 버킷과 별개로 데이터를 담는 새 버킷을 생성한다 — Access Point는 새 버킷을 만들지 않고 기존 버킷 위에 이름 붙은 가상 입구만 추가
• BVPC 전용 Access Point로 인터넷에서의 접근을 차단할 수 있다
• CAccess Point는 버킷당 최대 1개만 생성 가능해 입구를 단일화한다 — 실제로는 버킷당 수천 개(최대 10,000개) Access Point를 만들 수 있음
• D각 Access Point는 자체 독립적인 정책과 DNS 이름을 가진다