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のログファイルは自動的にローテーションされます。長期保管が必要なら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では、監査設定が意図した状態から変わっていないかを定期的に照合し、ログ量の推移とロググループの保持期間をあわせて管理しています。権限付与やテーブル削除といった検知対象イベントは通知の対象にし、通知後の一次確認を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が担える範囲(検知・切り分け・限定的な一次対応)と人間が判断すべき範囲(不可逆な操作・停止判断)を整理し、参照専用のトリアージクエリを提供します。
関連サービス
監査ログの保管と点検フローを設計する
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
監査ログの保管と点検フローを設計する