조건
- 호출 로깅은 기본 비활성화다. 로깅을 켜지 않고 과거 프롬프트가 자동 보존됐다고 가정하지 않는다.
- 지원 대상은 동일 계정·리전의 S3/CloudWatch Logs이며, 문서가 설명하는 엔드포인트 범위를 확인해야 한다.
- 요청·응답·메타데이터가 포함될 수 있으므로 로그 자체가 민감 데이터 저장소가 된다.
- 본문상 100KB를 넘는 JSON 또는 바이너리의 경우 S3 별도 객체 처리가 설명되어 있다. CloudWatch 이벤트 하나만 보고 원자료 전체가 없다고 단정하지 않는다.
조사 흐름
오류나 비용을 조사할 때는 requestId, modelId, API 작업, 호출 시각, 호출 주체와 토큰(token) 수를 연결한다. 이렇게 하면 어느 요청에서 어떤 모델을 사용했고 비용이나 오류가 언제 발생했는지 추적할 수 있다. 로그의 schemaVersion 예시인 1.0은 로그 스키마 버전(log schema version)이지 문서 페이지 버전이 아니다. requestMetadata는 호출자가 제공하는 값이므로 서비스가 직접 측정한 정보와 구분한다.
로그를 활성화하기 전에 누가 읽을 수 있는지와 암호화(encryption), 보존 기간(retention period), 마스킹(masking), 삭제 절차를 정한다. 프롬프트와 응답을 담는 로그 자체가 민감한 데이터가 될 수 있기 때문이다. 로깅을 끄면 이후 수집을 중단하는 것이지 이미 저장된 객체까지 삭제하는 것은 아니다.
추가 확인: S3 쓰기 정책은 Amazon Bedrock 서비스 주체와 지정 로그 경로의 PutObject, SourceAccount/SourceArn 조건을 사용한다. SSE-KMS(AWS KMS 키를 사용하는 서버 측 암호화) 구성에는 별도 GenerateDataKey 권한이 필요하다. CloudWatch는 Bedrock의 AssumeRole 신뢰 정책과 CreateLogStream/PutLogEvents 역할 정책을 구분한다. 로그 전송 권한과 로그를 읽는 사람의 권한은 별도다. 지원되는 bedrock-runtime 호출과 bedrock-mantle 호출을 혼동하지 않는다.
적용 범위: 정책의 실제 적용과 로그 전달은 테스트해야 한다. 하위 정책 문서 전체와 계정별 권한을 검증한 자료는 아니다.