[re:Invent 2025] CloudWatch 신규 기능들을 활용한 AWS Observability 향상 가이드 (2) – CloudWatch Logs Centralization
안녕하세요. GS 네오텍 이주완 입니다.
본 블로그 시리즈에서는 CloudWatch 신규 기능들을 활용해서 간단하게 AWS Observability 를 향상 시키는 방법을 설명 드리고 있습니다.
두 번째 주제는 바로 CloudWatch Logs Centralization 입니다.
첫번째 주제는 아래를 참고하시면 됩니다 🙂
CloudWatch 신규 기능들을 활용한 AWS Observability 향상 가이드 (1) – CloudWatch XAO
들어가기에 앞서
이전 주제에서 다룬 CloudWatch XAO (Cross-Account Observability) 는 여러 AWS 계정의 지표, 로그, 기타 Telemetry 데이터를 하나의 계정에서 통합하여 볼 수 있게 해주었지만 ,
다른 리전의 데이터는 통합할 수 없다는 한계가 있었습니다.
하지만 로그 데이터의 경우, CloudWatch Logs Centralization 기능을 활용하면 타 계정뿐만 아니라 타 리전의 로그까지도 하나의 대상 계정에 중앙 집중화 할 수 있습니다.
이는 멀티 계정/멀티 리전 환경에서 운영 효율성을 극대화하는 핵심 기능입니다.
1. CloudWatch Logs Centralization 개요
CloudWatch Logs Centralization 기능은 여러 AWS 계정 및 AWS 리전의 로그 데이터를 하나의 대상 계정 (Destination Account) 으로 복사하여 중앙 집중식으로 관리할 수 있게 해줍니다.
주요 특징 및 장점
- AWS Organizations 통합
- AWS Organizations와 원활하게 통합되어, 조직 전체, 특정 OU(조직 단위), 또는 선택한 계정에 걸친 워크로드의 로그를 효율적으로 집계할 수 있습니다.
- 간편한 관리
- 별도의 복잡한 사용자 지정 솔루션(예: Lambda 기반의 커스텀 파이프라인)을 구축하고 관리할 필요가 없습니다.
- 데이터 리니지 유지
- 복사된 로그 이벤트에는 원본 소스 계정과 리전을 식별하는 새로운 시스템 필드($@aws.account$ 및 $@aws.region$)가 자동으로 추가되어 데이터의 출처(Source Context)를 명확하게 알 수 있습니다.
- 유연한 구성
- 중앙 집중화 규칙을 조직 범위에 맞춰 세밀하게 지정 가능합니다.
- 선택적 로그 그룹 복사, 대상 계정 내 동일한 이름의 로그 그룹 자동 병합 기능을 제공하여 관리를 간소화합니다.
- 선택적 백업 리전 설정을 지원합니다.
필수 조건
이 기능을 사용하기 위해서는 반드시 다음 조건들이 충족되어야 합니다.
- AWS Organization 설정 필요
- 소스 계정 및 대상 계정이 모두 해당 조직에 속해야 합니다.
- 신뢰할 수 있는 액세스 활성화
- Organization 관리 계정에서 대상 CloudWatch에 대해 신뢰할 수 있는 액세스 (Trusted Access) 를 활성화하여 로그 데이터에 대한 액세스를 제공해야 합니다.
2. CloudWatch Logs Centralization 구성하기
CloudWatch 콘솔을 통해 간단하게 중앙 집중화 규칙을 구성할 수 있습니다.
(1) 조직의 관리 계정에서 로그인 후 [CloudWatch] 의 [설정] 클릭 후 [조직] 탭에서 [신뢰할 수 있는 액세스 켜기] 를 클릭합니다.
(2) [중앙 집중화 규칙 관리] 탭에서 [규칙 구성] 을 클릭합니다.
(3) [소스 세부 정보 지정] 탭에서 규칙 이름, 소스 계정, 소스 리전을 선택합니다. (※ 소스 계정을 72 로 시작하는 계정으로 선택했습니다.)
(4) [대상 세부 정보 지정] 에서 대상 계정, 대상 리전, 백업 리전을 선택합니다. (※ 대상 계정을 15로 시작하는 계정으로 선택했습니다.)
(5) [원격 분석] 탭에서 로그 그룹, 암호화를 설정합니다.
※ 다음과 같이 로그 그룹 이름을 기반으로 로그 그룹 필터링을 하실 수도 있습니다.
추가적으로 로그 그룹을 전달 시, KMS 암호화를 어떻게 처리할지 설정하실 수도 있습니다.
- 옵션 1 (KMS 키 포함): 원본의 KMS 암호화 로그를 대상 계정의 지정된 KMS 키로 재 암호화하여 전송합니다.
- 옵션 2 (KMS 키 미포함): 원본의 KMS 암호화 로그를 대상 계정의 CloudWatch 기본 암호화 상태로 전송합니다.
- 옵션 3 (전송 X): KMS로 암호화된 로그 그룹은 전송 대상에서 제외하고 원본 계정에 남겨둡니다.
(6) 설정 내용 검토 후 [규칙 생성] 을 클릭합니다.
(7) 소스 계정 (72xx-xxxx-xxxx) 으로 로그인 후, 특정 로그를 확인합니다.
특정 로그 스트림이 적재되어있는 것을 확인하실 수 있습니다.
그럼 이 로그 스트림이 대상 계정 로그에 적재되어 있는지 확인해보겠습니다.
(8) 대상 계정 (15xx-xxxx-xxxx) 으로 로그인 후, 해당 로그를 확인합니다.
위 사진과 같이, 소스 계정에 있었던 로그 스트림이 정상적으로 적재되어 있는 것을 확인하실 수 있습니다.
한 가지 특이점은 로그 스트림 이름에 “소스 계정 정보” (Ex. 72xxxxxxxxxx-ap-northeast-2) 가 추가로 부착되어 있는 것을 확인할 수 있습니다.
마무리하며
과거에는 A 계정에서 B 계정으로 CloudWatch Logs를 전달하기 위해서는 Amazon Kinesis Data Streams 또는 필요에 따라서 Lambda를 사용하기도 했습니다.
해당 방법은 번거로울 뿐 아니라 추가 비용이 발생하곤 했습니다.
하지만, 이번에 설명 드린 CloudWatch Logs Centralization 을 사용하면,
하나의 모니터링 계정으로 여러 소스 계정의 로그를 리전 관계 없이 중앙 집중화할 수 있습니다.
별도의 비용이 발생하지도 않습니다.
해당 기능을 사용해서 다중 계정의 CloudTrail Logs나 VPC Flow Logs 등을 하나의 계정에서 관리하고, 필요 시 Athena를 통해서 쿼리 분석도 가능합니다.
다음 주제에서도 AWS CloudWatch의 유용한 신규 기능을 소개해 드리겠습니다
감사합니다.
최신 댓글