【syslog入門 第9回】クラウドのログ ― AWSのログの全体像、CloudWatch Logs、CloudTrail、VPCフローログ、S3とAthena、マルチアカウント、Azure、オンプレとの一元化、コスト

「不正アクセスの疑いで調べたら、VPCフローログを有効にしていなかったので、通信の記録がありませんでした」
「CloudWatch Logsの請求が、毎月じわじわ増えています」

クラウドでは、何も設定しないと残らないログが多くあります。そして、残すと決めたログは、放っておくと費用が積み上がります。

第8回（分析と監視・SIEM）では、ログの検索と監視を見ました。第9回では、AWSを中心にクラウドのログサービスと、オンプレのログとの一元化を扱います。

---

AWSのログの全体像

ログ	分かること	主な出力先	既定の状態
CloudTrail（管理イベント）	誰が・いつ・どの API を呼んだか	イベント履歴（90日）、証跡で S3・CloudWatch Logs	90日の履歴は自動。長期は証跡を作る
CloudTrail（データイベント）	S3 のオブジェクト操作、Lambda の実行など	証跡で S3・CloudWatch Logs	無効（有料で有効化）
VPC フローログ	通信の5タプル、許可・拒否	CloudWatch Logs、S3、Amazon Data Firehose	無効
OS・アプリのログ	syslog、Windows のイベント、アプリのログ	CloudWatch Logs（エージェント経由）	エージェントの導入が必要
ELB・CloudFront・WAF のログ	リクエストごとの記録	S3（WAF は CloudWatch Logs・Firehose も）	無効
Route 53 VPC Resolver のクエリーログ	VPC 内の名前解決	CloudWatch Logs、S3、Firehose	無効（連載「DNS入門」第10回）
Lambda・ECS・RDS など	実行のログ、DB のログ	CloudWatch Logs	Lambda は自動、RDS はエクスポートの設定が必要

AWSでは、何も設定しないと残らないログが多いことに注意します。冒頭の「フローログが無かった」のように、事故が起きてから有効にしても、過去の分は取れません。アカウントを作ったときに有効にする項目を、決めておきます（後の「マルチアカウントの集約」）。各サービスの基本は、連載「クラウド入門」第11回（運用・監視・コスト 前編）を参照してください。

---

CloudWatch Logsの設計

CloudWatch Logsは、ロググループの中にログストリームを置く構造で、保持期間、ログクラス、暗号化、アクセス権はロググループ単位で決まります。

• 保持期間の既定は「失効しない」で、放置すると保存料が積み上がる。1日から10年の中から、規程（第7回）に合わせて必ず設定する
• ログクラスにはStandardとInfrequent Access（IA）がある。IAは取り込みの単価が半分だが、メトリクスフィルター、サブスクリプションフィルター、Live Tailなどが使えず、作成後に変えられない
• アラームや転送に使うログはStandard、調査のときだけ検索するログはIA、と用途で分ける
• 機密情報はデータ保護ポリシーで取り込み時に伏せられ、元の内容はlogs:Unmask権限を持つ人だけが見られる

冒頭の「請求がじわじわ増える」は、多くの場合、保持期間の設定漏れです。

CloudWatchエージェントとLogs Insights

{ "logs": { "logs_collected": { "files": { "collect_list": [ {
    "file_path": "/var/log/secure",
    "log_group_name": "/corp/prod/linux/secure",
    "log_stream_name": "{instance_id}",
    "retention_in_days": 400 } ] } } } }

fields @timestamp, @message
| filter @message like /Failed password/
| parse @message "for * from * port" as user, src
| stats count(*) as fails by user, src
| sort fails desc
| limit 20

• 上は、エージェントの設定（抜粋）と、Logs InsightsでSSHのログオン失敗をユーザーと送信元ごとに数えるクエリーの例
• エージェントは、ファイル、journald（Linux）、Windowsのイベントログを読んで送る。syslogをUDP・TCPで直接受ける機能はないので、機器のsyslogはrsyslogで受けてファイルに書き、それを読ませる（後の「オンプレのログとの一元化」）。設定の配り方は連載「クラウド入門」第11回
• Logs Insightsはスキャンした量で課金（東京0.0076 USD/GB）されるため、期間とロググループを絞る。OpenSearchのPPL・SQLでも書ける。AWS CLIは、Windowsでも同じコマンドで使える

---

CloudTrailの設計

CloudTrailの基本は、連載「クラウド入門」第11回で扱っています。

• まず、管理アカウントで組織の証跡を作り、全アカウント・全リージョンの記録をログアーカイブ用アカウントのS3へ出力する。メンバーアカウントからは止められない
• バケットには、Object Lockとバケットポリシーを設定し、KMSで暗号化する
• 整合性検証を有効にする。1時間ごとにダイジェストファイルが作られ、ログのSHA-256のハッシュと前のダイジェストのハッシュを含めて署名されるため、aws cloudtrail validate-logsで書き換えや削除を検出できる（第7回のハッシュチェーン）
• 記録は平均5分程度で届くが、保証はない
• CloudTrail Lakeは2026年5月末で新規の受け付けを終了したため、検索にはCloudWatchやAthenaを使う

改ざんは鎖で見つけ、消去はObject Lockと別アカウントで防ぎます。

---

VPCフローログ

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-0a1b2c3d4e5f67890 203.0.113.50 192.0.2.10 49152 22 6 3 180 1790384400 1790384460 REJECT OK

$ aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-0a1b2c3d4e5f67890 \
    --traffic-type ALL --log-destination-type s3 \
    --log-destination arn:aws:s3:::corp-example-flowlogs \
    --destination-options FileFormat=parquet,HiveCompatiblePartitions=true,PerHourPartition=true \
    --max-aggregation-interval 60

• 1行目が既定の形式（バージョン2）の項目名、2行目が記録の例（203.0.113.50からのSSHを拒否）。パケットの中身は含まない。用途は連載「クラウド入門」第7回
• 出力先は、CloudWatch Logs、S3、Amazon Data Firehose。集約の間隔は既定が最大10分で、1分も選べる。vpc-id、flow-direction、pkt-srcaddrなどは、カスタム形式で追加する
• 量が多いので、S3にParquet形式とHive互換のパーティションで出し、Athenaで検索すると安い。既存のフローログを後からParquetに変えることはできない。WindowsのPowerShellでは、行の継続を、行末の「\」ではなくバッククォート記号にする

---

S3への保管とAthenaでの検索

SELECT srcaddr, dstport, count(*) AS n
FROM vpc_flow_logs
WHERE year = '2026' AND month = '09' AND day = '25'
  AND action = 'REJECT'
GROUP BY srcaddr, dstport
ORDER BY n DESC
LIMIT 20;

• 上は、前日に拒否された通信を、送信元と宛先ポートごとに数えるAthenaのクエリーの例（year・month・dayは、フローログの出力で作ったパーティション）
• S3：ライフサイクルで、S3標準→（30日）標準IA→（90日）Glacier→（1年）削除のように移し、Object LockでWORMにする（第7回）
• Athena：S3のファイルにSQLで直接問い合わせる。スキャン量で課金（東京5 USD/TB、1クエリー最低10 MB）されるため、日付のパーティションで範囲を絞り、Parquetのような列指向の形式にして読む量を減らす。パーティション射影を使うと、パーティションの登録作業も要らない

---

マルチアカウントの集約

• AWSでは、本番、開発、部門ごとにアカウントを分けるのが一般的（連載「クラウド入門」第12回）。このとき、ログは専用のログアーカイブ用アカウントに集める。管理者が乗っ取られても、別のアカウントのログは消せないから（第7回の権限の分離）
• AWS Control Towerを使うと、ログアーカイブ用と監査用のアカウントが作られ、組織のCloudTrailとConfigの記録がログアーカイブ用アカウントのS3に集まる。保持期間の既定は、ログが1年、アクセスログが10年で、最長15年まで変えられる。ただし、2025年11月のランディングゾーン4.0から、これらの連携は任意になったので、有効かを確かめる
• CloudWatch Logsは、2025年9月に加わった一元化のルールで、複数のアカウント・リージョンのロググループを1つのアカウントへ複製できる

---

Azureとの対応表

AWS	Azure	違い・注意
CloudWatch Logs（ロググループ）	Log Analytics ワークスペース（テーブル）	保持はテーブル単位。分析用の保持は既定30日・最長2年、全体で最長12年
ログクラス（Standard・IA）	テーブルプラン（Analytics・Basic・Auxiliary）	Basic・Auxiliary は取り込みが安く、検索に課金
CloudWatch エージェント	Azure Monitor エージェント（AMA）＋データ収集ルール（DCR）	旧 Log Analytics エージェントは2024年8月に廃止
Logs Insights	KQL（Kusto 照会言語）	連載「クラウド入門」第11回
CloudTrail	アクティビティログ（管理操作、既定90日）、Entra ID のサインイン・監査ログ	長期の保存は診断設定で Log Analytics などへ送る
VPC フローログ	VNet フローログ（NSG フローログの後継）	出力先はストレージアカウント
S3＋Athena	ストレージアカウント、Log Analytics の長期保持と検索ジョブ	—
Security Lake＋SIEM	Microsoft Sentinel（Log Analytics の上で動く SIEM）、Sentinel データレイク	Defender ポータルへ移行。Azure ポータル版は2027年3月末で終了

syslogの受け方が違います。CloudWatchエージェントはファイルを読みますが、AMAは同じサーバーのrsyslogやsyslog-ngから転送を受け（新しい版はTCP 28330）、DCRで指定したFacilityとSeverityだけを送ります。CEF形式の機器は、ログフォワーダーを置いて、AMA経由でSentinelへ送ります。

---

オンプレのログとの一元化

経路	仕組み	向く場面	注意
①CloudWatch エージェント	rsyslog で集約したログサーバーのファイルを読んで送る	既存の rsyslog の集約を活かす	syslog は直接受けない。オンプレでは認証情報の用意（SSM のハイブリッドアクティベーションなど）が要る
②Fluent Bit	syslog を受け、CloudWatch Logs・S3・Firehose・OpenSearch へ送る	形式の変換、送り先が複数	自分で運用・監視する
③Amazon Data Firehose	中継から API で送り、S3・OpenSearch・Splunk などへ配信	大量のログを S3 に貯め、Athena で検索	バッファーの分だけ遅れて届く
④CloudWatch Logs の HTTP エンドポイント	OTLP・JSON を HTTP で直接送る（2026年3月〜）。rsyslog の omawslogshlc など	エージェントを置かずに送る	提供リージョンが限られる（東京は要確認）
⑤SIEM・検索基盤に集める	オンプレは中継から SIEM へ、AWS のログは SIEM が S3 から取り込む	SIEM を中心にする	両方で取り込みの費用がかかる

どの経路でも、中継からTLS（またはHTTPS）で運び、Direct Connect・VPNを通すか、インターネットを通すかを決めます。時刻はUTCにそろえ（第7回）、オンプレのホスト名とインスタンスIDの対応表を持っておくと、両方のログを突き合わせやすくなります（連載「NTP入門」第11回の問2）。

---

コストの考え方：取り込み・保存・検索

段階	CloudWatch Logs（東京）	S3＋Athena（東京）	抑える工夫
取り込み	Standard 0.76 USD/GB、IA 0.38 USD/GB。フローログなどは量に応じて段階的に安くなる	S3 への PUT は安い。フローログの S3 配信は 0.38 USD/GB から段階的に安くなる	不要なログ・デバッグログを送らない。送る前に絞る
保存	0.033 USD/GB・月（2026年7月から自動の階層化も選べる）	S3 標準は約0.025 USD/GB・月。Glacier はさらに安い	保持期間、ライフサイクル、圧縮
検索	Logs Insights 0.0076 USD/GB（スキャン量）	Athena 5 USD/TB（スキャン量）	期間と対象を絞る。Parquet・パーティション
転送	リージョンの外やインターネットへの転送は有料	同左	同じリージョンの中で処理する

第7回の例（1日約110 GB）をすべてCloudWatch LogsのStandardに取り込むと、取り込みだけで月に約2,500 USD（110 GB × 30日 × 0.76）かかります。アラームに使うログだけをCloudWatch Logsに入れ、ほかはS3に直接置いてAthenaで検索する、という分け方で費用は大きく変わります。単価は2026年9月時点です。

---

考えてみよう

1. 自分のAWSアカウントで、保持期間が「失効しない」のままのロググループはいくつありますか。そのうち、誰も見ていないものはどれですか。
2. CloudTrailの証跡を、ワークロードの管理者でも消せない形で残せていますか。証跡を止められたら、誰がどのように気づきますか。
3. オンプレのファイアウォールのログをAWS側でも検索したいとき、どの経路を選びますか。この記事の単価で、1か月の費用を見積もってください。

ヒント：この記事のCloudWatch Logsの保持期間、CloudTrailの証跡とマルチアカウントの権限の分離、一元化の経路とコストの表が手がかりです。

---

まとめ

• AWSは何も設定しないと残らないログが多い。アカウントを作るときに有効にする項目を決める
• CloudWatch Logsの保持期間の既定は「失効しない」。必ず設定し、StandardとIAを用途で分ける
• CloudTrailは組織の証跡をログアーカイブ用アカウントへ。整合性検証とObject Lockで守る
• VPCフローログは量が多いので、S3にParquetとパーティションで出し、Athenaで絞って検索
• AzureはLog AnalyticsとAMA＋DCR。AMAはrsyslogから転送を受ける
• オンプレとの一元化は5つの経路。どれもTLS・UTCで
• 費用は取り込み・保存・検索。アラームに使うものだけCloudWatch Logsへ、ほかはS3＋Athena

次回は、「ログが届かない」ときの切り分けの手順を扱います。

---

連載「syslog入門」全11回

全回の目次と、読む順番・目的別の読み方は、syslog入門の入口のページにまとめています。

1. ログとは・なぜ集めるか
2. syslogの基本
3. Linuxのログの仕組み
4. rsyslog 前編
5. rsyslog 後編
6. Windows・ネットワーク機器のログ
7. ログ集約基盤の設計
8. 分析と監視・SIEM
9. クラウドのログ（この記事）
10. syslogのトラブルシュート
11. ログ管理の設計演習