클라우드 이그레스 비용을 보안 신호로 보는 법

클라우드 청구서에서 데이터 전송 비용이 급증하면 가장 먼저 예산 초과를 떠올리기 쉽다. 그러나 이그레스는 단순한 비용 항목이 아니다. 백업 대상 변경, CDN 캐시 미스, 리전 간 복제, 외부 분석 도구 추가, 잘못 열린 저장소, 침해된 자격 증명을 이용한 대량 다운로드가 모두 비슷한 비용 곡선을 만들 수 있다.

문제는 비용팀, 보안팀, 인프라팀이 서로 다른 화면을 본다는 데 있다. 비용팀은 서비스별 청구 금액을 보고, 보안팀은 계정과 경보를 보고, 인프라팀은 네트워크 바이트와 오류율을 본다. 이 세 화면을 같은 사건 시간축에 올려야 정상 성장과 위험한 데이터 이동을 구분할 수 있다.

이그레스를 볼 때 먼저 나눌 네 가지 축

이상 징후를 발견한 뒤 곧바로 차단하면 정상 배포나 고객 다운로드를 멈출 수 있다. 반대로 비용팀 검토만 기다리면 실제 유출 대응이 늦어진다. 첫 판단은 다음 네 가지 축으로 나누는 것이 안전하다.

축	확인할 질문	정상 설명의 예	위험 신호의 예
자산	어느 버킷·DB·서비스에서 나갔는가	공개 정적 파일, 승인된 백업	고객정보, 내부 로그, 원본 백업
주체	어떤 계정·워크로드가 보냈는가	소유자가 있는 서비스 계정	개인 계정, 퇴사자 계정, 새 액세스 키
경로	어디로, 어떤 네트워크 경로로 나갔는가	등록된 CDN·파트너 엔드포인트	미승인 ASN, 새 국가, 직접 인터넷 경로
시점	배포·캠페인·마이그레이션과 맞는가	변경 티켓과 시간대가 일치	변경 기록 없이 야간에 급증

한 축만으로 결론을 내리지 않는다. 예를 들어 해외 리전으로 트래픽이 늘었다는 사실만으로는 침해라고 할 수 없다. 신규 고객 지역 확장일 수 있기 때문이다. 하지만 민감 버킷, 개인 계정, 새벽 시간대, 업무와 무관한 목적지가 동시에 나타난다면 우선순위는 크게 올라간다.

평소 범위를 만드는 방법

정액 임계치만 두면 작은 서비스의 이상 전송을 놓치고, 큰 서비스에서는 매일 경보가 울린다. 기준선은 서비스·데이터 등급·요일·시간대별로 나눠야 한다. 최소한 다음 지표를 함께 보자.

• 시간당 외부 전송 바이트와 요청 수
• 상위 목적지 IP·도메인·리전의 변화
• 버킷 또는 데이터베이스별 반환 바이트
• 계정·역할·워크로드별 전송량
• CDN 캐시 적중률과 원본 요청량
• NAT 게이트웨이 또는 프록시를 통과한 바이트
• 전송량과 청구 금액의 변화율

알림은 절대 금액, 변화율, 맥락 조건을 조합해야 한다. 예를 들어 “시간당 100GB 초과” 같은 값은 조직마다 의미가 다르다. 대신 “같은 요일·시간대 기준선 대비 4배 이상이며, 민감 데이터 자산에서 발생하고, 변경 티켓이 없는 경우”처럼 맥락을 넣는다. 숫자는 예시일 뿐이며 실제 임계치는 최소 몇 주의 정상 데이터와 장애·캠페인 기록을 보고 조정해야 한다.

15분 안에 할 1차 분류

이그레스 급증 경보가 울리면 첫 15분의 목표는 원인 확정이 아니라 피해 가능성과 소유자를 빠르게 좁히는 것이다.

1. 비용 항목을 리소스까지 분해한다. 서비스명 수준에서 멈추지 말고 버킷, 네트워크 인터페이스, NAT, 리전, 계정 태그까지 내려간다.
2. 같은 시간대의 변경 기록을 찾는다. 배포, 데이터 마이그레이션, 백업 정책, CDN 설정, 분석 도구 추가가 있었는지 확인한다.
3. 흐름 로그와 접근 로그를 연결한다. 출발지 자산, 목적지, 전송 바이트, 사용자 또는 역할, 요청 API를 한 사건으로 묶는다.
4. 데이터 등급을 확인한다. 공개 콘텐츠인지, 내부 운영 데이터인지, 고객정보나 인증정보가 섞인 자산인지 구분한다.
5. 즉시 소유자를 호출한다. 소유자가 없거나 연락되지 않는 트래픽은 그 자체로 운영 위험이다.
6. 차단 전 증거를 보존한다. 관련 로그, 설정 스냅샷, 액세스 키 메타데이터, 배포 버전을 보존한 뒤 범위를 줄여 차단한다.

차단은 최소 범위로 시작한다. 전체 인터넷 출구를 닫기보다 의심 역할의 세션 폐기, 특정 버킷의 임시 정책 제한, 문제 워크로드 격리, 목적지별 차단처럼 되돌릴 수 있는 조치를 우선한다.

자주 발생하는 실패 모드

CDN 캐시 미스로 원본 이그레스가 폭증한다

캐시 키 변경, 헤더 설정, TTL 축소, 배포 후 대량 무효화가 원인일 수 있다. 이 경우 외부 다운로드는 정상이어도 원본 트래픽과 비용이 급증한다. 캐시 적중률, 원본 요청 수, 배포 시간을 함께 보면 보안 사건과 구분하기 쉽다.

백업이나 복제 대상이 잘못 바뀐다

새 리전 또는 외부 저장소로 복제하도록 설정했지만 승인 범위 밖일 수 있다. 정상 작업 이름이 붙어 있어도 데이터 주권, 계약, 암호화, 보존 정책을 위반할 수 있으므로 목적지와 데이터 등급을 반드시 확인한다.

장기 자격 증명이 대량 다운로드에 사용된다

평소 API 호출이 거의 없던 키가 객체 목록 조회 후 연속 다운로드를 수행하면 계정 오남용을 의심할 수 있다. 새 사용자 에이전트, 새 IP, 비정상 시간대, 실패 후 성공 패턴이 함께 나타나는지 본다.

관측 도구 자체가 비용과 위험을 만든다

로그, 트레이스, 패킷 캡처를 외부 SaaS로 보내는 설정이 바뀌면 이그레스가 커진다. 원문 로그에 토큰·개인정보가 섞여 있다면 비용 문제를 넘어 데이터 유출 경로가 된다. AI 도구 로그 설계 기준과 같은 최소 수집 원칙을 관측 파이프라인에도 적용해야 한다.

탐지 규칙은 여러 신호를 묶어야 한다

단일 비용 경보보다 다음과 같은 조합 규칙이 실무에서 유용하다.

조합	우선순위가 올라가는 이유
이그레스 증가 + 새 액세스 키	정상 작업보다 자격 증명 오남용 가능성이 커진다
이그레스 증가 + 객체 목록 조회 급증	대량 수집 또는 탐색 단계일 수 있다
민감 자산 + 미승인 국가·ASN	데이터 경계 위반 가능성이 있다
야간 전송 + 개인 계정 + 배포 없음	업무 맥락으로 설명하기 어렵다
캐시 적중률 하락 + 원본 트래픽 증가	CDN 설정 문제일 가능성이 높다
NAT 바이트 증가 + 새 목적지 도메인	워크로드 설정 변경이나 악성 통신을 확인해야 한다

SIEM에 넣을 때는 “이그레스 비용 증가”라는 이름보다 대응에 필요한 필드를 먼저 확보한다. 최소 필드는 event_time, cloud_account, resource_id, data_class, principal, destination, bytes_out, baseline_ratio, change_ticket, owner다.

탐지 규칙 우선순위는 경보 후 소유자가 실제로 확인하고 조치할 수 있는지를 기준으로 정하는 편이 좋다.

사고와 비용 최적화를 같은 티켓에서 다루기

원인이 보안 사건이 아니더라도 조치가 끝난 것은 아니다. 캐시 미스, 잘못된 리전 복제, 무제한 로그 전송은 다시 발생할 수 있다. 티켓에는 다음 항목을 남긴다.

• 원인과 최초 관측 시각
• 영향 자산과 데이터 등급
• 관련 계정·역할·키
• 전송 목적지와 예상·실제 바이트
• 즉시 차단 또는 완화 조치
• 재발 방지 설정과 담당자
• 예외가 있다면 만료일
• 다음 기준선 재학습 시점

비용 절감만 목표로 하면 압축과 캐시만 보게 된다. 보안 관점에서는 “왜 이 데이터가 이 주체에 의해 이 목적지로 나갔는가”가 핵심이다. 비용, 흐름 로그, 접근 로그, 변경 기록이 같은 티켓에 모일 때 이그레스는 회계 숫자가 아니라 데이터 경계의 관측 신호가 된다.

참고 기준

• NIST Cybersecurity Framework 2.0
• AWS VPC 모니터링과 VPC Flow Logs
• AWS CloudWatch Anomaly Detection
• Google Cloud Event Threat Detection과 VPC Flow Logs
• Azure Virtual Network Flow Logs

클라우드 이그레스 비용은 침해를 단독으로 증명하지 않는다. 다만 평소와 다른 데이터 이동을 가장 먼저 보여 주는 신호가 될 수 있다. 비용 변화에 자산, 주체, 경로, 변경 맥락을 붙이면 재무팀과 보안팀이 같은 사건을 더 빠르게 판단할 수 있다.