최근 관리 이벤트를 계정·리전 단위로 확인할 때는 Event history에서 시작하고, 지속적인 보관이나 데이터 이벤트 수집이 필요하면 Trail의 범위·저장·조회 설계를 따로 검토하세요. “CloudTrail을 쓴다”는 한 문장만으로 모든 활동이 보관됐다고 판단할 수 없습니다.
원인: 현재 조회되는 기록과 지속 수집 설정을 혼동한다
Event history는 최근 90일의 리전별 관리 이벤트를 보여 주며 Trail이나 이벤트 데이터 스토어와 별개입니다. 기본 조회 화면에 나타난다는 사실과 조직 전체·장기 보관 요구를 만족한다는 판단은 다릅니다. 애플리케이션 오류 로그나 사용자 행동 분석도 이 범위와 구분해야 합니다.
| 확인할 요구 | 먼저 볼 곳 | 놓치기 쉬운 조건 |
| 최근 관리 작업 확인 | Event history | 계정·리전·기간·필터 |
| 지속적인 감사 기록 | Trail 설계 | 이벤트 선택·S3 보존·조회 |
| 객체 수준 활동 등 | 데이터 이벤트 범위 | 지원 서비스·선택기·요금 |
1. 조사 질문을 계정·리전·시각·작업으로 나눈다
예를 들어 “누가 설정을 바꿨는가”라면 대상 계정, 리전, 시간대와 예상 API 작업을 먼저 적습니다. Event history의 단일 속성 필터와 시간 범위로 찾을 수 있는 질문인지 확인하세요. 콘솔의 기본 읽기 전용 필터 때문에 기대한 이벤트가 보이지 않는지도 점검합니다. 빈 결과 하나로 실제 작업이 없었다고 단정하지 않습니다.
2. 보관 전에 필요한 이벤트 유형을 결정한다
기존 조사 화면의 이벤트 한 건을 보고 장기 수집 범위를 정하지 마세요. 운영 요구를 관리 이벤트·데이터 이벤트·대상 리소스로 나누고 Trail의 이벤트 선택 설정과 대조합니다. S3 버킷의 객체 작업처럼 리소스 수준의 활동은 별도 데이터 이벤트 요구가 될 수 있습니다. 모든 데이터 이벤트가 Event history에 자동으로 나타나는 것은 아닙니다.
3. 수집과 나중의 조회를 함께 시험한다
설정 검토서에는 수집 대상뿐 아니라 저장 위치, 보존 기간, 접근 가능한 담당 역할, 조회 방법을 적습니다. 승인된 시험 활동을 기록해 생성 시각과 대상 식별자를 남긴 뒤 지정된 경로에서 이벤트를 찾는 검증을 계획하세요. 이 문장의 시험은 권장 절차이며 이 글에서 AWS 계정에 실제 이벤트를 만든 것은 아닙니다.
비용·보안·보존 설정 시 주의
Event history 조회와 별도 Trail의 전달·저장·분석 비용을 한 항목으로 취급하지 마세요. 실제 요금은 수집 유형과 적용 지역·저장·조회 구성의 최신 공식 요금표에서 확인해야 합니다. 이 글은 금액이나 절감률을 계산하지 않습니다. 기존 Trail·버킷 정책·보존 설정을 바꾸기 전 승인 범위와 원래 값을 보존하고, 조사 대상 로그를 시험 삼아 삭제하지 마세요. 수집 성공과 무결성·접근 통제·보존 준수는 각각 검증할 항목입니다.
FAQ
CloudTrail이면 앱 로그도 모두 있나요? 이 글은 AWS 계정 활동의 감사 이벤트를 다룹니다. 애플리케이션의 요청 본문·오류 로그와 구별해야 합니다.
Trail을 만들면 과거 기록도 채워지나요? 새 수집 설정이 과거의 미수집 이벤트를 만들어 주는 것으로 가정하지 마세요.
데이터 이벤트는 기본 Event history에서 보나요? 관리 이벤트와 별도 유형이므로 필요한 수집 설정과 조회 경로를 확인해야 합니다.
공식 출처와 관련 글
자료 확인일: 2026년 10월 22일. 공식 문서 기반 설계 안내입니다. AWS 계정 배포·성능·요금 실측을 수행하지 않았습니다.
'소프트웨어개발' 카테고리의 다른 글
| CloudFront 캐시 정책과 오리진 요청 정책: 캐시 키와 추가 전달값 구분 (0) | 2026.10.23 |
|---|---|
| rsync 복사 경로가 한 단계 달라질 때: 소스 끝 슬래시와 dry-run 확인 (0) | 2026.10.22 |
| gitignore가 적용되지 않을 때: 추적 파일과 규칙 일치를 따로 확인 (0) | 2026.10.22 |
