AWS CloudWatch 과금

AWS ECS + CloudWatch, 배포 후 2일 뒤의 청구서

33.59$ㅋㅋㅋㅋㅋㅋ

이게 무슨 일인가...

log data가 44GB라니..

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/discodeit",
    "awslogs-region": "ap-northeast-2",
    "awslogs-stream-prefix": "ecs"
  }
}

 

위 설정은 태스크를 만들 때 default로 지정되는 값이다.

해당 내용을 검색하니

Task Definition 내 logDriver: awslogs를 사용할 경우, 해당 컨테이너의 로그가 Amazone CloudWatch logs로 전송된다.

awslogs는 CloudWatch logs로 수집할 수 있게 해주는 Docker 로그 드라이버다.
이를 사용하면 ECS 태스크에서 발생하는 표준 출력(stdout)과 표준 에러(stderr)가 지정한 CloudWatch 로그 그룹/스트림에 기록된다.

 

자 이게 무슨말이냐...

예를 들어 Spring Boot가 다음과 같은 로그를 남기면

2025-07-07 01:20:30 INFO ... started successfully  ← stdout
2025-07-07 01:20:31 ERROR ... DB connection failed ← stderr

위 로그가 그대로 CloudWatch에 올라가게 된다.

 

이것 자체로는 큰 문제가 되지 않는다.

그럼 이제 어떤 이유로 로그가 44GB까지 쌓이게 된건지 확인을 해야한다...

 

운영 중인 서비스는 채팅 기능을 제공한다.
메시지에는 텍스트뿐 아니라 이미지도 함께 포함될 수 있는데...

디버깅을 위해, 나는 메시지를 담고 있는 DTO 전체를 로그로 남겼다.

log.debug("chatDto: {}", messageDto);

근데 여기서 문제..

messageDto 안에 이미지 byte[]가 그대로 포함되어 있었던 것.

즉, 이미지 한 장을 base64로 인코딩한 것과 비슷한 수천~수만 자의 텍스트가 그대로 로그로 남았다.

 

프론트에서는 메세지 요청을 폴링방식을 통해 3~5초마다 GET 요청을 보낸다.

난 테스트를 위해 채팅방에 6~7시간 넘게 접속해 있었고, 그 결과 엄청난 요청과 로그를 남기게 된 것이다.

 

여기에 겹쳐서 운영환경의 application-prod.yaml을 보면

logging:
  level:
    root: DEBUG

로그 레벨이 DEBUG로 잘못 설정되어 있던 것이다.

이러니 로그 크기가 44GB까지 쌓일 수 밖에

 

우선 더이상 CloudWatch로 log를 보내지 않게 logConfiguration을 삭제하고, 로그 그룹도 삭제했다.

application-prod.yaml의 로그레벨을 info로 변경해주었고, 이미지 등 바이너리 데이터는 로그로 출력하지 않도록 처리했다.