スキル・知識・技術 - 運用保守エンジニアに成る。

AWS試験対策(CLF/SAA)：セキュリティサービスをまとめて簡単解説

いけやん — Sat, 14 Mar 2026 07:55:42 +0000

AWSの認定試験（CLF／SAA）で頻出となる「AWSセキュリティサービス」の覚えづらさの理由。
それは、サービス数が多いだけでなく、守備範囲や役割が似通っており、名前だけを追って理解しようとすると混乱しやすい構造になっているからです。

そこで本記事では、AWS公式ドキュメントやホワイトペーパーをベースに、セキュリティサービスをカテゴリごとに整理しつつ、試験で狙われやすい紛らわしいポイントをかみ砕いてまとめました。
「これ、何と何で迷うんだっけ？」という状態を一つずつ減らし、セキュリティ分野の覚えづらさの対策をしていきましょう。

AWSセキュリティサービスの全体像

セキュリティサービスのカテゴリ

本記事では、以下のカテゴリに分けて整理します。

アクセス管理（誰が触れるか）
鍵管理・暗号（データをどう守るか）
ログ・構成・ガバナンス（監査・統制をどう回すか）
脅威検知・分析・脆弱性（異常と弱点をどう見つけるか）
アプリケーション防御（入口をどう守るか）
機密情報管理（秘密情報をどこに置くか）
コンプライアンス・監査（監査資料・監査支援）

本記事で扱うサービス一覧

カテゴリ	サービス
アクセス管理	IAM / IAM Identity Center / Amazon Cognito / AWS Resource Access Manager（RAM）
鍵管理・暗号	AWS KMS / AWS CloudHSM
ログ・構成・ガバナンス	AWS CloudTrail / AWS Config / AWS Organizations（SCP）/ AWS Firewall Manager
脅威検知・分析・脆弱性	Amazon GuardDuty / Amazon Detective / Amazon Inspector / Amazon Macie / AWS Security Hub
アプリケーション防御	AWS WAF / AWS Shield / AWS Network Firewall
機密情報管理	AWS Secrets Manager
コンプライアンス・監査	AWS Artifact / AWS Audit Manager

サービス解説：アクセス管理

このカテゴリでは、AWSにおけるアクセス管理をつかさどるサービスを簡単に整理します。
AWSのアクセス管理とは、「誰がAWSやアプリを利用できるのか」「どのAWSリソースにアクセスできるのか」「どこまでの操作を許可するのか」を決める仕組みのことです。
試験では、この考え方を前提として、後続の各サービスが「どの対象を管理しているのか」「何を制御しているのか」を正しく理解できているかが問われます。

IAM

内容

IAM（Identity and Access Management）は、 AWSにおけるアクセス管理を実現するための中核となるサービスです。
IAMは、次の3つの要素を組み合わせてアクセス管理を行います。

IAMポリシー： AWSリソースに対して「どの操作を許可／拒否するか」を定義する権限の中身です。
アクセス権をどの単位で与えるか（ユーザーかロールか）に依存しない点が重要で、実際のアクセス制御は「ポリシーをどこに付与するか」で決まります。
IAMユーザー： 人単位でAWSへのアクセス権を管理するための仕組みです。
「この人は何ができるか」という形で、個人ごとにアクセス権を管理したい場合に使われます。
IAMロール： AWSサービス間やアカウント間のアクセス権を管理するための単位です。
EC2やLambdaなどのAWSサービスが、他のAWSサービス（例：S3、DynamoDB）へアクセスする際に、「このサービスは何をしてよいか」という権限をロールとして引き受けます。

また、IAMでは「最小権限設計」という考え方が非常に重要です。
最小権限設計とは、「そのユーザーやロールが本当に必要とする操作だけを許可し、それ以外は許可しない」というセキュリティ設計の基本原則です。

試験での出題傾向

IAMポリシー／IAMユーザー／IAMロールの役割の違い
最小権限設計の考え方

IAM Identity Center

内容

IAM Identity Centerは、「会社の人（従業員）がAWSにログインするための“入口”をまとめるサービス」です。
AWSを会社で使うようになると、開発用・本番用などでAWSアカウントが複数になります。このとき、各アカウントにIAMユーザーを作って管理すると、

退職・異動のたびに全アカウントを修正する必要がある
誰にどの権限があるか追いにくい

といった運用事故が起きやすくなります。

IAM Identity Centerを使うと、従業員は1回ログインするだけで、許可されたAWSアカウントへ入れるようになります（SSO＝「1回ログインしたらまとめて入れる仕組み」）。
また、どの人にどの権限を与えるかを中央で管理できるため、マルチアカウント運用の基本パターンとして登場しやすいです。
混同しやすいのはCognitoですが、Cognitoはアプリの利用者（お客さん）向け、Identity Centerは従業員向けと覚えるとズレません。

試験での出題傾向

複数AWSアカウントでSSOを使いたい
従業員のログイン管理を一元化したい

Amazon Cognito

内容

Amazon Cognitoは、「Webアプリやスマホアプリの利用者向けに、“ログイン機能一式”を用意するサービス」です。
アプリにログイン機能を持たせるには、本来は

ユーザー登録（サインアップ）
ログイン（サインイン）
パスワード管理・再設定
二段階認証（MFA）

などを自分で作る必要があります。Cognitoを使うと、これらをAWSの仕組みとしてまとめて用意できます。
ここで大事なのは、Cognitoが管理するのはAWSを操作する人ではなく、アプリを使う人（エンドユーザー）であるという点です。
試験では「アプリのログイン」「ユーザー登録」「ソーシャルログイン（Googleでログインなど）」といった言い回しが出たらCognitoを疑うのが基本です。

試験での出題傾向

アプリにログイン機能を実装したい
アプリ利用者の認証をAWSで行いたい

AWS Resource Access Manager（RAM）

内容

AWS Resource Access Manager（RAM）は、「AWSリソースを、組織内の別アカウントと共有するためのサービス」です。

AWSでは、セキュリティや請求管理の観点から、開発・本番・共通基盤などをアカウント単位で分けて運用する（マルチアカウント構成）のが一般的です。この構成では、次のような課題が出てきます。

各アカウントで同じリソースを何度も作るのは管理が大変
本来は共通で使いたいリソースを、アカウントごとに分けたくない

RAMは、この問題を解決するために、「1つのAWSリソースを、複数のAWSアカウントで使えるようにする」仕組みを提供します。
また、RAMはAWS Organizationsと組み合わせて使われる前提のサービスであり、「組織内アカウントに安全に共有する」という文脈で登場します。

試験での出題傾向

マルチアカウント環境で、AWSリソースを共有したい
ネットワークを含む共通基盤を、複数アカウントで使い回したい

サービス解説：鍵管理・暗号

このカテゴリでは、「データをどのように暗号化し、その鍵を誰が管理するのか」を扱います。
試験では、

鍵管理をAWSに任せたいのか
鍵を自分たちで厳密に管理する必要があるのか

という要求レベルの違いを見抜けるかがポイントになります。

AWS KMS

内容

AWS KMSは、「AWSで使う暗号鍵をまとめて管理する標準サービス」です。
S3、EBS、RDS など多くのAWSサービスと連携し、保存されるデータを自動的に暗号化できます。

試験では、「保存データを暗号化したい」「鍵の管理をできるだけ簡単にしたい」といった要件で登場します。
この場合、まず選択肢に上がるのがKMSです。

KMSでは、

AWS管理キー
カスタマー管理キー

といった種類があり、鍵の管理責任をどこまで持ちたいかで使い分けます。

試験での出題傾向

保存データを暗号化したい
鍵管理をAWSに任せたい

AWS CloudHSM

内容

AWS CloudHSMは、「暗号鍵（データを守るための“鍵”）を、自分たちで厳密に管理したい場合のサービス」です。

KMSは便利で、通常の試験対策では「暗号化＝まずKMS」で大丈夫です。
ただし、業界や規制によっては、

鍵をクラウド事業者に預けたくない（預けられない）
鍵の操作を自社で完全にコントロールしたい

というケースがあります。
CloudHSMは、そのような要件に対応するためのサービスで、専用のハードウェア（HSM：暗号鍵を安全に扱うための専用装置）上で鍵を管理します。

試験では「規制が厳しい」「鍵管理を自社で完全に」「専用ハードウェア」などの言い回しが出たらCloudHSMを疑います。

試験での出題傾向

厳しい規制要件がある（金融・政府系など）
鍵をAWSに預けられないケース
鍵管理を自社で完全にコントロールしたい

サービス解説：ログ・構成・ガバナンス

このカテゴリでは、「AWS環境で何が起きたのか／設定は正しいのか／組織としてどう縛るのか」を解決するサービスを扱います。
試験では、

事後に調査したいのか（ログ）
現在の設定状態をチェックしたいのか（構成）
組織全体で強制したいのか（ガバナンス）

という目的の違いを切り分けられるかがポイントです。

AWS CloudTrail

内容

AWS CloudTrailは、「AWS上で行われた操作の履歴（誰が・いつ・何をしたか）を記録するサービス」です。
API操作（AWSへの操作）を中心に記録するため、

リソースが削除された
設定が変更された

といった事象が起きた後から原因を調べる用途で使われます。

CloudTrailは「操作の記録」を残すものであり、設定が正しいかどうかを判断するサービスではありません。

試験での出題傾向

誰がリソースを削除／変更したかを調べたい
セキュリティインシデントの事後調査

AWS Config

内容

AWS Configは、「AWSリソースの設定がルール通りかを継続的にチェックするサービス」です。

CloudTrailが「何が起きたか」を記録するのに対し、Configは

暗号化が有効か
パブリック公開されていないか

など、現在の設定状態を確認します。

試験での出題傾向

設定がベストプラクティスに沿っているか確認したい
設定逸脱を検知したい

AWS Organizations（SCP）

内容

AWS Organizationsは、「複数のAWSアカウントを“会社として”まとめて管理するための基盤」です。

重要なのは2つあります。

1つ目は請求（利用料金のまとめ）です。
複数アカウントの支払いを、管理アカウント（旧マスターアカウント）に集約できます。試験でも「アカウントごとの請求をまとめたい」「会社として一括で管理したい」といった文脈で登場します。

2つ目がSCP（Service Control Policy）による縛りです。
SCPは「権限を与えるもの」ではなく、「この組織では“ここまでしか操作できない”という上限を決める仕組み」です。
たとえば「全アカウントで特定リージョンを使わせない」「特定サービスの利用を禁止する」といった“会社ルール”を、OU（アカウントのグループ）単位で強制できます。

また、SCPは管理アカウントには適用されない点が頻出のひっかけです。

試験での出題傾向

複数AWSアカウントの請求をまとめて管理したい
組織全体で特定の操作を禁止したい（SCP）
SCPは権限を付与せず、実行可能範囲の“上限”を決めるだけ
管理アカウントにはSCPが適用されない

AWS Firewall Manager

内容

AWS Firewall Managerは、「複数アカウントに同じ“防御ルール”をまとめて配るためのサービス」です。

WAFやNetwork Firewallは強力ですが、アカウントが増えると「各アカウントで同じルールを作る・更新する」作業が地獄になります。
Firewall Managerを使うと、Organizations配下のアカウントに対して、

WAFのルール
Network Firewallのポリシー

などを中央から一括で適用できます。

試験では「新しいアカウントが増えても自動で同じルールを適用したい」「複数アカウントのWAF設定をまとめたい」といった運用の一元化の話で登場します。

試験での出題傾向

WAFルールを複数アカウントで一元管理したい
新アカウントにも自動で同じルールを適用したい
Organizations前提の運用

サービス解説：脅威検知・分析・脆弱性

このカテゴリでは、システムに悪影響を及ぼすイベントの検知・分析を行う機能を提供するサービスを解説します。

Amazon Inspector

内容

Amazon Inspectorは、「攻撃される前に、システムの弱点（脆弱性）を見つけるサービス」です。

脆弱性はざっくり言うと「ソフトウェアの弱点」です。OSやライブラリが古いままだと、その弱点を突かれて侵入されることがあります。
Inspectorは、EC2（仮想サーバー）やコンテナ、Lambda（プログラム実行）を対象に、

更新不足（パッチ不足）
既に知られている弱点（CVE＝公開されている弱点の番号）

がないかを自動でチェックします。

試験でのポイントは「事前に弱点を洗い出す」ことです。
不審な動きを検知するGuardDutyとは目的が違います。

試験での出題傾向

本番前に脆弱性を洗い出したい
定期的に更新不足（パッチ不足）を見つけたい
EC2／コンテナ／Lambdaの脆弱性管理を自動化したい

Amazon GuardDuty

内容

Amazon GuardDutyは、「システム稼働中に“怪しい動き”を見つけるサービス」です。

GuardDutyは、次のようなログを材料にして（＝“証拠”として）、異常を判断します。

CloudTrail（操作ログ）
VPCフローログ（通信ログ）
DNSログ（名前解決のログ）

つまり、GuardDutyが見ているのは「データの中身」ではなく、操作や通信の“振る舞い”です。

試験では「見覚えのないAPI操作（AWSへの操作）」「普段と違う国からのアクセス」「不審な通信」といった、実行中の異常検知の文脈で登場します。

試験での出題傾向

不審なAPI操作（AWSへの操作）や通信を検知したい
セキュリティイベントを自動で見つけたい
継続的に脅威を監視したい

Amazon Macie

内容

Amazon Macieは、「S3に保存されているデータの中身を見て、機密情報を見つけるサービス」です。

ポイントは、Macieが機械学習（ML：コンピュータが特徴を学んで判定する仕組み）を使って、データを自動分類できることです。
たとえばS3のファイルに、

個人情報（PII：個人を特定できる情報）
クレジットカード番号

のようなものが入っていないかを、自動で検出します。

GuardDutyが「怪しい操作・通信」を見るのに対して、Macieは「保存されているデータそのもの」を見る。
この違いが分かると、試験の選択肢で迷いません。

試験での出題傾向

S3に個人情報や機密情報が含まれていないか確認したい
データ分類を自動化したい
情報漏えいリスクを把握したい

Amazon Detective

内容

Amazon Detectiveは、「セキュリティの問題が起きた“後”に、原因を調べやすくするサービス」です。

何が起きたのか
どのユーザー／どの端末（EC2）／どのIPが関係しているのか
いつから怪しいのか

Detectiveは、関連する情報を時系列やつながり（関係）で整理し、調査を楽にします。

重要なのは、Detectiveは「新しく検知する」サービスではなく、検知後の分析（調査）を助ける立ち位置だということです。

試験での出題傾向

GuardDutyの検知結果を詳しく調べたい
インシデントの原因調査を効率化したい

AWS Security Hub

内容

AWS Security Hubは、「セキュリティの結果を“まとめて見る”ためのサービス」です。

GuardDuty、Inspector、Macieなどの結果がバラバラだと、

どこで何が起きているのか
何から対応すべきか

が分かりにくくなります。
Security Hubは、これらの結果を1か所に集約し、全体の状況を把握しやすくします。

試験でのポイントは、Security Hubは「検知そのもの」をするのではなく、結果の集約・可視化が役割だということです。

試験での出題傾向

セキュリティ状況を一元的に把握したい
複数サービスの検知結果をまとめて確認したい

サービス解説：境界・アプリケーション防御

このカテゴリでは、「外部からの攻撃を入口で防ぐ」サービスを扱います。

AWS WAF

内容

AWS WAFは、「Webアプリケーションへの攻撃を防ぐサービス」です。

ALB（Application Load Balancer：負荷分散の入口）やCloudFront（コンテンツ配信の入口）と組み合わせ、アプリに届く前の通信を検査します。

試験での出題傾向

Webアプリへの攻撃対策
ALBやCloudFrontと組み合わせた防御

AWS Shield

内容

AWS Shieldは、「DDoS攻撃（大量アクセス攻撃）から守るサービス」です。
DDoSは、攻撃者が大量のアクセスを送りつけてサービスを止めようとする攻撃です。

Shieldは、CloudFront（コンテンツ配信の入口）やALB（Application Load Balancer：負荷分散の入口）、Route 53などインターネットの入口に近い部分で防御を行います。

試験では、

「大量アクセスによりサービスが落ちるのを防ぎたい」
「DDoS対策をしたい」

という要件が出たらShieldが候補になります。

試験での出題傾向

大量アクセス（DDoS）からサービスを守りたい
Shield Standard と Advanced の違い

AWS Network Firewall

内容

AWS Network Firewallは、「VPCの中を流れる通信をまとめてチェックして止められる“ネットワーク用の防御サービス”」です。

セキュリティグループやネットワークACL（ネットワークの通行ルール）は、基本的に「IPとポート」などの条件で許可／拒否を決めます。
一方でNetwork Firewallは、より高度なルールで通信を検査できます。

試験では「セキュリティグループやネットワークACLだけでは不安」「VPC全体で統一した通信ルールを適用したい」という文脈で登場します。

試験での出題傾向

VPC内通信を詳細に制御したい
セキュリティグループでは足りない通信制御

サービス解説：機密情報管理

このカテゴリでは、「パスワードやAPIキーなどの重要な情報を安全に保管する」ためのサービスを扱います。

AWS Secrets Manager

内容

AWS Secrets Managerは、「パスワードやAPIキーを安全に保管するサービス」です。
暗号化して保存でき、定期的な自動ローテーションにも対応しています。

試験では、「定期的にパスワードを変更したい」「アプリから安全に参照したい」といった 秘密情報管理 の要件で登場します。

試験での出題傾向

パスワードや認証情報の安全な管理
自動ローテーション要件

サービス解説：コンプライアンス・監査

このカテゴリでは、「監査対応や証跡の準備を楽にする」ためのサービスを扱います。

AWS Artifact

内容

AWS Artifactは、「AWSが提供する監査・コンプライアンス資料を入手する場所」です。
AWS側が用意しているSOCレポートやISO認証などを確認できます。

試験では、「AWSが取得している監査資料を提示したい」という 資料取得 の文脈で登場します。

試験での出題傾向

AWSのコンプライアンス資料を確認したい

AWS Audit Manager

内容

AWS Audit Managerは、「自社環境の監査対応を支援するサービス」です。
監査に必要な証跡を自動で集め、整理するのを助けます。

試験では、「監査準備の手間を減らしたい」といった 監査効率化 の要件で登場します。

試験での出題傾向

監査対応を効率化したい
証跡収集を自動化したい

全体サマリ（1サービス1文で試験直前に総復習）

ここでは、各サービスを「どんな問題文が出たら、そのサービスを選ぶのか」という観点で、
1サービス＝1文で整理します。試験直前は、この章だけを流し読みしてください。

アイデンティティ／アクセス管理

IAM：AWSリソースに対して「誰が何をしてよいか」を制御したいときに使う基本の権限管理。
IAM Identity Center：複数AWSアカウントで、従業員のログインと権限管理をまとめたいときに使う。
Amazon Cognito：Web／モバイルアプリに、利用者向けのログイン機能を実装したいときに使う。
AWS Resource Access Manager（RAM）：VPCなどのAWSリソースを、組織内の別アカウントと共有したいときに使う。

鍵管理・暗号

AWS KMS：S3やEBSなどのデータを、AWS管理の暗号鍵で簡単に暗号化したいときに使う。
AWS CloudHSM：暗号鍵をAWSに預けず、自社で厳密に管理する必要があるときに使う。

ログ・構成・ガバナンス

AWS CloudTrail：誰が・いつ・何を操作したのかを後から確認したいときに使う。
AWS Config：AWSリソースの設定が、ルール通りかどうかを継続的に確認したいときに使う。
AWS Organizations（SCP）：複数AWSアカウントをまとめ、組織全体で操作の上限ルールを強制したいときに使う。
AWS Firewall Manager：WAFやNetwork Firewallのルールを、複数アカウントへ一括で適用したいときに使う。

脅威検知・分析・脆弱性

Amazon Inspector：本番前や定期的に、EC2やコンテナの脆弱性を洗い出したいときに使う。
Amazon GuardDuty：稼働中の環境で、不審な操作や通信を自動で検知したいときに使う。
Amazon Macie：S3に保存されたデータに、個人情報や機密情報が含まれていないか確認したいときに使う。
Amazon Detective：GuardDutyなどの検知結果をもとに、インシデント原因を詳しく調査したいときに使う。
AWS Security Hub：複数のセキュリティサービスの検知結果を、まとめて把握したいときに使う。

境界・アプリケーション防御

AWS WAF：Webアプリケーションへの攻撃を、ALBやCloudFrontの前段で防ぎたいときに使う。
AWS Shield：DDoS攻撃（大量アクセス）から、サービス全体を守りたいときに使う。
AWS Network Firewall：VPC内の通信を、セキュリティグループやネットワークACLより細かく制御したいときに使う。

機密情報管理

AWS Secrets Manager：パスワードやAPIキーを安全に保管し、定期的に自動更新したいときに使う。

コンプライアンス・監査

AWS Artifact：AWSが取得している監査・コンプライアンス資料を確認したいときに使う。
AWS Audit Manager：自社環境の監査対応を効率化し、証跡収集を自動化したいときに使う。

参考リンク（公式）

本記事は、以下の AWS公式ドキュメント／公式ページ を一次情報として整理しています。試験対策としては本文の理解を優先し、必要に応じて公式情報に立ち戻る使い方がおすすめです。

※ 試験対策としては、すべてを読み込む必要はありません。本文で整理した「役割・境界・使いどころ」を軸に、気になったサービスだけ公式ドキュメントで補強する、という使い方で十分です。

練習問題

ここでは、CLF／SAAでよく出る典型的なシナリオをもとに、**本試験に近い「選択式（4択）」**の練習問題を用意しました。

各問題では、まず

どのカテゴリの話か
何をしたいのか

を意識してから選択肢を見てください。

まとめ

AWSのセキュリティサービスは、個別に暗記しようとすると必ず混乱します。CLF／SAAで重要なのは、「どのカテゴリの話か／何をしたいのか」を問題文から読み取り、適切なサービスを選べることです。本記事では、セキュリティサービスをカテゴリごとに整理し、試験でそのまま使える判断軸に落とし込みました。特に、3章の「1サービス1文サマリ」と5章の練習問題を押さえておけば、セキュリティ分野は大きな失点を防げます。試験直前は細部にこだわりすぎず、「この要件なら、このサービス」と即答できる状態を目指してください。本記事が、その最終確認として役立てば幸いです。

このほかにもAWS認定資格試験の対策に関する記事がありますので、以下のリンクから気になる記事を覗いてみてください！

”AWS認定資格試験の対策記事一覧”

The post AWS試験対策(CLF/SAA)：セキュリティサービスをまとめて簡単解説 first appeared on 運用保守エンジニアに成る。.

AWSクラウドプラクティショナー(CLF)合格体験記

いけやん — Sun, 01 Mar 2026 09:55:19 +0000

AWS認定資格であるクラウドプラクティショナー（以降、CLF）を受けようと思ったものの、手が止まっていませんか。

教材は多い。
体験記も多い。
それでも、「自分は何をすればいいのか」が定まらない。

本音はこうではないでしょうか。

『まずは資格を取りたい』

理解を極める前に、合格という結果を出したい。
履歴書に書ける実績を作りたい。
次の資格やキャリアに進む土台を作りたい。

本記事ではそんな方のために、AWS未経験の私が実際にAWS CLFに合格するまでに実施した勉強方法を解説していきます。

＜前提＞
私がCLFに合格したときの経歴は、IT経験7年・クラウド実務未経験。
そのため、IT未経験者の場合は、本記事で解説する内容に加えてIT基礎を学ぶ労力と時間がかかるイメージで考えてください。(ITパスポートを取れるくらいの実力)

試験概要の整理

まず、試験対策の解説に入る前に簡単に試験概要を簡単に解説していきます。

AWSクラウドプラクティショナーの正式名称は、
AWS Certified Cloud Practitioner（CLF-C02）です。

AWS認定資格の中では「Foundational（基礎レベル）」に位置づけられ、クラウドの基本概念、主要サービス、料金体系などが問われます。

試験の基本情報

・試験時間：90分
・問題数：65問
・出題形式：択一選択問題および複数選択問題
・スコア形式：100〜1,000点のスケールスコア
・合格基準：700点以上
・受験方法：テストセンター受験またはオンライン監督試験
・受験料：100USD（約15,000円〜16,500円程度）※為替により変動

65問を90分で解くため、1問あたり約1分強。
時間配分は意識する必要があります。

公式参考リンク

試験の詳細や申し込み方法の最新情報は公式ページで確認してみてください！

・試験概要（公式）：https://aws.amazon.com/jp/certification/certified-cloud-practitioner/
・試験ガイド（CLF-C02）：https://d1.awsstatic.com/ja_JP/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf
・試験申込方法（AWS Certification）：https://aws.amazon.com/jp/certification/

勉強方法（教材・流れ）

勉強時間

勉強期間は4か月をかけました。
実際の勉強方法は以下の通りです。

・平日：30分（通勤電車）
・休日：2時間（自宅）

総学習時間は約60〜70時間といったところですね。

使用した教材

使用した教材はUdemyの2つのコースのみです。
いずれも有料になりますが、値段もかなりお手頃で解説も簡潔でわかりやすいため、資格取得を手っ取り早くしたい方は書籍よりも以下で紹介するコースを購入することを強くおススメします。

① Udemyコース①

・動画による基礎学習：14.5時間
・模擬試験：2回分 × 6周（約12時間）

＜講座リンク＞
【CLF-C02版】これだけでOK! AWS認定クラウドプラクティショナー試験突破講座（豊富な試験問題300問付き）

② Udemyコース②

・模擬試験：6回分 × 6周（約36時間）　※講座なし

＜講座リンク＞
【CLF-C02版】最多合格実績のAWS 認定クラウドプラクティショナー模擬試験問題集（6回分390問）

勉強の進め方

勉強の進め方は大きく2段階に分けられます。

① インプット：講座を受講する
② 問題演習：模擬試験を繰り返し解く

いたってシンプルですが、それぞれのポイントがあるので以下にまとめていきます。

① インプット：講座を受講する

上記で紹介しているUdemyコース①を最後まで視聴しました。

意識したポイントは2つあります。

・疑問が出ても深追いしない
・キーワードと簡単な概要は重視して確認する

講座自体が15時間弱とかなり長いので、わからないことを逐一深堀して調べているとかなり時間がかかってしまうのと、講座を受け終える時点で前半の内容を忘れてしまうことがほとんどのため、まずはスピード感をもって全体をさらうことが重要になります。

② 問題演習：模擬試験を繰り返し解く

講座を受講し終わったら、上記で紹介しているUdemyコース①,②の模擬試験を繰り返し解きました。
だいたい目安としては模擬試験がすべて9割以上の正答率になればCLFに合格するには十分な知識が身についたと言えると思います。
私は正答率9割に到達するまでに6週かかりました。

・コース①の模擬試験：2回分 × 6周
・コース②の模擬試験：6回分 × 6周

1つの模擬試験の取り組み方についてですが、本試験は時間制限があるため、時間を意識して問題を解いていきます。
Udemyの模擬試験では問題に対してマークをして、終了後に見返すことができる機能があるため、回答に自信がない問題はマークをつけながら1つの模擬試験をやり切ります。
模擬試験が終わったら、間違えた問題と、途中でマークした問題の解説を確認していくという流れです。
解説を理解していく際には、ChatGPTなどの生成AIを活用することをおすすめします。
※詳細な活用方法は、次のセクションで解説していきます。

勉強方法のコツ

生成AIにサービスの解説をお願いする

AWSには用途別に豊富なサービスが存在しており、類似するサービスについてはその違いが分かりづらいという側面があります。
ここでおススメしたいのが用途ごとや類似サービスごとにその内容を生成AIにまとめさせることです。
模擬試験を解いた後、間違えた問題やマークをした問題に対して、解説文を読むだけでなく生成AIに質問をすることで理解を深めるとインプット効率がかなり上がりました。

生成AIへの質問の仕方についておすすめのプロンプト文を紹介します。

○○の用途について教えて
○○と△△の違いを教えて
AWSのセキュリティに関連するサービスの比較表を作成して

講座はサクッと模擬試験をガッツリと

上記でも述べていますが、講座のターンはとにかくスピード感を重視ししてわからないとこが少しあってもすっ飛ばす勢いで学習を進めておくことをおススメします。
そして模擬試験では解答確認の際にしっかりと時間を割いて、自身の弱点を克服する時間に充てることが重要です。

講座の受講に注力しても時間を変えた割に、定着度は今一つという状態に陥る可能性が高いです。
暗記系の作業が得意な方は、書籍などの教材を買ってじっくり学習を進める方法をとっても良いと思いますが、短期で資格取得を目指す方にとっては非効率だと思います。

まとめ

AWS CLFに合格するまでの勉強方法やコツ、それまでにかかる時間など具体的にイメージできたのではないでしょうか？
これから試験勉強をしていこうと考えているかたは、今回の記事の内容を参考にしていただければと思います。

また、本記事でも触れた「生成AIにサービスの解説をお願いする」について、私が実際にやってみて、さらにその内容をIT初心者でもわかりやすいように解説した記事もありますのでぜひそちらもご覧になってください。

＜記事リンク＞
”AWS認定資格試験の対策記事一覧”

The post AWSクラウドプラクティショナー(CLF)合格体験記 first appeared on 運用保守エンジニアに成る。.

AWS試験対策(CLF/SAA)：コスト管理ツールを用途ごとに簡単解説

いけやん — Sun, 30 Nov 2025 12:14:58 +0000

AWS認定試験の学習中、「コスト関連のサービスが多すぎて、どれが何の目的で使われるのかいつも迷う…」そんな悩みを感じたことはありませんか？
私自身も、「コスト管理ツールは多いのに、用途ごとの使い分け問題でいつも間違える…」といった壁に何度もぶつかってきました。

この記事では、そうした混乱をスッキリ解消するために、試験でよく問われる主要なコスト管理ツールを“目的別”に整理しています。内容はすべてAWS公式ドキュメントに基づいており、正確性と信頼性にも配慮しています。

無理なく覚えやすく、選択肢で迷わなくなるように、ポイントを押さえて一緒に確認していきましょう。

AWSコスト管理の全体像

AWSのコスト管理に関するツールやサービスは多岐にわたり、それぞれの役割を整理して理解することが重要です。このセクションでは、後半で解説する各ツールの使い分けをスムーズにするために、目的別のカテゴリに分けて全体像を一覧化しました。

次のセクションへ進む前に、各サービスの位置づけを視覚的に整理しておきましょう。

カテゴリ	主な目的	主なツール
コスト予測	利用前にコストを見積もる	Pricing Calculator
コスト可視化・監視	利用中のコストを見える化し、予算超過や異常を検知する	Cost Explorer / Budgets / コスト異常検知 / 請求アラート
コスト最適化	無駄なリソースを削減し、効率的な構成へ改善する	Trusted Advisor / Compute Optimizer / コスト最適化ハブ
コスト分析	詳細な利用明細を取得し、集計・分析する	コストと使用状況レポート
組織別コスト管理	組織単位・タグ単位でのコスト分類と統合管理	コスト配分タグ / Cost Categories / Organizations / 請求ダッシュボード / Billing Conductor

この全体像を把握したうえで、次のセクションから各ツールの具体的な機能や使い方を一緒に見ていきましょう。

各ツール・サービスの役割と使いどころ

AWS Pricing Calculator

概要

AWS導入前に、クラウドリソースの利用料金を事前に見積もるためのツールです。インスタンスタイプやリージョンなどを指定して構成し、月額・年額の見積もりを算出できます。

主な機能・特徴

GUIで構成しながら簡単に見積もり作成可能
複数サービスを組み合わせた詳細な見積もりに対応
保存・共有・エクスポートが可能

他ツールとの違い

導入前のコスト見積もりに特化しており、利用中の可視化や分析には不向き

試験での出題傾向

「導入前にコストを予測したい」といった文脈でよく登場
構成要素を指定して見積もる場面が想定される

AWS Cost Explorer

概要

利用中のAWSサービスのコストと使用状況を視覚的にグラフで表示するツールです。フィルタやグループ化により詳細分析が可能です。

主な機能・特徴

月ごとのコスト推移を可視化
サービス別・アカウント別のグループ集計
予測機能あり（今後の傾向も表示）

他ツールとの違い

可視化と傾向分析に強いが、しきい値通知は不可

試験での出題傾向

「コストの傾向を確認したい」「グラフで把握したい」などの文脈で登場
予測機能やグループ化条件が問われる

AWS Budgets

概要

特定のサービスやアカウントに対して予算を設定し、実際の使用状況と比較してしきい値を超えた場合に通知を送る機能です。

主な機能・特徴

コスト、使用量、リザーブドインスタンス/Savings Plansの利用率など多様な条件に対応
SNSなどを使ったアラート通知
成果指標やKPIにも活用可能

他ツールとの違い

Budgetsはサービス単位でしきい値設定が可能(請求アラートは「AWSコスト全体」しきい値設定のみ)

試験での出題傾向

「サービスごとに予算を設定したい」「予算超過を通知したい」などのシナリオで登場
条件や通知対象が問われる

コスト異常検知（AWS Cost Anomaly Detection）

概要

過去のコスト使用傾向を機械学習で分析し、異常な請求が発生した際に自動で通知するサービスです。

主な機能・特徴

機械学習で異常検知
定義したモニタごとにアカウントやサービス単位で設定可能
SNSによる通知設定あり

他ツールとの違い

請求アラートより精度の高い分析

試験での出題傾向

「急激なコスト変動を検知したい」といった文脈で選択肢に登場
機械学習や通知方法が問われる

請求アラート（CloudWatch Billingアラーム）

概要

請求アラートは、AWSアカウントの請求額が特定のしきい値を超えた際にアラームを発報する機能です。CloudWatchと連携し、リアルタイムでコストの急増を検知できます。

主な機能・特徴

CloudWatchメトリクス「EstimatedCharges」を利用
SNS通知と連携してアラート送信
AWS Budgetsよりも即時性に優れる

他ツールとの違い

請求アラームは全体の請求額監視に特化(AWS Budgetsはサービスごとのしきい値設定が可能)

試験での出題傾向

請求超過の即時通知手段として選択肢に登場

AWS Trusted Advisor

概要

AWSアカウントの設定をチェックし、ベストプラクティスに基づいた改善提案を行うサービスです。コスト、セキュリティ、信頼性、パフォーマンス、サービス制限の5カテゴリに対応します。

注意

AWS Trusted Advisorはコスト管理のみのサービスではなく、一部の機能としてコスト最適化の改善提案の役割を担います。

主な機能・特徴

未使用のリソースやアイドル状態のリソースを検出
一部のチェックは無料、全機能利用にはBusinessサポート以上が必要
ダッシュボードで改善状況を可視化

他ツールとの違い

Compute Optimizerが“使用実績”から提案するのに対し、Trusted Advisorは“設定”に基づく静的チェックが中心

試験での出題傾向

「コスト最適化のために未使用リソースを削減したい」「改善提案を確認したい」といったシナリオで登場

AWS Compute Optimizer

概要

実際のリソース使用データをもとに、コスト最適化とパフォーマンス改善のためのインスタンスタイプの推奨を行うサービスです。

主な機能・特徴

CPU、メモリ、ネットワーク指標に基づいて推奨
EC2、EBS、Lambda、Auto Scalingなどに対応
推奨の理由（アンダー/オーバープロビジョニングなど）も提示

他ツールとの違い

Trusted Advisorより“動的・使用実績ベース”の分析
より細かいパフォーマンス指標に基づいた提案

試験での出題傾向

「EC2の無駄をなくしたい」「最適なインスタンスタイプに変更したい」という文脈で出題
Trusted Advisorとの使い分けが問われる

コスト最適化ハブ（Cost Optimization Hub）

概要

コスト最適化に関連する複数のサービス（Trusted Advisor、Compute Optimizer、Savings Plans）などからの推奨事項を一元的に可視化・管理するハブ型ツールです。

主な機能・特徴

各サービスの推奨を1か所で管理
組織全体やアカウント単位での確認が可能
フィルターやアクション追跡などの管理機能も充実

他ツールとの違い

個別の最適化ツールを統合的に扱える

試験での出題傾向

Trusted AdvisorやCompute Optimizerとの連携を問う問題で登場
「最適化提案を一元管理」といったキーワードがヒント

コストと使用状況レポート（Cost and Usage Report）

概要

AWSの利用明細をCSV形式で出力し、詳細なコスト分析や請求処理に活用できるレポート機能です（略称：CUR）。

主な機能・特徴

S3バケットに毎日または時間単位で出力
Athena、Redshift、QuickSightと連携して集計・分析
最も詳細な課金情報が含まれる

他ツールとの違い

Cost Explorerよりもはるかに詳細なレベルでの分析が可能

試験での出題傾向

「コストを詳細に分析したい」「外部ツールで利用明細を処理したい」といった文脈で登場

コスト配分タグ（Cost Allocation Tags）

概要

AWSリソースにタグを付け、それを使ってコストを分類・分析するための仕組みです。

主な機能・特徴

ユーザー定義タグとAWS提供タグに対応
コスト配分タグは有効化が必要
Cost ExplorerやCURと連携して集計に活用可能

他ツールとの違い

タグベースの分類が可能なのはこの機能だけ
Cost Categoriesと併用することで柔軟な分類が可能

試験での出題傾向

タグによる課金集計の手段として選択肢に登場
有効化の必要があることを問われる場合も

Cost Categories

概要

AWSリソースにコスト配分のためのタグを付けることで、部門別・プロジェクト別など任意の単位でコストの分類・追跡を可能にする機能です。タグに基づいたコスト分析を行うための前提となる設定です。

主な機能・特徴

複数の条件（アカウント、サービス、タグなど）で柔軟に分類
Cost ExplorerやBudgetsで利用可能
カテゴリごとの集計・フィルタが容易になる

他ツールとの違い

タグを用いた分類はCost Allocation Tags、複数条件を掛け合わせた分類はCost Categories
より高次の集計・レポート作成に向いている

試験での出題傾向

タグだけでは分類できない複数条件の例で出題
「プロジェクト別にコストを見たい」といった文脈で選択肢に登場

AWS Organizations

概要

複数のAWSアカウントを統合管理できるサービスで、請求の一括化（コンソリデーティッドビリング）やポリシーの統制に活用されます。

注意

AWS Organizationsはコスト管理のみのサービスではなく、一部の機能としてコスト最適化の改善提案の役割を担います。

主な機能・特徴

一括請求（Consolidated Billing）で請求情報を集約
SCP（サービスコントロールポリシー）によるアクセス制御
OU（組織単位）による階層的管理

他ツールとの違い

コスト分類というより“請求統合”や“ポリシー制御”に関わる
Billing Conductorと組み合わせることで社内課金に対応

試験での出題傾向

「複数アカウントを統合管理したい」「組織単位でコストをまとめて管理したい」といった文脈で登場

請求ダッシュボード（Billing & Cost Management コンソール）

概要

請求書の確認、支払い方法の設定、支払い履歴などを管理するための標準的なWebコンソールです。

主な機能・特徴

課金状況のダッシュボード表示
支払い方法や請求書のダウンロード
Cost ExplorerやBudgetsなど他機能へのリンク

他ツールとの違い

コスト分析ではなく“支払い管理”に特化
実務では必ず使う基礎的なコンソール

試験での出題傾向

支払い情報の管理手段として選択肢に登場
請求確認の方法を問われる

Billing Conductor

概要

AWS Organizationsで統合された請求を、内部的に再構成して部門ごとや顧客単位で課金できるようにする高度な機能です。

主な機能・特徴

アカウントごとに独自の請求ルールを設定可能
見かけ上の請求金額をカスタマイズ可能（社内課金など）
専用ダッシュボードで管理・確認が可能

他ツールとの違い

外部請求でなく内部請求（社内コスト配分）向け
Organizationsと連携して初めて意味を持つ

試験での出題傾向

上級試験で「社内部門ごとの請求調整をしたい」などのシナリオで出題
実務要素が強いためCLFでは出題少なめ

シナリオ別まとめ

ここでは、実際の試験や現場で問われる“課題や目的”に対して、どのサービスを使うべきかをすぐに判断できるように整理しています。似たようなツールが複数登場して混乱しやすい分野のため改めてまとめておくので参考にしてください！

やりたいこと	該当ツール
新規導入前にコストを見積もりたい	AWS Pricing Calculator
利用中のコスト傾向をグラフで把握したい	AWS Cost Explorer
リソースごとに予算を設定して通知を受けたい	AWS Budgets
異常な請求を自動で検出したい	コスト異常検知
請求額が一定額を超えたら即通知を受けたい	請求アラート
未使用リソースを見つけて削減したい(設定情報をもとに)	Trusted Advisor
未使用リソースを見つけて削減したい(使用データをもとに)	Compute Optimizer
削減提案を一元管理したい	コスト最適化ハブ
詳細なコストデータをCSVで出力・分析したい	コストと使用状況レポート（CUR）
コストをタグや部門で分類・集計したい	コスト配分タグ / Cost Categories
組織全体のアカウントを統合管理したい	AWS Organizations
独自ルールで社内請求を再構成したい	Billing Conductor
支払い方法や請求書を確認したい	請求ダッシュボード（Billing & Cost Management コンソール）

参考リンク

今回紹介したAWSコスト管理ツールについて記載されているAWS公式ドキュメントへのリンクです。試験対策や実務の確認にご活用ください！

練習問題

上記で学んだことをもとに実際にAWS認定試験と同じ形式で問題を解いてみましょう。
試験で狙われやすいポイントを重視して問題設定をしています。

まとめ

本記事では、AWSのコスト管理に関するツールを「目的別」に整理し、試験で狙われやすい観点から理解を深めることを目的に解説しました。サービス数が多く複雑に感じる領域ではありますが、“いつ・何を・なぜ使うのか”を理解することで選択問題にも対応できるようになります。

このほかにもAWS認定資格試験の対策に関する記事がありますので、以下のリンクから気になる記事を覗いてみてください！

”AWS認定資格試験の対策記事一覧”

The post AWS試験対策(CLF/SAA)：コスト管理ツールを用途ごとに簡単解説 first appeared on 運用保守エンジニアに成る。.

AWS試験対策(CLF/SAA)：AWS CAF(クラウド導入フレームワーク)を簡単解説

いけやん — Sat, 22 Nov 2025 03:28:27 +0000

AWSの認定試験で頻出である「AWS CAF」、“覚えづらい”と思いませんか？それは、6つのパースペクティブそれぞれの役割が抽象的で、どの視点がどんな内容を担当しているのか分かりにくいからなのです。
そこで、この記事ではCAFを比較的省エネで理解できるようにまとめてみました。特に、試験でよく狙われる紛らわしいポイントや、パースペクティブ同士の境界をかみ砕いて説明しているので、「あれ？これってどの視点だっけ？」という迷いを一つずつ減らしていけるはずです。

AWS CAFの概要

AWS CAFとは？

組織がクラウドサービスを効果的に導入・運用できるよう、AWSの経験とベストプラクティスを集約したガイドラインです。
CAFは、クラウド導入を成功に導くために必要な6つの視点（パースペクティブ）で構成されています。各パースペクティブは、ビジネス・人材・ガバナンス・プラットフォーム・セキュリティ・オペレーションのそれぞれに焦点を当てており、「どの観点をどのように整備するか」を明確にします。

パースペクティブ	概要
ビジネス（Business）	クラウド投資がビジネス成果につながることを確保する視点
人材（People）	組織・人材・文化・スキルをクラウド適応できるように整える視点
ガバナンス（Governance）	クラウド導入を管理・制御し、リスクと価値を最適化する視点
プラットフォーム（Platform）	ハイブリッド／クラウド基盤を実現・標準化・モダナイズする視点
セキュリティ（Security）	データ／ワークロードの機密性・整合性・可用性を実現する視点
オペレーション（Operations）	クラウド環境を運用・監視・改善して、ビジネス要件を満たす視点

これら6つを通して、クラウド導入に伴う変化を ビジネスと技術の両面から体系的に整理 できます。

いつ・どのように使うのか

CAFは、クラウド導入の初期段階で「現状把握」と「改善ポイントの特定」を行うために使います。ズバリ言うと、CAFは“クラウド移行に向けて会社として何が足りていて、何が足りていないのか”を明確にするための仕組みです。公式に沿った最も実務的な使い方は以下です。

① クラウドビジネスアセスメントを実施する

CAFを使うとき、一番重要なのは Cloud Business Assessment（クラウドビジネスアセスメント） です。これは、AWSが公式に推奨する“CAFの中心となる使い方”です。
アセスメントの進め方は次のとおり：

6つのパースペクティブごとに質問（設問）が用意されている
現状がどの程度できているか（成熟度）をスコアとして回答する
スコアが低い領域＝移行に向けてリスクがある領域として可視化
不足している能力（Capabilities）を補うためのアクションが自動的に提示される

AWSワークショップではこのプロセスが標準で行われます。誤情報を避けて明確に言うと、CAFを使う “実務的な中心作業” はこのアセスメントです。

② 結果をもとに、改善ロードマップを作成する

アセスメントでスコアが低い領域（例：人材スキル、ガバナンス、セキュリティ統制など）は、移行における“詰まりポイント”になり得ます。CAFでは、これら不足している能力に対し、パースペクティブごとのガイダンス（Capabilities） が提供されます。つまり、「何を整備すればよいか」「どんな順番で進めるべきか」「誰が関わるべきか」といった改善内容が、公式ドキュメントに沿って明確になります。これに基づき、クラウド移行に向けた 改善ロードマップ を作成します。

③ 移行前・移行中・運用後にも“点検”として使う

CAFは「一度やって終わり」ではなく、システムの移行前、移行中、移行後の運用フェーズでも継続的な点検が実施されます。

移行前：成熟度評価と改善計画
移行中：改善ロードマップに沿って進捗確認
運用後：再度CAFを使い、組織としての成熟度が向上したか評価

6つのパースペクティブの詳細解説

各パースペクティブについて、AWS認定試験（CLF／SAA）で問われやすいキーワードを意識して以下に整理します。試験では概念理解と用語の結びつきが重要となるため、キーワードを押さえておくことで得点しやすくなります。

ビジネス（Business）

クラウド導入の目的を明確にし、投資がどのようにビジネス価値を生み出すかを定義する視点です。たとえば、業務効率の向上、新規サービスのスピード改善、コスト構造の最適化など、「クラウドが経営戦略にどう寄与するか」を整理します。

ビジネス視点の主なCapabilities（AWS公式）

ストラテジーマネジメント：
クラウドを活用してビジネス成果を加速させる戦略を策定する能力
プロダクトマネジメント：
データやクラウド活用のプロダクトを管理し価値を提供する能力
ビジネスインサイト：
ビジネス状況をリアルタイムで把握し、意思決定に役立つ洞察を得る能力
ポートフォリオマネジメント：
価値の高いクラウドプロダクトやイニシアティブの優先順位を付け、投資を最適化する能力
戦略パートナーシップ：
クラウドプロバイダーとの戦略的パートナーシップを構築し、ビジネス成長につなげる能力
データサイエンス：
分析・機械学習を活用し複雑なビジネス課題を解決する能力
イノベーションマネジメント：
新しいプロセス・サービス・製品を生み出し、既存のものを改善する能力
データの収益化：
データを活用し具体的なビジネス価値（収益・効率化）を獲得する能力

これらはすべてAWS公式CAFホワイトペーパーに定義されている内容であり、ビジネス視点が「単に経営目標とクラウドを結びつけるだけでなく、データ活用やイノベーション創出まで含む広い範囲」を対象としていることがわかります。

ポイント

データサイエンスやデータの収益化についてはビジネスパースペクティブに紐づきにくい用語のため、選択問題として問われた際は注意しましょう。
また、全体的にガバナンスパースペクティブの内容と混同されがちなので以降で突き合わせて確認しておきましょう。

人材（People）

このパースペクティブでは、組織のスキルや文化をクラウド時代に適応させるための施策（教育、役割再定義、リーダー育成、変化管理）を扱います。「変化が日常になる」文化を築くことがゴールです。
さらにAWS公式では、人材（People）パースペクティブのために、以下のような能力が定義されています。これは“クラウド時代の人・組織が持つべき力”を体系化したものです。

人材視点の主なCapabilities（AWS公式）

文化の進化：
組織文化を評価し、デジタル変革に向けて段階的に進化させ、共通理解を形成する能力
ワークフォースのトランスフォーメーション：
クラウド時代にふさわしいスキルを持つ人材を育成し、高いパフォーマンスを発揮できるチームを構築する能力
トランスフォーメーションリーダーシップ：
組織変革を推進できるリーダーを育成し、クラウド導入を牽引する能力
変革の促進：
新しい働き方・プロセスの採用を促進し、組織が迅速に変化へ対応できるようにする能力
組織の連携：
組織構造・文化・ビジネスオペレーションを結びつけ、一貫性を持ってクラウド活用を推進する能力
クラウドフルエンシー：
クラウドを理解し、自信を持って業務に活かせるだけの知識と判断力を組織全体で持つ能力
組織設計：
クラウド時代の働き方に適した組織デザインを行い、役割・責任・プロセスを最適化する能力

これらの機能は、単に“教育を行う”という範囲にとどまらず、人材・組織文化・リーダーシップ・組織設計といった広範な領域でクラウド適応力を強化するためのものです。

ポイント

変革の促進については、ビジネスパースペクティブの内容と混同しがちなので注意しましょう。
また、ワークフォースのトランスフォーメーションやクラウドフルエンシーなど聞きなれない言葉は復習多めにした方が良いでしょう。

ガバナンス（Governance）

クラウドを導入しても、管理が不十分であればリスクやコストが膨らみます。この視点では、クラウド投資の効果測定、リスク管理、ポリシー策定、コンプライアンスなどを通じて、導入を統制しつつ継続的に最適化する方法を定義します。さらに、組織全体のリスクを抑えながら、クラウド投資によるメリットを最大化する仕組みづくりを支援するのも目的の一つです。経営層と技術部門の橋渡し役となる領域です。

ガバナンス視点の主なCapabilities（AWS公式）

プログラム／プロジェクト管理：
複数のクラウド施策をムダなく連携させて、計画的に進める能力
クラウド財務管理：
クラウド支出を計画・測定・最適化する能力
利益管理：
クラウド投資によって得られるビジネス上の利益を確実に実現・維持する能力
アプリケーションポートフォリオ管理：
ビジネス戦略に沿ってアプリケーション群を整理・最適化する能力
データキュレーション：
データカタログを整備し、データプロダクトのインベントリを管理する能力
リスク管理：
クラウド活用に伴うリスクを特定し、クラウドを活かしてリスクプロファイルを低減する能力
データガバナンス：
データに対する権限と統制を行使し、ステークホルダーの期待に応える能力

これらの機能は、「クラウド利用のルールづくり」から「コスト最適化」「リスク軽減」「データガバナンス」までを広くカバーしています。

ポイント

ビジネスパースペクティブの内容と混同されがちなので突き合わせて確認しておきましょう。
また、整理・管理という要素が深いものはガバナンスに該当するので最終手段の紐づけ方として覚えておくのもよいかと思います。

プラットフォーム（Platform）

アプリケーションやワークロードを安全かつ効率的に実行できるクラウド基盤を整備する視点です。ネットワーク、セキュリティ、モニタリング、CI/CD といった要素を標準化し、スケーラブルな環境を構築します。アーキテクトやエンジニアが主に担う領域です。

プラットフォーム視点の主なCapabilities（AWS公式）

プラットフォームアーキテクチャ：
クラウド環境のガイドライン・原則・パターン・ガードレールを定義し、標準化された基盤を構築する能力
データエンジニアリング：
組織全体でデータフローを自動化・オーケストレーションし、データ活用の基盤を整備する能力
データアーキテクチャ：
用途に適した分析基盤やデータアーキテクチャを設計・進化させる能力
プロビジョニングとオーケストレーション：
承認済みクラウドプロダクトのカタログを作成・管理し、ユーザーが適切に利用できるよう提供する能力
継続インテグレーションと継続デリバリー（CI/CD）：
アプリケーションやサービスを迅速に改善・展開できるよう、自動化されたCI/CDパイプラインを構築する能力
プラットフォームエンジニアリング：
セキュリティ統合と再利用可能なプロダクトを備えた準拠性の高いクラウド環境を構築する能力
モダンアプリケーション開発：
クラウドネイティブなアプリケーションを設計・構築し、クラウドのベストプラクティスに沿った形で提供する能力

これらは、インフラからデータ基盤、モダン開発まで含めた“総合的なプラットフォーム能力”です。

ポイント

プロビジョニングとオーケストレーション、継続インテグレーションと継続デリバリーに関してはオペレーションパースペクティブの内容と混同されがちなので注意しましょう。

セキュリティ（Security）

クラウド導入における「信頼性の根幹」を支える視点です。データ保護、アクセス管理、脅威検知、コンプライアンス対応を通じて、情報資産を守ります。

セキュリティ視点の主なCapabilities（AWS公式）

セキュリティガバナンス：
セキュリティに関する役割・責任・ポリシー・手順を明確に定め、組織全体に浸透させる能力
脅威検知：
設定ミス・脅威・異常動作など潜在的なセキュリティリスクを理解・特定する能力
データ保護：
データの可視性と制御を維持し、アクセス方法や利用状況を管理する能力
セキュリティ保証：
セキュリティおよびプライバシープログラムの有効性を監視・評価・管理・改善する能力
脆弱性管理：
脆弱性を継続的に識別・分類・修正・軽減する能力
アプリケーションセキュリティ：
ソフトウェア開発プロセス全体でセキュリティリスクを検知し、対処する能力
IAM（Identity and Access Management）：
大規模な環境でアイデンティティと権限を一貫して管理する能力
インフラ保護：
クラウド上のシステムやサービスを保護し、セキュリティ基準に準拠させる能力
インシデント対応：
セキュリティインシデントに迅速かつ効果的に対応し、潜在的な影響を最小化する能力

これらは AWS のセキュリティベストプラクティスを包括的に整理した能力セットです。

ポイント

インシデント対応がオペレーションパースペクティブの内容と混同されがちなので注意しましょう。

オペレーション（Operations）

クラウド環境を安定して運用し、継続的に改善していくための視点です。監視、インシデント対応、変更管理、パフォーマンス最適化などを通して、クラウドサービスを「運用可能な状態」で維持します。

オペレーション視点の主なCapabilities（AWS公式）

可観測性：
インフラやアプリケーションのデータから問題を可視化し、行動可能な洞察を得る能力
イベント管理／AIOps：
イベントを検知し、影響度を評価し、適切なコントロールアクションを決定する能力
インシデント・問題管理：
障害を迅速に復旧し、ビジネス影響を最小化する能力
変更／リリース管理：
本番環境への影響を最小限にしつつ、ワークロードの変更やリリースを安全に実施する能力
性能／キャパシティ管理：
ワークロード性能を監視し、現在および将来の需要に応じて最適なキャパシティを維持する能力
構成管理：
ワークロードの構成、依存関係、変更履歴を一元的に管理する能力
パッチ管理：
ソフトウェア更新を体系的に配布・適用し、セキュリティと安定性を維持する能力
可用性と継続性：
重要な情報・アプリケーション・サービスの可用性を確保する能力
アプリケーション管理：
アプリケーションの問題を単一画面から調査・監視・改善する能力

これらの機能はクラウド運用の“可視化・自動化・継続改善”を支える中核です。

ポイント

インシデント・問題管理、パッチ管理がセキュリティパースペクティブの内容と混同されがちなので注意しましょう。
また、全体的にプラットフォームの内容と混同されがちなので注意しましょう。

参考リンク

AWSが提供するCAF公式ドキュメントは、パースペクティブごとに役割・目的・能力（Capabilities）が詳細に整理されています。学習時は “パースペクティブ → 能力 → 活用シーン” の順に読むと理解しやすくなります。下記リンクはすべてAWS公式ホワイトペーパーです。

各パースペクティブの公式ホワイトペーパー

ビジネス（Business）：
https://docs.aws.amazon.com/whitepapers/latest/aws-caf-business-perspective/aws-caf-business-perspective.html
人材（People）：
https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/aws-caf-people-perspective.html
ガバナンス（Governance）：
https://docs.aws.amazon.com/whitepapers/latest/aws-caf-governance-perspective/aws-caf-governance-perspective.html
プラットフォーム（Platform）：
https://docs.aws.amazon.com/whitepapers/latest/aws-caf-platform-perspective/aws-caf-platform-perspective.html
セキュリティ（Security）：
https://docs.aws.amazon.com/whitepapers/latest/aws-caf-security-perspective/aws-caf-security-perspective.html
オペレーション（Operations）：
https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html

■全体像をつかむためのガイド

AWS Cloud Adoption Framework（総括文書）：
https://docs.aws.amazon.com/whitepapers/latest/aws-cloud-adoption-framework/aws-cloud-adoption-framework.pdf

CAFの主要概念（パースペクティブ・Capabilities・アセスメント手法など）はすべてこの総括文書に集約されています。まずは全体像を押さえ、必要に応じて各パースペクティブのホワイトペーパーを深掘りするのがおすすめです。

練習問題

まとめ

本記事では、AWS CAF の6つのパースペクティブを「役割」「能力」「試験での狙われ方」という3つの切り口で整理しました。CAFは範囲が広く抽象度も高いため、まずは“どのパースペクティブが何を扱うのか”を押さえることが理解の第一歩です。
このほかにもAWS認定資格試験の対策に関する記事がありますので、以下のリンクから気になる記事を覗いてみてください！

”AWS認定資格試験の対策記事一覧”

The post AWS試験対策(CLF/SAA)：AWS CAF(クラウド導入フレームワーク)を簡単解説 first appeared on 運用保守エンジニアに成る。.

AWS試験対策(CLF/SAA)：Well-Architected Frameworkの覚え方

いけやん — Sun, 02 Nov 2025 21:35:03 +0000

AWS認定試験で頻出のテーマ「Well-Architected Framework（ウェルアーキテクテッドフレームワーク）」
そこまで難しくないはずなのに、イマイチ定着しないと感じたり、意外と模擬試験で何回も間違えてしまったりするポイントであると思います。
この記事ではそんな方の悩みを打破できるよう、次の3ステップを通して理解を深めていただければと思います。

出題の傾向 … 実際の試験でどのように問われるかを確認します。
6つの設計原則について … 各設計原則の特徴と考え方をキーワード重視で整理します。
基本原則ではないものの識別 … 試験でよく出る“紛らわしいキーワード”を整理します。

出題の傾向

Well-Architected Frameworkについて、CLF/SAAでの出題形式は大きく2つのパターンになる傾向がみられます。

基本原則でないもの／基本原則であるものを選択

4~5くらいの選択肢の中から基本原則であるもの、そうでないものを選択させる形式。

例：「次のうち、Well-Architected Frameworkの設計原則ではないものはどれか？」
①運用上の優秀性　②安全性　③可用性　④信頼性
“③可用性”が正解

特定の原則に関する正しい内容を選択

6つ設計原則の内、1つの項目に対する正しい内容を選択させる形式。

例：「次のうち、Well-Architected Frameworkの安全性に当てはまる内容はどれか？」
①最小権限の付与　②サーバレスの活用　③障害を前提とした設計　④コスト可視化
“①最小権限の付与”が正解

6つの設計原則について

初心者でも「何を・どう覚えれば良いか」が明確になるよう構成しています。では、6つの設計原則の概要と重要なキーワードを見ていきましょう。

運用上の優秀性

リリースされた後のシステムを運用していくにあたり、継続的な改善を促していくための考え方です。システムを運用するためには、定例的な作業とトラブル時の対処が必要になります。この作業が効率よくミスなく行われるようにすることが、運用上の優秀性につながるのです。
改善の方法として最も効果的であるのが運用の自動化です。人が手順書に沿ってポチポチ操作するより、作業の内容をコードに落とし込み、時刻かイベント発生を契機に自動実行させる方がミスがないよね？楽だよね？というのは言うまでもないでしょう。
そして、この改善は、ぼーっと作業していても始まりませんし、逆に大きな効果を得ることにこだわっているとなかなか変革は進みません。
日常的に作業やイベントを観測し、改善点を探すこと、小さな改善を頻繁に行っていくことが必要になるんだよ～ということを覚えておきましょう。

💡 覚えておくべきキーワード
・継続的な改善
・運用の自動化(運用のコード化)
・小さく頻繁に変更

運用上の優秀性に必要な要素について、もう少し具体化すると以下のようなものがあげられます。

運用の自動化：定型作業（バックアップ取得、ログローテーション、死活監視の復旧手順など）はスクリプト化し、人手のばらつきを無くします。
運用をコードとして管理：手順や設定をドキュメントだけでなく、**コード（Infrastructure as Code・自動化スクリプト）**で再現可能にして、レビューや再利用を容易にします。
小さく頻繁な変更：大規模な一括変更よりも、小さく速く変更して早期に問題を発見・是正します。
観測と学習（メトリクス・ログ）：メトリクスとログを常に計測・可視化し、**事後振り返り（ポストモーテム）**で改善点を取り込みます。
準備と標準化：実行手順（ランブック）、**障害対応手順（プレイブック）**を用意し、だれが実施しても結果が安定するようにします。

安全性

システムの中で扱われる情報の漏洩や悪用などの脅威から守るための設計原則です。
データを脅威から守るためには、データにアクセスできる人を必要最小限に絞り込み(最小権限の原則)、データを暗号化して簡単には解読できないようにするなどの防御壁を複数設けることが重要になります。また、不正にアクセスを監視する仕組みや、もし、アクセスされた場合には状況を確認して原因を特定しやすくする仕組み(トレーサビリティ)も不可欠になることも覚えておきましょう。

💡 覚えておくべきキーワード
・最小権限の原則(ユーザ許可の管理)
・データの暗号化
・トレーサビリティ

安全性に必要な要素について、もう少し具体化すると以下のようなものがあげられます。

最小権限の原則：必要最小限の権限を付与し、リスクを減らす。
多層防御：ネットワーク・アプリ・データなど複数の層で守る。
データ保護：暗号化とアクセス制御を組み合わせる。
トレーサビリティ：CloudTrailなどで操作履歴を可視化する。
自動化された監査：Security Hubなどで設定の安全性を自動チェック。

信頼性

システムを止めない、壊れてもすぐに復旧できる、この「強さ」を設計する考え方です。ハードウェアの故障や災害を想定して、複数の筐体、複数の拠点でシステムを動かして(冗長化)、何か障害が発生しても片方の筐体で業務を継続させる仕組みを作ったり、障害が発生した際の復旧方法を定める、または自動的に復旧させる仕組みを作ったりするのが信頼性を強固にする重要な対応になります。

💡 覚えておくべきキーワード
・冗長化
・自動復旧
・バックアップとリストア
・障害を前提とした設計

信頼性に必要な要素について、もう少し具体化すると以下のようなものがあげられます。

障害を前提に設計：サーバーやAZ障害を想定して設計する。
自動復旧の仕組み：Auto ScalingやRoute 53のヘルスチェックなどを活用。
バックアップとリストア：定期的に実施し、手順もテストする。
キャパシティ管理：リソース不足で停止しないようにする。
テスト文化：フェイルオーバーテストで実際に耐障害性を確認。

パフォーマンス効率

リソースを効率よく使い、変化に応じて最適なパフォーマンスを維持するための考え方です。
AWSの柔軟な仕組み(スケーラビリティ／サーバレス)を活用し、必要な時に必要なだけ性能を引き出す設計を目指します。最先端技術を取り入れることを頻繁に検討していくこともパフォーマンス効率を求める際の重要な対応となります。

💡 覚えておくべきキーワード
・スケーラビリティ
・サーバレス
・最新技術の活用

パフォーマンス効率に必要な要素について、もう少し具体化すると以下のようなものがあげられます。

リソースの最適化：用途に合ったインスタンスやストレージを選ぶ。
スケーラビリティ：Auto Scalingやロードバランサーを活用する。
モニタリングと分析：CloudWatch・X-Rayで可視化する。
サーバーレスの活用：LambdaやRDSで効率運用を実現する。
最新技術の採用：新しいインスタンス世代などで性能を改善する。

コスト最適化

コスト最適化とは、単なる節約ではなく「お金の使い方を最適化する」考え方です。限られたお金で最大の価値を出すために、マネージド型サービス(AWSの管理範囲が広いサービス)を活用し、投資すべき箇所に集中したり、使用状況を可視化し、使われていないリソースを削除することも重要です。
また、AWSにはコストを分析するためのツールが存在するため、そのツールをうまく活用していくこともコスト最適化を進めていくうえで重要な対応になります。

💡 覚えておくべきキーワード
・コスト可視化
・サーバレス
・最新技術の活用

コスト最適化に必要な要素について、もう少し具体化すると以下のようなものがあげられます。

可視化と分析：Cost ExplorerやBilling Dashboardで使用状況を確認。
購入オプションの選択：RI・SPを活用してコストを抑える。
ライフサイクル管理：未使用リソースを削除して浪費を防ぐ。
自動スケーリング：需要に合わせてリソースを調整する。
コスト意識の共有：チーム全体でコスト効率を意識する文化を作る。

持続可能性（サステナビリティ）

システムの運用が環境に与える影響を減らすための考え方です。AWSが提供するクラウドを使うこと自体が、オンプレミス環境に比べて省エネにつながりますが、設計や運用を工夫することでさらに効果を高めることができます。
こちらはAWS側とユーザ側で役割が定められており、インフラを提供するAWS側はサーバの使用率や、データセンタの設備(電力や冷却装置)を最適化することでエネルギー効率を高めるという事が求められます。一方、ユーザ側はエネルギー効率に適したサービスやコードの選定をしていくことが求められます。
全体的に上述している5つの設計原則と被っていますが、それぞれの設計原則に対して持続可能性の観点を当てはめて考えるといった解釈をするとわかりやすいかなと思います。

💡 覚えておくべきキーワード
・エネルギー効率
・効率的なサービス選定

基本原則ではないものとしてよく出る要素

試験では、6つの設計原則に含まれない概念が選択肢として出されることがあります。これらを知っておくことで、誤答を避けやすくなります。

よく出る「紛らわしい」キーワード

ガバナンス（Governance）：管理体制やポリシーに関する概念で、設計原則そのものではありません。
コンプライアンス（Compliance）：法令遵守は重要ですが、Well-Architected Frameworkの柱には含まれません。
可用性（Availability）：信頼性の一部として扱われますが、独立した設計原則ではありません。

まとめ

この記事で紹介したWell-Architected Frameworkは、AWS認定試験全般において基礎となる重要テーマです。
このほかにもAWS認定資格試験の対策に関する記事がありますので、以下のリンクから気になる記事を覗いてみてください！

”AWS認定資格試験の対策記事一覧”

The post AWS試験対策(CLF/SAA)：Well-Architected Frameworkの覚え方 first appeared on 運用保守エンジニアに成る。.

AWS試験対策(CLF/SAA)：EC2の特徴をわかりやすく整理してみた

いけやん — Sat, 25 Oct 2025 06:09:43 +0000

本記事は、AWSのコンポーネントであるEC2、EBS、インスタンスストアについて試験向けの解説記事になります。

実際に私がAWS認定資格勉強をしていた際に、「いつまでも覚えられない」「わかりづらい」と思った箇所を初学者でもスッと入ってくるような整理をしてみました。AWS認定資格の勉強している方は試験対策としてぜひ参考にして頂ければと思います。

EC2／EBS／インスタンスストアの概要

特徴や使い分け

EC2はAWS上で仮想サーバーを提供するサービスで、アプリケーションを動かす“本体”です。そのデータを保存するために利用するのがEBS、そして一時的なデータを保存するための作業領域として使うのがインスタンスストアです。

コンポーネント	役割	特徴	主な使い分け
EC2	サーバー本体	OSやアプリケーションを動かす	サービスの中核を担う仮想マシン
EBS	外部ストレージ	停止してもデータが保持される	永続データ保存（設定ファイル、ログなど）
インスタンスストア	一時ストレージ	停止するとデータが消えるが高速	一時ファイル、キャッシュ処理など

EC2周りの構成は“距離感”でイメージするとより分かりやすくなります。
EC2がメインのサーバーで、EBSは少し離れた場所にある倉庫、インスタンスストアは机の上のメモ帳のような関係です。つながってはいるけれど役割が異なります。EC2が実行されると、ルートボリュームとしてEBSが接続され、OSや設定情報を永続的に保持します。一方、インスタンスストアはインスタンスと同じ物理ホスト上に配置され、一時的なキャッシュや高速なI/O処理に使われます。つまり、EBSは「永続的な記録用」、インスタンスストアは「一時的な作業領域」、EC2は「処理を実行する主体」という関係です。これらを正しく使い分けることで、コストと性能を最適化できます。

💡 試験ポイント：「EBS＝永続的」「インスタンスストア＝一時的」というキーワードをセットで覚えましょう。

EC2／EBS／インスタンスストアの料金発生トリガー

EC2やEBSは「どんな操作をしたときに課金が発生するのか」を理解しておくことが大切です。これは試験でもよく問われるポイントです。

対象	課金のタイミング	試験での注意点
EC2	インスタンスが「稼働中（running）」の間	停止中は課金されないが、EBS分は残る
EBS	ボリュームを保持している間	停止していてもデータを保存している限り課金される
インスタンスストア	EC2稼働時のみ	停止するとデータも削除されるので課金も終了

💡 覚え方：「EC2は動いてる間」「EBSは存在している間」。

EC2の弾力性とは？

EC2について試験では「弾力性（Elasticity）」とは何かという問いが頻出傾向にあります。
弾力性とは、必要に応じてサーバーの数や性能を増やしたり減らしたりできる柔軟性のことです。たとえば、普段はアクセスが少ないけれど、セール時やイベント期間だけアクセスが急増するようなサービスを想像してみてください。EC2では、そんなときにサーバーをすぐに追加し、アクセスが落ち着いたら減らすことができます。

この仕組みのおかげで、使わない時間に無駄なコストを払う必要がなく、必要なときに必要な分だけ使うという効率的な運用が可能になります。

また、弾力性は単に「増減できる」だけでなく、スピーディーに対応できる点も重要です。物理サーバーを購入して設置する場合は数週間〜数ヶ月かかるところを、EC2なら数分で新しいサーバーを立ち上げられます。

💡 覚え方：「弾力性＝ゴムのように伸び縮み」してリソースを調整できる性質。

EC2のサービス種類

EC2には、利用目的やコストに応じていくつかのサービス種類があります。ここでは、試験に出やすい「スペック」「料金モデル」「利用形態」に分けて整理します。

スペックの概要

EC2のインスタンスタイプの命名規則を理解しておくと、スペックの意味がぐっと分かりやすくなります。
たとえば t3.micro というインスタンス名の場合、以下のように読み解けます。

t：タイプ（T系＝低コスト・バースト可能なタイプ）
3：世代番号（数字が大きいほど新しい世代）
micro：サイズ（vCPUやメモリ容量を表す）

このように、インスタンスタイプ名は「タイプ」「世代」「サイズ」の3要素で構成されており、どんなスペックかを名前だけである程度判断できます。
EC2のインスタンスにはさまざまなタイプがあり、CPU・メモリ・ネットワーク性能のバランスが異なります。代表的なカテゴリは以下の通りです。

タイプ	特徴	主な用途
T系	低コストでバースト性能あり	開発・検証環境、軽量Webサーバー
C系	CPU重視	計算処理やバッチ処理などCPU負荷の高い処理
R系	メモリ重視	データベース、キャッシュサーバーなど
M系	バランス型	汎用的な業務アプリケーション

料金モデル

EC2の料金モデルは、使い方や目的に合わせて選ぶことができます。それぞれの特徴をざっくり整理しておくと、コスト面で失敗しにくくなります。

オンデマンド

必要な時だけ使用できる、まさに“予約不要の自由席”のようなイメージです。サーバーを起動している時間だけ料金が発生し、止めれば課金も止まります。短期的な利用や検証環境にぴったりです。

スポットインスタンス

AWSの空きリソースを格安で使えるモデル。オンデマンドよりもかなり安い（最大90％引き）ですが、AWS側の都合で一時的に利用できないこともあります。つまり「遅れても大丈夫な処理」に最適。バッチ処理や一時的なデータ解析などに使われます。

リザーブドインスタンス

1年または3年契約をする代わりに、大幅な割引を受けられるモデルです。オンデマンドよりも安く、断続的に稼働するシステムにも向いています。常時稼働する本番環境など、安定した利用が見込めるケースで効果を発揮します。

Savings Plans

こちらも1年または3年契約ですが、リザーブドインスタンスより柔軟です。期間中の利用量に上限がある代わりに、インスタンスタイプやスペックを変更しても割引が維持されます。リザーブドインスタンスは特定のインスタンスタイプやリージョンに固定されますが、Savings Plansでは柔軟に変更できる点が最大の違いです。つまり、「長期利用するけど途中で構成を変えるかも」というケースに最適です。

モデル	契約期間	柔軟性	主な特徴	向いている使い方
オンデマンド	なし	◎ 高い	予約不要・従量課金	検証環境・短期利用
スポットインスタンス	なし	○ 普通（AWS側で停止の可能性あり）	最安だが中断リスクあり	一時的なデータ解析やバッチ処理
リザーブドインスタンス	1年／3年	△ 固定的	長期契約で大幅割引	常時稼働する本番環境
Savings Plans	1年／3年	○ 中程度	長期割引＋構成変更が可能	長期運用だが構成変更の可能性あり

専有ホストとハードウェア専有インスタンスの違い

EC2を専有する必要があるのは、他の組織やユーザーと物理サーバーを共有せず、セキュリティやライセンスの制約を満たすためです。専有ホストとハードウェア専有インスタンスは、どちらも物理ホストを占有する仕組みですが、管理範囲と利用できる権限が異なります。

専有ホスト：
AWSアカウント単位で物理ホストを占有し、他組織とのサーバー共有を回避できます。物理ホストの管理権限もあり、ユーザーごとの占有やライセンス管理も利用者側で実施できます。
ハードウェア専有インスタンス：
AWSアカウント単位で物理ホストを占有し、他組織とのサーバー共有を回避できますが、物理ホスト内の管理権限はAWS側にあります。そのため、ユーザーごとの物理ホストの占有やライセンス管理はできません。

💡 覚え方：会社単位で物理サーバーを占有できればよい場合はハードウェア専有インスタンス、部署ごとに物理サーバーを占有したい場合は専有ホスト

項目	専有ホスト	ハードウェア専有インスタンス
占有範囲	AWSアカウント単位（部署単位で制御可）	AWSアカウント単位（全体で共有）
他組織との共有	不可	不可
部署間共有	可（部署ごとに専有可能）	不可（アカウント全体で共有）
管理権限	利用者が物理ホストを制御可能	AWSが制御
主な用途	ライセンス管理、部署単位の分離	組織単位での物理分離

EC2の構成とベストプラクティス（可用性を高める設計）

EC2は1台だけでも動きますが、信頼性を上げるなら複数の場所に分けて配置するのが基本です。

マルチAZ構成（高可用性）

AZ（Availability Zone／アベイラビリティゾーン）は、AWSが提供する物理的に独立したデータセンターのことです。
1つのデータセンター（AZ）が落ちても、別のAZにあるEC2が動いていればシステムは止まりません。

AZ（アベイラビリティゾーン）＝物理的に独立したデータセンター
マルチAZ構成＝別々のAZに同じサーバーを配置しておくこと

💡 イメージ：「同じ内容のサーバーを2カ所に置く」＝片方が壊れてももう片方が動く。

マルチリージョン構成（災害対策）

国や地域レベルの災害に備える設計。東京リージョンと大阪リージョンに同じ環境を用意しておくことで、地震や停電が起きても切り替えて動作可能になります。

💡 「マルチAZ＝高可用性」「マルチリージョン＝災害対策」とセットで覚えましょう。

EC2とオンプレミスの違い

オンプレミスではサーバーを買う、設置する、電源や空調を管理する…と手間が多いです。EC2ならそれを全部クラウド上で済ませられます。

比較項目	オンプレミス	EC2（クラウド）
準備期間	数週間〜数ヶ月	数分で起動できる
拡張性	台数を増やすのが大変	簡単にスケールできる
保守	自分で管理	AWSがハード部分を管理

💡 キーワード：「柔軟性（Flexibility）」＝必要なときだけ使えること。

まとめ：EC2は“柔軟に使えるクラウドサーバー”

この記事では、AWS認定試験（CLF・SAA）で頻出のEC2に関するポイントを整理しました。
EC2の仕組みを「なんとなく覚える」ではなく、「どうしてそうなっているのか」という構造で理解しておくと、試験だけでなく実務でも役立ちます。まずはキーワードを見て思い出せるレベルを目指して復習していきましょう。
このほかにもAWS認定資格試験の対策に関する記事がありますので、以下のリンクから気になる記事を覗いてみてください！

”AWS認定資格試験の対策記事一覧”

The post AWS試験対策(CLF/SAA)：EC2の特徴をわかりやすく整理してみた first appeared on 運用保守エンジニアに成る。.

ChatGPT 無料版とPlusの本質的な違いと選び方

いけやん — Sun, 07 Sep 2025 03:52:42 +0000

「ChatGPT Plusって本当に必要なの？」という疑問を持つ人は多いでしょう。
機能の比較記事は数多くありますが、実際にはどんな特徴の違いが本質なのかを理解することが大切です。
本記事では、その本質を整理し、あなたがどちらを選ぶべきかを明確にします。

ChatGPT Plusの位置づけ

ChatGPT Plusは、無料版に比べて「優先的にアクセスできる」「より多くの上位モデルを利用できる」といったアドバンテージを持つ有料プランです。
単に新しい機能が先行して使えるだけではなく、混雑時でも安定した環境を確保できる点や、高度な推論を制限なく活用できる点に強みがあります。

本質的な違いは「料金」と「制限」

ChatGPTの無料版とPlusの違いは多数ありますが、その多くは後から無料版にも開放される傾向があります。
長期的に見て、選択の決め手となるのは以下の2点です。

料金（月額20ドル／約3,000円）
制限付きアクセスの差

料金の視点

Plusは月額20ドル。
使う頻度が少ない人にとっては割高に感じるかもしれません。
ですが、毎日使う人や、仕事や学習に活用する人にとっては十分に元が取れる投資です。
例えば、毎月の業務や学習で数時間の短縮ができれば、20ドル分の価値は回収できると考えられます。

制限付きアクセスの視点

ChatGPTには利用できる回数や時間に上限があり、特に高度なモデルでは無料版とPlusで差があります。
ここでは、モデルごとの利用制限（2025年9月時点）を整理します。

モデル	無料版	Plus
GPT-5 Auto/Fast モード	10メッセージ/5時間 → 以降は旧モデル	80メッセージ/8時間 → 以降は旧モデル
GPT-5 Thinking モード	1メッセージ/日	3,000回/週

高度な推論（Thinkingモード）とは？

Thinkingモードは、通常よりも深く考えた応答を生成するモードです。難解な課題の分解、長文の整理、複雑なロジック構築などで力を発揮します。例えば、研究論文の要約や高度なアルゴリズムの説明といったケースでは、通常モードよりも明確で体系的な回答を得やすいです。

ポイント

Autoモードに関しては、旧モデルでも性能が高く、しかも頻繁に更新されるため、そこまで気にしなくても良い。
Thinkingモードは、無料版では1日1回までという厳しい制限があり、制限を気にせず使えるかどうかが最大の差となります。

無料版を選ぶべき人

無料版を選ぶべき人の特徴は以下の通りです。

ChatGPTを使う頻度が低い
アイデア出しや文章作成程度で十分
Thinkingモードをほとんど必要としない
まずは無料で試したい

Plusを選ぶべき人

Plusを選ぶべき人の特徴は以下の通りです。

ChatGPTを毎日利用する
高度な推論（Thinkingモード）を頻繁に使いたい
制限を気にせず快適に使いたい
毎月数時間以上の効率化が見込める人
成果物の品質を高めたい人（一貫性のある文章や体系的な整理を求める場合に効果大）

筆者の提案（結論）

ChatGPTの無料版とPlusの最大の違いは「高度な推論をどれだけ制限なく使えるか」にあります。
機能の細かい差分は時間とともに変わりますが、高度な推論モードの制限はずっと厳しいままです。

高度な推論を日常的に使うならPlus一択。そうでなければ無料版で十分。

FAQ（よくある質問）

Q1. 機能差は考慮しなくていいの？
A. 多くの機能は後に無料版にも開放されるため、選択理由としては弱いです。

Q2. Autoモデルを旧モデルに切り替えたら性能は落ちる？
A. 実務では十分な性能があり、大きな問題はありません。

Q3. コストはどう回収すべき？
A. 毎月数時間の時短が見込めるなら、20ドルの投資はすぐに回収できます。

The post ChatGPT 無料版とPlusの本質的な違いと選び方 first appeared on 運用保守エンジニアに成る。.

【保存版】運用保守エンジニア必修20語｜新人でも会話についていける基礎用語集

いけやん — Fri, 29 Aug 2025 08:08:50 +0000

運用の現場で用語があいまいだと、会議についていけなかったり、障害対応の通話で確認の往復が増えて復旧が遅れたりします。
報告やチケットが曖昧になれば、後続の作業が手戻りすることも。
つまり「用語を知っているかどうか」が、対応スピードや安心感に直結するのです。

この記事では、配属初日から3年目くらいまでに知らないと困る20語を厳選しました。
定義を覚えるよりも「どんな場面で使われるのか」を理解し、会話についていけるようになることを目的にしています。

必修20語

可用性（Availability）

システムがどれだけ止まらずに利用できるかを表す言葉。
「99.9%の可用性」なら、1か月に40分程度までの停止が許される計算になる。
計画停止を含むかどうかは契約やルールによるため、認識を合わせておく必要がある。

冗長化（Redundancy）

機器やサーバーを複数用意して、1台壊れてもサービスを止めない仕組み。
「片方が落ちてももう片方で動く」という考え方で、可用性を高めるために必須。
ただし設計や切替手順が甘いと結局止まるため、冗長化されている＝安心ではない。

フェイルオーバー（Failover）

稼働中の機器が故障したときに、自動または手動で待機機に切り替えること。
冗長化とセットで語られることが多く、「切替に何秒かかるか」が現場では重要。
試験をしておかないと、いざという時に切替できず障害が長引くことがある。

インシデント（Incident）

サービスに悪影響を与える、または与える可能性がある出来事。
障害でシステムが止まるケースはもちろん、レスポンスが遅い、エラーが増えている、といった兆候も含まれる。
「障害」と「インシデント」を区別して話せると、報告や議論がスムーズになる。

変更管理（Change Management）

本番に変更を加えるときに、影響やリスクを整理して承認を得る仕組み。
勝手な変更で障害を起こさないためのルールであり、運用では必ず登場する。
「誰が承認するのか」「戻す条件は何か」を明確にしていないとトラブルにつながる。

リリース（Release）

変更や新機能を本番環境に反映すること。
単なるファイルの配置だけでなく、設定や確認まで含めてリリースと呼ぶ。
「どこまで終わったらリリース完了か」を共有しておかないと、チームで認識がズレやすい。

ロールバック（Rollback）

変更後に問題が起きたとき、元の状態に戻すこと。
設定やプログラムを直前の状態に戻すケースが多い。
ロールバック手順を事前に用意していないと、障害からの復旧が大幅に遅れてしまう。

MTTR（Mean Time to Repair）

障害が発生してから復旧までにかかる平均時間を示す指標。
「うちのMTTRは30分」といえば、平均で30分以内に復旧できているという意味。
短くするには監視の速さ、初動の切り分け、復旧の標準化など総合力が必要。

アラート（Alert）

監視システムが「人が対応すべき」と判断して通知するもの。
単なる記録（イベント）とは異なり、無視できないサイン。
アラートが多すぎると現場はパンクするため、適切なしきい値設定が大事になる。

一次対応（First Response）

障害を検知したときに最初に行う基本対応。
ログ確認、再起動、切り分けなどの初動を指す。
範囲が曖昧だとたらい回しになりやすく、手順書で明確にしておくことが多い。

二次対応（Second Response）

一次対応で解決できない場合に、専門知識を持つ人が引き継ぐ対応。
アプリの不具合調査やDBの復旧など、深い作業はこちらで行う。
呼び出しが遅れると復旧も遅れるため、エスカレーションとセットで語られる。

エスカレーション（Escalation）

自分で対応できないと判断したときに、上位担当者や別のチームに引き上げること。
「誰に・どのタイミングで・どの手段で伝えるか」をルール化している現場が多い。
ここが曖昧だと、重大障害で対応が遅れる最大の要因になる。

バックアップ（Backup）

データを消えたり壊れたりしないようにコピーを保存しておくこと。
「バックアップを取ってあるから安心」というのは誤解で、実際に戻せるかどうかが重要。
運用では「いつ・どこに保存しているか」を押さえておくだけでも会話がしやすい。

スナップショット（Snapshot）

ある時点の状態をそのまま保存する仕組み。
仮想マシンやデータベースでよく使われ、変更前に「今の状態」を残すのに便利。
ただし同じ環境に置かれることが多く、バックアップの代わりにはならない。

死活監視（Health Check）

システムが生きているかどうかを定期的に確認する仕組み。
PingやHTTP応答などが代表例。
ただし応答があっても正常動作とは限らないため、重要サービスでは機能確認も行う。

キャパシティ計画（Capacity Planning）

システムの利用が将来どれくらい増えるかを予測し、余裕を持って準備すること。
「年末商戦でアクセスが倍増しても落ちないように増強する」などが典型。
不足すれば障害につながり、積みすぎればコストが無駄になるのでバランスが重要。

スループット（Throughput）

システムが一定時間に処理できる量。
「1秒あたり100件処理できる」といった性能の指標。
遅延（レイテンシ）とセットで使われることが多く、ボトルネック調査で必須。

サーバーログ（Log）

システムの動作やエラーを記録したファイル。
アプリケーションログ、OSログ、DBログなどがあり、障害調査の第一手段になる。
「とりあえずログを見よう」という言葉が現場で頻繁に出る。

ジョブ（Job／Batch）

決まった時間や条件で自動的に実行される処理。
夜間に動くデータ集計や帳票出力のバッチが代表例。
遅延や失敗が業務全体に直結するため、運用現場では非常に重要。

パッチ（Patch）

ソフトやOSにあとから適用する修正プログラム。
セキュリティ対応や不具合修正のために提供される。
適用の有無でリスクが大きく変わるため、毎月の定例作業で必ず話題になる。

まとめ

運用保守の現場で飛び交う言葉は多くありますが、まずはこの20語を押さえておけば会話の迷子にならずに済みます。
完全に使いこなせなくても、意味がわかるだけで会議や障害対応でのストレスは大きく減ります。

今後はさらに「監視」「クラウド」「セキュリティ」などの領域別に用語を追加していく予定です。

The post 【保存版】運用保守エンジニア必修20語｜新人でも会話についていける基礎用語集 first appeared on 運用保守エンジニアに成る。.

部下が辞めない組織へ！1on1マネジメントと心理的安全性の実践法

いけやん — Sat, 09 Aug 2025 09:12:57 +0000

「最近、部下の元気がない」
「相談が減った」
「突然の退職を告げられてしまった」

そんな経験がある管理職の方も多いのではないでしょうか。
部下との関係性に不安を感じていながらも、どうすれば信頼関係を築けるのかがわからない。
そんなモヤモヤを抱えている人にこそ、ぜひ読んでいただきたいのが、佐原資寛著『成長する組織を作る1on1マネジメント』です。

本記事では、1on1マネジメントの本質を解き明かすとともに、私自身が実践の中で共感したポイント、現場でのマネジメントにどう活かせるのかを交えてご紹介します。

1on1の重要性について

まず、なぜ「1on1」がこれほど重要視されるのでしょうか？
厚生労働省の「令和元年雇用動向調査」によると、退職理由の第1位は「職場の人間関係」。
上司との関係が良好であれば防げた可能性のある理由が、上位を占めています。

つまり、マネジメントの質が離職リスクに直結しているということです。

その中でも1on1は、部下との信頼関係を築き、課題を早期に発見・共有できる最も有効な手段のひとつ。
形骸化した面談ではなく、対話を通じて部下を理解し、成長を支援するための時間として活用することが求められています。

1on1マネジメントの3stepについて

本書では、1on1を効果的に行うための3つのステップが紹介されています。
以下には各ステップの概要を記載します。

Step1：徹底的に聞く

部下自身が「どうなりたいか」「何に困っているか」「どんな支援が欲しいか」を引き出すことが第一歩。アドバイスよりも傾聴が重要です。
特に経験則でのアドバイスは1対1のマネジメントにおいては適切ではないので要注意。

Step2：価値観に合った共通目標の設定

一人ひとり異なる価値観に合わせて、「納得感のある目標」をすり合わせる。会社の方針と部下の目標の接点を見つける作業です。

Step3：支援者として認識してもらう

最終的には「この上司は自分を支えてくれる存在だ」と感じてもらうこと。ここまできて初めて、関係性が信頼に変わっていきます。

最も大事なのは心理的安全性

1on1の効果を最大化するには、前提として「心理的安全性」が欠かせません。
心理的安全性とは、部下が自分の考えや感情を率直に話せる状態のこと。これがないと、表面上の会話ばかりで本音にたどり着けません。

心理的安全性が確保されると、以下のようなメリットがあります

チームに前向きな雰囲気が生まれ問題発見と対応が早くなる
部下のチャレンジ精神が高まる
「突然の退職」が起きにくくなる

逆に、心理的安全性が築かれていない職場では「無知だと思われる不安」「失敗を恐れる不安」などが支配し、意見も本音も引き出せません。

5つの意識構造タイプ別マネジメント

本書の中でも興味深かったのが、部下の価値観を5つのタイプで分類し、それぞれに合ったマネジメントを行うという考え方です。
すべての人間がどれか一つの方にピッタリ当てはまるわけではありません。
しかし、組織に属する人間としてどのような価値に重きを置いているかをとらえることはとても重要です。
その軸としてこの5つの意識構造タイプ別マネジメントは従業員満足度に大きく影響を与えると思います。

以下に、5つの意識構造タイプの概要を記載します。
タイプ別のマネジメント例については本の中で解説されていますので、ぜひそちらをご覧ください。

他者誘導型
自分を中心に考え自己の利益を追求するタイプ
組織においては権利や報酬にこだわる
組織貢献型
自分だけでなく同僚や上司との関係性を重視するタイプ
組織においては会社や社会のルールや文化、習慣などを順守する傾向にある
日本人は「組織貢献型」が特に多いと言われており、「期待に応えること」を意識する傾向があります。
組織調整型
自分、同僚、上司だけでなく組織全体との調和を重視するタイプ
利己を抑えてでも組織内で承認されたいと考える
理論運用型
自分のやり方で周りを動かして成果を上げたいタイプ
結果や利害を重視する
正義調和型
自分と同僚、上司だけけでなく社内に限らず、同じ志を持つ仲間や他社と交流しながら目的達成のため働きたいタイプ

1on1を実施する上でのテクニック

1on1を継続して実施するためには、いくつかのテクニックも有効です。
ここでは本の中で解説されていた内、私自身が実践して効果があったと感じた内容をピックアップしています。

話の比率は部下7割・上司3割が理想
→ 話すのが苦手な部下には、要約して確認したり、問いかけを増やすと良い
「はい、わかりました」に注意
→ 建前の可能性あり。「実はこういうことに困っているんじゃない？」と一歩深掘りを
1on1の頻度は固定しない
→ 定例化による”やらされ感”を避け、状況に応じて柔軟に設定
部下からフィードバックをもらう
→ 部下自身が「上司に意見を言っていいんだ」という認識が生まれる

1on1を実施する前にしておきたい上司のマインドセット

1on1を実施する際、テクニックや「やり方」を身につけるだけでは必ず失敗します。
部下も人間なので、上司の言動の背景や感情を敏感に感じ取ります。
いくらテクニックを披露しても、自身に関心がない上司には部下はついてこないのです。
そのため、上司側にもマインドセットが重要になります。

その中でも、上司は「偉い」「教える側である」こういった固定観念は崩していく必要があります。
今後求められるマネジメントは、部下が自分に合わせるのではなく、「上司が部下に合わせてマネジメントする」なのです。

少し前の主流は全く逆の考えで、それに従って成長してきた方がマインドを変えることは簡単なことではありません。
部下とともに上司も成長していくという感覚で1on1を取り組んでみてください。

まとめ

『成長する組織を作る1on1マネジメント』は、単なる面談のテクニック本ではなく、マネジメントの本質と向き合う一冊です。
部下と真摯に向き合いたい。けれどどうしていいかわからない。そんな管理職の方に、まずは「聞く姿勢」と「共感の一言」から始めてほしいと思います。
私自身、実践してみて変わったと感じるのは、部下の表情や発言が少しずつ柔らかくなっていくこと。そして、部下のモチベーションや行動が目に見えて変わることです。
上司である自分が変われば、組織は確実に変わっていきます。

The post 部下が辞めない組織へ！1on1マネジメントと心理的安全性の実践法 first appeared on 運用保守エンジニアに成る。.

新人指導に迷ったら読むべき3冊｜育成の引き出しが増える実践ガイド

いけやん — Sat, 19 Jul 2025 09:04:15 +0000

新人や若手指導をしているメンバーからよくこんな声を耳にします。

「どう伝えればいいのかわからない」

「育成が自己流で不安」

そこで今回は、後輩や新人と向き合う中で、戸惑いやモヤモヤを感じたときに手に取ってほしい本をまとめました。
本記事では、人材育成の手法を学べる書籍を厳選して紹介しています。
1冊ずつの想定読者など簡潔な要約を添えているため、時間がない方でも自分に合った書籍の情報を掴めるようにしています。
気になる本だけを深掘りできるよう、詳細記事（#1〜#3）へのリンクもご用意！
今後も書籍は随時追加していきますので、必要なときに見返せるよう、ブックマークしていただければ嬉しいです。

最終更新：2025-07-09／紹介冊数：3冊

書籍情報

今回紹介する書籍の概要について、以下の表にまとめました。
1冊ずつ本の見所や私自身が本から得た学びで有益だなと思った情報をまとめた記事のリンクも貼っていますのでぜひご覧になってください！！

書籍名	著者	キーワード	詳細記事リンク
成長する組織をつくる1on1マネジメント	佐原資寛	1on1／心理的安全性／タイプ別マネジメント	コチラから
アオアシに学ぶ「答えを教えない」教え方	仲山進也	問いで導く／観察	コチラから
OJT完全マニュアル	松尾睦	OJT6ステップ／振り返り	コチラから

5分でわかる書籍概要

成長する組織をつくる1on1マネジメント

重要テーマ
- 多対一ではなく一対一であることを意識
- 部下のタイプに合わせたマネジメント手法
- 部下の伴走者となる方法
想定読者
- チーム力を底上げしたいと考えるリーダ層
- 1on1を取り入れようと思っているが何に気を付けたらいいかわからない方
- 1on1を取り入れているが、なかなか効果を感じられない方
おすすめポイント
1on1はどのようにしたらうまくいくのかについて実際のミーティングのコツもそうですが、部下との関係構築などの下地の作り方も含め解説されています。
旧来のマネジメントと比較して解説されるパートが多いため、この本を読んでおくとよくありがちな失敗を回避できるようになる効果があると思います。

アオアシに学ぶ「答えを教えない」教え方』

重要テーマ
- 何もしないように見える「愚者風リーダシップ」
- 仕事の振り方で成長スピードが段違い「お題設計アプローチ」の5ステップ
- チーム化で学びの相乗効果を生み出す
想定読者
- 後輩の育成方法に悩んでいる方
- 教えすぎ、教えなさすぎが良くないことに気づき始めている方
おすすめポイント
この本はタイトルの通り、「アオアシ」というサッカー漫画を題材にしています。
漫画の中のエピソードをもとに指導方法が解説されていて、わかりやすいのがおすすめポイントです。
「教えすぎると部下が受け身」になる、「教えなさ過ぎると部下が成長しない・挙句の果てにやめてしまう」というよくある問題に対しクリティカルな解決方法を提供してくれます。
部下の指導について、まさにこの悩みを抱えている方にはぜひ読んでいただきたい内容になっています。

OJT完全マニュアル

重要テーマ
- OJTを実施する上での、部下との信頼関係の築き方
- OJT期間に行う目標設定の仕方
- OJT期間のPDCAサイクル
想定読者
- これからOJTで部下を育成していく立場にある方
- これからOJTを取り入れようと考えている方
おすすめポイントOJTの段取りについて初心者でもわかりやすい内容で書かれているのがおすすめポイントです。
特にOJTを実施している中で陥りやすい失敗ケースと打開策が段階ごとに盛り込まれているため私も大きくこの本に助けられました。
まずはOJTが始まる前に一通りざっと目を通し、OJTを進めていくうえでうまくいっていないポイントに対しては辞書のように扱うのがおすすめです。

まとめ

新人指導に正解はありませんが、だからこそ考え方の引き出しを持っておくことが重要です。
今回ご紹介した3冊は、それぞれ違ったアプローチで育成に向き合える実践書です。

1on1を通じて信頼関係を深めたい方
教え方のバランスに悩む方
OJTの進め方に自信が持てない方

それぞれの状況に合わせて手に取ることで、明日からの関わり方にヒントが生まれるはずです。
書籍は今後も随時追加予定です。気になるタイトルがあれば、詳細記事やガイドもぜひあわせてご覧ください。

The post 新人指導に迷ったら読むべき3冊｜育成の引き出しが増える実践ガイド first appeared on 運用保守エンジニアに成る。.