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

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

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

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

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

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

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

このカテゴリでは、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公式ドキュメント／公式ページ を一次情報として整理しています。試験対策としては本文の理解を優先し、必要に応じて公式情報に立ち戻る使い方がおすすめです。

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

• IAM（Identity and Access Management）
  https://docs.aws.amazon.com/iam/
• IAM Identity Center（旧 AWS SSO）
  https://docs.aws.amazon.com/singlesignon/
• Amazon Cognito
  https://docs.aws.amazon.com/cognito/
• AWS Resource Access Manager（RAM）
  https://docs.aws.amazon.com/ram/

鍵管理・暗号

• AWS Key Management Service（KMS）
  https://docs.aws.amazon.com/kms/
• AWS CloudHSM
  https://docs.aws.amazon.com/cloudhsm/

ログ・構成・ガバナンス

• AWS CloudTrail
  https://docs.aws.amazon.com/cloudtrail/
• AWS Config
  https://docs.aws.amazon.com/config/
• AWS Organizations（SCP）
  https://docs.aws.amazon.com/organizations/
• AWS Firewall Manager
  https://docs.aws.amazon.com/firewall-manager/

脅威検知・分析・脆弱性

• Amazon GuardDuty
  https://docs.aws.amazon.com/guardduty/
• Amazon Inspector
  https://docs.aws.amazon.com/inspector/
• Amazon Macie
  https://docs.aws.amazon.com/macie/
• Amazon Detective
  https://docs.aws.amazon.com/detective/
• AWS Security Hub
  https://docs.aws.amazon.com/securityhub/

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

• AWS WAF
  https://docs.aws.amazon.com/waf/
• AWS Shield
  https://docs.aws.amazon.com/shield/
• AWS Network Firewall
  https://docs.aws.amazon.com/network-firewall/

機密情報管理

• AWS Secrets Manager
  https://docs.aws.amazon.com/secretsmanager/

コンプライアンス・監査

• AWS Artifact
  https://docs.aws.amazon.com/artifact/
• AWS Audit Manager
  https://docs.aws.amazon.com/audit-manager/

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

練習問題

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

各問題では、まず

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

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

Time's up

まとめ

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

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

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

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

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

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

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

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

試験概要の整理

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

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時間）

② Udemyコース②

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

勉強の進め方

勉強の進め方は大きく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初心者でもわかりやすいように解説した記事もありますのでぜひそちらもご覧になってください。

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

• うまくいったこと
• 遠回りだったこと
• 今思えばやらなくてもよかったこと

そういったものを整理し、これからの行動を選ぶための判断材料として残すことが目的です。
2026年に向けて、本記事の記事の中から、 『これなら自分にもできそう』 『これは同じ失敗をしなくてよさそう』 そんな気づきが1つでもあれば幸いです。

2025年 やってよかったこと

自己投資編

AWSクラウドプラクティショナーの資格勉強

2025年にやってよかった自己投資の1つが、AWSクラウドプラクティショナー（CLF）の資格勉強です。
正直に言うと、当初は「今さら入門資格では？」という気持ちもありました。運用保守エンジニアとして数年働いてきて、クラウドという言葉自体は当たり前のように触れていたし、自身が担当するシステムはオンプレミスのシステムだったためです。
AWSの資格勉強をしておいてよかったと感じている一番の理由は、クラウド人材の需要が高まっていく中で、今のうちから基礎知識を蓄えられたことです。
ニュースや業界動向として「クラウド人材が不足している」「クラウド経験者が重宝される」といった話は以前から耳にしていましたが、資格勉強を通じて、

• クラウド環境で最低限押さえるべき用語や考え方
• オンプレミスとクラウドの役割分担の違い
• 運用・コスト・責任範囲の基本構造

といった知識を一通りインプットできたことで、『この分野について、まったく分からない状態ではなくなった』という安心感を得られました。
今すぐクラウド案件に関わるわけではなくても、将来的に求められる可能性が高い分野に対して、最低限の備えができたという点で、この資格勉強は意味のある自己投資だったと感じています。
さらに、AWSの学習を通じて、システム全体像を意識する視点が身についたことも大きな収穫でした。
ネットワーク、サーバ、ストレージ、セキュリティ、可用性、コストといった要素が、クラウド上ではどのように役割分担され、どこまでが利用者の責任なのか。この整理ができたことで、『自分が今、システムのどのレイヤーを担当しているのか』を俯瞰して考えられるようになりました。
これはオンプレミス中心の運用保守エンジニアにとっても大きな意味があり、目の前の作業だけでなく、システム全体を意識した判断がしやすくなったと感じています。

Difyの活用研究

2025年は、Difyを使った生成AI活用の研究にも時間を使いました。
きっかけは、『ChatGPTは便利だけど、そのままでは業務に使いにくい』という違和感でした。単発の質問には強い一方で、

• 社内ドキュメント
• 過去の設計書
• 手順書

といった自分たちの文脈を理解させるには工夫が必要です。
Difyを触ってみて強く感じたのは、AI活用の本質はモデルよりもデータと設計だということでした。

RAG（社内ドキュメントを検索して回答させる仕組み）を試作する中で、

• 文書が整理されていないとAIも役に立たない
• プロンプト設計で回答の質が大きく変わる

といった、ある意味当たり前だけど重要な現実を体感できました。
これは運用保守の仕事とも相性が良く、『手順書が整っていない現場は、人が変わっても苦労する』という経験則と重なります。
これから触る人は、いきなり大規模な仕組みを作ろうとせず、

• FAQ検索
• 手順書の要約

など小さなユースケースから始めるのがおすすめです。8割はデータ整備です。

Copilotの活用研究

Copilotについては、一般的にイメージされがちな「ちょっと便利な文章生成ツール」というより、会社が推奨する“業務標準のAIアシスタント”として触れておいてよかったと感じています。
というのも、私の会社では有償版のCopilotアカウントが提供されており、利用が推奨されています。ここが大きなポイントで、無料版や単体ツールとして触るCopilotとは、使い勝手も「できること」も少し別物でした。
特にメリットが大きいのは、Office（Microsoft 365）と連動して、社内ドキュメントを横断的に検索・要約できることです。
運用保守の仕事って、結局のところ

• 過去のメールや議事録
• 設計書や手順書
• Teamsのやり取り
• 申請書・問い合わせ履歴

こういった「散らばった情報」を探して、つなぎ合わせて判断する場面が多いです。

この“探す作業”が重い。そして、探している間に『何を探していたか分からなくなる』こともある。有償版のCopilotは、ここにかなり効きました。

• 「この変更の背景ってどこに書いてあったっけ？」を探す
• 過去のやり取りを要約して、判断材料を短時間で作る
• 関係者向けの説明文や報告文を整える

といった、情報探索〜整理〜文章化の流れを一気に短縮できる感覚があります。
そしてもう1つ大きいのが、（会社のルールの範囲内で）社外秘情報もインプットにRAG的な使い方ができる点です。
もちろん、「何でも入れてOK」という話ではありません。社内規定や情報管理ルールは前提として守る必要があります。
ただ、会社が有償アカウントを配布し、推奨しているということは、『一定のガバナンス（利用ルール・管理の枠組み）の上で、業務に使う前提がある』ということでもあります。
だからこそ、個人でAIツールを試すのとは別に、“職場で使えるAI”を早めに触っておく価値がありました。

具体的には、

• どんな質問が得意で、どんな質問が苦手か
• どう指示すると狙った情報に当たるか
• 回答の根拠（参照先）をどう確認すべきか

といった「使いこなしの勘所」を、日々の業務の中で掴めます。

よくある失敗は、『AIが出した答えをそのまま採用して、後でズレに気づく』ことです。
Copilotに限らず、生成AIは便利ですが、運用保守の現場では正確性が最優先になります。
だから私が意識していたのは、次の3点です。

• 出力は必ず一次情報（元のドキュメント）に当たって確認する
• 指示は具体的に（対象範囲・目的・期限・前提を明記する）
• 入力していい情報／ダメな情報は社内ルールに従う

結局、Copilotの価値は「全部やってくれる」ことではなく、人が判断する前の“材料集め”と“整理”を高速化できることにあると感じています。
2025年にCopilotを触っておいてよかったのは、今後この手のツールが“特別なもの”ではなく、Excelやメールと同じくらい当たり前の仕事道具になっていく中で、早めに「使い方の基礎体力」を作れたことです。

ChatGPTの活用研究

ChatGPTは、2025年に最も使ったツールの1つです。
仕事、学習、ブログ作成など、使い道は多岐にわたりましたが、一番の価値は思考の壁打ち相手になってくれたことだと思います。

『この考え方で合っているだろうか？』
『別の視点はないだろうか？』

こうした問いを投げることで、思考が整理され、アウトプットまでのスピードが明らかに上がりました。
一方で、鵜呑みにしない姿勢も重要です。ChatGPTはあくまで補助であり、最終判断は人間が行う必要があります。

具体的に使うなら、

• 前提条件を明確にする
• 目的をはっきり書く

この2点を意識するだけで、出力の質は大きく変わります。

娯楽や生活

読書（小説）

2025年は、あえて小説を読む時間を増やしました。
自己投資や勉強が続くと、どうしても頭が疲れてきます。そんな中で小説は、

• 強制的に仕事から意識を切り離せる
• 脳のリフレッシュになる

という点で非常に効果的でした。

また、文章に触れることで、言語化能力や表現力のトレーニングにもなります。
ポイントは、『学びにしようとしないこと』です。純粋に楽しむ読書だからこそ、結果的に仕事にも良い影響がありました。

収支の見える化と分析

2025年に取り組んでよかったことの1つが、収支の見える化と分析を一段深くやったことです。
前提として、家計簿アプリのZaimには以前から登録しており、利用している金融機関の口座連携も一通り済ませていました。ただし、その使い方はかなりライトで、

• ざっくり予算を設定する
• 日々の支出を何となく眺める

といったレベルに留まっていました。数字は見えているものの、「それをどう判断し、どう行動に反映するか」までは落とし込めていなかったと思います。
2025年は、ここを一度きちんと整理し直しました。具体的には、過去数年間の支出を遡って確認し、支出項目の具体化と予算金額の見直しを行いました。これまで感覚的に設定していた予算を、実際の支出実績をもとに修正した形です。
あわせて、自身の将来像をかなりざっくりではありますが描き、投資計画にも挑戦しました。まだ粗い計画ではあるものの、『今の収支バランスで、将来に向けた選択肢はどれくらいあるのか』を考えるきっかけにはなりました。

そのうえで、月単位で

• 予算に対してどれくらい使ったのか
• 想定とズレている項目はどこか

を確認するようにしました。毎日細かくチェックするのではなく、月次で振り返るくらいの距離感が、自分にはちょうどよかったです。
この取り組みをしてよかったと感じた点は大きく2つあります。
1つ目は、普段の買い物に自然と気を遣うようになったことです。無理に我慢するのではなく、「これは予算内か」「本当に今必要か」を一度考える癖がつきました。
2つ目は、現在や将来に対する漠然とした不安が薄れたことです。完璧な計画が立ったわけではありませんが、数字を把握し、自分なりに整理したことで、『よく分からないから不安』という状態からは一歩抜け出せたと感じています。
結果として、収支の見える化と分析は、節約そのものよりも、安心して日々の判断をするための土台作りとして意味があった取り組みでした。

摂取カロリーのコントロール

30歳が近づいてきたことをきっかけに、これまでよりも脂肪がつきやすくなってきたと感じ、摂取カロリーを意識するようになりました。
最初から厳密に管理しようとするとストレスになりそうだったため、「しんどくなったら気にしすぎるのはやめよう」という前提で、あくまで目安として取り組み始めました。
一般的に、成人男性の1日の摂取カロリーの目安は2,000〜2,700kcal程度とされていますが、実際に意識してみると、この範囲内でも意外と食事を楽しめることに気づきました。

カロリーを意識するようになると、自然と

• 主食・主菜・副菜のバランス
• 間食や飲み物の選び方

にも目が向くようになり、結果として普段の食事内容そのものを見直すきっかけになりました。
厳しい食事制限をしたわけではありませんが、「何となく食べる」状態から一歩抜け出せたことで、体調面・健康面ともにプラスの変化を感じています。
摂取カロリーのコントロールは、我慢のための取り組みではなく、長く健康に過ごすための土台作りとして、やってよかったと感じている習慣です。

2025年 やめてよかったこと

自己投資編

生成AIの環境構築の勉強

2025年にやめてよかったと感じたのが、生成AIのローカル環境構築を深追いすることです。
※ここでいう「ローカル環境構築」とは、ChatGPTやCopilotのような既成のサービスを使うのではなく、自分のPCやサーバー上に生成AIの実行環境を用意し、モデルを動かすところから整える学習を指しています。

当時は、生成AIそのものへの関心が高まり、「エンジニアとしてこの分野を理解しておくべきではないか」と考えていました。ローカルでLLMを動かす方法や、GPU・推論環境の仕組み、関連するフレームワークやツールについて調べること自体は、純粋に技術的な面白さがありました。
しかし、時間をかけて取り組む中で、次第に違和感を覚えるようになりました。生成AIの環境構築は、機械学習の基礎知識やモデル構造、ハードウェアの知識など、前提となる学習範囲が非常に広く、理解を深めようとすればするほど、別の分野の知識が必要になります。また、この分野は技術の進化が早く、数か月前の情報がすぐに古くなってしまうことも珍しくありません。

それ以上に大きかったのは、学習にかけた時間に対して、実務で得られるリターンが見えにくかったことです。環境を構築できたとしても、『それによって自分の業務の何が楽になるのか』『どの作業が効率化されるのか』を明確に説明できませんでした。
振り返ると、いつの間にか「業務を改善するため」ではなく、「環境を構築すること自体」が目的になっていたように思います。技術的な達成感はあっても、運用保守エンジニアとして重視すべき、安定運用への貢献や属人化の解消、判断や手順を楽にする、といった点には結びついていませんでした。
この経験から強く感じたのは、流行している技術であっても、今の自分にとって最優先で学ぶべきとは限らないということです。

今であれば、まずはChatGPTやCopilotのようなSaaS、Difyのようなマネージドな基盤を使い、実際の業務課題が解決できるかどうかを先に確かめます。そのうえで、『内部構造を理解しないと要件を満たせない』『自分で制御する必要が出てきた』と感じた段階で、初めてローカル環境構築や低レイヤーの勉強に進む方が、結果的に効率が良いと考えています。

自己啓発本の読み漁り

自己啓発本を大量に読むことも、やめてよかったことの1つです。
読んでいると前向きな気持ちになりますし、一時的にはモチベーションも上がります。ただ、その一方で、『分かった気』だけが増え、行動が伴わない状態に陥りやすいと感じました。
特に象徴的だったのが、日々つけていた日記を振り返ったときの気づきです。自己啓発本で読んだ内容を「これは大事だ」「実践したい」と思っているにもかかわらず、実際の行動としてはほとんど実行できていない、という振り返りが何度も出てきました。
頭では理解しているつもりでも、行動が変わっていない。その結果、『知識ばかり増えて、頭でっかちになっているのではないか』と感じる場面が増えていきました。
また、インプットした内容が増えすぎたことで、『結局、自分は何を行動指針にすればいいのか』が分からなくなりかけていたのも、今振り返ると大きなサインだったと思います。

それに加えて、2025年は、生成AIの活用研究や自動化施策など、より直接的に業務の成果や利益につながるコンテンツが急激に増えた年でもありました。限られた時間の中で、それらに対応していくためには、相応の学習コストと試行錯誤の時間が必要になります。
その結果、『今の自分にとって、本当に優先すべきインプットは何か』を考えるようになり、自己啓発本を次々と読むことの優先度は自然と下がっていきました。
今後の方針としては、少なくとも1年間は新たに自己啓発本を購読せず、自身のコアタスクに集中するつもりです。そして、2027年以降に、これまで読んできた自己啓発本を改めて読み直し、『今の自分なら、どの考え方を行動に落とせるか』という視点で再評価したいと考えています。

娯楽や生活

YouTube Premium

YouTube Premiumも解約しました。結論から言うと、費用対効果が合わなかったためです。
YouTube Premiumの体験自体はとても優れていると感じていました。広告なし視聴やバックグラウンド再生、音楽アプリのように使える点など、ユーザー体験としては非常に完成度が高く、使っていて不満はほとんどありませんでした。

ただ、自分の生活スタイルを冷静に振り返ってみると、

• 音楽はすでにApple Musicを利用している
• 1日に占めるYouTubeの動画視聴時間は平均すると約1時間程度

という状況で、月々およそ1,300円を支払い続けるほど使い込んでいるかというと、正直そこまでではありませんでした。
「便利なのは間違いないが、自分にとって必須か？」と考えたとき、現時点では優先度が低いと判断し、解約することにしました。
とはいえ、広告なし視聴やバックグラウンド再生を手放すのは、かなり惜しいと感じたのも事実です。そのため、今後もし家族やパートナーなど、共有できる人ができたタイミングで、再度サブスクライブを検討する余地はあると思っています。
YouTube Premiumは「不要なサービス」だったわけではなく、今の自分の使い方にはコストが見合わなかった、というのが正直な結論です。

整体通い

整体通いについては、今まで利用していた店舗に通い続けることをやめました。
これまで通っていたのは、カラダファクトリーです。施術のクオリティは高く、信頼できる施術者の方にも担当していただいていたため、サービス自体には大きな不満はありませんでした。
ただ、継続を見直すきっかけになったのが料金の値上げです。40分の施術で約7,000円まで上がってしまい、自分の生活費や他の自己投資とのバランスを考えたとき、正直なところ負担が大きくなってきました。
そのタイミングで、カラダファクトリーと比べると施術のクオリティは多少落ちるものの、1時間4,000円程度でマッサージを受けられる別のお店を見つけました。絶対的な満足度は下がるかもしれませんが、価格と内容のバランスを考えると、こちらの方が自分には合っていると判断しました。
信頼できる施術者の方がいたこともあり、通うのをやめる決断は簡単ではありませんでしたが、最終的には自分の財布事情と向き合った結果の判断です。

整体通いを完全にやめたわけではなく、「どこに、どれくらいお金をかけるか」を見直した、というのが実際のところです。

まとめ

2025年を振り返って感じたのは、
「何をやるか」以上に「何を選ばないか」が重要だということです。

すべての行動が正解である必要はありません。

この記事が、来年の自分に残したい行動を考えるきっかけになれば幸いです。

The post 【2025年振り返り】やってよかったこと・やめてよかったこと｜現役エンジニア first appeared on 運用保守エンジニアに成る。.

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

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

AWSコスト管理の全体像

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

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

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

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

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カテゴリに対応します。

主な機能・特徴

• 未使用のリソースやアイドル状態のリソースを検出
• 一部のチェックは無料、全機能利用には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アカウントを統合管理できるサービスで、請求の一括化（コンソリデーティッドビリング）やポリシーの統制に活用されます。

主な機能・特徴

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

他ツールとの違い

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

試験での出題傾向

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

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

概要

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

主な機能・特徴

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

他ツールとの違い

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

試験での出題傾向

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

Billing Conductor

概要

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

主な機能・特徴

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

他ツールとの違い

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

試験での出題傾向

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

シナリオ別まとめ

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

参考リンク

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

• AWS Pricing Calculator
• AWS Cost Explorer
• AWS Budgets
• コスト異常検知
• 請求アラート
• AWS Trusted Advisor
• AWS Compute Optimizer
• AWS コスト最適化 Hub
• コストと使用状況レポート
• コスト配分タグ
• Cost Categories
• AWS Organizations
• 請求ダッシュボード(Billing & Cost Management コンソール)
• Billing Conductor

練習問題

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

Time's up

まとめ

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

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

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

AWS CAFの概要

AWS CAFとは？

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

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

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

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

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

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

1. 6つのパースペクティブごとに質問（設問）が用意されている
2. 現状がどの程度できているか（成熟度）をスコアとして回答する
3. スコアが低い領域＝移行に向けてリスクがある領域として可視化
4. 不足している能力（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認定試験と同じ形式で問題を解いてみましょう。
試験で狙われやすいポイントを重視して問題設定をしています。

Time's up

まとめ

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

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

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

出題の傾向

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

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

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

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

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

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認定資格試験の対策に関する記事がありますので、以下のリンクから気になる記事を覗いてみてください！

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

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

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

特徴や使い分け

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

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

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

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

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

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

EC2の弾力性とは？

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

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

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

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

EC2のサービス種類

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

スペックの概要

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

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

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

料金モデル

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

オンデマンド

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

スポットインスタンス

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

リザーブドインスタンス

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

Savings Plans

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EC2とオンプレミスの違い

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

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

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

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

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

若手時代に年収500万円を突破した錯覚

私は大卒でITシステムの運用保守を生業とする会社に所属しており、転職は未経験の身です。給与水準は平均ですが、若手ながら少しばかり忙しくさせてもらっており、社会人5年目あたりで年収500万円を突破していました。若手でこの水準を稼げている人はそう多くなく、私は同世代より若干稼いでいるという優越感を持っていました。
「このままいけば平均より上の年収で推移するだろう」と錯覚し、将来に対して根拠のない安心感を抱いていたのです。

もちろん、上には上がいて、その人たちに憧れて年収アップを視野に転職を考えた時期もありました。しかし最終的には現状維持を選び、満足してしまったのです。

転換点は部署異動

その後の転換点は、部署異動でした。異動先では残業がほとんどゼロになり、年収はガクッと落ちました。
忙しかった以前の部署とは違い、残業するほどの仕事がなく、しかもコスト管理が厳しい部署。残業を増やすことは簡単ではありませんでした。

始めは残業が減って自身の自由な時間が増えることに喜びを感じましたが、異動後初めての給料日を迎えたときそれは不安に変化していきました。
こうして気づいたときには、周りと比べて自分の年収が低くなっていたのです。

錯覚に気づいた後に感じたこと①

残業代が大幅に減少したときから、いつになく年収というものに敏感になりました。周りの友人や同僚が年収アップを狙って転職した話や独立して稼いでいる友人の話を聞いたりすると、少し妬みのような感情が生まれてくるのです。そして過去、なんで転職をしようと思わなかったのかという後悔やこれからどうしようという不安に襲われることもありました。
さらに時代は自動化が進み、これまで人間が担ってきた作業はどんどん減るとされています。残業代をあてにする働き方は、今後ますますリスクが高まると考えるようになりました。
「残業が常にある」という錯覚に陥り、残業代ありきで年収を換算するのは危険だと痛感したのです。
しかし大切なのは周囲との比較ではなく、自分自身の現状を正しくとらえることでした。

錯覚に気づいた後に感じたこと②

そんなこんなでいろいろ悩んだ末、自分自身に疑問に思う事がありました。
『自分はいったいいくら年収をもらえれば満足するんだ？』
今までは周りの人と比べて高かったらいい、とか、世間一般の平均年収より上回っていれば安心。とかそのくらいの基準でしか自身の満足度を計ったことがなかったのです。

極論比較相手が、スポーツ選手や芸能人、大物Youtuberやどこかの社長と比べていたら比較による満足なんてないのです。きれいごとでも何でもなく年収は他人との比較で満足を得るのではなく、自身がどのくらい将来お金を必要としているのか。それに対して現状、十分満たせる見込みがあるのかという確実性を得ることでないと自身の欲求は満たされないのだと気づきました。

大切なのは周囲との比較ではなく、自分自身の現状を正しくとらえることでした。

若い世代に伝えたいこと（20代へ）

入社1～3年目くらいの自分にアドバイスをするなら5つあげます。

• 年収は人と比較してもいいが、自身が満足する理由にするな
• 周囲の人の年収を聞き出せ
• 残業代込みの年収のモノサシは捨てよ
• 給与体系を理解し、3シナリオで年収予測を立てよ
• 職場では転職を視野に入れた人間関係を構築せよ

それぞれもう少し分解して書いています。

年収は人と比較してもいいが、自身が満足する理由にするな

これは私の過去の体験として上述していますが、他人や世間一般の年収と比較して、優劣で自身の将来を決めてはいけないという事です。
他人と比較して年収が高かった場合、短期的な優越感に自信が満たされることはあるかもしれませんが、自身が理想とする生活に対して及ばない可能性は大いにあります。逆に周りの人に比べて年収が低かった場合にでも、実は自身が理想とする生活を送る水準に達しており、そこで感じる不安は取り越し苦労だった。なんてこともあると思います。

周囲の人の年収を聞き出せ

他人と比較して満足するな！と言っておきながらこんなことを書いていますが、他業界や他職種の給料を聞くことは自身の将来の選択(転職)をするうえでよい材料になるので集めておくと良いでしょう。
また同じ会社の人にも年が近い先輩や上司、役員(これは難しいかもですが)の年収を聞いておくと、現状自身が置かれている立場から将来設計をした場合の基準になるので、できるなら集めておいた方がいいと思います。

残業代込みの年収のモノサシは捨てよ

これも上述していますが、今当たり前のように発生している残業はいつなくなるかわかりません。
ネットで転がっている年収情報も他人から聞く年収もそれと比較する自身の年収も残業代は差し引いた額で比較をするべき。
友人の年収を聞くときは、聞きづらいかもしれないが、固定残業代制がとられているならそれを差し引いた額、基本給を聞いてみましょう。

給与体系を理解し、3シナリオで年収予測を立てよ

これは少し手間なのですが、時間をかけてでもやることをおススメします。
自身の会社の給与体系を理解し、昇給、昇進のタイミング、各レイヤーに応じた基本給のレンジを確認して、順調に昇給、昇格した場合のハッピープラン、無難に昇給、昇格したばあいのノーマルプラン、うまくいかなく思った通りの昇給、昇進ができなかった場合のバッドプランの3つを立てて、各収入で自身が思い描く生活ができるのかをチェックするのです。
その前提として自身がどのくらいお金が必要なのかの計算をしなければいけないのがさらに手間なのですが、これはぜひ時間をかけてやってみてください。

職場では転職を視野に入れた人間関係を構築せよ

これは過剰なほど義理人情を持っているひと(私もこの類と自負)のみ該当しますが、要するに自分が転職しづらい空気を作らないようにした方がいいという事です。
同僚や上司と仲良くするなと言っているわけではありませんが、いつしか転職というカードを切りたくなった時に、精神的にブロックをかけないように工夫をする必要があると思います。
私は失敗している側の人間なので反面教師的なアドバイスしかできないのですが、あまり頑張るアピールをするなというのが簡単なまとめです。昇給、昇格をするうえでバイタリティが評価されることは今時ないと思うのでここは割り切っていった方が自分のためになると思います。
これは声に出す出さないに限らず、自身が頑張ろうとする理由に「会社のため」だとか「今までお世話になった上司のため」という発想は捨てた方がいいという事です。素晴らしいことですが、後々身を滅ぼしかねない考えなのでほどほどにしておきましょう。

アラサー(私)の選択

残業が減り年収がガクッと下がったタイミングで、単純に転職して年収を上げるのか、これまで築いた信頼や実績を土台に昇進を狙っていくのか──その間で悩んでいましたが。
上述でいろいろ偉そうなことを言っていても、結局私は今、現職で頑張ることを選択しています。
勤続年数を重ねてきたからこそ判断は慎重になっていることもその要素の一つですが、理由は年収以外に、職場環境や居心地の良さ、やりがいのある仕事、尊敬できる上司など多くのプラス要素があるからという理由もあります。
それでも、もし今後の年収予測が納得できないものなら、転職か副業を選択肢に入れる必要があると考えています。株や不動産のような大きな投資に挑むのは、年収450万円前後のアラサーにとって相当な覚悟が必要で、私はそのリスクは取らないと決めています。

転職をしないという選択を取っていますが、年収を諦めたわけではありません。その中でも「超順調に昇格するハッピープラン」をベースに目標を立て、もし達成が難しいと感じれば転職で短期的に年収を上げる方法を取るつもりです。さらにリスク低減のために副業も始めようとしています。

結局何が正解かは、自分が何を求めているかによります。
私が伝えたいのは、年収という基準は自分の望む生活水準に達するかどうかで判断すべきだということ。そしてそのとき、残業代を含めて換算しないことです。

私は失敗から気づくのが遅れました。だからこそ、この記事が若い世代や同世代の方にとって、現状を見極めるきっかけになればと思います。

本ブログでは運用保守エンジニアについての情報発信を行っています。
運用保守エンジニアの給料事情についての記事もありますので、ぜひご覧になってみてください。

2024.11.03

運用保守エンジニアの給料はいくら？：経験者が語るリアルな収入推移

運用保守エンジニアの仕事に興味があっても 「実際の給料はどうなんだろう？」 「安定しているけど、収入面で不安はないのか？」 と悩む方は...

The post 残業代込みの年収は錯覚だった｜30代目前で気づいた“お金とキャリア”の現実 first appeared on 運用保守エンジニアに成る。.

とはいえ、現場では同じミスが繰り返されます。原因は一つではありません。体制や権限設計、手順や仕組み、情報の見える化、人のスキルや負荷など、たいていは複合要因です。そのうえで、日々の意思決定を大きく左右するのが「考え方（判断の基準と順序）」です。本記事では、この“考え方”に焦点を当て、なぜ必要かを整理し、読んだ直後から現場で使える思考の土台を共有します。

システムを守るという視点

「守る」とは、かっこいい復旧テクニックを披露することではありません。被害を最小にしながら、最も早く安定を取り戻すために、冷静に順番を決めて動くことです。

なぜ必要か

システムは人やビジネスが毎分使う社会インフラです。判断を誤れば被害は広がります。だからこそ、順番と根拠を整えて動くことが、安定へ最短で到達するために不可欠です。

考え方

1）安定稼働を最優先にする。
誰のせいかは後でいい。まずは“止血”です。影響範囲を素早く見極め、広がりを抑える暫定策（回避導線や手動処理、対象機能の一時停止など）を先に打つ。

2）事実と推測を分ける。
「たぶん」「おそらく」は行動の根拠になりません。ログの時刻、アラートの数値、実際に発生している症状──観測できる事実だけを最初に並べる。推測は“仮説メモ”として別枠に置く。

3）時系列と事象を関連付ける。
発生→検知→報告→対応→復旧を縦の軸に、各時点で「何が起き、直前に何をしたか」を横の軸で紐づける。10:02のアラートと10:00のリリース、9:58のエラー出力が並ぶと、検証すべき順番が自然に見えてきます。

4）被害を最小化する。
全復旧までの“つなぎ”を軽視しない。「A機能は止まっているが、B経由で代替できる」「バッチは遅延するが、日中の処理は確保できる」──この“橋渡し”の提案が、ユーザーの不安も損失も下げます。

5）透明に伝える。
状況を飾らない。「今どこにいて、何をして、次の報告は何分後か」。専門用語を外し、短く正確に。誤魔化しは信頼を削り、判断を遅らせます。守る対象はシステムだけではなく、その先にいる人とビジネスです。

6）応急で終わらせない。
復旧直後は疲れていても、なぜ起きたか、再発をどう防ぐかを必ず言語化する。短期（応急）、中期（恒久策）、長期（設計の見直し）を分けて打ち、約束した期日を守る。ここまでやって初めて「守った」と言えます。

仕組みで解決する発想

人は疲れます。夜勤明けは判断が鈍り、忙しい日は注意が雑になります。だからこそ、注意力に頼らない。 人間の弱さを前提に、同じ品質を再現できる道具立てを作る。それが“仕組みで解決する”という考え方です。

なぜ必要か

人の注意力には波があります。仕組みによって品質を固定化し、忙しい日や夜勤明けでも同じ結果を出すために必要です。

考え方

1）属人化をやめる。
「あの人しかできない」は称賛ではなくリスク。手順は他の人が読んでも迷わず実行できるか、作業後の状態が同じ結果になるか。名前の付け方、画面のスクリーンショット、確認観点の書き方まで含めて“誰でも”の設計にする。

2）注意力を設計に埋め込む。
手で打つ作業は、極力スクリプト化・バッチ化する。実行前に“乾式テスト（dry-run）”のモードを用意し、対象件数や影響範囲を画面に出す。危険な引数には二重確認を入れる。これらは賢さではなく、臆病さの設計です。臆病であれ。そのほうが現場は強くなります。

3）標準化でスピードと品質を両立する。
フォルダ構成、手順書フォーマット、命名規則、ログの保存場所──細部を揃えると、初見の人でも迷いません。迷いが減れば、スピードも品質も上がる。標準は“自由を奪う鎖”ではなく、“判断の回数を減らすレール”です。

4）仕組みは育てる。
一度作って終わりではありません。実際に使い、引っかかった箇所に印をつけ、次回直す。冗長な手順は削り、曖昧な表現は具体に置き換える。仕組みは“完成品”ではなく“育成中のプロダクト”。更新を躊躇しないことが、事故の芽を摘み続ける力になります。

改善と学習を続ける姿勢

同じ種類の障害が続くとき、現場は復旧に全力でも、対応内容が前回と同じなら原因特定と対策設計が後回しになっているサインです。復旧はゴールではなく次の改善への起点――「なぜ起きたか／次はどう防ぐか」まで含めて一連の仕事と捉える視点が必要です。

なぜ必要か

同じ問題を繰り返さないことで、残業や機会損失を減らし、現場への信頼を積み上げるためです。

考え方

1）繰り返しを合図にする。
同じ現象が2度起きたら、赤信号。3度目は許容しない。暫定対応の直後に15分だけでも振り返りの枠を確保し、「次に同じことが起きたら、どこを触らず、どこを先に見るか」を決める。

2）小さくていいから動かす。
改善は大工事でなくていい。アラートメールの件名を見直す、手順書に一行だけ補足を入れる、ダッシュボードに“いつも見る数値”を1つ足す。1ミリの改善は積み重なると道になります。

3）学びを業務に結びつける。
新しく知ったことは、翌日の仕事で1回使ってみる。たとえばログの検索の仕方を学んだら、実際の障害記録をその手法で振り返る。学びが“知っている”から“使える”に変わる瞬間です。

4）変化を恐れない。
安定は「変えないこと」では生まれません。むしろ、より良い方法に置き換えていくから安定が続く。現状維持は一見安全に見えて、実は“劣化の始まり”。勇気を持って、より良いほうへ一歩動く。失敗したら戻せばいい。戻せる設計にしておけば、挑戦は怖くありません。

チームで動く意識

運用保守は交代制、複数人、複数部門が前提です。
個人のヒーローより、チーム全体のふつうの強さがシステムを守ります。

なぜ必要か

運用は交代制・多人数前提です。個人の限界をチームの仕組みで乗り越え、24時間の連続性を保つために不可欠です。

考え方

1）情報を残す。
口頭は消えます。書き残した情報は残ります。「何が起き、何をして、今はどうか、次はいつ見るか」。この4点を短く、でも具体的に。未来の自分や同僚が、記録を見れば5分で現状に追いつける状態を目指す。

2）引き継ぎは“そのまま動ける”レベルで。
「念のため見てください」では弱い。「10時にこのグラフを確認、閾値を越えたらジョブを止め、B担当に連絡」のように、行動指示まで書く。相手の想像力に頼らず、行動に直結する言葉で渡す。

3）属人化をほどく。
手順やスクリプトを共有し、担当外のメンバーでも回せる状態を作る。結果として、“その人が休めない”状況を減らし、組織全体の耐久性が上がる。人を守ることは、システムを守ることでもあります。

4）学びはチームに戻す。
自分だけが知っている小さなコツほど、ドキュメントや朝会で共有する。知っている人と知らない人の差を放置しないこと。差は、トラブルの温床です。

5）チームの成果を優先する。
個人がどれだけ頑張っても、全体が止まれば意味がありません。だから、情報を独り占めしない。助けを求める。助けに行く。互いの見落としを補い合う。その文化が、最終的に顧客の信頼になります。

ステークホルダと関わる姿勢

運用保守は“裏方”でありながら、実はたくさんの人と信頼をやり取りする仕事です。相手の立場によって、聞きたいことも、必要な言葉も変わります。

なぜ必要か

相手が正しく状況を理解し行動できるようにすることが、被害の最小化と意思決定の迅速化につながるためです。

考え方

1）相手の関心に合わせる。
利用部門は「いつ何ができて、何ができないか」。経営は「損失と復旧見込み」。開発は「再現条件とログ」。相手別に軸を切り替える。

2）事実と見込みを分ける。
「今、A機能は使えません（事実）。Bで代替可能です（回避策）。13時に再度報告します（次の約束）。復旧見込みは14時±30分です（見込み）」。これで相手は次の行動が取れます。

3）短く、正確に。
10分の長説明より、1分の正確な要点。専門用語はできるだけ削り、どうしても必要なら一言で置き換える（例：「データの渋滞です」）。伝わらない説明は、していないのと同じです。

まとめ

運用保守エンジニアは「作業する人」ではありません。システムを守り、仕組みで再現性をつくり、改善を積み重ね、チームで成果を出し、関係者に正しく伝える人です。ここに挙げた考え方は、難しいテクニックではなく、誰でも今日から実践できます。

派手さはありません。けれど、こうした小さな積み重ねが、あなたの現場を確実に強くします。あなたの手で、今日の“当たり前”を守っていきましょう。

The post 現場で差がつく運用保守の考え方：安定運用を支える実務視点 first appeared on 運用保守エンジニアに成る。.

私自身も、今回の異動は希望ではなく部門の判断によるものでした。
これまでのベンダースキルや仕事への取り組み方を評価され、新たなプロジェクトに呼ばれることになったのです。
異動が決まった瞬間、心に浮かんだのはワクワクと不安が半々という複雑な感情でした。

新しいシステムに携われることへの期待。
評価に応えられるのかというプレッシャー。
さらに、上司からは「これからリーダーとして活躍してほしかった」と惜しまれ、後輩からは「自分たちのチームが不安」と言われました。
誇らしさと責任感を同時に感じながら、私は新しい環境に足を踏み入れることになったのです。

異動前に抱えていた期待と不安

異動が決まった直後、一人で静かに考えを巡らせたとき、まず浮かんだのは「新しい技術を学べる」という純粋な喜びでした。
知的好奇心が刺激され、これまで触れたことのない分野に挑戦できることは大きなモチベーションになったのです。

しかし同時に、強いプレッシャーもありました。
新規着任の場で「システム有識者」として紹介されたときは、胸に重い責任を感じました。
「自分が期待に応えられなかったらどうしよう」という不安は、喜びと同じくらいの強さで心に残りました。

それでも、上司や後輩からの反応は自分を支えるものでした。
上司からの惜別の言葉は、自分の努力が認められていた証拠であり、後輩の不安の声もまた、自分がチームにとって存在感を持っていたことを示していました。
これらの言葉は、誇らしさと同時に「新しい場所でも応えたい」という強い思いを与えてくれたのです。

異動後に得た発見と苦労

異動して最初に直面したのは、業務そのものではなく「働き方の文化の違い」でした。
以前の部署では出社が中心で、疑問や相談は隣席の同僚に声をかければすぐに解決できました。
しかし新しい部署はリモートワークが主流で、やり取りは基本的にチャット。
即時性に欠ける場面が多く、スピード感が落ちてしまうのではないかと強い懸念を覚えました。

最初は、この環境にうまくなじめず、些細なことでも不便さを感じました。
しかし、やがて「これまでのやり方をそのまま持ち込むのではなく、環境に合わせて工夫すべきだ」と考えるようになりました。
具体的には、これまで口頭で済ませていた報告や確認を資料として形に残すこと。
共有のタイミングを意識し、必要なときに誰もが参照できる状態を整えること。
こうした小さな工夫を積み重ねることで、むしろ情報伝達の透明性や再現性が高まるという副次的な効果を得られました。

また、異動を通じて人脈が広がったことは大きな収穫でした。
同じシステムに詳しい有識者と直接つながることができただけでなく、以前から自分の目標としていた人物と近い距離で仕事を共にできるようになったのです。
彼らの姿勢や考え方に触れることは、単なる技術的な知識以上に、自分のキャリア観を広げる刺激となりました。

こうして振り返ると、異動後に直面した「文化の違いによる戸惑い」は、単なる苦労ではなく、自分のスキルや考え方を拡張する契機となったと言えます。
環境が変わるからこそ得られる学びがある。
これが、異動を経験して最初に気づいた大きな価値でした。

キャリア的に見た異動の意味

異動は、単に新しい環境で仕事をすることにとどまりません。
担当者という立場で見ても、前の部署で培ったノウハウを持ち込み、新しいチームに還元できる点は大きな価値です。
同時に、新しいチームで得た知識や文化を吸収し、自分のスキルセットに加えることができます。
つまり異動は「知識とノウハウの双方向交換の場」であり、経験の幅を広げる絶好の機会なのです。

さらに、この経験は将来のキャリアに直結します。
異動を通じて築いた人脈は、将来的に横断的な案件をリードする際の基盤となります。
関係部署との信頼関係があることで、調整や協力を得やすくなり、組織全体を動かす力につながります。

また、異動で得た知識やノウハウは、管理職としての活動にも活かせます。
具体的には、以下のような場面です。

• プロダクト導入事例をチームに共有し、意思決定の材料とする
• 運用高度化や自動化、機能融合、コスト最適化といったソリューション提案に活かす
• 複数の部署で得た経験を踏まえてプロジェクト管理を行い、リスクを事前に察知する

こうした積み重ねは、将来的に人材マネジメントを担う立場になったとき、大きな力を発揮します。
単に業務をこなすだけでは得られない「横断的な視点」と「実践知の蓄積」が、異動経験によって強化されるのです。

異動は配置転換というより、キャリア形成における布石。
そう捉えることで、日々の経験が将来への投資へと変わっていきます。

キャリア形成という観点において「転職」も視野に入れている方は以下の記事もおススメです！

2024.12.15

運用保守エンジニアの次のキャリアについて実例5つを紹介

運用保守エンジニアとして働いていて、キャリアの次のステップに悩むことはありませんか？ 「自分のスキルは他の職種で通用するのか」「このまま運...

まとめ──異動はリスクの少ないキャリア形成の手段

部署異動は、自分の意思に関係なく決まることが多く、不安や戸惑いを伴うのは自然なことです。
私自身も、異動の知らせを受けたときは期待と同じくらい大きな不安を抱いていました。

しかし振り返ってみると、異動はキャリア形成における「リスクの少ない選択肢」だと確信しています。
転職のようにゼロから人間関係を築いたり、立場を一から作り直したりする必要はありません。
社内での基盤を維持しながら、新しい環境で経験を積み、知識やノウハウを吸収できるのです。

たとえ異動先で思うような成果を出せなかったとしても、その経験は必ず自分のキャリアに残ります。
文化の違いに適応する中で得られた工夫や、人脈の広がりは、後に必ず役立つ資産になります。
特に運用保守エンジニアのように幅広いシステムや部署に関わる職種においては、この「経験の厚み」がキャリアを加速させる要素になるでしょう。

異動を「会社都合の配置換え」と捉えるのではなく、「キャリア形成におけるリスクの少ない手段」として捉える。
そう意識するだけで、不安の中にも前向きな意味を見出せるはずです。
いま異動を控えている人、すでに異動に直面している人にとって、この考え方が一歩を踏み出す後押しになれば幸いです。

The post 部署異動はキャリアを広げるチャンスか？─運用保守エンジニアが実体験から考える first appeared on 運用保守エンジニアに成る。.