rsyslogは、Linuxのログの書き出しと転送を担う中心的なソフトウェアです（第3回）。設定はシンプルに見えますが、キューの仕組みを知らないと、転送先の障害が送信側全体を止めたり、ログが静かに消えたりします。

第4回（前編）では、rsyslogの内部構成と、受信・転送の設定、そしてログサーバーが止まっても欠損させない方法を扱います。第5回（後編）では、テンプレート・振り分け・TLS・RELPなどを扱います。

rsyslogの内部構成

rsyslogは、ログを「受け取る」「振り分ける」「書き出す」処理を、モジュールと呼ぶ部品の組み合わせで行います。

1. 入力モジュール（名前がimで始まる）が、journal、ローカルのソケット、ネットワーク（UDP・TCP・RELP）、テキストファイルなどからメッセージを受け取る
2. パーサーで、PRI、時刻、ホスト名などに分解される
3. キューに入る
4. キューから取り出されたメッセージに、ルールセットに書かれたフィルター（条件）が上から順に当てはめられ、合えばアクションが実行される
5. アクションの実体は出力モジュール（omで始まる）で、ファイルへの書き込み、別のサーバーへの転送、HTTPでの送信などを行う。加工用のモジュール（mm）もある

設定ファイルは、この「入力 → ルールセット → 出力」を書き並べたものだと考えると、読みやすくなります。

メインキューとアクションキュー

冒頭の「ログサーバーが止まったら各サーバーまで遅くなった」の原因が、ここにあります。

• rsyslogには2種類のキューがある。すべての入力はまず1つのメインキュー（既定はメモリ上に10万件）に入り、ワーカースレッドがルールセットを実行する
• 一方、各アクションは既定ではキューを持たないDirectモードで、メインキューのスレッドがその場で書き込みや送信を行う
• ここに落とし穴がある。TCPで転送する先が応答しなくなると、そのアクションで処理が止まり、メインキューがたまり続け、やがてローカルのファイルへの書き込みや入力の受け付けまで滞る

そこで、遅くなりうるアクション（リモートへの転送、HTTP、データベース）にはアクションキューを付けて切り離します。種類は必要な分だけメモリを使うLinkedListを選び、ファイル名を与えてディスクにも退避できるようにします（この後の転送の設定）。

ポイント
詰まりを、1つのアクションの中に閉じ込める。転送のアクションには必ずキューを付ける。

主なモジュールとパッケージ

RHELでは、TLS（rsyslog-gnutlsかrsyslog-openssl）とRELP（rsyslog-relp）が別パッケージで、入れずに設定だけ書くとモジュールを読み込めず、起動に失敗します（sudo dnf install rsyslog-gnutls rsyslog-relp）。Ubuntuも同様です。ほかに、テキストファイルを読むimfile、メールを送るommail（第5回）があります。GSSAPIは今はほぼ使われません。

現行版と設定の検査（rsyslogd -N1）

$ rsyslogd -v | head -1
rsyslogd  8.2512.0 (aka 2025.12) compiled with:
$ sudo rsyslogd -N1
rsyslogd: version 8.2512.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
$ sudo rsyslogd -N1          # 誤りがある場合
rsyslogd: error during parsing file /etc/rsyslog.d/90-forward.conf, on or before line 9: parameter 'target' required but not specified - fix config [v8.2512.0 try https://www.rsyslog.com/e/2207 ]

• -N1は起動せずに設定を検査し、構文、パラメーター名のつづり、必須の項目を確かめる
• 証明書の読み込みや接続までは検査しないため、再起動後にsystemctl status rsyslogとjournalctl -u rsyslogでエラーが無いかも確かめる
• 変更したら必ず「-N1 → 再起動 → 確認」の順で進める。版番号の8.YYMMは、リリースの年月

3つの書式の見分け方

# ① sysklogd 形式：セレクター と 出力先
authpriv.*                          /var/log/secure
# ② レガシー形式：行頭が $
$ModLoad imudp
$UDPServerRun 514
# ③ RainerScript：名前="値" で書く（①②と同じ意味）
module(load="imudp")
input(type="imudp" port="514")
authpriv.* action(type="omfile" file="/var/log/secure")

Ubuntu 26.04の既定の設定には、今もレガシー形式（$FileOwnerなど）が残っています。混在しても動きますが、自分で書くファイルはRainerScriptにそろえます。Webで拾った例は、どの書式・どの版向けかを確かめてから使います。引用符は必ず半角の"（全角や曲がった引用符はパースエラーになります）。

受信の設定（imudp・imtcp）

# /etc/rsyslog.d/10-remote.conf（ログサーバー logsv01）
module(load="imudp")
module(load="imtcp" MaxSessions="1000")    # 既定は 200 セッション
ruleset(name="remote") {
    action(type="omfile" file="/var/log/remote/all.log")
}
input(type="imudp" port="514" ruleset="remote")
input(type="imtcp" port="514" ruleset="remote")

• module()は1つのモジュールにつき1回だけ書く。待ち受けはinput()を必要な数だけ並べる
• ruleset="remote"で、受信したログを専用のルールセットに流す。ローカルのログ（/var/log/messages）と混ざらず、受信側の振り分けを1か所にまとめられる
• ポートは514/udp、514/tcp（慣習。IANAでは514/tcpはshellに割り当て）、TLSは6514/tcp（第2回・第5回）
• 送信元が多いときは、TCPの同時セッションの上限（MaxSessions、既定200）を超えないようにする
• 振り分けと保存先のファイル名は、このルールセットの中に書く（第5回）

受信側のOSの設定（firewalld・SELinux）

$ sudo firewall-cmd --permanent --add-service=syslog         # 514/udp
$ sudo firewall-cmd --permanent --add-port=514/tcp
$ sudo firewall-cmd --permanent --add-service=syslog-tls     # 6514/tcp・udp
$ sudo firewall-cmd --reload
$ sudo semanage port -l | grep syslog                        # （抜粋）
syslog_tls_port_t              tcp      6514, 10514
syslog_tls_port_t              udp      6514, 10514
syslogd_port_t                 tcp      601, 20514
syslogd_port_t                 udp      514, 601, 20514
$ sudo semanage port -a -t syslogd_port_t -p tcp 30514      # 既定外のポートを使うとき
$ sudo ss -tulnp | grep rsyslogd                             # 待ち受けの確認
PS> Test-NetConnection logsv01.corp.example.jp -Port 6514     # Windows から TCP の到達を確認

• RHELのSELinuxでは、rsyslogが使えるポートが決まっている。一覧に無いポートで待ち受けると、設定が正しくてもbindが拒否されて起動時にエラーになる
• 514/tcpは一覧ではrsh_port_tだが、rsyslogが使うことはポリシーで許可されている
• WindowsのTest-NetConnectionが確かめられるのはTCPだけ（TcpTestSucceeded : Trueなら到達）。UDPは届いたかを送信側で確かめられないため、受信側のtcpdumpで見る（第10回）

転送の設定（omfwd）とアクションキュー

# /etc/rsyslog.d/90-forward.conf（送信側 web01）
action(type="omfwd" name="fwd_logsv01"
       target="logsv01.corp.example.jp" port="514" protocol="tcp"
       template="RSYSLOG_SyslogProtocol23Format"
       queue.type="LinkedList"
       queue.filename="fwd_logsv01"
       queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on"
       action.resumeRetryCount="-1"
       action.resumeInterval="30")

• target（必須）・port・protocol：送り先。targetを書き忘れると、起動時にエラーになる（上の-N1の誤りの例）
• template：RFC 5424形式で送る（第5回）。省略すると、RFC 3164風のRSYSLOG_TraditionalForwardFormat
• queue.type="LinkedList"：このアクション専用のキューを作り、メインキューから切り離す
• queue.filename：名前を付けると、あふれた分をディスク（/var/lib/rsyslog）へ退避する。転送先ごとに別の名前にする
• queue.maxDiskSpace：退避に使うディスクの上限。queue.saveOnShutdown="on"：停止時にメモリ上の未送信分を保存する
• action.resumeRetryCount="-1"：送れるまで再試行し続ける。既定の0では、失敗したメッセージは捨てられる

ログサーバーが止まっても欠損させない

冒頭の「再起動の間のログが抜けた」への答えです。ログサーバーの再起動や回線の断は、必ず起きます。欠損させないには、送信側で「送れなかった分をためて、戻ったら送る」仕組みが要ります。

• 前の節の設定では、転送先が応答しないとアクションが一時停止し、メッセージはアクションキューにたまる。メモリがいっぱいに近づくと/var/lib/rsyslogの下のファイルへ退避され、rsyslogを止めるときも保存される
• 転送先が戻ると、定期的な再試行で気付き、たまった分を古い順に送る

ただし、限界もあります。

• UDPは、相手が止まっても送信側でエラーにならないため、ためる仕組みが働かない
• TCPでも、切断の直前に送った分が失われることがあり、確実に届けるにはRELP（第5回）を使う（第2回の「到達保証と暗号化は別のもの」）
• queue.maxDiskSpaceを超えた分は捨てられるため、想定する停止時間 × ログの量から容量を見積もる（第7回）

送信側のディスクが、止まっている間の受け皿になるのです。

考えてみよう

1. 担当のサーバーのrsyslogで、転送のアクションにキューは付いていますか。転送先が1時間止まったら、何が起きますか。
2. ログの量が1秒あたり200件・1件300バイトのサーバーで、ログサーバーの4時間の停止に耐えるには、queue.maxDiskSpaceをどれくらいにしますか。
3. ネットワーク機器からUDPで受けているログは、ログサーバーの再起動の間、どうなりますか。どう減らせますか。

ヒント：この記事のメインキューとアクションキューの図、転送の設定の各パラメーター、欠損させない仕組みの図が手がかりです。2問目は200 × 300 × 14,400秒 ≒ 864MBです。

まとめ

• rsyslogは入力（im）→ パーサー → キュー → ルールセット → 出力（om）。設定ファイルはこの流れの書き並べ
• アクションは既定でDirect。転送先が止まるとメインキューごと詰まる。転送にはアクションキューを付ける
• TLS・RELPは別パッケージ。変更は「-N1 → 再起動 → 確認」
• 自分で書く設定はRainerScriptに。引用符は半角
• 受信はinput()ごとに専用のルールセットへ。RHELではfirewalldとSELinuxの関門も確かめる
• 転送はqueue.type="LinkedList"・queue.filename・resumeRetryCount="-1"でためて送る。UDPはためられない

次回（後編）は、テンプレート、振り分け、TLS、RELP、メール発報、レート制限を扱います。

連載「syslog入門」全11回

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

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

AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 CLF）では、AWS 自体のコンプライアンスの資料と契約（AWS Artifact）と、自社の環境の記録・評価（CloudTrail・Config・Trusted Advisor）を見分ける問題が問われます。決め手は、「AWS の」資料なのか、「自社の」記録なのかです。

この記事は、CLF の練習問題を1問ずつ解説する連載の第22問です。問題は筆者が試験の範囲に合わせて作ったもので、実際の試験の問題ではありません。まず自分で答えを選んでから、解説を読んでください。

▶ この回の内容は、YouTube の動画（約5分）でも見られます（記事の最後にも埋め込んであります）。

問題

ある医療系の企業は、患者の健康情報を扱うシステムを AWS 上に作ります。取引先の監査人から、AWS が ISO 27001 の認証を受けていることを示す証明書の提出を求められました。また、米国の HIPAA の対象となるため、AWS と事業提携契約（BAA）を結ぶ必要があります。これらに使う AWS サービスはどれですか。

• A. AWS Config
• B. AWS Trusted Advisor
• C. AWS CloudTrail
• D. AWS Artifact

答えを決めたら、下を開いてください。

正解は D

正解は D の AWS Artifact です。

• AWS 自体のコンプライアンスの資料（ISO の証明書など）をダウンロードできる
• BAA のような AWS との契約を、確認して承諾できる
• ほかの3つは、利用者自身の環境を記録したり、評価したりするサービス

ここから、選択肢を1つずつ見ていきます。

選択肢ごとの解説

A：Config は自社の設定の評価（誤り）

図の上は、今回の4つのサービスを2つに分けた図です。左は AWS 自体の資料と契約、右は利用者自身の環境の記録と評価です。AWS Config は、右のグループです。

Config は、利用者のリソースの設定を記録し、ルールに沿っているかを評価します。これは自社の環境の評価です。AWS の証明書は、Config では手に入りません。

B：Trusted Advisor は自社の点検（誤り）

AWS Trusted Advisor も、右のグループです。利用者のアカウントを点検するサービスで、コスト、セキュリティ、耐障害性などの面から、ベストプラクティスに沿った推奨を出します。

点検するのは自社のアカウントです。AWS 自体の監査の資料は出しません。

C：CloudTrail は自社の操作の記録（誤り）

AWS CloudTrail も、右のグループです。利用者のアカウントで行われた API の呼び出しを記録し、誰が、いつ、何をしたかを、後から確かめられます。

ただし、これは自社の環境の証跡です。AWS が認証を受けていることを示す資料ではありません。

D：AWS の資料と契約は Artifact（正解）

AWS Artifact は、左のグループで、AWS 自体の資料と契約を扱います。ISO の認証の証明書や、SOC、PCI のレポートを、必要なときにダウンロードできます。これを監査人に渡します。

BAA のような AWS との契約も、Artifact で確認して承諾できます。料金はかかりません。

4つのサービスの使い分け

AWS の資料や AWS との契約は Artifact、自社の操作の記録は CloudTrail、自社の設定の評価は Config、ベストプラクティスの点検は Trusted Advisor です。

なお、古い問題集では、AWS Audit Manager が引っかけによく出ます。自社の監査の証拠を集めるサービスです。Audit Manager は、2026年4月30日から、新しい利用者は使えなくなりました。

ポイント

• AWS の レポート・証明書・契約 は AWS Artifact（無料）
• CloudTrail・Config・Trusted Advisor は 利用者自身の環境 の記録・評価・点検
• 「AWS の」資料か「自社の」記録かで見分ける

AWS Artifact の使いどころと、自社の環境の記録・評価のサービスの違いは、講座の記事で詳しく解説しています。

• 講座の第10回⑨「コンプライアンスと情報源」（連載の入口のページから）
• 講座の第09回③「AWS Config と3つの使い分け」（連載の入口のページから）

講座の全14回は、連載の入口のページから順に読めます。

動画で見る

この回の内容を、YouTube の動画（約5分）でも解説しています。

連載の全回は、YouTube の再生リスト「CLF-C02 試験対策問題」にまとめています。

連載「CLF-C02 試験対策問題」

全回の目次と、読む順番・目的別の読み方は、CLF-C02 試験対策問題の入口のページにまとめています。

1. 第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）
2. 第2問 数分でグローバルに展開（世界同時公開と低い遅延）
3. 第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）
4. 第4問 クラウドの俊敏性（数分で作成・すぐに削除）
5. 第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）
6. 第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）
7. 第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）
8. 第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）
9. 第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）
10. 第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）
11. 第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）
12. 第12問 移行のビジネスケース（Migration Evaluator）
13. 第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）
14. 第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）
15. 第15問 ファイルの移行（AWS DataSync）
16. 第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）
17. 第17問 適切なサイズ設定（CPU は余り、メモリが不足）
18. 第18問 責任共有モデル（Lambda と RDS）
19. 第19問 最小権限の原則（IAM のポリシーと SCP）
20. 第20問 責任共有モデル（EC2 と S3、AWS の責任）
21. 第21問 共有統制の例（責任共有モデルの IT 統制）
22. 第22問 コンプライアンスの資料と契約（AWS Artifact）（この記事）
23. 第23問 脅威の検出（Amazon GuardDuty）
24. 第24問 脆弱性の継続的なスキャン（Amazon Inspector）
25. 第25問 S3 の機密データの検出（Amazon Macie）
26. 第26問 S3 の保管時の暗号化とキーの管理
27. 第27問 だれが操作したかを調べる（AWS CloudTrail）
28. 第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）
29. 第29問 EC2 のアプリケーションに権限を与える（IAM ロール）
30. 第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）
31. 第31問 社員に一時的な認証情報を発行するサービス（AWS STS）
32. 第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）
33. 第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）
34. 第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）
35. 第35問 追加料金なしの DDoS 保護（AWS Shield Standard）
36. 第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）
37. 第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）
38. 第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）
39. 第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）
40. 第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）
41. 第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）
42. 第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）
43. 第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）
44. 第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）
45. 第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）
46. 第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）
47. 第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）
48. 第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）
49. 第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）
50. 第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）
51. 第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）
52. 第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）
53. 第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）
54. 第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）
55. 第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）
56. 第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）
57. 第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）
58. 第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）
59. 第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）
60. 第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）
61. 第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）
62. 第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）
63. 第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）
64. 第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）
65. 第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）
66. 第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）
67. 第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）
68. 第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）
69. 第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）
70. 第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）
71. 第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）
72. 第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）
73. 第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）
74. 第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）
75. 第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）
76. 第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）
77. 第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）
78. 第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）
79. 第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）
80. 第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）
81. 第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）
82. 第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）
83. 第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）
84. 第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）
85. 第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）
86. 第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）
87. 第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）
88. 第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）
89. 第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）
90. 第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）
91. 第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）
92. 第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）
93. 第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）
94. 第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）
95. 第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）
96. 第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）
97. 第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）
98. 第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）
99. 第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）
100. 第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）

どちらも、AWS の伸縮性を学び始めた人から出やすい質問です。答えは、1つ目は 「大きくするのが垂直スケーリング、台数を増やすのが水平スケーリング。ELB と Auto Scaling は水平スケーリングで伸縮性を実現する」、2つ目は 「ELB が担当するのは振り分けだけで、台数は増減しない。台数を増減するのは Auto Scaling」 です。この記事では、ある EC サイトの会社の例で、その違いを順に見ていきます。

この記事は、AWS クラウドプラクティショナー試験対策講座（AWS Certified Cloud Practitioner、試験コード CLF-C02。以下 CLF）の第04回③です。試験ガイドのタスク 3.3（AWS のコンピューティングサービスを特定する）のうち、自動スケーリングによる伸縮性とロードバランサーの目的を扱います。なお、この連載は AWS の公式の資料ではありません。試験の情報は2026年10月26日時点のもので、変わることがあるので、受験の前に AWS の公式ページで確かめてください。

1台のサーバーの限界

ある EC サイトの会社が、shop.example.com でセールを開くとします。

普段のアクセスなら1台のサーバーで足りても、セールの日にはアクセスが集中して処理が追いつかず、画面の表示が遅くなります。お店でいえば、レジが1台しかなく、客の行列が伸びる状態です。

さらに、その1台が故障すると、サイト全体が止まってしまいます。

このように、1台だけで支える形には、集中に弱いこと、止まると全体が止まることという2つの限界があります。この限界を超えるために、台数を増やして支える考え方を、次の節から順に見ていきます。

• アクセスが集中すると、1台では遅くなる
• 1台が止まると、サービス全体が止まる
• 台数を増やして支える考え方を、次から学ぶ

垂直スケーリングと水平スケーリング ◎

処理能力を増やす方法は2つあります。

垂直スケーリング（1台を大きくする。スケールアップとも言う）は、1台のサーバーをより大きな型に替えて、CPU やメモリを増やす方法です。EC2 では、インスタンスタイプを変えることにあたります。なお、AWS の文書では「スケールアップ」を、単に容量を増やす意味で使うこともあります（第02回②の「伸縮性とスケーラビリティ」の節）。この講座では、1台を大きくするか台数を増やすかを分けて話すときに、スケールアップ・スケールアウトの語を使います。

水平スケーリング（台数を増やす。スケールアウトとも言う）は、同じ大きさのサーバーの台数を増やす方法で、減らすことはスケールインと言います。

垂直は1台の大きさに限りがありますが、水平は台数を足し引きして、需要に合わせやすくなります。次に見る ELB と Auto Scaling は、水平スケーリングで伸縮性（第02回②の「伸縮性」の節）を実現します。

• 垂直：1台を大きくする（スケールアップとも言う）
• 水平：台数を増やす（スケールアウトとも言う）
• 垂直は大きさ、水平は台数と覚える

冒頭の1つ目の相談がこれです。サーバーを大きくするのは垂直、台数を増やすのは水平です。第04回②の「インスタンスタイプとは」の節で見たように、EC2 の大きさは型（インスタンスタイプ）で決まるので、1台を大きくする垂直は、型を替えることにあたります。

ロードバランサーの目的 ◎

台数を増やすと、新しい問題が出てきます。利用者からの要求を、複数のサーバーにどう配るかです。

ロードバランサーは、利用者からの要求を受け取る入口を1つにして、複数のサーバーに振り分ける仕組みです。お店でいえば、空いているレジに客を案内する係にあたります。これにより、1台に負荷が偏らず、全体で多くの要求をさばけます。

さらに、ヘルスチェック（振り分け先が正常に動いているかを、定期的に確かめること）を行い、止まったサーバーには要求を送りません。利用者は、裏でサーバーが何台あるか、どれが止まっているかを意識せずに使えます。

試験ガイドにも、ロードバランサーの目的を特定することが、対象スキルとして挙がっています。

• 入口を1つにして、複数のサーバーに振り分ける
• ヘルスチェックで、止まったサーバーを外す
• 台数の増減は別の仕組み（Auto Scaling）

Elastic Load Balancing（ELB）とは ◎

Elastic Load Balancing（ELB） は、AWS のロードバランサーのサービスです。

ELB が担当するのは振り分けだけで、サーバーの台数は増減しません。台数を増減するのは、Auto Scaling の役割です。

振り分け先はターゲットと呼び、EC2 のインスタンスなどを登録します。ターゲットは1つ以上の AZ に置け、複数の AZ に分けて置けば、1つの AZ が止まっても、残りで続けやすくなります（AZ の考え方は第03回②の「アベイラビリティーゾーン（AZ）」の節）。

ヘルスチェックの結果が正常なターゲットにだけ、要求を送ります。また、要求の量が変わると、ELB 自体の容量も自動で調整されます。

• ELB は AWS のロードバランサーのサービス
• ヘルスチェックで、正常なターゲットだけに振り分ける
• 台数を増減するのは Auto Scaling の役割

冒頭の2つ目の相談の前半がこれです。ELB は振り分けだけで、サーバーの台数は変えません。

ELB の種類 ○

ELB には種類があります。ここでは、次の3つを見ます。

補足：Classic Load Balancer は前の世代です（2026年10月26日時点）。試験ガイドの対象のサービス一覧に ELB は無く、対象スキルに「ロードバランサーの目的」があります。

出典：Elastic Load Balancing とは

Auto Scaling とは ◎

Auto Scaling は、需要に合わせて、サーバーの台数を自動で増やし、減らす仕組みです。第02回で学んだ伸縮性を、AWS の仕組みで実現するものです。お店でいえば、混んだらレジを開け、すいたら閉じる役にあたります。

台数を増減する単位を Auto Scaling グループと呼び、グループには最小・希望・最大の台数を決めます。

名前が似たものに注意してください。

この回では、台数を増減する仕組みをまとめて Auto Scaling と書きます。

• Auto Scaling は台数を自動で増やし、減らす
• 台数は Auto Scaling グループで最小・希望・最大を決める
• EC2 版は台数の増減、AWS 版は複数サービスの計画

Auto Scaling の動き

Auto Scaling グループには、台数の下限（最小）、目標（希望）、上限（最大）を決めます。たとえば最小2台・最大6台なら、台数は2台から6台の間で増減します。

増減のきっかけにはいくつかあります。

• 人が手で台数を決める
• あらかじめ決めた時刻に変える
• CPU の使用率などの指標を見て自動で変える

指標は Amazon CloudWatch が集めます（第09回①の「Amazon CloudWatch」「CloudWatch のアラーム」の節で扱います）。

セールの日の昼はアクセスの山に合わせて台数が増え、夜になると減ります。台数が減れば、使わないサーバーの分の費用も下がります。サーバーが正常でなくなったときは、新しいサーバーに置き換えて、希望の台数を保ちます。

• 最小・最大の範囲で台数が増減する
• きっかけは指標・時刻・手動など
• 異常なサーバーは新しいものに置き換わる

ELB と Auto Scaling を組み合わせる

実際のシステムでは、ELB と Auto Scaling を組み合わせます。役割は別々です。

• Auto Scaling が台数を増減する
• ELB が今あるサーバーへ要求を振り分ける

Auto Scaling を ELB と結びつけておくと、新しくサーバーを起動したときに ELB の振り分け先へ自動で登録され、終了すると登録が外れます。

さらに、サーバーを AZ-a と AZ-b のように2つの AZ に分けて置けば、片方の AZ が止まっても、もう片方で続けられます。これは、第03回で学んだ複数の AZ で止まりにくくする考え方（第03回③の「複数 AZ に分けて置く」の節）を、AWS の仕組みで実現した形です。ある EC サイトの会社のセールの日も、この形で乗り切れます。

• Auto Scaling は台数を増減する
• ELB は今あるサーバーへ振り分ける
• 2つの AZ に分けて置くと止まりにくい

冒頭の2つ目の相談がこれです。2つの役割は別々で、組み合わせて使います。

もっと詳しく知りたい人向けに、連載「クラウド入門」の第4回「コンピューティング 後編」の「Auto Scaling」の節と「ELB（Elastic Load Balancing）」の節で、試験の範囲を超えた詳しい内容（増減の判断の方法、ELB の種類ごとの機能など）を扱っています。

考えてみよう

1. セールの日のアクセスの集中に、垂直スケーリングと水平スケーリングのどちらで備えるか、それぞれの特徴を比べて説明してみてください。冒頭の1つ目の相談に、自分の言葉で答えるつもりで考えてみてください
2. ロードバランサーの役割を、レジの例（空いているレジに客を案内する係）と、ヘルスチェックの働きを使って説明してみてください
3. 冒頭の2つ目の相談に、「振り分ける」「台数を増減する」という言葉を使って答えてみてください。また、2つの AZ に分けて置くと、なぜ止まりにくくなるかも説明してみてください

ヒント：1 は「垂直スケーリングと水平スケーリング」の節、2 は「ロードバランサーの目的」の節、3 は「Elastic Load Balancing（ELB）とは」「ELB と Auto Scaling を組み合わせる」の節を見直してください。

まとめ

• 1台だけで支える形には、集中に弱い、止まると全体が止まるという2つの限界がある
• 垂直スケーリングは1台を大きくする（スケールアップ）、水平スケーリングは台数を増やす（スケールアウト）、減らすのはスケールイン。ELB と Auto Scaling は水平スケーリングで伸縮性を実現する
• ロードバランサーは入口を1つにして複数のサーバーに振り分ける。ヘルスチェックで、止まったサーバーには要求を送らない
• ELB は AWS のロードバランサーのサービスで、振り分けだけを担当する。振り分け先はターゲット。種類は ALB（Web のやり取り）・NLB（Web 以外も含む通信）・GWLB（検査用の機器に通す）
• Auto Scaling は台数を自動で増減する。Auto Scaling グループに最小・希望・最大を決める。きっかけは指標・時刻・手動など。異常なサーバーは新しいものに置き換わる
• ELB と Auto Scaling を組み合わせ、2つの AZ に分けて置くと、集中にも故障にも強くなる

次は、第04回④で、サーバーレスを扱います。

連載「AWS クラウドプラクティショナー試験対策講座」

全回の目次と、読む順番・目的別の読み方は、AWS クラウドプラクティショナー試験対策講座の入口のページにまとめています。

1. 第01回① CLF はどんな資格か（AWS 認定のレベル・CLF の位置づけ・誰向けか・問われること／問われないこと・身につくもの）
2. 第01回② 試験の形式と合格基準（試験の基本情報・2種類の設問・採点される50問・換算スコアと合格点・補整型・結果・受験の流れ・再受験と有効期間）
3. 第01回③ 出題の範囲と配点（4つの分野と配点・試験ガイドの組み立て・分野ごとのタスク・配点と学ぶ量・対象外のサービス）
4. 第01回④ 講座の進め方と学び方（全14回の地図・深さの印・学び方の輪・公式の学習リソース・AWS を触るときの注意・問題文の読み方・早見表）
5. 第02回① クラウドとは（3つの特徴・オンプレミスとの違い・使い始めるまでの速さ・IaaS／PaaS／SaaS・デプロイモデルと選び方）
6. 第02回② AWS クラウドの利点（価値提案・6つのメリット・高可用性・伸縮性・俊敏性・例で見分ける）
7. 第02回③ クラウドエコノミクス（固定費と変動費・オンプレミスのコスト・総保有コスト・規模の経済・適切なサイジング・BYOL・オートメーション）
8. 第02回④ 第02回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
9. 第03回① サービスの全体像（この回のねらい・この講座について・前の回の振り返り・サービスの集まり・カテゴリ・カテゴリと講座の回）
10. 第03回② グローバルインフラ（リージョン・AZ・エッジロケーション・3つの関係と比較・Local Zones・Outposts）
11. 第03回③ 高可用性と複数リージョン（単一障害点・複数 AZ・サービスごとの AZ・複数リージョンの理由・リージョンの選び方）
12. 第03回④ AWS へのアクセス方法（API・コンソール・CLI・SDK・IaC・CloudFormation・1回限りと繰り返す作業）
13. 第03回⑤ 第03回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
14. 第04回① サーバーと仮想マシン（この回のねらい・この講座について・前の回の振り返り・コンピューティングとサーバー・仮想マシン・コンピューティングの全体像）
15. 第04回② Amazon EC2（EC2 とは・ユースケース・お客様が扱う範囲・インスタンスタイプ・ファミリーと選び方・起動するときに選ぶもの）
16. 第04回③ ELB と Auto Scaling（1台のサーバーの限界・垂直と水平のスケーリング・ロードバランサーの目的・ELB とその種類・Auto Scaling・組み合わせ）（この記事）
17. 第04回④ サーバーレス（サーバーレスとは・AWS Lambda とその特徴・ユースケース・Amazon API Gateway・EC2 と Lambda の違い）
18. 第04回⑤ コンテナーとほかの選択肢（コンテナーとは・3つの役割・ECR・ECS と EKS・Fargate・Elastic Beanstalk・Lightsail・Batch）
19. 第04回⑥ 第04回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
20. 第05回① ストレージの種類（この回のねらい・この講座について・前の回の振り返り・ストレージとは・ブロック・ファイル・オブジェクト・3つの種類の比べ方・AWS のストレージの地図）
21. 第05回② EBS とインスタンスストア（Amazon EBS・AZ の中でのレプリケート・スナップショット・EBS の暗号化・インスタンスストア・2つの違い）
22. 第05回③ Amazon S3 とストレージクラス（S3 とは・S3 の特徴・ユースケース・ストレージクラスの考え方・ストレージクラスの一覧）
23. 第05回④ Glacier とライフサイクル（S3 Glacier のクラス・クラスの選び方・ライフサイクルポリシー・ライフサイクルのユースケース・S3 のセキュリティ）
24. 第05回⑤ ファイルとハイブリッド（Amazon EFS・Amazon FSx・ハイブリッドクラウドとストレージ・AWS Storage Gateway・Storage Gateway の種類）
25. 第05回⑥ バックアップと災害対策（バックアップと災害対策の違い・AWS Backup・ユースケース・AWS Elastic Disaster Recovery・データを守る仕組みの重ね方）
26. 第05回⑦ 第05回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
27. 第06回① ネットワークの基本（この回のねらい・この講座について・前の回の振り返り・IP アドレスとネットワークの範囲・ルーティングとゲートウェイ・ポートとプロトコル・この回のサービスの地図）
28. 第06回② VPC とサブネット（Amazon VPC とは・サブネット・パブリックサブネットとプライベートサブネット・インターネットゲートウェイ・NAT ゲートウェイ・ルートテーブル）
29. 第06回③ セキュリティグループとネットワーク ACL（セキュリティグループ・ネットワーク ACL・2つの違い・VPC フローログ・VPC の全体を見る）
30. 第06回④ VPC の外とつなぐ（つなぐ先は3つ・AWS Transit Gateway・AWS PrivateLink・オンプレミスとつなぐ方法）
31. 第06回⑤ VPN と Direct Connect（AWS Site-to-Site VPN・AWS Client VPN・AWS Direct Connect・VPN と Direct Connect の比べ方）
32. 第06回⑥ DNS と Route 53（DNS とドメイン名・Amazon Route 53・Route 53 のルーティングの方法）
33. 第06回⑦ CloudFront と Global Accelerator（エッジロケーションとキャッシュ・Amazon CloudFront・CloudFront の使いどころ・AWS Global Accelerator・CloudFront と Global Accelerator の違い）
34. 第06回⑧ 第06回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
35. 第07回① データベースとは（この回のねらい・この講座について・前の回の振り返り・データベースとは・テーブル・行・列・SQL とは）
36. 第07回② データベースの種類（リレーショナルデータベース・NoSQL データベース・インメモリデータベース・3つの種類の比べ方・EC サイトで使い分けると）
37. 第07回③ 自分で運用か任せるか（データベースを動かすのに要る作業・EC2 上のデータベース・マネージドデータベース・作業の分担の比べ方・使い分けの考え方）
38. 第07回④ RDS とマルチ AZ 配置（Amazon RDS とは・RDS で選べるエンジン・RDS で AWS が引き受けること・マルチ AZ 配置・フェイルオーバー）
39. 第07回⑤ リードレプリカと Aurora（リードレプリカ・マルチ AZ 配置とリードレプリカの違い・Amazon Aurora・RDS と Aurora の関係）
40. 第07回⑥ Amazon DynamoDB（DynamoDB とは・DynamoDB の特長・DynamoDB のテーブル・DynamoDB と RDS の違い）
41. 第07回⑦ ElastiCache・DocumentDB・Neptune（Amazon ElastiCache・キャッシュの置き方・Amazon DocumentDB・Amazon Neptune・ほかの回で扱う DB の話題）
42. 第07回⑧ 第07回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
43. 第08回① 疎結合とつなぎ方の言葉（この回のねらい・この講座について・前の回の振り返り・疎結合とは・つなぎ方の言葉）
44. 第08回② SQS と SNS（Amazon SQS の仕組み・SQS の使いどころ・Amazon SNS の仕組み・SNS の使いどころ）
45. 第08回③ EventBridge と Step Functions（Amazon EventBridge の仕組み・EventBridge の使いどころ・AWS Step Functions の仕組み・Step Functions の使いどころ・SNS・SQS・EventBridge の使い分け・メッセージと通知のサービスを選ぶ）
46. 第08回④ AI と機械学習のサービス（AI と機械学習の言葉・AI/ML のサービスの全体像・画像・文書・文章のサービス・音声と会話のサービス・生成 AI のサービス）
47. 第08回⑤ データ分析のサービス（データ分析の流れ・集める・加工するサービス・分析・見える化のサービス・Athena・Redshift・EMR の違い）
48. 第08回⑥ 業務と開発のサービス（ビジネスアプリケーション・エンドユーザーコンピューティング・開発者ツール・CI/CD の流れ・フロントエンドと IoT）
49. 第08回⑦ 第08回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
50. 第09回① 監視の基本と CloudWatch（この回のねらい・この講座について・前の回の振り返り・3つの困りごとと3つのサービス・Amazon CloudWatch・CloudWatch のアラーム・CloudWatch Logs と標準で取れないもの）
51. 第09回② AWS CloudTrail（AWS CloudTrail・CloudTrail の記録の残し方・CloudTrail の使いどころ）
52. 第09回③ AWS Config と3つの使い分け（AWS Config・Config ルールと準拠の確認・CloudTrail と Config の違い・3つの使い分け・3つを組み合わせる流れ）
53. 第09回④ Trusted Advisor と AWS Health（AWS Trusted Advisor・Trusted Advisor のチェックのカテゴリ・サポートプランと使えるチェック・AWS Health Dashboard・AWS Health API・Trusted Advisor・Health・CloudWatch の違い）
54. 第09回⑤ 運用管理の道具（AWS Systems Manager・AWS Compute Optimizer・Service Quotas と License Manager・運用管理の使い分け）
55. 第09回⑥ Organizations と SCP（なぜアカウントを分けるのか・AWS Organizations・Organizations でできること・サービスコントロールポリシー（SCP）・SCP と IAM の関係）
56. 第09回⑦ Control Tower・Service Catalog・RAM（AWS Control Tower・AWS Service Catalog・AWS RAM）
57. 第09回⑧ 第09回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
58. 第10回① クラウドで守る利点と責任共有モデル（この回のねらい・この講座について・前の回の振り返り・クラウドで守る利点・責任共有モデルとは）
59. 第10回② 責任の分かれ方（AWS の責任（クラウドのセキュリティ）・お客様の責任（クラウド内のセキュリティ）・共有する管理・サービスで変わる責任）
60. 第10回③ 暗号化と KMS・CloudHSM・ACM（転送時と保管時の暗号化・AWS KMS・AWS CloudHSM・AWS Certificate Manager（ACM））
61. 第10回④ AWS アカウントとルートユーザー（AWS アカウントとルートユーザー・ルートユーザーだけができる作業・ルートユーザーの守り方）
62. 第10回⑤ IAM と最小権限（IAM の全体像・IAM ユーザーとグループ・IAM ロール・ポリシーの種類・最小権限の原則とアクセスレポート）
63. 第10回⑥ MFA・フェデレーション・認証情報の保管（パスワード・MFA・アクセスキー・クロスアカウントの IAM ロール・フェデレーションと IAM アイデンティティセンター・Directory Service と Cognito・認証情報の保管）
64. 第10回⑦ Shield・WAF・Firewall Manager（守りの層・AWS Shield・AWS WAF・AWS Firewall Manager・Shield・WAF・Firewall Manager の使い分け）
65. 第10回⑧ 検出と調査のサービス（Amazon GuardDuty・Amazon Inspector・Amazon Macie・Amazon Detective・AWS Security Hub・検出と調査の使い分け）
66. 第10回⑨ コンプライアンスと情報源（コンプライアンスの考え方・第三者認証と地域・業界・AWS Artifact・監査に使うログ・AWS Marketplace のセキュリティ製品・セキュリティ情報の入手先）
67. 第10回⑩ 第10回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
68. 第11回① Well-Architected フレームワークと6つの柱（この回のねらい・この講座について・前の回の振り返り・この回の役割・Well-Architected フレームワークとは・6つの柱の全体像）
69. 第11回② 柱の問いと Well-Architected Tool（柱が答える問い・一般的な設計原則・柱どうしのトレードオフ・Well-Architected Tool）
70. 第11回③ 6つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性・柱と回の対応）
71. 第11回④ 柱どうしの見分け方（信頼性とパフォーマンス効率・コスト最適化と持続可能性・運用上の優秀性と信頼性・セキュリティの柱と第10回）
72. 第11回⑤ 問題文と事例で柱を選ぶ（問題文の言葉から柱を選ぶ・ある EC サイトの会社の構成・柱の目で見直す）
73. 第11回⑥ 故障に備えた設計と疎結合（4つの原則の全体像・故障に備えた設計・コンポーネントの分離（疎結合））
74. 第11回⑦ 伸縮性・並列化と4つの原則（伸縮性の活用・並列化を考慮する・4つの原則と柱）
75. 第11回⑧ 第11回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
76. 第12回① 移行とは何か（この回のねらい・この講座について・前の回の振り返り・移行とは何か・この回の例の会社）
77. 第12回② 移行の流れと利点（移行の大まかな流れ・移行の利点・移行を支えるリソース）
78. 第12回③ AWS CAF の6つの観点（AWS CAF とは・6つの観点・ビジネス寄りの3つの観点・技術寄りの3つの観点・期待できる成果・CAF と Well-Architected の違い）
79. 第12回④ 7つの R と移し方（7つの R とは・そのまま移す：リホストとリロケート・少し手を加える：リプラットフォーム・作り直す：リファクタリング（リアーキテクト）・4つの R を並べて見分ける）
80. 第12回⑤ 買い替える・移さない戦略（買い替える：リパーチェス・移さない：リテインとリタイア・例の会社に当てはめる）
81. 第12回⑥ 評価のサービスと AWS MGN（移行のサービスの地図・費用を見積もる：Migration Evaluator・環境を調べる：Application Discovery Service・進み具合を1か所で見る：Migration Hub・サーバーを移す：AWS MGN）
82. 第12回⑦ データベースの移行：DMS と SCT（データベースの移行とは・AWS DMS・止めずに移す：データベースのレプリケーション・設計を変換する：AWS SCT・DMS と SCT の組み合わせ）
83. 第12回⑧ Snow ファミリーと例の会社の移行（大容量データを運ぶ：Snow ファミリー・例の会社の移行を通して見る）
84. 第12回⑨ 第12回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
85. 第13回① 従量課金と料金の決まり方（この回のねらい・この講座について・前の回の振り返り・従量課金と料金の決まり方）
86. 第13回② データ転送とストレージの料金（データ転送：受信と送信・データ転送：リージョン内とリージョン間・ストレージの料金）
87. 第13回③ サービスごとの料金と無料利用枠（安いクラスを選ぶときの注意・サービスごとの料金の決まり方・AWS 無料利用枠）
88. 第13回④ オンデマンドとリザーブドインスタンス（購入オプションの全体像・オンデマンドインスタンス・リザーブドインスタンス（RI）・RI の柔軟性・Organizations での割引の共有）
89. 第13回⑤ Savings Plans・スポットと使い分け（Savings Plans・RI と Savings Plans の違い・スポットインスタンス・専有ホストとハードウェア専有インスタンス・キャパシティーの予約・購入オプションの使い分け）
90. 第13回⑥ 見積り・予算・分析の道具（コスト管理の道具の全体像・AWS 料金見積りツール・AWS Budgets・AWS Cost Explorer・AWS Cost and Usage Report）
91. 第13回⑦ タグ・一括請求とコスト改善（コスト配分タグ・AWS Organizations の一括請求・請求と料金の情報・コスト改善の考え方）
92. 第13回⑧ 困ったときの窓口とサポートプラン（困ったときの窓口の全体像・サポートプランの比較・サポートプランと Trusted Advisor のチェック・AWS サポートセンター）
93. 第13回⑨ Trust & Safety・パートナー・Marketplace（AWS Trust & Safety チーム・技術リソース・AWS パートナーネットワーク（APN）・AWS Marketplace・技術支援）
94. 第13回⑩ 第13回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
95. 第14回① 見分け方の表と分野 1（この回のねらい・この講座について・前の回の振り返り・見分け方の表の読み方・分野 1 ①：クラウドの性質と費用・分野 1 ②：設計と移行の考え方）
96. 第14回② 分野 2 の見分け方（分野 2 ①：責任共有モデル・分野 2 ②：アクセスと鍵の管理・分野 2 ③：攻撃からの守りと検出・分野 2 ④：記録・監査・統制）
97. 第14回③ 分野 3 の見分け方（分野 3 ①：インフラと処理の場所・分野 3 ②：ストレージ・データベース・移行・分野 3 ③：ネットワーク・分野 3 ④：連携・分析・AI）
98. 第14回④ 分野 4 の見分け方と5つの問い（分野 4 ①：料金と購入オプション・分野 4 ②：コスト管理とサポート・見分けの5つの問い）
99. 第14回⑤ 条件の言葉と主語（基本から一歩進める・条件の言葉①：運用と費用・条件の言葉②：可用性と性能・条件の言葉③：守りと統制・主語を見る：AWS かお客様か）
100. 第14回⑥ 似た言葉と問題文を読む順（似た言葉の取り違え・名前が似ているサービス・時間の配分と見直し・問題文を読む順）
101. 第14回⑦ 受験の申し込みと本人確認（申し込みから結果までの流れ・テストセンターとオンライン・申し込みの手順・本人確認と身分証明書・持ち物と持ち込めないもの）
102. 第14回⑧ オンライン受験の環境と当日（オンライン受験の環境・予約の変更と取り消し・当日の流れと遅刻・試験の後）
103. 第14回⑨ 第14回のまとめ（各回の見分け方の一覧・この回の要点・全14回を終えたら・参考資料）

AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 CLF）では、責任共有モデルの IT 統制を、「継承された統制」「共有統制」「お客様固有」の3つに分けて見分ける問題が問われます。物理統制・ハイパーバイザー・ゾーンセキュリティのような具体的な統制の名前が、3つのどれに当たるかを答えます。

この記事は、CLF の練習問題を1問ずつ解説する連載の第21問です。問題は筆者が試験の範囲に合わせて作ったもので、実際の試験の問題ではありません。まず自分で答えを選んでから、解説を読んでください。

▶ この回の内容は、YouTube の動画（約5分）でも見られます（記事の最後にも埋め込んであります）。

問題

ある企業は、AWS 責任共有モデルにおける IT 統制の考え方を、社内の監査チームに説明しています。AWS と利用者の双方が、それぞれの範囲で実施する「共有統制」の例として、正しいものはどれですか。

• A. 意識とトレーニング：AWS は AWS の従業員を、利用者は自社の従業員を教育する
• B. ハイパーバイザーの管理：AWS が仮想化レイヤーにパッチを当て、利用者がその設定を変える
• C. ゾーンセキュリティ：特定のセキュリティ環境の中でのデータの経路や区分を、AWS と利用者で分担して決める
• D. 物理統制と環境統制：AWS がデータセンターの電源や空調を管理し、利用者もデータセンターへの入館を管理する

答えを決めたら、下を開いてください。

正解は A

正解は A です。

• 意識とトレーニングは共有統制の例：AWS は AWS の従業員を、利用者は自社の従業員を、それぞれ教育する
• ほかの3つは、AWS だけ、または利用者だけが行うもので、分担はしない

ここから、選択肢を1つずつ見ていきます。

選択肢ごとの解説

A：トレーニングは共有統制（正解）

図の上は、責任共有モデルの IT 統制の3つの分類で、共有統制は真ん中です。共有統制は、同じ統制を、AWS と利用者の両方が、それぞれの範囲で実施するものです。

意識とトレーニングでは、図の左のように、AWS は AWS の従業員を教育します。図の右のように、利用者は自社の従業員を教育します。

B：ハイパーバイザーは AWS だけ（誤り）

ハイパーバイザーは、物理サーバーの上でゲスト OS を動かすための、仮想化レイヤーです。その管理もパッチの適用も、AWS だけが行います。利用者は、その設定に触れることができません。

AWS と利用者が分担するものではないので、共有統制ではありません。

C：ゾーンセキュリティはお客様固有（誤り）

ゾーンセキュリティは、サービスおよび通信の保護と合わせて、お客様固有の統制の例に挙げられています。図の上の、右の分類です。

特定のセキュリティ環境の中で、データの経路や区分を決めるのは、利用者です。デプロイするアプリケーションに基づいて、利用者がすべての責任を負います。AWS と分担するものではありません。

D：物理と環境は継承された統制（誤り）

物理統制と環境統制は、図の上の左、継承された統制です。データセンターの電源や空調、入館の管理は、AWS が行います。利用者は、これらの統制を AWS から完全に継承します。

利用者がデータセンターに入ることはなく、入館を管理することもありません。

共有統制の3つの例

共有統制の3つの例を、AWS の範囲と利用者の範囲に分けて整理します。どれも、同じ統制を、AWS と利用者がそれぞれの範囲で行う形です。

名前は AWS の責任共有モデルの日本語のページの表記です（2026-10-26 に確認）。

ポイント

• 共有統制の例は3つ パッチ管理・構成管理・意識とトレーニング
• 物理統制と環境統制は 継承された統制。利用者は AWS から完全に継承する
• ゾーンセキュリティは お客様固有。ハイパーバイザーは AWS だけ が管理

責任共有モデルの IT 統制の3つの分類と、サービスによる責任の変わり方は、講座の記事で詳しく解説しています。

• 講座の第10回②「責任の分かれ方」（連載の入口のページから）

講座の全14回は、連載の入口のページから順に読めます。

動画で見る

この回の内容を、YouTube の動画（約5分）でも解説しています。

連載の全回は、YouTube の再生リスト「CLF-C02 試験対策問題」にまとめています。

連載「CLF-C02 試験対策問題」

全回の目次と、読む順番・目的別の読み方は、CLF-C02 試験対策問題の入口のページにまとめています。

1. 第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）
2. 第2問 数分でグローバルに展開（世界同時公開と低い遅延）
3. 第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）
4. 第4問 クラウドの俊敏性（数分で作成・すぐに削除）
5. 第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）
6. 第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）
7. 第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）
8. 第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）
9. 第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）
10. 第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）
11. 第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）
12. 第12問 移行のビジネスケース（Migration Evaluator）
13. 第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）
14. 第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）
15. 第15問 ファイルの移行（AWS DataSync）
16. 第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）
17. 第17問 適切なサイズ設定（CPU は余り、メモリが不足）
18. 第18問 責任共有モデル（Lambda と RDS）
19. 第19問 最小権限の原則（IAM のポリシーと SCP）
20. 第20問 責任共有モデル（EC2 と S3、AWS の責任）
21. 第21問 共有統制の例（責任共有モデルの IT 統制）（この記事）
22. 第22問 コンプライアンスの資料と契約（AWS Artifact）
23. 第23問 脅威の検出（Amazon GuardDuty）
24. 第24問 脆弱性の継続的なスキャン（Amazon Inspector）
25. 第25問 S3 の機密データの検出（Amazon Macie）
26. 第26問 S3 の保管時の暗号化とキーの管理
27. 第27問 だれが操作したかを調べる（AWS CloudTrail）
28. 第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）
29. 第29問 EC2 のアプリケーションに権限を与える（IAM ロール）
30. 第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）
31. 第31問 社員に一時的な認証情報を発行するサービス（AWS STS）
32. 第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）
33. 第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）
34. 第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）
35. 第35問 追加料金なしの DDoS 保護（AWS Shield Standard）
36. 第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）
37. 第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）
38. 第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）
39. 第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）
40. 第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）
41. 第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）
42. 第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）
43. 第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）
44. 第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）
45. 第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）
46. 第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）
47. 第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）
48. 第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）
49. 第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）
50. 第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）
51. 第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）
52. 第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）
53. 第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）
54. 第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）
55. 第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）
56. 第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）
57. 第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）
58. 第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）
59. 第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）
60. 第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）
61. 第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）
62. 第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）
63. 第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）
64. 第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）
65. 第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）
66. 第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）
67. 第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）
68. 第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）
69. 第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）
70. 第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）
71. 第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）
72. 第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）
73. 第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）
74. 第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）
75. 第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）
76. 第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）
77. 第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）
78. 第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）
79. 第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）
80. 第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）
81. 第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）
82. 第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）
83. 第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）
84. 第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）
85. 第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）
86. 第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）
87. 第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）
88. 第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）
89. 第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）
90. 第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）
91. 第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）
92. 第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）
93. 第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）
94. 第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）
95. 第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）
96. 第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）
97. 第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）
98. 第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）
99. 第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）
100. 第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）

どちらも、Linuxの中でjournaldとrsyslogがどうログを受け渡しているかを知っていれば、すぐに説明がつきます。

第2回（syslogの基本）では、syslogの形式と転送方式を見ました。第3回では、Linuxの中でログがどのように集められ、ファイルや転送に渡るのかを扱います。第4回・第5回のrsyslogの設定の土台になる回です。

journaldとrsyslogの関係

現在のLinuxでは、ログはまずsystemd-journald（以下journald）に集まります。

• journaldは、カーネル、サービスの標準出力・標準エラー、/dev/logに書かれたsyslogのメッセージを受け取り、サービス名やPIDを付けてバイナリ形式で保存する
• テキストファイルへの書き出しと転送は、rsyslogの担当
• 受け渡しの方法は2つある。1つは、rsyslogのimjournalがジャーナルを直接読む方法で、RHELの既定。もう1つは、journaldのForwardToSyslog=yesで、syslog用のソケットへ流したメッセージをrsyslogのimuxsockが受け取る方法で、Ubuntuの既定

両方を有効にすると、同じログが2回記録されます。冒頭の「2回ずつ記録される」は、このパターンです。

RHELとUbuntuの違い

• Amazon Linux 2023とDebian 12以降は、rsyslogが既定で入っておらず、ログはjournaldにしかない。導入の有無はsystemctl status rsyslogで確かめる
• RHELはjournaldが再起動で消える既定のため、再起動前の調査には、rsyslogが書く/var/log/messagesを使う

冒頭の「再起動前のログが見えない」は、RHELの既定どおりの動きです。

journaldの保存と転送の設定

# RHEL で journald を永続化する（どちらか一方）
$ sudo mkdir -p /var/log/journal && sudo journalctl --flush
$ sudo mkdir -p /etc/systemd/journald.conf.d
$ printf '[Journal]\nStorage=persistent\n' | sudo tee /etc/systemd/journald.conf.d/persistent.conf
$ sudo systemctl restart systemd-journald
# 確かめる
$ journalctl --list-boots        # 過去の起動分が並べば永続化されている
$ systemd-analyze cat-config systemd/journald.conf | grep -E 'Storage|ForwardToSyslog'

• Storage=：auto（/var/log/journalがあれば永続）、persistent、volatile（メモリのみ）。既定値はビルド時に決まり、RHELはメモリ上、Ubuntuは永続
• ForwardToSyslog=：syslog用のソケットへ流すか。RHELはno（imjournalで読むため）。imjournalと両方を使うと、二重に記録される
• ログサーバーへ送るのはrsyslogの役目。journaldにもsystemd-journal-uploadなどの転送の仕組みはあるが、機器やWindowsを含めて集めるなら、syslogが共通語になる（第7回）
• 容量の上限はSystemMaxUse=、古いログの削除はjournalctl --vacuum-time=で行う

journalctlの要点（ログ集約の観点）

$ journalctl -u sshd --since "2026-09-26 09:00" --until "10:00"
$ journalctl -p warning -b                     # 今回の起動以降の warning 以上
$ journalctl -t myapp -n 1 -o short-iso-precise --utc
2026-09-26T08:42:28.476857+00:00 web01 myapp[1276115]: disk usage 91% on /var
$ journalctl -t myapp -n 1 -o json             # 抜粋。実際は1件が1行
{"MESSAGE":"disk usage 91% on /var","PRIORITY":"4","SYSLOG_FACILITY":"16",
 "SYSLOG_IDENTIFIER":"myapp","_PID":"1276115","_HOSTNAME":"web01",
 "_TRANSPORT":"syslog","__REALTIME_TIMESTAMP":"1790412148476874"}

• -u（サービス）、-p（Severity。-p warning..errのように範囲も可）、--since／--until（時刻）を組み合わせて絞る。サービス名は、RHELがsshd、Ubuntuがssh
• -o jsonでは、PRIORITY（Severity）とSYSLOG_FACILITYが数値のまま入り、収集ツールが読みやすい。先頭が_の項目（_PID・_HOSTNAMEなど）はjournaldが付けるもので、送信元のプログラムは偽れない
• --utcでUTCで表示する。複数の機器と突き合わせるときは、時刻の基準をそろえる（連載「NTP入門」第2回）

Windowsで同じことを調べる

PS> Get-WinEvent -LogName System -MaxEvents 1
   ProviderName: Microsoft-Windows-Kernel-General
TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
2026/09/26 17:40:10             16 情報             …（抜粋）
PS> Get-WinEvent -FilterHashtable @{LogName='System'; Level=1,2,3; StartTime=(Get-Date).AddHours(-24)}
PS> Get-WinEvent -LogName Application -MaxEvents 1 |
      Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message | ConvertTo-Json
PS> wevtutil qe System /c:3 /rd:true /f:text

• Windowsには、journaldもsyslogも無く、イベントログ（System・Application・Securityなどのチャネル）に記録される。詳しくは第6回
• -LogNameがjournalctlの対象の指定、-FilterHashtableのLevel（1＝重大〜4＝情報）が-p、StartTime／EndTimeが--since／--untilに当たる
• ConvertTo-Jsonで、-o jsonのように項目付きで出せる。wevtutilは標準のコマンド（/rd:trueで新しい順）。Securityログの読み取りには管理者権限が必要

/var/logの主なファイル

• FacilityとSeverityの組み合わせ（セレクター）でファイルを分けている（第2回）
• RHELのmessagesはauthprivを除くため、SSHのログインはsecureにしかない
• ログサーバーへ転送するときも、同じセレクターで選べる（第5回）
• これらのファイルはrsyslogが書くため、rsyslogの無い環境には存在しない

loggerで試す

ローカルに書く

$ logger -p local0.warning -t myapp "disk usage 91% on /var"
$ tail -n 1 /var/log/syslog                   # Ubuntu（RHEL は /var/log/messages）
2026-09-26T17:42:28.477025+09:00 web01 myapp: disk usage 91% on /var
$ journalctl -t myapp -n 1
Sep 26 17:42:28 web01 myapp[1276115]: disk usage 91% on /var

journaldがPIDを補うため、journalctlには[1276115]が付きますが、rsyslogが書くファイルには付きません（-iを付ければ両方に付きます）。オプションは、すべて半角のハイフンです。資料などからコピーすると、ハイフンがenダッシュ（–）になっていて動かないことがあります。

ログサーバーへ送り、中身を見る

$ logger -n 192.0.2.50 -P 514 -p local0.warning -t myapp "disk usage 91%"
（受信側で見たペイロード）<132>1 2026-09-26T17:41:43.895957+09:00 web01 myapp - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="124747"] disk usage 91%
$ logger -n 192.0.2.50 -P 514 --rfc3164 -p local0.warning -t myapp "disk usage 91%"
（受信側で見たペイロード）<132>Sep 26 17:41:43 web01 myapp: disk usage 91%
$ logger -T -n 192.0.2.50 -P 514 -p local0.err -t myapp "tcp test"   # TCP（-P を省くと 601 番）
PS> $udp = New-Object System.Net.Sockets.UdpClient
PS> $b = [Text.Encoding]::UTF8.GetBytes("<134>1 2026-09-26T17:41:43+09:00 pc01 test - - - hello from Windows")
PS> $udp.Send($b, $b.Length, "192.0.2.50", 514)
67
PS> $udp.Close()
PS> Test-NetConnection 192.0.2.50 -Port 6514      # TCP だけ確かめられる

• -nを付けると、既定でRFC 5424形式・UDPで送る。UDPで送れないときだけTCPを試す
• 受信側では、sudo tcpdump -i ens192 -n -A udp port 514でペイロードを見て、PRIと形式を確かめる（第10回）
• Windowsにはloggerが無いが、PowerShellから.NETのUdpClientで1行送れる（67は送ったバイト数）。Test-NetConnectionはTCPしか確かめられない。UDPは、受信側で届いたかを見る

logrotate：ログサーバーでの注意

# /etc/logrotate.d/remote（送信元ごとのディレクトリに書く場合の例）
/var/log/remote/*/*.log {
    daily
    rotate 400
    dateext
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
    endscript
}

• rsyslogはHUPを受けると、書き込み中のファイルを閉じ、次の書き込みで開き直す
• ファイルが大量になる：送信元ごと・種類ごとに分けると数千ファイルになる。ワイルドカードで1つの設定にまとめ、sharedscriptsでHUPを1回にする
• 圧縮：テキストのログは圧縮がよく効く。delaycompressで直前の世代は圧縮せず残し、書き込みの取りこぼしに備える
• 保存期間：rotate 400は日次で約13か月（PCI DSSの12か月に余裕を持たせた例。第1回（ログとは・なぜ集めるか））。世代数は規程の保存期間から逆算し、ディスクの容量を見積もる（第7回）
• ファイル名に日付を入れて書く方式（rsyslogのテンプレート。第5回）なら切り替えは不要で、古いファイルを消すだけでよい

auditdとの違い

syslogのログは、プログラムが「自分は何をしたか」を申告したもので、logger -p auth.infoのように誰でも任意のFacilityで書き込めます。auditdはカーネルが記録するため詐称に強く、PCI DSSの「管理者の操作」「重要なファイルへのアクセス」の証跡に向いています。監査ログも、集約先へ送って保管します。

考えてみよう

1. 担当のRHELサーバーでjournalctl --list-bootsを実行すると、前回の起動分は見えますか。見えない場合、再起動前の障害はどこで調べますか。
2. rsyslogのimjournalと、journaldのForwardToSyslogが両方とも有効になっていたら、何が起きますか。どうやって確かめますか。
3. 一般ユーザーでlogger -p auth.info -t sshd "Accepted password for root"と打つと、何が記録されますか。このことから、syslogのログを証跡として使うときの注意を説明してください。

ヒント：この記事のRHELとUbuntuの違いの表、journaldの設定のsystemd-analyze cat-config、「自己申告」と「カーネルが記録」の図が手がかりです。

まとめ

• ログはまずjournaldに集まり、ファイルへの書き出しと転送はrsyslogが担う
• 受け渡しはimjournal（RHEL）かForwardToSyslog（Ubuntu）のどちらか。両方だと二重に記録される
• RHELのjournaldは再起動で消える既定。Amazon Linux 2023・Debian 12以降はrsyslogが無い
• journalctl -o jsonの先頭が_の項目は、送信元が偽れない
• logger -n … -P …で送り、受信側のtcpdumpでPRIと形式を確かめる
• ログサーバーのlogrotateは、ワイルドカードとsharedscripts、保存期間から世代数を逆算
• syslogは自己申告。証跡にはauditdも集める

次回は、rsyslogでログを受信・転送し、キューで欠損を防ぐ設定を扱います（前編）。

連載「syslog入門」全11回

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

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

どちらも、syslogの形式と運び方を知っていれば、原因と対策が見えてくる話です。

第1回（ログとは・なぜ集めるか）では、なぜログを集めるのかを見ました。第2回では、ログを集める共通の仕組みであるsyslogの、メッセージの形式と転送方式を扱います。

syslogの歴史

syslogは、1980年代にBSD UNIXの開発の中で、Eric Allmanがメール配送ソフトのsendmailのために作ったログの仕組みが始まりです。やがてUNIX系のOS全般とネットワーク機器へ広がりました。

• 長い間、仕様書のない「事実上の標準」で、実装ごとに少しずつ違っていた
• 2001年のRFC 3164は、既存の実装の動きを観察して記録したもので、標準ではなくInformational（情報提供）という位置づけ
• 2009年に、形式を定めるRFC 5424と、運び方を定めるRFC 5425（TLS）・5426（UDP）などが標準として公開され、RFC 3164は廃止（Obsolete）された

それでも、今も多くの機器が3164に近い形式で送るため、集める側は両方の形式を読めなければなりません。

syslogに関するRFC

RFC 9662（2024年10月）で、TLS・DTLSの必須の暗号スイートに、前方秘匿性のあるTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256が加わり、DTLSは1.2が必須になりました（前方秘匿性は連載「証明書入門」第2回）。

Facility：どこから来たログか

syslogのメッセージには、「どこから来たか」を表すFacilityと、「どれくらい重要か」を表すSeverityが付きます。

名前はOSや実装によって異なり、上の表はrsyslog 8.2512で表示を確かめたものです。local0〜7は「local4はファイアウォール、local5はESXi」のように、組織内で割り当てを決めて台帳に残すと、振り分け（第5回）が楽になります。

Severity：どれくらい重要か

• 値が小さいほど重要。journalctl -p（第3回）や、rsyslogの比較（$syslogseverity <= 4、第5回）もこの値を使う
• WindowsのイベントのLevelは1＝重大〜5＝詳細で、並びが違うため、変換に注意する（第6回）
• どのSeverityを付けるかは作者が決めるので、一律に切らない（第1回）

PRIの計算

syslogのメッセージの先頭にある<132>のような数字がPRI（Priority value）で、FacilityとSeverityを1つにまとめたものです。

• 計算式は「Facility × 8 ＋ Severity」。Severityは0〜7の8通りなので重ならない。例えばlocal0（16）のwarning（4）は16 × 8 ＋ 4 ＝ 132
• 戻すには8で割る。<134>なら134 ÷ 8 ＝ 16 余り 6で、local0.info
• PRIはパケットの先頭にあるので、tcpdumpで見れば、どのFacility・Severityで届いたかが分かる（第10回）。一方、ファイルに書かれたログにはPRIが残らないのが普通で、確かめるにはテンプレートで出力させる（第5回）

RFC 3164（BSD形式）の形式

<132>Sep 26 17:41:43 web01 myapp: disk usage 91%
<86>Jul  6 08:05:12 web01 sshd[1234]: Accepted publickey for alice from 192.0.2.21 port 50522 ssh2

• 3つの部分からなる：PRI（<132>）、HEADER（TIMESTAMPとHOSTNAME）、MSG（TAGとCONTENT）。1行目はlogger --rfc3164で送り、受信側で見た実物
• TIMESTAMPはMmm dd hh:mm:ssの現地時刻で、年とタイムゾーンが無い。日が1桁なら0ではなく空白で埋める（Jul 6、空白2つ）
• HOSTNAMEはドメインを付けない名前かIPアドレス。TAGはプログラム名で32文字以内、慣例で[PID]を付け、: の後にCONTENTが続く
• パケット全体は1024バイト以下（RFC 3164 4.1）。ただし実際の機器はこの形式から少しずつ外れることが多く、受信側は推測しながら解釈している

RFC 5424の形式

<132>1 2026-09-26T17:41:43.895957+09:00 web01 myapp - - [timeQuality tzKnown="1" isSynced="1" syncAccuracy="124747"] disk usage 91%

値の無い項目は-（NILVALUE）で埋めるため、項目の数と順番は常に同じです。TIMESTAMPの時は2桁で、2020-07-16T8:17:45Zではなく2020-07-16T08:17:45Zが正しい形です。上の例はlogger --rfc5424で送り、受信側で見た実物です。

構造化データとMSG

<37>1 2026-09-26T17:41:43.899752+09:00 web01 myapp - LOGIN [timeQuality tzKnown="1" isSynced="1" syncAccuracy="124747"][auth@32473 user="alice"] login ok
2026-09-18T08:08:07.478788+09:00 web01 rsyslogd: [origin software="rsyslogd" swVersion="8.2512.0" x-pid="1445" x-info="https://www.rsyslog.com"] start

• 構造化データは[SD-ID 名前="値" …]の形で、機械が読みやすいキーと値を載せる。いくつも並べられ、無ければ-
• SD-IDは、IANA登録の名前（timeQuality・originなど）か、名前@企業番号（auth@32473。32473は文書用）。1つ目は、loggerの--msgid・--sd-id・--sd-paramで付けた例
• timeQualityは時刻の品質（isSynced="1"は同期済み、syncAccuracyは誤差の上限でマイクロ秒）で、loggerが自動で付ける。2つ目は、rsyslogd自身の起動メッセージ
• MSGはUTF-8なら先頭にBOM（EF BB BF）を付けると定めるが、付けない実装が多い（loggerも付けない）。受信側はどちらにも備える

RFC 3164とRFC 5424の比較

• 3164しか解釈できない受信側に5424形式を送っても、PRIで振り分けられ、残りは文字列として保存される（日付の前にVERSIONの1が紛れ込む）
• 逆に3164形式には年とタイムゾーンが無く、受信側が自分の年とタイムゾーンで補うため、両者のタイムゾーンが違うと時刻がずれる（第7回、連載「NTP入門」第2回）

冒頭の「ネットワーク機器のログだけ9時間ずれる」は、この典型です。機器がUTCの時刻を3164形式で送り、JSTのログサーバーが「JSTの時刻」として補っているのです。

メッセージ長

480と1180は、IPv4の576・IPv6の1280オクテットという最小のMTUをもとに、断片化せずに届く大きさとして決めたと、RFC 5426に明記されています。実際の上限は実装と設定で決まります（rsyslogの既定は8k。global(maxMessageSize="64k")などで変更）。長いログは途中で切れるため、送受信の設定をそろえます。

転送方式

logger -T（TCP）は、ポートを指定しないと601/tcp（syslog-conn、RFC 3195）に送ろうとします。手元のUbuntu 26.04では、この名前を解決できずにエラーになりました。TCPで試すときは、-P 514のようにポートを必ず指定します（第3回）。

到達保証と暗号化は別のもの

冒頭の「TLSにしたから取りこぼさない」への答えです。

• 転送方式は、「届いたことを保証したい（到達保証）」と「盗み見・改ざんを防ぎたい（暗号化）」を分けて考える
• よくある誤解が「TCPやTLSにすればログは失われない」。TCPの確認応答は、相手のOSが受け取ったことを示すだけで、ログサーバーが処理してディスクに書いたことは示さない。接続が切れた瞬間に送信側のOSに残っていた未確認のデータは、アプリケーションに知らされないまま失われる
• TLSはこれに暗号化と相手の認証を加えるだけで、到達についてはTCPと同じ（RFC 5425も、TLSが守るのは区間ごとの通信だとしている）
• アプリケーションの層で「処理しました」と応答し、切断時に未確認の分を送り直すのがRELP

ポイント
到達保証はRELP、暗号化はTLS。両方ほしければRELP over TLS。送り先の停止に備え、ディスクのキュー（第4回）と組み合わせる。

考えてみよう

1. <86>と<190>は、それぞれどのFacility・Severityですか。自分の担当機器のログが、どのFacilityで送られているか説明できますか。
2. ネットワーク機器からRFC 3164形式で届いたログを、別のタイムゾーンで動いているログサーバーで受けると、時刻はどう記録されますか。
3. 「ログの欠損を防ぎたいのでTLSにしたい」と相談されたら、何と答えますか。

ヒント：この記事のPRIの計算、RFC 3164と5424の比較表の「時刻」の行、「到達保証と暗号化は別のもの」の図が手がかりです。

まとめ

• syslogは1980年代生まれ。RFC 3164は既存の記録、RFC 5424が標準。今も3164形式の機器は多い
• Facilityは「どこから」、Severityは「どれくらい重要か」（小さいほど重要）
• PRI＝Facility×8＋Severity。ファイルには残らないので、パケットかテンプレートで確かめる
• 3164は年・タイムゾーンが無く、受信側が補う。5424は項目の数と順番が決まっている
• 長いログは切れる。送受信の長さの設定をそろえる
• UDPは欠損に気付けない。到達保証はRELP、暗号化はTLS

次回は、Linuxの中でログがどのように集められ、ファイルや転送に渡るのか（journaldとrsyslog）を扱います。

連載「syslog入門」全11回

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

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

AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 CLF）では、EC2 と S3 を使う場面で、AWS が責任を負う項目（クラウド「の」セキュリティ）を見分ける問題がよく出ます。物理的な機器とネットワークは AWS、データと権限の設定は利用者、という境目が決め手です。

この記事は、CLF の練習問題を1問ずつ解説する連載の第20問です。問題は筆者が試験の範囲に合わせて作ったもので、実際の試験の問題ではありません。まず自分で答えを選んでから、解説を読んでください。

▶ この回の内容は、YouTube の動画（約5分）でも見られます（記事の最後にも埋め込んであります）。

問題

ある企業は、Amazon EC2 インスタンスでウェブアプリケーションを動かし、利用者がアップロードした画像を Amazon S3 に保存しています。AWS 責任共有モデルにおいて、AWS が責任を負う項目はどれですか。（2つ選択）

• A. EC2 インスタンスが動く物理サーバーの、故障した部品の交換
• B. S3 に保存する画像のうち、個人情報を含むものの分類
• C. EC2 インスタンスで動くウェブサーバーのソフトウェアの更新
• D. アベイラビリティーゾーンの間を結ぶネットワーク機器の運用
• E. S3 バケットへのパブリックアクセスをブロックする設定

答えを2つ決めたら、下を開いてください。

正解は A と D

正解は A と D です。

• A：物理サーバーは、AWS のサービスを動かすインフラ
• D：アベイラビリティーゾーンを結ぶネットワークも、AWS のサービスを動かすインフラ

インフラを守るのは、AWS の責任です。ほかの3つは、データの分類、ソフトウェアの更新、アクセス権限の設定で、利用者の責任です。ここから、選択肢を1つずつ見ていきます。

選択肢ごとの解説

A：物理サーバーの保守は AWS（正解）

図の左は、EC2 と S3 の責任の分かれ目を、層に分けた図です。青が利用者、橙が AWS の責任です。

EC2 インスタンスが動く物理サーバーは、AWS のデータセンターにあるハードウェアです。故障した部品の交換などの保守は、AWS が行います。ハードウェアは、クラウド「の」セキュリティで、AWS の責任です。利用者は、物理サーバーに触れることができません。

B：データの分類は利用者（誤り）

S3 に保存する画像のうち、どれが個人情報を含むかは、利用者にしか分かりません。保存するデータの分類は、利用者の責任です。S3 のように、AWS が多くを管理するサービスでも、データの管理は利用者が行います。

C：EC2 のソフトの更新は利用者（誤り）

EC2 では、ゲスト OS と、利用者が入れたアプリケーションは、利用者が管理します。ウェブサーバーのソフトウェアの更新や、パッチの適用も、利用者が行います。

一方、図の S3 の列では、OS やプラットフォームも AWS が管理します。責任の分かれ目は、サービスによって変わります。

D：AZ を結ぶネットワークは AWS（正解）

図の右のように、リージョンの中には、複数のアベイラビリティーゾーンがあり、ネットワークで結ばれています。このネットワークは、AWS のサービスを動かすインフラの一部です。

ネットワーク機器の運用は、AWS が行います。利用者が機器に触れることはありません。

E：公開の設定は利用者（誤り）

S3 バケットを公開するかどうかは、利用者が決めることです。パブリックアクセスをブロックする機能は AWS が用意しますが、設定するのは利用者です。これは、アクセス権限の設定で、利用者の責任です。

AWS と利用者の責任

AWS の責任は、クラウド「の」セキュリティです。サービスを動かすインフラ、つまり、ハードウェア・ソフトウェア・ネットワーキング・施設を守ります。ここでのソフトウェアは、AWS のサービスを動かすソフトウェアのことです。

利用者の責任は、クラウド「における」セキュリティです。データ、アクセス権限、そして EC2 では、ゲスト OS とアプリケーションです。

ポイント

• 物理サーバー・AZ を結ぶネットワーク・施設は クラウド「の」セキュリティ＝AWS
• データの分類・バケットの公開設定は どのサービスでも利用者
• EC2 の ゲスト OS とアプリは利用者。S3 は OS・プラットフォームも AWS

責任共有モデルの境目と、AZ とリージョンの関係は、講座の記事で詳しく解説しています。

• 講座の第10回②「責任の分かれ方」（連載の入口のページから）
• 【AWS クラウドプラクティショナー試験対策講座 第03回②】グローバルインフラ

講座の全14回は、連載の入口のページから順に読めます。

動画で見る

この回の内容を、YouTube の動画（約5分）でも解説しています。

連載の全回は、YouTube の再生リスト「CLF-C02 試験対策問題」にまとめています。

連載「CLF-C02 試験対策問題」

全回の目次と、読む順番・目的別の読み方は、CLF-C02 試験対策問題の入口のページにまとめています。

1. 第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）
2. 第2問 数分でグローバルに展開（世界同時公開と低い遅延）
3. 第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）
4. 第4問 クラウドの俊敏性（数分で作成・すぐに削除）
5. 第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）
6. 第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）
7. 第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）
8. 第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）
9. 第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）
10. 第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）
11. 第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）
12. 第12問 移行のビジネスケース（Migration Evaluator）
13. 第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）
14. 第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）
15. 第15問 ファイルの移行（AWS DataSync）
16. 第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）
17. 第17問 適切なサイズ設定（CPU は余り、メモリが不足）
18. 第18問 責任共有モデル（Lambda と RDS）
19. 第19問 最小権限の原則（IAM のポリシーと SCP）
20. 第20問 責任共有モデル（EC2 と S3、AWS の責任）（この記事）
21. 第21問 共有統制の例（責任共有モデルの IT 統制）
22. 第22問 コンプライアンスの資料と契約（AWS Artifact）
23. 第23問 脅威の検出（Amazon GuardDuty）
24. 第24問 脆弱性の継続的なスキャン（Amazon Inspector）
25. 第25問 S3 の機密データの検出（Amazon Macie）
26. 第26問 S3 の保管時の暗号化とキーの管理
27. 第27問 だれが操作したかを調べる（AWS CloudTrail）
28. 第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）
29. 第29問 EC2 のアプリケーションに権限を与える（IAM ロール）
30. 第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）
31. 第31問 社員に一時的な認証情報を発行するサービス（AWS STS）
32. 第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）
33. 第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）
34. 第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）
35. 第35問 追加料金なしの DDoS 保護（AWS Shield Standard）
36. 第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）
37. 第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）
38. 第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）
39. 第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）
40. 第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）
41. 第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）
42. 第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）
43. 第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）
44. 第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）
45. 第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）
46. 第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）
47. 第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）
48. 第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）
49. 第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）
50. 第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）
51. 第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）
52. 第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）
53. 第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）
54. 第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）
55. 第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）
56. 第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）
57. 第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）
58. 第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）
59. 第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）
60. 第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）
61. 第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）
62. 第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）
63. 第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）
64. 第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）
65. 第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）
66. 第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）
67. 第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）
68. 第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）
69. 第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）
70. 第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）
71. 第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）
72. 第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）
73. 第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）
74. 第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）
75. 第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）
76. 第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）
77. 第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）
78. 第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）
79. 第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）
80. 第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）
81. 第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）
82. 第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）
83. 第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）
84. 第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）
85. 第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）
86. 第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）
87. 第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）
88. 第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）
89. 第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）
90. 第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）
91. 第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）
92. 第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）
93. 第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）
94. 第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）
95. 第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）
96. 第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）
97. 第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）
98. 第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）
99. 第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）
100. 第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）

どちらも、EC2 を学び始めた人から出やすい質問です。答えは、1つ目は 「OS の更新と設定、入れたアプリケーション、データ、通信を通すか止めるかを決める仮想のファイアウォール（セキュリティグループ）の設定は、お客様が扱う。AWS が扱うのは、データセンターの建物、物理サーバー、仮想化の層」、2つ目は 「名前の細かい部分ではなく、まずファミリー（得意なことで分けた系統）ごとの用途を押さえる。名前の先頭の英字は、系統の目印」 です。この記事では、その根拠を順に見ていきます。

この記事は、AWS クラウドプラクティショナー試験対策講座（AWS Certified Cloud Practitioner、試験コード CLF-C02。以下 CLF）の第04回②です。試験ガイドのタスク 3.3（AWS のコンピューティングサービスを特定する）のうち、Amazon EC2 とインスタンスタイプを扱います。なお、この連載は AWS の公式の資料ではありません。試験の情報は2026年10月26日時点のもので、変わることがあるので、受験の前に AWS の公式ページで確かめてください。

Amazon EC2 とは ◎

第04回①の「AWS のコンピューティングの全体像」の節で見た4つの方法のうち、1つめの「借りる」にあたるのが Amazon EC2 です。

Amazon Elastic Compute Cloud（Amazon EC2） は、仮想サーバーを、必要なときに必要な数だけ借りられるサービスです。借りた1台1台の仮想サーバーを「インスタンス」と呼びます。

物理サーバーを買って置く必要はなく、使い始めるのも、やめるのも、自分の都合で決められます。OS は、Linux や Windows などから選べます。

たとえば、ある EC サイト（インターネットで商品を売るサイト）の会社が、Web サイトを動かすサーバーを EC2 で用意する、といった使い方ができます。

料金は、使った分に応じて払う形が基本です。購入の方法の違いは、第13回④の「購入オプションの全体像」の節から⑤にかけて扱います。

• EC2 は仮想サーバー（インスタンス）を借りるサービス
• 必要な数・大きさを、必要なときに用意できる
• 購入の方法の違いは第13回④⑤で扱う

EC2 のユースケース

EC2 は、どんな用途に向くのでしょうか。ある EC サイトの会社の例で、表にまとめます。

補足：表の例は、EC2 の使い方の一例として自分の言葉で書いたものです。AWS の製品ページは、このほかに機械学習や macOS のアプリのビルド・テストなども挙げています（2026年10月26日時点）。

出典：Amazon EC2

EC2 でお客様が扱う範囲 ◎

EC2 では、仮想サーバーを借りる代わりに、その中身の管理はお客様の仕事になります。

AWS が扱うのは、データセンターの建物、物理サーバー、仮想化の層です。

その上の次のものは、お客様が扱います。

• OS の更新（セキュリティパッチを含む）と設定
• 入れたアプリケーション
• データ
• 通信を通すか止めるかを決める仮想のファイアウォール（セキュリティグループ。第06回③の「セキュリティグループ」の節で扱います）の設定

一方で、AWS Lambda（第04回④）のように、実行環境（OS と、プログラムを動かすためのソフトウェアであるランタイム）を AWS が管理するサービスもあります。

この役割分担の全体は責任共有モデルと呼ばれ、第10回①の「責任共有モデルとは」の節と、第10回②の「サービスで変わる責任」の節で扱います。

• AWS は建物・物理サーバー・仮想化を扱う
• お客様は OS の更新・アプリ・データを扱う
• 役割分担の全体は第10回①②で扱う

冒頭の1つ目の相談がこれです。OS の更新も、お客様の仕事です。第04回①の「コンピューティングとサーバー」の節で見たサーバーの3段のうち、ハードウェアと仮想化の部分は AWS が、OS から上はお客様が受け持ちます。

出典：AWS 責任共有モデル

インスタンスタイプとは ◎

インスタンスタイプとは、インスタンスに割り当てる CPU・メモリ・ストレージ・ネットワークの組み合わせの型です。用途に合う型を選んで起動し、あとから変えることもできます（変えるには条件があります）。

型の名前には決まりがあります。たとえば「m7g.large」なら、次のように読みます。

• 先頭の英字 m：系統の目印。m は汎用を表す
• 次の数字 7：世代
• 続く英字 g：追加の特徴
• ドットの後ろの large：大きさ

試験では、まずファミリー（インスタンスタイプのファミリー、またはインスタンスファミリー。得意なことで分けた系統）ごとの用途を押さえます。次の節で、ファミリーの一覧を見ます。なお、AWS の文書では、「m7g」のような名前の部分そのものをファミリーと呼ぶこともあります。この講座では、得意なことで分けた系統（汎用など）をファミリーと呼びます。

• インスタンスタイプは CPU・メモリなどの組み合わせの型
• 用途に合う型を選び、あとから変えられる
• 名前の先頭の英字は系統の目印。まず用途を押さえる

冒頭の2つ目の相談がこれです。名前を全部覚える必要はなく、まずは「先頭の英字が系統の目印」「ファミリーごとの用途」を押さえます。

インスタンスタイプのファミリー ◎

ファミリーは、得意なことで分けた系統です。6つあります。

補足：HPC はハイパフォーマンスコンピューティング（大規模な計算を高速に行うこと）です。一覧は変わることがあります（2026年10月26日時点）。

出典：Amazon EC2 インスタンスタイプ

ファミリーの選び方

用途からファミリーを選ぶ練習をします。ある EC サイトの会社の例です。

補足：大きさの見直し（適切なサイジング）の考え方は第02回③の「適切なサイジング」の節、見直しに使うツール（AWS Compute Optimizer）は第09回⑤の「AWS Compute Optimizer」の節で扱います。購入の方法は第13回④⑤です。HPC 最適化は特別な大規模計算向けなので、この表では省きました。

EC2 を起動するときに選ぶもの ○

EC2 でインスタンスを起動するときに選ぶ主な項目から、名前を押さえたい6つを挙げます。

⑤のセキュリティグループは、起動の画面ではネットワーク設定の中で選びます（④は第06回②の「Amazon VPC とは」の節、⑤は第06回③の「セキュリティグループ」の節）。⑥のストレージは、Amazon Elastic Block Store（Amazon EBS）などを選びます（第05回②の「Amazon EBS」の節）。インスタンスを置く AZ も、④のネットワークの設定の中で決まります（どのサブネットに置くかで決まる。第06回②の「サブネット」の節）。複数の AZ に分けて起動すると1つの AZ の障害に備えられる、という考え方は、第03回③の「AZ の使い方はサービスで違う」の節で見ました。

これは操作の手順ではなく、選ぶものの地図です。

• 起動のときに選ぶ主な項目は6つ
• OS のひな形（AMI）と型（インスタンスタイプ）から始める
• ネットワークは第06回②（VPC とサブネット）・③（セキュリティグループとネットワーク ACL）、ストレージは第05回②（EBS とインスタンスストア）で扱う

キーペアとログイン

③のキーペアは、プライベートキーとパブリックキーの組です。インスタンスを起動すると、パブリックキーがインスタンスの中に置かれます。Linux のインスタンスに SSH でログインするときは、手元に保管したプライベートキーを指定します。

プライベートキーのファイルをダウンロードできるのは、キーペアを作ったときの1回だけです。EC2 はコピーを持たないので、なくしても取り戻せません。

試験のポイント：「Linux の EC2 に SSH でログインする」→ キーペアのプライベートキー。「パブリックキー」はインスタンスの中に置かれる側。

出典（2026年11月3日時点）：Amazon EC2 ユーザーガイド（Amazon EC2 のキーペア）

考えてみよう

1. EC2 でインスタンスを借りたとき、AWS が扱う範囲とお客様が扱う範囲を、「物理サーバー・仮想化」「OS」「アプリケーション・データ」の3段を使って説明してみてください。セキュリティグループの設定がどちらの仕事かも言ってみてください
2. 「m7g.large」の名前を、「系統の目印・世代・追加の特徴・大きさ」の4つに分けて読んでみてください。また、試験でまず押さえるのは何かも説明してみてください
3. ある EC サイトの会社が、「商品画像の認識」と「大量のログの読み書き」を EC2 で動かすとします。どのファミリーを選ぶか、理由も添えて説明してみてください

ヒント：1 は「EC2 でお客様が扱う範囲」の節、2 は「インスタンスタイプとは」の節、3 は「ファミリーの選び方」の節を見直してください。

まとめ

• Amazon EC2 は、仮想サーバーを必要なときに必要な数だけ借りられるサービス。借りた1台1台がインスタンス。OS は Linux や Windows などから選べ、料金は使った分に応じて払う形が基本
• EC2 の用途は、Web サイトのサーバー・業務アプリケーション・開発・テストの環境・計算の多い処理など
• OS の更新と設定・アプリケーション・データ・セキュリティグループの設定はお客様、建物・物理サーバー・仮想化は AWS が扱う。役割分担の全体は責任共有モデル（第10回①②）
• インスタンスタイプは CPU・メモリ・ストレージ・ネットワークの組み合わせの型。「m7g.large」は、系統の目印（m は汎用）・世代（7）・追加の特徴（g）・大きさ（large）の順に読む
• ファミリーは6つ。汎用・コンピューティング最適化・メモリ最適化・ストレージ最適化・高速コンピューティング・HPC 最適化。まず用途を押さえる
• 起動のときに選ぶ主な項目は、AMI・インスタンスタイプ・キーペア・ネットワーク・セキュリティグループ・ストレージの6つ
• キーペアはプライベートキーとパブリックキーの組。SSH のログインにはプライベートキーを使い、なくしても取り戻せない

次は、第04回③で、ELB と Auto Scaling を扱います。

連載「AWS クラウドプラクティショナー試験対策講座」

全回の目次と、読む順番・目的別の読み方は、AWS クラウドプラクティショナー試験対策講座の入口のページにまとめています。

1. 第01回① CLF はどんな資格か（AWS 認定のレベル・CLF の位置づけ・誰向けか・問われること／問われないこと・身につくもの）
2. 第01回② 試験の形式と合格基準（試験の基本情報・2種類の設問・採点される50問・換算スコアと合格点・補整型・結果・受験の流れ・再受験と有効期間）
3. 第01回③ 出題の範囲と配点（4つの分野と配点・試験ガイドの組み立て・分野ごとのタスク・配点と学ぶ量・対象外のサービス）
4. 第01回④ 講座の進め方と学び方（全14回の地図・深さの印・学び方の輪・公式の学習リソース・AWS を触るときの注意・問題文の読み方・早見表）
5. 第02回① クラウドとは（3つの特徴・オンプレミスとの違い・使い始めるまでの速さ・IaaS／PaaS／SaaS・デプロイモデルと選び方）
6. 第02回② AWS クラウドの利点（価値提案・6つのメリット・高可用性・伸縮性・俊敏性・例で見分ける）
7. 第02回③ クラウドエコノミクス（固定費と変動費・オンプレミスのコスト・総保有コスト・規模の経済・適切なサイジング・BYOL・オートメーション）
8. 第02回④ 第02回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
9. 第03回① サービスの全体像（この回のねらい・この講座について・前の回の振り返り・サービスの集まり・カテゴリ・カテゴリと講座の回）
10. 第03回② グローバルインフラ（リージョン・AZ・エッジロケーション・3つの関係と比較・Local Zones・Outposts）
11. 第03回③ 高可用性と複数リージョン（単一障害点・複数 AZ・サービスごとの AZ・複数リージョンの理由・リージョンの選び方）
12. 第03回④ AWS へのアクセス方法（API・コンソール・CLI・SDK・IaC・CloudFormation・1回限りと繰り返す作業）
13. 第03回⑤ 第03回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
14. 第04回① サーバーと仮想マシン（この回のねらい・この講座について・前の回の振り返り・コンピューティングとサーバー・仮想マシン・コンピューティングの全体像）
15. 第04回② Amazon EC2（EC2 とは・ユースケース・お客様が扱う範囲・インスタンスタイプ・ファミリーと選び方・起動するときに選ぶもの）（この記事）
16. 第04回③ ELB と Auto Scaling（1台のサーバーの限界・垂直と水平のスケーリング・ロードバランサーの目的・ELB とその種類・Auto Scaling・組み合わせ）
17. 第04回④ サーバーレス（サーバーレスとは・AWS Lambda とその特徴・ユースケース・Amazon API Gateway・EC2 と Lambda の違い）
18. 第04回⑤ コンテナーとほかの選択肢（コンテナーとは・3つの役割・ECR・ECS と EKS・Fargate・Elastic Beanstalk・Lightsail・Batch）
19. 第04回⑥ 第04回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
20. 第05回① ストレージの種類（この回のねらい・この講座について・前の回の振り返り・ストレージとは・ブロック・ファイル・オブジェクト・3つの種類の比べ方・AWS のストレージの地図）
21. 第05回② EBS とインスタンスストア（Amazon EBS・AZ の中でのレプリケート・スナップショット・EBS の暗号化・インスタンスストア・2つの違い）
22. 第05回③ Amazon S3 とストレージクラス（S3 とは・S3 の特徴・ユースケース・ストレージクラスの考え方・ストレージクラスの一覧）
23. 第05回④ Glacier とライフサイクル（S3 Glacier のクラス・クラスの選び方・ライフサイクルポリシー・ライフサイクルのユースケース・S3 のセキュリティ）
24. 第05回⑤ ファイルとハイブリッド（Amazon EFS・Amazon FSx・ハイブリッドクラウドとストレージ・AWS Storage Gateway・Storage Gateway の種類）
25. 第05回⑥ バックアップと災害対策（バックアップと災害対策の違い・AWS Backup・ユースケース・AWS Elastic Disaster Recovery・データを守る仕組みの重ね方）
26. 第05回⑦ 第05回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
27. 第06回① ネットワークの基本（この回のねらい・この講座について・前の回の振り返り・IP アドレスとネットワークの範囲・ルーティングとゲートウェイ・ポートとプロトコル・この回のサービスの地図）
28. 第06回② VPC とサブネット（Amazon VPC とは・サブネット・パブリックサブネットとプライベートサブネット・インターネットゲートウェイ・NAT ゲートウェイ・ルートテーブル）
29. 第06回③ セキュリティグループとネットワーク ACL（セキュリティグループ・ネットワーク ACL・2つの違い・VPC フローログ・VPC の全体を見る）
30. 第06回④ VPC の外とつなぐ（つなぐ先は3つ・AWS Transit Gateway・AWS PrivateLink・オンプレミスとつなぐ方法）
31. 第06回⑤ VPN と Direct Connect（AWS Site-to-Site VPN・AWS Client VPN・AWS Direct Connect・VPN と Direct Connect の比べ方）
32. 第06回⑥ DNS と Route 53（DNS とドメイン名・Amazon Route 53・Route 53 のルーティングの方法）
33. 第06回⑦ CloudFront と Global Accelerator（エッジロケーションとキャッシュ・Amazon CloudFront・CloudFront の使いどころ・AWS Global Accelerator・CloudFront と Global Accelerator の違い）
34. 第06回⑧ 第06回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
35. 第07回① データベースとは（この回のねらい・この講座について・前の回の振り返り・データベースとは・テーブル・行・列・SQL とは）
36. 第07回② データベースの種類（リレーショナルデータベース・NoSQL データベース・インメモリデータベース・3つの種類の比べ方・EC サイトで使い分けると）
37. 第07回③ 自分で運用か任せるか（データベースを動かすのに要る作業・EC2 上のデータベース・マネージドデータベース・作業の分担の比べ方・使い分けの考え方）
38. 第07回④ RDS とマルチ AZ 配置（Amazon RDS とは・RDS で選べるエンジン・RDS で AWS が引き受けること・マルチ AZ 配置・フェイルオーバー）
39. 第07回⑤ リードレプリカと Aurora（リードレプリカ・マルチ AZ 配置とリードレプリカの違い・Amazon Aurora・RDS と Aurora の関係）
40. 第07回⑥ Amazon DynamoDB（DynamoDB とは・DynamoDB の特長・DynamoDB のテーブル・DynamoDB と RDS の違い）
41. 第07回⑦ ElastiCache・DocumentDB・Neptune（Amazon ElastiCache・キャッシュの置き方・Amazon DocumentDB・Amazon Neptune・ほかの回で扱う DB の話題）
42. 第07回⑧ 第07回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
43. 第08回① 疎結合とつなぎ方の言葉（この回のねらい・この講座について・前の回の振り返り・疎結合とは・つなぎ方の言葉）
44. 第08回② SQS と SNS（Amazon SQS の仕組み・SQS の使いどころ・Amazon SNS の仕組み・SNS の使いどころ）
45. 第08回③ EventBridge と Step Functions（Amazon EventBridge の仕組み・EventBridge の使いどころ・AWS Step Functions の仕組み・Step Functions の使いどころ・SNS・SQS・EventBridge の使い分け・メッセージと通知のサービスを選ぶ）
46. 第08回④ AI と機械学習のサービス（AI と機械学習の言葉・AI/ML のサービスの全体像・画像・文書・文章のサービス・音声と会話のサービス・生成 AI のサービス）
47. 第08回⑤ データ分析のサービス（データ分析の流れ・集める・加工するサービス・分析・見える化のサービス・Athena・Redshift・EMR の違い）
48. 第08回⑥ 業務と開発のサービス（ビジネスアプリケーション・エンドユーザーコンピューティング・開発者ツール・CI/CD の流れ・フロントエンドと IoT）
49. 第08回⑦ 第08回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
50. 第09回① 監視の基本と CloudWatch（この回のねらい・この講座について・前の回の振り返り・3つの困りごとと3つのサービス・Amazon CloudWatch・CloudWatch のアラーム・CloudWatch Logs と標準で取れないもの）
51. 第09回② AWS CloudTrail（AWS CloudTrail・CloudTrail の記録の残し方・CloudTrail の使いどころ）
52. 第09回③ AWS Config と3つの使い分け（AWS Config・Config ルールと準拠の確認・CloudTrail と Config の違い・3つの使い分け・3つを組み合わせる流れ）
53. 第09回④ Trusted Advisor と AWS Health（AWS Trusted Advisor・Trusted Advisor のチェックのカテゴリ・サポートプランと使えるチェック・AWS Health Dashboard・AWS Health API・Trusted Advisor・Health・CloudWatch の違い）
54. 第09回⑤ 運用管理の道具（AWS Systems Manager・AWS Compute Optimizer・Service Quotas と License Manager・運用管理の使い分け）
55. 第09回⑥ Organizations と SCP（なぜアカウントを分けるのか・AWS Organizations・Organizations でできること・サービスコントロールポリシー（SCP）・SCP と IAM の関係）
56. 第09回⑦ Control Tower・Service Catalog・RAM（AWS Control Tower・AWS Service Catalog・AWS RAM）
57. 第09回⑧ 第09回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
58. 第10回① クラウドで守る利点と責任共有モデル（この回のねらい・この講座について・前の回の振り返り・クラウドで守る利点・責任共有モデルとは）
59. 第10回② 責任の分かれ方（AWS の責任（クラウドのセキュリティ）・お客様の責任（クラウド内のセキュリティ）・共有する管理・サービスで変わる責任）
60. 第10回③ 暗号化と KMS・CloudHSM・ACM（転送時と保管時の暗号化・AWS KMS・AWS CloudHSM・AWS Certificate Manager（ACM））
61. 第10回④ AWS アカウントとルートユーザー（AWS アカウントとルートユーザー・ルートユーザーだけができる作業・ルートユーザーの守り方）
62. 第10回⑤ IAM と最小権限（IAM の全体像・IAM ユーザーとグループ・IAM ロール・ポリシーの種類・最小権限の原則とアクセスレポート）
63. 第10回⑥ MFA・フェデレーション・認証情報の保管（パスワード・MFA・アクセスキー・クロスアカウントの IAM ロール・フェデレーションと IAM アイデンティティセンター・Directory Service と Cognito・認証情報の保管）
64. 第10回⑦ Shield・WAF・Firewall Manager（守りの層・AWS Shield・AWS WAF・AWS Firewall Manager・Shield・WAF・Firewall Manager の使い分け）
65. 第10回⑧ 検出と調査のサービス（Amazon GuardDuty・Amazon Inspector・Amazon Macie・Amazon Detective・AWS Security Hub・検出と調査の使い分け）
66. 第10回⑨ コンプライアンスと情報源（コンプライアンスの考え方・第三者認証と地域・業界・AWS Artifact・監査に使うログ・AWS Marketplace のセキュリティ製品・セキュリティ情報の入手先）
67. 第10回⑩ 第10回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
68. 第11回① Well-Architected フレームワークと6つの柱（この回のねらい・この講座について・前の回の振り返り・この回の役割・Well-Architected フレームワークとは・6つの柱の全体像）
69. 第11回② 柱の問いと Well-Architected Tool（柱が答える問い・一般的な設計原則・柱どうしのトレードオフ・Well-Architected Tool）
70. 第11回③ 6つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性・柱と回の対応）
71. 第11回④ 柱どうしの見分け方（信頼性とパフォーマンス効率・コスト最適化と持続可能性・運用上の優秀性と信頼性・セキュリティの柱と第10回）
72. 第11回⑤ 問題文と事例で柱を選ぶ（問題文の言葉から柱を選ぶ・ある EC サイトの会社の構成・柱の目で見直す）
73. 第11回⑥ 故障に備えた設計と疎結合（4つの原則の全体像・故障に備えた設計・コンポーネントの分離（疎結合））
74. 第11回⑦ 伸縮性・並列化と4つの原則（伸縮性の活用・並列化を考慮する・4つの原則と柱）
75. 第11回⑧ 第11回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
76. 第12回① 移行とは何か（この回のねらい・この講座について・前の回の振り返り・移行とは何か・この回の例の会社）
77. 第12回② 移行の流れと利点（移行の大まかな流れ・移行の利点・移行を支えるリソース）
78. 第12回③ AWS CAF の6つの観点（AWS CAF とは・6つの観点・ビジネス寄りの3つの観点・技術寄りの3つの観点・期待できる成果・CAF と Well-Architected の違い）
79. 第12回④ 7つの R と移し方（7つの R とは・そのまま移す：リホストとリロケート・少し手を加える：リプラットフォーム・作り直す：リファクタリング（リアーキテクト）・4つの R を並べて見分ける）
80. 第12回⑤ 買い替える・移さない戦略（買い替える：リパーチェス・移さない：リテインとリタイア・例の会社に当てはめる）
81. 第12回⑥ 評価のサービスと AWS MGN（移行のサービスの地図・費用を見積もる：Migration Evaluator・環境を調べる：Application Discovery Service・進み具合を1か所で見る：Migration Hub・サーバーを移す：AWS MGN）
82. 第12回⑦ データベースの移行：DMS と SCT（データベースの移行とは・AWS DMS・止めずに移す：データベースのレプリケーション・設計を変換する：AWS SCT・DMS と SCT の組み合わせ）
83. 第12回⑧ Snow ファミリーと例の会社の移行（大容量データを運ぶ：Snow ファミリー・例の会社の移行を通して見る）
84. 第12回⑨ 第12回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
85. 第13回① 従量課金と料金の決まり方（この回のねらい・この講座について・前の回の振り返り・従量課金と料金の決まり方）
86. 第13回② データ転送とストレージの料金（データ転送：受信と送信・データ転送：リージョン内とリージョン間・ストレージの料金）
87. 第13回③ サービスごとの料金と無料利用枠（安いクラスを選ぶときの注意・サービスごとの料金の決まり方・AWS 無料利用枠）
88. 第13回④ オンデマンドとリザーブドインスタンス（購入オプションの全体像・オンデマンドインスタンス・リザーブドインスタンス（RI）・RI の柔軟性・Organizations での割引の共有）
89. 第13回⑤ Savings Plans・スポットと使い分け（Savings Plans・RI と Savings Plans の違い・スポットインスタンス・専有ホストとハードウェア専有インスタンス・キャパシティーの予約・購入オプションの使い分け）
90. 第13回⑥ 見積り・予算・分析の道具（コスト管理の道具の全体像・AWS 料金見積りツール・AWS Budgets・AWS Cost Explorer・AWS Cost and Usage Report）
91. 第13回⑦ タグ・一括請求とコスト改善（コスト配分タグ・AWS Organizations の一括請求・請求と料金の情報・コスト改善の考え方）
92. 第13回⑧ 困ったときの窓口とサポートプラン（困ったときの窓口の全体像・サポートプランの比較・サポートプランと Trusted Advisor のチェック・AWS サポートセンター）
93. 第13回⑨ Trust & Safety・パートナー・Marketplace（AWS Trust & Safety チーム・技術リソース・AWS パートナーネットワーク（APN）・AWS Marketplace・技術支援）
94. 第13回⑩ 第13回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）
95. 第14回① 見分け方の表と分野 1（この回のねらい・この講座について・前の回の振り返り・見分け方の表の読み方・分野 1 ①：クラウドの性質と費用・分野 1 ②：設計と移行の考え方）
96. 第14回② 分野 2 の見分け方（分野 2 ①：責任共有モデル・分野 2 ②：アクセスと鍵の管理・分野 2 ③：攻撃からの守りと検出・分野 2 ④：記録・監査・統制）
97. 第14回③ 分野 3 の見分け方（分野 3 ①：インフラと処理の場所・分野 3 ②：ストレージ・データベース・移行・分野 3 ③：ネットワーク・分野 3 ④：連携・分析・AI）
98. 第14回④ 分野 4 の見分け方と5つの問い（分野 4 ①：料金と購入オプション・分野 4 ②：コスト管理とサポート・見分けの5つの問い）
99. 第14回⑤ 条件の言葉と主語（基本から一歩進める・条件の言葉①：運用と費用・条件の言葉②：可用性と性能・条件の言葉③：守りと統制・主語を見る：AWS かお客様か）
100. 第14回⑥ 似た言葉と問題文を読む順（似た言葉の取り違え・名前が似ているサービス・時間の配分と見直し・問題文を読む順）
101. 第14回⑦ 受験の申し込みと本人確認（申し込みから結果までの流れ・テストセンターとオンライン・申し込みの手順・本人確認と身分証明書・持ち物と持ち込めないもの）
102. 第14回⑧ オンライン受験の環境と当日（オンライン受験の環境・予約の変更と取り消し・当日の流れと遅刻・試験の後）
103. 第14回⑨ 第14回のまとめ（各回の見分け方の一覧・この回の要点・全14回を終えたら・参考資料）

AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 CLF）では、権限を付与する仕組み（IAM のポリシー）と、上限を決める仕組み（SCP）、記録する仕組み（CloudTrail・Config）を見分けて、最小権限の原則に沿った与え方を選ぶ問題がよく出ます。「記録する」ことは、権限を絞る代わりにはなりません。

この記事は、CLF の練習問題を1問ずつ解説する連載の第19問です。問題は筆者が試験の範囲に合わせて作ったもので、実際の試験の問題ではありません。まず自分で答えを選んでから、解説を読んでください。

▶ この回の内容は、YouTube の動画（約5分）でも見られます（記事の最後にも埋め込んであります）。

問題

ある企業では、運用チームに新しく加わった担当者が、Amazon EC2 インスタンスの起動と停止だけを行います。AWS 責任共有モデルでは、AWS のリソースへのアクセス権限の管理は利用者の責任です。最小権限の原則に沿って、この担当者に権限を与える方法として、最も適切なものはどれですか。

• A. AWS アカウントのルートユーザーの認証情報を担当者と共有し、AWS CloudTrail で操作を記録する
• B. 管理者の権限（AdministratorAccess）を担当者に付与し、AWS Config で設定の変更を記録する
• C. AWS Identity and Access Management（IAM）のポリシーで、EC2 インスタンスの起動と停止の操作だけを許可し、担当者に付与する
• D. AWS Organizations のサービスコントロールポリシー（SCP）で、担当者に EC2 インスタンスの起動と停止を許可する

答えを決めたら、下を開いてください。

正解は C

正解は C です。

• IAM のポリシーで、必要な操作だけを許可して、担当者に付与する
• これが、最小権限の原則に沿った与え方

ほかの3つは、権限が大きすぎるか、そもそも権限を付与できない方法です。ここから、選択肢を1つずつ見ていきます。

選択肢ごとの解説

A：ルートユーザーは共有しない（誤り）

ルートユーザーは、AWS アカウントのすべてを操作できる、特別なユーザーです。図のように、認証情報を共有すると、担当者もすべての操作ができてしまいます。必要なのは、緑の枠の起動と停止の2つだけです。

ルートユーザーの認証情報は共有せず、日常の作業にも使わないのが原則です。CloudTrail で操作を記録しても、後から分かるだけで、権限が大きすぎることは変わりません。

B：管理者の権限は大きすぎる（誤り）

AdministratorAccess は、すべての操作ができる、管理者の権限です。起動と停止だけを行う担当者には大きすぎて、最小権限の原則に反します。

AWS Config は、リソースの設定の変更を記録して、評価するサービスです。記録は後から分かるだけで、不要な操作を防ぐことはできません。

C：必要な操作だけを IAM で許可（正解）

IAM のポリシーで、EC2 インスタンスの起動と停止の操作だけを許可し、担当者に付与します。IAM では、何も許可しなければ、すべての操作が拒否されます。ポリシーで許可した操作だけができます。

図では、起動と停止だけが許可され、ほかの操作は拒否されます。これが最小権限です。

なお、人のユーザーには、IAM Identity Center でサインインさせる方法が勧められています。そこで付与する許可セットも、中身は IAM のポリシーです。

D：SCP は上限で、付与しない（誤り）

AWS Organizations の SCP は、権限を付与しません。組織や OU、アカウントで使える権限の上限を決めるもので、ガードレールとも呼ばれます。

図の右のように、実際に使えるのは、SCP の上限と、IAM のポリシーで許可した範囲の重なりだけです。SCP で起動と停止を許可していても、IAM のポリシーで許可しなければ、担当者は何もできません（図の左）。

付与する・上限を決める・記録する

権限に関わる3つの仕組みを、役割ごとに整理しておきます。

ポイント

• 最小権限 ＝ 必要な操作だけを IAM のポリシーで許可 して付与する
• SCP は 上限（ガードレール）。権限を付与しない
• CloudTrail・Config の記録は 権限を絞る代わりにならない
• ルートユーザーは 共有せず、日常の作業に使わない

最小権限の原則と IAM のポリシー、SCP と IAM の関係は、講座の記事で詳しく解説しています。

• 講座の第10回⑤「IAM と最小権限」（連載の入口のページから）
• 講座の第09回⑥「Organizations と SCP」（連載の入口のページから）

講座の全14回は、連載の入口のページから順に読めます。

動画で見る

この回の内容を、YouTube の動画（約5分）でも解説しています。

連載の全回は、YouTube の再生リスト「CLF-C02 試験対策問題」にまとめています。

連載「CLF-C02 試験対策問題」

全回の目次と、読む順番・目的別の読み方は、CLF-C02 試験対策問題の入口のページにまとめています。

1. 第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）
2. 第2問 数分でグローバルに展開（世界同時公開と低い遅延）
3. 第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）
4. 第4問 クラウドの俊敏性（数分で作成・すぐに削除）
5. 第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）
6. 第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）
7. 第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）
8. 第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）
9. 第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）
10. 第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）
11. 第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）
12. 第12問 移行のビジネスケース（Migration Evaluator）
13. 第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）
14. 第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）
15. 第15問 ファイルの移行（AWS DataSync）
16. 第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）
17. 第17問 適切なサイズ設定（CPU は余り、メモリが不足）
18. 第18問 責任共有モデル（Lambda と RDS）
19. 第19問 最小権限の原則（IAM のポリシーと SCP）（この記事）
20. 第20問 責任共有モデル（EC2 と S3、AWS の責任）
21. 第21問 共有統制の例（責任共有モデルの IT 統制）
22. 第22問 コンプライアンスの資料と契約（AWS Artifact）
23. 第23問 脅威の検出（Amazon GuardDuty）
24. 第24問 脆弱性の継続的なスキャン（Amazon Inspector）
25. 第25問 S3 の機密データの検出（Amazon Macie）
26. 第26問 S3 の保管時の暗号化とキーの管理
27. 第27問 だれが操作したかを調べる（AWS CloudTrail）
28. 第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）
29. 第29問 EC2 のアプリケーションに権限を与える（IAM ロール）
30. 第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）
31. 第31問 社員に一時的な認証情報を発行するサービス（AWS STS）
32. 第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）
33. 第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）
34. 第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）
35. 第35問 追加料金なしの DDoS 保護（AWS Shield Standard）
36. 第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）
37. 第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）
38. 第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）
39. 第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）
40. 第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）
41. 第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）
42. 第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）
43. 第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）
44. 第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）
45. 第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）
46. 第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）
47. 第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）
48. 第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）
49. 第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）
50. 第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）
51. 第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）
52. 第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）
53. 第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）
54. 第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）
55. 第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）
56. 第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）
57. 第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）
58. 第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）
59. 第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）
60. 第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）
61. 第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）
62. 第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）
63. 第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）
64. 第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）
65. 第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）
66. 第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）
67. 第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）
68. 第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）
69. 第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）
70. 第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）
71. 第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）
72. 第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）
73. 第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）
74. 第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）
75. 第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）
76. 第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）
77. 第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）
78. 第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）
79. 第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）
80. 第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）
81. 第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）
82. 第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）
83. 第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）
84. 第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）
85. 第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）
86. 第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）
87. 第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）
88. 第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）
89. 第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）
90. 第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）
91. 第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）
92. 第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）
93. 第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）
94. 第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）
95. 第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）
96. 第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）
97. 第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）
98. 第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）
99. 第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）
100. 第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）

どちらも、よく聞く話です。でも前者はログを機器の中に置いたままだったこと、後者は大事な記録を自分で捨てていることが問題です。

ログは、障害や不正アクセスが起きたときに「何が起きたか」を後から確かめられる、ほとんど唯一の手がかりです。連載「syslog入門」では、なぜログを集めるのかから始め、syslogの形式と転送方式、Linuxのjournaldとrsyslog、Windows・ネットワーク機器のログ、集約基盤の設計、SIEM、クラウドのログ、届かないときの切り分けまでを全11回で扱います。第1回は、ログとは何か、なぜ集めるのかです。

連載の進め方

第1回〜第3回が土台です。第1回で「なぜ・何を集めるか」、第2回で「syslogの形式と運び方」、第3回で「Linuxの中のログの流れ」を押さえると、第4回（rsyslog 前編）以降の設定の意味が分かります。コマンドは、LinuxとWindows標準のPowerShellを併記します。

ログの役割

ログとは、システムが「いつ、どこで、何が起きたか」を時刻付きで書き残した記録です。役割は大きく4つあります。

1. 障害調査：サービスが止まった時刻の前後に何が起きたかをたどり、原因と影響の範囲を特定する
2. セキュリティの検知と調査：ログインの失敗の急増や、深夜の管理者権限の使用などから攻撃の兆候を見つけ、侵入された後は、いつ、どこから入り、何をされたかを追跡する
3. 監査の証跡：誰がいつ何を変更し、どのデータにアクセスしたかを第三者に示す。PCI DSSやISMSが保存を求めるのはこの役割
4. 性能と容量の把握：アクセス数やエラーの件数の推移から、増強の時期や設定の問題を判断する

同じログでも、目的によって必要な保存期間と検索の速さが違います。何のために集めるのかを先に決めることが、設計の出発点です。

ログを集中管理する理由

ログを各機器の中に置いたままにすると、3つの問題が起きます。

1. 機器と一緒に失われる：ディスクが壊れたサーバー、交換したネットワーク機器、Auto Scalingで削除された仮想マシンのログは、もう調べられない。再起動で消える機器も多い
2. 侵入者に消される、書き換えられる：攻撃者は痕跡を消すためにログを削除・改ざんする（MITRE ATT&CKのT1070）。管理者権限を奪われた機器のログは信用できない
3. 横断して調べられない：1件の不正アクセスは、ファイアウォール、VPN、AD、サーバーのログにまたがって現れる。1台ずつ見ていては、時刻の順に並べられない

そこで、ログは発生したらすぐにログサーバーへ送り、そこで保管と検索を行います。ログサーバーは、送信元とは別の管理者権限で守ります。冒頭の「ディスクが壊れてログが読めない」は、集中管理していれば防げた問題です。

ポイント
失う・消される・並べられない、を1か所で防ぐ。ログは「発生したらすぐ外へ」。

1件の不正アクセスは、4か所のログにまたがる

2026-09-26T01:02:11Z fw01   allow tcp 203.0.113.50:51022 -> 192.0.2.30:443           （ファイアウォール）
2026-09-26T01:02:14Z vpn01  user=tanaka login success from 203.0.113.50                  （VPN）
2026-09-26T01:05:40Z dc01   4624 Logon Type 3 TargetUserName=tanaka IpAddress=192.0.2.200 （AD）
2026-09-26T01:07:02Z web01  sudo: tanaka : COMMAND=/usr/bin/tar czf /tmp/x.tgz /data      （サーバー）

• 外部の同じアドレスから、ファイアウォールを通り、VPNに同じ利用者名でログインし、ADで認証され、サーバーでデータをまとめている……という流れは、4台のログを時刻で並べて初めて見える
• どれか1台のログが消えていたり、時刻がずれていたりすると、流れが途切れる
• 上の例はUTCで、年・秒までそろえて記録している。形式がばらばらだと、並べる前に変換が要る（第2回・第7回）

ログとメトリクス・トレース

システムの状態を知る手がかりには、ログのほかにメトリクス（CPU使用率・件数などの数値の時系列）とトレース（1件の要求が複数のサービスをたどった経路）があります。

• ログ：何が起きたかの個々の記録。調査と証跡に強い
• メトリクス：数値の推移。しきい値の監視とグラフに強く、量が少ない
• トレース：1件の処理の経路と所要時間。マイクロサービスの遅延の調査に強い（分散トレースの設計は、このブログの連載「AWSマイクロサービス設計入門」第6回でも扱います）

「応答時間の推移」のような数値はメトリクスで監視し、ログは記録と調査に使う、と分けると、ログの量も抑えられます。この連載はログを中心に扱い、収集ツールの一部（OpenTelemetry Collectorなど）でメトリクス・トレースにも触れます（第7回）。

何を集めるか：種類ごとの優先度

優先度は目安です。「必須」の3種類は、PCI DSSの要件10.2が記録を求める範囲とほぼ重なります。まず必須の3種類を確実に集め、容量の見積もり（第7回）と相談しながら範囲を広げます。何を監視して警報を出すかは、第8回で扱います。

どこまで集めるか：絞り方の注意

冒頭の「warning以上だけ集める」は、ここで問題になります。

• Severityで一律に切らない：Severityは、各ソフトウェアの作者が決めた分類にすぎない。SSHのログイン成功（sshdのAccepted publickey）はauthpriv.info（RHELの既定。Debian系はauth.info）で届くため、「warning以上だけ」にするとログインの記録が消える
• 絞るなら、送信元の種類・Facility・プログラム名で決める。例：認証はinfo以上をすべて、一般のサービスはnotice以上（Facility・Severityは第2回）
• ローカルにも短期間残す：集約先へ送るのに加え、各機器にも数日分は残す。ネットワークやログサーバーの障害の間の穴埋めになる
• ログに入れてはいけないもの：パスワード、APIキーやトークン、カード番号（PAN）の全桁。アプリのデバッグ出力や、リクエストの全文記録に紛れ込みやすい
• 量は「1件の大きさ × 1秒あたりの件数 × 保存期間」で決まる。見積もり方は第7回

重要さの線は1本ではなく、ログの種類ごとに引くのです。

規制とガイドライン① PCI DSS

PCI DSSは、カード情報を扱う事業者の基準です。現行はv4.0.1（2024年6月公開。v4.0は2024年末で廃止）で、2025年3月末で将来日付だった要件もすべて必須になりました。

対象外の組織でも、「12か月保存・直近3か月はすぐ検索」「中央へ速やかに送る」「毎日確認」は、保存期間と構成を決めるときの良い目安になります。時刻の同期（10.6）は、連載「NTP入門」で詳しく扱っています。

規制とガイドライン② ISMSと個人情報

• ISMS（ISO/IEC 27001:2022、JIS Q 27001:2023）：附属書Aの管理策8.15（ログ取得）で、活動・例外・障害などのログを取得し、保存し、保護し、分析することを求める。8.16（監視活動）で異常の監視、8.17（クロックの同期）で時刻の同期を求める
• ISMSは保存期間の数値を定めない。事業上の必要、法令、契約から自社で決め、規程に書いて守る
• ログも個人情報になり得る：ユーザーID、メールアドレス、氏名などを含み、他の情報と照らして個人を特定できるログは、個人情報として安全管理措置の対象になる
• 個人情報保護委員会のガイドライン（通則編）は、安全管理措置の手法の例として、ログイン実績やアクセスログなどの記録の整備と、ログ等の定期的な分析による不正アクセスの検知を挙げている

ログサーバーは、個人情報の集積所でもあります。閲覧できる人を限り、閲覧の記録も残し、保存期間を過ぎたら消します。

考えてみよう

1. 担当するシステムのログは、どこに、何日分残っていますか。機器が壊れたり、管理者権限を奪われたりしたとき、そのログは残りますか。
2. 「容量が心配なのでwarning以上だけ集める」という方針を提案されたら、どう答えますか。そのとき失われるログの例を挙げてください。
3. 自社のログの保存期間は、どの規程・契約・基準に基づいて決まっていますか。決まっていなければ、何を根拠に決めますか。

ヒント：この記事の集中管理の3つの理由、sshdの例、PCI DSSの「12か月・3か月」と、ISMSは数値を定めないことが手がかりです。

まとめ

• ログは「いつ・どこで・何が起きたか」を時刻付きで残した記録。役割は障害調査・セキュリティ・監査の証跡・性能と容量
• 目的で保存期間と検索の速さが変わる。目的を先に決める
• 機器に置いたままだと失う・消される・並べられない。発生したらすぐログサーバーへ送り、別の権限で守る
• まず認証・管理操作・境界の通信の必須3種類を確実に集める
• Severityで一律に切らない。種類ごとに線を引き、ローカルにも数日残す
• PCI DSSは12か月保存・直近3か月はすぐ検索。ISMSは数値を定めず、自社で決める。ログサーバーは個人情報の集積所でもある

次回は、ログを集める共通の仕組みであるsyslogのメッセージの形式と転送方式を扱います。

連載「syslog入門」全11回

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

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