Aurora MySQL에서 감사 로그를 수집하고 확인하는 방법
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
Aurora MySQL에서 감사 로그를 수집하려면 DB 클러스터 파라미터 그룹에서 `server_audit_logging`을 1로 설정하고, `server_audit_events`에 기록할 이벤트 종류(CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML, TABLE)를 지정합니다. 대상은 `server_audit_incl_users` / `server_audit_excl_users`로 좁힐 수 있습니다. 출력 대상은 RDS 로그 파일과 CloudWatch Logs입니다. 모두 클러스터 단위 설정입니다.
この文書の適用条件
| 対象製品 | Aurora MySQL(MySQL 호환 에디션) Advanced Auditing |
|---|---|
| 確認バージョン | Aurora MySQL 2.x(MySQL 5.7 호환) / 3.x(MySQL 8.0 호환). 사용 가능한 이벤트 종류의 세부 사항은 버전에 따라 다르므로 실제 환경에서 확인 필요 |
| 適用環境 | Amazon Aurora(AWS). Amazon RDS for MySQL에는 동일한 이름의 기능이 없음 |
| 必要権限 | 파라미터 변경은 IAM의 `rds:ModifyDBClusterParameterGroup`, 로그 수집은 `rds:DescribeDBLogFiles` / `rds:DownloadDBLogFilePortion`. CloudWatch Logs 출력 활성화에는 `rds:ModifyDBCluster` |
| 実行影響 | 조회계는 영향 없음. 감사 활성화는 기록량 증가와 쓰기 처리에 대한 추가 부하를 수반함 |
| 再起動 | 파라미터마다 다르므로 `ApplyType` 확인 필요. `immediate`로 적용되지 않는 항목은 재시작 필요 |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- Aurora MySQL 2.x / 3.x
- 権限
- 접속 권한(전역 변수 조회)
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: 接続権限(グローバル変数の参照のみ)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
'server_audit_logging',
'server_audit_events',
'server_audit_incl_users',
'server_audit_excl_users'
);이 변수들이 표시되지 않으면 해당 클러스터에서는 Advanced Auditing이 구성되어 있지 않습니다. 파라미터 그룹 쪽 설정을 확인하십시오. `server_audit_logging`이 0이면 감사가 기록되지 않습니다.
- 対象
- Aurora MySQL(DB 클러스터 파라미터 그룹)
- 権限
- IAM: `rds:DescribeDBClusterParameters`
- 変更作業
- 없음(조회만)
- Production実行
- 가능
# 対象: Aurora MySQL(DBクラスターパラメータグループ)
# 権限: IAM rds:DescribeDBClusterParameters
# 変更作業: なし(参照のみ)
# Production 実行: 可能
aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
--query "Parameters[?starts_with(ParameterName, 'server_audit')].{Name:ParameterName,Value:ParameterValue,Apply:ApplyType,Source:Source}" \
--output table`Apply` 열(`ApplyType`)이 `dynamic`이면 재시작 없이 적용되고, `static`이면 재시작이 필요합니다. `Source`가 `engine-default`인 경우 그 파라미터는 명시적으로 설정되지 않은 것입니다.
- 対象
- Aurora MySQL(DB 클러스터 파라미터 그룹)
- 権限
- IAM: `rds:ModifyDBClusterParameterGroup`
- 変更作業
- 있음(클러스터 전체의 감사 설정 변경)
- Production実行
- 변경 관리 절차를 거친 후 실시. 기록량 증가를 감안할 것
# 対象: Aurora MySQL(DBクラスターパラメータグループ)
# 権限: IAM rds:ModifyDBClusterParameterGroup
# 変更作業: あり(クラスター全体に効く監査設定の変更)
# Production 実行: 変更管理を通したうえで実施。記録量の増加を必ず見込むこと
# 値にカンマを含むため、shorthand ではなく JSON 形式で指定する
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
--parameters '[
{"ParameterName":"server_audit_logging","ParameterValue":"1","ApplyMethod":"immediate"},
{"ParameterName":"server_audit_events","ParameterValue":"CONNECT,QUERY_DDL,QUERY_DCL","ApplyMethod":"immediate"},
{"ParameterName":"server_audit_excl_users","ParameterValue":"rdsadmin","ApplyMethod":"immediate"}
]'`server_audit_events`에 지정할 수 있는 주요 값은 CONNECT / QUERY / QUERY_DCL / QUERY_DDL / QUERY_DML / TABLE입니다. 먼저 CONNECT와 QUERY_DDL, QUERY_DCL부터 시작하고 필요해지면 QUERY나 QUERY_DML을 추가하는 것이 안전합니다. `QUERY`는 모든 SQL을 기록하므로 기록량이 급증합니다. `ApplyMethod`는 앞서 확인한 `ApplyType`에 맞추십시오.
- 対象
- Aurora MySQL(DB 클러스터)
- 権限
- IAM: `rds:ModifyDBCluster`
- 変更作業
- 있음(로그 출력 대상 추가)
- Production実行
- 가능. CloudWatch Logs의 수집량에 따른 비용이 발생함
# 対象: Aurora MySQL(DBクラスター)
# 権限: IAM rds:ModifyDBCluster
# 変更作業: あり(ログ出力先の追加)
# Production 実行: 可能。ただしCloudWatch Logsの取り込み量に応じた料金が発生する
aws rds modify-db-cluster \
--db-cluster-identifier example-aurora-cluster \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}' \
--apply-immediately
# 現在の出力設定を確認する
aws rds describe-db-clusters \
--db-cluster-identifier example-aurora-cluster \
--query 'DBClusters[0].EnabledCloudwatchLogsExports' \
--output textCloudWatch Logs로 출력하면 보존 기간 설정, Logs Insights를 이용한 검색, 메트릭 필터를 통한 알림을 사용할 수 있습니다. 수집량과 스토리지에 따른 비용이 발생하므로 감사 대상을 좁힌 뒤 활성화하십시오.
- 対象
- Aurora MySQL 인스턴스
- 権限
- IAM: `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
- 変更作業
- 없음(조회만)
- Production実行
- 가능
# 対象: Aurora MySQL インスタンス
# 権限: IAM rds:DescribeDBLogFiles, rds:DownloadDBLogFilePortion
# 変更作業: なし(参照のみ)
# Production 実行: 可能
# 1) 監査ログのファイル一覧を取得する
aws rds describe-db-log-files \
--db-instance-identifier example-aurora-instance \
--filename-contains audit \
--query 'DescribeDBLogFiles[].{Name:LogFileName,Size:Size,LastWritten:LastWritten}' \
--output table
# 2) 1) で得たファイル名を指定して内容を取得する
aws rds download-db-log-file-portion \
--db-instance-identifier example-aurora-instance \
--log-file-name "audit/audit.log.0.0" \
--starting-token 0 \
--output text로그 파일명은 환경과 시각에 따라 달라지므로 반드시 1)의 목록에서 얻은 값을 사용하십시오. 감사 로그는 인스턴스 단위로 출력되므로 라이터와 리더 양쪽을 모두 확인해야 합니다.
- 対象
- CloudWatch Logs(Aurora MySQL의 audit 로그 그룹)
- 権限
- IAM: `logs:StartQuery`, `logs:GetQueryResults`
- 変更作業
- 없음(조회만)
- Production実行
- 가능
# 対象: CloudWatch Logs(Aurora MySQL の audit ロググループ)
# 権限: IAM logs:StartQuery, logs:GetQueryResults
# 変更作業: なし(参照のみ)
# Production 実行: 可能
# 監査ログはカンマ区切りのレコードとして出力されるため、まず生の行を数件確認し、
# 実際のフィールド順を目視で確認してから parse のパターンを決める
fields @timestamp, @message
| sort @timestamp desc
| limit 20
# 特定ユーザーの操作だけを抽出する例(フィールド順を確認したうえで使う)
fields @timestamp, @message
| filter @message like /sample_user/
| sort @timestamp desc
| limit 100감사 로그의 레코드는 타임스탬프·접속 출처·사용자·연결 ID·작업 종류·대상 객체 등을 쉼표로 구분해 나열한 형식입니다. 필드 순서는 버전에 따라 차이가 있을 수 있으므로, `parse`로 기계적으로 분해하기 전에 반드시 실제 데이터를 몇 줄 확인하십시오.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| server_audit_logging | 감사 로그 활성화 여부 | 1이 아니면 아무것도 기록되지 않음 |
| server_audit_events | 기록할 이벤트 종류(쉼표 구분) | CONNECT / QUERY / QUERY_DCL / QUERY_DDL / QUERY_DML / TABLE 중 무엇이 포함되어 있는지. `QUERY`가 있으면 기록량이 큼 |
| server_audit_incl_users | 기록 대상에 포함할 사용자 | 지정된 경우 여기에 없는 사용자의 작업은 기록되지 않음 |
| server_audit_excl_users | 기록 대상에서 제외할 사용자 | 모니터링용 계정이나 `rdsadmin`을 제외하면 기록량을 줄일 수 있음 |
| ApplyType(파라미터 쪽) | 파라미터 적용 방식 | `static`이면 재시작 필요. `dynamic`이면 즉시 적용 가능 |
| LogFileName | RDS 로그 파일명 | 다운로드 시 이 값을 그대로 지정 |
| Size / LastWritten | 파일 크기와 마지막 기록 시각 | 크기 증가 방식이 기록량의 실측값이 됨. 설정 변경 전후로 비교 |
こういう状況で使います
- "누가 언제 이 테이블을 변경했는지"를 나중에 확인할 수 없음
- 감사 요건이 요구되었지만 현재 어디까지 기록되고 있는지 알 수 없음
- 감사 로그를 활성화한 것 같은데 로그 파일이 늘지 않음
- 감사 로그를 활성화했더니 로그량이 예상을 크게 초과함
- 슬로우 쿼리 로그는 있지만 성공한 작업의 기록이 남아 있지 않음
考えられる原因(可能性の高い順)
01
`server_audit_logging`이 활성화되지 않음
이벤트 종류만 설정해도 `server_audit_logging`이 0인 채로는 기록되지 않습니다. 먼저 이 값을 확인합니다.
02
인스턴스 단위 파라미터 그룹을 편집하고 있음
Advanced Auditing 설정은 DB 클러스터 파라미터 그룹 쪽에 있습니다. 인스턴스 단위 DB 파라미터 그룹을 편집해도 적용되지 않습니다.
03
`server_audit_incl_users` 지정으로 대상이 너무 좁아짐
포함할 사용자를 지정하면 그 외 사용자의 작업은 기록되지 않습니다. 의도치 않게 대상에서 제외되지 않았는지 확인하십시오.
04
파라미터가 `static`이고 재시작되지 않음
`ApplyType`이 `static`인 항목은 재시작까지 적용되지 않습니다. 파라미터 그룹의 값과 실제 가동 중인 값이 달라져 있을 수 있습니다.
05
`server_audit_events`에 `QUERY`를 넣어 기록량이 급증함
`QUERY`는 모든 SQL을 대상으로 합니다. 트래픽이 많은 인스턴스에서는 기록량이 커져 로그 보관 비용과 쓰기 부하 양쪽에 영향을 줍니다.
確認手順
- 1
가동 중인 값과 파라미터 그룹의 값을 모두 확인하기
参照のみSQL로 전역 변수를 확인하고 CLI로 파라미터 그룹 쪽 값과 `ApplyType`을 확인합니다. 둘이 일치하지 않으면 미적용 상태입니다.
- 2
로그 파일 생성 상황 확인하기
参照のみ`describe-db-log-files`로 감사 로그 파일 목록과 크기, 마지막 기록 시각을 확인합니다.
- 3
실제 레코드를 몇 줄 가져와 형식 확인하기
参照のみ`download-db-log-file-portion` 또는 CloudWatch Logs로 원본 행을 확인해 필요한 정보가 포함되어 있는지 봅니다.
- 4
기록량 증가를 실측하기
参照のみ설정 변경 전후로 로그 파일 크기의 증가를 비교합니다. 사전 추정치가 아니라 실측하십시오.
- 5
성능 영향을 검증 환경에서 측정하기
中운영과 동등한 부하를 건 상태에서 감사 여부에 따른 차이를 측정합니다. 영향의 크기는 워크로드에 따라 다릅니다.
対応方法
すぐに実施できる低リスクの対応
기록 목적을 먼저 정하기
参照のみ"부정 접근 탐지", "변경 작업 추적", "접속 출처 파악" 중 무엇인지에 따라 필요한 이벤트 종류가 달라집니다. 목적을 정하지 않고 전부 활성화하면 기록량만 늘어납니다.
CONNECT와 DDL / DCL부터 시작하기
高연결과 권한 변경, 스키마 변경만으로도 기록량을 줄이면서 감사 요건의 핵심 부분을 충족하는 경우가 많습니다.
事前検討が必要な変更
제외 사용자 설정하기
高모니터링용 조회 전용 계정이나 관리용 계정을 `server_audit_excl_users`에 넣어 노이즈를 줄입니다. 제외된 내용은 기록되지 않으므로 제외 정책을 문서화하십시오.
CloudWatch Logs로 출력하고 보존 기간 설정하기
高로그 그룹의 보존 기간을 감사 요건에 맞춰 설정합니다. 장기 보관이 필요하다면 S3로의 내보내기도 검토하십시오.
탐지 규칙 정하기
中권한 부여, 테이블 삭제, 예상치 못한 호스트로부터의 접속 등 알려야 할 이벤트를 메트릭 필터로 정의합니다.
再起動・サービス影響を伴う変更
`QUERY`를 포함해 모든 SQL 기록하기
高추적 가능성은 최대가 되지만 기록량과 쓰기 처리에 대한 영향이 커집니다. 반드시 검증 환경에서 부하와 기록량을 측정한 뒤 판단하십시오.
`static` 파라미터 적용을 위해 인스턴스 재시작하기
高재시작은 연결 끊김을 수반합니다. 계획된 정지로 처리하십시오.
!注意事項
- `server_audit_events`에 `QUERY`를 포함하면 실행된 모든 SQL이 기록 대상이 됩니다. 트래픽이 많은 인스턴스에서는 기록량이 크게 늘어납니다. 증가량과 성능 영향은 환경에 따라 다르므로 본 문서에서는 구체적인 비율을 제시하지 않습니다. 반드시 검증 환경에서 측정하십시오.
- 감사 로그에는 SQL 문이 포함되므로 리터럴로 작성된 개인정보나 민감한 값이 로그에 남습니다. 로그 보관 위치와 접근 권한을 먼저 결정하십시오.
- 제외 사용자를 설정하면 그 사용자의 작업은 전혀 기록되지 않습니다. 제외는 감사의 사각지대가 되므로 이유를 문서화하십시오.
- Advanced Auditing의 설정은 DB 클러스터 파라미터 그룹 쪽입니다. 인스턴스 단위 파라미터 그룹을 편집해도 활성화되지 않습니다.
- CloudWatch Logs로의 출력은 수집량과 스토리지에 따른 비용이 발생합니다. 감사 대상을 좁히기 전에 활성화하면 비용이 예상을 초과할 수 있습니다.
- 감사 로그는 "누가 무엇을 했는지"의 기록입니다. "왜 느린지"는 알 수 없습니다. 성능 조사에는 슬로우 쿼리 로그와 Performance Insights를 사용하십시오.
バージョン・環境による違い
これで解決しない場合に確認すること
리더 인스턴스의 감사 로그도 수집하고 있는지 확인하기
로그는 인스턴스 단위로 출력됩니다. 조회계를 리더로 보내고 있다면 리더 쪽 로그도 필요합니다.
감사 로그의 보관 기간이 요건을 충족하는지 확인하기
RDS의 로그 파일은 자동으로 순환(rotation)됩니다. 장기 보관이 필요하다면 CloudWatch Logs나 S3로 옮기는 설계가 필요합니다.
애플리케이션이 공유 계정으로 접속하고 있지 않은지 확인하기
모든 사용자가 같은 DB 사용자로 접속하고 있다면 감사 로그를 수집해도 "누구"를 특정할 수 없습니다.
일반 로그(general log)와의 구분 사용법 정리하기
일반 로그는 모든 연결과 SQL을 기록하지만 감사 목적의 필터링이나 제외 설정은 할 수 없습니다. 용도가 다릅니다.
로그 접근 권한 확인하기
감사 로그를 열람할 수 있는 사람이 너무 많으면 그 자체가 정보 유출 경로가 됩니다.
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
Amazon Aurora MySQL의 Advanced Auditing 관련 클러스터 파라미터(`server_audit_logging`, `server_audit_events`, `server_audit_incl_users`, `server_audit_excl_users`), CloudWatch Logs로의 로그 출력 설정, 그리고 `describe-db-log-files` / `download-db-log-file-portion`의 공개 사양에 기반합니다. 감사 활성화로 인한 성능 영향이나 기록량 증가율은 환경에 따라 다르므로 수치를 기재하지 않았습니다.
よくある質問
감사 로그는 어디에서 설정합니까?
DB 클러스터 파라미터 그룹입니다. `server_audit_logging`, `server_audit_events`, `server_audit_incl_users`, `server_audit_excl_users`를 설정합니다. 인스턴스 단위 DB 파라미터 그룹에는 없으므로 그쪽에서 찾아도 보이지 않습니다.
Production에서 실행할 수 있습니까?
설정값 확인과 로그 수집은 조회만 하므로 운영 환경에서도 실행할 수 있습니다. 감사 활성화는 클러스터 전체의 설정 변경이며 기록량 증가와 쓰기 처리에 대한 영향을 수반하므로, 대상을 좁힌 뒤 변경 관리 절차를 거쳐 실시하십시오.
감사 로그를 활성화하면 성능이 얼마나 떨어집니까?
일률적인 수치는 제시할 수 없습니다. 기록하는 이벤트 종류, SQL 실행 빈도, 인스턴스 클래스에 따라 영향이 달라지기 때문입니다. 검증 환경에서 운영과 동등한 부하를 걸어 감사 유무에 따른 측정값을 판단 근거로 삼으십시오.
슬로우 쿼리 로그와는 무엇이 다릅니까?
목적이 다릅니다. 슬로우 쿼리 로그는 "어떤 SQL이 느렸는지"를 기록해 성능 조사에 사용합니다. 감사 로그는 "누가 언제 무엇을 했는지"를 기록해 추적과 설명 책임을 위해 사용합니다. 빠른 SQL도 감사 대상이 될 수 있고, 느린 SQL도 감사 대상이 아닐 수 있습니다.
어떤 권한이 필요합니까?
설정값 조회는 접속 권한으로 충분합니다. 파라미터 변경에는 IAM의 `rds:ModifyDBClusterParameterGroup`, CloudWatch Logs 출력 설정에는 `rds:ModifyDBCluster`, 로그 수집에는 `rds:DescribeDBLogFiles`와 `rds:DownloadDBLogFilePortion`이 필요합니다.
기록량을 줄이려면 어떻게 해야 합니까?
`server_audit_events`에서 `QUERY`와 `QUERY_DML`을 제외하고 CONNECT·QUERY_DDL·QUERY_DCL로 좁히는 것이 기본입니다. 추가로 모니터링용 계정을 `server_audit_excl_users`로 제외합니다. 단, 제외된 작업은 기록되지 않으므로 감사 요건과 비교해 결정하십시오.
この文書がカバーする質問
- Aurora MySQL에서 누가 테이블을 삭제했는지 조사하고 싶다
- RDS의 감사 로그를 CloudWatch Logs로 내보내고 싶다
- 감사 로그와 일반 로그·슬로우 쿼리 로그의 차이를 알고 싶다
- 감사 로그의 기록량을 줄이는 설정을 알고 싶다
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
감사 로그는 "수집을 시작하는 것"보다 "계속 수집하면서 필요할 때 읽을 수 있게 유지하는 것"이 더 어려운 체계입니다. GIIP에서는 감사 설정이 의도한 상태에서 벗어나지 않았는지 정기적으로 대조하고, 로그량의 추이와 로그 그룹의 보존 기간을 함께 관리하고 있습니다. 권한 부여나 테이블 삭제 같은 탐지 대상 이벤트는 알림 대상으로 하고, 알림 후의 1차 확인은 AI 에이전트가 수행한 뒤 대응 필요 여부의 판단은 사람이 맡는 방식으로 하고 있습니다.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
Aurora MySQL에서 특정 쿼리가 느려졌을 때 확인하는 절차
슬로우 쿼리 로그, PROCESSLIST, EXPLAIN, 다이제스트 집계 순으로 위험도가 낮은 확인부터 시작해 느린 쿼리를 찾아내는 절차입니다. performance_schema가 비활성화된 환경의 대안도 제시합니다.
aurora-mysqlAurora MySQL에서 binlog 보존 시간을 확인·설정하는 방법
binlog 보존 시간은 `mysql.rds_show_configuration`으로 확인하고 `mysql.rds_set_configuration`에 시간 단위로 설정합니다. binlog_format은 클러스터 파라미터이며 변경에는 재시작이 필요합니다.
monitoring서버와 데이터베이스를 24시간 모니터링할 때 설정할 항목
24시간 모니터링을 설계할 때의 모니터링 대상·임계값 사고방식·에스컬레이션 체계·외부 모니터링의 필요성을 계층별로 정리한 체크리스트입니다.
incident-responseAI 에이전트가 데이터베이스 장애에 대응할 수 있는 범위와, 사람이 판단해야 하는 범위
장애 대응을 단계별로 나누어 AI가 담당할 수 있는 범위(감지·원인 분리·제한적인 1차 대응)와 사람이 판단해야 하는 범위(불가역적 작업·중단 판단)를 정리하고, 조회 전용 트리아지 쿼리를 제공합니다.
関連サービス
감사 로그 보관 및 점검 흐름을 설계하기
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
감사 로그 보관 및 점검 흐름을 설계하기