S3 레플리케이션 완료를 트리거로 Lambda로 파일 날짜 이름 바꾸기 자동화
AWS를 쓰다 보면 "파일은 잘 쌓이는데, 정리가 안 된다"는 문제가 슬금슬금 쌓입니다.
이 글에서는 S3 레플리케이션으로 복제된 파일을 EventBridge로 감지하고, Lambda로 자동 날짜 리네임 후 processed/ 디렉터리로 이동시키는 구조를 처음부터 끝까지 정리해보겠습니다.
초급~중급 AWS 사용자, 특히 "여러 AWS 서비스를 한 번에 엮어 보고 싶다"는 분들을 대상으로, 최소 권한 원칙까지 포함해서 실무에 바로 써먹을 수 있는 구성을 소개합니다.
S3 레플리케이션 + Lambda로 무엇을 자동화할까?
상황을 하나 떠올려보겠습니다.
업로드 전용 S3 버킷 하나, 실제로 서비스를 위한 S3 버킷 하나가 있습니다.
사용자는 filetransfer-dev-source-bucket에 파일만 던져 넣습니다.
이 파일은 S3 레플리케이션으로 자동으로 filetransfer-dev-destination-bucket에 복제됩니다.
여기까지는 S3가 알아서 해주지만, 문제는 그 다음입니다.
도착한 파일을 날짜별로 정리하거나, 처리된 파일과 미처리 파일을 구분하려면 결국 사람이 작업하거나, 주기적인 배치 스크립트를 돌려야 합니다.
이 글에서 다루는 구조는 바로 그 "그 다음"을 자동으로 처리해 줍니다.
Destination 버킷에 파일이 복제된 순간, EventBridge가 이를 감지하고 Lambda를 호출합니다.
Lambda는 도착 시각을 기준으로 파일 이름에 타임스탬프를 붙이고, processed/ 디렉터리로 이동시켜 정리된 형태로 쌓이도록 만듭니다.
결과적으로, 사용자는 그냥 Source 버킷에 올리기만 하면 되고, Destination 버킷에는 날짜가 포함된 파일명이 깔끔하게 정리된 상태로 보이게 됩니다.
전체 아키텍처: S3, EventBridge, Lambda 연결 구조
구성을 한 줄로 요약하면 이렇게 정리할 수 있습니다.
"S3 레플리케이션 완료 → EventBridge 이벤트 발생 → Lambda 실행 → 파일 날짜 리네임 + processed/ 이동"
조금 더 구체적으로 흐름을 따라가 보겠습니다.
먼저 사용자가 filetransfer-dev-source-bucket에 파일을 업로드합니다.
S3 레플리케이션 기능이 이 파일을 filetransfer-dev-destination-bucket으로 자동 복제합니다.
Destination 버킷은 Object Created 이벤트를 EventBridge로 전송하도록 설정되어 있습니다.
EventBridge 규칙 filetransfer-dev-s3-put-rule는 이 Object Created 이벤트를 감시하다가, 새로운 객체가 생기면 지정된 Lambda 함수 filetransfer-dev-rename-function을 호출합니다.
Lambda 함수는 이벤트에서 버킷 이름과 객체 키를 꺼내고, 도착 시간을 기반으로 YYYYMMDD-HHMMSS_원래파일명 형태로 새 이름을 만든 뒤, processed/ 디렉터리 아래로 복사한 뒤 원본 파일을 삭제합니다.
이 구조의 핵심은 "레플리케이션이 끝난 뒤"를 기준으로 트리거가 걸려 있다는 점입니다.
즉, Source 버킷 업로드 시점이 아니라 Destination 버킷에 실제 복제된 순간을 기준으로 정리 작업이 실행되므로, 데이터 정합성 면에서도 깔끔한 흐름이 됩니다.
S3 레플리케이션 설정과 최소 권한 IAM 설계
S3 레플리케이션을 구성할 때 가장 먼저 챙겨야 할 것은 버전 관리와 IAM 권한입니다.
레플리케이션은 버전 관리가 켜져 있어야 동작하기 때문에, Source와 Destination 두 버킷 모두에서 버전 관리를 활성화해야 합니다.
그다음은 레플리케이션용 IAM Role입니다.
신뢰 정책(Trust Policy)에는 s3.amazonaws.com을 주체로 설정하여, S3 서비스가 이 역할을 사용할 수 있도록 합니다.
권한 정책(Permissions Policy)에는 "필요한 권한만" 넣는 것이 중요합니다.
Source 버킷에서는 GetObject, Destination 버킷에는 ReplicateObject 정도만 허용하여, 다른 불필요한 S3 작업은 할 수 없도록 제한합니다.
이렇게 만들어진 역할이 filetransfer-dev-replication-role이고, S3 레플리케이션 설정에서 이 역할을 사용하도록 지정합니다.
정리하자면,
두 버킷 모두 버전 관리 활성화
S3 전용 신뢰 정책을 가진 레플리케이션 IAM Role 생성
Source는 읽기, Destination은 복제 관련 권한만 허용
이 세 가지만 정확히 잡으면, S3 레플리케이션의 기반은 탄탄하게 깔립니다.
EventBridge와 Lambda: 파일 도착을 실시간으로 감지하기
이제 "언제 Lambda를 실행할 것인가?"를 고민해 볼 차례입니다.
단순히 배치로 5분, 10분에 한 번씩 S3를 스캔하도록 만들 수도 있지만, 그건 비용도 비효율적이고, 무엇보다 우아하지 않습니다.
AWS에서는 S3 버킷에서 발생하는 Object Created 이벤트를 EventBridge로 보낼 수 있습니다.
Destination 버킷에서 이 기능을 활성화하면, 파일이 복제될 때마다 이벤트가 EventBridge로 날아가게 됩니다.
다음으로 EventBridge에서 규칙을 하나 만듭니다.
이 규칙은 Destination 버킷에서 발생하는 Object Created 이벤트를 조건으로 필터링하고, 매칭되면 지정된 Lambda 함수를 대상으로 이벤트를 전달합니다.
덕분에 Lambda 함수는 "파일이 실제로 도착했을 때만" 실행됩니다.
주기적으로 불필요하게 실행하지 않으니 비용도 절약되고, 아키텍처도 훨씬 간단해집니다.
Lambda로 S3 파일 날짜 리네임 구현하기 (Python 3.12)
이제 핵심인 Lambda 구현 부분입니다.
먼저 권한 설계부터 보겠습니다.
Lambda 실행 역할 filetransfer-dev-lambda-role에는 두 가지 축이 있습니다.
첫째, Destination 버킷에 대해 GetObject, PutObject, DeleteObject 권한을 부여합니다.
둘째, CloudWatch Logs의 로그 그룹 /aws/lambda/filetransfer-dev-rename-function에 로그를 쓸 수 있는 권한을 부여합니다.
이 정도면 운영 환경에서도 크게 문제 없을 정도로 최소 권한에 가깝고, 디버깅에 필요한 로그도 남길 수 있습니다.
코드는 Python 3.12로 작성되어 있으며, 핵심 로직은 다음과 같습니다.
EventBridge 이벤트에서 버킷 이름과 객체 키를 읽는다.
이미
processed/디렉터리 안에 있는 객체라면 즉시 리턴하여 무한 루프를 막는다.현재 시간을 `YYYYMMDD-HH
