<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>資格 | インフラエンジニアへの道</title>
	<atom:link href="https://www.seichan.org/category/%e8%b3%87%e6%a0%bc/feed" rel="self" type="application/rss+xml" />
	<link>https://www.seichan.org</link>
	<description>DNSからAWSの設計まで、インフラの基礎を連載で</description>
	<lastBuildDate>Sun, 15 Nov 2026 00:22:04 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.4</generator>

<image>
	<url>https://www.seichan.org/blog/wp-content/uploads/2026/10/site-icon-2026-150x150.png</url>
	<title>資格 | インフラエンジニアへの道</title>
	<link>https://www.seichan.org</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>【CLF-C02 試験対策問題 第29問】EC2 のアプリケーションに権限を与える（IAM ロール）</title>
		<link>https://www.seichan.org/2026/11/clfq-029-iam-role.html</link>
					<comments>https://www.seichan.org/2026/11/clfq-029-iam-role.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Sun, 15 Nov 2026 00:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[AWS資格]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[CLF-C02 試験対策問題]]></category>
		<category><![CDATA[練習問題]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=16148</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の練習問題・第29問。EC2 のアプリケーションから DynamoDB に書き込むとき、長期のアクセスキーを置かずに必要な権限だけを与える方法を選ぶ問題です。正解の IAM ロールと、誤りの3つの選択肢を図で解説します。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「EC2 から DynamoDB に書き込むのに、セキュリティグループで通信を許可するだけでは足りないのはなぜですか」<br>「アクセスキーを設定ファイルに書くのが、いちばん確実だと思っていました」</p>



<p class="wp-block-paragraph">AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 <strong>CLF</strong>）では、<strong>EC2 のアプリケーションに、アクセスキーを置かずに権限を与える方法</strong>を選ぶ問題が出ます。通信の許可と操作の権限の違い、ルートユーザーや IAM ユーザーのアクセスキーがなぜ避けられるかが、選択肢の誤りの論点になります。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/6qp9kbMiliY" target="_blank">YouTube の動画（約5分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-1" checked><label class="toc-title" for="toc-checkbox-1">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">問題</a></li><li><a href="#toc2" tabindex="0">正解は C</a></li><li><a href="#toc3" tabindex="0">選択肢ごとの解説</a><ol><li><a href="#toc4" tabindex="0">A：通信の許可は権限ではない（誤り）</a></li><li><a href="#toc5" tabindex="0">B：ルートユーザーのキーは使わない（誤り）</a></li><li><a href="#toc6" tabindex="0">C：IAM ロールをアタッチする（正解）</a></li><li><a href="#toc7" tabindex="0">D：長期のアクセスキーは置かない（誤り）</a></li></ol></li><li><a href="#toc8" tabindex="0">長期の認証情報と一時的な認証情報</a></li><li><a href="#toc9" tabindex="0">ポイント</a></li><li><a href="#toc10" tabindex="0">動画で見る</a></li><li><a href="#toc11" tabindex="0">連載「CLF-C02 試験対策問題」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">問題</span></h2>



<p class="wp-block-paragraph">ある企業は、Amazon EC2 インスタンスで動くアプリケーションから、Amazon DynamoDB のテーブルにデータを書き込みます。長期間使えるアクセスキーをインスタンスに置かずに、必要な権限だけを与えたいと考えています。最も適切な方法はどれですか。</p>



<ul class="wp-block-list">
<li><strong>A.</strong> セキュリティグループのアウトバウンドルールで、DynamoDB への通信を許可する</li>


<li><strong>B.</strong> AWS アカウントのルートユーザーのアクセスキーを、インスタンスの環境変数に設定する</li>


<li><strong>C.</strong> DynamoDB のテーブルへの書き込みだけを許可した IAM ロールを作り、インスタンスにアタッチする</li>


<li><strong>D.</strong> IAM ユーザーを作ってアクセスキーを発行し、アプリケーションの設定ファイルに書く</li>
</ul>



<p class="wp-block-paragraph">答えを決めたら、下を開いてください。</p>



<details class="quiz-answer"><summary><strong>正解を見る</strong>（クリックで開きます）</summary>
<p><strong>正解：C</strong></p>
<p>書き込みだけを許可した <strong>IAM ロール</strong>をインスタンスにアタッチすると、アプリケーションは一時的な認証情報を自動で受け取れます。アクセスキーを置かずに、必要な権限だけを与えられます。</p>
</details>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">正解は C</span></h2>



<p class="wp-block-paragraph">正解は <strong>C</strong> です。</p>



<p class="wp-block-paragraph">書き込みだけを許可した IAM ロールを、インスタンスにアタッチします。アプリケーションは、<strong>一時的な認証情報</strong>を自動で受け取るので、アクセスキーを置かずに済みます。ここから、選択肢を1つずつ見ていきます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">選択肢ごとの解説</span></h2>



<h3 class="wp-block-heading"><span id="toc4">A：通信の許可は権限ではない（誤り）</span></h3>



<figure class="wp-block-image size-full"><img fetchpriority="high" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-a-sg.png" alt="左上は EC2 インスタンスのアプリケーションから、アウトバウンド通信を許可したセキュリティグループを通って DynamoDB へ向かうが、書き込みは拒否される。左下は、書き込むには2つとも通る必要があり、通信を通すか（セキュリティグループ）は許可して通る、操作してよいか（IAM の権限）は与えていないので拒否。右は「通信の許可と操作の権限は別」「権限は与えない」" class="wp-image-16143" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-a-sg.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-a-sg-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-a-sg-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-a-sg-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-a-sg-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-a-sg-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">セキュリティグループは、通信を通すかどうかを決める、ネットワークの門です。DynamoDB にデータを書き込むには、通信が通ることに加えて、<strong>IAM の権限</strong>が要ります。</p>



<p class="wp-block-paragraph">図のように、アウトバウンドルールで通信を許可しても、IAM の権限が無ければ、書き込みは拒否されます。通信の許可と、操作の権限は、別のものです。</p>



<h3 class="wp-block-heading"><span id="toc5">B：ルートユーザーのキーは使わない（誤り）</span></h3>



<figure class="wp-block-image size-full"><img decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-b-root.png" alt="左上は EC2 インスタンスの環境変数にルートユーザーのアクセスキーを置き、アカウントのすべてを操作できるルートユーザーとして動く。このキーでできる操作は、DynamoDB への書き込み（必要なのは緑の枠のこれだけ）のほか、テーブルの削除、EC2 の終了、S3 のデータの削除、IAM ユーザーの作成、請求情報の確認、RDS の DB の削除、アカウントの閉鎖。右は「必要な権限だけにならない」" class="wp-image-16144" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-b-root.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-b-root-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-b-root-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-b-root-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-b-root-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-b-root-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">ルートユーザーは、AWS アカウントのすべてを操作できる、特別なユーザーです。図のように、そのアクセスキーを使うと、アプリケーションはテーブルの削除や、アカウントの閉鎖まで、<strong>何でもできてしまいます</strong>。必要な権限だけ、という要件に反します。</p>



<p class="wp-block-paragraph">ルートユーザーのアクセスキーは、作らないのが原則です。長期間使えるキーなので、漏れるとアカウントのすべてが危険になります。</p>



<h3 class="wp-block-heading"><span id="toc6">C：IAM ロールをアタッチする（正解）</span></h3>



<figure class="wp-block-image size-full"><img decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-c-role.png" alt="左上の IAM ロール（ポリシー：DynamoDB のテーブルへの書き込みだけ許可）を、インスタンスプロファイルで EC2 インスタンスにアタッチする。アプリケーション（AWS SDK・CLI）が DynamoDB のテーブルへ書き込む。一時的な認証情報は、インスタンスメタデータから自動で渡され、AWS が自動でローテーションする。右は「最小権限」で、アクセスキーを置かない" class="wp-image-16145" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-c-role.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-c-role-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-c-role-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-c-role-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-c-role-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-c-role-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">書き込みだけを許可した IAM ロールを、インスタンスにアタッチします。<strong>インスタンスプロファイル</strong>という仕組みです。</p>



<p class="wp-block-paragraph">アプリケーションは、インスタンスメタデータから、一時的な認証情報を受け取ります。AWS SDK や CLI は、これを自動で使います。一時的な認証情報は、<strong>AWS が自動でローテーション</strong>します。ロールのポリシーを変えると、新しい権限の認証情報が自動で渡されます。</p>



<p class="wp-block-paragraph">アクセスキーを置かずに済み、必要な権限だけにもなります。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<h3 class="wp-block-heading"><span id="toc7">D：長期のアクセスキーは置かない（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-d-key.png" alt="IAM ユーザーに発行したアクセスキーを、EC2 インスタンスのアプリケーションの設定ファイル（access_key と secret_key）に書く。コードの公開・バックアップなどから漏れて、第三者が同じ権限でいつでも使える。長期の認証情報は、削除・無効化するまで使い続けられ、自分でローテーションする必要がある。右は「要件に反する」で、EC2 には IAM ロールを使う" class="wp-image-16146" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-d-key.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-d-key-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-d-key-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-d-key-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-d-key-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq029-d-key-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">IAM ユーザーのアクセスキーは、<strong>長期間使える</strong>認証情報です。削除や無効化をするまで使い続けられます。</p>



<p class="wp-block-paragraph">設定ファイルに書くと、図のように、コードの公開やバックアップから漏れたとき、第三者に悪用されるおそれがあります。そもそも、長期間使えるアクセスキーを置かない、という要件に反します。EC2 のアプリケーションには、IAM ロールを使います。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">長期の認証情報と一時的な認証情報</span></h2>



<p class="wp-block-paragraph">長期の認証情報と一時的な認証情報の違いを、表で整理します。大きな違いは、置く必要があるかどうかと、ローテーションをだれが行うかです。</p>



<figure class="wp-block-table"><table><thead><tr><th>項目</th><th>長期の認証情報</th><th>一時的な認証情報</th></tr></thead><tbody><tr><td><strong>例</strong></td><td>IAM ユーザー・ルートユーザーのアクセスキー</td><td>IAM ロール（EC2 のインスタンスプロファイル）</td></tr><tr><td><strong>置き場所</strong></td><td>設定ファイル・環境変数などに自分で置く</td><td>置かない。インスタンスメタデータから受け取る</td></tr><tr><td><strong>使える期間</strong></td><td>削除・無効化するまで</td><td>期限がある</td></tr><tr><td><strong>ローテーション</strong></td><td>自分で行う</td><td><strong>AWS が自動で行う</strong></td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">ポイント</span></h2>



<ul class="wp-block-list">
<li>EC2 のアプリケーションに権限を与える ＝ <strong>IAM ロール</strong> をアタッチ</li>


<li>一時的な認証情報が <strong>自動で渡され、自動でローテーション</strong></li>


<li>アクセスキーを <strong>設定ファイル・環境変数に置かない</strong></li>


<li>セキュリティグループは <strong>通信の許可</strong>。操作の権限は IAM</li>
</ul>



<p class="wp-block-paragraph">IAM ロールの仕組みと、ルートユーザーのアクセスキーを作らない理由は、講座の記事で詳しく解説しています。</p>



<ul class="wp-block-list">
<li>講座の第10回⑤「IAM と最小権限」の「IAM ロール」の節（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>


<li>講座の第10回④「AWS アカウントとルートユーザー」の「ルートユーザーの守り方」の節（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>
</ul>



<p class="wp-block-paragraph">講座の全14回は、<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から順に読めます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約5分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="EC2 のアプリケーションに権限を与える（IAM ロール）【CLF-C02】AWS クラウドプラクティショナー 試験対策問題 第29問" width="1256" height="707" src="https://www.youtube.com/embed/6qp9kbMiliY?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">連載の全回は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLSxdgP1WVL3E" target="_blank">再生リスト「CLF-C02 試験対策問題」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc11">連載「CLF-C02 試験対策問題」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clfq">CLF-C02 試験対策問題の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/11/clfq-001-cost-benefits.html" target="_blank">第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-002-global-reach.html" target="_blank">第2問 数分でグローバルに展開（世界同時公開と低い遅延）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-003-high-availability.html" target="_blank">第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-004-agility.html" target="_blank">第4問 クラウドの俊敏性（数分で作成・すぐに削除）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-005-rehost-responsibility.html" target="_blank">第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-006-peak-scaling.html" target="_blank">第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-007-well-architected-pillars.html" target="_blank">第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-008-reliability-principles.html" target="_blank">第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-009-sustainability-principles.html" target="_blank">第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-010-caf-phases.html" target="_blank">第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-011-caf-operations.html" target="_blank">第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-012-migration-evaluator.html" target="_blank">第12問 移行のビジネスケース（Migration Evaluator）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-013-caf-people.html" target="_blank">第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-014-transform-mgn.html" target="_blank">第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-015-datasync.html" target="_blank">第15問 ファイルの移行（AWS DataSync）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-016-repurchase.html" target="_blank">第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-017-right-sizing.html" target="_blank">第17問 適切なサイズ設定（CPU は余り、メモリが不足）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-018-lambda-rds-responsibility.html" target="_blank">第18問 責任共有モデル（Lambda と RDS）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-019-least-privilege.html" target="_blank">第19問 最小権限の原則（IAM のポリシーと SCP）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-020-aws-responsibility.html" target="_blank">第20問 責任共有モデル（EC2 と S3、AWS の責任）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-021-shared-controls.html" target="_blank">第21問 共有統制の例（責任共有モデルの IT 統制）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-022-artifact.html" target="_blank">第22問 コンプライアンスの資料と契約（AWS Artifact）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-023-guardduty.html" target="_blank">第23問 脅威の検出（Amazon GuardDuty）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-024-inspector.html" target="_blank">第24問 脆弱性の継続的なスキャン（Amazon Inspector）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-025-macie.html" target="_blank">第25問 S3 の機密データの検出（Amazon Macie）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html" target="_blank">第26問 S3 の保管時の暗号化とキーの管理</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-027-cloudtrail.html" target="_blank">第27問 だれが操作したかを調べる（AWS CloudTrail）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-028-credential-report.html" target="_blank">第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）</a></li>


<li><strong>第29問 EC2 のアプリケーションに権限を与える（IAM ロール）（この記事）</strong></li>


<li>第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）</li>


<li>第31問 社員に一時的な認証情報を発行するサービス（AWS STS）</li>


<li>第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）</li>


<li>第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）</li>


<li>第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）</li>


<li>第35問 追加料金なしの DDoS 保護（AWS Shield Standard）</li>


<li>第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）</li>


<li>第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）</li>


<li>第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）</li>


<li>第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）</li>


<li>第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）</li>


<li>第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）</li>


<li>第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）</li>


<li>第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）</li>


<li>第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）</li>


<li>第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）</li>


<li>第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）</li>


<li>第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）</li>


<li>第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）</li>


<li>第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）</li>


<li>第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）</li>


<li>第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）</li>


<li>第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）</li>


<li>第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）</li>


<li>第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）</li>


<li>第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）</li>


<li>第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）</li>


<li>第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）</li>


<li>第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）</li>


<li>第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）</li>


<li>第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）</li>


<li>第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）</li>


<li>第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）</li>


<li>第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）</li>


<li>第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）</li>


<li>第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）</li>


<li>第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）</li>


<li>第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）</li>


<li>第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）</li>


<li>第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）</li>


<li>第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）</li>


<li>第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）</li>


<li>第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）</li>


<li>第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）</li>


<li>第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）</li>


<li>第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）</li>


<li>第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）</li>


<li>第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）</li>


<li>第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）</li>


<li>第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）</li>


<li>第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）</li>


<li>第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）</li>


<li>第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）</li>


<li>第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）</li>


<li>第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）</li>


<li>第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）</li>


<li>第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）</li>


<li>第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）</li>


<li>第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）</li>


<li>第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）</li>


<li>第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）</li>


<li>第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）</li>


<li>第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）</li>


<li>第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）</li>


<li>第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）</li>


<li>第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）</li>


<li>第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）</li>


<li>第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）</li>


<li>第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）</li>


<li>第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）</li>


<li>第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clfq-029-iam-role.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【CLF-C02 試験対策問題 第28問】IAM ユーザーの認証情報の一覧（認証情報レポート）</title>
		<link>https://www.seichan.org/2026/11/clfq-028-credential-report.html</link>
					<comments>https://www.seichan.org/2026/11/clfq-028-credential-report.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Sat, 14 Nov 2026 06:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[AWS資格]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[CLF-C02 試験対策問題]]></category>
		<category><![CDATA[練習問題]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=16141</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の練習問題・第28問。全 IAM ユーザーの MFA の有無とアクセスキーの最終ローテーション日を、一覧の資料で出す最も手間の少ない方法を選ぶ問題です。正解の認証情報レポートと、誤りの選択肢の違いを図で解説します。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「最終アクセス情報と認証情報レポートは、どちらも IAM の『レポート』のようで、どちらを選べばよいか迷います」<br>「『監査』という言葉があると、つい AWS Artifact を選んでしまいます」</p>



<p class="wp-block-paragraph">AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 <strong>CLF</strong>）では、<strong>IAM の点検に使う道具を、目的で見分ける</strong>問題が出ます。今回のように「すべての IAM ユーザーの MFA とアクセスキーの状態を一覧で」という目的から、どの道具が答えかを選びます。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/HEQ_V5xc8qg" target="_blank">YouTube の動画（約5分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-2" checked><label class="toc-title" for="toc-checkbox-2">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">問題</a></li><li><a href="#toc2" tabindex="0">正解は B</a></li><li><a href="#toc3" tabindex="0">選択肢ごとの解説</a><ol><li><a href="#toc4" tabindex="0">A：最終アクセス情報は権限の見直し（誤り）</a></li><li><a href="#toc5" tabindex="0">B：認証情報レポートは CSV の一覧（正解）</a></li><li><a href="#toc6" tabindex="0">C：Artifact は AWS 自身のレポート（誤り）</a></li><li><a href="#toc7" tabindex="0">D：CloudTrail は操作の記録（誤り）</a></li></ol></li><li><a href="#toc8" tabindex="0">IAM の点検の道具</a></li><li><a href="#toc9" tabindex="0">ポイント</a></li><li><a href="#toc10" tabindex="0">動画で見る</a></li><li><a href="#toc11" tabindex="0">連載「CLF-C02 試験対策問題」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">問題</span></h2>



<p class="wp-block-paragraph">ある企業は、外部の監査人から、AWS アカウントのすべての IAM ユーザーについて、MFA が有効かどうかと、アクセスキーを最後にローテーションした日を、一覧の資料で出すように求められました。最も手間の少ない方法はどれですか。</p>



<ul class="wp-block-list">
<li><strong>A.</strong> IAM の最終アクセス情報（アクセスアドバイザー）を、ユーザーごとに確認する</li>


<li><strong>B.</strong> IAM の認証情報レポートを生成し、CSV ファイルをダウンロードする</li>


<li><strong>C.</strong> AWS Artifact から、コンプライアンスのレポートをダウンロードする</li>


<li><strong>D.</strong> AWS CloudTrail のイベント履歴から、ユーザーごとの操作を探す</li>
</ul>



<p class="wp-block-paragraph">答えを決めたら、下を開いてください。</p>



<details class="quiz-answer"><summary><strong>正解を見る</strong>（クリックで開きます）</summary>
<p><strong>正解：B</strong></p>
<p>IAM の<strong>認証情報レポート</strong>は、すべての IAM ユーザーのパスワード・アクセスキー・MFA の状態を、1つの CSV ファイルの一覧にします。そのまま監査人に渡せるので、最も手間の少ない方法です。</p>
</details>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">正解は B</span></h2>



<p class="wp-block-paragraph">正解は <strong>B</strong> の IAM の認証情報レポートです。</p>



<p class="wp-block-paragraph">認証情報レポートは、アカウントのすべての IAM ユーザーの、パスワード・アクセスキー・MFA の状態を、<strong>1つの CSV ファイルの一覧</strong>にします。そのまま監査人に渡せるので、最も手間の少ない方法です。ここから、選択肢を1つずつ見ていきます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">選択肢ごとの解説</span></h2>



<h3 class="wp-block-heading"><span id="toc4">A：最終アクセス情報は権限の見直し（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-a-advisor.png" alt="左はユーザー sato の最終アクセス情報で、許可されたサービスごとの最終アクセスの表。Amazon S3 は2日前、Amazon EC2 は15日前、Amazon DynamoDB と AWS Lambda は「アクセスなし」。右は「目的は権限の見直し（1人ずつ見る）」で、使っていないサービスの権限を削って最小権限に近づける。下に赤字「MFA・アクセスキーのローテーションの状態の一覧ではない」" class="wp-image-16136" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-a-advisor.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-a-advisor-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-a-advisor-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-a-advisor-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-a-advisor-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-a-advisor-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">最終アクセス情報は、アクセスアドバイザーとも呼ばれます。図のように、1人のユーザーが、許可されたサービスに<strong>最後にアクセスした日時</strong>を示します。</p>



<p class="wp-block-paragraph">長い間アクセスしていないサービスの権限を見つけて削り、最小権限に近づけるために使います。MFA やアクセスキーのローテーションの状態の一覧ではありません。ユーザーごとに見るので、手間もかかります。</p>



<h3 class="wp-block-heading"><span id="toc5">B：認証情報レポートは CSV の一覧（正解）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-b-report.png" alt="IAM の認証情報レポート（credential-report.csv）の表。列は、ユーザー、MFA が有効か、アクセスキーの最終ローテーション日、パスワードの最終使用日。tanaka・sato・ito は MFA が true、suzuki だけ false で赤く強調され「MFA が無効 すぐ分かる」。右に「すべての IAM ユーザーが1つの一覧に」、下に「1つの CSV ファイル。そのまま監査人に渡せる」" class="wp-image-16137" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-b-report.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-b-report-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-b-report-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-b-report-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-b-report-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-b-report-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">IAM の認証情報レポートは、アカウントのすべての IAM ユーザーと、ルートユーザーの認証情報の状態を、<strong>CSV ファイル</strong>にまとめたものです。</p>



<p class="wp-block-paragraph">図のように、MFA が有効か、アクセスキーを最後にローテーションした日、パスワードを最後に使った日などが、列に並びます。MFA が無効のユーザーも、すぐに分かります。レポートは4時間に1回生成でき、そのまま監査人に渡せます。</p>



<h3 class="wp-block-heading"><span id="toc6">C：Artifact は AWS 自身のレポート（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-c-artifact.png" alt="左の橙の枠は AWS Artifact で、「渡すのは AWS 自身のレポート」。AWS 自身の環境から、SOC・PCI などのレポートを経て、監査人に渡す流れ。右の青の枠は利用者のアカウントで、tanaka・suzuki・sato の3人が「MFA？キー？」のまま。「Artifact は、利用者の IAM ユーザーを見ない」。下に「自社の IAM ユーザーの状態は分からない」" class="wp-image-16138" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-c-artifact.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-c-artifact-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-c-artifact-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-c-artifact-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-c-artifact-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-c-artifact-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">AWS Artifact で入手できるのは、<strong>AWS 自身</strong>のコンプライアンスのレポートです。SOC や PCI のレポートなどです。</p>



<p class="wp-block-paragraph">監査やレポートという言葉は合っていますが、中身は AWS の環境についての資料です。利用者のアカウントの中の、IAM ユーザーの状態は分かりません。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<h3 class="wp-block-heading"><span id="toc7">D：CloudTrail は操作の記録（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-d-trail.png" alt="左はイベント履歴（操作の記録）の表で、時刻・ユーザー・イベントが並ぶ（10:58 sato PutObject、10:41 tanaka ConsoleLogin、10:37 suzuki RunInstances など）。過去90日分の操作がずっと続く。右は「知りたいのは今の状態」で、MFA は今、有効か、アクセスキーを最後にローテーションした日は、に対し×「操作の記録をたどっても、一覧にならない」" class="wp-image-16139" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-d-trail.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-d-trail-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-d-trail-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-d-trail-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-d-trail-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq028-d-trail-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">CloudTrail のイベント履歴は、だれが、いつ、どの<strong>操作</strong>をしたかの記録です。図のように、操作が時刻の順に並びます。</p>



<p class="wp-block-paragraph">この中から、ユーザーごとに操作を探すのは、手間がかかります。しかも、操作の記録をたどっても、MFA が今有効かどうかの一覧にはなりません。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">IAM の点検の道具</span></h2>



<p class="wp-block-paragraph">IAM の点検に使う道具を、目的で整理します。目的に合わせて使い分けましょう。</p>



<figure class="wp-block-table"><table><thead><tr><th>道具</th><th>分かること・使い道</th></tr></thead><tbody><tr><td><strong>認証情報レポート</strong></td><td><strong>すべての IAM ユーザーの認証情報の状態（CSV）</strong>／<strong>パスワード・アクセスキー・MFA → 監査に出す</strong></td></tr><tr><td>最終アクセス情報</td><td>サービスに最後にアクセスした日時／→ 使っていない権限を削る</td></tr><tr><td>IAM Access Analyzer</td><td>外部と共有されているリソースを見つける</td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">ポイント</span></h2>



<ul class="wp-block-list">
<li>全 IAM ユーザーの <strong>MFA・アクセスキー・パスワード</strong> の状態 → <strong>認証情報レポート</strong>（CSV）</li>


<li>使っていない権限を見つける → <strong>最終アクセス情報</strong></li>


<li>AWS 自身の監査のレポート → <strong>Artifact</strong></li>


<li>操作の記録 → <strong>CloudTrail</strong></li>
</ul>



<p class="wp-block-paragraph">認証情報レポートと最終アクセス情報、最小権限の原則は、講座の記事で詳しく解説しています。</p>



<ul class="wp-block-list">
<li>講座の第10回⑤「IAM と最小権限」の「最小権限の原則とアクセスレポート」の節（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>


<li>講座の第10回⑨「コンプライアンスと情報源」の「AWS Artifact」の節（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>
</ul>



<p class="wp-block-paragraph">講座の全14回は、<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から順に読めます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約5分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="IAM ユーザーの認証情報の一覧（認証情報レポート）【CLF-C02】AWS クラウドプラクティショナー 試験対策問題 第28問" width="1256" height="707" src="https://www.youtube.com/embed/HEQ_V5xc8qg?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">連載の全回は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLSxdgP1WVL3E" target="_blank">再生リスト「CLF-C02 試験対策問題」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc11">連載「CLF-C02 試験対策問題」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clfq">CLF-C02 試験対策問題の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/11/clfq-001-cost-benefits.html" target="_blank">第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-002-global-reach.html" target="_blank">第2問 数分でグローバルに展開（世界同時公開と低い遅延）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-003-high-availability.html" target="_blank">第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-004-agility.html" target="_blank">第4問 クラウドの俊敏性（数分で作成・すぐに削除）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-005-rehost-responsibility.html" target="_blank">第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-006-peak-scaling.html" target="_blank">第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-007-well-architected-pillars.html" target="_blank">第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-008-reliability-principles.html" target="_blank">第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-009-sustainability-principles.html" target="_blank">第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-010-caf-phases.html" target="_blank">第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-011-caf-operations.html" target="_blank">第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-012-migration-evaluator.html" target="_blank">第12問 移行のビジネスケース（Migration Evaluator）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-013-caf-people.html" target="_blank">第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-014-transform-mgn.html" target="_blank">第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-015-datasync.html" target="_blank">第15問 ファイルの移行（AWS DataSync）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-016-repurchase.html" target="_blank">第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-017-right-sizing.html" target="_blank">第17問 適切なサイズ設定（CPU は余り、メモリが不足）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-018-lambda-rds-responsibility.html" target="_blank">第18問 責任共有モデル（Lambda と RDS）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-019-least-privilege.html" target="_blank">第19問 最小権限の原則（IAM のポリシーと SCP）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-020-aws-responsibility.html" target="_blank">第20問 責任共有モデル（EC2 と S3、AWS の責任）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-021-shared-controls.html" target="_blank">第21問 共有統制の例（責任共有モデルの IT 統制）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-022-artifact.html" target="_blank">第22問 コンプライアンスの資料と契約（AWS Artifact）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-023-guardduty.html" target="_blank">第23問 脅威の検出（Amazon GuardDuty）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-024-inspector.html" target="_blank">第24問 脆弱性の継続的なスキャン（Amazon Inspector）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-025-macie.html" target="_blank">第25問 S3 の機密データの検出（Amazon Macie）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html" target="_blank">第26問 S3 の保管時の暗号化とキーの管理</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-027-cloudtrail.html" target="_blank">第27問 だれが操作したかを調べる（AWS CloudTrail）</a></li>


<li><strong>第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clfq-029-iam-role.html" target="_blank">第29問 EC2 のアプリケーションに権限を与える（IAM ロール）</a></li>


<li>第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）</li>


<li>第31問 社員に一時的な認証情報を発行するサービス（AWS STS）</li>


<li>第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）</li>


<li>第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）</li>


<li>第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）</li>


<li>第35問 追加料金なしの DDoS 保護（AWS Shield Standard）</li>


<li>第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）</li>


<li>第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）</li>


<li>第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）</li>


<li>第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）</li>


<li>第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）</li>


<li>第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）</li>


<li>第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）</li>


<li>第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）</li>


<li>第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）</li>


<li>第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）</li>


<li>第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）</li>


<li>第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）</li>


<li>第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）</li>


<li>第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）</li>


<li>第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）</li>


<li>第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）</li>


<li>第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）</li>


<li>第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）</li>


<li>第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）</li>


<li>第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）</li>


<li>第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）</li>


<li>第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）</li>


<li>第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）</li>


<li>第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）</li>


<li>第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）</li>


<li>第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）</li>


<li>第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）</li>


<li>第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）</li>


<li>第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）</li>


<li>第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）</li>


<li>第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）</li>


<li>第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）</li>


<li>第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）</li>


<li>第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）</li>


<li>第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）</li>


<li>第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）</li>


<li>第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）</li>


<li>第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）</li>


<li>第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）</li>


<li>第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）</li>


<li>第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）</li>


<li>第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）</li>


<li>第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）</li>


<li>第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）</li>


<li>第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）</li>


<li>第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）</li>


<li>第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）</li>


<li>第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）</li>


<li>第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）</li>


<li>第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）</li>


<li>第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）</li>


<li>第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）</li>


<li>第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）</li>


<li>第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）</li>


<li>第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）</li>


<li>第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）</li>


<li>第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）</li>


<li>第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）</li>


<li>第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）</li>


<li>第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）</li>


<li>第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）</li>


<li>第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）</li>


<li>第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）</li>


<li>第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）</li>


<li>第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clfq-028-credential-report.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【AWS クラウドプラクティショナー試験対策講座 第04回⑥】第04回のまとめ ― 処理を動かす場所・コンテナーのサービス・増やす振り分ける選ぶの見分け方、この回の要点、参考資料、次の回の予告、持ち帰ってほしい3点</title>
		<link>https://www.seichan.org/2026/11/clf-04-6-summary.html</link>
					<comments>https://www.seichan.org/2026/11/clf-04-6-summary.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Sat, 14 Nov 2026 03:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS クラウドプラクティショナー試験対策講座]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[コンピューティング]]></category>
		<category><![CDATA[用語の見分け方]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=13101</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の第04回「コンピューティング」を振り返ります。EC2・Lambda・Fargate・Elastic Beanstalk・Lightsail・Batch・API Gateway の見分け方、ECR・ECS・EKS・Fargate・EC2 の役割、垂直と水平のスケーリング・ELB・Auto Scaling・ファミリーの見分け方の表、この回の要点、参考資料、次の回の予告、持ち帰ってほしい3点まで。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「EC2、Lambda、Fargate、Elastic Beanstalk、Lightsail、Batch。サービスが多すぎて、問題文を読んでも、どれのことか決められません」<br>「第04回は項目が多くて、結局、何を覚えて帰ればいいのか分かりません」</p>



<p class="wp-block-paragraph">どちらも、第04回を読み終えた人が、いちばん最初につまずくところです。1つ目は、<strong>サービスの名前を覚えるだけでなく、「問題文の手がかりの言葉」とセットで覚える</strong> と解決しやすくなります。2つ目は、この記事の最後に <strong>持ち帰ってほしい3点</strong> にまとめました。</p>



<p class="wp-block-paragraph">この記事は、AWS クラウドプラクティショナー試験対策講座（AWS Certified Cloud Practitioner、試験コード CLF-C02。以下 CLF）の第04回⑥で、第04回の <strong>まとめ</strong> です。第04回①〜⑤で出てきた似たサービスを、3つの表で見分けます。そのあと、この回の要点、参考資料、次の回の予告を載せます。冒頭の1つ目の相談には3つの表の節、2つ目の相談には「まとめ（持ち帰ってほしい3点）」の節で答えます。</p>



<p class="wp-block-paragraph">なお、この連載は AWS の公式の資料ではありません。試験の情報は2026年10月26日時点のもので、変わることがあるので、受験の前に AWS の公式ページで確かめてください。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-3" checked><label class="toc-title" for="toc-checkbox-3">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">この回の見分け方①：処理を動かす場所</a></li><li><a href="#toc2" tabindex="0">この回の見分け方②：コンテナーのサービス</a></li><li><a href="#toc3" tabindex="0">この回の見分け方③：増やす・振り分ける・選ぶ</a></li><li><a href="#toc4" tabindex="0">この回の要点</a></li><li><a href="#toc5" tabindex="0">参考資料</a></li><li><a href="#toc6" tabindex="0">考えてみよう</a></li><li><a href="#toc7" tabindex="0">まとめ（持ち帰ってほしい3点）</a></li><li><a href="#toc8" tabindex="0">次の回の予告</a></li><li><a href="#toc9" tabindex="0">連載「AWS クラウドプラクティショナー試験対策講座」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">この回の見分け方①：処理を動かす場所</span></h2>



<p class="wp-block-paragraph">まず、処理を動かすサービスの見分けです。第04回①の「AWS のコンピューティングの全体像」の節で見た、処理を動かす方法の4つの分け方（借りる・増やして支える・管理を任せる・コンテナーと手軽なサービス）のうち、動かす場所になるサービスと、API の入口を、1つの表にしました。</p>



<figure class="wp-block-table"><table><thead><tr><th>サービス</th><th>ひとことで</th><th>問題文の手がかりの言葉</th></tr></thead><tbody><tr><td>Amazon EC2</td><td>仮想サーバーを借りる。OS から上は利用者</td><td>OS を自由に設定したい、長く動かし続ける</td></tr><tr><td>AWS Lambda</td><td>きっかけで動く短い処理。サーバー管理は不要</td><td>サーバーを管理せず、きっかけで動かす</td></tr><tr><td>AWS Fargate</td><td>コンテナーを動かすサーバーレスの場所</td><td>コンテナーを、サーバーを管理せずに動かす</td></tr><tr><td>AWS Elastic Beanstalk</td><td>コードを渡すと環境を用意する</td><td>コードを渡すだけで公開したい</td></tr><tr><td>Amazon Lightsail</td><td>手軽な月額のサーバー</td><td>手軽に、定額で、小さな Web サイト</td></tr><tr><td>AWS Batch</td><td>大量の仕事をまとめて処理</td><td>大量のバッチ処理、夜にまとめて集計</td></tr><tr><td>Amazon API Gateway</td><td>API の入口を受け持つ</td><td>外から呼ばれる窓口を作る</td></tr></tbody></table></figure>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1200" height="1540" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f04.png" alt="「この回の見分け方①：処理を動かす場所」の図。似たサービスの組ごとにカードを並べ、各カードに「ひとことで」と「問題文の手がかり」を示す。組「EC2／Lambda／Fargate」：「Amazon EC2」はひとことで「仮想サーバーを借りる。OS から上は利用者」、手がかりは「OS を自由に設定したい、長く動かし続ける」。「AWS Lambda」は「きっかけで動く短い処理。サーバー管理は不要」、手がかりは「サーバーを管理せず、きっかけで動かす」。「AWS Fargate」は「コンテナーを動かすサーバーレスの場所」、手がかりは「コンテナーを、サーバーを管理せずに動かす」。組「Elastic Beanstalk／Lightsail」：「AWS Elastic Beanstalk」は「コードを渡すと環境を用意する」、手がかりは「コードを渡すだけで公開したい」。「Amazon Lightsail」は「手軽な月額のサーバー」、手がかりは「手軽に、定額で、小さな Web サイト」。組「Batch／API Gateway」：「AWS Batch」は「大量の仕事をまとめて処理」、手がかりは「大量のバッチ処理、夜にまとめて集計」。「Amazon API Gateway」は「API の入口を受け持つ」、手がかりは「外から呼ばれる窓口を作る」。最下部の注記は「手がかりの言葉は、見分けるための目安で、試験の問題文そのものではありません。似たサービスの見分け方は、第14回でほかの回の分と合わせて振り返ります。」。" class="wp-image-13097" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f04.png 1200w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f04-300x385.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f04-546x701.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f04-117x150.png 117w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f04-768x986.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f04-1197x1536.png 1197w" sizes="(max-width: 1200px) 100vw, 1200px" /></figure>



<p class="wp-block-paragraph">補足：手がかりの言葉は、見分けるための目安で、試験の問題文そのものではありません。似たサービスの見分け方は、第14回（総まとめ）でほかの回の分と合わせて振り返ります（この回の組は、第14回③の「分野 3 ①：インフラと処理の場所」の節）。</p>



<p class="wp-block-paragraph">1行ずつ読み直します。</p>



<ul class="wp-block-list">
<li><strong>Amazon EC2</strong>：仮想サーバーを借りるサービスで、OS から上は利用者が扱います。「OS を自由に設定したい」「長く動かし続ける」が手がかりです</li>


<li><strong>AWS Lambda</strong>：きっかけがあったときに動く短い処理で、サーバーの管理は要りません。「サーバーを管理せず、きっかけで動かす」が手がかりです</li>


<li><strong>AWS Fargate</strong>：コンテナーを動かす、サーバーレスの場所です。「コンテナーを、サーバーを管理せずに動かす」が手がかりです</li>


<li><strong>AWS Elastic Beanstalk</strong>：コードを渡すと、環境を用意してくれます。「コードを渡すだけで公開したい」が手がかりです</li>


<li><strong>Amazon Lightsail</strong>：手軽な月額のサーバーです。「手軽に」「定額で」「小さな Web サイト」が手がかりです</li>


<li><strong>AWS Batch</strong>：大量の仕事をまとめて処理します。「大量のバッチ処理」「夜にまとめて集計」が手がかりです</li>


<li><strong>Amazon API Gateway</strong>：API の入口を受け持ちます。「外から呼ばれる窓口を作る」が手がかりです</li>
</ul>



<p class="wp-block-paragraph">EC2 と Lambda の違いは第04回④の「EC2 と Lambda の違い」の節、Fargate・Elastic Beanstalk・Lightsail・Batch は第04回⑤のそれぞれの節、API Gateway は第04回④の「Amazon API Gateway とは」の節に載せています。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">この回の見分け方②：コンテナーのサービス</span></h2>



<p class="wp-block-paragraph">次に、コンテナーを動かす5つのサービスの見分けです。第04回⑤の「コンテナーを動かす3つの役割」の節の「置く」「管理する」「動かす」の役割ごとに、並べています。</p>



<figure class="wp-block-table"><table><thead><tr><th>サービス</th><th>役割</th><th>ひとことで</th></tr></thead><tbody><tr><td>Amazon ECR</td><td>置く</td><td>イメージを保管して配る。コンテナーは動かさない</td></tr><tr><td>Amazon ECS</td><td>管理する</td><td>AWS が作った仕組みでコンテナーを管理する</td></tr><tr><td>Amazon EKS</td><td>管理する</td><td>Kubernetes でコンテナーを管理する</td></tr><tr><td>AWS Fargate</td><td>動かす</td><td>サーバーを管理せずに動かす。ECS・EKS で使う</td></tr><tr><td>Amazon EC2</td><td>動かす</td><td>サーバーを利用者が管理して動かす</td></tr></tbody></table></figure>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1200" height="1130" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f05.png" alt="「この回の見分け方②：コンテナーのサービス」の図。コンテナーの3つの役割ごとに、サービスのカードを並べる。「置く」：「Amazon ECR」はひとことで「イメージを保管して配る。コンテナーは動かさない」。「管理する：ECS／EKS」：「Amazon ECS」は「AWS が作った仕組みでコンテナーを管理する」、「Amazon EKS」は「Kubernetes でコンテナーを管理する」。「動かす：Fargate／EC2」：「AWS Fargate」は「サーバーを管理せずに動かす。ECS・EKS で使う」、「Amazon EC2」は「サーバーを利用者が管理して動かす」。最下部の注記は「3つの役割は、第04回⑤の「コンテナーを動かす3つの役割」の節と同じです。Fargate は ECS・EKS の代わりではありません。」。" class="wp-image-13098" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f05.png 1200w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f05-300x283.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f05-546x514.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f05-150x141.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f05-768x723.png 768w" sizes="(max-width: 1200px) 100vw, 1200px" /></figure>



<p class="wp-block-paragraph">補足：「置く」「管理する」「動かす」の3つの役割は、第04回⑤の「コンテナーを動かす3つの役割」の節と同じです。Fargate は ECS・EKS の代わりではありません。</p>



<ul class="wp-block-list">
<li><strong>置く</strong>：ECR。イメージを保管して配るだけで、コンテナーは動かしません</li>


<li><strong>管理する</strong>：ECS と EKS。AWS が作った仕組みなら ECS、Kubernetes なら EKS です</li>


<li><strong>動かす</strong>：Fargate と EC2。サーバーの管理を AWS に任せるなら Fargate、利用者が管理するなら EC2 です</li>


<li>Fargate は、ECS と EKS の両方で使える「動かす場所」で、ECS・EKS の代わりではありません</li>
</ul>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">この回の見分け方③：増やす・振り分ける・選ぶ</span></h2>



<p class="wp-block-paragraph">最後に、台数を増やして支える仕組みと、型の選び方の見分けです。第04回②の「インスタンスタイプのファミリー」の節と、第04回③の「垂直スケーリングと水平スケーリング」「Elastic Load Balancing（ELB）とは」「Auto Scaling とは」の節を、1つの表にしました。</p>



<figure class="wp-block-table"><table><thead><tr><th>項目</th><th>ひとことで</th><th>問題文の手がかり</th></tr></thead><tbody><tr><td>垂直スケーリング</td><td>1台を大きくする（スケールアップとも言う）</td><td>性能の高いサーバーに替える</td></tr><tr><td>水平スケーリング</td><td>台数を増やす（スケールアウトとも言う）・減らす</td><td>サーバーの台数を増やして対応する</td></tr><tr><td>ELB</td><td>複数のサーバー（ターゲット）に振り分ける</td><td>入口を1つにする、正常なサーバーにだけ送る</td></tr><tr><td>Auto Scaling</td><td>最小〜最大の範囲で、希望の台数に合わせて増減する</td><td>需要に応じて自動で台数を調整する</td></tr><tr><td>ファミリー</td><td>用途から選ぶ（第04回②の「インスタンスタイプのファミリー」の節の表）</td><td>計算・メモリ・読み書き・機械学習など、処理の種類に合う型を選ぶ</td></tr></tbody></table></figure>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1200" height="1540" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f06.png" alt="「この回の見分け方③：増やす・振り分ける・選ぶ」の図。迷いやすい組ごとにカードを並べ、各カードに「ひとことで」と「問題文の手がかり」を示す。組「垂直スケーリング／水平スケーリング」：「垂直スケーリング」は「1台を大きくする（スケールアップとも言う）」、手がかりは「性能の高いサーバーに替える」。「水平スケーリング」は「台数を増やす（スケールアウトとも言う）・減らす」、手がかりは「サーバーの台数を増やして対応する」。組「ELB／Auto Scaling」：「ELB」は「複数のサーバー（ターゲット）に振り分ける」、手がかりは「入口を1つにする、正常なサーバーにだけ送る」。「Auto Scaling」は「最小〜最大の範囲で、希望の台数に合わせて増減する」、手がかりは「需要に応じて自動で台数を調整する」。組「ファミリー」：「ファミリー」は「用途から選ぶ（第04回②の「インスタンスタイプのファミリー」の節の表）」、手がかりは「計算・メモリ・読み書き・機械学習など、処理の種類に合う型を選ぶ」。最下部の注記は「ELB は振り分け、Auto Scaling は台数の増減で、組み合わせて使います。ファミリーの一覧は変わることがあります（2026年10月26日時点）。」。" class="wp-image-13099" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f06.png 1200w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f06-300x385.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f06-546x701.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f06-117x150.png 117w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f06-768x986.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f06-1197x1536.png 1197w" sizes="(max-width: 1200px) 100vw, 1200px" /></figure>



<p class="wp-block-paragraph">補足：ELB は振り分け、Auto Scaling は台数の増減で、組み合わせて使います。ファミリーの一覧は変わることがあります（2026年10月26日時点）。</p>



<ul class="wp-block-list">
<li><strong>垂直スケーリング／水平スケーリング</strong>：垂直は <strong>1台を大きくする</strong>、水平は <strong>台数を増やす（減らす）</strong> です。「性能の高いサーバーに替える」なら垂直、「サーバーの台数を増やして対応する」なら水平と見分けます</li>


<li><strong>ELB／Auto Scaling</strong>：ELB は <strong>振り分け</strong>、Auto Scaling は <strong>台数の増減</strong> です。「入口を1つにする」「正常なサーバーにだけ送る」なら ELB、「需要に応じて自動で台数を調整する」なら Auto Scaling と見分けます。Auto Scaling の台数は、最小・希望・最大で決めます</li>


<li><strong>ファミリー</strong>：インスタンスタイプを <strong>用途から選ぶ</strong> 型の分類です。「計算・メモリ・読み書き・機械学習など」、処理の種類に合う型を選びます</li>
</ul>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc4">この回の要点</span></h2>



<p class="wp-block-paragraph">この回では、処理を動かす場所を用途で選ぶ見方を学びました。</p>



<p class="wp-block-paragraph">Amazon EC2 は仮想サーバーを借りるサービスで、OS から上は利用者が扱います。型は、用途に合うファミリーから選びます。台数で支えるときは、ELB が要求を振り分け、Auto Scaling が台数を増減します。組み合わせると、第02回②の「伸縮性」の節で見た伸縮性を実現でき、複数の AZ に置けば、第03回③の「複数 AZ に分けて置く」の節で見た高可用性にもつながります。</p>



<p class="wp-block-paragraph">AWS Lambda と AWS Fargate は、サーバーの管理が要らないサーバーレスで、API の入口は Amazon API Gateway が受け持ちます。コンテナーは ECR に置き、ECS か EKS で管理し、EC2 か Fargate で動かします。</p>



<ul class="wp-block-list">
<li><strong>EC2 は仮想サーバー。OS から上は利用者</strong></li>


<li><strong>ELB は振り分け、Auto Scaling は台数の増減</strong></li>


<li><strong>Lambda と Fargate はサーバーの管理が要らない</strong></li>
</ul>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc5">参考資料</span></h2>



<p class="wp-block-paragraph">この回で使った公式のページです。まず、EC2 と負荷分散の資料です。</p>



<figure class="wp-block-table"><table><thead><tr><th>資料</th><th>URL</th></tr></thead><tbody><tr><td>試験ガイド</td><td><a href="https://docs.aws.amazon.com/ja_jp/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02.html">https://docs.aws.amazon.com/ja_jp/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02.html</a></td></tr><tr><td>サービス一覧</td><td><a href="https://docs.aws.amazon.com/ja_jp/aws-certification/latest/cloud-practitioner-02/clf-02-in-scope-services.html">https://docs.aws.amazon.com/ja_jp/aws-certification/latest/cloud-practitioner-02/clf-02-in-scope-services.html</a></td></tr><tr><td>EC2</td><td><a href="https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/concepts.html">https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/concepts.html</a></td></tr><tr><td>ELB</td><td><a href="https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html">https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html</a></td></tr><tr><td>Auto Scaling</td><td><a href="https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html">https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html</a></td></tr></tbody></table></figure>



<p class="wp-block-paragraph">試験ガイドは全体の入口で、分野 3 のページ（タスク 3.3 の対象知識・スキル）へ進めます。サービス一覧は試験ガイドの対象のサービスの一覧です。EC2・ELB（Elastic Load Balancing）・Auto Scaling（Amazon EC2 Auto Scaling）は、それぞれのドキュメントの「とは」のページです。インスタンスタイプの一覧のドキュメントは、第04回②の「インスタンスタイプのファミリー」の節の補足にあります。URL は 2026年10月26日に開けることを確かめました。</p>



<p class="wp-block-paragraph">次に、サーバーレスとコンテナーの資料です。</p>



<figure class="wp-block-table"><table><thead><tr><th>資料</th><th>URL</th></tr></thead><tbody><tr><td>AWS Lambda</td><td><a href="https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html">https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html</a></td></tr><tr><td>Amazon API Gateway</td><td><a href="https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html">https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html</a></td></tr><tr><td>Amazon ECS</td><td><a href="https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html">https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html</a></td></tr><tr><td>ドキュメントの入口</td><td><a href="https://docs.aws.amazon.com/ja_jp/">https://docs.aws.amazon.com/ja_jp/</a></td></tr></tbody></table></figure>



<p class="wp-block-paragraph">AWS Lambda・Amazon API Gateway・Amazon ECS は、それぞれのドキュメントの「とは」のページです。ECR・EKS・Fargate・Elastic Beanstalk・Lightsail・Batch などは、ドキュメントの入口からサービス名で探せます。URL は 2026年10月26日に開けることを確かめました。内容は変わることがあるため、受験の前に公式のページで確かめてください。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc6">考えてみよう</span></h2>



<ol class="wp-block-list">
<li>冒頭の1つ目の相談に答えてみてください。「コードを渡すだけで公開したい」「手軽に、定額で、小さな Web サイト」「大量のバッチ処理、夜にまとめて集計」の3つの手がかりは、それぞれどのサービスを指すか、「この回の見分け方①」の表を使って説明してください</li>


<li>「ECR・ECS・EKS・Fargate・EC2」の5つを、「置く」「管理する」「動かす」の3つの役割に分けて説明してみてください。Fargate が ECS・EKS の代わりではない理由も添えてください</li>


<li>「性能の高いサーバーに替える」と「サーバーの台数を増やして対応する」の違いを、垂直スケーリングと水平スケーリングの言葉を使って説明してみてください。ELB と Auto Scaling は、それぞれ何を担うのかも添えてください</li>
</ol>



<p class="wp-block-paragraph"><strong>ヒント</strong>：1 は「この回の見分け方①：処理を動かす場所」、2 は「この回の見分け方②：コンテナーのサービス」、3 は「この回の見分け方③：増やす・振り分ける・選ぶ」を見直してください。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc7">まとめ（持ち帰ってほしい3点）</span></h2>



<p class="wp-block-paragraph">第04回の持ち帰りは、次の3点です。</p>



<ul class="wp-block-list">
<li><strong>EC2 は仮想サーバー、OS から上は利用者</strong></li>


<li><strong>ELB は振り分け、Auto Scaling は台数の増減</strong></li>


<li><strong>Lambda と Fargate はサーバーの管理が要らない</strong></li>
</ul>



<p class="wp-block-paragraph">1つ目は、第04回②の「Amazon EC2 とは」「EC2 でお客様が扱う範囲」の節の内容です。EC2 は仮想サーバーを借りるサービスで、AWS が扱うのは建物・物理サーバー・仮想化まで、OS から上は利用者が扱います。型は、用途に合うファミリーから選びます。</p>



<p class="wp-block-paragraph">2つ目は、第04回③の「ELB と Auto Scaling を組み合わせる」の節の内容です。ELB は要求を複数のサーバー（ターゲット）に振り分け、Auto Scaling は最小・希望・最大の台数に合わせて増減します。組み合わせて使います。</p>



<p class="wp-block-paragraph">3つ目は、第04回④の「サーバーレスとは」の節と、第04回⑤の「AWS Fargate」の節の内容です。AWS Lambda と AWS Fargate は、サーバーの用意や管理を AWS に任せるサーバーレスです。試験ガイドの対象のサービス一覧の分け方でも、「サーバーレス」は Lambda と Fargate です（2026年10月26日時点）。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">次の回の予告</span></h2>



<ul class="wp-block-list">
<li><strong>次の回</strong>：第05回 ストレージ</li>


<li><strong>扱うこと</strong>：ストレージの種類、EBS とインスタンスストア、S3 とストレージクラス、EFS・FSx・Storage Gateway、バックアップと災害対策</li>


<li><strong>試験との対応</strong>：分野 3 クラウドテクノロジーとサービス（34%）のタスク 3.6「AWS ストレージサービスを特定する」</li>


<li><strong>この回から持ち込むもの</strong>：EC2 のデータの置き場所という見方（第04回②の「EC2 を起動するときに選ぶもの」の節のストレージ）</li>


<li><strong>準備</strong>：特に無い。EC2 が仮想サーバーであることを思い出しておく</li>
</ul>



<p class="wp-block-paragraph">補足：第05回では、この回で名前だけ出てきた EBS を「EC2 のディスク」として説明します。第05回の記事は、第05回①「ストレージの種類」から第05回⑦「第05回のまとめ」までの7本です（EBS は第05回②）。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">連載「AWS クラウドプラクティショナー試験対策講座」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clf">AWS クラウドプラクティショナー試験対策講座の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/10/clf-01-1-about.html" target="_blank">第01回① CLF はどんな資格か（AWS 認定のレベル・CLF の位置づけ・誰向けか・問われること／問われないこと・身につくもの）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-2-exam-format.html" target="_blank">第01回② 試験の形式と合格基準（試験の基本情報・2種類の設問・採点される50問・換算スコアと合格点・補整型・結果・受験の流れ・再受験と有効期間）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-3-domains.html" target="_blank">第01回③ 出題の範囲と配点（4つの分野と配点・試験ガイドの組み立て・分野ごとのタスク・配点と学ぶ量・対象外のサービス）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-4-study-plan.html" target="_blank">第01回④ 講座の進め方と学び方（全14回の地図・深さの印・学び方の輪・公式の学習リソース・AWS を触るときの注意・問題文の読み方・早見表）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-02-1-what-is-cloud.html" target="_blank">第02回① クラウドとは（3つの特徴・オンプレミスとの違い・使い始めるまでの速さ・IaaS／PaaS／SaaS・デプロイモデルと選び方）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-2-benefits.html" target="_blank">第02回② AWS クラウドの利点（価値提案・6つのメリット・高可用性・伸縮性・俊敏性・例で見分ける）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-3-economics.html" target="_blank">第02回③ クラウドエコノミクス（固定費と変動費・オンプレミスのコスト・総保有コスト・規模の経済・適切なサイジング・BYOL・オートメーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-4-summary.html" target="_blank">第02回④ 第02回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-1-services.html" target="_blank">第03回① サービスの全体像（この回のねらい・この講座について・前の回の振り返り・サービスの集まり・カテゴリ・カテゴリと講座の回）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-2-global-infra.html" target="_blank">第03回② グローバルインフラ（リージョン・AZ・エッジロケーション・3つの関係と比較・Local Zones・Outposts）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-3-high-availability.html" target="_blank">第03回③ 高可用性と複数リージョン（単一障害点・複数 AZ・サービスごとの AZ・複数リージョンの理由・リージョンの選び方）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-4-access.html" target="_blank">第03回④ AWS へのアクセス方法（API・コンソール・CLI・SDK・IaC・CloudFormation・1回限りと繰り返す作業）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-5-summary.html" target="_blank">第03回⑤ 第03回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-1-servers.html" target="_blank">第04回① サーバーと仮想マシン（この回のねらい・この講座について・前の回の振り返り・コンピューティングとサーバー・仮想マシン・コンピューティングの全体像）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-2-ec2.html" target="_blank">第04回② Amazon EC2（EC2 とは・ユースケース・お客様が扱う範囲・インスタンスタイプ・ファミリーと選び方・起動するときに選ぶもの）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-3-elb-autoscaling.html" target="_blank">第04回③ ELB と Auto Scaling（1台のサーバーの限界・垂直と水平のスケーリング・ロードバランサーの目的・ELB とその種類・Auto Scaling・組み合わせ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-4-serverless.html" target="_blank">第04回④ サーバーレス（サーバーレスとは・AWS Lambda とその特徴・ユースケース・Amazon API Gateway・EC2 と Lambda の違い）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-5-containers.html" target="_blank">第04回⑤ コンテナーとほかの選択肢（コンテナーとは・3つの役割・ECR・ECS と EKS・Fargate・Elastic Beanstalk・Lightsail・Batch）</a></li>


<li><strong>第04回⑥ 第04回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）（この記事）</strong></li>


<li>第05回① ストレージの種類（この回のねらい・この講座について・前の回の振り返り・ストレージとは・ブロック・ファイル・オブジェクト・3つの種類の比べ方・AWS のストレージの地図）</li>


<li>第05回② EBS とインスタンスストア（Amazon EBS・AZ の中でのレプリケート・スナップショット・EBS の暗号化・インスタンスストア・2つの違い）</li>


<li>第05回③ Amazon S3 とストレージクラス（S3 とは・S3 の特徴・ユースケース・ストレージクラスの考え方・ストレージクラスの一覧）</li>


<li>第05回④ Glacier とライフサイクル（S3 Glacier のクラス・クラスの選び方・ライフサイクルポリシー・ライフサイクルのユースケース・S3 のセキュリティ）</li>


<li>第05回⑤ ファイルとハイブリッド（Amazon EFS・Amazon FSx・ハイブリッドクラウドとストレージ・AWS Storage Gateway・Storage Gateway の種類）</li>


<li>第05回⑥ バックアップと災害対策（バックアップと災害対策の違い・AWS Backup・ユースケース・AWS Elastic Disaster Recovery・データを守る仕組みの重ね方）</li>


<li>第05回⑦ 第05回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第06回① ネットワークの基本（この回のねらい・この講座について・前の回の振り返り・IP アドレスとネットワークの範囲・ルーティングとゲートウェイ・ポートとプロトコル・この回のサービスの地図）</li>


<li>第06回② VPC とサブネット（Amazon VPC とは・サブネット・パブリックサブネットとプライベートサブネット・インターネットゲートウェイ・NAT ゲートウェイ・ルートテーブル）</li>


<li>第06回③ セキュリティグループとネットワーク ACL（セキュリティグループ・ネットワーク ACL・2つの違い・VPC フローログ・VPC の全体を見る）</li>


<li>第06回④ VPC の外とつなぐ（つなぐ先は3つ・AWS Transit Gateway・AWS PrivateLink・オンプレミスとつなぐ方法）</li>


<li>第06回⑤ VPN と Direct Connect（AWS Site-to-Site VPN・AWS Client VPN・AWS Direct Connect・VPN と Direct Connect の比べ方）</li>


<li>第06回⑥ DNS と Route 53（DNS とドメイン名・Amazon Route 53・Route 53 のルーティングの方法）</li>


<li>第06回⑦ CloudFront と Global Accelerator（エッジロケーションとキャッシュ・Amazon CloudFront・CloudFront の使いどころ・AWS Global Accelerator・CloudFront と Global Accelerator の違い）</li>


<li>第06回⑧ 第06回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第07回① データベースとは（この回のねらい・この講座について・前の回の振り返り・データベースとは・テーブル・行・列・SQL とは）</li>


<li>第07回② データベースの種類（リレーショナルデータベース・NoSQL データベース・インメモリデータベース・3つの種類の比べ方・EC サイトで使い分けると）</li>


<li>第07回③ 自分で運用か任せるか（データベースを動かすのに要る作業・EC2 上のデータベース・マネージドデータベース・作業の分担の比べ方・使い分けの考え方）</li>


<li>第07回④ RDS とマルチ AZ 配置（Amazon RDS とは・RDS で選べるエンジン・RDS で AWS が引き受けること・マルチ AZ 配置・フェイルオーバー）</li>


<li>第07回⑤ リードレプリカと Aurora（リードレプリカ・マルチ AZ 配置とリードレプリカの違い・Amazon Aurora・RDS と Aurora の関係）</li>


<li>第07回⑥ Amazon DynamoDB（DynamoDB とは・DynamoDB の特長・DynamoDB のテーブル・DynamoDB と RDS の違い）</li>


<li>第07回⑦ ElastiCache・DocumentDB・Neptune（Amazon ElastiCache・キャッシュの置き方・Amazon DocumentDB・Amazon Neptune・ほかの回で扱う DB の話題）</li>


<li>第07回⑧ 第07回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第08回① 疎結合とつなぎ方の言葉（この回のねらい・この講座について・前の回の振り返り・疎結合とは・つなぎ方の言葉）</li>


<li>第08回② SQS と SNS（Amazon SQS の仕組み・SQS の使いどころ・Amazon SNS の仕組み・SNS の使いどころ）</li>


<li>第08回③ EventBridge と Step Functions（Amazon EventBridge の仕組み・EventBridge の使いどころ・AWS Step Functions の仕組み・Step Functions の使いどころ・SNS・SQS・EventBridge の使い分け・メッセージと通知のサービスを選ぶ）</li>


<li>第08回④ AI と機械学習のサービス（AI と機械学習の言葉・AI/ML のサービスの全体像・画像・文書・文章のサービス・音声と会話のサービス・生成 AI のサービス）</li>


<li>第08回⑤ データ分析のサービス（データ分析の流れ・集める・加工するサービス・分析・見える化のサービス・Athena・Redshift・EMR の違い）</li>


<li>第08回⑥ 業務と開発のサービス（ビジネスアプリケーション・エンドユーザーコンピューティング・開発者ツール・CI/CD の流れ・フロントエンドと IoT）</li>


<li>第08回⑦ 第08回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第09回① 監視の基本と CloudWatch（この回のねらい・この講座について・前の回の振り返り・3つの困りごとと3つのサービス・Amazon CloudWatch・CloudWatch のアラーム・CloudWatch Logs と標準で取れないもの）</li>


<li>第09回② AWS CloudTrail（AWS CloudTrail・CloudTrail の記録の残し方・CloudTrail の使いどころ）</li>


<li>第09回③ AWS Config と3つの使い分け（AWS Config・Config ルールと準拠の確認・CloudTrail と Config の違い・3つの使い分け・3つを組み合わせる流れ）</li>


<li>第09回④ Trusted Advisor と AWS Health（AWS Trusted Advisor・Trusted Advisor のチェックのカテゴリ・サポートプランと使えるチェック・AWS Health Dashboard・AWS Health API・Trusted Advisor・Health・CloudWatch の違い）</li>


<li>第09回⑤ 運用管理の道具（AWS Systems Manager・AWS Compute Optimizer・Service Quotas と License Manager・運用管理の使い分け）</li>


<li>第09回⑥ Organizations と SCP（なぜアカウントを分けるのか・AWS Organizations・Organizations でできること・サービスコントロールポリシー（SCP）・SCP と IAM の関係）</li>


<li>第09回⑦ Control Tower・Service Catalog・RAM（AWS Control Tower・AWS Service Catalog・AWS RAM）</li>


<li>第09回⑧ 第09回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第10回① クラウドで守る利点と責任共有モデル（この回のねらい・この講座について・前の回の振り返り・クラウドで守る利点・責任共有モデルとは）</li>


<li>第10回② 責任の分かれ方（AWS の責任（クラウドのセキュリティ）・お客様の責任（クラウド内のセキュリティ）・共有する管理・サービスで変わる責任）</li>


<li>第10回③ 暗号化と KMS・CloudHSM・ACM（転送時と保管時の暗号化・AWS KMS・AWS CloudHSM・AWS Certificate Manager（ACM））</li>


<li>第10回④ AWS アカウントとルートユーザー（AWS アカウントとルートユーザー・ルートユーザーだけができる作業・ルートユーザーの守り方）</li>


<li>第10回⑤ IAM と最小権限（IAM の全体像・IAM ユーザーとグループ・IAM ロール・ポリシーの種類・最小権限の原則とアクセスレポート）</li>


<li>第10回⑥ MFA・フェデレーション・認証情報の保管（パスワード・MFA・アクセスキー・クロスアカウントの IAM ロール・フェデレーションと IAM アイデンティティセンター・Directory Service と Cognito・認証情報の保管）</li>


<li>第10回⑦ Shield・WAF・Firewall Manager（守りの層・AWS Shield・AWS WAF・AWS Firewall Manager・Shield・WAF・Firewall Manager の使い分け）</li>


<li>第10回⑧ 検出と調査のサービス（Amazon GuardDuty・Amazon Inspector・Amazon Macie・Amazon Detective・AWS Security Hub・検出と調査の使い分け）</li>


<li>第10回⑨ コンプライアンスと情報源（コンプライアンスの考え方・第三者認証と地域・業界・AWS Artifact・監査に使うログ・AWS Marketplace のセキュリティ製品・セキュリティ情報の入手先）</li>


<li>第10回⑩ 第10回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第11回① Well-Architected フレームワークと6つの柱（この回のねらい・この講座について・前の回の振り返り・この回の役割・Well-Architected フレームワークとは・6つの柱の全体像）</li>


<li>第11回② 柱の問いと Well-Architected Tool（柱が答える問い・一般的な設計原則・柱どうしのトレードオフ・Well-Architected Tool）</li>


<li>第11回③ 6つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性・柱と回の対応）</li>


<li>第11回④ 柱どうしの見分け方（信頼性とパフォーマンス効率・コスト最適化と持続可能性・運用上の優秀性と信頼性・セキュリティの柱と第10回）</li>


<li>第11回⑤ 問題文と事例で柱を選ぶ（問題文の言葉から柱を選ぶ・ある EC サイトの会社の構成・柱の目で見直す）</li>


<li>第11回⑥ 故障に備えた設計と疎結合（4つの原則の全体像・故障に備えた設計・コンポーネントの分離（疎結合））</li>


<li>第11回⑦ 伸縮性・並列化と4つの原則（伸縮性の活用・並列化を考慮する・4つの原則と柱）</li>


<li>第11回⑧ 第11回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第12回① 移行とは何か（この回のねらい・この講座について・前の回の振り返り・移行とは何か・この回の例の会社）</li>


<li>第12回② 移行の流れと利点（移行の大まかな流れ・移行の利点・移行を支えるリソース）</li>


<li>第12回③ AWS CAF の6つの観点（AWS CAF とは・6つの観点・ビジネス寄りの3つの観点・技術寄りの3つの観点・期待できる成果・CAF と Well-Architected の違い）</li>


<li>第12回④ 7つの R と移し方（7つの R とは・そのまま移す：リホストとリロケート・少し手を加える：リプラットフォーム・作り直す：リファクタリング（リアーキテクト）・4つの R を並べて見分ける）</li>


<li>第12回⑤ 買い替える・移さない戦略（買い替える：リパーチェス・移さない：リテインとリタイア・例の会社に当てはめる）</li>


<li>第12回⑥ 評価のサービスと AWS MGN（移行のサービスの地図・費用を見積もる：Migration Evaluator・環境を調べる：Application Discovery Service・進み具合を1か所で見る：Migration Hub・サーバーを移す：AWS MGN）</li>


<li>第12回⑦ データベースの移行：DMS と SCT（データベースの移行とは・AWS DMS・止めずに移す：データベースのレプリケーション・設計を変換する：AWS SCT・DMS と SCT の組み合わせ）</li>


<li>第12回⑧ Snow ファミリーと例の会社の移行（大容量データを運ぶ：Snow ファミリー・例の会社の移行を通して見る）</li>


<li>第12回⑨ 第12回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第13回① 従量課金と料金の決まり方（この回のねらい・この講座について・前の回の振り返り・従量課金と料金の決まり方）</li>


<li>第13回② データ転送とストレージの料金（データ転送：受信と送信・データ転送：リージョン内とリージョン間・ストレージの料金）</li>


<li>第13回③ サービスごとの料金と無料利用枠（安いクラスを選ぶときの注意・サービスごとの料金の決まり方・AWS 無料利用枠）</li>


<li>第13回④ オンデマンドとリザーブドインスタンス（購入オプションの全体像・オンデマンドインスタンス・リザーブドインスタンス（RI）・RI の柔軟性・Organizations での割引の共有）</li>


<li>第13回⑤ Savings Plans・スポットと使い分け（Savings Plans・RI と Savings Plans の違い・スポットインスタンス・専有ホストとハードウェア専有インスタンス・キャパシティーの予約・購入オプションの使い分け）</li>


<li>第13回⑥ 見積り・予算・分析の道具（コスト管理の道具の全体像・AWS 料金見積りツール・AWS Budgets・AWS Cost Explorer・AWS Cost and Usage Report）</li>


<li>第13回⑦ タグ・一括請求とコスト改善（コスト配分タグ・AWS Organizations の一括請求・請求と料金の情報・コスト改善の考え方）</li>


<li>第13回⑧ 困ったときの窓口とサポートプラン（困ったときの窓口の全体像・サポートプランの比較・サポートプランと Trusted Advisor のチェック・AWS サポートセンター）</li>


<li>第13回⑨ Trust &#038; Safety・パートナー・Marketplace（AWS Trust &#038; Safety チーム・技術リソース・AWS パートナーネットワーク（APN）・AWS Marketplace・技術支援）</li>


<li>第13回⑩ 第13回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第14回① 見分け方の表と分野 1（この回のねらい・この講座について・前の回の振り返り・見分け方の表の読み方・分野 1 ①：クラウドの性質と費用・分野 1 ②：設計と移行の考え方）</li>


<li>第14回② 分野 2 の見分け方（分野 2 ①：責任共有モデル・分野 2 ②：アクセスと鍵の管理・分野 2 ③：攻撃からの守りと検出・分野 2 ④：記録・監査・統制）</li>


<li>第14回③ 分野 3 の見分け方（分野 3 ①：インフラと処理の場所・分野 3 ②：ストレージ・データベース・移行・分野 3 ③：ネットワーク・分野 3 ④：連携・分析・AI）</li>


<li>第14回④ 分野 4 の見分け方と5つの問い（分野 4 ①：料金と購入オプション・分野 4 ②：コスト管理とサポート・見分けの5つの問い）</li>


<li>第14回⑤ 条件の言葉と主語（基本から一歩進める・条件の言葉①：運用と費用・条件の言葉②：可用性と性能・条件の言葉③：守りと統制・主語を見る：AWS かお客様か）</li>


<li>第14回⑥ 似た言葉と問題文を読む順（似た言葉の取り違え・名前が似ているサービス・時間の配分と見直し・問題文を読む順）</li>


<li>第14回⑦ 受験の申し込みと本人確認（申し込みから結果までの流れ・テストセンターとオンライン・申し込みの手順・本人確認と身分証明書・持ち物と持ち込めないもの）</li>


<li>第14回⑧ オンライン受験の環境と当日（オンライン受験の環境・予約の変更と取り消し・当日の流れと遅刻・試験の後）</li>


<li>第14回⑨ 第14回のまとめ（各回の見分け方の一覧・この回の要点・全14回を終えたら・参考資料）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clf-04-6-summary.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【CLF-C02 試験対策問題 第27問】だれが操作したかを調べる（AWS CloudTrail）</title>
		<link>https://www.seichan.org/2026/11/clfq-027-cloudtrail.html</link>
					<comments>https://www.seichan.org/2026/11/clfq-027-cloudtrail.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Sat, 14 Nov 2026 00:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[AWS資格]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[CLF-C02 試験対策問題]]></category>
		<category><![CDATA[練習問題]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=16134</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の練習問題・第27問。セキュリティグループに追加された SSH のルールを、だれが・いつ・どこから変えたか調べるサービスを選ぶ問題です。正解の CloudTrail と、誤りの VPC フローログ・メトリクス・Config の違いを図で解説します。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「CloudTrail・Config・フローログ・CloudWatch は、どれも『記録』のサービスに見えて、問題になると区別がつきません」<br>「設定が変わったことが分かる Config なら、だれが変えたかも分かると思っていました」</p>



<p class="wp-block-paragraph">AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 <strong>CLF</strong>）では、<strong>何を記録するサービスかで、操作・設定・通信・数値を見分ける</strong>問題がよく出ます。「だれが・いつ・どこから」のような問いの言葉から、どのサービスの記録かを選びます。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/YzUinMdD67g" target="_blank">YouTube の動画（約4分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-4" checked><label class="toc-title" for="toc-checkbox-4">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">問題</a></li><li><a href="#toc2" tabindex="0">正解は D</a></li><li><a href="#toc3" tabindex="0">選択肢ごとの解説</a><ol><li><a href="#toc4" tabindex="0">A：フローログは通信の記録（誤り）</a></li><li><a href="#toc5" tabindex="0">B：メトリクスは数値の記録（誤り）</a></li><li><a href="#toc6" tabindex="0">C：Config は設定の変化の記録（誤り）</a></li><li><a href="#toc7" tabindex="0">D：CloudTrail が操作を記録（正解）</a></li></ol></li><li><a href="#toc8" tabindex="0">記録するもので選ぶ</a></li><li><a href="#toc9" tabindex="0">ポイント</a></li><li><a href="#toc10" tabindex="0">動画で見る</a></li><li><a href="#toc11" tabindex="0">連載「CLF-C02 試験対策問題」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">問題</span></h2>



<p class="wp-block-paragraph">ある企業で、本番環境のセキュリティグループに、すべての IP アドレス（0.0.0.0/0）からSSH の接続を許可するルールが、いつの間にか追加されていました。この変更を、だれが、いつ、どこの IP アドレスから行ったかを調べたいと考えています。どの AWS サービスを使いますか。</p>



<ul class="wp-block-list">
<li><strong>A.</strong> VPC フローログ</li>


<li><strong>B.</strong> Amazon CloudWatch のメトリクス</li>


<li><strong>C.</strong> AWS Config</li>


<li><strong>D.</strong> AWS CloudTrail</li>
</ul>



<p class="wp-block-paragraph">答えを決めたら、下を開いてください。</p>



<details class="quiz-answer"><summary><strong>正解を見る</strong>（クリックで開きます）</summary>
<p><strong>正解：D</strong></p>
<p>AWS CloudTrail は、AWS の<strong>操作（API の呼び出し）</strong>を記録するサービスです。だれが、いつ、どこの IP アドレスから、何をしたかが、操作1件ごとに残ります。</p>
</details>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">正解は D</span></h2>



<p class="wp-block-paragraph">正解は <strong>D</strong> です。</p>



<p class="wp-block-paragraph">AWS CloudTrail は、API の呼び出し、つまり <strong>AWS の操作</strong>を記録するサービスです。だれが、いつ、どこの IP アドレスから、何をしたかが分かります。ここから、選択肢を1つずつ見ていきます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">選択肢ごとの解説</span></h2>



<h3 class="wp-block-heading"><span id="toc4">A：フローログは通信の記録（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-a-flowlogs.png" alt="左に VPC フローログ（通信の情報を記録する）、中央に記録するもの「出入りする通信」。ネットワークインターフェイスを通る入る通信・出る通信と、送信元・送信先・ポート・結果の表（22 番は ACCEPT、3389 番は REJECT など）。右は、だれが・いつ・どこの IP アドレスからに対し、×「通信の記録。設定を変えた操作は記録しない」" class="wp-image-16129" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-a-flowlogs.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-a-flowlogs-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-a-flowlogs-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-a-flowlogs-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-a-flowlogs-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-a-flowlogs-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">VPC フローログは、ネットワークインターフェイスを出入りする、<strong>通信</strong>の情報を記録します。図の中央のように、送信元と送信先の IP アドレス、ポート、許可されたかどうか、などです。</p>



<p class="wp-block-paragraph">記録するのは通信です。セキュリティグループを変えた操作は、記録しません。</p>



<h3 class="wp-block-heading"><span id="toc5">B：メトリクスは数値の記録（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-b-metrics.png" alt="左に Amazon CloudWatch のメトリクス（数値を記録してグラフにする）、中央に記録するもの「数値（メトリクス）」。10:00 から 12:00 の CPU の使用率の折れ線グラフで、11:00 ごろに最も高い。右は、だれが・いつ・どこの IP アドレスからに対し、×「数値の記録。だれが操作したかは分からない」" class="wp-image-16130" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-b-metrics.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-b-metrics-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-b-metrics-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-b-metrics-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-b-metrics-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-b-metrics-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon CloudWatch のメトリクスは、CPU の使用率などの<strong>数値</strong>を、時間を追って記録するものです。図の中央のようにグラフにして、リソースの状態を監視するのに使います。</p>



<p class="wp-block-paragraph">数値の記録なので、だれが操作したかは分かりません。</p>



<h3 class="wp-block-heading"><span id="toc6">C：Config は設定の変化の記録（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-c-config.png" alt="左に AWS Config（リソースの設定の変化を記録する）、中央に記録するもの「設定の変化」。変更前は SSH：社内の IP、変更後は社内の IP に加えて赤字の SSH：0.0.0.0/0 が増え、「何が変わったかは分かる」。だれが変えたかは CloudTrail の記録と結び付けて調べる。右は×「設定の変化の記録。だれがは CloudTrail にある」" class="wp-image-16131" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-c-config.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-c-config-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-c-config-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-c-config-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-c-config-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-c-config-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">AWS Config は、リソースの設定がどう変わったかを、変更前と変更後で記録します。図の中央のように、SSH を許可するルールが増えたことは分かります。</p>



<p class="wp-block-paragraph">ただし、だれが API を呼んだかの記録は、<strong>CloudTrail</strong> にあります。だれが変えたかは、CloudTrail の記録と結び付けて調べます。</p>



<h3 class="wp-block-heading"><span id="toc7">D：CloudTrail が操作を記録（正解）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="610" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-d-cloudtrail.png" alt="IAM ユーザーなどが API の呼び出しで本番のセキュリティグループに SSH：0.0.0.0/0 を追加し、AWS CloudTrail が記録する。イベント（操作1件ごと）は、だれが：IAM ユーザー dev-taro、いつ：2026-10-24 23:14、どこから：送信元の IP アドレス 203.0.113.25、何を：ルールを追加する API。下に、イベント履歴は過去90日を無料、90日より長くは証跡を作って S3 に保存" class="wp-image-16132" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-d-cloudtrail.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-d-cloudtrail-300x114.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-d-cloudtrail-546x208.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-d-cloudtrail-150x57.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-d-cloudtrail-768x293.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq027-d-cloudtrail-1536x586.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">AWS CloudTrail は、コンソール、CLI、SDK からの、API の呼び出しを記録します。図の右のように、<strong>だれが・いつ・どこから・何を</strong>したかが、操作1件ごとに残ります。今回は、セキュリティグループにルールを追加した操作の記録を探します。</p>



<p class="wp-block-paragraph">CloudTrail は、何も設定しなくても有効です。イベント履歴で、過去90日の管理イベントを、無料で見られます。90日より長く残すには、証跡を作って、S3 に保存します。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">記録するもので選ぶ</span></h2>



<p class="wp-block-paragraph">4つのサービスを、記録するもので整理します。試験では、<strong>操作・設定・通信・数値</strong>という言葉で見分けましょう。</p>



<figure class="wp-block-table"><table><thead><tr><th>知りたいこと</th><th>記録するもの</th><th>サービス</th></tr></thead><tbody><tr><td><strong>だれが・いつ・どこから</strong> <strong>操作したか</strong></td><td><strong>API の呼び出し（操作）</strong></td><td><strong>AWS CloudTrail</strong></td></tr><tr><td>設定がどう変わったか</td><td>リソースの設定（変更前と変更後）</td><td>AWS Config</td></tr><tr><td>どんな通信があったか</td><td>ネットワークインターフェイスを出入りする通信</td><td>VPC フローログ</td></tr><tr><td>数値やログの監視</td><td>CPU の使用率などの数値・ログ</td><td>Amazon CloudWatch</td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">ポイント</span></h2>



<ul class="wp-block-list">
<li>だれが・いつ・どこから <strong>操作</strong> したか ＝ <strong>AWS CloudTrail</strong></li>


<li>何も設定しなくても有効。<strong>イベント履歴</strong> で過去 <strong>90日</strong> の管理イベントを見られる</li>


<li>設定の変化 ＝ <strong>Config</strong>、通信 ＝ <strong>VPC フローログ</strong>、数値の監視 ＝ <strong>CloudWatch</strong></li>
</ul>



<p class="wp-block-paragraph">CloudTrail の記録の残し方と、CloudTrail・Config・CloudWatch の使い分けは、講座の記事で詳しく解説しています。</p>



<ul class="wp-block-list">
<li>講座の第09回②「AWS CloudTrail」（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>


<li>講座の第09回③「AWS Config と3つの使い分け」の「CloudTrail と Config の違い」の節（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>
</ul>



<p class="wp-block-paragraph">講座の全14回は、<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から順に読めます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約4分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="だれが操作したかを調べる（AWS CloudTrail）【CLF-C02】AWS クラウドプラクティショナー 試験対策問題 第27問" width="1256" height="707" src="https://www.youtube.com/embed/YzUinMdD67g?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">連載の全回は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLSxdgP1WVL3E" target="_blank">再生リスト「CLF-C02 試験対策問題」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc11">連載「CLF-C02 試験対策問題」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clfq">CLF-C02 試験対策問題の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/11/clfq-001-cost-benefits.html" target="_blank">第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-002-global-reach.html" target="_blank">第2問 数分でグローバルに展開（世界同時公開と低い遅延）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-003-high-availability.html" target="_blank">第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-004-agility.html" target="_blank">第4問 クラウドの俊敏性（数分で作成・すぐに削除）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-005-rehost-responsibility.html" target="_blank">第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-006-peak-scaling.html" target="_blank">第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-007-well-architected-pillars.html" target="_blank">第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-008-reliability-principles.html" target="_blank">第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-009-sustainability-principles.html" target="_blank">第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-010-caf-phases.html" target="_blank">第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-011-caf-operations.html" target="_blank">第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-012-migration-evaluator.html" target="_blank">第12問 移行のビジネスケース（Migration Evaluator）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-013-caf-people.html" target="_blank">第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-014-transform-mgn.html" target="_blank">第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-015-datasync.html" target="_blank">第15問 ファイルの移行（AWS DataSync）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-016-repurchase.html" target="_blank">第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-017-right-sizing.html" target="_blank">第17問 適切なサイズ設定（CPU は余り、メモリが不足）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-018-lambda-rds-responsibility.html" target="_blank">第18問 責任共有モデル（Lambda と RDS）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-019-least-privilege.html" target="_blank">第19問 最小権限の原則（IAM のポリシーと SCP）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-020-aws-responsibility.html" target="_blank">第20問 責任共有モデル（EC2 と S3、AWS の責任）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-021-shared-controls.html" target="_blank">第21問 共有統制の例（責任共有モデルの IT 統制）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-022-artifact.html" target="_blank">第22問 コンプライアンスの資料と契約（AWS Artifact）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-023-guardduty.html" target="_blank">第23問 脅威の検出（Amazon GuardDuty）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-024-inspector.html" target="_blank">第24問 脆弱性の継続的なスキャン（Amazon Inspector）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-025-macie.html" target="_blank">第25問 S3 の機密データの検出（Amazon Macie）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html" target="_blank">第26問 S3 の保管時の暗号化とキーの管理</a></li>


<li><strong>第27問 だれが操作したかを調べる（AWS CloudTrail）（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clfq-028-credential-report.html" target="_blank">第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-029-iam-role.html" target="_blank">第29問 EC2 のアプリケーションに権限を与える（IAM ロール）</a></li>


<li>第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）</li>


<li>第31問 社員に一時的な認証情報を発行するサービス（AWS STS）</li>


<li>第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）</li>


<li>第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）</li>


<li>第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）</li>


<li>第35問 追加料金なしの DDoS 保護（AWS Shield Standard）</li>


<li>第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）</li>


<li>第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）</li>


<li>第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）</li>


<li>第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）</li>


<li>第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）</li>


<li>第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）</li>


<li>第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）</li>


<li>第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）</li>


<li>第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）</li>


<li>第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）</li>


<li>第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）</li>


<li>第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）</li>


<li>第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）</li>


<li>第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）</li>


<li>第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）</li>


<li>第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）</li>


<li>第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）</li>


<li>第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）</li>


<li>第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）</li>


<li>第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）</li>


<li>第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）</li>


<li>第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）</li>


<li>第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）</li>


<li>第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）</li>


<li>第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）</li>


<li>第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）</li>


<li>第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）</li>


<li>第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）</li>


<li>第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）</li>


<li>第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）</li>


<li>第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）</li>


<li>第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）</li>


<li>第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）</li>


<li>第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）</li>


<li>第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）</li>


<li>第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）</li>


<li>第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）</li>


<li>第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）</li>


<li>第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）</li>


<li>第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）</li>


<li>第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）</li>


<li>第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）</li>


<li>第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）</li>


<li>第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）</li>


<li>第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）</li>


<li>第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）</li>


<li>第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）</li>


<li>第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）</li>


<li>第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）</li>


<li>第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）</li>


<li>第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）</li>


<li>第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）</li>


<li>第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）</li>


<li>第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）</li>


<li>第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）</li>


<li>第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）</li>


<li>第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）</li>


<li>第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）</li>


<li>第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）</li>


<li>第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）</li>


<li>第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）</li>


<li>第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）</li>


<li>第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）</li>


<li>第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）</li>


<li>第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clfq-027-cloudtrail.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【CLF-C02 試験対策問題 第26問】S3 の保管時の暗号化とキーの管理</title>
		<link>https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html</link>
					<comments>https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Fri, 13 Nov 2026 06:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[AWS資格]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[CLF-C02 試験対策問題]]></category>
		<category><![CDATA[練習問題]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=16127</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の練習問題・第26問。S3 に保管するファイルの暗号化で、キーを自社で管理し、だれが使えるかも自社で決める方法を2つ選ぶ問題です。正解の SSE-KMS とクライアント側の暗号化、誤りの HTTPS・SSE-S3・バージョニングを、図で解説します。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「S3 は自動で暗号化されると聞いたのに、キーを自社で管理したい問題で『SSE-S3 に任せる』が誤りなのはなぜですか」<br>「HTTPS で通信を暗号化すれば、保管したファイルも守れると思っていました」</p>



<p class="wp-block-paragraph">AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 <strong>CLF</strong>）では、<strong>S3 の暗号化で、キーをだれが管理するかを見分ける</strong>問題が出ます。転送中と保管時の違い、サーバー側とクライアント側の違い、SSE-S3 と SSE-KMS の違いを、「キーを自社で管理し、だれが使えるかを自社で決める」という要件の言い回しから選びます。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/vrIjeyLdeHo" target="_blank">YouTube の動画（約5分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-5" checked><label class="toc-title" for="toc-checkbox-5">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">問題</a></li><li><a href="#toc2" tabindex="0">正解は B と D</a></li><li><a href="#toc3" tabindex="0">選択肢ごとの解説</a><ol><li><a href="#toc4" tabindex="0">A：HTTPS は転送中の保護（誤り）</a></li><li><a href="#toc5" tabindex="0">B：SSE-KMS はキーを自社で管理（正解）</a></li><li><a href="#toc6" tabindex="0">C：SSE-S3 のキーは S3 が管理（誤り）</a></li><li><a href="#toc7" tabindex="0">D：クライアント側はすべて自社で管理（正解）</a></li><li><a href="#toc8" tabindex="0">E：バージョニングは古い版を残す（誤り）</a></li></ol></li><li><a href="#toc9" tabindex="0">暗号化の方法とキーの管理者</a></li><li><a href="#toc10" tabindex="0">ポイント</a></li><li><a href="#toc11" tabindex="0">動画で見る</a></li><li><a href="#toc12" tabindex="0">連載「CLF-C02 試験対策問題」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">問題</span></h2>



<p class="wp-block-paragraph">ある企業は、Amazon S3 に保存する契約書のファイルを、保管時に暗号化します。社内の規程で、暗号化に使うキーは自社で管理し、だれがキーを使えるかを自社で決められるようにする必要があります。この要件を満たす方法はどれですか。<strong>（2つ選択）</strong></p>



<ul class="wp-block-list">
<li><strong>A.</strong> バケットポリシーで、HTTPS の通信だけを許可する</li>


<li><strong>B.</strong> AWS KMS のカスタマーマネージドキーを使い、サーバー側の暗号化（SSE-KMS）でオブジェクトを暗号化する</li>


<li><strong>C.</strong> Amazon S3 マネージドキーによるサーバー側の暗号化（SSE-S3）に任せる</li>


<li><strong>D.</strong> 自社で管理するキーでファイルを暗号化してから、S3 にアップロードする（クライアント側の暗号化）</li>


<li><strong>E.</strong> S3 バケットのバージョニングを有効にする</li>
</ul>



<p class="wp-block-paragraph">答えを2つ決めたら、下を開いてください。</p>



<details class="quiz-answer"><summary><strong>正解を見る</strong>（クリックで開きます）</summary>
<p><strong>正解：B と D</strong></p>
<p>B の SSE-KMS は、カスタマーマネージドキーの<strong>キーポリシー</strong>で、だれがキーを使えるかを自社で決められます。D のクライアント側の暗号化は、暗号化の仕組みとキーを<strong>すべて自社</strong>で管理します。</p>
</details>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">正解は B と D</span></h2>



<p class="wp-block-paragraph">正解は <strong>B と D</strong> です。</p>



<ul class="wp-block-list">
<li><strong>B</strong>：SSE-KMS。カスタマーマネージドキーの<strong>キーポリシー</strong>で、だれがキーを使えるかを自社で決める</li>


<li><strong>D</strong>：クライアント側の暗号化。暗号化の仕組みとキーを、<strong>すべて自社</strong>で管理する</li>
</ul>



<p class="wp-block-paragraph">ここから、選択肢を1つずつ見ていきます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">選択肢ごとの解説</span></h2>



<h3 class="wp-block-heading"><span id="toc4">A：HTTPS は転送中の保護（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-a-https.png" alt="上段は「転送中」と「保管時（S3 に置いてあるデータ）」に分かれ、保管時はサーバー側の暗号化の SSE-S3・SSE-KMS と、クライアント側の暗号化。左端の HTTPS（SSL/TLS、通信の経路を守る）が強調され「保管時とは別」。下段は、要件「キーを自社で管理し、だれが使えるかを自社で決める」に対し×「転送中の通信を守るもの」" class="wp-image-16121" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-a-https.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-a-https-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-a-https-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-a-https-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-a-https-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-a-https-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">HTTPS（SSL/TLS）は、図の左の、<strong>転送中</strong>のデータを守るものです。バケットポリシーで HTTPS だけを許可すると、通信の途中での盗み見を防げます。</p>



<p class="wp-block-paragraph">しかし、S3 に保管したファイルの暗号化や、キーの管理とは別の話です。</p>



<h3 class="wp-block-heading"><span id="toc5">B：SSE-KMS はキーを自社で管理（正解）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-b-kms.png" alt="上段は図 A と同じ4つの方法の並びで、SSE-KMS（KMS のカスタマーマネージドキー、キー：自社（キーポリシー））が強調されている。下段は、要件「キーを自社で管理し、だれが使えるかを自社で決める」に対し、丸印「カスタマーマネージドキーのキーポリシーで、だれがキーを使えるかを自社で決められる」" class="wp-image-16122" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-b-kms.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-b-kms-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-b-kms-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-b-kms-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-b-kms-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-b-kms-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">SSE-KMS は、サーバー側の暗号化の1つです。S3 が、AWS KMS のキーを使って、オブジェクトを暗号化します。</p>



<p class="wp-block-paragraph"><strong>カスタマーマネージドキー</strong>は、利用者が作って管理するキーです。キーポリシーで、だれがキーを使えるかを自社で決められます。キーのローテーションも、自社で設定できます。</p>



<h3 class="wp-block-heading"><span id="toc6">C：SSE-S3 のキーは S3 が管理（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-c-sses3.png" alt="上段は図 A と同じ4つの方法の並びで、SSE-S3（S3 マネージドキー、2023-01-05 から既定、キー：S3 が管理）が強調されている。下段は、要件「キーを自社で管理し、だれが使えるかを自社で決める」に対し×「保管時の暗号化だが、キーは S3 が管理する。だれが使えるかを自社では決められない」" class="wp-image-16123" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-c-sses3.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-c-sses3-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-c-sses3-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-c-sses3-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-c-sses3-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-c-sses3-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">SSE-S3 も保管時の暗号化ですが、<strong>キーは S3 が管理</strong>します。だれがキーを使えるかを、自社で決めることはできません。</p>



<p class="wp-block-paragraph">なお、S3 では、2023年1月5日から、SSE-S3 が既定になりました。新しくアップロードされるオブジェクトは、何も設定しなくても、追加の費用なしで暗号化されます。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<h3 class="wp-block-heading"><span id="toc7">D：クライアント側はすべて自社で管理（正解）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-d-client.png" alt="上段は図 A と同じ4つの方法の並びで、右端のクライアント側（自社で暗号化してからアップロード、キー：すべて自社）が強調されている。下段は、要件に対し、丸印「暗号化の仕組みとキーを、すべて自社で管理する。S3 には暗号化された状態で届く」" class="wp-image-16124" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-d-client.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-d-client-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-d-client-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-d-client-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-d-client-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-d-client-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">クライアント側の暗号化では、図の右のように、<strong>暗号化してからアップロード</strong>します。自社でファイルを暗号化し、そのファイルを S3 に送ります。S3 には、暗号化された状態のファイルが届きます。</p>



<p class="wp-block-paragraph">暗号化の仕組みとキーは、<strong>すべて自社</strong>で管理します。キーを使える人も、自社で決められます。</p>



<h3 class="wp-block-heading"><span id="toc8">E：バージョニングは古い版を残す（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-e-version.png" alt="「バージョニングを有効にした S3 バケット」の中で、契約書.pdf の版1が上書きで版2、さらに上書きで版3（いまの版（最新））になり、版1・版2は「前の版として残る」。前の版に元に戻せる。下段は、要件に対し×「上書き・削除の前の版を残す機能。暗号化ではなく、キーの管理とも関係がない」" class="wp-image-16125" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-e-version.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-e-version-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-e-version-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-e-version-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-e-version-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq026-e-version-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">バージョニングを有効にすると、オブジェクトを上書きしたり削除したりしても、<strong>前の版が残ります</strong>。誤って上書きしたファイルや、消したファイルを、元に戻すための機能です。</p>



<p class="wp-block-paragraph">暗号化ではなく、キーの管理とも関係がありません。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">暗号化の方法とキーの管理者</span></h2>



<p class="wp-block-paragraph">保管時の暗号化には、サーバー側とクライアント側があります。キーをだれが管理するかで、方法を見分けます。</p>



<figure class="wp-block-table"><table><thead><tr><th>方法</th><th>守るデータ</th><th>キーを管理するのは</th><th>キーを自社で管理</th></tr></thead><tbody><tr><td><strong>SSE-S3</strong> サーバー側の暗号化</td><td>保管時</td><td>S3 が管理／2023-01-05 から既定</td><td>×</td></tr><tr><td><strong>SSE-KMS</strong> サーバー側の暗号化</td><td>保管時</td><td>KMS のキー／キーポリシーを自社で決める</td><td>○</td></tr><tr><td><strong>クライアント側の暗号化</strong></td><td>保管時</td><td>仕組みもキーもすべて自社</td><td>○</td></tr><tr><td><strong>HTTPS（SSL/TLS）</strong></td><td>転送中</td><td>通信を守るもので、保管時の暗号化ではない</td><td>－</td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">ポイント</span></h2>



<ul class="wp-block-list">
<li>保管時の暗号化は <strong>サーバー側</strong>（SSE-S3・SSE-KMS）と <strong>クライアント側</strong></li>


<li>キーを自社で管理するなら <strong>SSE-KMS（カスタマーマネージドキー）</strong> か <strong>クライアント側</strong></li>


<li>SSE-S3 は <strong>S3 がキーを管理</strong>（2023-01-05 から既定）</li>


<li>HTTPS は <strong>転送中</strong> の保護</li>
</ul>



<p class="wp-block-paragraph">暗号化の考え方と AWS KMS のキーポリシー、S3 の暗号化は、講座の記事で詳しく解説しています。</p>



<ul class="wp-block-list">
<li>講座の第10回③「暗号化と KMS・CloudHSM・ACM」の「AWS KMS」の節（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>


<li>講座の第05回④「Glacier とライフサイクル」の「S3 のセキュリティ」の節（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>
</ul>



<p class="wp-block-paragraph">講座の全14回は、<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から順に読めます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc11">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約5分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="S3 の保管時の暗号化とキーの管理【CLF-C02】AWS クラウドプラクティショナー 試験対策問題 第26問" width="1256" height="707" src="https://www.youtube.com/embed/vrIjeyLdeHo?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">連載の全回は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLSxdgP1WVL3E" target="_blank">再生リスト「CLF-C02 試験対策問題」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc12">連載「CLF-C02 試験対策問題」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clfq">CLF-C02 試験対策問題の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/11/clfq-001-cost-benefits.html" target="_blank">第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-002-global-reach.html" target="_blank">第2問 数分でグローバルに展開（世界同時公開と低い遅延）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-003-high-availability.html" target="_blank">第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-004-agility.html" target="_blank">第4問 クラウドの俊敏性（数分で作成・すぐに削除）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-005-rehost-responsibility.html" target="_blank">第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-006-peak-scaling.html" target="_blank">第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-007-well-architected-pillars.html" target="_blank">第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-008-reliability-principles.html" target="_blank">第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-009-sustainability-principles.html" target="_blank">第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-010-caf-phases.html" target="_blank">第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-011-caf-operations.html" target="_blank">第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-012-migration-evaluator.html" target="_blank">第12問 移行のビジネスケース（Migration Evaluator）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-013-caf-people.html" target="_blank">第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-014-transform-mgn.html" target="_blank">第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-015-datasync.html" target="_blank">第15問 ファイルの移行（AWS DataSync）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-016-repurchase.html" target="_blank">第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-017-right-sizing.html" target="_blank">第17問 適切なサイズ設定（CPU は余り、メモリが不足）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-018-lambda-rds-responsibility.html" target="_blank">第18問 責任共有モデル（Lambda と RDS）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-019-least-privilege.html" target="_blank">第19問 最小権限の原則（IAM のポリシーと SCP）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-020-aws-responsibility.html" target="_blank">第20問 責任共有モデル（EC2 と S3、AWS の責任）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-021-shared-controls.html" target="_blank">第21問 共有統制の例（責任共有モデルの IT 統制）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-022-artifact.html" target="_blank">第22問 コンプライアンスの資料と契約（AWS Artifact）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-023-guardduty.html" target="_blank">第23問 脅威の検出（Amazon GuardDuty）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-024-inspector.html" target="_blank">第24問 脆弱性の継続的なスキャン（Amazon Inspector）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-025-macie.html" target="_blank">第25問 S3 の機密データの検出（Amazon Macie）</a></li>


<li><strong>第26問 S3 の保管時の暗号化とキーの管理（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clfq-027-cloudtrail.html" target="_blank">第27問 だれが操作したかを調べる（AWS CloudTrail）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-028-credential-report.html" target="_blank">第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-029-iam-role.html" target="_blank">第29問 EC2 のアプリケーションに権限を与える（IAM ロール）</a></li>


<li>第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）</li>


<li>第31問 社員に一時的な認証情報を発行するサービス（AWS STS）</li>


<li>第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）</li>


<li>第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）</li>


<li>第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）</li>


<li>第35問 追加料金なしの DDoS 保護（AWS Shield Standard）</li>


<li>第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）</li>


<li>第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）</li>


<li>第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）</li>


<li>第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）</li>


<li>第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）</li>


<li>第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）</li>


<li>第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）</li>


<li>第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）</li>


<li>第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）</li>


<li>第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）</li>


<li>第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）</li>


<li>第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）</li>


<li>第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）</li>


<li>第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）</li>


<li>第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）</li>


<li>第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）</li>


<li>第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）</li>


<li>第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）</li>


<li>第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）</li>


<li>第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）</li>


<li>第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）</li>


<li>第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）</li>


<li>第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）</li>


<li>第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）</li>


<li>第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）</li>


<li>第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）</li>


<li>第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）</li>


<li>第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）</li>


<li>第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）</li>


<li>第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）</li>


<li>第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）</li>


<li>第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）</li>


<li>第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）</li>


<li>第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）</li>


<li>第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）</li>


<li>第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）</li>


<li>第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）</li>


<li>第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）</li>


<li>第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）</li>


<li>第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）</li>


<li>第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）</li>


<li>第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）</li>


<li>第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）</li>


<li>第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）</li>


<li>第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）</li>


<li>第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）</li>


<li>第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）</li>


<li>第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）</li>


<li>第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）</li>


<li>第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）</li>


<li>第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）</li>


<li>第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）</li>


<li>第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）</li>


<li>第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）</li>


<li>第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）</li>


<li>第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）</li>


<li>第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）</li>


<li>第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）</li>


<li>第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）</li>


<li>第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）</li>


<li>第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）</li>


<li>第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）</li>


<li>第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）</li>


<li>第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）</li>


<li>第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【AWS クラウドプラクティショナー試験対策講座 第04回⑤】コンテナーとほかの選択肢 ― コンテナーとは、3つの役割、ECR、ECS と EKS、Fargate、Elastic Beanstalk、Lightsail、Batch</title>
		<link>https://www.seichan.org/2026/11/clf-04-5-containers.html</link>
					<comments>https://www.seichan.org/2026/11/clf-04-5-containers.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Fri, 13 Nov 2026 03:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS クラウドプラクティショナー試験対策講座]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[ECS・EKS・Fargate]]></category>
		<category><![CDATA[コンテナー]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=13095</guid>

					<description><![CDATA[AWS Certified Cloud Practitioner（CLF-C02）の第04回⑤として、コンテナーとほかの選択肢を未経験者向けに解説します。コンテナーとは何か、置く・管理する・動かすの3つの役割、Amazon ECR・Amazon ECS・Amazon EKS・AWS Fargate、AWS Elastic Beanstalk・Amazon Lightsail・AWS Batch の違いまで。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「コンテナーって、仮想サーバーと何が違うのですか。ECR、ECS、EKS、Fargate と名前が似ていて、どれが何をするのか区別できません」<br>「Elastic Beanstalk と Lightsail は、どちらも『手軽に Web サイトを動かせるサービス』に見えます。違いは何ですか」</p>



<p class="wp-block-paragraph">どちらも、コンテナーのサービスを初めて読んだ人から出やすい質問です。答えは、1つ目は <strong>「コンテナーは OS を共有するので軽い。ECR は置く、ECS・EKS は管理する、EC2・Fargate は動かす、と役割で分けて覚える」</strong>、2つ目は <strong>「Elastic Beanstalk はコードを渡すと環境を用意するサービス、Lightsail は手軽な月額の仮想サーバーなどをまとめて提供するサービス」</strong> です。この記事では、その根拠を順に見ていきます。</p>



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


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-6" checked><label class="toc-title" for="toc-checkbox-6">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">コンテナーとは ○</a></li><li><a href="#toc2" tabindex="0">コンテナーを動かす3つの役割</a></li><li><a href="#toc3" tabindex="0">Amazon ECR ○</a></li><li><a href="#toc4" tabindex="0">Amazon ECS と Amazon EKS ○</a></li><li><a href="#toc5" tabindex="0">AWS Fargate ○</a></li><li><a href="#toc6" tabindex="0">AWS Elastic Beanstalk ○</a></li><li><a href="#toc7" tabindex="0">Amazon Lightsail ○</a></li><li><a href="#toc8" tabindex="0">AWS Batch ○</a></li><li><a href="#toc9" tabindex="0">考えてみよう</a></li><li><a href="#toc10" tabindex="0">まとめ</a></li><li><a href="#toc11" tabindex="0">連載「AWS クラウドプラクティショナー試験対策講座」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">コンテナーとは ○</span></h2>



<p class="wp-block-paragraph">第04回④までは、仮想サーバーを借りる EC2 と、サーバーの管理を任せる Lambda を見てきました。ここからは、アプリケーションの動かし方を、用途に合わせて選ぶ話に進みます。まず、コンテナーという考え方です。</p>



<p class="wp-block-paragraph"><strong>コンテナー</strong>は、アプリケーションと、それを動かすのに要る部品や設定を、ひとまとめにした箱です。コンテナーのひな形を <strong>「コンテナーイメージ」</strong>（以下、イメージ）と呼びます。同じイメージなら、どこで動かしても同じように動くのが特徴で、同じコンテナーを複数起動することもできます。</p>



<p class="wp-block-paragraph">仮想サーバーは1台ごとに OS を持ちますが、コンテナーは1つの OS を共有して動くので、軽く、すばやく起動できます。たとえば、ある EC サイトの会社が作った注文のアプリを、同じ形のまま何個も動かせます。コンテナーを動かすためのサービスは、次の節から順に見ていきます。</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1153" height="781" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s033.png" alt="左右に2つの図を並べた図。左の見出しは「仮想サーバー」で、下に帯「物理サーバー・仮想化」、その上に3つの箱が横に並び、各箱の中は下から「OS」「アプリ」（OS が3つ、アプリが3つ）。右の見出しは「コンテナー」で、下に帯「サーバー」、その上に1つだけの「OS」の箱、その上に「コンテナー」の小箱が3つ横に並ぶ。右の図の上に「コンテナーイメージ（ひな形）」と書かれ、下向きの矢印がコンテナーの小箱をまとめるかっこへ向かう。最下部の文は「コンテナーは OS を共有するので軽い」。" class="wp-image-13090" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s033.png 1153w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s033-300x203.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s033-546x370.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s033-150x102.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s033-768x520.png 768w" sizes="(max-width: 1153px) 100vw, 1153px" /></figure>



<ul class="wp-block-list">
<li>アプリと必要なものを箱にまとめる</li>


<li><strong>仮想サーバーより軽く起動する</strong></li>


<li>ひな形はコンテナーイメージ</li>
</ul>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">コンテナーを動かす3つの役割</span></h2>



<p class="wp-block-paragraph">コンテナーを動かすには、<strong>3つの役割</strong>が要ります。</p>



<ol class="wp-block-list">
<li><strong>置く</strong>：イメージを置く場所です。開発者がイメージを置き、必要なときに取り出せるようにします。AWS では Amazon ECR がこれを担います</li>


<li><strong>管理する</strong>：どこで何個のコンテナーを動かすかを管理する役で、Amazon ECS か Amazon EKS が担います</li>


<li><strong>動かす</strong>：コンテナーを実際に動かす場所で、EC2 のサーバーか AWS Fargate を選びます。動かす場所は、ECR からイメージを取り出してコンテナーを起動します</li>
</ol>



<p class="wp-block-paragraph">この3つを分けて覚えると、次の節からのサービスの区別がしやすくなります。</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1200" height="822" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s034.png" alt="コンテナーを動かす3つの役割を、左から右へ3つの枠で示した図。上に「開発者」（人の絵）があり、青の破線の矢印で、左の枠「① 置く」へ向かう（凡例は「人の操作」）。「① 置く」の枠には ECR。中央の枠「② 管理する」には ECS と EKS。右の枠「③ 動かす」には EC2 と Fargate。② の枠から ③ の枠へ実線の矢印があり、ラベルは「管理」。① の枠の下から、② の枠の下をまわって ③ の枠へ向かう実線の矢印があり、ラベルは「イメージ」。最下部の太字の1行は「置く・管理する・動かすの3役」。" class="wp-image-13091" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s034.png 1200w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s034-300x206.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s034-546x374.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s034-150x103.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s034-768x526.png 768w" sizes="(max-width: 1200px) 100vw, 1200px" /></figure>



<ul class="wp-block-list">
<li>置く：イメージの保管は <strong>ECR</strong></li>


<li>管理する：<strong>ECS か EKS</strong></li>


<li>動かす：<strong>EC2 か Fargate</strong></li>
</ul>



<p class="wp-block-paragraph">冒頭の1つ目の相談に、この3役で答えられます。ECR・ECS・EKS・Fargate（と EC2）は、同じ役割のサービスではありません。「置く」「管理する」「動かす」のどの役割かで区別します。</p>



<p class="wp-block-paragraph">もっと詳しく知りたい人向けに、連載「クラウド入門」の<a href="https://www.seichan.org/2026/10/cloud-04-compute-scaling.html">第4回「コンピューティング 後編」</a>の「コンテナ：ECS・EKS・Fargate・ECR」の節で、ECS のタスク定義や、Fargate と EC2 の選び方など、試験の範囲を超えた内容を扱っています。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">Amazon ECR ○</span></h2>



<p class="wp-block-paragraph"><strong>Amazon ECR</strong>（Amazon Elastic Container Registry）は、3つの役割のうち「置く」役のサービスです。</p>



<ul class="wp-block-list">
<li><strong>何をするか</strong>：コンテナーイメージを保管して、必要なときに配る置き場所（レジストリ）</li>


<li><strong>正式名</strong>：Amazon Elastic Container Registry</li>


<li><strong>何をしないか</strong>：コンテナーを動かすことはしない。動かすのは、ECS・EKS が管理する動かす場所</li>


<li><strong>だれが使うか</strong>：開発者がイメージを置き、動かす場所がそこから取り出す</li>


<li><strong>守り方</strong>：置き場所ごとに、使える人を AWS Identity and Access Management（IAM）で決められる（第10回⑤（IAM と最小権限））</li>


<li><strong>覚え方</strong>：コンテナーの「置く」役</li>
</ul>



<p class="wp-block-paragraph">補足：<strong>レジストリ</strong>とは、イメージを保管して配る場所のことです。ECR は AWS が運用を引き受けるマネージドサービスです。</p>



<p class="wp-block-paragraph">出典：<a href="https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/what-is-ecr.html">Amazon ECR とは</a></p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc4">Amazon ECS と Amazon EKS ○</span></h2>



<p class="wp-block-paragraph">「管理する」役のサービスは2つあります。</p>



<figure class="wp-block-table"><table><thead><tr><th>項目</th><th>Amazon ECS</th><th>Amazon EKS</th></tr></thead><tbody><tr><td>正式名</td><td>Amazon Elastic Container Service</td><td>Amazon Elastic Kubernetes Service</td></tr><tr><td>役割</td><td>コンテナーを管理する</td><td>コンテナーを管理する</td></tr><tr><td>仕組み</td><td>AWS が作った管理の仕組み</td><td>Kubernetes を使う</td></tr><tr><td>向く場面</td><td>AWS の仕組みに沿って管理したい</td><td>すでに Kubernetes を使っている</td></tr><tr><td>主な動かす場所</td><td>EC2 か Fargate</td><td>EC2 か Fargate</td></tr></tbody></table></figure>



<p class="wp-block-paragraph">補足：<strong>オーケストレーション</strong>とは、多数のコンテナーの配置・起動・停止をまとめて管理することで、ECS と EKS はどちらもこれを担います。<strong>Kubernetes</strong> は、コンテナーを管理する、広く使われているオープンソースのソフトウェアです。</p>



<p class="wp-block-paragraph">2つの違いは「仕組み」と「向く場面」の行です。AWS が作った管理の仕組みに沿って管理したいなら ECS、すでに Kubernetes を使っているなら、その知識を生かせる EKS、というのが見分けの目安です。</p>



<p class="wp-block-paragraph">出典：<a href="https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html">Amazon ECS とは</a>、<a href="https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/what-is-eks.html">Amazon EKS とは</a></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc5">AWS Fargate ○</span></h2>



<p class="wp-block-paragraph">「動かす」役の選択肢のひとつが <strong>AWS Fargate</strong> で、コンテナー向けのサーバーレスの実行環境です。</p>



<p class="wp-block-paragraph">EC2 で動かす場合は、コンテナーを載せるサーバーの用意や OS の更新を、お客様が行います。Fargate で動かす場合は、そのサーバーの管理を AWS が引き受けるので、お客様はコンテナーの設定に集中できます。</p>



<p class="wp-block-paragraph">Fargate は、<strong>ECS と EKS の両方で使えます</strong>。ECS や EKS の代わりではなく、それらが管理するコンテナーを動かす場所として組み合わせます。試験ガイドの対象のサービス一覧では、AWS Lambda とともに「サーバーレス」に入っています。</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1200" height="945" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s037.png" alt="AWS Fargate の位置づけを示した図。上の横長の枠に「ECS」「EKS」と、「（管理する役）」の文字。枠から下の2つの縦の箱へ、実線の矢印が1本ずつ伸び、どちらにもラベル「管理」が付く。左の見出し「EC2 で動かす」の3段は、上から「アプリケーション・データ（コンテナー）」（橙）、「OS」（橙）、「物理サーバー・仮想化」（紺）。右の見出し「Fargate で動かす」（橙の枠）の3段は、上から「アプリケーション・データ（コンテナー）」（橙）、「OS」（紺）、「物理サーバー・仮想化」（紺）。凡例は、橙が「お客様が扱う」、紺が「AWS が扱う」。最下部の太字の1行は「Fargate ならサーバーの管理は AWS」。" class="wp-image-13092" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s037.png 1200w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s037-300x236.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s037-546x430.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s037-150x118.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s037-768x605.png 768w" sizes="(max-width: 1200px) 100vw, 1200px" /></figure>



<ul class="wp-block-list">
<li>コンテナーを動かす場所のひとつ</li>


<li><strong>ECS・EKS の両方で使える</strong></li>


<li>ECS・EKS の代わりではない</li>
</ul>



<p class="wp-block-paragraph">図の下の部分は、第04回④の「サーバーレスとは」の節の図と同じ段の名前・同じ色の決まりです。EC2 で動かす場合は OS からお客様が扱い、Fargate では OS が AWS 側の紺になります。Fargate は、ECS・EKS と並べる選択肢ではなく、それらが管理するコンテナーを動かす場所として、図でも下に置かれています。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc6">AWS Elastic Beanstalk ○</span></h2>



<p class="wp-block-paragraph">ここからは、コンテナーに限らない、手軽に使えるサービスです。</p>



<p class="wp-block-paragraph"><strong>AWS Elastic Beanstalk</strong> は、Web アプリケーションのコードを渡すと、それを動かすのに要る環境を AWS が代わりに用意するサービスです。たとえば、EC2 のサーバー、ELB のロードバランサー、Auto Scaling グループなどを、利用者が一つずつ組み立てなくて済みます。</p>



<p class="wp-block-paragraph">作られたリソースは利用者の AWS アカウントの中にあり、設定を変えることもできます。そのため、<strong>サーバーレスではありません</strong>。Elastic Beanstalk 自体に追加の料金はなく、使った AWS のリソース（EC2 など）の分だけ料金がかかります（2026年10月26日時点）。</p>



<p class="wp-block-paragraph">出典：<a href="https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/Welcome.html">AWS Elastic Beanstalk とは</a></p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1153" height="976" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s038.png" alt="左から右へ、開発者、コード、Elastic Beanstalk、自動で作られるものを結んだ図。左は人のアイコンと「開発者」。開発者から「コード」の箱へ青の破線の矢印（凡例は「人の操作」）。「コード」から、橙の枠の箱（Elastic Beanstalk のアイコンと「Elastic Beanstalk」）へ実線の矢印。Elastic Beanstalk から下の「自動で作られるもの」の枠へ実線の矢印。枠の中には3つの小箱が並び、左から「EC2 のサーバー」（EC2 のアイコン）「ELB のロードバランサー」（ELB のアイコン）「Auto Scaling グループ」（Auto Scaling のアイコン）。最下部の文は「コードを渡すと環境ができる」。" class="wp-image-13093" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s038.png 1153w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s038-300x254.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s038-546x462.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s038-150x127.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s038-768x650.png 768w" sizes="(max-width: 1153px) 100vw, 1153px" /></figure>



<ul class="wp-block-list">
<li><strong>コードを渡すと環境を用意してくれる</strong></li>


<li>サーバーなどのリソースは利用者のアカウントにある</li>


<li>サーバーレスではない</li>
</ul>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc7">Amazon Lightsail ○</span></h2>



<p class="wp-block-paragraph"><strong>Amazon Lightsail</strong> は、仮想サーバーなどを手軽に使えるようにしたサービスです。</p>



<ul class="wp-block-list">
<li><strong>何か</strong>：仮想サーバー、ストレージ、データベースなどをひとまとまりにして提供する、手軽なサービス</li>


<li><strong>料金</strong>：月ごとに決まったプランの料金（月額）で、費用が読みやすい（2026年10月26日時点）</li>


<li><strong>向く場面</strong>：小さな Web サイトやブログ、キャンペーンのサイトなど、シンプルなもの</li>


<li><strong>EC2 との違い</strong>：EC2 の別名ではない。選ぶ項目を絞り、始めやすくしたサービス</li>


<li><strong>成長したとき</strong>：大きくなったら、EC2 などほかの AWS のサービスへ広げることもできる</li>


<li><strong>見分け方</strong>：「手軽に」「月額」「小さな Web サイト」が手がかり</li>
</ul>



<p class="wp-block-paragraph">補足：Amazon Lightsail の料金プランの中身は、仮想サーバーの大きさなどで変わります。料金の考え方の全体は、第13回①の「従量課金と料金の決まり方」の節と第13回③の「サービスごとの料金の決まり方」の節で扱います。</p>



<p class="wp-block-paragraph">冒頭の2つ目の相談に答えます。Elastic Beanstalk は「コードを渡すと、EC2・ELB・Auto Scaling グループなどの環境を用意してくれる」サービスで、作られたリソースは利用者のアカウントにあり、設定も変えられます。Lightsail は「仮想サーバー、ストレージ、データベースなどをひとまとまりにして、月額で提供する」サービスで、小さな Web サイトなどシンプルなものに向きます。「コードを渡す」なら Beanstalk、「手軽に、月額で」なら Lightsail が手がかりです。</p>



<p class="wp-block-paragraph">出典：<a href="https://aws.amazon.com/jp/lightsail/">Amazon Lightsail</a></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">AWS Batch ○</span></h2>



<p class="wp-block-paragraph"><strong>AWS Batch</strong> は、大量の計算の仕事（ジョブ）をまとめて実行するサービスです。<strong>バッチ処理</strong>とは、ためておいた仕事をまとめて処理することをいいます。たとえば、ある EC サイトの会社が、夜にその日の売上をまとめて集計する仕事が当てはまります。</p>



<p class="wp-block-paragraph">仕事の量に応じて、計算に使うリソース（EC2 や Fargate など）を AWS Batch が用意し、順番に、または並べて実行します。利用者は、バッチ処理を回す仕組みを自分で用意して運用しなくて済みます。AWS Batch 自体に追加の料金はなく、使った計算のリソースの分だけ料金がかかります（2026年10月26日時点）。</p>



<ul class="wp-block-list">
<li>バッチ処理は、ためた仕事をまとめて処理</li>


<li><strong>計算のリソースの用意は AWS Batch が代行</strong></li>


<li>大量の計算の仕事に向く</li>
</ul>



<p class="wp-block-paragraph">出典：<a href="https://docs.aws.amazon.com/ja_jp/batch/latest/userguide/what-is-batch.html">AWS Batch とは</a>、<a href="https://aws.amazon.com/batch/pricing/">AWS Batch の料金（英語）</a></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">考えてみよう</span></h2>



<ol class="wp-block-list">
<li>冒頭の1つ目の相談に、ECR・ECS・EKS・Fargate を「置く」「管理する」「動かす」の言葉を使って、友人に説明してみてください。コンテナーが仮想サーバーより軽い理由も添えてください</li>


<li>Fargate は ECS や EKS の代わりになるでしょうか。「ECS と EKS の両方で使える」「動かす場所」の言葉を使って説明してみてください</li>


<li>冒頭の2つ目の相談に答えてみてください。Elastic Beanstalk・Lightsail・AWS Batch は、それぞれどんな場面で使うか、「コードを渡す」「月額」「夜にまとめて集計」の言葉を使って説明してください</li>
</ol>



<p class="wp-block-paragraph"><strong>ヒント</strong>：1 は「コンテナーとは」と「コンテナーを動かす3つの役割」の節、2 は「AWS Fargate」の節、3 は「AWS Elastic Beanstalk」「Amazon Lightsail」「AWS Batch」の節を見直してください。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">まとめ</span></h2>



<ul class="wp-block-list">
<li><strong>コンテナー</strong>は、アプリケーションと、動かすのに要る部品や設定をひとまとめにした箱。ひな形は<strong>コンテナーイメージ</strong>。仮想サーバーは1台ごとに OS を持つが、コンテナーは1つの OS を共有するので、軽く、すばやく起動できる</li>


<li>コンテナーを動かす3つの役割は、<strong>置く（Amazon ECR）、管理する（Amazon ECS か Amazon EKS）、動かす（EC2 か AWS Fargate）</strong></li>


<li>ECR はイメージを保管して配る置き場所（レジストリ）で、コンテナーは動かさない</li>


<li>ECS は AWS が作った管理の仕組み、EKS は Kubernetes を使う。どちらもオーケストレーション（多数のコンテナーの配置・起動・停止をまとめて管理すること）を担う</li>


<li>Fargate はコンテナー向けのサーバーレスの実行環境で、<strong>ECS と EKS の両方で使える</strong>。ECS・EKS の代わりではなく、動かす場所のひとつ</li>


<li><strong>Elastic Beanstalk</strong> はコードを渡すと環境を用意する（サーバーレスではない）。<strong>Lightsail</strong> は手軽な月額のサービスで、小さな Web サイトに向く。<strong>Batch</strong> は大量の計算の仕事をまとめて実行する。Beanstalk と Batch 自体に追加の料金はなく、使ったリソースの分だけかかる（2026年10月26日時点）</li>
</ul>



<p class="wp-block-paragraph">次は、第04回⑥で、この回のまとめとして、サービスの見分け方と、この回の要点、参考資料、次の回の予告を扱います。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc11">連載「AWS クラウドプラクティショナー試験対策講座」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clf">AWS クラウドプラクティショナー試験対策講座の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/10/clf-01-1-about.html" target="_blank">第01回① CLF はどんな資格か（AWS 認定のレベル・CLF の位置づけ・誰向けか・問われること／問われないこと・身につくもの）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-2-exam-format.html" target="_blank">第01回② 試験の形式と合格基準（試験の基本情報・2種類の設問・採点される50問・換算スコアと合格点・補整型・結果・受験の流れ・再受験と有効期間）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-3-domains.html" target="_blank">第01回③ 出題の範囲と配点（4つの分野と配点・試験ガイドの組み立て・分野ごとのタスク・配点と学ぶ量・対象外のサービス）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-4-study-plan.html" target="_blank">第01回④ 講座の進め方と学び方（全14回の地図・深さの印・学び方の輪・公式の学習リソース・AWS を触るときの注意・問題文の読み方・早見表）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-02-1-what-is-cloud.html" target="_blank">第02回① クラウドとは（3つの特徴・オンプレミスとの違い・使い始めるまでの速さ・IaaS／PaaS／SaaS・デプロイモデルと選び方）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-2-benefits.html" target="_blank">第02回② AWS クラウドの利点（価値提案・6つのメリット・高可用性・伸縮性・俊敏性・例で見分ける）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-3-economics.html" target="_blank">第02回③ クラウドエコノミクス（固定費と変動費・オンプレミスのコスト・総保有コスト・規模の経済・適切なサイジング・BYOL・オートメーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-4-summary.html" target="_blank">第02回④ 第02回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-1-services.html" target="_blank">第03回① サービスの全体像（この回のねらい・この講座について・前の回の振り返り・サービスの集まり・カテゴリ・カテゴリと講座の回）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-2-global-infra.html" target="_blank">第03回② グローバルインフラ（リージョン・AZ・エッジロケーション・3つの関係と比較・Local Zones・Outposts）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-3-high-availability.html" target="_blank">第03回③ 高可用性と複数リージョン（単一障害点・複数 AZ・サービスごとの AZ・複数リージョンの理由・リージョンの選び方）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-4-access.html" target="_blank">第03回④ AWS へのアクセス方法（API・コンソール・CLI・SDK・IaC・CloudFormation・1回限りと繰り返す作業）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-5-summary.html" target="_blank">第03回⑤ 第03回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-1-servers.html" target="_blank">第04回① サーバーと仮想マシン（この回のねらい・この講座について・前の回の振り返り・コンピューティングとサーバー・仮想マシン・コンピューティングの全体像）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-2-ec2.html" target="_blank">第04回② Amazon EC2（EC2 とは・ユースケース・お客様が扱う範囲・インスタンスタイプ・ファミリーと選び方・起動するときに選ぶもの）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-3-elb-autoscaling.html" target="_blank">第04回③ ELB と Auto Scaling（1台のサーバーの限界・垂直と水平のスケーリング・ロードバランサーの目的・ELB とその種類・Auto Scaling・組み合わせ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-4-serverless.html" target="_blank">第04回④ サーバーレス（サーバーレスとは・AWS Lambda とその特徴・ユースケース・Amazon API Gateway・EC2 と Lambda の違い）</a></li>


<li><strong>第04回⑤ コンテナーとほかの選択肢（コンテナーとは・3つの役割・ECR・ECS と EKS・Fargate・Elastic Beanstalk・Lightsail・Batch）（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-6-summary.html" target="_blank">第04回⑥ 第04回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li>第05回① ストレージの種類（この回のねらい・この講座について・前の回の振り返り・ストレージとは・ブロック・ファイル・オブジェクト・3つの種類の比べ方・AWS のストレージの地図）</li>


<li>第05回② EBS とインスタンスストア（Amazon EBS・AZ の中でのレプリケート・スナップショット・EBS の暗号化・インスタンスストア・2つの違い）</li>


<li>第05回③ Amazon S3 とストレージクラス（S3 とは・S3 の特徴・ユースケース・ストレージクラスの考え方・ストレージクラスの一覧）</li>


<li>第05回④ Glacier とライフサイクル（S3 Glacier のクラス・クラスの選び方・ライフサイクルポリシー・ライフサイクルのユースケース・S3 のセキュリティ）</li>


<li>第05回⑤ ファイルとハイブリッド（Amazon EFS・Amazon FSx・ハイブリッドクラウドとストレージ・AWS Storage Gateway・Storage Gateway の種類）</li>


<li>第05回⑥ バックアップと災害対策（バックアップと災害対策の違い・AWS Backup・ユースケース・AWS Elastic Disaster Recovery・データを守る仕組みの重ね方）</li>


<li>第05回⑦ 第05回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第06回① ネットワークの基本（この回のねらい・この講座について・前の回の振り返り・IP アドレスとネットワークの範囲・ルーティングとゲートウェイ・ポートとプロトコル・この回のサービスの地図）</li>


<li>第06回② VPC とサブネット（Amazon VPC とは・サブネット・パブリックサブネットとプライベートサブネット・インターネットゲートウェイ・NAT ゲートウェイ・ルートテーブル）</li>


<li>第06回③ セキュリティグループとネットワーク ACL（セキュリティグループ・ネットワーク ACL・2つの違い・VPC フローログ・VPC の全体を見る）</li>


<li>第06回④ VPC の外とつなぐ（つなぐ先は3つ・AWS Transit Gateway・AWS PrivateLink・オンプレミスとつなぐ方法）</li>


<li>第06回⑤ VPN と Direct Connect（AWS Site-to-Site VPN・AWS Client VPN・AWS Direct Connect・VPN と Direct Connect の比べ方）</li>


<li>第06回⑥ DNS と Route 53（DNS とドメイン名・Amazon Route 53・Route 53 のルーティングの方法）</li>


<li>第06回⑦ CloudFront と Global Accelerator（エッジロケーションとキャッシュ・Amazon CloudFront・CloudFront の使いどころ・AWS Global Accelerator・CloudFront と Global Accelerator の違い）</li>


<li>第06回⑧ 第06回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第07回① データベースとは（この回のねらい・この講座について・前の回の振り返り・データベースとは・テーブル・行・列・SQL とは）</li>


<li>第07回② データベースの種類（リレーショナルデータベース・NoSQL データベース・インメモリデータベース・3つの種類の比べ方・EC サイトで使い分けると）</li>


<li>第07回③ 自分で運用か任せるか（データベースを動かすのに要る作業・EC2 上のデータベース・マネージドデータベース・作業の分担の比べ方・使い分けの考え方）</li>


<li>第07回④ RDS とマルチ AZ 配置（Amazon RDS とは・RDS で選べるエンジン・RDS で AWS が引き受けること・マルチ AZ 配置・フェイルオーバー）</li>


<li>第07回⑤ リードレプリカと Aurora（リードレプリカ・マルチ AZ 配置とリードレプリカの違い・Amazon Aurora・RDS と Aurora の関係）</li>


<li>第07回⑥ Amazon DynamoDB（DynamoDB とは・DynamoDB の特長・DynamoDB のテーブル・DynamoDB と RDS の違い）</li>


<li>第07回⑦ ElastiCache・DocumentDB・Neptune（Amazon ElastiCache・キャッシュの置き方・Amazon DocumentDB・Amazon Neptune・ほかの回で扱う DB の話題）</li>


<li>第07回⑧ 第07回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第08回① 疎結合とつなぎ方の言葉（この回のねらい・この講座について・前の回の振り返り・疎結合とは・つなぎ方の言葉）</li>


<li>第08回② SQS と SNS（Amazon SQS の仕組み・SQS の使いどころ・Amazon SNS の仕組み・SNS の使いどころ）</li>


<li>第08回③ EventBridge と Step Functions（Amazon EventBridge の仕組み・EventBridge の使いどころ・AWS Step Functions の仕組み・Step Functions の使いどころ・SNS・SQS・EventBridge の使い分け・メッセージと通知のサービスを選ぶ）</li>


<li>第08回④ AI と機械学習のサービス（AI と機械学習の言葉・AI/ML のサービスの全体像・画像・文書・文章のサービス・音声と会話のサービス・生成 AI のサービス）</li>


<li>第08回⑤ データ分析のサービス（データ分析の流れ・集める・加工するサービス・分析・見える化のサービス・Athena・Redshift・EMR の違い）</li>


<li>第08回⑥ 業務と開発のサービス（ビジネスアプリケーション・エンドユーザーコンピューティング・開発者ツール・CI/CD の流れ・フロントエンドと IoT）</li>


<li>第08回⑦ 第08回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第09回① 監視の基本と CloudWatch（この回のねらい・この講座について・前の回の振り返り・3つの困りごとと3つのサービス・Amazon CloudWatch・CloudWatch のアラーム・CloudWatch Logs と標準で取れないもの）</li>


<li>第09回② AWS CloudTrail（AWS CloudTrail・CloudTrail の記録の残し方・CloudTrail の使いどころ）</li>


<li>第09回③ AWS Config と3つの使い分け（AWS Config・Config ルールと準拠の確認・CloudTrail と Config の違い・3つの使い分け・3つを組み合わせる流れ）</li>


<li>第09回④ Trusted Advisor と AWS Health（AWS Trusted Advisor・Trusted Advisor のチェックのカテゴリ・サポートプランと使えるチェック・AWS Health Dashboard・AWS Health API・Trusted Advisor・Health・CloudWatch の違い）</li>


<li>第09回⑤ 運用管理の道具（AWS Systems Manager・AWS Compute Optimizer・Service Quotas と License Manager・運用管理の使い分け）</li>


<li>第09回⑥ Organizations と SCP（なぜアカウントを分けるのか・AWS Organizations・Organizations でできること・サービスコントロールポリシー（SCP）・SCP と IAM の関係）</li>


<li>第09回⑦ Control Tower・Service Catalog・RAM（AWS Control Tower・AWS Service Catalog・AWS RAM）</li>


<li>第09回⑧ 第09回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第10回① クラウドで守る利点と責任共有モデル（この回のねらい・この講座について・前の回の振り返り・クラウドで守る利点・責任共有モデルとは）</li>


<li>第10回② 責任の分かれ方（AWS の責任（クラウドのセキュリティ）・お客様の責任（クラウド内のセキュリティ）・共有する管理・サービスで変わる責任）</li>


<li>第10回③ 暗号化と KMS・CloudHSM・ACM（転送時と保管時の暗号化・AWS KMS・AWS CloudHSM・AWS Certificate Manager（ACM））</li>


<li>第10回④ AWS アカウントとルートユーザー（AWS アカウントとルートユーザー・ルートユーザーだけができる作業・ルートユーザーの守り方）</li>


<li>第10回⑤ IAM と最小権限（IAM の全体像・IAM ユーザーとグループ・IAM ロール・ポリシーの種類・最小権限の原則とアクセスレポート）</li>


<li>第10回⑥ MFA・フェデレーション・認証情報の保管（パスワード・MFA・アクセスキー・クロスアカウントの IAM ロール・フェデレーションと IAM アイデンティティセンター・Directory Service と Cognito・認証情報の保管）</li>


<li>第10回⑦ Shield・WAF・Firewall Manager（守りの層・AWS Shield・AWS WAF・AWS Firewall Manager・Shield・WAF・Firewall Manager の使い分け）</li>


<li>第10回⑧ 検出と調査のサービス（Amazon GuardDuty・Amazon Inspector・Amazon Macie・Amazon Detective・AWS Security Hub・検出と調査の使い分け）</li>


<li>第10回⑨ コンプライアンスと情報源（コンプライアンスの考え方・第三者認証と地域・業界・AWS Artifact・監査に使うログ・AWS Marketplace のセキュリティ製品・セキュリティ情報の入手先）</li>


<li>第10回⑩ 第10回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第11回① Well-Architected フレームワークと6つの柱（この回のねらい・この講座について・前の回の振り返り・この回の役割・Well-Architected フレームワークとは・6つの柱の全体像）</li>


<li>第11回② 柱の問いと Well-Architected Tool（柱が答える問い・一般的な設計原則・柱どうしのトレードオフ・Well-Architected Tool）</li>


<li>第11回③ 6つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性・柱と回の対応）</li>


<li>第11回④ 柱どうしの見分け方（信頼性とパフォーマンス効率・コスト最適化と持続可能性・運用上の優秀性と信頼性・セキュリティの柱と第10回）</li>


<li>第11回⑤ 問題文と事例で柱を選ぶ（問題文の言葉から柱を選ぶ・ある EC サイトの会社の構成・柱の目で見直す）</li>


<li>第11回⑥ 故障に備えた設計と疎結合（4つの原則の全体像・故障に備えた設計・コンポーネントの分離（疎結合））</li>


<li>第11回⑦ 伸縮性・並列化と4つの原則（伸縮性の活用・並列化を考慮する・4つの原則と柱）</li>


<li>第11回⑧ 第11回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第12回① 移行とは何か（この回のねらい・この講座について・前の回の振り返り・移行とは何か・この回の例の会社）</li>


<li>第12回② 移行の流れと利点（移行の大まかな流れ・移行の利点・移行を支えるリソース）</li>


<li>第12回③ AWS CAF の6つの観点（AWS CAF とは・6つの観点・ビジネス寄りの3つの観点・技術寄りの3つの観点・期待できる成果・CAF と Well-Architected の違い）</li>


<li>第12回④ 7つの R と移し方（7つの R とは・そのまま移す：リホストとリロケート・少し手を加える：リプラットフォーム・作り直す：リファクタリング（リアーキテクト）・4つの R を並べて見分ける）</li>


<li>第12回⑤ 買い替える・移さない戦略（買い替える：リパーチェス・移さない：リテインとリタイア・例の会社に当てはめる）</li>


<li>第12回⑥ 評価のサービスと AWS MGN（移行のサービスの地図・費用を見積もる：Migration Evaluator・環境を調べる：Application Discovery Service・進み具合を1か所で見る：Migration Hub・サーバーを移す：AWS MGN）</li>


<li>第12回⑦ データベースの移行：DMS と SCT（データベースの移行とは・AWS DMS・止めずに移す：データベースのレプリケーション・設計を変換する：AWS SCT・DMS と SCT の組み合わせ）</li>


<li>第12回⑧ Snow ファミリーと例の会社の移行（大容量データを運ぶ：Snow ファミリー・例の会社の移行を通して見る）</li>


<li>第12回⑨ 第12回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第13回① 従量課金と料金の決まり方（この回のねらい・この講座について・前の回の振り返り・従量課金と料金の決まり方）</li>


<li>第13回② データ転送とストレージの料金（データ転送：受信と送信・データ転送：リージョン内とリージョン間・ストレージの料金）</li>


<li>第13回③ サービスごとの料金と無料利用枠（安いクラスを選ぶときの注意・サービスごとの料金の決まり方・AWS 無料利用枠）</li>


<li>第13回④ オンデマンドとリザーブドインスタンス（購入オプションの全体像・オンデマンドインスタンス・リザーブドインスタンス（RI）・RI の柔軟性・Organizations での割引の共有）</li>


<li>第13回⑤ Savings Plans・スポットと使い分け（Savings Plans・RI と Savings Plans の違い・スポットインスタンス・専有ホストとハードウェア専有インスタンス・キャパシティーの予約・購入オプションの使い分け）</li>


<li>第13回⑥ 見積り・予算・分析の道具（コスト管理の道具の全体像・AWS 料金見積りツール・AWS Budgets・AWS Cost Explorer・AWS Cost and Usage Report）</li>


<li>第13回⑦ タグ・一括請求とコスト改善（コスト配分タグ・AWS Organizations の一括請求・請求と料金の情報・コスト改善の考え方）</li>


<li>第13回⑧ 困ったときの窓口とサポートプラン（困ったときの窓口の全体像・サポートプランの比較・サポートプランと Trusted Advisor のチェック・AWS サポートセンター）</li>


<li>第13回⑨ Trust &#038; Safety・パートナー・Marketplace（AWS Trust &#038; Safety チーム・技術リソース・AWS パートナーネットワーク（APN）・AWS Marketplace・技術支援）</li>


<li>第13回⑩ 第13回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第14回① 見分け方の表と分野 1（この回のねらい・この講座について・前の回の振り返り・見分け方の表の読み方・分野 1 ①：クラウドの性質と費用・分野 1 ②：設計と移行の考え方）</li>


<li>第14回② 分野 2 の見分け方（分野 2 ①：責任共有モデル・分野 2 ②：アクセスと鍵の管理・分野 2 ③：攻撃からの守りと検出・分野 2 ④：記録・監査・統制）</li>


<li>第14回③ 分野 3 の見分け方（分野 3 ①：インフラと処理の場所・分野 3 ②：ストレージ・データベース・移行・分野 3 ③：ネットワーク・分野 3 ④：連携・分析・AI）</li>


<li>第14回④ 分野 4 の見分け方と5つの問い（分野 4 ①：料金と購入オプション・分野 4 ②：コスト管理とサポート・見分けの5つの問い）</li>


<li>第14回⑤ 条件の言葉と主語（基本から一歩進める・条件の言葉①：運用と費用・条件の言葉②：可用性と性能・条件の言葉③：守りと統制・主語を見る：AWS かお客様か）</li>


<li>第14回⑥ 似た言葉と問題文を読む順（似た言葉の取り違え・名前が似ているサービス・時間の配分と見直し・問題文を読む順）</li>


<li>第14回⑦ 受験の申し込みと本人確認（申し込みから結果までの流れ・テストセンターとオンライン・申し込みの手順・本人確認と身分証明書・持ち物と持ち込めないもの）</li>


<li>第14回⑧ オンライン受験の環境と当日（オンライン受験の環境・予約の変更と取り消し・当日の流れと遅刻・試験の後）</li>


<li>第14回⑨ 第14回のまとめ（各回の見分け方の一覧・この回の要点・全14回を終えたら・参考資料）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clf-04-5-containers.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【CLF-C02 試験対策問題 第25問】S3 の機密データの検出（Amazon Macie）</title>
		<link>https://www.seichan.org/2026/11/clfq-025-macie.html</link>
					<comments>https://www.seichan.org/2026/11/clfq-025-macie.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Fri, 13 Nov 2026 00:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[AWS資格]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[CLF-C02 試験対策問題]]></category>
		<category><![CDATA[練習問題]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=16119</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の練習問題・第25問。S3 のファイルの中の個人情報を毎日自動で調べて一覧にするサービスを選ぶ問題です。正解の Macie と、誤りの Detective・GuardDuty・Inspector の論点を図で解説します。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「GuardDuty は S3 も守ってくれると聞いたので、S3 の中の個人情報も見つけてくれる気がします」<br>「Detective と Inspector は、名前から『調べるサービス』に見えて、何を調べるのかが区別できません」</p>



<p class="wp-block-paragraph">AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 <strong>CLF</strong>）では、<strong>S3 のファイルの中身から機密データを見つけるサービスを、脅威・脆弱性・原因の調査のサービスと見分ける</strong>問題が問われます。「ファイルの中身を調べる」のか、「動きやログを見る」のかが分かれ目です。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/PJdd7EnAi-8" target="_blank">YouTube の動画（約4分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-7" checked><label class="toc-title" for="toc-checkbox-7">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">問題</a></li><li><a href="#toc2" tabindex="0">正解は A</a></li><li><a href="#toc3" tabindex="0">選択肢ごとの解説</a><ol><li><a href="#toc4" tabindex="0">A：Macie は S3 の機密データを検出（正解）</a></li><li><a href="#toc5" tabindex="0">B：Detective は原因の調査（誤り）</a></li><li><a href="#toc6" tabindex="0">C：GuardDuty は怪しい動き（誤り）</a></li><li><a href="#toc7" tabindex="0">D：Inspector は脆弱性を探す（誤り）</a></li></ol></li><li><a href="#toc8" tabindex="0">見つけるもので選ぶ</a></li><li><a href="#toc9" tabindex="0">ポイント</a></li><li><a href="#toc10" tabindex="0">動画で見る</a></li><li><a href="#toc11" tabindex="0">連載「CLF-C02 試験対策問題」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">問題</span></h2>



<p class="wp-block-paragraph">ある企業は、複数の Amazon S3 バケットに、顧客から受け取った申込書のファイルを保存しています。ファイルの中に、氏名や住所、パスポート番号などの個人情報を含むものがどれだけあるかを、毎日自動で調べて一覧にしたいと考えています。どの AWS サービスを使いますか。</p>



<ul class="wp-block-list">
<li><strong>A.</strong> Amazon Macie</li>


<li><strong>B.</strong> Amazon Detective</li>


<li><strong>C.</strong> Amazon GuardDuty</li>


<li><strong>D.</strong> Amazon Inspector</li>
</ul>



<p class="wp-block-paragraph">答えを決めたら、下を開いてください。</p>



<details class="quiz-answer"><summary><strong>正解を見る</strong>（クリックで開きます）</summary>
<p><strong>正解：A</strong></p>
<p>Amazon Macie は、機械学習とパターンマッチングで、S3 に保存したデータの中から個人情報などの機密データを見つけるサービスです。自動機密データ検出を有効にすると、毎日バケットを評価し、ファイルを選んで中を調べて、検出結果を一覧にします。</p>
</details>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">正解は A</span></h2>



<p class="wp-block-paragraph">正解は <strong>A</strong> です。</p>



<ul class="wp-block-list">
<li>Amazon Macie は、S3 に保存したデータの中から、<strong>個人情報などの機密データ</strong>を見つけるサービス</li>
</ul>



<p class="wp-block-paragraph">ここから、選択肢を1つずつ見ていきます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">選択肢ごとの解説</span></h2>



<h3 class="wp-block-heading"><span id="toc4">A：Macie は S3 の機密データを検出（正解）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-a-macie.png" alt="左は複数の S3 バケットで、それぞれに申込書のファイルがある。矢印が中央の Amazon Macie に集まり、「毎日、バケットを評価する」「ファイルを選んで（サンプリング）中を調べる」「マネージドデータ識別子」の3段が並ぶ。右の検出結果（一覧）は、申込書_0012.pdf がパスポート番号、申込書_0158.pdf がクレジットカード番号、申込書_0203.pdf がパスポート番号。S3 バケットの暗号化や公開の状態も評価する。下に「ファイルの中身から、機密データ（個人情報など）を毎日自動で見つける」とある" class="wp-image-16114" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-a-macie.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-a-macie-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-a-macie-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-a-macie-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-a-macie-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-a-macie-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon Macie は、機械学習とパターンマッチングで、S3 の中の機密データを見つける、データセキュリティサービスです。<strong>自動機密データ検出</strong>を有効にすると、毎日バケットを評価し、ファイルを選んで中を調べます。</p>



<p class="wp-block-paragraph">パスポート番号やクレジットカード番号などは、Macie が用意した、マネージドデータ識別子で見つけられます。見つけたものは、図の右のように、検出結果として一覧になります。</p>



<h3 class="wp-block-heading"><span id="toc5">B：Detective は原因の調査（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-b-detective.png" alt="左に Amazon Detective「セキュリティの検出結果の原因を調査する」。中央は「材料：記録と検出結果」で、CloudTrail・VPC フローログ・GuardDuty の検出結果から、行動グラフを作って根本原因を調査する。検出結果が出たあとに、何が起きたかをさかのぼって調べる。右の赤い枠は「今回の要件は？」で、ファイルの中の個人情報を見つけること、毎日自動で調べて一覧にすることが並び、「原因の調査。ファイルの中身は見ない」に×印が付いている" class="wp-image-16115" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-b-detective.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-b-detective-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-b-detective-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-b-detective-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-b-detective-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-b-detective-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon Detective は、セキュリティの検出結果の、<strong>原因を調査する</strong>サービスです。図の中央のように、CloudTrail や VPC フローログ、GuardDuty の検出結果を材料に、行動グラフを作ります。それを使って、何が起きたかをさかのぼって調べます。</p>



<p class="wp-block-paragraph">ファイルの中の個人情報を見つけるものでは、ありません。</p>



<h3 class="wp-block-heading"><span id="toc6">C：GuardDuty は怪しい動き（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-c-guardduty.png" alt="左に Amazon GuardDuty「アカウントの怪しい動き（脅威）を見つける」。中央は「見るもの：アカウントの動き」で、CloudTrail の管理イベント・VPC フローログ・DNS ログから、脅威（怪しい動き）を検出する。例は S3 への怪しいアクセスで、だれがどうアクセスしたかは見るが、ファイルに何が書かれているかは見ない。右の赤い枠は「今回の要件は？」で、ファイルの中の個人情報を見つけること、毎日自動で調べて一覧にすることが並び、「怪しい動きの検出。ファイルの中身は見ない」に×印が付いている" class="wp-image-16116" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-c-guardduty.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-c-guardduty-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-c-guardduty-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-c-guardduty-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-c-guardduty-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-c-guardduty-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon GuardDuty は、アカウントの中の怪しい動き、つまり脅威を検出するサービスです。S3 への怪しいアクセスは、見つけることができます。ただし、<strong>ファイルの中に個人情報があるかどうか</strong>は、調べません。</p>



<p class="wp-block-paragraph">アクセスのしかたを見るのが GuardDuty、ファイルの中身を見るのが Macie です。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<h3 class="wp-block-heading"><span id="toc7">D：Inspector は脆弱性を探す（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-d-inspector.png" alt="左に Amazon Inspector「ソフトウェアの弱点（脆弱性）を探す」。中央は「見るもの：ソフトウェアの弱点」で、EC2 インスタンス・コンテナイメージ・Lambda 関数の脆弱性を継続的にスキャンする。S3 に保存したデータの中身は調べない。右の赤い枠は「今回の要件は？」で、ファイルの中の個人情報を見つけること、毎日自動で調べて一覧にすることが並び、「脆弱性の検出。S3 のデータは見ない」に×印が付いている" class="wp-image-16117" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-d-inspector.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-d-inspector-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-d-inspector-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-d-inspector-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-d-inspector-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq025-d-inspector-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon Inspector は、ソフトウェアの弱点、つまり脆弱性をスキャンするサービスです。図の中央のように、<strong>EC2 インスタンス、コンテナイメージ、Lambda 関数</strong>が対象です。</p>



<p class="wp-block-paragraph">S3 に保存したデータの中身は、調べません。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">見つけるもので選ぶ</span></h2>



<p class="wp-block-paragraph">S3 の中の機密データ（たとえば個人情報）は Macie、怪しい動き（脅威）は GuardDuty、ソフトウェアの弱点（脆弱性）は Inspector、検出結果の原因の調査は Detective です。試験では、<strong>機密データ・脅威・脆弱性・調査</strong>という言葉で見分けます。</p>



<figure class="wp-block-table"><table><thead><tr><th>見つけたいもの</th><th>サービス</th><th>見るもの</th></tr></thead><tbody><tr><td><strong>機密データ（個人情報など）</strong></td><td><strong>Amazon Macie</strong></td><td>S3 のバケットの中のファイル</td></tr><tr><td>怪しい動き（脅威）</td><td>Amazon GuardDuty</td><td>CloudTrail の管理イベント・VPC フローログ・DNS ログ</td></tr><tr><td>ソフトウェアの弱点（脆弱性）</td><td>Amazon Inspector</td><td>EC2・コンテナイメージ・Lambda</td></tr><tr><td>検出結果の原因の調査</td><td>Amazon Detective</td><td>CloudTrail・VPC フローログ・GuardDuty の検出結果</td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">ポイント</span></h2>



<ul class="wp-block-list">
<li>S3 の中の個人情報（<strong>機密データ</strong>）を見つける ＝ <strong>Amazon Macie</strong></li>


<li>自動機密データ検出は、<strong>毎日</strong> バケットを評価し、ファイルの中を調べる</li>


<li>脅威 ＝ <strong>GuardDuty</strong>、脆弱性 ＝ <strong>Inspector</strong>、原因の調査 ＝ <strong>Detective</strong></li>
</ul>



<p class="wp-block-paragraph">Macie・GuardDuty・Inspector・Detective の役割と使い分けは、講座の記事で詳しく解説しています。</p>



<ul class="wp-block-list">
<li>講座の第10回⑧「検出と調査のサービス」（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>
</ul>



<p class="wp-block-paragraph">講座の全14回は、<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から順に読めます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約4分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="S3 の機密データの検出（Amazon Macie）【CLF-C02】AWS クラウドプラクティショナー 試験対策問題 第25問" width="1256" height="707" src="https://www.youtube.com/embed/PJdd7EnAi-8?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">連載の全回は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLSxdgP1WVL3E" target="_blank">再生リスト「CLF-C02 試験対策問題」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc11">連載「CLF-C02 試験対策問題」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clfq">CLF-C02 試験対策問題の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/11/clfq-001-cost-benefits.html" target="_blank">第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-002-global-reach.html" target="_blank">第2問 数分でグローバルに展開（世界同時公開と低い遅延）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-003-high-availability.html" target="_blank">第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-004-agility.html" target="_blank">第4問 クラウドの俊敏性（数分で作成・すぐに削除）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-005-rehost-responsibility.html" target="_blank">第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-006-peak-scaling.html" target="_blank">第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-007-well-architected-pillars.html" target="_blank">第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-008-reliability-principles.html" target="_blank">第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-009-sustainability-principles.html" target="_blank">第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-010-caf-phases.html" target="_blank">第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-011-caf-operations.html" target="_blank">第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-012-migration-evaluator.html" target="_blank">第12問 移行のビジネスケース（Migration Evaluator）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-013-caf-people.html" target="_blank">第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-014-transform-mgn.html" target="_blank">第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-015-datasync.html" target="_blank">第15問 ファイルの移行（AWS DataSync）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-016-repurchase.html" target="_blank">第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-017-right-sizing.html" target="_blank">第17問 適切なサイズ設定（CPU は余り、メモリが不足）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-018-lambda-rds-responsibility.html" target="_blank">第18問 責任共有モデル（Lambda と RDS）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-019-least-privilege.html" target="_blank">第19問 最小権限の原則（IAM のポリシーと SCP）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-020-aws-responsibility.html" target="_blank">第20問 責任共有モデル（EC2 と S3、AWS の責任）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-021-shared-controls.html" target="_blank">第21問 共有統制の例（責任共有モデルの IT 統制）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-022-artifact.html" target="_blank">第22問 コンプライアンスの資料と契約（AWS Artifact）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-023-guardduty.html" target="_blank">第23問 脅威の検出（Amazon GuardDuty）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-024-inspector.html" target="_blank">第24問 脆弱性の継続的なスキャン（Amazon Inspector）</a></li>


<li><strong>第25問 S3 の機密データの検出（Amazon Macie）（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html" target="_blank">第26問 S3 の保管時の暗号化とキーの管理</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-027-cloudtrail.html" target="_blank">第27問 だれが操作したかを調べる（AWS CloudTrail）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-028-credential-report.html" target="_blank">第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-029-iam-role.html" target="_blank">第29問 EC2 のアプリケーションに権限を与える（IAM ロール）</a></li>


<li>第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）</li>


<li>第31問 社員に一時的な認証情報を発行するサービス（AWS STS）</li>


<li>第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）</li>


<li>第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）</li>


<li>第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）</li>


<li>第35問 追加料金なしの DDoS 保護（AWS Shield Standard）</li>


<li>第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）</li>


<li>第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）</li>


<li>第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）</li>


<li>第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）</li>


<li>第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）</li>


<li>第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）</li>


<li>第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）</li>


<li>第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）</li>


<li>第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）</li>


<li>第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）</li>


<li>第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）</li>


<li>第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）</li>


<li>第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）</li>


<li>第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）</li>


<li>第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）</li>


<li>第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）</li>


<li>第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）</li>


<li>第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）</li>


<li>第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）</li>


<li>第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）</li>


<li>第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）</li>


<li>第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）</li>


<li>第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）</li>


<li>第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）</li>


<li>第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）</li>


<li>第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）</li>


<li>第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）</li>


<li>第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）</li>


<li>第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）</li>


<li>第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）</li>


<li>第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）</li>


<li>第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）</li>


<li>第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）</li>


<li>第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）</li>


<li>第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）</li>


<li>第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）</li>


<li>第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）</li>


<li>第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）</li>


<li>第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）</li>


<li>第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）</li>


<li>第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）</li>


<li>第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）</li>


<li>第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）</li>


<li>第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）</li>


<li>第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）</li>


<li>第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）</li>


<li>第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）</li>


<li>第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）</li>


<li>第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）</li>


<li>第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）</li>


<li>第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）</li>


<li>第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）</li>


<li>第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）</li>


<li>第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）</li>


<li>第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）</li>


<li>第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）</li>


<li>第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）</li>


<li>第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）</li>


<li>第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）</li>


<li>第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）</li>


<li>第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）</li>


<li>第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）</li>


<li>第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）</li>


<li>第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）</li>


<li>第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clfq-025-macie.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【CLF-C02 試験対策問題 第24問】脆弱性の継続的なスキャン（Amazon Inspector）</title>
		<link>https://www.seichan.org/2026/11/clfq-024-inspector.html</link>
					<comments>https://www.seichan.org/2026/11/clfq-024-inspector.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Thu, 12 Nov 2026 06:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[AWS資格]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[CLF-C02 試験対策問題]]></category>
		<category><![CDATA[練習問題]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=16112</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の練習問題・第24問。EC2・コンテナイメージ・Lambda の脆弱性を継続的にスキャンするサービスを選ぶ問題です。正解の Inspector と、誤りの GuardDuty・Config・Patch Manager の論点を図で解説します。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「脆弱性を見つけるサービスと、直すサービス、怪しい動きを見つけるサービスが、どれも『セキュリティ』に見えて選べません」<br>「Config も EC2 の状態を見てくれるので、脆弱性も分かるのではないかと思ってしまいます」</p>



<p class="wp-block-paragraph">AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 <strong>CLF</strong>）では、<strong>ソフトウェアの脆弱性をスキャンするサービスと、見つけた脆弱性を直すサービス、脅威や設定を扱うサービスを、役割で見分ける</strong>問題が問われます。問題文の「脆弱性」「スキャン」「継続的」といった言葉が手がかりです。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/bc8NzKFX7oo" target="_blank">YouTube の動画（約5分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-8" checked><label class="toc-title" for="toc-checkbox-8">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">問題</a></li><li><a href="#toc2" tabindex="0">正解は B</a></li><li><a href="#toc3" tabindex="0">選択肢ごとの解説</a><ol><li><a href="#toc4" tabindex="0">A：GuardDuty は脅威の検出（誤り）</a></li><li><a href="#toc5" tabindex="0">B：Inspector が継続的にスキャン（正解）</a></li><li><a href="#toc6" tabindex="0">C：Config は設定の記録と評価（誤り）</a></li><li><a href="#toc7" tabindex="0">D：Patch Manager は直す側（誤り）</a></li><li><a href="#toc8" tabindex="0">4つのサービスの役割</a></li></ol></li><li><a href="#toc9" tabindex="0">ポイント</a></li><li><a href="#toc10" tabindex="0">動画で見る</a></li><li><a href="#toc11" tabindex="0">連載「CLF-C02 試験対策問題」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">問題</span></h2>



<p class="wp-block-paragraph">ある企業は、Amazon EC2 インスタンスで動くアプリケーションに加えて、Amazon ECR に保存したコンテナイメージと AWS Lambda の関数を使っています。これらに含まれるソフトウェアに既知の脆弱性（CVE）があれば、すぐに分かるようにしたいと考えています。新しい脆弱性が公開されたときにも、自動で再スキャンされる仕組みが必要です。どの AWS サービスを使いますか。</p>



<ul class="wp-block-list">
<li><strong>A.</strong> Amazon GuardDuty</li>


<li><strong>B.</strong> Amazon Inspector</li>


<li><strong>C.</strong> AWS Config</li>


<li><strong>D.</strong> AWS Systems Manager Patch Manager</li>
</ul>



<p class="wp-block-paragraph">答えを決めたら、下を開いてください。</p>



<details class="quiz-answer"><summary><strong>正解を見る</strong>（クリックで開きます）</summary>
<p><strong>正解：B</strong></p>
<p>Amazon Inspector は、EC2 インスタンス・ECR のコンテナイメージ・Lambda 関数を自動で見つけて、ソフトウェアの脆弱性（CVE）を継続的にスキャンするサービスです。新しい脆弱性が公開されたときにも、自動で再スキャンします。</p>
</details>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">正解は B</span></h2>



<p class="wp-block-paragraph">正解は <strong>B</strong> の Amazon Inspector です。</p>



<ul class="wp-block-list">
<li>EC2、ECR のコンテナイメージ、Lambda 関数のソフトウェアの脆弱性を、<strong>継続的にスキャン</strong>する</li>


<li>新しい脆弱性が公開されたときにも、<strong>自動で再スキャン</strong>する</li>
</ul>



<p class="wp-block-paragraph">ここから、選択肢を1つずつ見ていきます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">選択肢ごとの解説</span></h2>



<h3 class="wp-block-heading"><span id="toc4">A：GuardDuty は脅威の検出（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-a-guardduty.png" alt="左の「分析するログ」に CloudTrail のイベント・VPC フローログ・DNS のログが並び、矢印が Amazon GuardDuty に集まる。その右は検出結果「怪しい動き（脅威）」で、例は不審な通信とふだんと違う API の呼び出し。右端の枠は「脅威の検出」で、アカウントの中の怪しい動きを見張り、ログを分析して脅威を検出結果として知らせる。最後に「ソフトウェアの脆弱性はスキャンしない」に×印が付いている" class="wp-image-16106" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-a-guardduty.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-a-guardduty-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-a-guardduty-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-a-guardduty-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-a-guardduty-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-a-guardduty-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon GuardDuty は、アカウントの中の怪しい動き、つまり<strong>脅威</strong>を検出するサービスです。図の左のように、CloudTrail のイベントや、VPC フローログ、DNS のログを分析します。たとえば、不審な通信や、ふだんと違う API の呼び出しを、検出結果として知らせます。</p>



<p class="wp-block-paragraph">ソフトウェアの脆弱性のスキャンは、しません。</p>



<h3 class="wp-block-heading"><span id="toc5">B：Inspector が継続的にスキャン（正解）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="620" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-b-inspector.png" alt="左の「自動で見つける」に EC2 インスタンス・ECR のコンテナイメージ・Lambda 関数が並び、矢印が Amazon Inspector（継続的にスキャン）に集まる。右の検出結果は、ソフトウェアの脆弱性（CVE）と意図しないネットワークの露出。下の枠は自動で再スキャンするきっかけで、新しい CVE の公開とパッケージの入れ替えから、Inspector へ戻る矢印が伸びる" class="wp-image-16107" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-b-inspector.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-b-inspector-300x116.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-b-inspector-546x212.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-b-inspector-150x58.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-b-inspector-768x298.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-b-inspector-1536x595.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon Inspector は、<strong>脆弱性の管理</strong>のサービスです。図の左の、EC2 インスタンス、ECR のコンテナイメージ、Lambda 関数を自動で見つけて、継続的にスキャンします。</p>



<p class="wp-block-paragraph">見つけるのは、CVE と呼ばれる、ソフトウェアの既知の脆弱性と、意図しないネットワークの露出です。図の下のように、新しい脆弱性が公開されたときや、パッケージが入れ替わったときには、<strong>自動で再スキャン</strong>します。</p>



<h3 class="wp-block-heading"><span id="toc6">C：Config は設定の記録と評価（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-c-config.png" alt="左の「見るのは「設定」」に EC2 のインスタンス・S3 のバケット・IAM のポリシーが並び、矢印が AWS Config に集まる。右へ「記録する（いつ、どの設定がどう変わったか）」と「ルールで評価する（準拠／非準拠。例：S3 のバケットが公開されていないか）」に分かれる。右端の枠は「設定の記録と評価」で、リソースの設定とその変更を記録し、ルールに沿っているかを評価する。最後に「中のソフトウェアの脆弱性は調べない」に×印が付いている" class="wp-image-16108" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-c-config.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-c-config-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-c-config-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-c-config-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-c-config-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-c-config-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">AWS Config は、リソースの設定と、その変更を記録するサービスです。記録した設定が、ルールに沿っているかも評価します。たとえば、S3 のバケットが公開されていないか、といったルールです。</p>



<p class="wp-block-paragraph">見るのは、あくまで<strong>設定</strong>です。中で動くソフトウェアの脆弱性は、調べません。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<h3 class="wp-block-heading"><span id="toc7">D：Patch Manager は直す側（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-d-patch.png" alt="上段は、左の Systems Manager Patch Manager から、パッチを当てる矢印がマネージドノード（EC2 インスタンスなど）3つへ伸びる。右の灰色の枠は、ECR のコンテナイメージと Lambda 関数に×印が付き、「スキャンしない」とある。下段は「役割の分担」で、左の赤い枠「見つける：Amazon Inspector」から、右の緑の枠「直す：Patch Manager」へ矢印が伸びる" class="wp-image-16109" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-d-patch.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-d-patch-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-d-patch-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-d-patch-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-d-patch-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-d-patch-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Patch Manager は、Systems Manager の機能で、EC2 インスタンスなどのマネージドノードに、パッチを当てる作業を自動にします。ECR のコンテナイメージや、Lambda 関数の脆弱性は、スキャンしません。</p>



<p class="wp-block-paragraph">図の下のように、<strong>脆弱性を見つけるのが Inspector、パッチを当てて直すのが Patch Manager</strong> と分けて覚えましょう。</p>



<h3 class="wp-block-heading"><span id="toc8">4つのサービスの役割</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-e-roles.png" alt="4つの枠。左上は赤の「見つける」で Amazon Inspector：ソフトウェアの脆弱性（CVE）を継続的にスキャン。右上は緑の「直す」で Systems Manager Patch Manager：マネージドノードにパッチを当てる。左下は橙の「脅威」で Amazon GuardDuty：アカウントの中の怪しい動きを検出。右下は青の「設定」で AWS Config：リソースの設定を記録して、ルールで評価する" class="wp-image-16110" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-e-roles.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-e-roles-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-e-roles-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-e-roles-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-e-roles-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq024-e-roles-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">4つのサービスの役割を、<strong>見つける・直す・脅威・設定</strong>の4つで整理します。脆弱性を見つけるのは Inspector、パッチを当てて直すのは Patch Manager です。アカウントの中の脅威を検出するのは GuardDuty、リソースの設定を記録して、ルールで評価するのは Config です。</p>



<p class="wp-block-paragraph">問題文に、脆弱性やスキャンという言葉があれば、Inspector を思い出してください。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">ポイント</span></h2>



<ul class="wp-block-list">
<li>脆弱性のスキャン＝<strong>Amazon Inspector</strong>（EC2・ECR のコンテナイメージ・Lambda 関数）</li>


<li>新しい CVE の公開で <strong>自動で再スキャン</strong> する</li>


<li>見つけた脆弱性を直すのは <strong>Patch Manager</strong> など、別の仕組み</li>


<li>GuardDuty は <strong>脅威</strong>、Config は <strong>設定</strong></li>
</ul>



<p class="wp-block-paragraph">Inspector の対象と、GuardDuty・Macie などとの使い分けは、講座の記事で詳しく解説しています。パッチを当てる Patch Manager は、運用管理の道具の回で扱っています。</p>



<ul class="wp-block-list">
<li>講座の第10回⑧「検出と調査のサービス」（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>


<li>講座の第09回⑤「運用管理の道具」（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>
</ul>



<p class="wp-block-paragraph">講座の全14回は、<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から順に読めます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約5分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="脆弱性の継続的なスキャン（Amazon Inspector）【CLF-C02】AWS クラウドプラクティショナー 試験対策問題 第24問" width="1256" height="707" src="https://www.youtube.com/embed/bc8NzKFX7oo?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">連載の全回は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLSxdgP1WVL3E" target="_blank">再生リスト「CLF-C02 試験対策問題」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc11">連載「CLF-C02 試験対策問題」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clfq">CLF-C02 試験対策問題の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/11/clfq-001-cost-benefits.html" target="_blank">第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-002-global-reach.html" target="_blank">第2問 数分でグローバルに展開（世界同時公開と低い遅延）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-003-high-availability.html" target="_blank">第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-004-agility.html" target="_blank">第4問 クラウドの俊敏性（数分で作成・すぐに削除）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-005-rehost-responsibility.html" target="_blank">第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-006-peak-scaling.html" target="_blank">第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-007-well-architected-pillars.html" target="_blank">第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-008-reliability-principles.html" target="_blank">第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-009-sustainability-principles.html" target="_blank">第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-010-caf-phases.html" target="_blank">第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-011-caf-operations.html" target="_blank">第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-012-migration-evaluator.html" target="_blank">第12問 移行のビジネスケース（Migration Evaluator）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-013-caf-people.html" target="_blank">第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-014-transform-mgn.html" target="_blank">第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-015-datasync.html" target="_blank">第15問 ファイルの移行（AWS DataSync）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-016-repurchase.html" target="_blank">第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-017-right-sizing.html" target="_blank">第17問 適切なサイズ設定（CPU は余り、メモリが不足）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-018-lambda-rds-responsibility.html" target="_blank">第18問 責任共有モデル（Lambda と RDS）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-019-least-privilege.html" target="_blank">第19問 最小権限の原則（IAM のポリシーと SCP）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-020-aws-responsibility.html" target="_blank">第20問 責任共有モデル（EC2 と S3、AWS の責任）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-021-shared-controls.html" target="_blank">第21問 共有統制の例（責任共有モデルの IT 統制）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-022-artifact.html" target="_blank">第22問 コンプライアンスの資料と契約（AWS Artifact）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-023-guardduty.html" target="_blank">第23問 脅威の検出（Amazon GuardDuty）</a></li>


<li><strong>第24問 脆弱性の継続的なスキャン（Amazon Inspector）（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clfq-025-macie.html" target="_blank">第25問 S3 の機密データの検出（Amazon Macie）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html" target="_blank">第26問 S3 の保管時の暗号化とキーの管理</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-027-cloudtrail.html" target="_blank">第27問 だれが操作したかを調べる（AWS CloudTrail）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-028-credential-report.html" target="_blank">第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-029-iam-role.html" target="_blank">第29問 EC2 のアプリケーションに権限を与える（IAM ロール）</a></li>


<li>第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）</li>


<li>第31問 社員に一時的な認証情報を発行するサービス（AWS STS）</li>


<li>第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）</li>


<li>第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）</li>


<li>第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）</li>


<li>第35問 追加料金なしの DDoS 保護（AWS Shield Standard）</li>


<li>第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）</li>


<li>第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）</li>


<li>第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）</li>


<li>第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）</li>


<li>第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）</li>


<li>第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）</li>


<li>第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）</li>


<li>第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）</li>


<li>第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）</li>


<li>第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）</li>


<li>第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）</li>


<li>第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）</li>


<li>第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）</li>


<li>第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）</li>


<li>第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）</li>


<li>第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）</li>


<li>第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）</li>


<li>第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）</li>


<li>第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）</li>


<li>第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）</li>


<li>第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）</li>


<li>第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）</li>


<li>第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）</li>


<li>第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）</li>


<li>第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）</li>


<li>第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）</li>


<li>第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）</li>


<li>第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）</li>


<li>第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）</li>


<li>第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）</li>


<li>第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）</li>


<li>第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）</li>


<li>第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）</li>


<li>第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）</li>


<li>第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）</li>


<li>第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）</li>


<li>第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）</li>


<li>第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）</li>


<li>第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）</li>


<li>第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）</li>


<li>第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）</li>


<li>第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）</li>


<li>第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）</li>


<li>第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）</li>


<li>第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）</li>


<li>第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）</li>


<li>第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）</li>


<li>第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）</li>


<li>第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）</li>


<li>第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）</li>


<li>第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）</li>


<li>第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）</li>


<li>第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）</li>


<li>第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）</li>


<li>第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）</li>


<li>第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）</li>


<li>第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）</li>


<li>第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）</li>


<li>第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）</li>


<li>第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）</li>


<li>第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）</li>


<li>第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）</li>


<li>第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）</li>


<li>第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）</li>


<li>第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clfq-024-inspector.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【AWS クラウドプラクティショナー試験対策講座 第04回④】サーバーレス ― サーバーレスとは、AWS Lambda とその特徴、ユースケース、Amazon API Gateway、EC2 と Lambda の違い</title>
		<link>https://www.seichan.org/2026/11/clf-04-4-serverless.html</link>
					<comments>https://www.seichan.org/2026/11/clf-04-4-serverless.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Thu, 12 Nov 2026 03:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS Lambda]]></category>
		<category><![CDATA[AWS クラウドプラクティショナー試験対策講座]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[サーバーレス]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=13088</guid>

					<description><![CDATA[AWS Certified Cloud Practitioner（CLF-C02）の第04回④として、サーバーレスを未経験者向けに解説します。サーバーレスとは何か、AWS Lambda とその特徴（実行時間とメモリの上限）、ユースケース、Amazon API Gateway、EC2 と Lambda の違いまで。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「サーバーレスって、サーバーが無いという意味ですか。でも、プログラムはどこかで動いているはずですよね」<br>「Lambda も EC2 も、プログラムを動かすサービスに見えます。どこが違うのか、どう見分ければいいのか分かりません」</p>



<p class="wp-block-paragraph">どちらも、サーバーレスの話を初めて読んだ人から出やすい質問です。答えは、1つ目は <strong>「サーバーが無いのではなく、AWS の側で動いている。利用者はサーバーの用意や管理をしなくてよい」</strong>、2つ目は <strong>「EC2 は OS から上を利用者が管理して長く動かす。Lambda は AWS が管理し、きっかけがあったときだけ短く動く」</strong> です。この記事では、その根拠を順に見ていきます。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/HkSt4i8Rovw" target="_blank">YouTube の動画（約14分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-9" checked><label class="toc-title" for="toc-checkbox-9">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">サーバーレスとは ◎</a></li><li><a href="#toc2" tabindex="0">AWS Lambda とは ◎</a></li><li><a href="#toc3" tabindex="0">Lambda の特徴 ◎</a></li><li><a href="#toc4" tabindex="0">Lambda のユースケース</a></li><li><a href="#toc5" tabindex="0">Amazon API Gateway とは ◎</a></li><li><a href="#toc6" tabindex="0">EC2 と Lambda の違い</a></li><li><a href="#toc7" tabindex="0">考えてみよう</a></li><li><a href="#toc8" tabindex="0">まとめ</a></li><li><a href="#toc9" tabindex="0">動画で見る</a></li><li><a href="#toc10" tabindex="0">連載「AWS クラウドプラクティショナー試験対策講座」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">サーバーレスとは ◎</span></h2>



<p class="wp-block-paragraph">第04回③までは、仮想サーバーを借りて自分で管理する Amazon EC2 と、台数を増やして支える ELB・Auto Scaling を見てきました。ここからは、サーバーの管理そのものを AWS に任せる考え方に進みます。</p>



<p class="wp-block-paragraph"><strong>サーバーレス</strong>とは、サーバーの用意や管理を AWS に任せ、お客様はプログラムとデータだけを扱う形です。「サーバーが無い」のではなく、AWS の側で動いています。実行環境（OS・ランタイム）の管理とサーバーの台数の調整は AWS が引き受けるので、お客様は処理の作成に集中できます。料金は使った分だけです。OS から上をお客様が扱う EC2 と比べて、扱う範囲が狭くなります。</p>



<p class="wp-block-paragraph">ランタイムとは、プログラムを動かすためのソフトウェアのことです。</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1200" height="693" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s026.png" alt="EC2 とサーバーレスで、お客様が扱う範囲を比べた図。左の見出し「EC2」の3段は、上から「アプリケーション・データ」（橙）、「OS」（橙）、「物理サーバー・仮想化」（紺）。右の見出し「サーバーレス」の3段は、上から「アプリケーション・データ」（橙）、「OS」（紺）、「物理サーバー・仮想化」（紺）。凡例は、橙が「お客様が扱う」、紺が「AWS が扱う」。最下部の太字の1行は「サーバーレスはお客様が扱う範囲が狭い」。" class="wp-image-13083" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s026.png 1200w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s026-300x173.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s026-546x315.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s026-150x87.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s026-768x444.png 768w" sizes="(max-width: 1200px) 100vw, 1200px" /></figure>



<p class="wp-block-paragraph">図は、EC2 とサーバーレスで、誰がどの層を扱うかを比べたものです。橙の箱がお客様が扱う層、紺の箱が AWS が扱う層です。EC2 では、OS とその上のアプリケーション・データの2段をお客様が扱います。サーバーレスでは、お客様が扱うのは最上段のアプリケーション・データだけで、OS は AWS が扱います。</p>



<ul class="wp-block-list">
<li>サーバーの管理は AWS に任せる</li>


<li>お客様が扱うのはプログラムとデータ</li>


<li><strong>一覧の分け方では Lambda・Fargate</strong></li>
</ul>



<p class="wp-block-paragraph">最後の項目は、試験ガイドの対象のサービス一覧の分け方では、「サーバーレス」は <strong>AWS Lambda</strong> と <strong>AWS Fargate</strong> である、という意味です（2026年10月26日時点）。Fargate は、第04回⑤で扱います。ほかにも、Amazon API Gateway のように、一覧では別のカテゴリでもサーバーを管理しなくてよいものがあります。責任共有モデルの全体は、第10回①②で扱います。</p>



<p class="wp-block-paragraph">冒頭の1つ目の相談がこれです。サーバーレスは「サーバーが無い」のではなく、AWS の側で動いていて、利用者がサーバーの管理をしない形、と覚えます。</p>



<p class="wp-block-paragraph">出典：<a href="https://aws.amazon.com/jp/serverless/">サーバーレスのページ</a>、<a href="https://docs.aws.amazon.com/ja_jp/aws-certification/latest/cloud-practitioner-02/clf-02-in-scope-services.html">試験ガイドの対象のサービス一覧</a></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">AWS Lambda とは ◎</span></h2>



<p class="wp-block-paragraph"><strong>AWS Lambda</strong> は、プログラムを「関数」として置いておき、きっかけ（イベント）があったときだけ動かすサービスです。サーバーを用意したり管理したりせずに、コードを実行できます。</p>



<p class="wp-block-paragraph">たとえば、ある EC サイトの会社で、商品の画像がファイルの置き場所（Amazon Simple Storage Service（Amazon S3）。第05回③の「Amazon S3 とは」の節で扱います）に置かれたとします。これをきっかけに Lambda の関数が動き、縮小版の画像を作ります。関数は、きっかけがあるたびに動き、終われば止まるので、動いていない間は料金がかかりません。</p>



<p class="wp-block-paragraph">プログラムの書き方は試験の対象外なので、この講座では扱いません。</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1153" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s027.png" alt="左から右へ3つの箱を矢印で結んだ図。左の見出しは「きっかけ」で箱の文字は「商品の画像が置かれた」。中央の見出しは「関数」で、橙の枠の箱に Lambda のアイコンと「Lambda の関数」の文字。右の見出しは「結果」で箱の文字は「縮小版の画像ができる」。矢印は左から右の1方向だけ。最下部の文は「きっかけがあったときだけ動く」。" class="wp-image-13084" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s027.png 1153w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s027-300x151.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s027-546x275.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s027-150x75.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s027-768x386.png 768w" sizes="(max-width: 1153px) 100vw, 1153px" /></figure>



<ul class="wp-block-list">
<li><strong>関数を置き、きっかけで動かす</strong></li>


<li>サーバーの用意・管理は不要</li>


<li>プログラムの書き方は対象外</li>
</ul>



<p class="wp-block-paragraph">関数が動くきっかけには、ファイルが置かれた、要求が届いた、などがあります。次の「Lambda のユースケース」の節の表で、場面ごとに見ます。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">Lambda の特徴 ◎</span></h2>



<p class="wp-block-paragraph">Lambda の特徴は、次の6つです。</p>



<ul class="wp-block-list">
<li><strong>サーバーの管理が要らない</strong>：サーバーの用意、実行環境（OS・ランタイム）の管理、容量の調整は AWS が行う</li>


<li><strong>自動で増える</strong>：要求の数に合わせて、同時に動く関数の数が自動で増減する</li>


<li><strong>料金は回数と時間</strong>：関数が呼ばれた回数と、コードが動いた時間にもとづく</li>


<li><strong>実行時間に上限がある</strong>：1回の実行は最長15分（標準の Lambda 関数の場合。2026年10月26日時点）</li>


<li><strong>メモリの量を選ぶ</strong>：1つの関数に割り当てるメモリは 128 MB〜10,240 MB（2026年10月26日時点）</li>


<li><strong>短い処理向き</strong>：前の呼び出しの結果を覚えていない、短い処理が得意。長く動き続ける処理には向かない</li>
</ul>



<p class="wp-block-paragraph">1回の実行が最長15分という上限があるため、長く動き続ける処理には向かない、という点が、EC2 との見分けの手がかりになります。</p>



<p class="wp-block-paragraph">補足：ランタイムの更新は、既定の設定では Lambda が自動で当てます。設定を変えると、お客様が関数を更新したときに取り込む形にもできます（<a href="https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/runtime-management-shared.html">Lambda ランタイム管理の責任共有モデル</a>）。</p>



<p class="wp-block-paragraph">補足：上限の出典は <a href="https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html">https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html</a> 、料金の単位の出典は <a href="https://aws.amazon.com/jp/lambda/pricing/">https://aws.amazon.com/jp/lambda/pricing/</a> です。料金の詳しい考え方は第13回③の「サービスごとの料金の決まり方」の節、無料の範囲は第13回③の「AWS 無料利用枠」の節で扱います。</p>



<p class="wp-block-paragraph">もっと詳しく知りたい人向けに、連載「クラウド入門」の<a href="https://www.seichan.org/2026/10/cloud-04-compute-scaling.html">第4回「コンピューティング 後編」</a>の「サーバーレス：AWS Lambda」の節で、ここで扱っていない制約や、課金の考え方、運用面の注意を扱っています。試験の範囲を超えて詳しいので、この講座を終えてから読んでも構いません。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc4">Lambda のユースケース</span></h2>



<p class="wp-block-paragraph">Lambda がよく使われる場面を、表で見ます。行の例は、架空の「ある EC サイトの会社」の場面です。</p>



<figure class="wp-block-table"><table><thead><tr><th>場面</th><th>きっかけ</th><th>処理の例</th></tr></thead><tbody><tr><td>ファイルの処理</td><td>商品の画像が置かれた</td><td>縮小版の画像を作る</td></tr><tr><td>API の裏側</td><td>注文の要求が届いた</td><td>注文の内容を確かめて受け付ける</td></tr><tr><td>データ処理</td><td>新しいデータが届いた</td><td>形式をそろえて保存する</td></tr><tr><td>決まった時刻の処理</td><td>毎晩の決まった時刻</td><td>不要になった一時ファイルを消す</td></tr></tbody></table></figure>



<p class="wp-block-paragraph">どの行も、「きっかけがあって、短い処理を動かす」という形です。</p>



<p class="wp-block-paragraph">補足：API は、プログラムどうしが呼び合うための窓口のことで、次の「Amazon API Gateway とは」の節で説明します。決まった時刻に動かすには、イベントを扱う Amazon EventBridge を組み合わせます（第08回③の「EventBridge の使いどころ」の節で扱います）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc5">Amazon API Gateway とは ◎</span></h2>



<p class="wp-block-paragraph"><strong>Amazon API Gateway</strong> は、API を作り、公開し、管理するサービスです。<strong>API</strong> とは、プログラムどうしが呼び合うための窓口のことです。</p>



<p class="wp-block-paragraph">たとえば、ある EC サイトの会社のスマートフォンのアプリが、注文を送るときに api.example.com の窓口を呼びます。API Gateway はその要求を受け取り、後ろにある処理（Lambda の関数や EC2 の上のプログラムなど）へ渡して、結果を返します。</p>



<p class="wp-block-paragraph">API Gateway 自体もサーバーを管理しなくてよいサービスで、Lambda と組み合わせると、サーバーを管理しない Web の API を作れます。試験ガイドの対象のサービス一覧の分け方ではカテゴリが「ネットワークとコンテンツ配信」ですが、Lambda と組むことが多いため、この回で扱います。</p>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1153" height="589" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s030.png" alt="左から右へ、スマートフォンのアプリ、API Gateway、Lambda の関数を並べた図。左はスマートフォンのアイコンと「スマートフォンのアプリ」。中央は橙の枠の箱に API Gateway のアイコンと「API Gateway」。右は Lambda のアイコンと「Lambda の関数」。アプリの上に小さく「api.example.com」。アプリから API Gateway へ、API Gateway から Lambda の関数へ、それぞれ右向きの実線の矢印（要求）が引かれ、同じ区間に、右向きの矢印から離して、左向きの実線の矢印（応答）が1本ずつ引かれている。凡例は、右向きの矢印が「要求」、左向きの矢印が「応答」。最下部の文は「API の入口を受け持つ」。" class="wp-image-13085" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s030.png 1153w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s030-300x153.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s030-546x279.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s030-150x77.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-s030-768x392.png 768w" sizes="(max-width: 1153px) 100vw, 1153px" /></figure>



<ul class="wp-block-list">
<li><strong>API の作成・公開・管理を担う</strong></li>


<li>受けた要求を Lambda などへ渡す</li>


<li>一覧のカテゴリはネットワーク系</li>
</ul>



<p class="wp-block-paragraph">出典：<a href="https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html">Amazon API Gateway とは</a></p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc6">EC2 と Lambda の違い</span></h2>



<p class="wp-block-paragraph">最後に、第04回②の「Amazon EC2 とは」の節で見た EC2 と、この記事の Lambda を、並べて比べます。</p>



<figure class="wp-block-table"><table><thead><tr><th>項目</th><th>Amazon EC2</th><th>AWS Lambda</th></tr></thead><tbody><tr><td>サーバーの管理</td><td>お客様が OS から上を管理する</td><td>AWS が管理する。お客様は関数を置く</td></tr><tr><td>OS・実行環境の管理</td><td>お客様</td><td>AWS</td></tr><tr><td>料金のかかり方</td><td>使った分（購入の方法は第13回④⑤）</td><td>呼ばれた回数と動いた時間</td></tr><tr><td>向く処理</td><td>長く動き続ける処理</td><td>短く、きっかけで呼ばれる処理</td></tr></tbody></table></figure>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1200" height="1050" src="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f03.png" alt="Amazon EC2 と AWS Lambda の違いを、左右に並べた図。上の見出しは左が「Amazon EC2」、右が「AWS Lambda」（右の箱は橙）。4つの項目ごとに灰色の帯があり、その下で左右を比べる。「サーバーの管理」：EC2 は「お客様が OS から上を管理する」、Lambda は「AWS が管理する。お客様は関数を置く」。「OS・実行環境の管理」：EC2 は「お客様」、Lambda は「AWS」。「料金のかかり方」：EC2 は「使った分（購入の方法は第13回）」、Lambda は「呼ばれた回数と動いた時間」。「向く処理」：EC2 は「長く動き続ける処理」、Lambda は「短く、きっかけで呼ばれる処理」。最下部の注記は「OS・実行環境の管理の行は、責任共有モデルのうち EC2 と Lambda の違いだけを取り出したものです。全体の整理は第10回で扱います。」。" class="wp-image-13086" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f03.png 1200w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f03-300x263.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f03-546x478.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f03-150x131.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/10/clf04-f03-768x672.png 768w" sizes="(max-width: 1200px) 100vw, 1200px" /></figure>



<p class="wp-block-paragraph">補足：OS・実行環境の管理の行は、責任共有モデルのうち EC2 と Lambda の違いだけを取り出したものです。全体の整理は第10回②の「サービスで変わる責任」の節で扱います。Lambda の実行時間の上限は、この記事の「Lambda の特徴」の節のとおりです。</p>



<p class="wp-block-paragraph">冒頭の2つ目の相談に、この表で答えられます。まず「サーバーの管理」を見て、OS から上を自分で管理するなら EC2、AWS に任せて関数を置くだけなら Lambda です。次に「向く処理」を見て、長く動き続けるなら EC2、短く、きっかけで呼ばれるなら Lambda と選びます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc7">考えてみよう</span></h2>



<ol class="wp-block-list">
<li>冒頭の1つ目の相談に、「サーバーが無い」と言わずに答えてみてください。EC2 と比べて、AWS が扱う範囲がどう違うかも添えてください</li>


<li>ある EC サイトの会社で、商品の画像が置かれたら縮小版を作る処理があります。この処理を Lambda で動かすと、動いていない間の料金と、サーバーの管理は、どうなりますか。説明してみてください</li>


<li>スマートフォンのアプリが api.example.com の窓口を呼んだとき、API Gateway は何をして、どこへ渡しますか。また、API Gateway は試験ガイドの一覧ではサーバーレスのカテゴリではないのに、この回で扱うのはなぜか、説明してみてください</li>
</ol>



<p class="wp-block-paragraph"><strong>ヒント</strong>：1 は「サーバーレスとは」の節、2 は「AWS Lambda とは」と「Lambda の特徴」の節、3 は「Amazon API Gateway とは」の節を見直してください。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">まとめ</span></h2>



<ul class="wp-block-list">
<li><strong>サーバーレス</strong>は、サーバーの用意や管理を AWS に任せ、お客様はプログラムとデータだけを扱う形。「サーバーが無い」のではなく、AWS の側で動いている</li>


<li>試験ガイドの一覧の分け方では、サーバーレスは <strong>AWS Lambda</strong> と <strong>AWS Fargate</strong>（2026年10月26日時点）。Amazon API Gateway のように、別のカテゴリでもサーバーを管理しなくてよいものがある</li>


<li><strong>AWS Lambda</strong> は、関数を置き、きっかけ（イベント）があったときだけ動かす。動いていない間は料金がかからず、料金は呼ばれた回数と動いた時間にもとづく</li>


<li>Lambda の1回の実行は最長15分、メモリは 128 MB〜10,240 MB（標準の Lambda 関数の場合。2026年10月26日時点）。短い処理向きで、長く動き続ける処理には向かない</li>


<li><strong>Amazon API Gateway</strong> は、API の作成・公開・管理を担い、受けた要求を Lambda の関数や EC2 の上のプログラムなどへ渡す。一覧のカテゴリは「ネットワークとコンテンツ配信」</li>


<li><strong>EC2 は OS から上をお客様が管理して長く動かす。Lambda は AWS が管理し、短く、きっかけで呼ばれる</strong></li>
</ul>



<p class="wp-block-paragraph">次は、第04回⑤で、コンテナーとほかの選択肢（Amazon ECR・Amazon ECS・Amazon EKS・AWS Fargate・AWS Elastic Beanstalk・Amazon Lightsail・AWS Batch）を扱います。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約14分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="サーバーレス ― サーバーレスとは、AWS Lambda とその特徴、ユースケース、Amazon API Gateway、EC2 と Lambda の違い【AWS CLF 試験対策講座 第04回④】" width="1256" height="707" src="https://www.youtube.com/embed/HkSt4i8Rovw?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">この回の動画は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLXBpQX49HOGQ" target="_blank">再生リスト「第04回 コンピューティング」</a>に、連載の全回は<a rel="noopener" href="https://www.youtube.com/playlist?list=PLHm6C00gB4nI" target="_blank">再生リスト「AWS クラウドプラクティショナー試験対策講座」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc10">連載「AWS クラウドプラクティショナー試験対策講座」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clf">AWS クラウドプラクティショナー試験対策講座の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/10/clf-01-1-about.html" target="_blank">第01回① CLF はどんな資格か（AWS 認定のレベル・CLF の位置づけ・誰向けか・問われること／問われないこと・身につくもの）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-2-exam-format.html" target="_blank">第01回② 試験の形式と合格基準（試験の基本情報・2種類の設問・採点される50問・換算スコアと合格点・補整型・結果・受験の流れ・再受験と有効期間）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-3-domains.html" target="_blank">第01回③ 出題の範囲と配点（4つの分野と配点・試験ガイドの組み立て・分野ごとのタスク・配点と学ぶ量・対象外のサービス）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-01-4-study-plan.html" target="_blank">第01回④ 講座の進め方と学び方（全14回の地図・深さの印・学び方の輪・公式の学習リソース・AWS を触るときの注意・問題文の読み方・早見表）</a></li>


<li><a href="https://www.seichan.org/2026/10/clf-02-1-what-is-cloud.html" target="_blank">第02回① クラウドとは（3つの特徴・オンプレミスとの違い・使い始めるまでの速さ・IaaS／PaaS／SaaS・デプロイモデルと選び方）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-2-benefits.html" target="_blank">第02回② AWS クラウドの利点（価値提案・6つのメリット・高可用性・伸縮性・俊敏性・例で見分ける）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-3-economics.html" target="_blank">第02回③ クラウドエコノミクス（固定費と変動費・オンプレミスのコスト・総保有コスト・規模の経済・適切なサイジング・BYOL・オートメーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-02-4-summary.html" target="_blank">第02回④ 第02回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-1-services.html" target="_blank">第03回① サービスの全体像（この回のねらい・この講座について・前の回の振り返り・サービスの集まり・カテゴリ・カテゴリと講座の回）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-2-global-infra.html" target="_blank">第03回② グローバルインフラ（リージョン・AZ・エッジロケーション・3つの関係と比較・Local Zones・Outposts）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-3-high-availability.html" target="_blank">第03回③ 高可用性と複数リージョン（単一障害点・複数 AZ・サービスごとの AZ・複数リージョンの理由・リージョンの選び方）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-4-access.html" target="_blank">第03回④ AWS へのアクセス方法（API・コンソール・CLI・SDK・IaC・CloudFormation・1回限りと繰り返す作業）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-03-5-summary.html" target="_blank">第03回⑤ 第03回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-1-servers.html" target="_blank">第04回① サーバーと仮想マシン（この回のねらい・この講座について・前の回の振り返り・コンピューティングとサーバー・仮想マシン・コンピューティングの全体像）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-2-ec2.html" target="_blank">第04回② Amazon EC2（EC2 とは・ユースケース・お客様が扱う範囲・インスタンスタイプ・ファミリーと選び方・起動するときに選ぶもの）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-3-elb-autoscaling.html" target="_blank">第04回③ ELB と Auto Scaling（1台のサーバーの限界・垂直と水平のスケーリング・ロードバランサーの目的・ELB とその種類・Auto Scaling・組み合わせ）</a></li>


<li><strong>第04回④ サーバーレス（サーバーレスとは・AWS Lambda とその特徴・ユースケース・Amazon API Gateway・EC2 と Lambda の違い）（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-5-containers.html" target="_blank">第04回⑤ コンテナーとほかの選択肢（コンテナーとは・3つの役割・ECR・ECS と EKS・Fargate・Elastic Beanstalk・Lightsail・Batch）</a></li>


<li><a href="https://www.seichan.org/2026/11/clf-04-6-summary.html" target="_blank">第04回⑥ 第04回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</a></li>


<li>第05回① ストレージの種類（この回のねらい・この講座について・前の回の振り返り・ストレージとは・ブロック・ファイル・オブジェクト・3つの種類の比べ方・AWS のストレージの地図）</li>


<li>第05回② EBS とインスタンスストア（Amazon EBS・AZ の中でのレプリケート・スナップショット・EBS の暗号化・インスタンスストア・2つの違い）</li>


<li>第05回③ Amazon S3 とストレージクラス（S3 とは・S3 の特徴・ユースケース・ストレージクラスの考え方・ストレージクラスの一覧）</li>


<li>第05回④ Glacier とライフサイクル（S3 Glacier のクラス・クラスの選び方・ライフサイクルポリシー・ライフサイクルのユースケース・S3 のセキュリティ）</li>


<li>第05回⑤ ファイルとハイブリッド（Amazon EFS・Amazon FSx・ハイブリッドクラウドとストレージ・AWS Storage Gateway・Storage Gateway の種類）</li>


<li>第05回⑥ バックアップと災害対策（バックアップと災害対策の違い・AWS Backup・ユースケース・AWS Elastic Disaster Recovery・データを守る仕組みの重ね方）</li>


<li>第05回⑦ 第05回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第06回① ネットワークの基本（この回のねらい・この講座について・前の回の振り返り・IP アドレスとネットワークの範囲・ルーティングとゲートウェイ・ポートとプロトコル・この回のサービスの地図）</li>


<li>第06回② VPC とサブネット（Amazon VPC とは・サブネット・パブリックサブネットとプライベートサブネット・インターネットゲートウェイ・NAT ゲートウェイ・ルートテーブル）</li>


<li>第06回③ セキュリティグループとネットワーク ACL（セキュリティグループ・ネットワーク ACL・2つの違い・VPC フローログ・VPC の全体を見る）</li>


<li>第06回④ VPC の外とつなぐ（つなぐ先は3つ・AWS Transit Gateway・AWS PrivateLink・オンプレミスとつなぐ方法）</li>


<li>第06回⑤ VPN と Direct Connect（AWS Site-to-Site VPN・AWS Client VPN・AWS Direct Connect・VPN と Direct Connect の比べ方）</li>


<li>第06回⑥ DNS と Route 53（DNS とドメイン名・Amazon Route 53・Route 53 のルーティングの方法）</li>


<li>第06回⑦ CloudFront と Global Accelerator（エッジロケーションとキャッシュ・Amazon CloudFront・CloudFront の使いどころ・AWS Global Accelerator・CloudFront と Global Accelerator の違い）</li>


<li>第06回⑧ 第06回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第07回① データベースとは（この回のねらい・この講座について・前の回の振り返り・データベースとは・テーブル・行・列・SQL とは）</li>


<li>第07回② データベースの種類（リレーショナルデータベース・NoSQL データベース・インメモリデータベース・3つの種類の比べ方・EC サイトで使い分けると）</li>


<li>第07回③ 自分で運用か任せるか（データベースを動かすのに要る作業・EC2 上のデータベース・マネージドデータベース・作業の分担の比べ方・使い分けの考え方）</li>


<li>第07回④ RDS とマルチ AZ 配置（Amazon RDS とは・RDS で選べるエンジン・RDS で AWS が引き受けること・マルチ AZ 配置・フェイルオーバー）</li>


<li>第07回⑤ リードレプリカと Aurora（リードレプリカ・マルチ AZ 配置とリードレプリカの違い・Amazon Aurora・RDS と Aurora の関係）</li>


<li>第07回⑥ Amazon DynamoDB（DynamoDB とは・DynamoDB の特長・DynamoDB のテーブル・DynamoDB と RDS の違い）</li>


<li>第07回⑦ ElastiCache・DocumentDB・Neptune（Amazon ElastiCache・キャッシュの置き方・Amazon DocumentDB・Amazon Neptune・ほかの回で扱う DB の話題）</li>


<li>第07回⑧ 第07回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第08回① 疎結合とつなぎ方の言葉（この回のねらい・この講座について・前の回の振り返り・疎結合とは・つなぎ方の言葉）</li>


<li>第08回② SQS と SNS（Amazon SQS の仕組み・SQS の使いどころ・Amazon SNS の仕組み・SNS の使いどころ）</li>


<li>第08回③ EventBridge と Step Functions（Amazon EventBridge の仕組み・EventBridge の使いどころ・AWS Step Functions の仕組み・Step Functions の使いどころ・SNS・SQS・EventBridge の使い分け・メッセージと通知のサービスを選ぶ）</li>


<li>第08回④ AI と機械学習のサービス（AI と機械学習の言葉・AI/ML のサービスの全体像・画像・文書・文章のサービス・音声と会話のサービス・生成 AI のサービス）</li>


<li>第08回⑤ データ分析のサービス（データ分析の流れ・集める・加工するサービス・分析・見える化のサービス・Athena・Redshift・EMR の違い）</li>


<li>第08回⑥ 業務と開発のサービス（ビジネスアプリケーション・エンドユーザーコンピューティング・開発者ツール・CI/CD の流れ・フロントエンドと IoT）</li>


<li>第08回⑦ 第08回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第09回① 監視の基本と CloudWatch（この回のねらい・この講座について・前の回の振り返り・3つの困りごとと3つのサービス・Amazon CloudWatch・CloudWatch のアラーム・CloudWatch Logs と標準で取れないもの）</li>


<li>第09回② AWS CloudTrail（AWS CloudTrail・CloudTrail の記録の残し方・CloudTrail の使いどころ）</li>


<li>第09回③ AWS Config と3つの使い分け（AWS Config・Config ルールと準拠の確認・CloudTrail と Config の違い・3つの使い分け・3つを組み合わせる流れ）</li>


<li>第09回④ Trusted Advisor と AWS Health（AWS Trusted Advisor・Trusted Advisor のチェックのカテゴリ・サポートプランと使えるチェック・AWS Health Dashboard・AWS Health API・Trusted Advisor・Health・CloudWatch の違い）</li>


<li>第09回⑤ 運用管理の道具（AWS Systems Manager・AWS Compute Optimizer・Service Quotas と License Manager・運用管理の使い分け）</li>


<li>第09回⑥ Organizations と SCP（なぜアカウントを分けるのか・AWS Organizations・Organizations でできること・サービスコントロールポリシー（SCP）・SCP と IAM の関係）</li>


<li>第09回⑦ Control Tower・Service Catalog・RAM（AWS Control Tower・AWS Service Catalog・AWS RAM）</li>


<li>第09回⑧ 第09回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第10回① クラウドで守る利点と責任共有モデル（この回のねらい・この講座について・前の回の振り返り・クラウドで守る利点・責任共有モデルとは）</li>


<li>第10回② 責任の分かれ方（AWS の責任（クラウドのセキュリティ）・お客様の責任（クラウド内のセキュリティ）・共有する管理・サービスで変わる責任）</li>


<li>第10回③ 暗号化と KMS・CloudHSM・ACM（転送時と保管時の暗号化・AWS KMS・AWS CloudHSM・AWS Certificate Manager（ACM））</li>


<li>第10回④ AWS アカウントとルートユーザー（AWS アカウントとルートユーザー・ルートユーザーだけができる作業・ルートユーザーの守り方）</li>


<li>第10回⑤ IAM と最小権限（IAM の全体像・IAM ユーザーとグループ・IAM ロール・ポリシーの種類・最小権限の原則とアクセスレポート）</li>


<li>第10回⑥ MFA・フェデレーション・認証情報の保管（パスワード・MFA・アクセスキー・クロスアカウントの IAM ロール・フェデレーションと IAM アイデンティティセンター・Directory Service と Cognito・認証情報の保管）</li>


<li>第10回⑦ Shield・WAF・Firewall Manager（守りの層・AWS Shield・AWS WAF・AWS Firewall Manager・Shield・WAF・Firewall Manager の使い分け）</li>


<li>第10回⑧ 検出と調査のサービス（Amazon GuardDuty・Amazon Inspector・Amazon Macie・Amazon Detective・AWS Security Hub・検出と調査の使い分け）</li>


<li>第10回⑨ コンプライアンスと情報源（コンプライアンスの考え方・第三者認証と地域・業界・AWS Artifact・監査に使うログ・AWS Marketplace のセキュリティ製品・セキュリティ情報の入手先）</li>


<li>第10回⑩ 第10回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第11回① Well-Architected フレームワークと6つの柱（この回のねらい・この講座について・前の回の振り返り・この回の役割・Well-Architected フレームワークとは・6つの柱の全体像）</li>


<li>第11回② 柱の問いと Well-Architected Tool（柱が答える問い・一般的な設計原則・柱どうしのトレードオフ・Well-Architected Tool）</li>


<li>第11回③ 6つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性・柱と回の対応）</li>


<li>第11回④ 柱どうしの見分け方（信頼性とパフォーマンス効率・コスト最適化と持続可能性・運用上の優秀性と信頼性・セキュリティの柱と第10回）</li>


<li>第11回⑤ 問題文と事例で柱を選ぶ（問題文の言葉から柱を選ぶ・ある EC サイトの会社の構成・柱の目で見直す）</li>


<li>第11回⑥ 故障に備えた設計と疎結合（4つの原則の全体像・故障に備えた設計・コンポーネントの分離（疎結合））</li>


<li>第11回⑦ 伸縮性・並列化と4つの原則（伸縮性の活用・並列化を考慮する・4つの原則と柱）</li>


<li>第11回⑧ 第11回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第12回① 移行とは何か（この回のねらい・この講座について・前の回の振り返り・移行とは何か・この回の例の会社）</li>


<li>第12回② 移行の流れと利点（移行の大まかな流れ・移行の利点・移行を支えるリソース）</li>


<li>第12回③ AWS CAF の6つの観点（AWS CAF とは・6つの観点・ビジネス寄りの3つの観点・技術寄りの3つの観点・期待できる成果・CAF と Well-Architected の違い）</li>


<li>第12回④ 7つの R と移し方（7つの R とは・そのまま移す：リホストとリロケート・少し手を加える：リプラットフォーム・作り直す：リファクタリング（リアーキテクト）・4つの R を並べて見分ける）</li>


<li>第12回⑤ 買い替える・移さない戦略（買い替える：リパーチェス・移さない：リテインとリタイア・例の会社に当てはめる）</li>


<li>第12回⑥ 評価のサービスと AWS MGN（移行のサービスの地図・費用を見積もる：Migration Evaluator・環境を調べる：Application Discovery Service・進み具合を1か所で見る：Migration Hub・サーバーを移す：AWS MGN）</li>


<li>第12回⑦ データベースの移行：DMS と SCT（データベースの移行とは・AWS DMS・止めずに移す：データベースのレプリケーション・設計を変換する：AWS SCT・DMS と SCT の組み合わせ）</li>


<li>第12回⑧ Snow ファミリーと例の会社の移行（大容量データを運ぶ：Snow ファミリー・例の会社の移行を通して見る）</li>


<li>第12回⑨ 第12回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第13回① 従量課金と料金の決まり方（この回のねらい・この講座について・前の回の振り返り・従量課金と料金の決まり方）</li>


<li>第13回② データ転送とストレージの料金（データ転送：受信と送信・データ転送：リージョン内とリージョン間・ストレージの料金）</li>


<li>第13回③ サービスごとの料金と無料利用枠（安いクラスを選ぶときの注意・サービスごとの料金の決まり方・AWS 無料利用枠）</li>


<li>第13回④ オンデマンドとリザーブドインスタンス（購入オプションの全体像・オンデマンドインスタンス・リザーブドインスタンス（RI）・RI の柔軟性・Organizations での割引の共有）</li>


<li>第13回⑤ Savings Plans・スポットと使い分け（Savings Plans・RI と Savings Plans の違い・スポットインスタンス・専有ホストとハードウェア専有インスタンス・キャパシティーの予約・購入オプションの使い分け）</li>


<li>第13回⑥ 見積り・予算・分析の道具（コスト管理の道具の全体像・AWS 料金見積りツール・AWS Budgets・AWS Cost Explorer・AWS Cost and Usage Report）</li>


<li>第13回⑦ タグ・一括請求とコスト改善（コスト配分タグ・AWS Organizations の一括請求・請求と料金の情報・コスト改善の考え方）</li>


<li>第13回⑧ 困ったときの窓口とサポートプラン（困ったときの窓口の全体像・サポートプランの比較・サポートプランと Trusted Advisor のチェック・AWS サポートセンター）</li>


<li>第13回⑨ Trust &#038; Safety・パートナー・Marketplace（AWS Trust &#038; Safety チーム・技術リソース・AWS パートナーネットワーク（APN）・AWS Marketplace・技術支援）</li>


<li>第13回⑩ 第13回のまとめ（この回の見分け方・要点・参考資料・次の回の予告）</li>


<li>第14回① 見分け方の表と分野 1（この回のねらい・この講座について・前の回の振り返り・見分け方の表の読み方・分野 1 ①：クラウドの性質と費用・分野 1 ②：設計と移行の考え方）</li>


<li>第14回② 分野 2 の見分け方（分野 2 ①：責任共有モデル・分野 2 ②：アクセスと鍵の管理・分野 2 ③：攻撃からの守りと検出・分野 2 ④：記録・監査・統制）</li>


<li>第14回③ 分野 3 の見分け方（分野 3 ①：インフラと処理の場所・分野 3 ②：ストレージ・データベース・移行・分野 3 ③：ネットワーク・分野 3 ④：連携・分析・AI）</li>


<li>第14回④ 分野 4 の見分け方と5つの問い（分野 4 ①：料金と購入オプション・分野 4 ②：コスト管理とサポート・見分けの5つの問い）</li>


<li>第14回⑤ 条件の言葉と主語（基本から一歩進める・条件の言葉①：運用と費用・条件の言葉②：可用性と性能・条件の言葉③：守りと統制・主語を見る：AWS かお客様か）</li>


<li>第14回⑥ 似た言葉と問題文を読む順（似た言葉の取り違え・名前が似ているサービス・時間の配分と見直し・問題文を読む順）</li>


<li>第14回⑦ 受験の申し込みと本人確認（申し込みから結果までの流れ・テストセンターとオンライン・申し込みの手順・本人確認と身分証明書・持ち物と持ち込めないもの）</li>


<li>第14回⑧ オンライン受験の環境と当日（オンライン受験の環境・予約の変更と取り消し・当日の流れと遅刻・試験の後）</li>


<li>第14回⑨ 第14回のまとめ（各回の見分け方の一覧・この回の要点・全14回を終えたら・参考資料）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clf-04-4-serverless.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
		<item>
		<title>【CLF-C02 試験対策問題 第23問】脅威の検出（Amazon GuardDuty）</title>
		<link>https://www.seichan.org/2026/11/clfq-023-guardduty.html</link>
					<comments>https://www.seichan.org/2026/11/clfq-023-guardduty.html#respond</comments>
		
		<dc:creator><![CDATA[seichan]]></dc:creator>
		<pubDate>Thu, 12 Nov 2026 00:00:00 +0000</pubDate>
				<category><![CDATA[クラウド]]></category>
		<category><![CDATA[資格]]></category>
		<category><![CDATA[AWS]]></category>
		<category><![CDATA[AWS認定]]></category>
		<category><![CDATA[AWS資格]]></category>
		<category><![CDATA[CLF-C02]]></category>
		<category><![CDATA[CLF-C02 試験対策問題]]></category>
		<category><![CDATA[練習問題]]></category>
		<guid isPermaLink="false">https://www.seichan.org/?p=16104</guid>

					<description><![CDATA[AWS クラウドプラクティショナー（CLF-C02）の練習問題・第23問。アカウントの中の怪しい動きを、ログを分析する仕組みを作らずに検出するサービスを選ぶ問題です。正解の GuardDuty と、誤りの Macie・CloudTrail・Inspector がなぜ違うのかを図で解説します。]]></description>
										<content:encoded><![CDATA[
<p class="wp-block-paragraph">「脅威を見つけるサービスと、脆弱性を探すサービスと、記録するサービスが、どれもセキュリティの名前で、ごちゃごちゃになります」<br>「CloudTrail に操作の記録が残るなら、怪しい動きもそれで見つかるのではないかと思ってしまいます」</p>



<p class="wp-block-paragraph">AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 <strong>CLF</strong>）では、<strong>「怪しい動き（脅威）」「ソフトウェアの弱点（脆弱性）」「機密データ」「操作の記録」を、問題文の言葉から見分けて、検出のサービスを選ぶ</strong>問題が問われます。問題文のどの言葉が、どのサービスを指すかが決め手です。</p>



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



<p class="wp-block-paragraph">▶ この回の内容は、<a rel="noopener" href="https://youtu.be/c13488u6wb0" target="_blank">YouTube の動画（約4分）</a>でも見られます（記事の最後にも埋め込んであります）。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>




  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-10" checked><label class="toc-title" for="toc-checkbox-10">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">問題</a></li><li><a href="#toc2" tabindex="0">正解は C</a></li><li><a href="#toc3" tabindex="0">選択肢ごとの解説</a><ol><li><a href="#toc4" tabindex="0">A：Macie は S3 の機密データ（誤り）</a></li><li><a href="#toc5" tabindex="0">B：CloudTrail は記録するだけ（誤り）</a></li><li><a href="#toc6" tabindex="0">C：GuardDuty はログを自動で分析（正解）</a></li><li><a href="#toc7" tabindex="0">D：Inspector は脆弱性を探す（誤り）</a></li></ol></li><li><a href="#toc8" tabindex="0">4つのサービスの見分け方</a></li><li><a href="#toc9" tabindex="0">ポイント</a></li><li><a href="#toc10" tabindex="0">動画で見る</a></li><li><a href="#toc11" tabindex="0">連載「CLF-C02 試験対策問題」</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">問題</span></h2>



<p class="wp-block-paragraph">ある企業のセキュリティ担当者は、AWS アカウントの中で起きる怪しい動きに早く気づきたいと考えています。たとえば、使ったことのないリージョンで急に EC2 インスタンスが起動される、EC2 インスタンスが悪意のある IP アドレスと通信する、といった兆候です。ログを分析する仕組みを自分で作らずに、こうした脅威を継続的に検出したい場合、どの AWS サービスを使いますか。</p>



<ul class="wp-block-list">
<li><strong>A.</strong> Amazon Macie</li>


<li><strong>B.</strong> AWS CloudTrail</li>


<li><strong>C.</strong> Amazon GuardDuty</li>


<li><strong>D.</strong> Amazon Inspector</li>
</ul>



<p class="wp-block-paragraph">答えを決めたら、下を開いてください。</p>



<details class="quiz-answer"><summary><strong>正解を見る</strong>（クリックで開きます）</summary>
<p><strong>正解：C</strong></p>
<p>Amazon GuardDuty は、有効にするだけで、CloudTrail の管理イベント・VPC フローログ・DNS ログを自動で分析し、怪しい動き（脅威）を継続的に検出するサービスです。ログを分析する仕組みを、自分で作る必要はありません。</p>
</details>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc2">正解は C</span></h2>



<p class="wp-block-paragraph">正解は <strong>C</strong> です。</p>



<ul class="wp-block-list">
<li>Amazon GuardDuty は、<strong>脅威を検出する</strong>サービス</li>


<li>有効にするだけで、ログを自動で分析して、怪しい動きを見つける</li>
</ul>



<p class="wp-block-paragraph">ここから、選択肢を1つずつ見ていきます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc3">選択肢ごとの解説</span></h2>



<h3 class="wp-block-heading"><span id="toc4">A：Macie は S3 の機密データ（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-a-macie.png" alt="左に Amazon Macie「S3 の機密データを見つける」。中央は「見るもの：S3 のバケットの中」で、S3 のバケットの中の機密データ（個人情報など）を、機械学習とパターンマッチングで検出する。右の赤い枠は「今回の兆候は？」で、使ったことのないリージョンでの起動と悪意のある IP アドレスとの通信が並び、「アカウントの動きは見ない」に×印が付いている" class="wp-image-16099" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-a-macie.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-a-macie-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-a-macie-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-a-macie-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-a-macie-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-a-macie-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon Macie は、Amazon S3 のバケットの中にある、機密データを見つけるサービスです。図の中央のように、個人情報などを、機械学習とパターンマッチングで検出します。</p>



<p class="wp-block-paragraph">見ているのは、<strong>S3 に保存されたデータ</strong>です。アカウントの中の怪しい動きは、検出しません。</p>



<h3 class="wp-block-heading"><span id="toc5">B：CloudTrail は記録するだけ（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-b-cloudtrail.png" alt="左に AWS CloudTrail「API の呼び出しを記録する」。中央は「操作の記録（ログの帳簿）」で、いつ・誰が・何をしたかの表（10:02 user-a RunInstances、10:05 user-b CreateUser、10:09 user-a DeleteBucket）と、「この記録を GuardDuty が分析の材料に使う」への矢印。右の赤い枠は今回の兆候（使ったことのないリージョンでの起動、悪意のある IP アドレスとの通信）で、「記録するだけ。分析して見つけない」に×印が付いている" class="wp-image-16100" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-b-cloudtrail.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-b-cloudtrail-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-b-cloudtrail-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-b-cloudtrail-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-b-cloudtrail-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-b-cloudtrail-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">AWS CloudTrail は、API の呼び出しを記録するサービスです。図の中央のように、いつ、誰が、何をしたかを、帳簿のように残します。</p>



<p class="wp-block-paragraph">ただし、<strong>記録するだけ</strong>で、分析して脅威を見つけることはしません。この記録を材料に使って、脅威を見つけるのが GuardDuty です。</p>



<h3 class="wp-block-heading"><span id="toc6">C：GuardDuty はログを自動で分析（正解）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="600" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-c-guardduty.png" alt="左の基本のデータソース3つ（CloudTrail の管理イベント・VPC フローログ・DNS ログ）から、矢印が中央の Amazon GuardDuty に集まる。GuardDuty の中には、脅威インテリジェンス（悪意のある IP などのリスト）と機械学習がある。右の検出結果は、使ったことのないリージョンでの起動、悪意のある IP アドレスとの通信、認証情報の漏洩など。下に「有効にするだけ。ログを分析する仕組みを自分で作らない」とある" class="wp-image-16101" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-c-guardduty.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-c-guardduty-300x113.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-c-guardduty-546x205.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-c-guardduty-150x56.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-c-guardduty-768x288.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-c-guardduty-1536x576.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon GuardDuty は、脅威検出サービスです。図の左の、CloudTrail の管理イベント、VPC フローログ、DNS ログを、利用者が何も用意しなくても、自動で分析します。悪意のある IP アドレスなどのリストと、機械学習を使って、図の右のような怪しい動きを見つけます。</p>



<p class="wp-block-paragraph">利用者は、<strong>GuardDuty を有効にするだけ</strong>です。ログを分析する仕組みを、自分で作る必要はありません。</p>


<div class=".for-sp">
</div>

<div class=".for-pc">
</div>



<h3 class="wp-block-heading"><span id="toc7">D：Inspector は脆弱性を探す（誤り）</span></h3>



<figure class="wp-block-image size-full"><img loading="lazy" decoding="async" width="1600" height="580" src="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-d-inspector.png" alt="左に Amazon Inspector「ソフトウェアの弱点（脆弱性）を探す」。中央は「見るもの：ソフトウェアの弱点」で、EC2 インスタンス・コンテナイメージ・Lambda 関数の脆弱性（CVE）を継続的にスキャンし、攻撃に使われるかもしれない弱い所を前もって見つけて直すため、と示す。右の赤い枠は今回の兆候（使ったことのないリージョンでの起動、悪意のある IP アドレスとの通信）で、「今起きている動きは見ない」に×印が付いている" class="wp-image-16102" srcset="https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-d-inspector.png 1600w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-d-inspector-300x109.png 300w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-d-inspector-546x198.png 546w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-d-inspector-150x54.png 150w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-d-inspector-768x278.png 768w, https://www.seichan.org/blog/wp-content/uploads/2026/11/clfq023-d-inspector-1536x557.png 1536w" sizes="(max-width: 1600px) 100vw, 1600px" /></figure>



<p class="wp-block-paragraph">Amazon Inspector は、ソフトウェアの弱点、つまり脆弱性を探すサービスです。EC2 インスタンス、コンテナイメージ、Lambda 関数を、継続的にスキャンします。攻撃に使われるかもしれない弱い所を、前もって見つけて直すためのものです。</p>



<p class="wp-block-paragraph"><strong>脆弱性は弱い所</strong>であって、今起きている怪しい動きを検出するものではありません。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc8">4つのサービスの見分け方</span></h2>



<p class="wp-block-paragraph">怪しい動き（脅威）は GuardDuty、ソフトウェアの弱点（脆弱性）は Inspector、S3 の機密データは Macie、操作の記録は CloudTrail です。試験では、<strong>脅威・脆弱性・機密データ・記録</strong>という言葉で見分けます。</p>



<figure class="wp-block-table"><table><thead><tr><th>見つけたいもの</th><th>サービス</th><th>見るもの</th></tr></thead><tbody><tr><td><strong>怪しい動き（脅威）</strong></td><td><strong>Amazon GuardDuty</strong></td><td>CloudTrail の管理イベント・VPC フローログ・DNS ログ</td></tr><tr><td>ソフトウェアの弱点（脆弱性）</td><td>Amazon Inspector</td><td>EC2・コンテナイメージ・Lambda</td></tr><tr><td>機密データ（個人情報など）</td><td>Amazon Macie</td><td>S3 のバケットの中</td></tr><tr><td>操作の記録を残す</td><td>AWS CloudTrail</td><td>API の呼び出し</td></tr></tbody></table></figure>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc9">ポイント</span></h2>



<ul class="wp-block-list">
<li>怪しい動き（<strong>脅威</strong>）を継続的に検出 ＝ <strong>Amazon GuardDuty</strong></li>


<li>有効にするだけで、CloudTrail・VPC フローログ・DNS ログを <strong>自動で分析</strong></li>


<li>脆弱性 ＝ <strong>Inspector</strong>、S3 の機密データ ＝ <strong>Macie</strong>、操作の記録 ＝ <strong>CloudTrail</strong></li>
</ul>



<p class="wp-block-paragraph">GuardDuty・Inspector・Macie の役割と使い分け、CloudTrail の記録の残し方は、講座の記事で詳しく解説しています。</p>



<ul class="wp-block-list">
<li>講座の第10回⑧「検出と調査のサービス」（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>


<li>講座の第09回②「AWS CloudTrail」（<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から）</li>
</ul>



<p class="wp-block-paragraph">講座の全14回は、<a href="https://www.seichan.org/series-clf">連載の入口のページ</a>から順に読めます。</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<h2 class="wp-block-heading"><span id="toc10">動画で見る</span></h2>



<p class="wp-block-paragraph">この回の内容を、YouTube の動画（約4分）でも解説しています。</p>



<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<iframe loading="lazy" title="脅威の検出（Amazon GuardDuty）【CLF-C02】AWS クラウドプラクティショナー 試験対策問題 第23問" width="1256" height="707" src="https://www.youtube.com/embed/c13488u6wb0?feature=oembed" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
</div></figure>



<p class="wp-block-paragraph">連載の全回は、YouTube の<a rel="noopener" href="https://www.youtube.com/playlist?list=PLSxdgP1WVL3E" target="_blank">再生リスト「CLF-C02 試験対策問題」</a>にまとめています。</p>



<h2 class="wp-block-heading"><span id="toc11">連載「CLF-C02 試験対策問題」</span></h2>



<p class="wp-block-paragraph">全回の目次と、読む順番・目的別の読み方は、<a href="https://www.seichan.org/series-clfq">CLF-C02 試験対策問題の入口のページ</a>にまとめています。</p>



<ol class="wp-block-list">
<li><a href="https://www.seichan.org/2026/11/clfq-001-cost-benefits.html" target="_blank">第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-002-global-reach.html" target="_blank">第2問 数分でグローバルに展開（世界同時公開と低い遅延）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-003-high-availability.html" target="_blank">第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-004-agility.html" target="_blank">第4問 クラウドの俊敏性（数分で作成・すぐに削除）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-005-rehost-responsibility.html" target="_blank">第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-006-peak-scaling.html" target="_blank">第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-007-well-architected-pillars.html" target="_blank">第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-008-reliability-principles.html" target="_blank">第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-009-sustainability-principles.html" target="_blank">第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-010-caf-phases.html" target="_blank">第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-011-caf-operations.html" target="_blank">第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-012-migration-evaluator.html" target="_blank">第12問 移行のビジネスケース（Migration Evaluator）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-013-caf-people.html" target="_blank">第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-014-transform-mgn.html" target="_blank">第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-015-datasync.html" target="_blank">第15問 ファイルの移行（AWS DataSync）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-016-repurchase.html" target="_blank">第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-017-right-sizing.html" target="_blank">第17問 適切なサイズ設定（CPU は余り、メモリが不足）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-018-lambda-rds-responsibility.html" target="_blank">第18問 責任共有モデル（Lambda と RDS）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-019-least-privilege.html" target="_blank">第19問 最小権限の原則（IAM のポリシーと SCP）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-020-aws-responsibility.html" target="_blank">第20問 責任共有モデル（EC2 と S3、AWS の責任）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-021-shared-controls.html" target="_blank">第21問 共有統制の例（責任共有モデルの IT 統制）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-022-artifact.html" target="_blank">第22問 コンプライアンスの資料と契約（AWS Artifact）</a></li>


<li><strong>第23問 脅威の検出（Amazon GuardDuty）（この記事）</strong></li>


<li><a href="https://www.seichan.org/2026/11/clfq-024-inspector.html" target="_blank">第24問 脆弱性の継続的なスキャン（Amazon Inspector）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-025-macie.html" target="_blank">第25問 S3 の機密データの検出（Amazon Macie）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-026-s3-kms-encryption.html" target="_blank">第26問 S3 の保管時の暗号化とキーの管理</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-027-cloudtrail.html" target="_blank">第27問 だれが操作したかを調べる（AWS CloudTrail）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-028-credential-report.html" target="_blank">第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）</a></li>


<li><a href="https://www.seichan.org/2026/11/clfq-029-iam-role.html" target="_blank">第29問 EC2 のアプリケーションに権限を与える（IAM ロール）</a></li>


<li>第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）</li>


<li>第31問 社員に一時的な認証情報を発行するサービス（AWS STS）</li>


<li>第32問 ルートユーザーでなければできない作業（アカウントの閉鎖・メールアドレスの変更）</li>


<li>第33問 アプリの会員のサインインとソーシャルログイン（Amazon Cognito）</li>


<li>第34問 同じ IP からの大量のリクエストを止める（AWS WAF のレートベースのルール）</li>


<li>第35問 追加料金なしの DDoS 保護（AWS Shield Standard）</li>


<li>第36問 他社のソフトウェアを AMI で使う（AWS Marketplace）</li>


<li>第37問 インストールなしでブラウザから AWS CLI を使う（AWS CloudShell）</li>


<li>第38問 同じ構成の環境をコードで何度でも作る（CloudFormation・CDK）</li>


<li>第39問 工場の中で AWS のサービスを動かすには（AWS Outposts）</li>


<li>第40問 世界の利用者の近くでキャッシュして配信（Amazon CloudFront）</li>


<li>第41問 コードを上げるだけで Web アプリを動かすサービス（AWS Elastic Beanstalk）</li>


<li>第42問 サーバーを管理せずにコンテナを動かす（AWS Fargate）</li>


<li>第43問 URL のパスで振り分けるロードバランサー（Application Load Balancer）</li>


<li>第44問 つながりを何段もたどるグラフデータベース（Amazon Neptune）</li>


<li>第45問 RDS の自動フェイルオーバーと読み取りの分離（マルチ AZ・リードレプリカ）</li>


<li>第46問 サーバーの管理なしにアクセスの増減に合わせるデータベース（Amazon DynamoDB）</li>


<li>第47問 セキュリティグループの特徴（ステートフル・インスタンス単位）</li>


<li>第48問 障害のときだけ別のリージョンへ DNS で切り替え（Route 53 のフェイルオーバールーティング）</li>


<li>第49問 今あるインターネット回線で、すぐに暗号化してつなぐ（AWS Site-to-Site VPN）</li>


<li>第50問 一部の管理者だけは解除できる削除の保護（S3 オブジェクトロックのガバナンスモード）</li>


<li>第51問 めったに見ないがミリ秒で開く画像の保管（S3 Glacier Instant Retrieval）</li>


<li>第52問 Windows のファイルサーバーを移す（Amazon FSx for Windows File Server）</li>


<li>第53問 案内文を翻訳して音声で読み上げる（Amazon Translate と Amazon Polly）</li>


<li>第54問 S3 のデータをカタログにして SQL で照会（AWS Glue と Amazon Athena）</li>


<li>第55問 依頼をためて、受け付けた順に1回だけ処理（Amazon SQS の FIFO キュー）</li>


<li>第56問 設備を買わずに電話とチャットの窓口を作る（Amazon Connect）</li>


<li>第57問 EC2 と自社のサーバーに少しずつ配置し、失敗したら戻す（AWS CodeDeploy）</li>


<li>第58問 アプリだけをブラウザに配信（WorkSpaces Applications・旧 AppStream 2.0）</li>


<li>第59問 コア単位のライセンスを持ち込み、同じ物理サーバーで動かす（EC2 の専有ホスト）</li>


<li>第60問 EC2・Fargate・Lambda と夜間のバッチのコスト削減（Compute Savings Plans・スポット）</li>


<li>第61問 管理者も外せないリージョンの制限と、請求書の一本化（AWS Organizations の SCP）</li>


<li>第62問 1つのアカウントの料金をプロジェクトごとに分ける（コスト配分タグ）</li>


<li>第63問 料金のグラフと予算超えの通知（Cost Explorer・Budgets）</li>


<li>第64問 アカウントを作る前に料金を見積もる（AWS Pricing Calculator）</li>


<li>第65問 ベストプラクティスに合わない所を自動で見つける（AWS Trusted Advisor）</li>


<li>第66問 AWS 側の保守の予定を前もって知る（AWS Health Dashboard）</li>


<li>第67問 アクセスに合わせて台数を自動で増減する（Amazon EC2 Auto Scaling）</li>


<li>第68問 パフォーマンス効率の柱の設計原則（高度なテクノロジー・グローバル展開）</li>


<li>第69問 移行戦略の7つの R（リタイア・使われていないアプリを停止）</li>


<li>第70問 AWS CAF のパースペクティブ（支出とデータの統制はガバナンス）</li>


<li>第71問 ライセンスを持たずに SQL Server を使う（RDS のライセンス込み）</li>


<li>第72問 EC2 と自社のサーバーのパッチを自動で当てる（AWS Systems Manager Patch Manager）</li>


<li>第73問 障害の教訓を共有し、運用の手順を見直す（運用上の優秀性の設計原則）</li>


<li>第74問 設定の履歴を記録し、社内ルールに合わないリソースを「非準拠」にする（AWS Config）</li>


<li>第75問 S3 へのアップロードごとに短い処理をサーバーレスで動かす（AWS Lambda）</li>


<li>第76問 12のアカウントと SaaS に1回でサインイン（AWS IAM Identity Center）</li>


<li>第77問 インターネットを通らずに、帯域とレイテンシーを安定させる（AWS Direct Connect）</li>


<li>第78問 途中でファミリーを変え、前払いできない RI の選び方（コンバーティブル・前払いなし）</li>


<li>第79問 セキュリティの検出結果を集めて設定もチェック（AWS Security Hub CSPM）</li>


<li>第80問 AWS CAF のパースペクティブ（イノベーションとデータの収益化はビジネス）</li>


<li>第81問 特定の IP アドレスの範囲を、サブネットの入り口で拒否する（ネットワーク ACL）</li>


<li>第82問 組織の外と共有・一般に公開されているリソースを一覧にする（IAM Access Analyzer）</li>


<li>第83問 複数の AZ の EC2 から NFS で同じファイルを共有する（Amazon EFS）</li>


<li>第84問 ルートユーザーの守り方と日常の作業（MFA・IAM Identity Center）</li>


<li>第85問 一括請求の料金の利点（ボリューム料金の階層・リザーブドインスタンスの割引の共有）</li>


<li>第86問 数ペタバイトの販売データをまとめて毎日集計する（Amazon Redshift）</li>


<li>第87問 OS のパッチを自社で当てなくてよい移行先（Amazon RDS・AWS Lambda）</li>


<li>第88問 移行戦略の7つの R（リプラットフォーム・VM をコンテナにして ECS と Fargate へ）</li>


<li>第89問 GPU の学習と CPU のバッチ処理に合うインスタンスファミリー（高速コンピューティング・コンピューティング最適化）</li>


<li>第90問 アプリのエラーの件数と CPU 使用率をしきい値で見張り、E メールで知らせる（Amazon CloudWatch）</li>


<li>第91問 1回の発行で SQS・Lambda・E メールに届ける（Amazon SNS のトピック）</li>


<li>第92問 部署の人の権限を追加料金なしでまとめて管理（IAM ユーザーグループ）</li>


<li>第93問 最も詳しいコストのデータを S3 へ（AWS Data Exports の CUR 2.0）</li>


<li>第94問 視聴履歴とクリックから利用者ごとの動画のおすすめ（Amazon Personalize）</li>


<li>第95問 攻撃中の専門チームの支援と DDoS のコスト保護（AWS Shield Advanced）</li>


<li>第96問 AWS CAF のトランスフォーメーションの分野（業務のデジタル化はプロセス）</li>


<li>第97問 パブリックとプライベートのサブネットに必要な部品（インターネットゲートウェイ・NAT ゲートウェイ）</li>


<li>第98問 SSH・コンソール・CLI の認証情報の使い分け（キーペアとアクセスキー）</li>


<li>第99問 よくある質問の解決の記事を読む（AWS re:Post のナレッジセンター）</li>


<li>第100問 設定値を階層でまとめて追加料金なしで保管（Parameter Store）</li>
</ol>
]]></content:encoded>
					
					<wfw:commentRss>https://www.seichan.org/2026/11/clfq-023-guardduty.html/feed</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
