AWS CloudTrail
CloudTrail은 AWS API 호출과 계정 활동을 시간순으로 남기는 감사 로그 계층입니다. 누가 어느 경로로 어떤 작업을 실행했는지 재구성할 수 있게 기록을 보관합니다.
▶아키텍처 다이어그램
📊 데이터 흐름 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
권한이 바뀌었거나 리소스가 삭제됐는데 누가 언제 호출했는지 남지 않으면 사고 조사 자체가 막힙니다. 상태 모니터링과 별개로 무슨 행동이 있었는지 기록하지 않으면 규정 준수도 설명할 수 없습니다.
초기 운영에서는 보안 그룹 규칙을 누가 바꿨는지, IAM 정책을 언제 수정했는지 추적할 방법이 마땅치 않았습니다. 서버 접속 기록은 남아도 AWS 콘솔이나 API를 통한 변경은 기록되지 않아서, 장애 원인이 인프라 설정 변경인지 코드 문제인지 구분하기 어려웠습니다. 규제 감사에서 "지난 분기 동안 누가 어떤 권한을 변경했는지 보여달라"는 요청을 받으면, 수동으로 정리할 수밖에 없었고 빠진 기록이 있는지조차 확인할 수 없었습니다. 클라우드에서 변경 속도와 API 호출 빈도가 급격히 올라가면서, 모든 행위를 자동으로 기록하고 시간순으로 재구성할 수 있는 CloudTrail 같은 감사 계층이 필수가 됐습니다.
콘솔, CLI, SDK 어느 경로로 AWS API를 호출하든, 요청은 컨트롤 플레인을 통과합니다. CloudTrail은 바로 이 지점에서 모든 API 호출을 가로채 로그 이벤트로 만듭니다. 누가(호출자 identity), 언제(타임스탬프), 어디서(source IP), 무엇을(API 이름과 request parameter), 어떤 결과로(response element) 실행했는지가 하나의 이벤트에 담깁니다. 생성된 이벤트는 S3 버킷에 장기 보관되거나 CloudWatch Logs로 실시간 전달됩니다. 이 흐름 덕분에 리소스가 변경된 뒤라도 '누가 어떤 API를 통해 바꿨는지'를 시간순으로 재구성할 수 있습니다.
CloudTrail과 CloudWatch는 둘 다 운영 정보를 다루지만 초점이 다릅니다. CloudTrail은 누가 어떤 API를 호출했는지 남기는 감사 기록이고, CloudWatch는 현재 상태와 성능 지표를 보는 관측성입니다. 변경 행위 추적과 감사가 문제면 CloudTrail을 보고, 지연 시간·오류율·리소스 상태 반응이 문제면 CloudWatch를 보면 됩니다.
보안팀이 IAM 정책 변경이나 루트 계정 로그인을 실시간으로 감지하고 싶을 때 CloudTrail 이벤트를 EventBridge 규칙으로 연결합니다. 감사팀이 분기별로 "누가 어떤 리소스를 변경했는지" 증적을 제출해야 할 때 S3에 저장된 로그를 기간별로 조회합니다. 장애 직후 "이 보안 그룹 규칙을 누가 언제 열었는지" 추적할 때도 CloudTrail이 출발점입니다. 관리 이벤트는 기본으로 기록되지만, S3 객체 접근이나 Lambda 실행 같은 데이터 이벤트는 별도로 켜야 하며 호출 건수에 비례해 비용이 늘어납니다. 이벤트가 S3에 전달되기까지 최대 15분 지연이 있어서 실시간 차단 용도로는 맞지 않습니다.