AWS 계정 50개 로그를 0달러로 한곳에 모으는 법: 클라우드워치 로그 중앙화 리전 확장의 실무 계산법

수십 개 계정에 흩어진 시스템 기록: 클라우드워치 로그 중앙화가 공공과 신흥 리전까지 넓혀진 배경

대규모 인프라를 운영하는 기업 엔지니어링팀의 오랜 골칫거리는 로그 수집이다. 서비스 규모가 커지면 보안과 권한 분리를 위해 개발, 스테이징, 운영 계정을 쪼개고, 결제 시스템이나 인공지능 워크로드는 별도 계정으로 격리한다. 계정이 수십 개로 늘어나고 서비스 지역이 아시아, 유럽, 중동으로 다변화되는 순간, 보안팀과 운영팀은 매번 개별 계정에 로그인해 로그를 뒤적거려야 했다.

이 번거로움을 해결하려고 현장에서는 계정마다 아마존 키네시스 데이터 파이어호스(Kinesis Data Firehose)를 띄우거나 이벤트 브릿지(EventBridge), 람다(Lambda) 함수를 엮어 중앙 감사 계정으로 로그를 쏘아 올리는 별도 데이터 통로를 손수 짰다. 하지만 이 방식은 통로를 유지하는 것 자체가 일이었다. 람다 실행 시간 초과, 전송 버퍼 지연, 리전 간 데이터 전송 요금, 암호화 키 권한 꼬임 같은 부작용이 끊이지 않았다.

아마존웹서비스(AWS)가 클라우드워치 로그 중앙화(CloudWatch Log Centralization) 지원 리전을 미국 정부 전용 구역인 AWS 거브클라우드(GovCloud US-East, US-West)와 아시아 태평양, 유럽, 중동, 아프리카 등 13개 상용 리전으로 전격 확대했다. 추가된 지역에는 홍콩, 자카르타, 말레이시아, 멜버른, 하이데라바드 같은 아시아 핵심 거점과 밀라노, 스페인, 취리히, 텔아비브, 바레인, UAE, 캘거리 등이 포함됐다.

이번 조치로 공공 데이터를 다루는 엄격한 규제 조직부터 다국적 서비스를 운영하는 엔터프라이즈까지, 별도의 데이터 배관 공사 없이 클릭 몇 번으로 전사 로그를 단일 계정으로 통합할 수 있게 됐다.

첫 번째 복제본 0달러의 셈법: 커스텀 데이터 통로와 네이티브 중앙화 비용 비교

엔지니어가 이번 발표에서 가장 주목해야 할 대목은 요금 정책이다. AWS는 다중 계정과 다중 리전에서 단일 대상 계정(Destination Account)으로 로그를 복사할 때, 첫 번째 중앙 복제본(centralize one copy)에 대해 복제 요금을 일체 부과하지 않는다.

기존 방식으로 로그를 중앙으로 모으려면 소스 계정의 클라우드워치 로그 수집 비용(GB당 $0.50 수준) 외에도 람다 호출 비용, 키네시스 파이어호스 수집 비용(GB당 약 $0.029–$0.035), 그리고 리전 경계를 넘을 때 발생하는 데이터 아웃바운드 비용이 추가로 얹혔다. 하지만 이번 네이티브 기능을 쓰면 추가 복사본(두 번째 이상의 수집 대상 계정)을 만들 때만 GB당 $0.05가 발생하고, 주 모니터링 계정으로 한 번 모으는 작업은 무료다.

비교 항목	기존 자체 구축 파이프라인 (Lambda + Kinesis)	클라우드워치 로그 중앙화 (네이티브 기능)
로그 수집 파이프라인 비용	Kinesis 수집비(GB당 약 $0.03) + Lambda 실행비	첫 번째 복제본 완전 무료 ($0)
추가 계정 복제 단가	파이프라인 개수만큼 비례 증가	추가 복제본당 GB당 $0.05
설정 방식	계정마다 CloudFormation 배포 및 IAM 역할 수동 연결	AWS Organizations 연동으로 조직·OU 단위 일괄 적용
소스 정보(메타데이터)	람다 코드에서 계정 ID, 리전 태그를 직접 가공해 주입	강화된 시스템 필드(Enriched Fields)로 원본 자동 보존
장애 모니터링 포인트	람다 실행 실패, 키네시스 병목, IAM 권한 오류	AWS 내부 관리형 서비스로 자체 유지보수 제로
적용 범위	엔지니어가 스크립트를 심어둔 계정만 동작	새로 생성되는 AWS 계정도 규칙에 따라 자동 편입

실무 시뮬레이션 추정치로 계산해 보면 차이는 뚜렷하다. 글로벌 5개 리전에 걸쳐 30개 AWS 계정을 운영하고, 매월 총 1TB(1,000GB)의 시스템 로그가 발생하는 기업이 있다고 가정해 보자.

자체 파이프라인을 굴릴 경우 키네시스 데이터 처리 요금으로 매월 약 $30–$35가 나가고, 로그 파싱용 람다 호출과 메모리 점유 요금으로 약 $40–$80가 지출된다. 여기에 리전 간 데이터 전송 요금과 인프라 코드 관리 공수를 합치면 매달 최소 $150–$250의 숨은 운영비가 빠져나간다. 반면 클라우드워치 네이티브 로그 중앙화를 적용하면 첫 번째 집계 계정으로 모으는 추가 배관 요금은 0원이다. 소스 계정의 기본 로그 수집비만 유지한 채 중앙 집계용 파이프라인 유지비를 완전히 아낄 수 있다.

멀티 어카운트 아키텍처 실무에 미치는 3가지 직접적 변화

기업 현장에서 수십 개 계정의 인프라를 관리하는 플랫폼 엔지니어링팀과 보안 감사팀은 이번 리전 확장으로 세 가지 직접적인 운영 개선 효과를 얻는다.

운영 비용: 파이프라인 유지보수와 불필요한 데이터 통로 요금의 삭제

그동안 인프라 팀은 각 계정의 로그를 S3나 통합 로그 계정으로 보내기 위해 테라폼(Terraform)이나 AWS CDK로 복잡한 전송 리소스를 관리했다. 새 계정이 생길 때마다 테라폼 코드를 배포해야 했고, 권한 정책이 조금만 틀어져도 로그가 중간에서 유실됐다.

네이티브 중앙화는 AWS 조직 관리 도구(AWS Organizations)와 직결된다. 전사 조직 전체, 특정 조직 단위(OU), 혹은 선택한 계정에만 규칙을 걸어둘 수 있다. 새 개발 계정이 생성되더라도 조직 단위 규칙에 묶여 있다면 엔지니어가 손을 대지 않아도 로그가 중앙 계정으로 자동 유입된다. 인프라 코드를 수정하고 배포 상태를 점검하던 엔지니어의 반복 작업 시간이 사라진다.

장애 추적 시간 단축: 단일 화면에서 10초 만에 끝나는 전사 로그 질의

과거에는 여러 마이크로서비스가 얽힌 장애가 터졌을 때, A 계정의 API 게이트웨이 로그를 보고, B 계정의 컨테이너 로그를 확인한 뒤, C 계정의 데이터베이스 오류를 따로 대조해야 했다. 각 계정 콘솔을 브라우저 탭에 10개씩 띄워놓고 시간을 맞춰가며 타임스탬프를 비교하는 일은 장애 복구 시간(MTTR)을 기하급수적으로 늘렸다.

로그 중앙화가 완료되면 대상 계정의 클라우드워치 로그 인사이트(CloudWatch Logs Insights) 한 화면에서 전사 로그를 쿼리할 수 있다. AWS는 중앙으로 복사되는 로그에 계정 ID, 리소스 원본 리전 등 시스템 필드를 자동으로 덧붙여 준다(Enriched System Fields). 따라서 질의문 한 줄로 특정 트랜잭션 ID가 어느 계정의 어떤 리전 인프라에서 병목을 일으켰는지 수초 안에 잡아낼 수 있다.

보안 및 감사 안정성: 로그 변조 방지와 규제 준수 장벽 해소

보안 관점에서도 개별 계정에 로그를 남겨두는 방식은 위험하다. 특정 개발 계정의 관리자 권한이 탈취당했을 때, 공격자가 침투 흔적을 지우기 위해 클라우드워치 로그 그룹을 통째로 삭제하면 사후 포렌식이 불가능해진다.

중앙화를 활용하면 로그가 생성되는 즉시 보안팀만 접근할 수 있는 격리된 감사 계정으로 복제된다. 개별 계정의 개발자나 악의적인 공격자가 자기 계정의 로컬 로그를 지우더라도, 중앙 계정에 복제된 사본은 건드릴 수 없다. 특히 이번에 엄격한 규제가 적용되는 AWS 거브클라우드(GovCloud)까지 지원이 확장되면서, 미국 연방정부 수준의 보안 규정(FedRAMP 등)을 준수해야 하는 공공 및 방산 연계 엔터프라이즈도 커스텀 암호화 배관 없이 중앙 집중 감사를 마칠 수 있게 됐다.

외부 관제 도구와 네이티브 중앙화의 역할 분담

중앙 계정으로 로그를 모으는 기능이 강력해졌다고 해서, 서드파티 통합 관제 도구의 필요성이 완전히 사라지는 것은 아니다. 기업의 로그 관리 전략은 이제 ‘어떻게 모을 것인가’에서 ‘어디서 분석할 것인가’로 이동하고 있다.

실무 현장에서는 애플리케이션 심층 분석이나 글로벌 서비스 통합 APM을 위해 Datadog 같은 전문 엔지니어링 관제 플랫폼을 함께 활용한다. 이때 클라우드워치 로그 중앙화는 외부 도구의 에이전트를 수십 개 계정마다 개별 설치하고 관리하는 번거로움을 크게 덜어준다.

기존에는 50개 계정 각각에 관제 수집기를 심고 개별 아웃바운드 통신을 열어야 했다면, 이제는 클라우드워치로 전사 로그를 단일 보안 계정에 모은 뒤, 해당 중앙 계정에서만 외부 도구로 로그 파이프라인을 단일화할 수 있다. 네트워크 접점이 하나로 줄어들고 IAM 보안 정책 관리가 단순해진다.

다만 주의할 점도 있다. 중앙 계정에 전사 로그가 한꺼번에 쌓이면 데이터 보관(Retention) 설정에 따라 스토리지 비용이 급증할 수 있다. 분석이 끝난 로그는 30일이나 90일 후 S3 Glacier로 자동 전환하는 수명 주기 정책을 중앙 계정 차원에서 미리 세워두어야 한다.

기술 도입 판정: 당장 활성화해야 할 곳과 신중해야 할 곳

클라우드워치 로그 중앙화의 리전 확장은 멀티 어카운트 환경을 운영하는 조직에게 환영할 만한 소식이다. 그러나 인프라 환경과 트래픽 특성에 따라 적용 우선순위는 갈린다.

지금 즉시 도입해야 할 기업 (Fit 조건 3가지)

• AWS Organizations 기반으로 10개 이상의 계정을 운영 중인 기업: 계정마다 테라폼으로 로그 전송 배관을 심고 유지하느라 플랫폼 엔지니어링 리소스가 낭비되고 있다면, 즉시 조직 단위 규칙을 적용해 운영 포인트를 제거해야 한다.
• 다국적 리전에서 서비스를 배포한 글로벌 엔터프라이즈: 이번에 추가된 동남아시아, 유럽, 중동 리전 및 거브클라우드를 사용하는 기업은 분산된 리전 로그를 미국 동부나 단일 거점 계정으로 모아 보안 사고 대응 지연 시간을 획기적으로 줄일 수 있다.
• 감사 로그 변조 방지가 필수적인 규제 산업군 기업: 핀테크, 헬스케어, 공공 연계 사업자처럼 개별 프로젝트 계정과 감사 계정을 물리적으로 격리하고, 원본 증적을 훼손 없이 한곳에 보관해야 하는 조직에 최적이다.

도입을 보류하고 지켜봐야 할 기업 (Non-Fit 리스크 3가지)

• 단일 계정에서 모놀리식 구조로 운영 중인 서비스: 계정이 1–2개에 불과하고 리전도 단일 리전만 사용한다면 중앙화 규칙을 켤 실익이 없다. 기본 클라우드워치 로그 그룹 설정만으로 충분하다.
• 이미 타사 관제 도구로 계정별 직렬 전송 파이프라인을 완전히 자동화한 기업: 각 인스턴스나 컨테이너에서 외부 분석 도구로 로그를 직접 쏘고 있고 AWS 내부에는 로그를 거의 남기지 않는 아키텍처라면, 굳이 클라우드워치 복제 규칙을 얹어 이중 보관 비용을 만들 필요가 없다.
• 중앙 계정 외에 개발팀별로 3개 이상의 복제 계정을 요구하는 복잡한 환경: 첫 번째 복제는 무료이지만 두 번째 복제본부터는 GB당 $0.05가 누적된다. 로그 발생량이 테라바이트 단위를 넘어서는 환경에서 여러 부서 계정으로 다중 복제를 걸면 의도치 않은 클라우드워치 청구서 폭탄을 맞을 수 있다.