Cloud Is My Life
[26WKRD2] Amazon Athena로 AWS의 다양한 로그 분석하기 본문
개요
Amazon Athena는 Amazon S3에 저장된 다양한 AWS 로그를 별도의 서버 구성 없이 SQL로 바로 분석할 수 있는 대표적인 서버리스 서비스입니다. VPC Flow Logs, CloudTrail, Elastic Load Balancing 로그, CloudFront 로그처럼 여러 서비스에서 생성되는 로그를 한곳에 모아두면, 운영 상태 점검부터 보안 이벤트 추적, 비용과 성능 분석까지 폭넓게 활용할 수 있습니다.
이 글에서는 Amazon Athena를 활용하여 AWS의 다양한 로그를 분석하는 기본 흐름을 소개할 예정입니다. 로그를 S3에 저장하고, Athena에서 테이블을 생성한 뒤, SQL로 필요한 정보를 조회하는 과정을 중심으로 각 로그 유형별 활용 예시와 함께 실무에서 바로 적용할 수 있는 분석 포인트를 정리하겠습니다.
이번 실습에서는 CloudTrail, ALB, VPC Flow의 로그를 분석할 예정입니다.
이 실습에서 제공되는 파일, 사용해야 하는 파일 등은 모두 <이 레포>에 올려두었으니 참고바랍니다.
1. S3 Setup
먼저, Athena 쿼리 결과가 저장될 버킷을 생성합니다.
이후, Athena -> 쿼리 설정에서 아래와 같이 설정합니다.
암호화 등의 여부는 여러분들의 입맛에 맞게 적절히 설정합니다.
이후, 각각의 로그를 담을 S3 버킷도 생성하여 아래와 같이 총 4개의 버킷을 생성합니다.
이후, ALB Bucket의 권한을 아래와 같이 설정합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AWSLogDeliveryWrite",
"Effect": "Allow",
"Principal": {
"Service": "logdelivery.elasticloadbalancing.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::athena-logs-alb-101010/*"
}
]
}.
2. 각 Source 별 설정
이제, 각 Data Source 별로 로그를 S3 버킷에 저장하도록 설정해보겠습니다.
2-1. CloudTrail
먼저, CloudTrail로 이동하여 추적을 생성합니다.
추적 이름을 설정하고, 로그가 저장될 S3 버킷을 선택합니다. 필자의 경우 1번에서 생성한 버킷을 지정하였습니다.
이후, 버킷의 어떤 디렉토리에 로그가 저장될지 작성하고, 로그 파일 암호화 여부를 선택합니다.
이후, 적절히 추가적인 옵션들을 선택합니다.
이후, 어떤 활동을 기록할지 선택합니다. 이 부분은 여러분들이 자유롭게 선택하셔도 됩니다.
다음으로 관리 이벤트 값을 적절히 설정합니다
이제 각 이벤트 타입 별로 어떤 리소스를 어떻게 로깅할지 선택합니다.
이후, Event Aggregation 관련 설정을 할 수 있는데, 필자는 모두 선택하였습니다.
이제 생성합니다.
2-2. Application Load Balancer
ALB 파트 실습은 클론받은 레포의 _starter_infra/template.yaml를 CloudFormation을 통해 배포하는 것으로 시작합니다.
CloudFormation으로 접속하여 스택 생성을 시작합니다. 기존 템플릿 선택을 선택하고, 아래와 같이 template.yaml을 선택합니다.
이후 스택 이름을 지정하고 쭉 진행하여 생성합니다. 생성까지 시간이 걸릴 수 있음에 유의합니다.
조금 기다리면, 아래와 같이 스택이 잘 생성된 것을 알 수 있습니다.
이제, EC2 -> 로드 밸런서 -> athena-lab-alb -> 속성으로 이동한 뒤, 편집을 선택합니다.
잘 선택 후 저장합니다.
2-3. VPC Flow Logs
VPC Flow Logs 파트 실습은 클론받은 레포의 _starter_infra/template.yaml를 CloudFormation을 통해 배포하는 것으로 시작합니다. 만약 생성하지 않은 경우, 2-2의 CFN 스택 생성 방법을 참고하여 생성 후 진행합니다.
VPC -> athena-lab-vpc -> 플로우 로그로 이동하여 생성을 선택합니다.
이름을 설정하고, 필터, 최대 집계 간격을 설정합니다.
이후, 로그를 전송할 대상을 선택합니다.
다음으로 로그 레코드를 어떻게 쌓을지 결정합니다. 형식의 경우 커스텀이 가능합니다.
마지막으로 로그 파일 형식과 일부 옵션을 선택합니다. 필자는 기본값으로 설정하였으나, 여러분들 옵션에 맞게 적절히 설정하시기 바랍니다. 또한, 클론받은 레포의 sql/vpcflow/ddl 디렉토리에 관련 사항을 전부 대응해두었으니 참고 바랍니다.
이제 생성합니다.
3. Athena로 쿼리하기
이제, 각 옵션 별로 Athena에서 쿼리를 시도해보도록 하겠습니다.
그 전에 아래 SQL 쿼리를 통해 데이터베이스를 생성합니다. 데이터베이스 이름은 여러분들이 멋지게 지으시기 바랍니다.
create database if not exists aws_logs;3-1. CloudTrail
클론받은 레포의 sql/cloudtrail/ddl.sql을 참고하여 테이블을 생성합니다. 이 때, 버킷 이름과 계정 ID, 리전은 잘 수정하시기 바랍니다.
정상적으로 실행되었다면 아래 사진들과 같이 테이블이 잘 정의되고, 완료 처리되었을겁니다.
그 후, 테이블을 검증하기 위해 아래 쿼리를 실행하여 데이터가 실제로 잘 정의되는지 확인합니다.
select * from aws_logs.cloudtrail
where dt = '2026/04/04'
limit 5;
테이블이 제대로 생성된 것이 맞다면 아래와 같이 결과가 제대로 뜰 것입니다.
만약 테이블을 잘못 생성하여 다시 정의하고자 한다면 아래 쿼리로 드롭 후 다시 생성하시기 바랍니다.
drop table aws_logs.cloudtrail;
이제, 실제 쿼리를 통해 정보를 얻어보겠습니다.
먼저 특정 IP에서 발생한 모든 이벤트를 조회합니다.
다음으로, 콘솔 로그인 기록을 살펴봅시다.
정상적으로 조회가 잘 되는 모습을 알 수 있습니다.
3-2. Application Load Balancer
이제 ALB의 액세스 로그를 Athena로 분석해보겠습니다.
먼저 클론받은 레포의 sql/alb/ddl.sql을 실행하여 테이블을 정의합니다.
위와 같이 테이블이 잘 생성되었다면, 아래 쿼리를 통해 테이블을 검증합니다.
select * from aws_logs.alb
where dt = '2026/04/04'
limit 5;
만일 위 쿼리를 실행했을 때, 아래처럼 값이 출력되지 않는다면 테이블 생성이 잘못된 것이므로 테이블을 Drop 한 뒤, 다시 생성합니다.
이제, 실제로 데이터를 조회해보겠습니다.
먼저, 2026년 4월 4일에 발생한 4xx 에러를 조회해보겠습니다.
매우 잘 뜨는 것을 알 수 있습니다.
다음으로, status code 별 요청 수를 집계해보겠습니다.
이번에도 잘 집계된 것을 알 수 있습니다.
마지막으로 user-agent 별 요청 수를 확인해보겠습니다.
이번에도 역시 잘 조회된 것을 알 수 있습니다.
3-3. VPC Flow Logs
먼저, VPC Flow 로그 분석을 위한 테이블을 정의하도록 하겠습니다.
이 부분의 경우 2-3번에서 VPC Flow 로그 생성 옵션에 따라 테이블 구성 방법이 달라지므로 클론받은 레포의 sql/vpcflow/ddl/ 디렉토리를 참고하시기 바랍니다.
필자의 경우 Text type + Non-hive + Daily로 옵션을 선택했기에, 아래와 같은 쿼리를 통해 테이블을 생성 후 검증하였습니다.
이후, 테이블이 정상적으로 생성되었는지 검증하는 쿼리를 실행합니다.
select * from aws_logs.vpc_flow
where dt = '2026/04/05'
limit 5;
테이블이 잘 생성되었습니다.
이제 실제 쿼리를 통해 데이터를 조회해보겠습니다.
먼저, 외부에서의 SSH / RDS Port 접근 시도를 조회해보겠습니다.
매우 잘 조회되는 모습을 확인할 수 있습니다.
이제 ENI 별 Traffic Top 10을 뽑아보겠습니다.
이번에도 매우 잘 조회되는 모습을 확인할 수 있습니다.
마지막으로 Source 별 Reject 횟수를 조회하여 의심되는 ip를 확인해보겠습니다.
결과 도출 성공.
마치며
이 글에서는 Amazon Athena를 활용해 CloudTrail, ALB, VPC Flow Logs를 S3에 수집하고, 이를 SQL로 직접 조회하는 기본적인 분석 흐름을 살펴보았습니다. 별도의 로그 분석 서버를 따로 구축하지 않아도, Athena만으로 운영 이벤트 확인, 접근 패턴 분석, 보안 이상 징후 탐지까지 폭넓게 수행할 수 있다는 점이 큰 장점입니다. 특히 로그를 S3에 체계적으로 적재하고, 용도에 맞는 테이블만 잘 정의해두면 실무에서도 빠르게 필요한 인사이트를 얻을 수 있습니다.
실습에서는 비교적 기본적인 조회 위주로 다루었지만, 이후에는 기간별 집계, 이상 패턴 탐지, 다중 로그 상관분석처럼 더 확장된 방식으로 활용할 수 있습니다. 이번 글이 AWS 환경에서 로그를 보다 능동적으로 분석하고 싶은 분들께 좋은 출발점이 되었기를 바랍니다.
참고 문서
[1] Amazon Athena로 ALB 쿼리하는 예시 - https://github.com/ninejuan/2025-day3/blob/main/docs/Athena.md
이거 다른 계정으로 옮겨두기