AWS S3 서버 액세스 로깅을 켜고 로그 전용 버킷 연결하기

S3 버킷에 누가 어떤 요청을 보냈는지 남기려면 서버 액세스 로깅을 켜야 합니다. 기본값은 꺼짐입니다. 이 글에서는 로그를 받을 전용 버킷과 로그를 남길 버킷을 따로 만들어 연결하고, 로깅을 켤 때 S3가 대상 버킷에 정책을 자동으로 붙이는 것을 확인합니다. 버킷 만들기 화면은 S3 버킷 보안 기본값 글과 같으므로 여기서는 이름만 입력하고 기본값으로 만듭니다.

준비물

화면의 계정 ID와 사용자 이름은 가렸습니다. 버킷 이름은 고유해야 하므로 같은 이름이 이미 쓰이고 있으면 끝의 숫자를 바꿉니다. 삭제 화면에는 버킷을 삭제하면 다른 AWS 사용자가 같은 이름을 쓸 수 있다는 경고가 있습니다.

1. 로그를 받을 버킷 만들기

S3 콘솔의 버킷에서 버킷 만들기를 누르고 버킷 이름에 cr-demo-logs-dst-1018을 입력합니다. 다른 항목은 건드리지 않고 맨 아래 버킷 만들기를 누릅니다.

같은 방법으로 로그를 남길 cr-demo-logs-src-1018 버킷도 만듭니다. 이 버킷에는 실제 서비스라면 파일이 들어 있을 것입니다. 이 실습에서는 빈 상태로 둡니다.

2. 원본 버킷의 서버 액세스 로깅 화면 열기

cr-demo-logs-src-1018 버킷을 열고 속성 탭을 아래로 내리면 서버 액세스 로깅 칸이 있습니다.

새로 만든 버킷은 화면에 비활성됨으로 표시됩니다. 아래 AWS CloudTrail 데이터 이벤트 칸은 CloudTrail 콘솔에서 따로 구성하라는 안내만 있고, 이 글에서는 열지 않았습니다. 편집을 누릅니다.

3. 로깅 켜기와 대상 지정

서버 액세스 로깅 편집 화면에서 활성화를 선택하면 노란 안내 상자가 나타납니다.

안내에 따르면 S3 콘솔이 대상 버킷의 정책을 자동으로 업데이트합니다. 대상 칸에 s3://cr-demo-logs-dst-1018/logs/를 입력합니다. 옆의 S3 찾아보기 단추로 버킷을 골라도 됩니다.

입력하면 대상 리전, 대상 버킷 이름, 대상 접두사가 아래에 자동으로 나뉘어 표시됩니다. 접두사 끝의 /를 빼면 접두사가 로그 파일 이름에 그대로 붙으므로 폴더처럼 쓰려면 /까지 입력합니다.

키 형식은 두 가지입니다. 기본값은 날짜와 시각이 접두사 뒤에 이어지는 형식이고, 두 번째는 계정 ID, 리전, 원본 버킷 이름, 날짜별 폴더로 나뉘는 형식입니다. 두 번째 형식에는 분석과 쿼리 속도를 높이려면 이 형식을 쓰라는 설명이 있습니다. 이 실습에서는 기본값을 썼고, 화면의 예제 날짜(2026-07-01)는 실제 로그 시각이 아닌 형식 견본입니다. 변경 사항 저장을 누릅니다.

4. 켜진 상태 확인하기

저장하면 버킷 화면으로 돌아갑니다. 속성 탭의 서버 액세스 로깅 칸에서 상태를 봅니다.

상태가 활성화됨으로 바뀌고 대상 버킷과 키 형식이 표시됩니다.

5. 대상 버킷에 자동으로 붙은 정책 읽기

cr-demo-logs-dst-1018 버킷의 권한 탭을 열고 아래로 내려 버킷 정책을 봅니다.

읽은 내용은 다음과 같습니다.

S3의 로그 전달 서비스가 이 버킷 안에 객체를 쓸 수 있게 허용하는 문장입니다. 실습 화면에서는 계정 조건만 보였고 원본 버킷을 특정하는 조건(aws:SourceArn)은 보이지 않았습니다. 또 Resource는 logs/ 접두사가 아니라 버킷 전체(/*)였습니다. AWS 문서가 안내하는 권장 정책은 원본 버킷 조건을 함께 쓰는 것으로 알려져 있으니, 운영 환경에서는 문서의 정책 예시와 비교해 보시기 바랍니다(이 실습에서 문서와 직접 대조한 것은 아닙니다). 7번 화면 위쪽 파란 상자는 이 버킷의 퍼블릭 액세스 차단 설정이 켜져 있어 퍼블릭 액세스가 차단된다고 안내합니다.

6. 정리: 버킷 두 개 삭제

로그를 남기는 쪽부터 지웁니다. 버킷 목록에서 cr-demo-logs-src-1018만 선택하고 삭제를 누르면 삭제 확인 화면이 열립니다.

확인 화면 제목의 버킷 이름이 지우려는 버킷과 같은지 확인한 뒤 이름을 입력하고 버킷 삭제를 누릅니다.

같은 방법으로 cr-demo-logs-dst-1018을 삭제합니다.

삭제 직후 목록의 버킷 수가 2개, 1개로 줄었습니다. 남은 1개는 이 실습 전부터 있던 다른 용도의 버킷이며 건드리지 않았습니다. 두 버킷 모두 안에 객체가 없어 바로 삭제되었습니다.

자주 막히는 곳

• 대상 버킷을 다른 리전에 만든 경우: 대상 칸 안내에 같은 리전의 버킷을 지정하라고 적혀 있습니다. 대상 버킷은 원본과 같은 리전에 만듭니다.
• 원본 버킷을 대상으로 지정하기: 같은 버킷을 쓰면 로그를 쓸 때마다 그 쓰기에 대한 로그가 추가로 생겨 저장 비용과 분석 부담이 늘어나므로 권장되지 않는 것으로 알려져 있습니다. 쓰더라도 별도 접두사를 지정하라고 안내합니다. 이 실습에서 시험하지는 않았으며 별도의 대상 버킷을 썼습니다.
• 로그가 바로 보이지 않는 경우: 이 실습에서는 로그 파일이 생기는지 확인하지 않았습니다. 서버 액세스 로그는 전달에 몇 시간 걸릴 수 있고 모든 요청이 기록된다고 보장되지 않는 것으로 알려져 있으니, 설정 직후 대상 버킷이 비어 있어도 설정 오류로 단정하지 않습니다.
• 삭제가 안 되는 경우: 대상 버킷에 로그 파일이 쌓인 뒤에는 버킷을 비운 다음 삭제해야 합니다. 삭제 전에 대상 버킷의 객체 탭이 비어 있는지 확인합니다. 이 실습에서는 비어 있었습니다.

이어서 해 볼 것

• 원본 버킷에 파일을 올리고 내려받은 뒤 대상 버킷에 로그 파일이 생기는지, 파일 안의 요청자와 요청 종류 필드가 무엇인지 읽기
• 대상 버킷에 수명 주기 규칙을 걸어 오래된 로그를 자동으로 지우기
• CloudTrail 데이터 이벤트로 같은 객체 접근을 기록하고 서버 액세스 로그와 무엇이 다른지 비교하기
• CloudTrail 이벤트 기록 글에서 PutBucketLogging 이벤트 찾아보기

확인한 범위와 확인하지 않은 것

• 확인한 것: 버킷 두 개 생성, 서버 액세스 로깅 켜기와 대상 지정, 켜진 상태 표시, 대상 버킷에 자동으로 붙은 정책, 두 버킷 삭제.
• 확인하지 않은 것: 로그 파일이 실제로 전달되는지와 그 내용, CloudTrail 데이터 이벤트 설정, 서버 액세스 로깅이 요청 성능이나 비용에 주는 영향. 화면 문구는 이 실습 시점의 한국어 콘솔 기준입니다.